个人认为，理解报文就理解了协议。通过报文中的字段可以理解协议在交互过程中相关传递的信息，更加便于理解协议。

因此本文将在DHCP协议报文的基础上进行介绍。在这里插入图片描述

其他相关资料：

…
DHCP还存在大量相关RFC，感兴趣者可查阅相关资料。

Note：第一章主要简介了DHCP相关背景。有相关基础可以直接阅读第二和三章节。
个人能力有限，敬请各位指导。
关于169.254.0.0/16，这里进行简单说明。RFC3927所分配定义，具有链路本地范围。这一地址目前主要用于Client启动DHCP失败后，自动分配的一个地址。

目录

DHCP

1.背景介绍

1.1.DHCP简介

DHCP的需求主要来自于网络规模的扩大和网络复杂度的提高。终端位置变化(如便携机或无线网络）和计算机数量超过可分配的IP地址，造成IP地址变化频繁以及IP地址不足的情况。此时，人力将难以胜任该工作。

DHCP是Dynamic HostConfiguration Protocol动态主机配置协议的简称，是一种对用户进行集中的动态管理和配置的技术DHCP技术保证了IP地址的合理分配问题，从而避兔了IP地址的浪费，提高了整网的IP地址使用率。

1.2.网络发展

在网络发展的初期，可以部署RARP服务器来为特定主机分配IP地址。主要用于无盘工作站，在网卡启动时发送携带自身Mac地址的请求报文。RARP服务器为其分配相应的IP地址后，终端可正常工作。
关于RARP基本原理，可参考博客ARP/RARP原理介绍+报文分析+配置示例

后续发展出了BOOTSTRAP PROTOCOL协议，也即BOOTP协议。无盘系统也可通过该协议获取相应的IP地址。除此之外，BOOTP协议还可获取子网掩码和DNS等相关信息。
关于BOOTP协议，可参考RFC951-BOOTSTRAP PROTOCOL (BOOTP)。

DHCP协议则相当于BOOTP协议的升级Plus版。因为BOOTP协议一个很大缺点在于为主机分配的IP对应是静态的。DHCP协议使用Client/Server架构，继承了BOOTP协议大部分内容。两者都使用UDP的67和68端口进行信息交互。
但DHCP可支持地址的动态分配，并具有多种Option属性具有丰富的可扩展性。

1.3.相关特性

RFC2131-Dynamic Host Configuration Protocol中介绍DHCP支持三种地址分配方式：
1@：automatic allocation自动分配。DHCP 为Client分配一个永久 IP 地址。

2@：dynamic allocation动态分配。DHCP 在有限的时间段内（或直到Client明确放弃该地址）将 IP 地址分配给Client。动态分配是三种机制中唯一一种允许自动重用Client不再需要特定地址的方式。

3@：manual allocation手动分配。Client的 IP 地址由网络管理员分配，DHCP 仅用于将分配的地址传达给Client。 特定网络将使用其中一种或多种机制，具体取决于网络管理员的策略。

DHCP设计目标：
1@：DHCP 必须允许本地系统管理员根据需要控制配置参数。例如，本地系统管理员应该能够在需要时执行有关分配和访问本地资源的本地策略。
2@：Client不应要求手动配置。每个Client都应该能够在没有用户干预的情况下发现适当的本地配置参数，并将这些参数合并到自己的配置中。
3@：网络不应要求对单个Client进行手动配置。在正常情况下，网络管理器不必为每个Client配置参数。
4@：DHCP 不应要求每个子网上都有Server。DHCP 必须允许跨路由器或通过 BOOTP delay的干预工作。
5@：DHCP Client必须准备好接收对配置参数请求的多个响应。 某些安装可能包括多个重叠的 DHCP Server，以增强可靠性和提高性能。
6@：DHCP 必须与 RFC 951 和 RFC 1542 所述的 BOOTP 中继代理行为进行互操作。DHCP 必须为现有的 BOOTP Server提供服务。
7@：保证任何特定的网络地址不会同时被多个 DHCP Client使用。
8@：DHCP Client重新启动期间保留 DHCP Client配置。 应尽可能为 DHCP Client分配相同的配置参数（例如，网络地址）以响应每个请求。
9@：在Server重新启动时保留 DHCP Client配置，并且，只要有可能，尽管重新启动了 DHCP 机制，仍应为 DHCP Client分配相同的配置参数。
10@：允许自动将配置参数分配给新客户端，以避免手动配置新客户端，
11@：支持将配置参数固定或永久分配给特定客户端。

点击此处回到目录

2.DHCP基本原理

在这里插入图片描述在具体介绍之前，这里先介绍DHCP底层封装：
1@：这里显示为广播帧是特定DHCP报文的显示结果，后续进行介绍。
2@：IP报文中的通常用于QOS的DSCP字段为0，是低等级的优先报文。这一点与OSPF/BGP不同。
3@：IP报文中的TTL字段为128，这一特点允许其跨局域网进行转发。而其他协议报文则有明确限制，例如IGMP的TTL=1，OSPF的TTL=1，VRRP的TTL=255。这些特定TTL都是基于协议安全的考虑。
4@：使用IP协议号17（也即UDP协议）进行承载。DHCP/BOOTP使用67/68作为目的端口进行识别。
其中DHCP Client使用68端口，监听来自Server的68端口，向Server使用的67端口发送消息；
DHCP Server使用67端口，监听来自Client的67端口，向Client使用的68端口发送消息。

@1：这里的 IP TTL 仅用于说明协议未做严格限制。一个重要考虑可能是Relay中继情况下跨越多个子网的情况。
在这里插入图片描述//dhcp set ttl命令用于DHCP请求报文在经过DHCP中继三层转发之后的处理情况。自动换行
@2：UDP的 SPort 未使用68作为Client的SPort，应与网卡厂家的DHCP实现相关。

2.1.DHCP 基本报文格式

在这里插入图片描述Op–Message op code / message type：1字节。表示DHCP/BOOTP报文类型–取值1表明为BOOTREQUEST（Client发给Server）, 取2表明为BOOTREPLY（Server发给Client）。
Htype–Hardware address type：1字节。取值1表示为10M Ethernet，目前也沿用该值。
hlen–Hardware address length：1字节。取值6表示为10M Ethernet，目前也沿用该值。
hops：1字节。Client通常设备为0，在中继代理是有意义。
xid：4字节。Transaction ID，Client选择的随机数。可用于标识特定会话。Client和Server的交互需要xid一致。
secs：2字节。由Client填写自Client开始地址获取或续订过程地址以来已经过去了几秒钟。
flags：2字节。目前仅第一个bit使用，broadcast flag。取1时标识报文为广播报文。
当DISCOVER的BOOTP Flag的B-bit未置位，Server应当以单播方式进行回应 OFFER 消息。
ciaddr：4字节。Client IP address。仅当Client处于绑定、续订或重新绑定状态并且可以响应 ARP 请求时才填写。
yiaddr：4字节。‘your’ (client) IP address。也即DHCP Server告知Client分配到的地址。
siaddr：4字节。bootstrap引导所使用的下一个服务器的地址。在DHCPOFFER, DHCPACK中携带。
giaddr：4字节。Relay agent IP address。在中继场景下使用。
chaddr：16字节。Client hardware address。
sname：64字节。Server Host Name。可选的Server主机名，以Null结尾的字符串。
file：128字节。Boot file name，以Null结尾的字符串。
Option：可变长。DHCP Client必须准备好接收长度至少为 312*8字节的“选项”字段的 DHCP 消息。

DHCP Option前4个字节为magic cookie。RFC1497中解释用于后续数据的模式说明。通常固定为0x63，0x82，0x53和0x63。
DHCP Option最后1个字节为Option255，该Option无length和value字段。
DHCP Option其余字段采用TLV的格式进行定义：
Type/Option=1字节，用于说明Option类型。也即DHCP最多有255种Option；
Length=1字节，用于说明Value字段的长度。也即Value字段最多有255字节；
Value=可变长，用于携带DHCP的具体参数信息。

DHCP报文示例：
在这里插入图片描述
//上图为DHCP的一个报文示例。
自动换行
Q：从上文的DHCP/BOOTP报文字段介绍中，我们可以发现在通用字段中只能标识报文发送类型。那么报文的具体类型应该如何体现？
A：通过Option53 DHCP Message Type 辨别具体的报文类型。目前该Option中定义了18种DHCP消息，这里仅介绍前8种。

Value Mess Type Ref.
1 DISCOVER RFC2123
2 OFFER RFC2123
3 REQUEST RFC2123
4 DECLINE RFC2123
5 ACK RFC2123
6 NAK RFC2123
7 RELEASE RFC2123
8 INFORM RFC2123
9 FORCERENEW RFC3203
10 LEASEQUERY RFC4388
11 LEASEUNASSIGNED RFC4388
12 LEASEUNKNOWN RFC4388
13 LEASEACTIVE RFC4388
14 BULKLEASEQUERY RFC6926
15 LEASEQUERYDONE RFC6926
16 ACTIVELEASEQUERY RFC7724
17 LEASEQUERYSTATUS RFC7724
18 TLS RFC7724

DHCP常用8种消息的作用：
DISCOVER： Client广播以发现Server存在；

OFFER：Server携带相应网络参数回应Client的DISCOVER消息；

REQUEST：1@Client携带特定一台Server提供的网络参数用于隐式拒绝其他Server提供的网络参数；
2@Client重启等情况，用于直接确认先前获得地址的可用性；
3@动态分配方式下，Client用于租期续约。

DECLINE：Client向Server广播通知分配地址的不可用性。

ACK：Server携带网络参数向Client固化网络配置。

NAK：Server向Client表明获得地址的错误性。

RELEASE：Client向Server单播通知撤销所分配地址并释放租约。

INFORM：Client向Server广播请求获取其他本地配置参数。

2.2.DHCP C/S基本交互过程

这里以局域网内有两台Server为例进行相关说明：（无DHCP Relay情况）
在这里插入图片描述//如上图所示DHCP的 Client/Server 交互首先由Client发起。
第一次Client/Server交互：
1@Client广播DISCOVER消息：该报文在局域网内广播，并携带了期望的地址和租期等Option信息。

2@Server回应OFFER消息：局域网内所有Server都会回应OFFER消息，该OFFER消息的yiaddr（your (client) IP address）字段中携带Server所提供的地址信息。并在发送前，Server可以检测该地址的可用性。例如进行ICMP探测。
Client可能会收到多个OFFER消息，通常Client以第一个收到的OFFER消息为主进行响应；
如果Client在定时器内未收到 OFFER 消息，则客户端超时并重新传输 DISCOVER消息。

第二次Client/Server交互：
3@Client广播REQUEST消息：该报文在局域网内广播，并携带了Option信息。
Option50=Requested IP Address，Value值携带步骤2@中Server提供的yiaddr（your (client) IP address）字段地址。
Option54=DHCP Server Identification，Value值携带步骤2@中Server提供的DHCP Server Identification相关信息。用于指示Client选择了哪个Server。

4@Server广播ACK/NAK消息：REQUEST 消息中选择的Server将Client的网络信息进行绑定，并使用包含配置参数的 ACK 消息进行响应。

  • Server和Client都通过DHCP报文的Option61=Client Identifier或Chaddr字段（Client hardware address）与分配的网络地址的组合构成了客户端租约的唯一标识符。
  • 如果所选Server无法满足Client的REQUEST消息请求，则回应NAK消息。
  • 如果所选Server收到REQUEST消息，则应将先前提供的地址进行绑定。
  • 如果所选Server未收到REQUEST消息，则先前提供的地址应当可分配给其他Client。

Client收到ACK/NCK后的动作：

  • Client对所分配的网络参数进行最终检测和记录。例如地址复用检测。如果地址被占用则应发送 DECLINE 消息，随后在一定定时器时间后重启DHCP交互过程。
  • 如果Client收到 NAK 消息，Client将重启DHCP交互过程。
  • 如果Client既未收到ACK又未收到NCK消息，应在一定定时器时间后和重传次数后重传 REQUEST 消息。如果还未收到响应消息，Client将重启DHCP交互过程。

图示的Graceful shutdown：
Client主动向Server单播发送 RELEASE 消息来放弃其在网络地址上的租约。

RELEASE 消息使用客户端租约的唯一标识符确认要释放的租约。也即前文所说的Option61=Client Identifier或Chaddr字段（Client hardware address）与分配的网络地址的组合。如果客户端在获取租约时使用Option61，则必须在 RELEASE 消息中使用Option61。

自动换行
DHCP地址重用过程：
如果Client记住并希望重用以前分配的网络地址，则客户端可以选择省略上述某些步骤。例如，我们的电脑和手机在家庭WIFI网络中通常获得的都是同一个地址。
在这里插入图片描述1@Client广播REQUEST消息：该报文在局域网内广播，并携带了Option信息。
Option50=Requested IP Address，Value值携带先前Server提供也即本地记录保存的地址。

2@Server广播ACK/NAK消息：REQUEST 消息中选择的Server将Client的网络信息进行绑定，并使用包含配置参数的 ACK 消息进行响应。

  • 此时，Server不应进行地址可用探测，因为此时Client可能会进行响应。
  • 如果所选Client请求无效，则Server回应NAK消息。
  • 如果所选Server收到REQUEST消息，则应将先前提供的地址进行绑定。
  • 如果所选Server未收到REQUEST消息，则先前提供的地址应当可分配给其他Client。

Client收到ACK/NCK后的动作：

  • Client对所分配的网络参数进行最终检测和记录。例如地址复用检测。如果地址被占用则应发送 DECLINE 消息，随后在一定定时器时间后重启DHCP交互过程。
  • 如果Client NAK 消息，Client将重启DHCP交互过程。
  • 如果Client既未收到ACK又未收到NCK消息，应在一定定时器时间后和重传次数后重传 REQUEST 消息。如果还未收到响应消息，Client将重启DHCP交互过程。

DHCP的相关参数说明：
1@：由于Client和Server之间很可能不存在时钟同步，因此时间在DHCP消息中显示为相对时间。并且出于补偿考虑，Server提供给Client的租期时间可以比Server保存到本地数据库的租约持续时间短。

2@：如果Client通过其他方式（例如手动配置）获得了网络地址，则可以使用 INFORM 请求消息来获取其他本地配置参数。响应的 Server 应单播给 INFORM 消息中 ciaddr 地址回应 ACK/NCK 消息。

3@：Client在初始化和报文发送中，无需请求所有的Option。仅在Client明确在消息中请求的Option才需携带，并且Server应当对其进行响应。未携带的Option应当认为其选定为默认值。

3@：每当本地网络参数可能已更改时，Client应使用 DHCP 重新获取或验证其 IP 地址和网络参数。如果此时 Client 无法正常向 Server 通信，则Client可继续使用先前的网络参数直至租约过期。

点击此处回到目录

2.3.DHCP 协议原理

Server的Option54=DHCP Server Identification：
服务器必须选择一个地址作为 DHCP Server Identification。
如果Server和Client在同一子网中，Server使用在该子网上进行通信的IP地址作为 DHCP Server Identification。
如果Server和Client在不同子网中，Server使用从接收消息的接口中选择一个地址作为 DHCP Server Identification。

Server的报文类型：
在所有情况下，当“giaddr”为零时，服务器会向0xffffffff广播任何DHCPNAK消息。
如果“giaddr”字段为零，“ciaddr”字段为非零，则 Server 将 OFFER 和 ACK 消息单播到“ciaddr”中的地址。
如果“giaddr”为零，“ciaddr”为零，并且设置了广播位，则 Server 将 OFFER 和 ACK 消息广播到0xffffffff。
并且“giaddr”为零，“ciaddr”为零，并且未设置了广播位，则 Server 将 OFFER 和 ACK 消息单播到 Client 的硬件地址和“yiaddr”地址。

sname和file字段：
如果DHCP消息的sname和file字段被使用，则Option中必须携带Option52=Overload。

Server的手动控制：
DHCP Server不需要响应它们收到的每个 DISCOVERY 和 REQUEST 消息。 例如，为了保持对连接到网络的 Client 的严格控制，网络管理员可以选择将 DHCP Server配置为仅响应以前通过某种外部机制注册的Client。

Server通过Client的 Option61=Client Identifier 来识别特定Client。如果Client未通告该Option，则Server必须使用 chaddr=Client Hardware Address 字段的内容来标识Client。

Client可以使用多种方式来填充 Option61=Client Identifier，例如制造商标识，DNS名称等。

Server的提供地址原则：
Server以如下原则为Client分配相应的地址：

  • Client当前绑定的地址。
  • Client当前绑定，但已经过期的地址。此时Server还需保证该地址在可分配地址池中状态正常。
  • Client中携带的 Option50=Requested IP Address的地址。此时Server还需保证该地址在可分配地址池中状态正常。
  • Server的可用地址池中分配的新地址。

对于地址的租约情况有如下原则：

  • DISCOVER 消息中未请求特定租约，但Client已分配网络地址。Server 回应先前提供的租约。
  • DISCOVER 消息中未请求特定租约未获得地址，Server 回应本地默认租约。
  • DISCOVER 消息中请求特定租约，Server 依照本地策略同意或选择其他租约。

Server接收REQUEST消息：

  • 如果REQUEST 消息包含Option54= DHCP Server Identification，则该消息是对 OFFER 消息的响应。
  • Client的 REQUEST 消息包含 Option61=Client Identifier 来识别，必须在所有后续消息中使用相同的 Client Identifier。
  • Server对 REQUEST 消息的响应不应与 Client 正在响应的早期 OFFER 消息中的参数冲突。
  • 在初始化重启状态期间生成的 REQUEST：不得携带 Option54=DHCP Server Identification，Option50=Requested IP address必须填写 Client 先前分配的地址。ciaddr 字段必须为零。
  • 在续订状态期间生成的 REQUEST（第一次单播续租）：不得携带 Option54=DHCP Server Identification 和 Option50=Requested IP address，ciaddr 字段必须填写 Client 先前分配的地址。
  • 在重新绑定状态期间生成的 REQUEST（第二次广播续租）：不得携带 Option54=DHCP Server Identification 和 Option50=Requested IP address，ciaddr 字段必须填写 Client 先前分配的地址。

2.4.DHCP 状态机

在RFC2131的4.4.章节提及Client状态机，此时仅仅简单说明：
在这里插入图片描述1@：Client从 INIT 状态开始并形成 DHCP 发现消息。 此时Client启动 1-10s 间随机等待计时器，以便取消DHCP的使用。
Client可以通过包含“参数请求列表”选项来请求特定参数。 客户端可以通过包括 Option55=Parameter Request List 和 Option51=IP Address Lease Time 来建议网络地址和/或租用时间。

2@：Client在一定时间内收集 OFFER 消息，通常选择第一接收到的 OFFER 或先前使用Server的 OFFER 消息进行回应。如果参数可接受，则Client会记录 Option54=DHCP Server Identification 中提供参数的服务器的地址，并在 REQUEST 广播消息携带该。

3@： 一旦收到来自Server的 ACK 消息，Client就会被初始化并进入 BOUND 状态。

4@：Client以 INIT-REBOOT 状态启动时，将直接发送 REQUEST 消息。 客户端必须在 REQUEST 消息中插入Option50=Requested IP Address，携带其已知网络地址。 Client可以通过携带 Option55=Parameter Request List来请求特定的配置参数。 但该 REQUEST 消息不得携带 Option54=DHCP Server Identification。

5@：Client维护两个时间T1=0.5*duration_of_lease，T2=0.875*duration_of_lease，用于尝试延长其网络地址租约的时间。T1 是Client进入 RENEWING 状态的时间，T2是Client进入 REBINDING 状态的时间。
在第一次T1到达时，Client向Server单播发送 REQUEST 消息。Client收到 ACK 消息后可刷新租期时间。如果Client既未收到 ACK 消息又未收到 NAK 消息，将在T2时间点广播发送 REQUEST 消息。

这一处理过程与基本处理过程的内容相似，因此省略关于 NAK 等内容。

点击此处回到目录

3.DHCP配置示例

3.1.DHCP配置示例

AR1设备基于接口作为DHCP Server：
在这里插入图片描述DHCP Relay 用于 DHCP Server 与 Client 位于不同子网的场景，DHCP Relay 会将来自 Client 的消息全部以单播方式代替 Client 向 Server 进行请求。
当然此时还会将 giaddr=Relay agent IP address 字段填充相应的 Relay 地址。

AR1：
dhcp enable
#
interface GE0/0/0
 ip address 10.1.1.1 255.255.255.0
 dhcp select interface
 dhcp server gateway-list 10.1.1.1
 dhcp server excluded-ip-address 10.1.1.2
 dhcp server static-bind ip-address 10.1.1.100 mac-address 00e0-fc88-b684
 //设备可实现部分绑定。
 dhcp server lease day 30 hour 0 minute 0
 dhcp server dns-list 10.1.1.2
 dhcp server domain-name huawei.com
#

AR2：
dhcp enable
#
interface GE0/0/1
 ip address 10.20.20.1 255.255.255.0
 dhcp select relay
 dhcp relay server-ip 10.1.1.1
#

这里Relay还可指定DHCP服务器组的方式指定多个DHCP Server。
在这里插入图片描述//Relay绑定DHCP服务器组。需定义DHCP服务器组。

dhcp server group <group1>
 dhcp-server 20.1.1.1 0
 dhcp-server 30.1.1.1 1
#

自动换行
AR1设备基于全局地址池作为DHCP Server：直接贴出配置

dhcp enable
#                                                                               
dhcp option template template1                                                  
 gateway-list 10.1.1.1                                                          
 next-server 10.1.1.3                                                           
 bootfile configuration.ini  
#
ip pool pool1
 gateway-list 10.1.1.1                                                          
 network 10.1.1.0 mask 255.255.255.0                                            
 excluded-ip-address 10.1.1.2 10.1.1.3                                          
 static-bind ip-address 10.1.1.4 mac-address 00e0-fc96-e4c0 option-template template1                                                                          
 lease unlimited                                                                
 dns-list 10.1.1.2        
#
interface GigabitEthernet0/0/1
 ip address 10.1.1.1 255.255.255.0
 dhcp select global
#

这里的模板用于为特定Client设定无盘启动，远程加载10.1.1.3的 Server 系统文件。

3.2.DHCP常用命令

在这里插入图片描述//ip address dhcp-alloc设置设备作为DHCP Client。
在这里插入图片描述//设置设备作为DHCP Client时，进行DHCP交互时携带自定义参数。

例如 dhcp client default-route preference <> 用于设定接收到DHCP路由/User Network Router路由的优先级。默认为60。
注意不同设备对DHCP支持能力不同，比如定义作为Client时携带 Option55=Parameter Request List。其他命令可查阅相关资料。

在这里插入图片描述//设置设备作为 DHCP Server 时，进行DHCP交互时携带参数。
在这里插入图片描述//查看设备的dhcp相关消息。

3.3.真实场景下DHCP报文交互

Windows系统下的DHCP：
在这里插入图片描述其中ipconfig /release命令用于重启整个DHCP报文交互过程；
ipconfig /renew命令用于手动单播发送 REQUEST 消息，可刷新租约。

DHCP报文交互一览：
在这里插入图片描述和
在这里插入图片描述从图中可以看出DHCP的基本交互使用广播消息传递，但有时也会使用单播消息传递。
当DISCOVER的BOOTP Flag的B-bit未置位，Server应当以单播方式进行回应 OFFER 消息。

3.4.DHCP的二层Snooping

DHCP Snooping是一种DHCP安全特性，主要在二层使用。
交换机通过截获Client和Relay之间的DHCP报文并进行分析处理，可以过滤不信任的DHCP报文并建立和维护一个DHCP-Snooping绑定表(untrust)。

在这里插入图片描述//开启DHCP Snooping功能。除全局外，也需要在相应的vlan下开启。
在这里插入图片描述//查看DHCP Snooping的相关信息。

相关概念及原理：
Trust端口：只允许该端口接收来自DHCP Server的消息。通过将端口设置为Trust端口，用于阻止私接路由器。
unTrust端口：拒绝接收来自DHCP Server的消息。

在这里插入图片描述//将端口设置为trust端口。默认端口为untrust。

DHCP-Snooping绑定表：交换机通过识别 unTrust 端口接收到的 REQUEST 报文来建立绑定表。绑定表包括MAC地址、IP地址、租约时间、VLAN ID和接口信息等。
并且绑定表又可分为动态生成和静态生成。

Option82：RFC3406-DHCP Relay Agent Information Option中定义了Option82=Relay Agent Information用于Server根据配置策略信息针对Client做出响应。

交换机将所有来自Client的DHCP报文插入Option82=Relay Agent Information。其中可以携带Agent Circuit ID Sub-option（code=1），Agent Remote ID Sub-option（code=2），RADIUS Attributes Sub-option（code=7）和Authentication Suboption（code=8）等多种用于识别特定终端的特定参数。

例如Agent Circuit ID Sub-option携带了端口/槽位ID，vlan ID等

交换机接收来自Server的DHCP报文也将Option82=Relay Agent Information，但将其转发给Client时将剥离该Option。

在这里插入图片描述//dhcp option82基于端口和vlan配置使能相应功能。
自动换行
在这里插入图片描述//可以看到此处包含了端口号等信息。
自动换行
在这里插入图片描述//dhcp snooping check dhcp-giaddr enable命令用来检测DHCP报文中 GIADDR字段=Relay agent IP address 是否非零的功能。
从Option82描述上看，应当属于Relay的一种策略。因此有时Server接收配置了Option82的报文后，如果检查 GIADDR 字段为0后会将其丢弃。HW默认不检查，Cisco需要关闭。

DHCP的防饿死：大量伪造 DHCP 请求报文耗尽Server地址池。
在这里插入图片描述//配置接口允许学习的DHCP Snooping绑定表项的最大个数。

在这里插入图片描述//配置接口收到DHCP报文的Chaddr地址，也即Client Hardware Address，与数据帧的SMAC地址是否一致。DHCP Server通常不关心二层帧的MAC地址，开启此功能可以防止伪造发送 DHCP 请求报文。
同时，也可配合端口的MAC地址绑定一同使用。

更新

点击此处回到目录

# 网络 # 面试 # 运维 # 网络协议
Logo
2048 AI社区

有“AI”的1024 = 2048，欢迎大家加入2048 AI社区

更多推荐

cover

别再瞎找了！AI论文软件 千笔·专业学术智能体 VS 云笔AI，继续教育写作首选！

avatar 2048 AI社区
cover

【ComfyUI】解决 ModuleNotFoundError: No module named ‘inference_core_nodes‘ 问题

avatar 2048 AI社区
cover

拖延症福音 10个AI论文写作软件测评：自考毕业论文+开题报告必备工具推荐

avatar 2048 AI社区