Protocol-04-DHCP

Protocol , Comments

动态主机配置协议DHCP(Dynamic Host Configuration Protocol) 是一种网络管理协议，用于集中对用户 IP 地址进行动态管理和配置。
DHCP协议由 RFC 2131 定义，采用 Client /服务器通信模式，由 客户端(DHCP Client) 向 **服务器(DHCP Server)**提出配置申请，Server为网络上的每个设备动态分配 IP 地址、子网掩码、默认网关地址，域名服务器(DNS)地址等参数

相关协议(按时间从远到近排序) RFC1531 、RFC1541、RFC2131 、RFC3396

DHCP好处

网络中，每个连接Internet的设备都需要分配唯一的 IP。DHCP 使网络管理员能从中心结点监控和分配IP地址，从以下几个方面降低了配置和部署设备的时间

  • 减少 IP 地址冲突：每个连接的设备都必须有一个IP地址。但是，每个地址只能使用一次，重复的地址将导致无法连接一个或两个设备的冲突。
  • IP地址管理的自动化：如果没有 DHCP，网络管理员将需要手动分配和撤消地址。手动需要随时知道设备何时需要访问网络以及何时需要离开网络。
  • 高效的变更管理：DHCP 的使用使更改地址，范围或端点变得非常简单。例如，组织可能希望将其IP寻址方案从一个范围更改为另一个范围。Server配置有新信息，该信息将传播到新端点。同样，如果升级并更换了网络设备，则不需要网络配置

DHCP 工作原理

DHCP 协议采用 UDP 作为传输协议，Client 发送请求消息到 Server 的 Port 67，Server 回应应答消息给 Client 的 Port 68，只有跟 Client 在同一个网段的 Server 才能收到 Client 广播的 DISCOVER报文。当 Client 与 Server 不在同一个网段时，必须部署DHCP中继来转发 Client 和Server之间的DHCP报文

非中继

在没有部署 DHCP中继 的场景下，首次接入网络 Client 与 Server 的报文交互过程，该过程称为DHCP报文四步交互

无中继场景时 Client 首次接入网络的报文交互示意图

第一步：发现阶段

首次接入网络的 Client 不知道 Server 的IP地址，为了学习到 Server 的IP地址，Client 以广播方式发送DISCOVER报文(目的IP地址为255.255.255.255)给同一网段内的所有设备(包括Server或中继)。DISCOVER报文中携带了 Client 的MAC地址等信息

第二步：提供阶段

与 Client 位于同一网段的 Server 都会接收到 DISCOVER报文，Server 选择跟接收 DISCOVER报文接口的IP地址处于同一网段的地址池，并且从中选择一个可用的IP地址，然后通过OFFER报文发送给Client，Server 在地址池中为 Client 分配IP地址的顺序如下：

  1. Server 上已配置的与 Client MAC地址静态绑定的 IP 地址。
  2. Client 发送的 DISCOVER报文中 Option50(请求IP地址选项)指定的地址
  3. 地址池内查找 Expired 状态的IP地址，即曾经分配给 Client 的超过租期的IP地址
  4. 在地址池内随机查找一个 Idle 状态的IP地址。
  5. 如果未找到可供分配的 IP 地址，则地址池依次自动回收超过租期的 Expired 和处于冲突状态 Conflict 的IP地址。回收后如果找到可用的IP地址，则进行分配；否则，Client 等待应答超时后，重新发送DHCP DISCOVER报文来申请IP地址

通常，Server 的地址池中会指定IP地址的租期，如果 Client 发送的 DISCOVER报文 中携带了期望租期，服务器会将 Client 请求的期望租期与其指定的租期进行比较，选择其中时间较短的租期

为了防止分配出去的IP地址跟网络中其他 Client 的IP地址冲突，比如Client所在网段已经手工配置了一个地址池中的地址用于DNS服务器，Server 在发送DHCP OFFER报文前通过发送 Source IP = ServerIP地址、Target IP 为预分配出去IP地址的 ICMP ECHO REQUEST报文 对分配的IP地址进行地址冲突探测。

  • 如果在指定的时间内没有收到应答报文，表示网络中没有 Client 使用这个IP地址，可以分配给 Client ；
  • 如果指定时间内收到应答报文，表示网络中已经存在使用此IP地址的 Client ，则把此地址列为冲突地址，然后等待重新接收到DHCP DISCOVER报文后重新选择（TODO 这个时间会不会很长，为什么不直接找一个IP地址分配）

此阶段 Server 分配给 Client 的IP地址不一定是最终确定使用的IP地址，因为DHCP OFFER报文发送给 Client 等待16秒 后如果没有收到 Client 的响应，此地址就可以继续分配给其他 Client 。

第三步：选择阶段

在发现阶段 DISCOVER报文 是广播报文，也就是说有可能有多个 Server 向 Client 回应 DHCP OFFER报文，则 Client 一般只接收第一个收到的 DHCP OFFER报文，然后以广播方式发送 DHCP REQUEST报文，该报文中包含 Client 想选择的 Server标识符(即Option50，填充了接收的DHCP OFFER报文中yiaddr字段的IP地址)

Client 广播发送 DHCP REQUEST报文通知所有的Server，它将选择某个Server提供的IP地址，其他Server可以重新将曾经分配给 Client 的IP地址分配给其他 Client 。

Server怎么判断这个报文是来请求自己分配出去的IP，还是 Client 用来告诉 Server 不用这个地址（两个DHCP 服务器分配的IP地址可能还都一样，不能通过IP判断是否是自己给的）？

第四步：确认阶段

当Server收到 Client 发送的DHCP REQUEST报文后，Server回应 DHCP ACK报文，表示 DHCP REQUEST报文 中请求的IP地址(Option50 填充的)分配给 Client 使用。

  1. Client 收到 DHCP ACK报文，会广播发送免费ARP报文，探测本网段是否有其他终端使用服务器分配的IP地址

    • 如果在指定时间内没有收到回应，表示 Client 可以使用此地址。

    • 如果收到了回应，说明有其他终端使用了此地址， Client 会向服务器发送 DHCP DECLINE报文，并重新向服务器请求IP地址，同时，服务器会将此地址列为冲突地址。当服务器没有空闲地址可分配时，再选择冲突地址进行分配，尽量减少分配出去的地址冲突

      DECLINE 是广播报文吗， 如果发送失败或者 Server无法分配其他地址呢？

  2. 当 Server 收到 Client 发送的 DHCP REQUEST报文 后，如果Client 由于某些原因（例如协商出错或者由于发送REQUEST过慢导致服务器已经把此地址分配给其他 Client )无法分配 DHCP REQUEST报文中 Option50 填充的IP地址，则发送DHCP NAK报文作为应答，通知 Client 无法分配此IP地址。** Client 需要重新发送DHCP DISCOVER报文来申请新的IP地址**

中继

有DHCP中继的场景中，首次接入网络的 Client 和Server的工作原理与无中继场景时 Client 首次接入网络的工作原理相同。主要差异是DHCP中继在Server和 Client 之间转发DHCP报文，以保证Server和 Client 可以正常交互。在 Client 看来，DHCP中继就像Server；在Server看来，DHCP中继就像 Client

如下图所示，在部署DHCP中继的场景下，首次接入网络 Client 与Server的报文交互过程

有中继场景时 Client 首次接入网络的报文交互示意图

第一步：发现阶段

DHCP中继接收到 Client 广播发送的 DHCP DISCOVER报文后，进行如下处理：

  1. 检查DHCP报文中的hops字段，如果大于16，则丢弃DHCP报文；否则，将hops字段加1(表明经过一次DHCP中继)，并继续下面的操作。

  2. 检查DHCP报文中的giaddr字段。如果是0，将giaddr字段设置为接收DHCP DISCOVER报文的接口IP地址。如果不是0，则不修改该字段，继续下面的操作。

    记录 giaddr 的目的就是在 DHCP 地址池中分配相同网段的 IP 地址

  3. 将DHCP报文的目的IP地址改为Server或下一跳中继的IP地址，源地址改为中继连接 Client 的接口地址，通过路由转发将DHCP报文单播发送到Server或下一跳中继

如果 Client 与Server之间存在多个DHCP中继，后面的中继接收到DHCP DISCOVER报文的处理流程同前面所述

第二步：提供阶段

Server接收到DHCP DISCOVER报文后，选择与报文中giaddr字段为同一网段的地址池，并为 Client 分配IP地址等参数，然后向giaddr字段标识的DHCP中继单播发送DHCP OFFER报文。

DHCP中继收到DHCP OFFER报文后，会进行如下处理：

  1. 检查报文中的giaddr字段，如果不是接口的地址，则丢弃该报文；否则，继续下面的操作。

    DHCP 服务器怎么知道是不是中继过来的？通过 hops 吗？

  2. DHCP中继检查报文的广播标志位。如果广播标志位为1，则将DHCP OFFER报文广播发送给 Client ；否则将DHCP OFFER报文单播发送给 Client 。

    广播标志位是什么时候设置的？

    为什么 DHCP OFFER 需要官博发送给 DHCP Client

第三步：选择阶段

中继接收到来自 Client 的DHCP REQUEST报文的处理过程同无中继场景下的选择阶段。

第四步：确认阶段

中继接收到来自服务器的DHCP ACK报文的处理过程同无中继场景下的确认阶段。

续租

DHCP提供了两种地址分配机制，可以根据网络需求为不同的主机选择不同的分配策略。

  • 动态分配机制：通过DHCP为主机分配一个有使用期限的IP地址
  • 静态分配机制：网络管理员通过DHCP为指定的主机分配固定的IP地址。

Client 向 Server 申请地址时可以携带期望租期，将分配租期与期望租期比较，**分配其中一个较短的租期给 Client **。租期到期或者 Client 下线释放地址后，服务器会收回该IP地址，收回的IP地址可以继续分配给其他 Client 使用。这种机制可以提高IP地址的利用率，避免 Client 下线后IP地址继续被占用。如果 Client 希望继续使用该地址，需要更新IP地址的租期(如延长IP地址租期)，更新租期过程如下

Client 更新租期示意图

  1. 当租期达到50%(T1)时，Client 会自动以单播的方式向 Server 发送 DHCP REQUEST报文，请求更新IP地址租期
    • 如果收到 Server 回应的 DHCP ACK报文，则租期更新成功(即租期从0开始计算)；
    • 如果收到 DHCP NAK报文，则重新发送 DHCP DISCOVER报文请求新的IP地址。
  2. 当租期达到87.5%(T2)时，如果仍未收到Server的应答，Client 会自动以广播的方式向 Server 发送 DHCP REQUEST报文，请求更新IP地址租期。后续处理逻辑同上
  3. 如果租期时间到时都没有收到服务器的回应， Client 停止使用此IP地址，重新发送DHCP DISCOVER报文请求新的IP地址。

Client 在租期时间到之前，如果不想使用分配的IP地址(例如 Client 网络位置需要变更)，会触发 Client 向 Server 发送 DHCP RELEASE报文，通知 Server 释放IP地址的租期。Server 会保留这个 Client 的配置信息，将IP地址列为曾经分配过的IP地址中，以便后续重新分配给该 Client 或其他 Client 。 Client 可以通过发送 DHCP INFORM报文向服务器请求更新配置信息

部署DHCP中继时，更新租期的过程与上述过程相似。

Client 通过DHCP中继更新租期示意图

**如果不是首次呢，比如客户端重启了 ？**如果客户端重启后，会自动发送 DHCP REQUEST广播 给 Server 以便请求继续租用原来使用的IP地址，

  • 如果服务器收到这个消息，确认客户端可以使用该地址，则回答一个DHCP ACK确认消息
  • 如果此IP地址已经无法再分配，则返回一个 DHCP NCK否认信息，客户端收到这个信息以后，则必须重新发送 DHCP Discovery消息获取新的地址(启动首次登录的流程)。 若没有得到响应，则尝试与网关通信，如果通信正常，这个租期还没到期的话，则可以继续使用，但是不能和网关通信的话，则会获得169.254.0.1~169.254.255.254之间的IP地址，然后每隔5min尝试更新租约

DHCP 报文

Server 与 Client 之间通过DHCP报文进行通信。DHCP报文是基于UDP协议传输的。Client 使用的端口号为68，Server 使用的端口号为67。目前DHCP定义了如下八种类型报文，每种报文的格式相同，只是某些字段的取值不同

报文名称 说明
DHCP DISCOVER Client 首次登录网络时进行DHCP交互过程发送的第一个报文，用来寻找Server。
DHCP OFFER Server用来响应DHCP DISCOVER报文，此报文携带了各种配置信息。
DHCP REQUEST 此报文用于以下三种用途。
1. Client 初始化后，发送广播的 DHCP REQUEST报文来回应服务器的DHCP OFFER报文。
2. Client 重启后，发送广播的 DHCP REQUEST报文来确认先前被分配的IP地址等配置信息。
3. 当 Client 已经和某个IP地址绑定后，发送 DHCP REQUEST单播或广播报文来更新IP地址的租约。
DHCP ACK Server 对 Client 的DHCP REQUEST报文的确认响应报文，Client收到此报文后，才真正获得了IP地址和相关的配置信息。
DHCP NAK 服务器对Client 的DHCP REQUEST报文的拒绝响应报文，例如Server收到DHCP REQUEST报文后，没有找到相应的租约记录，则发送DHCP NAK 报文作为应答，告知 Client 无法分配合适IP地址。
DHCP DECLINE 当 Client 发现服务器分配给它的IP地址发生冲突时会通过发送此报文来通知服务器，并且会重新向服务器申请地址。
DHCP RELEASE Client 可通过发送此报文主动释放服务器分配给它的IP地址，当服务器收到此报文后，可将这个IP地址分配给其它的 Client 。
DHCP INFORM Client 获取IP地址后，如果需要向Server获取更为详细的配置信息(网关地址、DNS服务器地址)，则向Server发送DHCP INFORM请求报文。

报文地址：https://wiki.wireshark.org/uploads/__moin_import__/attachments/Development/PcapNg/dhcp.pcapng

DHCP 四步交互如下

image-20230907230303654

服务端的端口是 67，客户端的端口是 68

这里有一个疑问就是 192.168.0.10 是从哪里来的，DHCP 服务器分配之后直接写进去了

Discover

image-20230907230549875

DHCP 报文格式一样，只是最后的 Option 不同，前面包含的字段如下：

  • Message type：报文的操作类型。分为请求报文和响应报文，1为请求报文，2为响应报文。具体报文类型在option字段中标识
  • Hardware type：DHCP客户端的硬件地址类型。1表示ethernet地址
  • Hardeare address length：DHCP客户端的硬件地址长度。Ethernet地址为6
  • Hops：DHCP报文经过的DHCP中继的数目。初始为0，报文每经过一个DHCP中继，该字段就会增加1
  • Transaction ID: 客户端发起一次请求时选择的随机数，用来标识一次地址请求过程
  • Seconds elapsed: Client 开始DHCP请求后所经过的时间。目前尚未使用，固定取0
  • Bootp flags：DHCP服务器响应报文是采用单播还是广播方式发送。只使用第0比特位，0表示采用单播方式，1表示采用广播方式，其余比特保留不用
  • Client IP address: DHCP客户端的IP地址
  • Your(client) IP address: DHCP服务器分配给客户端的IP地址
  • Next server IP address：DHCP客户端获取IP地址等信息的服务器IP地址
  • Relay agent IP address: DHCP客户端发出请求报文后经过的第一个DHCP中继的IP地址
  • Client MAC address: DHCP客户端的硬件地址
  • Server host name: DHCP客户端获取IP地址等信息的服务器名称
  • Boot file name: DHCP服务器为DHCP客户端指定的启动配置文件名称及路径信息
  • Magic cookie: 标识和解释DHCP消息的元素，有助于确保不同设备之间的协议兼容性，并提供了消息类型和选项格式的关键信息
  • Option：可选变长选项字段，包含报文的类型、有效租期、DNS服务器的IP地址和WINS服务器的IP地址等配置信息。

因为是广播报文，所以目的地址是 255.255.255.255，其中

  • Option(53): 表示 DHCP 消息类型，Discover(1)
  • Option(50): 用来记录请求的 IP
  • Option(55): 用来请求其他参数
  • Option(61): 客户端标识符

Offer

image-20230907230844722

这里也包含了很多 Option:

  • Option(53): DHCP 消息类型，Offer(2)
  • Option(1): 子网掩码， 255.255.255.0
  • Option(58): 续租时间 T1，一般为租期的 50%
  • Option(59): 重新发起T2, 租约响应超时，重新发起广播时间，一般位租期的 87.5%
  • Option(51): 租约
  • Option(54): DHCP服务器标识符选项

Request

image-20230907231535947

这里也包含了很多 Option:

  • Option(53): DHCP 消息类型，Request(3)
  • Option(61): 客户段标识
  • Option(50): 请求的 IP
  • Option(54): 服务端标识
  • Option(55): 请求的参数

ACK

image-20230907231557794

这里也包含了很多 Option:

  • Option(53): DHCP 消息类型，Ack(5)
  • Option(1): 子网掩码， 255.255.255.0
  • Option(58): 续租时间 T1，一般为租期的 50%
  • Option(59): 重新发起T2, 租约响应超时，重新发起广播时间，一般位租期的 87.5%
  • Option(51): 租约
  • Option(54): DHCP服务器标识符选项

DHCP Snooping

DHCP Snooping 是DHCP的一种安全特性，用于保证 DHCP客户端从合法的 DHCP服务器获取IP地址，并记录DHCP客户端IP地址与MAC地址等参数的对应关系。DHCP Snooping 用来抵御网络中针对DHCP的各种攻击

  1. DHCP攻击有哪些
  2. 它的原理是什么

DHCP 攻击

1. DHCP Server仿冒者攻击

由于 Server 和 Client 之间没有认证机制，而 DHCP Discover报文 是以广播形式发送，如果在网络上随意添加一台 DHCP服务器，它就可以为 Client 分配IP地址以及其他网络参数。

DHCP Client发送DHCP Discover报文示意图

如果此时 DHCP Server仿冒者 回应给 Client 仿冒信息，如错误的网关地址、错误的DNS(Domain Name System)服务器、错误的IP等信息。Client 将无法获取正确的IP地址和相关信息，导致合法客户无法正常访问网络或信息安全受到严重威胁。

img

解决办法：为了防止DHCP Server仿冒者攻击，可配置设备接口的 信任(Trusted)/非信任(Untrusted)工作模式

将与合法DHCP服务器直接或间接连接的接口设置为信任接口，其他接口设置为非信任接口。此后，从非信任(Untrusted)接口上收到的DHCP回应报文将被直接丢弃，这样可以有效防止DHCP Server仿冒者的攻击

img

2. 防止非DHCP用户攻击

在DHCP网络中，静态获取IP地址的用户（非DHCP用户）对网络可能存在多种攻击，譬如仿冒DHCP Server、构造虚假DHCP Request报文等。这将为合法DHCP用户正常使用网络带来了一定的安全隐患

解决办法：开启设备根据 DHCP Snooping绑定表 生成接口的静态MAC表项功能，设备将根据接口下所有的DHCP用户对应的DHCP Snooping绑定表项自动执行命令生成这些用户的静态MAC表项，并同时关闭接口学习动态MAC表项的能力。此时，只有源MAC与静态MAC表项匹配的报文才能够通过该接口，否则报文会被丢弃。因此对于该接口下的非DHCP用户，只有管理员手动配置了此类用户的静态MAC表项其报文才能通过，否则报文将被丢弃。

动态MAC表项是设备自动学习并生成的，静态MAC表项则是根据命令配置而成的。MAC表项中包含用户的MAC、所属VLAN、连接的接口号等信息，设备可根据MAC表项对报文进行二层转发

3. 防止仿冒DHCP报文攻击

已获取到IP地址的合法用户通过向服务器发送 DHCP Request 或 DHCP Release 报文用以续租或释放IP地址。

  • 如果攻击者冒充合法用户不断向DHCP Server发送DHCP Request报文来续租IP地址，会导致这些到期的IP地址无法正常回收，以致一些合法用户不能获得IP地址；
  • 而若攻击者仿冒合法用户的DHCP Release报文发往DHCP Server，将会导致用户异常下线

解决办法：利用DHCP Snooping绑定表的功能。设备通过将DHCP Request续租报文和DHCP Release报文与绑定表进行匹配操作能够有效的判别报文是否合法(主要是检查报文中的VLAN、IP、MAC、接口信息是否匹配动态绑定表)，若匹配成功则转发该报文，匹配不成功则丢弃

4. 防止DHCP Server服务拒绝攻击

若设备接口if1 下存在大量攻击者恶意申请IP地址，会导致DHCP Server中IP地址快速耗尽而不能为其他合法用户提供IP地址分配服务。

另一方面，DHCP Server通常仅根据DHCP Request报文中的(Client Hardware Address)字段来确认客户端的MAC地址。如果某一攻击者通过不断改变CHADDR字段向DHCP Server申请IP地址，同样将会导致DHCP Server上的地址池被耗尽，从而无法为其他正常用户提供IP地址

img

解决办法：

  • 为了抑制大量 Client 恶意申请IP地址，在使能设备的DHCP Snooping功能后，可配置设备或接口允许接入的最大DHCP用户数，当接入的用户数达到该值时，则不再允许任何用户通过此设备或接口成功申请到IP地址。

  • 通过改变DHCP Request报文中的CHADDR字段方式的攻击，可使能设备检测DHCP Request报文帧头MAC与DHCP数据区中CHADDR字段是否一致功能，此后设备将检查上送的DHCP Request报文中的帧头MAC地址是否与CHADDR值相等

5. LDRA功能感知用户位置信息

LDRA称为轻量级DHCPv6中继代理，该中继代理能够记录用户位置信息并将其发送到 DHCPv6 Server，从而使得DHCPv6 Server能够获取到用户详细的物理位置信息，以实现对用户客户端部署诸如地址分配、计费、接入控制等策略

LDRA应用组网图

解决办法：在使能Switch的DHCP Snooping功能之后，可使能其LDRA功能。Switch既能够获取用户详细的位置信息并将其发送到DHCPv6 Server。DHCPv6 Server即可根据用户的详细位置信息为其部署地址分配策略或其他安全策略

LDRA功能仅是记录了DHCPv6用户的详细位置信息并通过 RELAY-FORW报文 将该信息发送给DHCPv6 Server，对不同的用户部署诸如地址分配、计费、接入控制等策略，由DHCPv6 Server实现

实现原理

DHCP Snooping分为DHCPv4 Snooping和DHCPv6 Snooping，两者实现原理相似。开启 DHCP Snooping 的接口会根据 DHCP 请求与响应生成 DHCP Snoop 绑定表，后续设备再从盖接口接受用户发送的 DHCP 报文时，会进行匹配检查

img

如下图所示的DHCP场景中，连接在二层接入设备上的PC配置为自动获取IP地址。PC作为DHCP客户端通过广播形式发送DHCP请求报文，使能了DHCP Snooping功能的二层接入设备将其通过信任接口转发给DHCP服务器。最后DHCP服务器将含有IP地址信息的DHCP ACK报文通过单播的方式发送给PC。在这个过程中，二层接入设备收到DHCP ACK报文后，会从该报文中提取关键信息（包括PC的MAC地址以及获取到的IP地址、地址租期），并获取与PC连接的使能了DHCP Snooping功能的接口信息（包括接口编号及该接口所属的VLAN，根据这些信息生成DHCP Snooping绑定表。

img

DHCP Snooping绑定表 根据DHCP租期进行老化或根据用户释放IP地址时发出的DHCP Release报文自动删除对应表项

由于DHCP Snooping绑定表记录了DHCP客户端IP地址与MAC地址等参数的对应关系，故通过对报文与DHCP Snooping绑定表进行匹配检查，能够有效防范非法用户的攻击。

为了保证设备在生成DHCP Snooping绑定表时能够获取到用户MAC等参数，DHCP Snooping功能需应用于二层网络中的接入设备或第一个DHCP Relay上。

在DHCP中继使能DHCP Snooping场景中，DHCP Relay设备不需要设置信任接口。因为DHCP Relay收到DHCP请求报文后进行源目的IP、MAC转换处理，然后以单播形式发送给指定的合法DHCP服务器，所以DHCP Relay收到的DHCP ACK报文都是合法的，生成的DHCP Snooping绑定表也是正确的

总结来说，是有一个 DHCP Snooping 绑定表用来记录以及校验 DHCP 报文，另外还有校验 二层 MAC 地址与 DHCP 的 Client mac address 的功能

DHCPv6

546号端口用于 DHCPv6 Client，而不用于DHCPv4，是为DHCP failover服务，这是需要特别开启的服务，DHCP failover是用来做双机热备的

参考链接

  1. https://info.support.huawei.com/info-finder/encyclopedia/zh/DHCP.html
  2. https://support.huawei.com/hedex/hdx.do?docid=EDOC1100087046&id=ZH-CN_CONCEPT_0176371515
  3. https://support.huawei.com/hedex/hdx.do?docid=EDOC1100087046&id=ZH-CN_CONCEPT_0176371535
  4. https://info.support.huawei.com/info-finder/encyclopedia/zh/ICMP.html
  5. https://wiki.wireshark.org/DHCP.md
  6. https://info.support.huawei.com/info-finder/encyclopedia/zh/DHCP+Snooping.html