注:本文为 “DHCP 协议 | DHCP 字段含义”相关文章合辑。
第二篇图缺失受限于原文图异常。
DHCP 协议详解
zdzeng 于 2019-03-09 21:48:07 发布
什么是 DHCP
DHCP(Dynamic Host Configuration Protocol,动态主机配置协议),前身是 BOOTP 协议,是一个局域网的网络协议,使用 UDP 协议工作,统一使用两个 IANA 分配的端口:67(服务器端),68(客户端)。
DHCP 通常被用于局域网环境,主要作用是集中的管理、分配 IP 地址,使 client 动态的获得 IP 地址、Gateway 地址、DNS 服务器地址等信息,并能够提升地址的使用率。简单来说,DHCP 就是一个不需要账号密码登录的、自动给内网机器分配 IP 地址等信息的协议。
DHCP 协议
DHCP 报文种类
DHCP 一共有 8 中报文,各种类型报文的基本功能如下:
| 报文类型 | 说明 |
|---|---|
| Discover(0x01) | DHCP 客户端在请求 IP 地址时并不知道 DHCP 服务器的位置,因此 DHCP 客户端会在本地网络内以广播方式发送 Discover 请求报文,以发现网络中的 DHCP 服务器。所有收到 Discover 报文的 DHCP 服务器都会发送应答报文,DHCP 客户端据此可以知道网络中存在的 DHCP 服务器的位置。 |
| Offer(0x02) | DHCP 服务器收到 Discover 报文后,就会在所配置的地址池中查找一个合适的 IP 地址,加上相应的租约期限和其他配置信息(如网关、DNS 服务器等),构造一个 Offer 报文,发送给 DHCP 客户端,告知用户本服务器可以为其提供 IP 地址。但这个报文只是告诉 DHCP 客户端可以提供 IP 地址,最终还需要客户端通过 ARP 来检测该 IP 地址是否重复。 |
| Request(0x03) | DHCP 客户端可能会收到很多 Offer 请求报文,所以必须在这些应答中选择一个。 通常是选择第一个 Offer 应答报文的服务器作为自己的目标服务器,并向该服务器发送一个广播的 Request 请求报文,通告选择的服务器,希望获得所分配的 IP 地址。 另外,DHCP 客户端在成功获取 IP 地址后,在地址使用租期达到 50% 时,会向 DHCP 服务器发送单播 Request 请求报文请求续延租约。 如果没有收到 ACK 报文,在租期达到 87.5% 时,会再次发送广播的 Request 请求报文以请求续延租约。 |
| ACK(0x05) | DHCP 服务器收到 Request 请求报文后,根据 Request 报文中携带的用户 MAC 来查找有没有相应的租约记录。 如果有则发送 ACK 应答报文,通知用户可以使用分配的 IP 地址。 |
| NAK(0x06) | 如果 DHCP 服务器收到 Request 请求报文后,没有发现有相应的租约记录或者由于某些原因无法正常分配 IP 地址,则向 DHCP 客户端发送 NAK 应答报文,通知用户无法分配合适的 IP 地址。 |
| Release(0x07) | 当 DHCP 客户端不再需要使用分配 IP 地址时(一般出现在客户端关机、下线等状况)就会主动向 DHCP 服务器发送 RELEASE 请求报文,告知服务器用户不再需要分配 IP 地址,请求 DHCP 服务器释放对应的 IP 地址。 |
| Decline(0x04) | DHCP 客户端收到 DHCP 服务器 ACK 应答报文后,通过地址冲突检测发现服务器分配的地址冲突或者由于其他原因导致不能使用,则会向 DHCP 服务器发送 Decline 请求报文,通知服务器所分配的 IP 地址不可用,以期获得新的 IP 地址。 |
| Inform(0x08) | DHCP 客户端如果需要从 DHCP 服务器端获取更为详细的配置信息,则向 DHCP 服务器发送 Inform 请求报文;DHCP 服务器在收到该报文后,将根据租约进行查找到相应的配置信息后,向 DHCP 客户端发送 ACK 应答报文。 目前基本上不用了。 |
DHCP 报文格式

-
op:报文的操作类型。分为请求报文和响应报文。1:请求报文,2:应答报文。即 client 送给 server 的封包,设为 1,反之为 2。
-
请求报文:DHCP Discover、DHCP Request、DHCP Release、DHCP Inform 和 DHCP Decline。
-
应答报文:DHCP Offer、DHCP ACK 和 DHCP NAK。
-
htype:DHCP 客户端的 MAC 地址类型。MAC 地址类型其实是指明网络类型。htype 值为 1 时表示为最常见的以太网 MAC 地址类型。
-
hlen:DHCP 客户端的 MAC 地址长度。以太网 MAC 地址长度为 6 个字节,即以太网时 hlen 值为 6。
-
hops:DHCP 报文经过的 DHCP 中继的数目,默认为 0。DHCP 请求报文每经过一个 DHCP 中继,该字段就会增加 1。没有经过 DHCP 中继时值为 0。(若数据包需经过 router 传送,每站加 1,若在同一网内,为 0。)
-
xid:客户端通过 DHCP Discover 报文发起一次 IP 地址请求时选择的随机数,相当于请求标识。用来标识一次 IP 地址请求过程。在一次请求中所有报文的 Xid 都是一样的。
-
secs:DHCP 客户端从获取到 IP 地址或者续约过程开始到现在所消耗的时间,以秒为单位。在没有获得 IP 地址前该字段始终为 0。(DHCP 客户端开始 DHCP 请求后所经过的时间。目前尚未使用,固定为 0。)
-
flags:标志位,只使用第 0 比特位,是广播应答标识位,用来标识 DHCP 服务器应答报文是采用单播还是广播发送,0 表示采用单播发送方式,1 表示采用广播发送方式。其余位尚未使用。(即从 0-15bits,最左 1bit 为 1 时表示 server 将以广播方式传送封包给 client。)
-
注意:在客户端正式分配了 IP 地址之前的第一次 IP 地址请求过程中,所有 DHCP 报文都是以广播方式发送的,包括客户端发送的 DHCP Discover 和 DHCP Request 报文,以及 DHCP 服务器发送的 DHCP Offer、DHCP ACK 和 DHCP NAK 报文。当然,如果是由 DHCP 中继器转的报文,则都是以单播方式发送的。另外,IP 地址续约、IP 地址释放的相关报文都是采用单播方式进行发送的。
-
ciaddr:DHCP 客户端的 IP 地址。仅在 DHCP 服务器发送的 ACK 报文中显示,因为在得到 DHCP 服务器确认前,DHCP 客户端是还没有分配到 IP 地址的。在其他报文中均显示,只有客户端是 Bound、Renew、Rebinding 状态,并且能响应 ARP 请求时,才能被填充。
-
yiaddr:DHCP 服务器分配给客户端的 IP 地址。仅在 DHCP 服务器发送的 Offer 和 ACK 报文中显示,其他报文中显示为 0。
-
siaddr:下一个为 DHCP 客户端分配 IP 地址等信息的 DHCP 服务器 IP 地址。仅在 DHCP Offer、DHCP ACK 报文中显示,其他报文中显示为 0。(用于 bootstrap 过程中的 IP 地址)
-
一般来说是服务器的 ip 地址。但是注意!根据 openwrt 源码给出的注释,当报文的源地址、siaddr、option>server_id 字段不一致(有经过跨子网转发)时,通常认为 option>srever_id 字段为真正的服务器 ip,siaddr 有可能是多次路由跳转中的某一个路由的 ip
-
giaddr:DHCP 客户端发出请求报文后经过的第一个 DHCP 中继的 IP 地址。如果没有经过 DHCP 中继,则显示为 0。(转发代理(网关)IP 地址)
-
chaddr:DHCP 客户端的 MAC 地址。在每个报文中都会显示对应 DHCP 客户端的 MAC 地址。
-
sname:为 DHCP 客户端分配 IP 地址的 DHCP 服务器名称(DNS 域名格式)。在 Offer 和 ACK 报文中显示发送报文的 DHCP 服务器名称,其他报文显示为 0。
-
file:DHCP 服务器为 DHCP 客户端指定的启动配置文件名称及路径信息。仅在 DHCP Offer 报文中显示,其他报文中显示为空。
-
options:可选项字段,长度可变,格式为 “代码 + 长度 + 数据”。
| 代码 | 长度(字节) | 说明 |
|---|---|---|
| 1 | 4 | 子网掩码 |
| 3 | 长度可变,必须是 4 字节的倍数 | 默认网关(可以是一个路由器 IP 地址列表) |
| 6 | 长度可变,必须是 4 字节的倍数 | DNS 服务器(可以是一个 DNS 服务器 IP 地址列表) |
| 15 | 长度可变 | 域名称(主 DNS 服务器名称) |
| 42 | 长度可变,必须是 4 字节的倍数 | NTP 服务器(可以是一个 NTP 服务器 IP 地址列表) |
| 44 | 长度可变,必须是 4 字节的倍数 | WINS 服务器(可以是一个 WINS 服务器 IP 地址列表) |
| 51 | 4 | 有效租约期(以秒为单位) |
| 53 | 1 | 报文类型(1 ~ 8)分别表示:Discover,Offer,Request,Decline,ACK,NAK,Release,Inform |
| 58 | 4 | 续约时间 |
| 60 | 长度可变 | Authentication for DHCP Message,用来完成基于标准 DHCP 协议,以在客户端输入用户名和密码的方式进行地址鉴权主要用在按用户认证收费场合,与之对应的是 pppoe 认证计费 |
| 255 | 0 | 标记 options 结束 |
DHCP 工作流程
IP 地址分配方式
DHCP SERVER 负责接收客户端的 DHCP 请求,集中管理所有客户机的 IP 地址设定资料,并负责处理客户端的 DHCP 请求,相比于 BOOTP,DHCP 通过 “租约” 来实现动态分配 IP 的功能,实现 IP 的时分复用,从而解决 IP 资源短缺的问题。
其地址分配方式有如下三种
-
人工配置:由管理员对每台具体的计算机指定一个地址
-
自动配置:服务器为第一次连接网络的计算机分配一个永久地址,DHCP 客户端第一次成功地从 DHCP 服务器端分配到一个 IP 地址之后,就永远使用这个地址
-
动态配置:在一定的期限内将地址租给计算机,客户端第一次从 DHCP 服务器分配到 IP 地址后,并非永久地使用该地址,每次使用完后,DHCP 客户端就得释放这个 IP 地址,并且租期结束后客户必须续租或者停用该地址,而对于路由器,经常使用的地址分配方式是动态配置。
租约表
-
静态租约表:对应一个静态租约存储文件,server 运行时从文件中读取静态租约表。
-
动态租约表:对应一个周期存储文件,server 周期性将租约表存进该文件,在程序开始时将会读取上次存放的租约表。(租约表记录了当前所有分配的租约,包括静态链接的)。
-
DHCP 服务器是一直处在被动接受请求的状态,当有客户端请求时,服务器会读取获得客户端当前所在的状态以及客户端的信息,并在静态租约表和动态租约表中进行检索找到相应的表项,再根据客户端的状态执行不同的回复。
-
当收到客户端的首次请求时,DHCP 服务器先查找静态租约表;若存在请求的表项,返回这个客户的静态 IP 地址;否则,从 IP 地址池中选择可用的 IP 分配给客户,并添加信息到动态数据库中。此外,服务器将会周期性的刷新租约表写入文件存档,在这个过程中会顺便对动态租约表进行租期检查。
工作流程
客户端登陆网络:

-
客户机初始化 & 寻找 DHCP 服务器(DHCP Discover):DHCP 客户端启动时,计算机发现本机上没有任何 IP 地址设定,将以广播方式通过 UDP 67 端口发送DHCP Discover发现信息来寻找 DHCP 服务器,因为客户机还不知道自己属于哪一个网络,所以封包的源地址为 0.0.0.0 目的地址为 255.255.255.255,向网络发送特定的广播信息。网络上每一台安装了 TCP/IP 协议的主机都会接收这个广播信息,但只有 DHCP 服务器才会做出响应。
-
DHCP discover的等待时间预设为 1 秒,也就是当客户机将第一个 DHCP discover 封包送出去之后,在 1 秒之内没有得到回应的话,就会进行第二次 DHCP discover 广播。若一直没有得到回应,客户机会将这一广播包重新发送四次(以 2,4,8,16 秒为间隔,加上 1-1000 毫秒之间随机长度的时间)。如果都没有得到 DHCP Server 的回应,客户机会从 169.254.0.0/16 这个自动保留的私有 IP 地址中选用一个 IP 地址。并且每隔 5 分钟重新广播一次,如果收到某个服务器的响应,则继续 IP 租用过程。

-
分配 IP 地址 & 提供 IP 地址租用(DHCP Offer):DHCP 服务器收到客户端发出的DHCP discover广播后,通过解析报文,查询 dhcpd.conf 配置文件。它会从那些还没有租出去的地址中,选择最前面的空置 IP,连同其它 TCP/IP 设定,通过 UDP 68 端口响应给客户端一个DHCP offer数据包(包中包含 IP 地址、子网掩码、地址租期等信息)。告诉 DHCP 客户端,该 DHCP 服务器拥有资源,可以提供 DHCP 服务。
-
此时还是使用广播进行通讯,源 IP 地址为 DHCP 服务器的 IP 地址,目标地址为 255.255.255.255。同时,DHCP 服务器为此客户端保留它提供的 IP 地址,从而不会为其他 DHCP 客户分配此 IP 地址。
-
由于客户端在开始的时候还没有 IP 地址,所以在其DHCP discover封包内会带有其MAC 地址信息,并且有一个XID 编号来辨别该封包,DHCP 服务器响应的DHCP offer封包则会根据这些资料传递给要求租约的客户。

-
接受 IP 地址 & 接受 IP 租约(DHCP Request):DHCP 客户端接受到 DHCP offer 提供信息之后,如果客户机收到网络上多台 DHCP 服务器的响应,一般是最先到达的那个,然后以广播的方式回答一个DHCP request数据包(包中包含客户端的 MAC 地址、接受的租约中的 IP 地址、提供此租约的 DHCP 服务器地址等)。告诉所有 DHCP 服务器它将接受哪一台服务器提供的 IP 地址,所有其他的 DHCP 服务器撤销它们的提供以便将 IP 地址提供给下一次 IP 租用请求。
-
此时,由于还没有得到 DHCP 服务器的最后确认,客户端仍然使用 0.0.0.0 为源 IP 地址,255.255.255.255 为目标地址进行广播。
-
事实上,并不是所有 DHCP 客户端都会无条件接受 DHCP 服务器的 offer,特别是如果这些主机上安装有其它 TCP/IP 相关的客户机软件。客户端也可以用DHCP request向服务器提出 DHCP 选择,这些选择会以不同的号码填写在 DHCP Option Field 里面。客户机可以保留自己的一些 TCP/IP 设定。

-
IP 地址分配确认 & 租约确认(DHCP Ack):当 DHCP 服务器接收到客户机的DHCP request之后,会广播返回给客户机一个DHCP ack消息包,表明已经接受客户机的选择,告诉 DHCP 客户端可以使用它提供的 IP 地址。并将这一 IP 地址的合法租用以及其他的配置信息都放入该广播包发给客户机。
-
客户端在接收到DHCP ack广播后,会向网络发送三个针对此 IP 地址的ARP 解析请求以执行冲突检测,查询网络上有没有其它机器使用该 IP 地址;如果发现该 IP 地址已经被使用,客户机会发出一个DHCP decline数据包给 DHCP 服务器,拒绝此 IP 地址租约,并重新发送DHCP discover信息。此时,在 DHCP 服务器管理控制台中,会显示此 IP 地址为 BAD_ADDRESS。
-
如果网络上没有其它主机使用此 IP 地址,则客户机的 TCP/IP 使用租约中提供的 IP 地址完成初始化,从而可以和其他网络中的主机进行通讯。

客户端重新登录:
- 重新登录:以后 DHCP 客户端每次重新登录网络时,就不需要再发送DHCP discover发现信息了,而是直接发送包含前一次所分配的 IP 地址的DHCP request请求信息。当 DHCP 服务器收到这一信息后,它会尝试让 DHCP 客户机继续使用原来的 IP 地址,并回答一个DHCP ack确认信息。如果此 IP 地址已无法再分配给原来的 DHCP 客户端使用时,则 DHCP 服务器给 DHCP 客户端回答一个DHCP nack否认信息。当原来的 DHCP 客户机收到此DHCP nack否认信息后,它就必须重新发送DHCP discover发现信息来请求新的 IP 地址。


客户端离线:

-
更新租约:DHCP 服务器向 DHCP 客户机出租的 IP 地址一般都有一个租借期限,期满后 DHCP 服务器便会收回出租的 IP 地址。如果 DHCP 客户机要延长其 IP 租约,则必须更新其 IP 租约。
-
客户端会在租期过去 50% 的时候,直接向为其提供 IP 地址的 DHCP 服务器发送DHCP request消息包。如果客户端接收到该服务器回应的DHCP ack消息包,客户端就根据包中所提供的新的租期以及其它已经更新的 TCP/IP 参数,更新自己的配置,IP 租用更新完成。如果没有收到该服务器的回复,则客户端继续使用现有的 IP 地址,因为当前租期还有 50%。
-
如果在租期过去 50% 的时候没有更新,则客户端将在租期过去 87.5% 的时候再次向为其提供 IP 地址的 DHCP 联系。如果还不成功,到租约的 100% 时候,客户端必须放弃这个 IP 地址,重新申请。如果此时无 DHCP 可用,客户端会使用 169.254.0.0/16 中随机的一个地址,并且每隔 5 分钟再进行尝试。
服务器处理流程
DHCP OFFER
-
静态租用:首先匹配 MAC 地址,看是否能在静态租约表中找到对应的项,若能找到就把 IP 分配给他。静态表中的 IP 不能被其他客户使用。
-
动态租用:
-
服务器试图分配给客户端上次分配过的 IP,在这之前检查这个 IP 是否正在使用。
-
DHCP discover中含有request ip时,检查该 IP 是否在地址池范围,是否正在使用,是否到期,是否是静态 IP,网络上是否已经存在。
-
DHCP discover不含request ip,从地址池上寻找一个最小的可用 IP 分配。
DHCP ACK
-
根据是否含有 request ip 和 server ip 识别客户端现在 init_reboot,selecting,renewing/rebinding 中的哪个状态,并根据以下规则执行 DHCPACK 回复:
-
若客户端处于 selecting 状态,验证 request ip 和 server ip 是否同服务器中的匹配。
-
若客户端处于 init_reboot 状态,验证 request ip 是否符合租约记录。
-
若客户端处于 renewing/rebinding 状态,验证 client ip 是否符合租约记录。
DHCP NAK
-
请求的 IP 是静态 IP,但是 MAC 地址无法与其对应。
-
上面 DHCPACK 中验证失败。
服务器还可能会收到其他包
-
DHCP DECLINE:服务器会把租约表中相关 client 硬件地址置空,并保存这个地址一段时间。
-
DHCP RELEASE:清空租期回收 IP。
-
DHCP INFORM:回复 DHCPACK,数据包含有关于 server 的信息。
DHCP 报文详解及抓包实例
lanhuazui10 于 2020-04-18 22:58:33 发布
DHCP 协议简介
DHCP,全称是 Dynamic Host Configuration Protocol﹐中文名为动态主机配置协议,它的前身是 BOOTP,它工作在 OSI 的应用层,是一种帮助计算机从指定的 DHCP 服务器获取它们的配置信息的自举协议。
DHCP 使用客户端 / 服务器模式,请求配置信息的计算机叫做 DHCP 客户端,而提供信息的叫做 DHCP 的服务器。DHCP 为客户端分配地址的方法有三种:手工配置、自动配置、动态配置。主机地址动态分配任务由网络主机驱动。当 DHCP 服务器接收到来自网络主机申请地址的信息时,才会向网络主机发送相关的地址配置等信息,以实现网络主机地址信息的动态配置。DHCP 具有以下功能:
1、保证任何 IP 地址在同一时刻只能由一台 DHCP 客户机所使用。
2、DHCP 应当可以给用户分配永久固定的 IP 地址。
3、DHCP 应当可以同用其他方法获得 IP 地址的主机共存(如手工配置 IP 地址的主机)。
4、DHCP 服务器应当向现有的 BOOTP 客户端提供服务。
DHCP 最重要的功能就是动态分配。除了 IP 地址,DHCP 分组还为客户端提供其他的配置信息,比如子网掩码。这使得客户端无需用户动手就能自动配置连接网络。
DHCP(Dynamic Host Configuration Protocol,动态主机配置协议)是一个局域网的网络协议,使用 UDP 协议工作, 主要有两个用途:给内部网络或网络服务供应商自动分配 IP 地址,给用户或者内部网络管理员作为对所有计算机作中央管理的手段。
抓包方法:
在用 Wireshark 过滤显示 DHCP 包,需要输入过滤条件 BOOTP,而不是 DHCP
DHCP 的实现分为 4 步,分别是:
第一步:Client 端在局域网内发起一个 DHCP Discover 包,目的是想发现能够给它提供 IP 的 DHCP Server。
第二步:可用的 DHCP Server 接收到 Discover 包之后,通过发送 DHCP Offer 包给予 Client 端应答,意在告诉 Client 端它可以提供 IP 地址。
第三步:Client 端接收到 Offer 包之后,发送 DHCP Request 包请求分配 IP。
第四步:DHCP Server 发送 ACK 数据包,确认信息。
DHCP 的工作流程

发现阶段,即 DHCP 客户机寻找 DHCP 服务器的阶段。DHCP 客户机以广播方式(因为 DHCP 服务器的 IP 地址对于客户机来说是未知的)发送 DHCP discover 发现信息来寻找 DHCP 服务器,即向地址 255.255.255.255 发送特定的广播信息。网络上每一台安装了 TCP/IP 协议的主机都会接收到这种广播信息,但只有 DHCP 服务器才会做出响应。
提供阶段,即 DHCP 服务器提供 IP 地址的阶段。在网络中接收到 DHCP discover 发现信息的 DHCP 服务器都会做出响应,它从尚未出租的 IP 地址中挑选一个分配给 DHCP 客户机,以广播方式向 DHCP 客户机发送一个包含出租的 IP 地址和其他设置的 DHCP offer 提供信息。
选择阶段,即 DHCP 客户机选择某台 DHCP 服务器提供的 IP 地址的阶段。如果有多台 DHCP 服务器向 DHCP 客户机发来的 DHCP offer 提供信息,则 DHCP 客户机只接受第一个收到的 DHCP offer 提供信息,然后它就以广播方式回答一个 DHCP request 请求信息,该信息中包含向它所选定的 DHCP 服务器请求 IP 地址的内容。之所以要以广播方式回答,是为了通知所有的 DHCP 服务器,他将选择某台 DHCP 服务器所提供的 IP 地址。
确认阶段,即 DHCP 服务器确认所提供的 IP 地址的阶段。当 DHCP 服务器收到 DHCP 客户机回答的 DHCP request 请求信息之后,只有 DHCP 客户端选择的服务器会进行如下操作:如果确认将地址分配给该客户端,则以广播返回 DHCP-ACK 报文;否则广播返回 DHCP-NAK 报文,表明地址不能分配给该客户端。另外,除 DHCP 客户机选中的服务器外,其他的 DHCP 服务器都将收回曾提供的 IP 地址。
客户端收到服务器返回的 DHCP-ACK 确认保温后,会以广播方式发送免费 ARP 报文,探测是否有主机使用服务器分配的 IP 地址,如果在规定时间内没有收到回应,并且客户端上不存在与该地址同网段的其他地址时,客户端才使用此地址。否则,客户端会以单播的方式发送 DHCP –DECLINE 报文给 DHCP 服务器,并重新申请 IP 地址。
重新登录,以后 DHCP 客户机每次重新登录网络时,就不需要再发送 DHCP discover 发现信息了,而是直接发送包含前一次所分配的 IP 地址的 DHCP request 请求信息。当 DHCP 服务器收到这一信息后,它会尝试让 DHCP 客户机继续使用原来的 IP 地址,并回答一个 DHCP ACK 确认信息。如果此 IP 地址已无法再分配给原来的 DHCP 客户机使用时(比如此 IP 地址已分配给其它 DHCP 客户机使用),则 DHCP 服务器给 DHCP 客户机回答一个 DHCP NACK 否认信息。当原来的 DHCP 客户机收到此 DHCP NACK 否认信息后,它就必须重新发送 DHCP discover 发现信息来请求新的 IP 地址。
更新租约,DHCP 服务器向 DHCP 客户机出租的 IP 地址一般都有一个租借期限,期满后 DHCP 服务器便会收回出租的 IP 地址。如果 DHCP 客户机要延长其 IP 租约,则必须更新其 IP 租约。DHCP 客户机启动时和 IP 租约期限过一半时,DHCP 客户机都会自动向 DHCP 服务器发送更新其 IP 租约的信息。
如果网络中存在多个 DHCP 服务器,除 DHCP 客户端选中的服务器外,其他 DHCP 服务器中本次未分配的 IP 地址仍可分配给其他客户端。
IP 地址续约原理:
在 DHCP 客户端的 IP 地址租约期限达到一般左右时间时,DHCP 客户端会向为它分配 IP 地址的 DHCP 服务器发送 DHCP-REQUEST 报文,以进行 IP 租约的更新。如果许可 DHCP 服务器回应 DHCP-ACK 报文,否则回应 SHCP-NAK 报文。
如果在租约的一半时间进行的租约操作失败,DHCP 客户端会在租约期限达到 7/8 时,广播发送 DHCP-REQUEST 报文进行续约。DHCP 服务器的处理方式同上。
DHCP 报文种类
DHCP 一共有 8 种报文,分别为 DHCP Discover、DHCP Offer、DHCP Request、DHCP ACK、DHCP NAK、DHCP Release、DHCP Decline、DHCP Inform。各种类型报文的基本功能如下:
DHCP Discover
DHCP 客户端在请求 IP 地址时并不知道 DHCP 服务器的位置,因此 DHCP 客户端会在本地网络内以广播方式发送 Discover 请求报文,以发现网络中的 DHCP 服务器。所有收到 Discover 报文的 DHCP 服务器都会发送应答报文,DHCP 客户端据此可以知道网络中存在的 DHCP 服务器的位置。
DHCP Offer
DHCP 服务器收到 Discover 报文后,就会在所配置的地址池中查找一个合适的 IP 地址,加上相应的租约期限和其他配置信息(如网关、DNS 服务器等),构造一个 Offer 报文,发送给 DHCP 客户端,告知用户本服务器可以为其提供 IP 地址。但这个报文只是告诉 DHCP 客户端可以提供 IP 地址,最终还需要客户端通过 ARP 来检测该 IP 地址是否重复。
DHCP Request
DHCP 客户端可能会收到很多 Offer 请求报文,所以必须在这些应答中选择一个。通常是选择第一个 Offer 应答报文的服务器作为自己的目标服务器,并向该服务器发送一个广播的 Request 请求报文,通告选择的服务器,希望获得所分配的 IP 地址。另外,DHCP 客户端在成功获取 IP 地址后,在地址使用租期达到 50% 时,会向 DHCP 服务器发送单播 Request 请求报文请求续延租约,如果没有收到 ACK 报文,在租期达到 87.5% 时,会再次发送广播的 Request 请求报文以请求续延租约。
DHCP ACK
DHCP 服务器收到 Request 请求报文后,根据 Request 报文中携带的用户 MAC 来查找有没有相应的租约记录,如果有则发送 ACK 应答报文,通知用户可以使用分配的 IP 地址。
DHCP NAK
如果 DHCP 服务器收到 Request 请求报文后,没有发现有相应的租约记录或者由于某些原因无法正常分配 IP 地址,则向 DHCP 客户端发送 NAK 应答报文,通知用户无法分配合适的 IP 地址。
DHCP Release
当 DHCP 客户端不再需要使用分配 IP 地址时,就会主动向 DHCP 服务器发送 RELEASE 请求报文,告知服务器用户不再需要分配 IP 地址,请求 DHCP 服务器释放对应的 IP 地址。
DHCP Decline
DHCP 客户端收到 DHCP 服务器 ACK 应答报文后,通过地址冲突检测发现服务器分配的地址冲突或者由于其他原因导致不能使用,则会向 DHCP 服务器发送 Decline 请求报文,通知服务器所分配的 IP 地址不可用,以期获得新的 IP 地址。
DHCP Inform
DHCP 客户端如果需要从 DHCP 服务器端获取更为详细的配置信息,则向 DHCP 服务器发送 Inform 请求报文;DHCP 服务器在收到该报文后,将根据租约进行查找到相应的配置信息后,向 DHCP 客户端发送 ACK 应答报文。目前基本上不用了。
1)discovery:第一个报文,client 广播发送 discovery 报文请求 server 端获取地址,此时 client ip:0.0.0.0 (可能存在多个 DHCP Server)
2)offer : 对 dhcpdiscovery 的响应,当 server 收到 client 的 discovery 报文后,会单播发送一个 offer 报文响应。告诉 client ,server 给提供的 ip 地址和其他设置信息。(可能有多个 dhcpserver 发送 offer)
3)request:对 offer 的响应 或者是延续 ip 地址租期时发出的报文。对 server 提供的信息发送 request 请求获取提供的信息(client 接收第一个到达的 offer 并广播 request 告诉其他 server 已经选择好了 dhcp server), 其他人不需要再提供 dhcp 服务了。
4)ack : server 对 client 的 request 报文的确认响应报文,只要收到此报文才算是真正的获取了 ip 地址和相关配置信息。(ACK 中有个 option43 字段,用于填充 ACIP)
5)decline:当客户端发现服务器端分配的 ip 地址无法使用,如 ip 地址冲突,将发出此报文,通知 server 禁止使用此 ip 地址。
6)release :client 主动释放 server 分配给它的 ip 地址的报文,server 收到此报文后,可以回收这个 ip 地址,使其分配给其他 client 使用。(可手动 ipconfig /release 释放,wireshark 抓包可以看到此报文,ipconfig /renew 重新获取,输入后,会重新走 dhcp 获取地址的流程)
7 ) nak : server 对 client 的 request 报文的拒绝响应报文,client 收到此报文后,一般会重新开始新的 dhcp 过程。
8 ) inform : client 已经获取了 ip 地址,发送此报文,只是为了从 server 处获取其他的一些网络配置信息,如 route ip, dns ip 等。

DHCP 的报文格式
DHCP服务的8种报文的格式是相同的,不同类型的报文只是报文中的某些字段取值不同。DHCP报文格式基于BOOTP的报文格式。下面是各字段的说明。
| OP(1) | Htype(1) | Hlen(1) | Hops(1) |
| Transaction ID(4) | |||
| Seconds(2) | Flags(2) | ||
| Ciaddr(4) | |||
| Yiaddr(4) | |||
| Siaddr(4) | |||
| Giaddr(4) | |||
| Chaddr(16) | |||
| Sname(64) | |||
| File(128) | |||
| Options(variable) | |||
(图 1 DHCP 的 报文格式)
报文字段分析:
OP:报文的操作类型。分为请求报文和响应报文。1:请求报文,2:应答报文。即 client 送给 server 的封包,设为 1,反之为 2。
请求报文:DHCP Discover、DHCP Request、DHCP Release、DHCP Inform 和 DHCP Decline。
应答报文:DHCP Offer、DHCP ACK 和 DHCP NAK。
Htype:DHCP 客户端的 MAC 地址类型。MAC 地址类型其实是指明网络类型,Htype 值为 1 时表示为最常见的以太网 MAC 地址类型。
Hlen:DHCP 客户端的 MAC 地址长度。以太网 MAC 地址长度为 6 个字节,即以太网时 Hlen 值为 6。
Hops:DHCP 报文经过的 DHCP 中继的数目,默认为 0。DHCP 请求报文每经过一个 DHCP 中继,该字段就会增加 1。没有经过 DHCP 中继时值为 0。(若数据包需经过 router 传送,每站加 1,若在同一网内,为 0。)
Transaction ID:客户端通过 DHCP Discover 报文发起一次 IP 地址请求时选择的随机数,相当于请求标识。用来标识一次 IP 地址请求过程。在一次请求中所有报文的 Transaction ID 都是一样的。
Seconds:DHCP 客户端从获取到 IP 地址或者续约过程开始到现在所消耗的时间,以秒为单位。在没有获得 IP 地址前该字段始终为 0。(DHCP 客户端开始 DHCP 请求后所经过的时间。目前尚未使用,固定为 0。)
Flags:标志位,只使用第 0 比特位,是广播应答标识位,用来标识 DHCP 服务器应答报文是采用单播还是广播发送,0 表示采用单播发送方式,1 表示采用广播发送方式。其余位尚未使用。(即从 0-15bits,最左 1bit 为 1 时表示 server 将以广播方式传送封包给 client。)
【注意】在客户端正式分配了 IP 地址之前的第一次 IP 地址请求过程中,所有 DHCP 报文都是以广播方式发送的,包括客户端发送的 DHCP Discover 和 DHCP Request 报文,以及 DHCP 服务器发送的 DHCP Offer、DHCP ACK 和 DHCP NAK 报文。当然,如果是由 DHCP 中继器转的报文,则都是以单播方式发送的。另外,IP 地址续约、IP 地址释放的相关报文都是采用单播方式进行发送的。
Ciaddr:DHCP 客户端的 IP 地址。仅在 DHCP 服务器发送的 ACK 报文中显示,在其他报文中均显示 0,因为在得到 DHCP 服务器确认前,DHCP 客户端是还没有分配到 IP 地址的。只有客户端是 Bound、Renew、Rebinding 状态,并且能响应 ARP 请求时,才能被填充。
Yiaddr:DHCP 服务器分配给客户端的 IP 地址。仅在 DHCP 服务器发送的 Offer 和 ACK 报文中显示,其他报文中显示为 0。
Siaddr:下一个为 DHCP 客户端分配 IP 地址等信息的 DHCP 服务器 IP 地址。仅在 DHCP Offer、DHCP ACK 报文中显示,其他报文中显示为 0。(用于 bootstrap 过程中的 IP 地址)
Giaddr:DHCP 客户端发出请求报文后经过的第一个 DHCP 中继的 IP 地址。如果没有经过 DHCP 中继,则显示为 0。(转发代理(网关)IP 地址)
Chaddr:DHCP 客户端的 MAC 地址。在每个报文中都会显示对应 DHCP 客户端的 MAC 地址。
Sname:为 DHCP 客户端分配 IP 地址的 DHCP 服务器名称(DNS 域名格式)。在 Offer 和 ACK 报文中显示发送报文的 DHCP 服务器名称,其他报文显示为 0。
File:DHCP 服务器为 DHCP 客户端指定的启动配置文件名称及路径信息。仅在 DHCP Offer 报文中显示,其他报文中显示为空。
Options:可选项字段,长度可变,格式为 “代码 + 长度 + 数据”。
列出部分可选的选项:


wireshark 解码信息
1. 分析
要想抓取到 DHCP 包,先要保证有可用的 DHCP 服务器,然后将主机 IP 地址获取方式设置为自动获取。如果主机在抓包之前已经联网,需要先断开主机的网络连接,然后再连接网络。在 cmd 下使用命令 ipconfig 来完成网络断开与连接的过程:
(1) ipconfig /release
断开当前的网络连接,主机 IP 变为 0.0.0.0,主机与网络断开,不能访问网络。
(2) ipconfig /renew
更新适配器信息,请求连接网络,这条命令结束之后,主机会获得一个可用的 IP,再次接入网络。
2. 开始抓包
实验环境:Win10,Wireshark1.12.9,有线连接
(1) 在 Wireshark 中点击 start 开始抓包,在过滤栏输入 bootp,使其只显示 DHCP 数据包。
(2) 在 cmd 中输入 ipconfig /release 断开网络连接。

可以看到此时所有的网卡都已经断开。以太网处于断开状态。

Wireshark 中截获到一个 DHCP Release 数据包。
(3) 在 cmd 中输入 ipconfig /renew 请求网络连接。

此时,可以看到在 Wireshark 中新增了 4 个 DHCP 数据包:
数据包 1:DHCP Discover
数据包 2:DHCP Offer
数据包 3:DHCP Request
数据包 4:DHCP ACK

等待这条命令执行完毕之后,在 cmd 中可以看到主机被分配了 IP,主机成功连入网络中。
(4) 为了后续分析使用,我们再执行一次 ipconfig /renew:

可以看到 Wireshark 中新增了 3 个数据包:DHCP ACK;DHCP Request;DHCP ACk。
如果再次使用 ipconfig /renew, 每执行一次会新增 2 个数据包:DHCP Request;DHCP ACk。
3 DHCP 包分析
下面着重来分析当执行,ipconfig /renew 这条命令产生的 4 个 DHCP 数据包,这 4 个数据包代表了客户机和 DHCP 服务器的交互过程,也是 IP 动态分配的过程。

1,DHCP Discover 数据包
(1) Client 端使用 IP 地址 0.0.0.0 发送了一个广播包,可以看到此时的目的 IP 为 255.255.255.255。Client 想通过这个数据包发现可以给它提供服务的 DHCP 服务器。
(2) 从下图可以看出,DHCP 属于应用层协议,它在传输层使用 UDP 协议,目的端口是 67。

2,DHCP Offer 包
当 DHCP 服务器收到一条 DHCP Discover 数据包时,用一个 DHCP Offerr 包给予客户端响应。

(1) DHCP 服务器仍然使用广播地址作为目的地址,因为此时请求分配 IP 的 Client 并没有自己 ip, 而可能有多个 Client 在使用 0.0.0.0 这个 IP 作为源 IP 向 DHCP 服务器发出 IP 分配请求,DHCP 也不能使用 0.0.0.0 这个 IP 作为目的 IP 地址,于是依然采用广播的方式,告诉正在请求的 Client 们,这是一台可以使用的 DHCP 服务器。
(2) DHCP 服务器提供了一个可用的 IP, 在数据包的 Your (client) IP Address 字段可以看到 DHCP 服务器提供的可用 IP。
(3) 除此之外,如图中红色矩形框的内容所示,服务器还发送了子网掩码,路由器,DNS,域名,IP 地址租用期等信息。
3,DHCP Request 包
当 Client 收到了 DHCP Offer 包以后(如果有多个可用的 DHCP 服务器,那么可能会收到多个 DHCP Offer 包),确认有可以和它交互的 DHCP 服务器存在,于是 Client 发送 Request 数据包,请求分配 IP。
此时的源 IP 和目的 IP 依然是 0.0.0.0 和 255.255.255.255。
4,DHCP ACK 包
服务器用 DHCP ACK 包对 DHCP 请求进行响应。

在数据包中包含以下信息,表示将这些资源信息分配给 Client.
Your (client) IP address: 分配给 Client 的可用 IP。
后面有许多项 option 信息,前两项是 DHCP 服务器发送的消息类型(ACK) 和服务器的身份标识,后面几项是:
Subnet Mask:Client 端分配到的 IP 的子网掩码;
Router: 路由器
Domain Name Server:DNS, 域名服务器
Domain Name: 域名
IP Address Lease Time:IP 租用期。
DHCP 字段含义:DHCP OPTION 82 、OPTION 60 、OPTION 43
原创 Mark_L_Zhang2013-03-18 15:01:58
dhcp 报文中的一个选项,该选项在 dhcp 报文中为可变长的字段,option 选项中包含了部分租约信息、报文类型等。option 选项中最多可以包括 255 个 option,最少为 1 个 option。
一、option 82
1、说明
option 82 又称为中继代理信息选项(relay agent information option),是 dhcp 报文中 option 内容的一部分。rfc3046 中定义了 option 82,其位置在 option 255 之前而在其他 option 之后。option 82 中可以包含最多 255 个 sub-option,若定义了 option 82,至少要定义一个 sub-option。当 dhcp client 发送请求报文到 dhcp server 时,若需要经过 dhcp 中继,则由 dhcp 中继将 option 82 添加到请求报文中。option 82 包含很多 sub-option,目前 option 82 中常用的 sub-option 1、sub-option 2 和 sub-option 5。
sub-option 1
sub-option 1 是 option 82 的一个子选项,为代理电路 id(即 circuit id)子项。子选项通常在 dhcp 中继设备上配置,定义了在传输报文的时候要携带 dhcp 客户端所连接交换机端口的 vlan-id 及二层端口号。通常 sub-option 1 与 sub-option 2 子选项要共同使用来标识 dhcp 源端的信息。
sub-option 2
sub-option 2 也是 option 82 的一个子选项,为代理远程 id(即 remote id)子项。该子选项也通常在 dhcp 中继设备上配置,定义了在传输报文的时候要携带中继设备的 mac 地址信息。通常与 sub-option 1 子选项要共同使用来标识 dhcp 源端的信息。
sub-option 5
sub-option 5 也是 option 82 的一个子选项。为链路选择(link selection)子项,该选项中包含了 dhcp 中继添加的 ip 地址。这样 dhcp server 在分配 ip 地址给 dhcp 客户端的时候就可以分配与该地址同网段的 ip 地址。
2、 option 82 报文组成
option 82 报文结构如图 1-5。
在 dhcp 报文中有一个 options 字段,该字段可以为空,也可以为某一个特性的 option,option 82 就是其中的一种 option,可以有多个 sub-option 组成。组成如下:
code:标识了中继代理信息选项的序号。本报文中序号为 82,即 option 82。option 82 在其他 option 之后,在 option 255 之前。
len:为代理信息域(agent information field)的长度。
agent information field:代理信息域。在该字段中指定了使用的 sub-option。
sub-option 报文结构
sub-option 报文的组成如下:
subopt:子选项序号,本报文中为 sub-option 1、sub-option 2 和 sub-option 5。各子选项含义如下:
-
1 表示代理电路 id(circuit id)子项
-
2 表示代理远程 id(remote id)子项
-
5 表示链路选择(link selection)子项
len:标识 sub-option value 域的长度。
sub-option value:sub-option 的值。例如 sub-option 1 对应的值为 circuit id。
3、标准模式与华为固网模式
dhcp relay 支持 option 82,在收到从 client 到 server 的请求报文中添加 option 82,以标识用户的位置信息。现在只添加 sub-option 1 和 sub-option 2,不添加 sub-option5。在标准模式,sub-option 1 是接收报文的二层端口号和 vlan 号,sub-option 2 是接收报文设备的 mac 地址。
为了更加精确地定位用户位置信息,我司针对 dslam 应用提出 ip dslam 用户物理位置定位解决方案,定义了 dhcp option 82 的华为固网模式,其中 option 82 的 sub-option1 表示 “节点标识+框号 / 槽号 / 子槽 / 端口号+vlan”;sub-option2 没有改变,表示的是的 relay 系统 mac 地址;sub-option5 relay 不添加。
option 82 的 sub-option1 中的节点标识为字符串,缺省可以采用设备的管理接口 mac 地址,形如:00-e0-fc-0d-dc-ec。为了提高维护的方便性,也允许网络管理者通过配置修改用户节点标识,可以选择是用 relay 的桥 mac 或设备名(通过 sysname 配置的),也可以由用户自行输入字符串。
华为固网模式 option 82 中 sub-option 1 的标识格式:
accessnodeidentifier eth frame/slot/subslot/port:vlan
对各段的解释如下:
accessnodeidentifier:接入节点标识,长度不超过 50 个字符的字符串,缺省为桥 mac
frame:框号,不支持的为 0
eth:以太端口类型
slot:槽号
subslot: 子槽号
port:端口号
vlan:vlan 标识
4、 相关规范
与 dhcp 中继支持 option 82 相关的协议规范有:
-
rfc2131 dynamic host configuration protocol
-
rfc3046 dhcp relay agent information option
5、 dhcp 中继支持 option 82 工作机制
dhcp 客户端通过 dhcp 中继从 dhcp 服务器获取 ip 地址的过程与同网段的 dhcp 获取过程完全相同,都要经历发现、提供、选择和确认四个阶段,详细的过程请参考本手册 “网络层协议” 的 dhcp 部分。这里将只介绍 dhcp 中继支持 option 82 时的工作机制,具体如下:
dhcp 客户端在初始化时以广播的形式发送请求报文;
若本地网络存在 dhcp 服务器,则客户端可以直接从该服务器获取 ip 地址。
若本地网络没有 dhcp 服务器,则与本网络相连的 dhcp 中继设备对该广播报文进行相应的处理。dhcp 中继设备将检查报文中是否已有 option 82 选项,进行相应的处理。
如果报文中已有 option 82,设备按照配置的策略对该报文进行处理(丢弃、用中继设备本身的 option 82 项替代报文中原有的 option 82 项或保持报文原有的 option 82 项),然后将请求报文转发给 dhcp 服务器。
若请求报文中没有 option 82 选项,则 dhcp 中继设备将 option 82 选项添加到报文中后转发给 dhcp 服务器。此时,请求报文中将包含了 dhcp 客户端所连接的交换机端口的 mac 地址、所属的 vlan 以及 dhcp 中继设备本身的 mac 地址。
dhcp 服务器收到 dhcp 中继设备转发的 dhcp 请求报文后,将记录报文中 option 选项所携带的信息,然后将带着 dhcp 配置信息以及 option 82 信息的报文发给 dhcp 中继。
dhcp 中继收到 dhcp 服务器的返回报文后将剥离报文中的 option 82 信息,然后将带有 dhcp 配置信息的报文转发给 dhcp 客户端。
dhcp 客户端发送的请求报文有四种,分别为 dhcp_discover 报文、dhcp_request 报文、dhcp_release 报文和 dhcp_inform 报文,dhcp 中继设备将在四种报文中都添加 option 82 选项,因为不同厂商生产的 dhcp 服务器设备对请求报文的处理机制不同,有些设备处理 dhcp_discover 报文中的 option 82 信息,而有些处理 dhcp_request 报文中的 option 82 信息。
二、option 60
首先还是看看 RFC 咋说的吧。DHCP 是 RFC2131 定义,DHCP 2132 定义了 dhcp option。
9.13. Vendor class identifier
This option is used by DHCP clients to optionally identify the vendor type and configuration of a DHCP client. The information is a string of n octets, interpreted by servers. Vendors may choose to define specific vendor class identifiers to convey particular configuration or other identification information about a client. For example, the identifier may encode the client’s hardware configuration. Servers not equipped to interpret the class-specific information sent by a client MUST ignore it (although it may be reported). Servers that respond SHOULD only use option 43 to return the vendor-specific information to the client.
(这个选项作用于客户端可选地识别客户端厂商类型和配置,这个信息是 n 个 8 位编码,由 dhcp 服务端解析,厂商可能会为客户端选择定义特殊的厂商类标识符信息,以便表达特殊的配置或者其他关于客户端的信息。比如:这个标识符可能编码了客户端的硬件配置。客户端发送过来的服务器不能解析的类规范信息必须被忽略(尽管可能会有报告),服务器响应厂商规范信息到客户端应该仅仅通过 Option 43 来完成。
The code for this option is 60, and its minimum length is 1.
Code Len Vendor class Identifier
+—–+—–+—–+—–+—
| 60 | n | i1 | i2 | …
+—–+—–+—–+—–+—
从 rfc 中可以看出,dhcp 60 选项主要是用于客户端报告自身厂商以及配置信息的,服务器不能解析的 类标识符的应该被忽略,这个选项只是客户端发包报告自己的信息,客户端和服务器端交换厂商信息的应该是由 option 43 来完成。
未完,待续…(抓包观察下 pxe 客户端的信息,这 TM 做 PXE 的启动很久了,一直纠结这个 60 是干嘛的,而且 windowsDHCP 服务器我没加 60 也没见怎么着)
接着来吧,看看实际的包是啥样 ,测试环境为将笔记本和 DHCP 服务器用一根网线直连。
首先重启笔记本,然后启动的时候按 F12 让机器从网络启动,服务端进行抓包,查看收到的来自于笔记本的 DHCP 请求的包,如下图
可以清楚的看到,wireshark 抓到的来自于笔记本的网卡启动的 DHCP 请求包含 option 60 选项,wireshark 定义的 option 60 为 厂商类标识符,值为”PXEClient:Arch:00000:UNDI:002001”
然后启动系统,查看笔记本操作系统发出的 DHCP 请求包内容,如下图
从图中可以看到操作系统发出的 DHCP 请求也包含 option 60 选项,值为 “MSFT 5.0”
在 internet 上看到的一段文字:
1、支持 OPTION60(Authentication for DHCP Messages)
功能描述:
OPTION 60 功能用来完成基于标准 DHCP 协议,以在客户端输入用户名和密码的方式进行的地址鉴权。在机顶盒中只保留应用层帐号和密码,应用层帐号为 8 位数字,在 OPTION60 使用接入层帐号,帐号为 “ad”+ 应用层帐号 +“@iptv”,密码和应用层密码一致,目前密码暂定为固定值 123465。 应用层用户名和密码一旦输入之后,应储存在硬件之中。当 PPPOE 与 DHCP 接入模式相切换时如果之前已经输入过应用层用户名与密码,则要求无需再次输入,直接过渡至新的接入方式。
2、支持 OPTION 125(Vendor-ldentifying Vendor Options)
功能描述:
OPTION 125 功能是对标准 DHCP 协议一个补充标准,该功能的标准定义在 RFC 3925 中。DHCP 服务器在完成验证将客户端的 IP 地址等信息封装成 DHCP OFFER 包的时候,将 OPTION 125 信息封装 DHCP OFFER 包中再发送给客户端。 客户端收到 OFFER 包以后,首先查看该 OFFER 包所带的 OPTION 125 的 “Option-data 1” 字段中所填写的特征值,并与预先存储的信息进行比对。比对结果为相同则使用此 OFFER,如果比对结果不同或 OFFER 包中不带 OPTION 125, 则将此 OFFER 丢弃。
三、option 43
option43 属性主要应用在 WLAN 中 AP 设备从 dhcp 服务器获取地址后,通过 dhcp 服务器下发的 option43 属性去找 AC 注册,一般 option43 属性内容由 AC 侧工程师提供。
S8500 在 1278P08 版本配置 dhcp 的 option43 属性需要注意:
例如下列 vlan5 是设备配置完显示的数据。
interface Vlan-interface5
description To Wlan-TEST
ip binding vpn-instance Wlan-NM
ip address 10.16.100.1 255.255.255.0
dhcp select interface
dhcp server option 43 hex 80 0B 00 00 02 0A 10 04 0A 0A 10 04 0B
其中 option43 内容配置时直接输入 “ dhcp server option 43 hex 80 0B 00 00 02 0A 10 04 0A 0A 10 04 0B” 不能配置成功,在配置时只能输入 “ dhcp server option 43 hex 800B 0000 020A 1004 0A0A 1004 0B” 才能输入成功。
由于配置命令与设备显示命令行不一致,所以在重启 S8500 时一定要注意 option43 属性。重启 S8500 时是在 flash 中 vrpcfg.cfg 文件读取命令,所以重启后必须重新添加 option43 属性 “ dhcp server option 43 hex 800B 0000 020A 1004 0A0A 1004 0B”,否则重启后设备会丢失 option43 属性配置影响 WLAN 业务。
via:
-
DHCP 协议详解_那个字段包含 dhcp 服务器 - 优快云 博客 zdzeng 于 2019-03-09 21:48:07 发布
https://blog.youkuaiyun.com/zzd_zzd/article/details/88372014 -
DHCP OPTION 82 、OPTION 60 、OPTION 43_51CTO博客_原创 Mark_L_Zhang 2013-03-18 15:01:58
https://blog.51cto.com/ciscoexpert/1714127
6749

被折叠的 条评论
为什么被折叠?



