企业官网建设流程全解析

最近好几个在不同场合工作的朋友都在跟我聊 DHCP 的配置问题：有人问“华为交换机去哪里看 DHCP 配置”，有人问“两台虚拟机怎么用我的 DHCP 分配地址”，还有人问“内网已经有一台物理 DHCP 服务器了，交换机还要不要配”。这些问题单独看都不难，但放进真实项目里，牵扯到的细节和坑并不比别的网络协议少。我干脆借这篇把 DHCP 从原理到落地到排障完整梳理一遍，按我平时干活的实际顺序来写，适合刚接触交换机的网络新人，也适合被虚拟机地址问题折腾过的运维老手直接抄作业。

1. DHCP到底在做什么：地址从哪来，又是怎么没的

1.1 四个报文，一次握手

DHCP 全称 Dynamic Host Configuration Protocol，翻译过来是动态主机配置协议。它在网络里的角色，说人话就是：终端设备连上网络之后，自己去找一台服务器要一份“网络身份证”，这份身份证包括 IP 地址、子网掩码、默认网关、DNS 服务器等参数。没有 DHCP 的时代，这些参数全靠手工在每台机器上填，几百台电脑的工作量和出错率你可以想象一下。

客户端和服务器之间打交道，过程叫 DORA，四个报文：

• Discover：客户端说“我在这个网段里，有 DHCP 服务器吗？给我一个地址”。
• Offer：服务器说“我这有地址，192.168.10.100 可以给你，你看要不要”。
• Request：客户端说“要，就要这个地址”。
• Ack：服务器确认“好，这个地址归你了，有效期 24 小时”。

这四步里，Discover 和 Request 都是广播报文，Offer 和 Ack 对客户端来说也可能走广播。这里有一个非常关键的点：广播报文只能在一个广播域里传播，过不了三层网关。所以 DHCP 客户端和 DHCP 服务器如果不在同一个 VLAN，就需要中继设备帮忙传话，这个后面专门讲。

我个人一直觉得，DORA 的过程不用死记，把它记成一个酒店入住流程就好：你到前台要房，前台推荐房号，你确认要住，前台发房卡。真正干活的时候，比报文流程更重要的是地址池和租期怎么设，这两个才是日常运维里天天打交道的对象。

1.2 租期、地址池和“网关老大哥”

DHCP 分配出去的地址是带租约的，不是永久占用的。租期到了，客户端要续租，没有续租成功的地址会被服务器回收，放回地址池里等下一个客户。这个设计的目的是让有限的 IP 地址可以被反复利用，尤其适合流动性强的场景。

租期的续租节奏一般是：到达租期的 50% 时，客户端会单播 Request 想续租；如果失败，到 87.5% 时它会重新广播走一遍完整的 DORA 流程。我见过有人不理解为什么一条网线会上时不时出现 DHCP 广播，其实就是这个机制在跑。

那租期该怎么设？我一般按场景来定：

• 临时会议网络、咖啡店这种流动大的地方，租期设 30 分钟到 2 小时，人多的时候地址可以快速轮转。
• 企业办公网这种电脑长期在线的环境，设 8 小时到 1 天就够。太短会产生大量续租报文，太长又不利于地址回收。
• 服务器、打印机、门禁这类固定设备，最好的做法不是依赖租期，而是在 DHCP 上做保留绑定，或者干脆配置静态地址。

地址池的容量也要大致会估算。一个 /24 网段可用的地址是 254 个（去掉网络号和广播地址），网关占一个，再排除掉不参与动态分配的段，剩下的才是真正的动态地址池。比如网关是 192.168.10.254，网络里还有一台 DNS 占了 192.168.10.253，那地址池大概可以写成 192.168.10.1-192.168.10.252，再排除 .1-.50 作为服务器等固定设备保留段，实际动态分配范围就是 .51-.252，共 202 个地址。这个数最好心里有数，不然地址池耗尽的时候排查会很头疼。

1.3 跨网段为什么叫不到服务器

这个问题几乎是中继配置的必修课。DHCP 客户端发出 Discover 广播时，交换机只会把这个报文在同一个 VLAN 内部广播，不会跨 VLAN 转发。如果 DHCP 服务器不在客户端所在 VLAN，服务器根本收不到请求，自然不会有回应。客户端拿不到地址，时间一长就会退化成 169.254 开头的 APIPA 地址，Windows 上表现为“无法识别的网络”。

解决这个问题的方向有两个：要么把 DHCP 服务器部署到每个网段里，这显然不现实；要么在网关上做 DHCP 中继（Relay），让网关替客户端把请求转成单播发给服务器。中继的原理不复杂，但配置上有几个容易出错的地方，后面第 4 节我会专门演示，先在这里埋个伏笔。

2. 华为交换机上把DHCP服务开起来：全局模式还是接口模式

2.1 先选对模式，后面才不返工

在华为交换机上做 DHCP 服务，有两套路径：全局地址池模式和接口地址池模式。

全局地址池模式：先在系统视图下用ip pool创建地址池，定义network（可分配网段）、gateway-list（网关）、dns-list（DNS）等属性，然后在具体接口（通常是 VLANIF 三层的网关接口）下执行dhcp select global，让这个接口用全局配置的地址池来分发地址。

接口地址池模式：直接在 VLANIF 接口下执行dhcp select interface，地址池会自动取该接口所在网段，不需要单独创建地址池。这种模式适合网段少、参数简单的场景，比如一台小接入交换机只给一个 VLAN 发地址。

我的建议是：只要 VLAN 数量超过两三个，就优先用全局地址池。原因是接口地址池不好统一管理，DNS、租期、保留地址这些参数要在每个接口重复配置，一旦公司里 DNS 变了，你要跑到每个交换机接口下一遍遍改，容易漏。

2.2 全局地址池配置实操

拿一台核心交换机举例，我要给 VLAN 10 和 VLAN 20 两个网段发地址。规划如下：

• VLAN 10：192.168.10.0/24，网关 192.168.10.254，排除 .1-.50 作为固定设备段，动态分配 .51-.253，租期 1 天。
• VLAN 20：192.168.20.0/24，网关 192.168.20.254，排除 .1-.50，租期 3 天。

配置命令如下：

system-view # 全局开启 DHCP 服务能力 dhcp enable # VLAN 10 地址池 ip pool pool_vlan10 network 192.168.10.0 mask 255.255.255.0 gateway-list 192.168.10.254 dns-list 192.168.10.254 223.5.5.5 excluded-ip-address 192.168.10.1 192.168.10.50 lease day 1 hour 0 minute 0 quit # VLAN 20 地址池 ip pool pool_vlan20 network 192.168.20.0 mask 255.255.255.0 gateway-list 192.168.20.254 dns-list 192.168.10.254 223.5.5.5 excluded-ip-address 192.168.20.1 192.168.20.50 lease day 3 hour 0 minute 0 quit # 在 VLANIF 接口上启用全局 DHCP interface Vlanif10 dhcp select global quit interface Vlanif20 dhcp select global quit

这段配置里有个细节：dns-list我写了一个内网 DNS 和一个公共 DNS，实际项目里可以根据公司策略调整。excluded-ip-address一定不能省，否则网关地址或者服务器、打印机的固定 IP 被发出去，全网都会出现冲突。

2.3 查看与验证：display dhcp 系列命令

“华为交换机如何查看 DHCP 配置”这个热搜词，对应的就是这一组命令。我平时用得最多的有这几条：

# 1. 看全局 DHCP 功能是否开启 display dhcp enable # 2. 看所有地址池的情况 display ip pool # 3. 看某个具体地址池的详细参数和分配情况 display ip pool name pool_vlan10 # 4. 看当前已分配的租约，客户端 MAC 和 IP 的对应关系 display dhcp lease # 5. 看 DHCP 报文的收发统计 display dhcp statistics

我的排查路径通常是这样：先display ip pool name pool_vlan10看地址池剩余量，如果剩余为 0，就能解释为什么客户端拿不到地址；再看display dhcp lease找到底是哪些设备占着地址；如果地址池还有很多，就看display dhcp statistics判断报文是否正常流转。Discover 数量在涨、Offer 却是 0，说明服务器根本没回应或者回应被丢弃；Offer 有但 Ack 没有，多半是多个 DHCP 服务器冲突或者客户端主动拒绝了。

提示：华为不同版本命令有差异，遇到老版本可能看到display dhcp server statistics之类的写法，但核心排查思路一样。命令不确定时多敲一个问号，设备会提示补全。

2.4 这几个坑，我劝你别踩

先说第一个：地址池网段和 VLANIF 网段不匹配。很多人配置的时候只想着地址池写对，没注意 VLANIF 的 IP 是否在同一个网段。比如 VLANIF10 配的是 192.168.10.254，地址池 network 却写成 192.168.20.0，客户端从地址池拿到 192.168.20.x，网关却是 192.168.10.254，两者根本无法互通，终端虽然拿到了地址但完全无法上网。这种问题用display ip pool和display current-configuration interface Vlanif10对比一下就能看出来。

第二个：地址池里没做排除。有次一个朋友告诉我，公司网络莫名其妙频繁掉线，最后发现 DHCP 把网关地址 192.168.1.254 分给了某个终端，交换机的网关和它 IP 冲突，全网时通时断。这种低级错误排查起来非常难受，因为现象是随机性的。所以我在任何项目里，都会先把网关、网络设备管理地址、重要服务器地址全部手工列为排除段，再开 DHCP。

第三个：租期设得太短。如果地址池租期设成 5 分钟，全网几百台设备的续租报文会在短时间内集中产生，交换机 CPU 直接被负担拉满。租期短只适合特殊场景，日常办公网还是建议最少 1 小时以上。

3. 内网已有一台物理DHCP服务器，交换机该怎么配

3.1 先想清楚“谁该干活”

很多公司的情况是：内网已经有一台 Windows Server 或 Linux 服务器专门跑 DHCP 服务。这时候交换机的正确角色是“管道工”，不是“第二个房东”。有的人习惯性在交换机上也开 DHCP，结果网络上同时存在两个响应者，客户端可能拿到任意一台服务器的地址，地址冲突随时爆发。

我见过一次比较惨烈的现场：核心交换机上开着 DHCP，下面一台服务器也开着 DHCP，两边地址池还有重叠。某天早上办公网 PC 大面积提示“IP 地址冲突”，最后抓包发现同一个 Discover 回了两个 Offer，源 IP 一个是核心交换机，一个是那台服务器。处理方式只能是关掉其中一个。从此我们团队立了一条规矩：单一 DHCP 服务源，其余设备只做中继或透传。

所以，如果内网有物理 DHCP 服务器，交换机侧要做四件事：VLAN 放通、不启本地 DHCP Server、开启 DHCP Snooping、按需配置 DHCP Relay。前三件下面讲，第四件放第 4 节。

3.2 VLAN放通与DHCP Snooping：两份必须做的功课

VLAN 放通这件事很容易想当然。如果 DHCP 服务器和终端在同一个 VLAN 里，只要服务器所连的交换机接口加入了对应 VLAN，终端就能广播请求过去，交换机不需要额外配置。可要是服务器在 VLAN 100，终端在 VLAN 10，那就有两种做法：要么把服务器的接口划到终端所在 VLAN（不推荐，服务器一般有独立管理网段）；要么在 VLANIF 三层接口上配 DHCP Relay，让广播变成单播跨网段转。前者是二层放通，后者是三层中继，场景不同，别混。

再说 DHCP Snooping。这个功能的核心作用，是在交换机上建立一张“IP + MAC + 接口 + VLAN”的绑定表，并通过信任口机制防止非法的 DHCP 服务器响应报文进入网络。你可以把 Snooping 理解为门卫：它认得谁是正规的 DHCP 服务器（信任口），其他接口收到的 DHCP Offer/Ack 报文一律忽略。

配置的时候，关键是信任口设置：

system-view # 全局开启 DHCP Snooping dhcp snooping enable # 把连接物理 DHCP 服务器的接口设为信任口 interface GigabitEthernet0/0/1 dhcp snooping trusted quit # 在终端所在的 VLAN 上启用 Snooping vlan 10 dhcp snooping enable quit

这里最容易被坑的是：只要开了 Snooping，所有非信任口都不能接收合法的 DHCP Offer/Ack 报文。如果你忘了把接 DHCP 服务器的口配成 trusted，那全网终端都会拿不到地址，而且现象很像服务器挂了。所以开 Snooping 之后，第一件事就是验证信任口是否配对。

另外，如果交换机上联口接的是合法的 DHCP 中继设备（比如上级路由器的 DHCP Helper），这个上联口也要配 trusted，否则中继报文会被当作非法报文丢掉。判断标准就一句话：能让合法的 DHCP Offer/Ack 进来的口，就是 trusted。

3.3 一台服务器和一台交换机同时响应怎么办

如果因为历史原因已经出现了“双 DHCP 服务”的乱局，第一反应不要急着改配置，先抓包确认响应者是谁，再决定关谁。抓包可以在交换机上做端口镜像，也可以在客户端上用 Wireshark 抓 67/68 端口，看 Offer 报文的源 IP。确认来源之后，按业务规划关闭其中一端。比如公司统一以物理服务器为准，就把交换机上的 DHCP 全部停掉，地址池删掉。

如果公司为了高可用确实要跑两台 DHCP 服务器，也不是不行，但服务器之间要做故障转移或分裂作用域，千万不要两台服务器各自分配同一个网段而无协调，否则很容易出现分地址冲突。我遇到过两台服务器各自配了半个网段、结果因为其中一台时间不准导致租约混乱，客户端续租时被反复踢下线，这个坑单靠交换机侧无法规避。

养成一个习惯：有物理 DHCP 服务器时，在交换机上定期看看 Snooping 绑定表和统计：

display dhcp snooping user-binding display dhcp snooping statistics

如果客户端能正常拿地址但绑定表一直不增长，说明 Snooping 逻辑可能有异常，后续如果要做报文过滤策略，基础数据就不准。

4. 跨网段分配地址：DHCP中继配置拆解

4.1 中继的原理：广播变单播

DHCP 中继，也叫 Relay，解决的就是“客户端和服务器不在同一个广播域”的问题。工作过程是：客户端在本地广播一个 Discover，网关设备（通常是核心交换机或路由器）收到后，在报文的 giaddr 字段里填上自己的接口地址，然后把报文单播转发给指定的 DHCP 服务器；服务器收到后根据 giaddr 判断客户端所属网段，从对应地址池里挑一个地址，把 Offer 单播回给中继设备；中继设备再把 Offer 转给客户端。

你可以把它想象成：客户端在走廊里喊“谁有地址”，传达室大爷听到了，专门跑到行政楼问有没有空房，再跑回来把答复告诉客户端。中间人能不能准确传话，取决于大爷有没有记对房间号——对应到网络里就是 giaddr 字段是否准确、地址池是否和 giaddr 所在网段匹配。

4.2 华为交换机中继配置实例

需求是：VLAN 10 和 VLAN 20 两个网段的终端，都要找 192.168.100.5 这台物理 DHCP 服务器要地址。DHCP 服务器上已经分别建了两个 scope，对应 192.168.10.0/24 和 192.168.20.0/24。

交换机配置：

system-view # 全局开启 DHCP（提供中继能力，不建地址池） dhcp enable interface Vlanif10 ip address 192.168.10.254 255.255.255.0 dhcp select relay dhcp relay server-ip 192.168.100.5 quit interface Vlanif20 ip address 192.168.20.254 255.255.255.0 dhcp select relay dhcp relay server-ip 192.168.100.5 quit

注意两个关键点：一是每个 VLANIF 都要单独配dhcp relay server-ip，因为中继是接口级的；二是该交换机上不要再建地址池，也不要再配dhcp select global，同一接口二者互斥。配置完用display dhcp relay interface Vlanif10和display dhcp relay statistics看状态和转发统计。

可能有人会问：地址池建在物理服务器上，交换机怎么知道哪个地址池对应哪个 VLAN？答案就是靠 giaddr。服务器收到中继的单播请求后，只要看 giaddr 是 192.168.10.254，就知道客户端来自 192.168.10.0/24 网段，然后从对应 scope 里选地址。所以如果服务器上的 scope 网关配置和交换机 VLANIF 不一致，也会导致分配错误。

4.3 两台虚拟机“怎么用我的 DHCP”

这个场景我用最简单的例子讲：你在 VMware 或 KVM 上跑了两台虚拟机，分别接不同的虚拟网络，想用同一台 DHCP 服务器给它们发地址。从协议角度来说，虚拟机跟物理机没有区别，只要虚拟网络能和物理网络打通，DHCP 请求照样能到达服务器。具体路径是：

虚拟机 1 连在 VLAN 10 的虚拟交换机上 -> 虚拟交换机把广播送到物理交换机 -> 物理交换机的 Vlanif10 收到后做中继 -> 中继到 DHCP 服务器 -> 服务器从 192.168.10.0 的 scope 里分配地址 -> 应答原路返回。

虚拟机 2 如果连在 VLAN 20，同理会从 192.168.20.0 的 scope 拿地址。整个过程中，DHCP 服务器自始至终不关心对端是不是虚拟机，它只看 giaddr 和 MAC。所以如果你问“两台虚拟机如何用我的 DHCP”，答案不是去虚拟机里做什么特殊配置，而是把中间的三层中继和服务器上的地址池配好。

如果两台虚拟机在同一个 VLAN 里，那就连中继都不需要，只要 DHCP 服务器能在这个 VLAN 里被广播到，虚拟机开机后自己就能拿地址。

4.4 配置中继后如何验证链路真的通了

中继配完，最怕的是看着配置对了但实际不通。我的验证三板斧如下：

1. 在客户端上执行ipconfig /release和ipconfig /renew，同时在交换机上执行display dhcp relay statistics，看 Discover/Offer 报文计数是否有增长。没增长，说明客户端请求可能都没到交换机三层接口。
2. 在 DHCP 服务器上抓包，过滤 UDP 67 端口，看是否能收到来自中继地址的单播 Discover。如果收到了但没回包，检查服务器的 scope 和网关配置；如果连请求都没收到，说明交换机到服务器路由不通，或者中继配置被 Snooping 给挡了。
3. 看报文里的 giaddr 字段。客户端正常获取后，Offer 报文里的 yiaddr 必须和 giaddr 所在网段匹配。如果 giaddr 是 0.0.0.0，说明请求没经过中继，说明客户端和服务器其实在同一个二层广播域，那是另一种情况，不要用中继的思路去套。

5. 虚拟机与vnic：DHCP里的那些坑

5.1 虚拟机拿地址，和物理机到底有什么不同

从 DHCP 协议本身看，虚拟机的 vnic 和物理机的网卡没有本质区别，都是发广播、收 Offer、续租一样的流程。但从运维角度看，虚拟化带来的管理复杂度确实更高：克隆、快照回滚、多网卡、虚拟交换机安全策略，每一个环节都可能让 DHCP 出现不同于物理环境的怪问题。所以这一节单独拎出来讲。

最常见的第一类问题是克隆和快照。VMware 或者 KVM 里克隆一台虚拟机，虚拟网卡的 MAC 地址通常会重新生成，除非模板里做了特殊设置。如果你在 DHCP 服务器上针对原虚拟机的 MAC 做了保留绑定，克隆出来的新虚拟机 MAC 变了，保留绑定就失效，它会从动态池里拿地址，业务 IP 就不是你预期中的那个。快照回滚就更隐蔽——虚拟机回滚到几天前，网卡 MAC 没变，但 DHCP 服务器租约数据库里这个 MAC 之前的租约可能还没释放，或者地址已经被其他终端占用，结果就是回滚后的虚拟机拿到地址后就冲突。

我的建议是：给重要虚拟机固定 IP，不要手工在系统里配死，而是在 DHCP 服务器上做地址保留（Reservation），并且记清楚虚拟机的 MAC。这样后续做迁移、克隆时，至少 DHCP 侧的绑定关系是明确的。

5.2 克隆、快照和“地址变脸”问题

承接上面说的，克隆后如果 MAC 变了，虚拟机开机后拿到动态 IP 也属正常，但如果你需要它保持某个固定 IP，就要在 DHCP 服务器上把新 MAC 也加进保留。更稳妥的做法是在虚拟机模板里锁定网卡 MAC（比如 VMware 的“自动生成”改成“手动设置”），这样克隆出来的虚拟机 MAC 稳定，DHCP 保留就能直接用。

快照回滚导致的地址问题，处理方法通常是开机后把旧租约清掉重拿。Windows 里执行：

ipconfig /release ipconfig /renew

Linux 里：

dhclient -r dhclient

注意，执行 release 时如果网络不可用，DHCP 客户端可能一直等不到服务器确认释放，此时可以配合重启网络服务。但根本上说，重要虚机尽量用保留绑定，少依赖动态租约，能少掉很多事。

5.3 当“DHCP服务器为vnic”做绑定时：MAC与Client ID

“DHCP服务器为vnic”这个场景，实际是在 DHCP 服务器上给某个虚拟机的虚拟网卡单独做地址保留。这里有个容易被忽略的问题：DHCP 客户端在发请求时，除了 MAC 地址（chaddr 字段），还可能带一个 client-id 字段。Linux 的 dhclient 默认会用网卡 MAC 生成十六进制字符串作为 client-id；Windows 的 DHCP 客户端也会生成唯一的 client-id。

问题在于：Windows DHCP 服务器的“保留”默认按 MAC 匹配，一般没问题；但 ISC DHCP（Linux 上常见）的 host 声明默认按 client-id 匹配，如果你只写了hardware ethernet而客户端带的是另一种格式化 client-id，就会匹配不上。我以前在 Linux DHCP 服务器上给一台 CentOS 虚拟机做绑定，配了 MAC 却一直不生效，抓包看才发现是匹配逻辑卡住了。后来直接改成：

host vm-test { hardware ethernet 00:0c:29:aa:bb:cc; fixed-address 192.168.10.100; }

同时在 dhclient.conf 里锁定 client-id，才最终稳定。

所以在服务器侧做了保留但不生效，先确认绑定键是 MAC 还是 client-id。养成这个意识，能少走很多弯路。

5.4 多网卡虚拟机：拿到两个网关的麻烦

一台虚拟机配了两块 vnic，分别接两个 VLAN，开机后它会向两个网段的 DHCP 各要一个地址。如果两个地址都带了默认网关，Windows 的路由表就会出现两条默认路由，系统一般按跃点（metric）选一条，但实际通信时常常出现“时通时断”的诡异现象。

我处理过一例：某虚机上联业务网和存储网两个网段，存储网卡也启用了 DHCP，结果存储网网关优先级高，业务流量全走了存储网，业务直接卡死。最后处理是：存储网卡在 DHCP 上禁用默认网关，或者在虚机里把那张网卡的“自动跃点”调高，保证业务网卡主导默认路由。更规范的做法是存储网络直接用静态 IP，根本不上 DHCP。

6. 实战排查：地址分不下来、分得不对怎么办

6.1 从客户端开始，一层一层往外查

遇到“拿不到 IP”的报障，我习惯从终端往服务器方向一层层排查，不要一上来就翻服务器日志。第一步先看客户端有没有拿到 169.254.x.x（Windows 自动私有地址），拿到这个说明 DHCP 请求根本没得到有效回应。然后确认客户端到网关的物理链路和 VLAN 是否正常。能 ping 通网关不代表 DHCP 就一定通，因为 DHCP 依赖广播和中继，跟单播 ping 的路径不完全一样。

接下来到交换机上看 Snooping、VLANIF、Relay 状态。如果在交换机上已经配了中继，就用display dhcp relay statistics看报文计数；如果是交换机本地分配地址，就用display dhcp statistics看四类报文的收发情况。最后才到服务器侧：服务是否启动、地址池是否耗尽、租约库是否异常。

这套顺序的价值在于：每一步只用一两个命令，就能把问题范围缩小一半，不至于在错误的方向上浪费时间。

6.2 典型症状对照表

这里我把实际中常见的 DHCP 故障整理成一张速查表，遇到问题时直接对照：

这张表不能说覆盖所有情况，但能覆盖日常工作里八成左右的 DHCP 问题。

6.3 抓包与日志三板斧

排查 DHCP 问题，没有抓包和日志等于摸黑走路。我常用的三种手段：

第一，交换机上开 DHCP 调试。华为设备可以执行：

terminal monitor terminal debugging debugging dhcp all

不过生产环境要慎重，报文量大时调试信息会把 CPU 刷爆，建议维护窗口内短时间开启，用完就undo debugging dhcp all关掉。

第二，看服务器侧租约和日志。Windows DHCP 服务器的“地址租约”界面会列出每个客户端拿到的 IP、MAC 和租约到期时间；Linux 下租约文件一般在/var/lib/dhcp/dhcpd.leases或/var/lib/dhcpd/dhcpd.leases，直接查看最近分配记录。如果发现同一个 MAC 频繁出现短租约又释放，大概是客户端在反复续租失败。

第三，Wireshark 抓包只看 bootp。过滤器写bootp或udp.port==67，重点看三个字段：giaddr（中继地址）、chaddr（客户端 MAC）、yiaddr（分配 IP）。如果请求量很大，可以先用显示过滤提取特定报文。

6.4 几个我踩过的坑，给你当“避雷针”

这几年和 DHCP 打交道，踩过的坑不少，说几个印象最深的。

第一个是地址池网段和 VLANIF 网段“半通”的坑。有次给一家客户调网络，客户端顺利拿到了 192.168.1.x 的地址，能 ping 通网关，但访问外网时通时断。查了半天，最后发现核心交换机 VLANIF 配的是 192.168.0.254，而 DHCP 地址池却写成了 192.168.1.0。终端以为网关是 192.168.0.254，交换机确实也能路由这个地址，但路由表里没有对应的直连网段，出公网就走不通。这类问题从抓包看完全是正常的，必须同时核对地址池和 VLANIF 的网段。

第二个是开启 DHCP Snooping 后全网掉线。这几乎是新手最容易踩的坑：在交换机上执行了dhcp snooping enable，但没有把接 DHCP 服务器的口配成 trusted，结果所有 Offer 报文都被交换机丢弃，终端集体拿不到地址。我还见过更夸张的，把上联核心交换机的 trunk 口也误配成非信任，导致下面接入交换机的中继报文全部被丢。这类问题的排查思路就是检查信任口，凡是“能收到合法 DHCP 响应”的物理路径必须全部 trusted。

第三个是双 DHCP 服务器造成的“随机受灾”。有次一个办公网长期有零星 IP 冲突报错，排查了很久，最后在两台不同的服务器上都发现了 DHCP 服务进程，一台管业务网段，一台管办公网段。每当办公网地址池耗尽，第二台服务器开始响应超出地址池范围的请求，整个网络混乱无序。从那之后，我坚持“一台服务器只跑一组明确的 DHCP 作用域，其他设备只当中继”，即使要做高可用，也必须在服务端做好故障转移和分裂作用域，从根上避免双活冲突。

最后再说一个个人习惯：任何 DHCP 相关的大改动之前，先把当前配置完整备份和记录一遍。DHCP 服务一旦出问题往往是全网故障，没有回滚方案就动手，等于把自己架在火上烤。改之前拍照或存档，改完以后立刻验证，再小心都不为过。