1. 设备拿不到 IP 的现场从串口到抓包局域网里终端拿不到地址表面看是「DHCP 没生效」实际链路可能断在物理层、广播域、地址池、中继或冲突检测任意一环。这篇记录一次真实排障一台 AC 设备的 WAN 口接进 192.168.186.0/24 这个开了自动获取的子网串口下route -n却始终没有默认路由接口状态又是 UP 的。适合做网络运维、弱电交付、嵌入式设备调试的朋友对照排查。核心检索词先摆出来DHCP 拿不到 IP、BOOTP 流程、ARP 探查、静态绑定。这几个词基本覆盖了「设备无法获取 IP」的完整链路。我的思路是逐层往下剥先确认物理层和接口状态再抓 ARP 看广播域通不通然后抓 BOOTP 看四次握手走到哪一步最后用 ARP 表核验是不是地址冲突实在不行就静态绑定规避。整个过程用到的工具很朴素串口终端、ethtool、ip addr、ip route、tcpdump以及 DHCP 服务器上的show命令。不需要额外装什么关键是抓包过滤条件要写对不然一堆无关流量会淹没有效信息。2. TaoToken 前置把模型对话和接入文档备好排障过程中经常要临时查命令语法、确认某个 Option 字段含义或者让模型帮忙解读一段抓包输出。我习惯把 TaoToken 的模型对话页面开着当随身手册遇到tcpdump过滤表达式拿不准、或者 BOOTP 某个 Option 编号记不清时直接问一句比翻文档快。如果你也要接入自己的排障脚本或自动化工具先去控制台拿 API Key再对照接入文档改 base_url 和鉴权头。地址分别是模型对话https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite控制台https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewriteAPI Keyshttps://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewriteAPI 端点统一是https://taotoken.net/api这个不带 UTM直接填进代码里就行。长期做网络自动化或 Agent 编排的可以看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite注意TaoToken 在这里的角色是帮你查资料、解读抓包、生成排障脚本的辅助工具不是替代你现场敲命令。真正的定位还得靠串口和抓包。3. 可复制配置抓包过滤、DHCP 中继与静态绑定3.1 物理层与接口状态确认先接串口确认设备当前接口和 VLAN 划分。AC 类设备常见做法是所有网口建一个网桥再在网桥上划 VLANWAN 口默认走 4093/4094 这类 VLAN 并开启 DHCP client。# 查看接口简要状态确认物理层是否 UP show int brief # 验证面板丝印和实际网口对应关系执行后对应网口灯会闪 ethtool -p eth0 ethtool -p eth1 # 查看接口详细地址和 MAC ip addrip addr输出里重点看两处state UP和LOWER_UP说明物理层激活link/ether后面的 MAC 要和你后续抓包看到的源 MAC 对上。如果 eth0 的 MAC 和 VLAN 接口的 MAC 不一致别慌网桥模式下 VLAN 接口会继承网桥 MAC以 VLAN 接口的 MAC 为准。3.2 ARP 抓包确认广播域是否打通广播域不通DHCP 的 discover 根本出不去。先用 ARP 抓包看能不能收到同网段其他设备的广播# 抓 ARP-n 不解析主机名-e 显示 MAC-v 详细 tcpdump -i eth0 -nnev arp正常能收到类似这样的广播请求和应答09:36:15.687233 64:a3:80:86:ff:01 ff:ff:ff:ff:ff:ff, ethertype ARP, Request who-has 192.168.186.181 tell 0.0.0.0 09:36:15.687511 64:a3:41:b3:f7:60 64:a3:80:86:ff:01, ethertype ARP, Reply 192.168.186.181 is-at 64:a3:41:b3:f7:60这里有个关键知识点源 IP 是0.0.0.0的 ARP 请求叫ARP 探查Probe是设备拿到 IP 后用来检测地址冲突的默认发三次、间隔约 1 秒。如果三次都没人应答认为 IP 可用如果有人应答就判定冲突。3.3 BOOTP/DHCP 抓包看四次握手卡在哪确认广播域通了接着抓 DHCP 端口 67# 抓 DHCP 服务端端口看 discover/offer/request/ack 全流程 tcpdump -i eth0 -nnev port 67 # 同时抓 DHCP 和 ARP方便对照冲突检测 tcpdump -i eth0 -nnev port 67 or arp正常的 ACK 报文长这样192.168.186.1.67 192.168.186.181.68: BOOTP/DHCP, Reply, length 300 Your-IP 192.168.186.181 Client-Ethernet-Address 64:a3:80:86:ff:01 DHCP-Message Option 53: ACK Server-ID Option 54: 192.168.186.1 Subnet-Mask Option 1: 255.255.255.0 Default-Gateway Option 3: 192.168.186.1如果 ACK 之后紧跟一条 Decline就说明设备检测到冲突了0.0.0.0.68 255.255.255.255.67: BOOTP/DHCP, Request DHCP-Message Option 53: Decline Requested-IP Option 50: 192.168.186.181 MSG Option 56: Duplicate address detected3.4 DHCP 服务器侧核验与静态绑定在 DHCP 服务器上查 MAC 学习、租约和 ARP 表# 查 MAC 地址表确认设备 MAC 已被学习 show mac- | inc ff01 # 查活跃租约看有没有分配成功 show ip dhcp lease act | inc ff:01 # 查 ARP 表看 IP 和 MAC 有没有绑定 show ip arp | inc ff:01如果租约和 ARP 都为空但 MAC 已学习说明设备发了 discover 但没走完流程。这时用静态绑定规避# 进入 DHCP 配置视图做 MAC 与 IP 的静态绑定 dhcp-config static-bind mac-address 64a3.8086.ff01 ip address 192.168.186.44 # 确认配置已写入 show run | inc stati绑定后换一个物理口比如从 eth0 换到 eth1重新触发完整流程避免旧 IP 信息残留# 换口后观察 VLAN 接口是否拿到静态绑定的地址 ip addr # 检查路由表确认直连路由和默认路由生成 ip route route -n成功时ip addr会显示inet 192.168.186.44/24route -n会多出0.0.0.0 192.168.186.1 0.0.0.0 UG 0 0 0 vlan1.4094 192.168.186.0 0.0.0.0 255.255.255.0 U 0 0 0 vlan1.40944. 验证请求与成功结果静态绑定生效后完整验证一遍。先看接口地址ip addr show vlan1.4094期望输出包含inet 192.168.186.44/24和state UP。再看路由ip route期望看到默认路由default via 192.168.186.1 dev vlan1.4094和直连路由192.168.186.0/24 dev vlan1.4094。最后从同网段另一台机器 ping 一下ping -c 4 192.168.186.44如果四包全通说明地址、路由、广播域都没问题。再回到 DHCP 服务器确认租约show ip dhcp lease act | inc 192.168.186.44能看到对应 MAC 和 IP 的租约记录整个链路闭环。5. 本篇常见错排查抓包看不到任何 ARP 广播先查物理层ethtool看链路状态确认网线接的是不是目标 VLAN 对应的口。面板丝印和实际口不一致很常见用ethtool -p让灯闪来确认。能看到 ARP 但看不到 DHCP检查抓包过滤是不是只写了port 67有些环境 DHCP 走的是port 68客户端口用port 67 or port 68更稳。另外确认设备确实开启了 DHCP client。ACK 之后一直 Decline 死循环这是 DHCP 服务器收到冲突上报后没有重新分配空闲 IP 导致的。短时间改不了服务器行为直接静态绑定规避把冲突 IP 换成空闲地址。静态绑定后还是拿不到地址检查绑定的 MAC 格式服务器上常用64a3.8086.ff01这种点分十六进制别写成冒号分隔。另外换口后要确认新口的 VLAN 接口 MAC 和绑定 MAC 一致。路由表有直连路由但没有默认路由说明 DHCP 没下发 Default-Gateway或者 ACK 里 Option 3 缺失。抓包确认 Option 3 是否存在没有的话在服务器侧补上网关配置。设备最终用了 169.254.x.x这是本地链路地址说明 DHCP 彻底失败。回到抓包看 discover 有没有发出去、offer 有没有回来逐段定位。6. 把排障流程沉淀成可复用动作这套流程跑下来最值钱的是抓包过滤命令和判断逻辑。tcpdump -i eth0 -nnev port 67 or arp这一条基本能覆盖 DHCP 排障的大部分场景配合ip addr和route -n就能定位到具体环节。如果你想把这类排障脚本化或者让模型帮你解读抓包输出、生成对应的过滤表达式可以用 TaoToken 的模型对话快速验证思路https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite需要接入自动化工具的话API Key 在控制台拿https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite接入细节对照文档改就行https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite长期做网络自动化编排的Coding Plan 更适合https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite最后留一个实用习惯每次排障完把抓包过滤命令、关键判断点、最终配置片段记到一个笔记里。下次遇到类似问题直接翻笔记比重新抓包快得多。静态绑定这种规避手段记得在变更记录里写清楚原因不然过几个月自己都忘了为什么绑了这么个 IP。