终端插上网线右下角转圈最后蹦出个 169.254 开头的地址——这个场景我一年能碰上十几次。多数人的第一反应是去翻 DHCP 服务器的日志但实际排查下来问题往往卡在中间那台交换机上。DHCP 报文分析和交换机配置这两件事单拎出来都是独立的技能点可一旦把它们放在一条链路里看价值就完全不一样了报文是现象层配置是原因层中间那条排查路径才是你真正要掌握的东西。这篇内容我打算从一个网络排障者的视角把 DHCP 四步交互里每个字段的含义、交换机在报文转发路径上可能动的手脚、以及每一类半截交互对应的配置问题按我自己实际踩过的顺序讲一遍。适合正在做企业网运维、接触过 VLAN 和三层交换但 DHCP 排查总觉得没章法的朋友也适合想搞清楚为什么抓包看到了 DISCOVER 却看不到 OFFER这类问题的新手。不堆概念重点讲怎么从一包数据反推到某一行配置。1. DHCP 四步交互在交换机内部到底经过了什么1.1 从 DISCOVER 到 ACK哪些字段会被中间设备改写先把这个报文本身拆开。DHCP 报文本质上是 BOOTP 的扩展固定头 236 字节后面跟一个 4 字节的 magic cookie0x63825363再往后就是变长的 options 字段。固定头里有几个字段是排查时的关键抓手我在抓包时基本会第一时间把它们拉出来看字段长度排查时的作用op1 字节1 是客户端请求2 是服务器应答方向一眼可辨xid4 字节事务 ID客户端随机生成用来把一次四步交互串起来flags2 字节最高位是广播标志置 1 表示要求服务器用广播回复这个位是个大坑ciaddr4 字节客户端已有地址时填续租和 INIT-REBOOT 场景才有值yiaddr4 字节服务器准备分配给客户端的地址giaddr4 字节中继代理地址直接决定服务器从哪个地址池取地址chaddr16 字节客户端硬件地址前 6 字节就是 MACoption 53变长报文类型1 DISCOVER、2 OFFER、3 REQUEST、5 ACK、6 NAK除了这些option 55参数请求列表能看出客户端想要哪些参数option 60厂商类别标识能区分这是普通 PC、IP 话机还是 PXE 引导的机器option 61客户端标识有时候不是 MAC 而是MAC主机名的组合遇到按 option 61 做绑定策略的环境这个字段不看会绕大弯。option 82 是后加的中继代理信息里面又分 circuit-id通常是 VLAN 号加端口号和 remote-id通常是设备标识这一项是整个 DHCP 策略化分配的核心后面单独开一节讲。在交换机的转发路径上真正会被改写的字段其实不多但每改一个都可能引发连锁反应。giaddr 会被中继设备填充hops 每过一次中继加一option 82 会被接入设备插入源目 IP 和 MAC 会随广播转单播而变化。搞清楚了谁改了谁抓包时看到异常值就不会慌。1.2 交换机上三个会动手的功能位置一台普通二层接入交换机默认情况下对 DHCP 报文是纯透传的广播进来广播出去什么都不做。但只要开了下面三个功能中的任意一个它就从路人变成了参与者第一个是 DHCP Snooping。它的逻辑很朴素只允许从信任端口下来的服务器应答报文OFFER、ACK、NAK通过从非信任端口上来的这类报文一律丢弃。同时它会监听 ACK把MAC-IP-端口-VLAN-租期这五元组建一张绑定表。这张表既是防私接 DHCP 服务器的武器也是后续做 IP-MAC 绑定的数据源。它动手的方式是丢包而且丢得悄无声息这是排查时最容易误判的地方。第二个是 Option 82 插入。开启后接入设备会在客户端上行的 DHCP 报文里塞进 circuit-id 和 remote-id让服务器知道这个请求是从哪个设备的哪个端口上来的。服务器侧可以据此做同端口固定分配按楼层分配不同网段这类策略。它动手的方式是改包改了之后如果服务器不认这个 option可能直接丢弃。第三个是 DHCP 中继。跨网段场景必不可少把客户端的广播转成单播发给指定服务器同时把接收报文的那个三层接口地址填进 giaddr。它动手的方式是改地址giaddr 一填错服务器就会从错误的池子里分配地址客户端拿到一个本网段根本路由不到的 IP表现是拿到地址但上不了网。这三个功能在配置上是独立的但在报文路径上是叠加的。我见过一个环境同时开了 Snooping 和 Option 82上行口忘了配 trusted结果就是客户端 DISCOVER 一路畅通OFFER 全被丢在接入交换机上抓包只能看到一半的交互。1.3 抓包点选在哪里决定了你能不能看到真相这一点必须单独说因为它决定了后面所有分析的有效性。DHCP 是广播交互抓包点的位置不同看到的东西完全不一样。比较靠谱的做法是两端同时抓客户端侧抓一份服务器侧或者中继设备的上行口抓一份。如果只有客户端侧你只能知道我发了没收到如果只有服务器侧你只能知道服务器收到了没回或者根本没收到。两边一对比问题立刻被压缩到中间那一段。交换机上做端口镜像要注意方向。把接入端口作为镜像源、抓包口作为观察口入方向inbound能看到客户端发的 DISCOVER 和 REQUEST出方向outbound能看到服务器回来的 OFFER 和 ACK。很多环境只配了入方向然后困惑于为什么镜像口看不到服务器回应——因为回应是从上行口进来的压根没经过被镜像的那个接入口。# 以某主流厂商CLI为例关键词各厂商略有差异 observe-port 1 interface GigabitEthernet 0/0/20 interface GigabitEthernet 0/0/1 port-mirroring to observe-port 1 inbound port-mirroring to observe-port 1 outbound如果接入交换机是二层设备、没有可用的镜像能力退一步的办法是在上行链路的汇聚设备上做镜像但这时候你看到的是整个 VLAN 的 DHCP 流量需要用抓包过滤条件把它缩到单个 MAC 或者单个 xid 上。过滤表达式我一般这么写bootp eth.addr xx:xx:xx:xx:xx:xxxid 拿到之后再改成bootp.id 0x12345678精确锁定一次交互。提示镜像口带宽要留够接入交换机上做全端口镜像很容易把观察口打满抓包结果出现丢包反而误导判断。只镜像需要排查的那个端口就够。2. 抓包之前先把交换机侧的拦截点摸清楚2.1 Snooping 的信任端口为什么上行口必须 trusted这是我最常遇到的配置缺失没有之一。DHCP Snooping 的设计初衷是防止有人在接入层私接一台设备冒充 DHCP 服务器所以默认逻辑是所有端口都不信任只有我明确指定为信任的端口才放行服务器方向的报文。问题在于很多环境的配置是全局开了 snooping接入端口也配了唯独忘了给上行口加 trusted。这种情况下报文路径是这样的客户端发 DISCOVER从接入口进来方向是客户端到服务器Snooping 不拦正常转发服务器回 OFFER从上行口进来方向和上面相反Snooping 一看这个端口没配 trusted直接丢弃客户端等了几秒没收到重发 DISCOVER循环往复。最终现象就是客户端一直在获取地址抓包只能看到一串重复的 DISCOVER一个 OFFER 都没有。这时候如果去查服务器日志会发现服务器其实正常响应了甚至能看到分配记录——因为服务器确实发出去了只是被中间设备吃掉了。# 全局开启 dhcp snooping enable # 上行口连接 DHCP 服务器或中继设备的方向必须信任 interface GigabitEthernet 0/0/24 dhcp snooping trusted # 接入端口开启并限制单端口可学习的用户数 interface GigabitEthernet 0/0/1 dhcp snooping enable dhcp snooping max-user 4这里有个容易混淆的点dhcp snooping trusted配的端口是连接 DHCP 服务器方向的端口不是连接客户端的端口。有些同学看到接入端口也需要放行 DHCP就给接入口也加了 trusted结果等于把防私接功能废掉了任何一台接在接入口上的私接路由器都能发 OFFER 抢答。还有一个坑是级联场景。接入交换机 A 通过上行口连汇聚交换机 BB 上开启了 Snooping 且信任端口在更上一层。这时候 A 的上行口必须 trustedB 连接 A 的那个端口也必须 trusted信任链要一路打通到服务器方向。少一环OFFER 就断在那儿。2.2 VLAN、端口隔离、STP 这些不报错的拦截者Snooping 至少还留了个没有 OFFER的线索下面这几个干扰项更隐蔽因为它们不影响别的业务只影响 DHCP。VLAN 划分不一致。客户端的 DISCOVER 是广播广播域就是 VLAN。如果接入端口划分的 VLAN 和上行口允许通过的 VLAN 对不上报文从根上就出不去。这种情况通常伴随整个端口所有业务都不通比较容易发现。但也存在VLAN 是对的但上行口的 trunk 允许列表里漏了这个 VLAN的情况端口本身 upVLAN 也配了就是不通。端口隔离。开启端口隔离的接入端口默认是不能和同 VLAN 的其他端口互通的。DHCP 的场景下客户端和服务器不在同一个端口报文必须经过上行口。如果上行口没有被排除在隔离之外或者隔离组的配置把上行口也划进去了广播就被挡在端口内部。这个问题的特征是同 VLAN 内其他端口能通就这个端口不行而且抓包在接入口能看到 DISCOVER在上行口看不到。STP 收敛。端口插上网线之后如果不是边缘端口edge port要经历 listening、learning、forwarding 三个阶段默认时长在几十秒量级。这段时间里端口是隔离的DHCP 广播发不出去。用户感受就是插上网线等半分钟才拿到地址。这个不是故障但经常被当成故障报修。解决办法是在接入端口上配边缘端口同时对边缘端口开 BPDU 保护防止有人把交换机接到接入口上造成环路。interface GigabitEthernet 0/0/1 stp edged-port enable stp bpdu-protectionACL 误伤。有些环境为了限制 DHCP 广播会在上行口写一条 ACL 把 UDP 67/68 给拒了。这种操作我是真的见过而且配置时间久了自己都忘了。排查的时候如果 Snooping、VLAN、STP 都排除了一定要去看接口下的 ACL 和全局的流量策略。2.3 端口安全与 MAC 限制引发的连锁反应端口安全port-security和 DHCP Snooping 的 max-user 限制在功能上是两套东西但结果都是丢包。端口安全的逻辑是限制一个端口下能学习到多少个源 MAC。超了之后默认行为可能是丢弃后续 MAC 的报文也可能是直接 shutdown 端口。如果一台终端换了网卡、或者接了一台小交换机下面挂多台设备很容易触发。dhcp snooping max-user限制的是单端口可建立的 DHCP 绑定表项数量。超过上限后新的 DHCP 请求在交换机层面会被丢弃但已经建立的租约还能继续用。这个设计会导致一个很诡异的现象老终端正常上网新接入的终端怎么都拿不到地址。因为端口满载了。这两种限制的正确姿势是留足余量。办公工位按 1~2 个设备算会议室、打印区可能挂小交换机就要按实际预期放宽或者干脆在这些位置不用端口安全改用 IP-MAC 绑定做管控。我个人倾向于接入端口开 snooping 但 max-user 给到 4~8端口安全只配在确实需要限制的公共区域端口上。还有一个连锁反应容易被忽略开了 Snooping 之后如果客户端发的 DHCP 报文里的源 MAC 和报文里的 chaddr 不一致比如经过某些虚拟化环境或者 MAC 转换设备交换机可能判定为攻击并丢弃。这种情况在虚拟机宿主机、某些 USB 网卡、以及做了 MAC 克隆的设备上偶尔会遇到。拦截点典型现象快速验证方式Snooping 未信任只有 DISCOVER无 OFFER查上行口配置临时改 trusted 测试VLAN 不一致端口所有业务不通查接入端口与上行 trunk 的 VLAN 列表端口隔离单端口异常其他正常查隔离组和上行口是否被排除STP 收敛慢插线后延迟很久才有地址查端口角色和边缘端口配置ACL 误伤特定 VLAN 或时段异常查接口 ACL 和匹配计数max-user 超限老终端正常新终端拿不到查绑定表条目数3. 按报文断点定位四种典型半截交互的排查路径3.1 只有 DISCOVER 没有 OFFER这是最常见的形态判断链路要按抓包位置分情况。客户端侧抓到 DISCOVER交换机上行口没抓到——说明报文在接入交换机内部就没了。优先级排序Snooping 拦截DISCOVER 本身不太会被拦但某些设备会做 DHCP 报文合法性检查、端口隔离、VLAN 不匹配、ACL。先看 VLAN再看隔离最后看 Snooping 和 ACL这个顺序是因为 VLAN 问题最容易确认一条命令的事。上行口抓到 DISCOVER服务器侧没抓到——说明中间还有一跳。跨网段场景下要检查中继配置是否生效dhcp select relay和dhcp relay server-ip是不是配在了正确的三层接口上。有一个细节中继是在接收广播的那个三层接口上配的如果客户端所在的 VLAN 对应的 Vlanif 接口没配中继请求就出不去。另外中继的服务器地址如果写错报文会发到一个没有 DHCP 服务的地址上表现为单向可见。服务器侧抓到 DISCOVER但没回 OFFER——这时候问题在服务器。常见原因是地址池耗尽、地址池网段与 giaddr 不匹配、服务器上配置了针对 option 82 的策略但收到的报文里没有这个 option或者服务器做了 MAC 白名单。地址池耗尽这种情况抓包看不到任何异常只能靠登录服务器查池子使用率。提示判断是不是地址池满了最快的方式是拿一个已知在池子里的地址去 ping 一下如果全是通的基本就是满了。或者临时把租期改短看能不能快速回收一批。3.2 有 OFFER 却没有 REQUEST或者 REQUEST 之后没有 ACK这两种情况经常被混为一谈但原因完全不同。有 OFFER 没有 REQUEST说明客户端收到了服务器的分配提议但选择了不接受。可能的场景客户端在做地址冲突检测发 ARP 探测这个地址有没有人用探测到冲突就发 DECLINE 报文而不是 REQUEST客户端是双网卡环境另一张网卡已经拿到了地址优先级更高客户端操作系统里手动配置了静态地址DHCP 客户端服务处于半启用状态。抓包上区分很简单看有没有 option 53 4 的 DECLINE 报文。有 DECLINE 就是地址冲突要去查这个地址为什么被别人占着大概率是有人手工配了静态 IP 又没做地址保留。有 REQUEST 没有 ACK服务器的选择是拒绝。拒绝会体现在两方面要么服务器直接静默丢弃要么回一个 NAKoption 53 6NAK 里通常带 option 56 写明拒绝原因。NAK 的常见原因包括REQUEST 里 requested IPoption 50和 server identifieroption 54指向的服务器不一致说明有多台服务器在响应客户端请求的地址不在服务器的池子里租约已经过期且服务器不允许续租。这里有一个高频坑网络里存在两台 DHCP 服务器一台是正式服务器一台是某个部门自己搭的测试服务器。客户端广播 REQUEST两台都收到了但 REQUEST 里的 option 54 只指向了其中一台另一台会认为这个客户端选了别人于是释放掉自己刚分配的地址。这种环境下经常出现地址拿到了又没了的循环。3.3 拿到了地址但地址明显不对这类问题的判断标准很清楚客户端拿到的 IP 网段和它所在 VLAN 的网段对不上。最典型的元凶是私接 DHCP 服务器。有人在办公区插了一台家用无线路由器路由器的 LAN 口接了公司网络它的 DHCP 服务默认开启分配 192.168.1.x 之类的地址。客户端广播 DISCOVER公司服务器和这台路由器同时响应谁先到客户端就用谁。抓包特征非常明显两个 OFFER源 IP 不同option 54服务器标识不同分配的 yiaddr 网段也不同。这时候比的就是谁的响应快所以会出现有的人拿到正常地址有的人拿到 192.168.1.x这种随机现象。处理方式分两步先定位通过 OFFER 报文的源 MAC 找到交换机上的对应端口把端口关掉或者做端口隔离再防护在接入层开 Snooping 并把所有接入端口设为非信任从根上杜绝。第二种是中继 giaddr 配错。中继设备把接收报文的接口地址填进 giaddr服务器根据 giaddr 所在的网段选池。如果中继配在了一个错误的 Vlanif 上或者该接口配置了 secondary IP 导致选了另一个池客户端就会拿到跨网段的地址。这种情况在做了地址规划调整之后特别容易发生——VLAN 划过去了中继接口没跟着改。第三种是Option 82 策略误匹配。服务器侧按 circuit-id 做分配策略时如果交换机侧插入的 circuit-id 格式和服务器预期的不一致比如一边是VLAN槽位端口的二进制另一边按字符串解析匹配就会落到默认池上分配出一个不属于该位置的地址。3.4 地址拿到了网关也对就是上不了网这种情况严格来说已经超出 DHCP 的范畴了但排查时经常一起出现因为用户感知都是网络不通。DHCP 层面能确认的是地址、掩码、网关、DNS 四个参数都正确下发了。剩下的问题在转发路径上。我会按这个顺序过一遍客户端 arp -a 看网关的 MAC 学没学到学不到说明二层不通学到了就 ping 网关通不了说明网关侧有问题网关通了 ping 外网地址通不了查路由或者 NAT地址通但域名解析失败查 DNS 下发和服务器可达性。有一个和 DHCP 强相关的细节如果客户端拿到的是 /24 掩码但网关配成了别的网段或者 option 3路由器下发了多个网关地址而客户端只认第一个也会表现为有地址上不了网。抓包时把 ACK 里的 option 3、option 6、option 1 都展开看一眼能省很多时间。4. 中继场景giaddr 和 Option 82 的改写与配置对账4.1 giaddr 决定了服务器从哪个池子里取地址DHCP 服务器自己并不知道客户端在哪个网段它唯一的判断依据就是 giaddr。中继设备收到客户端的广播后把接收该广播的三层接口地址填进 giaddr然后单播转发给服务器服务器拿 giaddr 去匹配自己配置的地址池。这意味着一个很硬的规则giaddr 必须和地址池所在的网段精确匹配。差一个掩码位都可能出问题。比如地址池是 10.1.10.0/24中继接口配的是 10.1.10.1/23那 giaddr 落在 10.1.10.0/23 里服务器如果按 /24 匹配池子可能匹配不上也可能匹配到相邻的 10.1.11.0 池子上去。interface Vlanif 10 ip address 10.1.10.1 255.255.255.0 dhcp select relay dhcp relay server-ip 10.1.100.10 dhcp relay server-ip 10.1.100.11配置多个 server-ip 的时候中继默认是把请求发给所有服务器谁先回用谁这本身也是一种冗余设计。但如果两台服务器配置的地址池不一致就会出现有时候拿到这个网段的地址有时候拿到那个网段的随机现象。做冗余一定要保证两台服务器的池子配置完全同步。还有一个细节中继的源接口。有些设备允许指定中继报文的源地址如果不指定默认用出接口地址。在多出口或者有策略路由的环境里源地址选错会导致回程报文走另一条路径出现服务器收到了请求但应答回不来的单通现象。抓包上看就是服务器侧有 OFFER中继侧没有。hops 字段在中继场景下也值得看一眼。每经过一次中继加一超过阈值一般是 16报文会被丢弃。正常情况下 hops 应该是 0 或 1如果看到 3、4 甚至更高说明网络里存在中继环路——两台设备互相把对方的报文当中继请求转发形成死循环。这种情况通常发生在两台三层设备都配了中继、且互相同步了路由的环境里报文在两台设备之间来回弹。4.2 Option 82 的插入、透传与剥离Option 82 的价值在于让服务器知道这个请求来自哪个物理位置从而做精细化的地址分配。它的工作流程分三段插入发生在离客户端最近的那台开启了该功能的接入设备上。设备把接收报文的端口信息编码成 circuit-id子选项 1把设备自身标识编码成 remote-id子选项 2塞进报文的 option 82 字段。circuit-id 的格式各家实现不同常见的是VLAN ID2 字节 槽位号1 字节 端口号1 字节的四字节二进制也有用字符串格式的。透传发生在中间的二层或三层设备上。中继设备在转发时不修改 option 82 的内容但要保证它不被丢掉。有些设备默认会在转发前剥离 option 82需要显式开启保留。剥离发生在服务器应答返回客户端的最后一段。客户端是不认识 option 82 的标准要求中继设备在把 OFFER/ACK 转发给客户端之前把它剥掉。如果设备没剥某些客户端会直接丢弃这个报文表现为服务器回了但客户端不认。# 接入设备侧开启插入 interface GigabitEthernet 0/0/1 dhcp snooping enable dhcp snooping information enable # 中继设备侧配置保留与剥离策略关键词各厂商不同 interface Vlanif 10 dhcp relay information enable dhcp relay information strategy keep实际踩过的坑里最常见的是服务器侧策略依赖 option 82但接入设备没开插入结果所有请求都落到默认池。第二常见的是开了插入但服务器软件不识别这个 option直接丢弃报文这种情况在换服务器或者升级服务器软件之后经常出现因为不同实现对 option 82 的容错程度差别很大。排查时把抓包里的 option 82 展开对照服务器侧的配置看格式和内容是否匹配是唯一靠谱的办法。4.3 中继和 Snooping 同时开启时的顺序问题这两个功能在报文路径上是有先后顺序的。客户端上行的 DISCOVER 先经过 Snooping 检查因为是客户端方向不拦然后进中继模块中继模块填 giaddr、可能插入 option 82再转发出去。服务器回来的 OFFER 先由中继模块接收并剥掉 option 82然后交给 Snooping 检查这个方向要被拦所以必须从信任端口进来。问题就出在这个顺序上。中继设备收到 OFFER 的那个接口在逻辑上是服务器方向必须配 trusted。但很多人在配中继的时候只关注了dhcp select relay和server-ip忘了 Snooping 还在那儿守着结果 OFFER 被自己的 Snooping 丢了。这种配置在同一个设备上既做中继又做 Snooping 的环境里特别容易出现因为两个功能配在不同菜单下很容易只配一半。我自己的习惯是只要设备上开了 Snooping配完中继之后一定要补一条dhcp snooping trusted到面向服务器的接口上然后抓一次包确认 OFFER 能正常返回。宁可多花五分钟验证也别等到用户报障。5. 从绑定表反推配置Snooping 表的生成、查询与静态绑定5.1 动态绑定表什么时候生成为什么有时候是空的Snooping 的绑定表不是凭空来的它是在监听 DHCP ACK 报文的过程中逐条建立的。也就是说没有完整的四步交互就没有绑定表项。这一点在排查时非常有用。如果你发现某台终端的绑定表项不存在说明它的 DHCP 交互在某一步断掉了这时候抓包就能直接定位断点在哪一步。反过来如果绑定表里有这条记录说明地址分配是成功的问题不在 DHCP 层面。# 查询全部绑定表项 display dhcp snooping user-bind all # 按接口过滤 display dhcp snooping user-bind interface GigabitEthernet 0/0/1正常的表项包含 MAC、IP、租期、VLAN、接口这几项。有几种情况会导致表项看起来不对表项里的 IP 是 0.0.0.0通常出现在客户端发 DECLINE 或者 RELEASE 之后交换机还没来得及清理表项存在但客户端已经下线是因为租期没到交换机不会主动删同一个 MAC 出现多条记录说明这个 MAC 在多个端口上出现过可能是终端移动位置但旧表项没老化也可能是 MAC 冲突。绑定表还有个容易被忽略的用途它可以作为 IP-MAC 绑定的数据源配合 ARP 检测功能做准入。开了dhcp snooping check arp enable之后交换机会检查经过的 ARP 报文如果源 IP 和源 MAC 的对应关系不在绑定表里就直接丢弃。这个功能对私设静态 IP 的管控很有效但也容易误伤——服务器、打印机、网络设备这些配了静态 IP 的必须手工加静态绑定否则 ARP 直接被拦表现就是能 ping 通但业务不通或者干脆完全不通。5.2 静态绑定该配在哪配错了会怎样静态绑定的作用是把MAC-IP-接口-VLAN这组关系写死不依赖 DHCP 交互。它用在两类场景一是静态 IP 的设备需要参与 ARP 检测二是需要给特定终端固定分配地址。dhcp snooping user-bind static ip-address 10.1.10.20 mac-address 0011-2233-4455 interface GigabitEthernet 0/0/1 vlan 10配错的典型表现是业务时通时不通。比如接口写成了上行口而不是实际的接入口ARP 检测时源接口对不上报文被丢弃或者 VLAN 写错绑定关系和实际转发不在同一个广播域里。这类问题排查起来很费时间因为绑定表的查询结果看起来是有记录的只有把记录里的每个字段和实际情况逐一核对才能发现。我个人的建议是静态绑定尽量少配能用 DHCP 保留地址解决的就不用静态绑定。确实需要配的配完之后立刻用display命令查一遍把接口、VLAN、IP、MAC 四项对照现场实际情况确认别配完就走。5.3 表项异常时的清理与持久化绑定表默认存在内存里设备重启就没了。这在正常环境下没问题因为终端会重新走一遍 DHCP 交互重建表项。但在开了 ARP 检测的环境里设备重启后到终端重新拿到地址之前这段时间内的 ARP 报文全部会被丢弃表现为重启完交换机一片终端短暂断网。这个窗口期通常几分钟取决于终端的续租周期。解决办法是开持久化把绑定表写到存储介质里重启后自动恢复。命令各厂商不同通常是dhcp snooping user-bind auto-save之类的开关。开启之后要确认存储空间够用表项多的时候文件不小。还有一种情况需要手工清理终端换了网卡MAC 变了但旧表项还在。这时候新 MAC 走 DHCP 能拿到地址但如果服务器分配的是同一个 IP就会出现两个 MAC 对应同一个 IP 的表项ARP 检测会混乱。清理单条表项的命令通常是reset dhcp snooping user-bind加上过滤条件用的时候注意别把整个表清了尤其是在业务高峰期。6. 一次现场复盘某个工位终端拿不到地址的排查记录6.1 现象描述与第一轮假设去年处理过一个挺典型的问题。某办公区三层的一个工位终端插上网线之后一直显示正在识别网络最后落到 169.254 网段。同一个接入交换机的其他工位全部正常同一层的其他交换机也正常。第一轮假设列了三个接入端口配置问题VLAN 划错或者端口被禁用、Snooping 拦截、终端本身网卡问题。先做最简单的排除把终端换到隔壁工位能正常拿到地址说明终端没问题把隔壁工位的终端换到这个工位同样拿不到地址说明问题确实在这个端口上。登录接入交换机查端口配置VLAN 划分正确端口状态 up没有 shutdown没有 ACL。查 Snooping 配置全局开启上行口 trusted这个端口dhcp snooping enable也配了。查绑定表这个端口下没有任何表项。到这里基本可以确定是报文在某个环节被丢了但不知道丢在哪。上镜像抓包。6.2 抓包结果推翻假设在接入端口做双向镜像抓了两分钟。过滤 bootp 之后只看到这个端口发出的 DISCOVER 报文一个 OFFER 都没有。DISCOVER 的 chaddr 是终端 MAC源 IP 0.0.0.0目的 255.255.255.255报文本身完全正常。再到上行口镜像同样过滤 bootp能看到这个 VLAN 里其他端口的完整四步交互但看不到故障端口发出的那几条 DISCOVER。这就把范围缩到了接入端口到上行口之间。继续查VLAN 是通的其他端口同 VLAN 正常端口隔离没开STP 状态是 forwardingACL 没有。剩下一个怀疑对象Snooping 的报文合法性检查。翻配置发现这个端口上多配了一条dhcp snooping check chaddr enable有些设备叫dhcp snooping check mac作用是校验 DHCP 报文里的 chaddr 字段和以太网帧的源 MAC 是否一致不一致就丢弃。把终端的以太网帧源 MAC 和 DHCP 报文里的 chaddr 拉出来对比果然不一致。终端是一台装了某些网络管理软件的机器软件做了 MAC 层的封装处理帧头和报文里的地址对不上。6.3 根因与最终处理根因就是这条 chaddr 校验。这个功能本来是防攻击的——有人伪造 chaddr 来骗取地址或者做地址耗尽攻击交换机通过校验把伪造报文丢掉。但在实际环境里某些终端软件、虚拟化网卡、USB 网卡确实会产生帧头与 chaddr 不一致的报文导致正常终端也被误伤。处理方式有两种一是把这条端口的 chaddr 校验关掉保留其他端口的校验二是把终端上的那个网络管理软件的处理逻辑改掉。前一种更现实因为不能要求用户去改软件配置。interface GigabitEthernet 0/0/1 undo dhcp snooping check chaddr enable改完之后让终端重新插拔网线抓包立刻看到了完整的 DORA 四步交互绑定表也生成了对应表项问题解决。这次排查给我的教训是Snooping 除了信任端口这个明面上的拦截点还有一堆报文合法性检查的隐藏开关包括 chaddr 校验、源 MAC 校验、option 82 格式校验等等。这些开关在不同设备上的默认值不一样有的是默认关有的是默认开。接手一个陌生环境时我会先把这些检查项全部列出来看一遍而不是等到出问题再一条条试。顺便说一句如果当时没有做上行口的镜像对比只在接入口抓包看到的现象会是DISCOVER 发出去了很容易误判成服务器没回应然后跑去查服务器方向就完全错了。两端同时抓包这件事看起来麻烦实际上是最省时间的做法。排查完之后我还做了一件事把这个接入交换机的所有端口配置导出来和其他楼层的同型号交换机做了一次 diff把不一致的项逐条过了一遍。结果又发现两台设备的max-user配得偏小一台配了 1接小交换机的工位必然会出问题。这种顺手的事做多了后面报障的频率会明显下降。最后一提DHCP 排查里最容易忽略的其实是时间。抓包文件拿到手第一件事看时间戳看 DISCOVER 的重发间隔。正常的重发是 1 秒、2 秒、4 秒、8 秒这样指数退避如果看到间隔是 0.1 秒的密集重发那基本可以确定是客户端侧的问题而不是网络侧——正常的 DHCP 客户端不会那么急。这个细节能帮你在一分钟内判断该往哪个方向查。