DHCP与DHCP中继：从原理、配置到排错实战全解析-代码聚汇网

DHCP与DHCP中继：从原理、配置到排错实战全解析

DHCPDHCP中继IP地址分配

|难度：普通|阅读约 43 分钟

刚入职那年，IT扔给我一台笔记本，说“插上网线就能上网”。我插上，五秒，能上网了。当时觉得这种事情本来就该这样。直到后来自己搭服务器、配交换机，才发现这五秒背后站着一整套协议——DHCP。再后来遇到公司十几个VLAN、几十台终端拿不到IP，才明白光会DHCP远远不够，还得懂DHCP中继。这篇文章我想把这两个东西串起来讲清楚：从协议本身为什么要这么设计，到中继解决的问题，再到Linux服务器和三层交换机的完整配置，最后把我这些年踩过的排错坑一并交代。不管你是刚学网络的、做桌面运维的，还是准备网络认证的，都可以把这篇当一份能直接落地的实操参考。

1. 从手动配置到DHCP：这协议到底解决了什么问题

1.1 手动配置IP时代的痛点

先回想一下没有DHCP的时候，一台设备想上网需要什么。你要手动填四个东西：IP地址、子网掩码、网关、DNS。IP地址是这台设备在网络里的门牌号，子网掩码是判断哪些门牌在同一个小区，网关是出小区的门卫，DNS是把你想访问的名字翻译成门牌号的名录。四个填错任何一个，轻则这台设备上不了网，重则跟别人冲突，把别人的网络也带崩。

一台设备还好，几十台还能忍，几百台就要命了。更麻烦的是移动场景：笔记本从三楼搬到五楼，换了一个网段，IP就得改一次。每次改配置都得上门、开终端、敲命令，运维的人天天跑断腿。这个痛点催生了自动分配IP的需求。DHCP（Dynamic Host Configuration Protocol，动态主机配置协议）最早就是从BOOTP协议演进过来的，RFC 2131、2132是它的核心规范。它的目标很简单：让设备插上网线（或者连上Wi-Fi）之后，不用任何人工干预，自己就能拿到一套合法可用的网络参数，包括IP、掩码、网关、DNS，还有租约时间。

1.2 DORA四步握手：客户端没有IP，是怎么拿到IP的

DHCP最反直觉的地方是：客户端一开始连IP都没有，它是怎么发出请求的？答案是它用了一个特殊的身份：源IP是0.0.0.0，目标IP是255.255.255.255（广播）。这就好比一个刚搬进新小区的人，自己还没有门牌号，但可以站在楼下大喊“有没有人管分配的？”整栋楼都能听见。整个过程就是经典的DORA：

DCDiscover：客户端发广播，问“有没有DHCP服务器在？我需要一个IP”。
DHCPOffer：服务器收到后，在它的地址池里挑一个可用的IP，用广播回复“这个IP给你用，附带掩码、网关、DNS，以及租约时间”。
DHCPRequest：客户端收到Offer后，再广播一次“我决定用这个服务器给我的IP”。注意这里又是广播，不是单播。原因很简单：局域网里可能同时存在多台DHCP服务器，都发过Offer，客户端必须广播告诉所有人“我选了谁”，这样没被选中的服务器就能把预留的地址收回去重新进入可用池。
DHAck：被选中的服务器收到Request后，最终确认“这个IP正式归你”。

这个过程中，服务器发Offer时也是广播，因为客户端此时还没有IP，服务器不知道该怎么单播给它。整个流程跑完，一台设备就正式在网络上有了身份。后面续租时用的DHCPREQUEST就是单播到服务器了，因为此时客户端已经有IP，可以点对点说话。

1.3 租约不是永久给你，而是“暂住证”

DHCP分配的IP不是无限期的，这是很多人初学时会忽略的点。每个IP都配了一个租约时间。默认情况下，客户端在租约时间过去一半（T1，也就是50%）时，会主动向分配它的服务器发起单播续租，成功后租约重新计时；如果T1续租失败，它会一直用到87.5%（T2）的时间点，然后改成广播寻找任意一台DHCP服务器，尽量在租约到期前拿到新的可用地址。如果整个周期都失败，租约到期，客户端自动丢弃这个IP，回到无IP状态。

你可以把租约理解成暂住证。临时住半年，到期前一个月去续签，续不上就广播找别的管理员，再不行就搬出去。设计这套机制的核心目的是回收不用的IP。尤其是无线网络和会议室场景，设备来来去去，如果没有租约回收，地址池很快就会耗尽。后面配置部分我会专门讲租约时长怎么设，这里先记住一个原则：动态IP的本质是“复用”，不是“独占”。

1.4 服务器发地址前的“验伤”：ping packet 2为什么不能省

有段时间群里很多人搜“dhcp server ping packet 2”，其实这个配置项背后是一段很值得说的逻辑。DHCP服务器在从地址池里挑出一个IP之后，不会直接发给客户端，而是先往这个IP发几个ICMP探测包，确认没人用它，再发Offer。这个探测包的数量通常就是2个，所以你在配置里会看到类似“dhcp server ping packet 2”的字样。

为什么要做这步？因为地址池是静态维护的，服务器并不知道某个IP是不是已经被某台静态配置的设备占用了。假设你办公网里有人给打印机手动设了192.168.10.100，而DHCP地址池也恰好包含这个IP，那服务器如果直接把192.168.10.100发给另一台电脑，现场就会立马上演“IP冲突”大戏。所以服务器在分配之前先ping一下目标地址：有回应，说明有人占用，换下一个IP；没回应，才敢分配。这在ISC DHCP里由ping-check true和探测包数量控制，Windows的DHCP服务里叫“冲突检测尝试次数”，默认是0，生产环境建议至少开1到2次。

这个机制有个副作用：它会增加分配耗时，尤其是地址池快耗尽时，服务器要连续探测好几个IP才能找到一个没被占用的，客户端感觉就是“转圈圈转了好久”。但千万别图快把它关了。IP冲突导致的间歇性断网，比慢几秒钟难受得多。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. DHCP中继：广播过不了三层，那跨网段怎么办

2.1 先搞懂一个问题：广播到底是怎么“死”在三层上的

二层交换机天然会把广播帧在所属VLAN内转发，所以同网段内的DHCP Discover可以畅通无阻。但路由器不是这样工作的。路由器连接两个网段，默认不会把收到的广播包转发到另一个网段，这是它最基本的职责：隔离广播域。如果广播可以随便穿过路由器，整个网络就会因为广播风暴瘫痪。

这就出现了矛盾。企业网络架构通常是二层接入、三层汇聚，业务按VLAN分网段。VLAN10、VLAN20、VLAN30各是一个独立网段，彼此之间相互隔离，只有三层设备能打通。DHCP广播只能在自己所在的VLAN里打转，那VLAN20、VLAN30的客户端怎么找到位于另一处的DHCP服务器？

早期真的有人就地为每个VLAN放一台DHCP服务器。一台开在机房，一台开在弱电井，还有一台塞在机柜角落。配置不一样、版本不一样、负责人不一样，出了故障排查要多跑好几个地方。更重要的是地址池被切成几十个小碎片，资源没法统一调配。这个问题需要一个更聪明的解法。

2.2 中继代理扮演的“传话人”角色

DHCP中继（DHCP Relay Agent）就是专门解决跨网段分配的。它一般运行在客户端所在网段的网关设备上，也就是三层交换机或路由器上。你可以把它理解成法院门口的传话人：里面的当事人没法直接找法官，传话人替他把材料送过去，再把判决送回来。

完整的跨网段流程是这样跑的：

客户端在自己的VLAN里广播DHCP Discover，目的地址255.255.255.255。
网关设备上的中继代理侦听到这个广播，在报文里填一个关键字段——giaddr（Gateway IP Address，即收到请求的接口的IP地址），然后把报文从广播形式改成单播，发给事先配置好的DHCP服务器地址。
DHCP服务器收到后，看到giaddr是192.168.10.1，立刻明白这个客户端属于192.168.10.0/24网段，于是从对应的地址池里挑IP，然后把Offer/Ack发回给giaddr这个地址。
中继设备收到服务器的单播回复后，再变成广播包发回客户端所在的VLAN。

整个过程，客户端从头到尾以为自己是在跟本地广播里的某个服务器对话，实际上真正的服务器可能远在机房，路径中间全是单播转发。中继把这个对客户端“透明”的服务做完了。

2.3 giaddr这个字段，才是整个中继的关键

理解中继，最核心的就是理解giaddr。为什么服务器没法根据报文本身判断客户端属于哪个网段？因为客户端的原始Discover报文里，源IP是0.0.0.0，服务器根本无从得知这个“0.0.0.0”到底在哪个子网里。没有中继的时候，服务器和客户端在同一个二层广播域，服务器就知道自己是从哪个接口收到广播的，那这个接口所在的子网就是客户端的网段。但有了中继，服务器收报文的接口通常是它自己的业务网口，可能是192.168.100.x网段，跟客户端不在一个地方。

giaddr字段就是中继设备顺手在报文的固定位置填上的“真实来源网段”信息。服务器不需要猜，直接看giaddr，就知道该从哪个subnet声明里选地址。所以当你给Linux DHCP服务器配置了一堆subnet段落时，这些网段甚至不需要跟服务器的网卡直接连通，只要giaddr能指明请求来自哪个网段，服务器就能按配置分配。这个“地址池和网卡不必相同”的特点，经常让第一次配中继的人觉得别扭，但它恰恰是集中管理的精髓。

3. 实操：Linux DHCP服务器 + 三层交换机中继，完整配置

3.1 先看拓扑，再定义地址规划

我不喜欢一上来就贴命令。先给一个最常见的集中式DHCP拓扑，你理解了再动手，配置才不容易错。

假设现在是这样一个网络：一台Linux服务器作为集中DHCP服务器，接在核心交换机上，IP是192.168.100.254/24。核心交换机上划分了VLAN10和VLAN20，分别对应192.168.10.0/24和192.168.20.0/24两个业务网段。PC1接在VLAN10下面，PC2接在VLAN20下面。服务器和这两个VLAN之间通过三层路由可达。

规划地址池的时候，有一个黄金原则：给静态设备留出独立区域，给动态分配划一个明确范围。比如192.168.10.1是网关，192.168.10.2到192.168.10.49留给服务器、打印机、网络设备等静态IP，192.168.10.100到192.168.10.200才是DHCP地址池。这样做的好处是，动态池和静态区永远不会互相踩踏，DHCP服务器即便配了ping探测，也省了很多不必要的冲突。

网段	网关	DHCP地址池	保留静态区	租约时间
VLAN10	192.168.10.1	192.168.10.100-200	192.168.10.2-49	1天
VLAN20	192.168.20.1	192.168.20.100-200	192.168.20.2-49	1天
服务器互联网段	192.168.100.254	不分配	全部保留	无

3.2 Linux服务器端配置：声明“我有货”，但不知道要发给谁

在Debian/Ubuntu系系统上，先安装ISC DHCP Server：

bash复制sudo apt update
sudo apt install isc-dhcp-server

然后编辑主配置文件/etc/dhcp/dhcpd.conf。一个典型的双网段配置长这样：

text复制option domain-name "example.internal";
option domain-name-servers 192.168.10.2, 223.5.5.5;

# 服务器自身所在的直连网段
subnet 192.168.100.0 netmask 255.255.255.0 {
    # 这个网段不做动态分配，但也必须声明
}

subnet 192.168.10.0 netmask 255.255.255.0 {
    range 192.168.10.100 192.168.10.200;
    option routers 192.168.10.1;
    option domain-name-servers 192.168.10.2, 223.5.5.5;
    default-lease-time 86400;
    max-lease-time 172800;
    ping-check true;
}

subnet 192.168.20.0 netmask 255.255.255.0 {
    range 192.168.20.100 192.168.20.200;
    option routers 192.168.20.1;
    option domain-name-servers 192.168.20.2, 223.5.5.5;
    default-lease-time 86400;
    max-lease-time 172800;
    ping-check true;
}

有几个容易踩的坑要提前说。

第一，服务器自身的直连网段192.168.100.0/24必须声明一个subnet，哪怕它没有range。原因是dhcpd启动时会检查“我所有网卡上配置的IP是否都能在配置里找到对应的subnet声明”，找不到会报No subnet declaration for eth0 (192.168.100.254)并拒绝启动。很多人第一次配，死活起不来服务，就是漏了这一段。

第二，option domain-name-servers建议优先写内网DNS，再写公共DNS，顺序是有意义的。内网有域名解析需求时，写在外面反而更慢。

第三，ping-check true保留着，这是前面说的分配前冲突检测。如果服务器的日志里出现“PING response received from ...”，说明检测到地址冲突，它会自动换一个IP分配。

改完配置后，先跑一个语法检查，确认无误再启动：

bash复制sudo dhcpd -t -cf /etc/dhcp/dhcpd.conf
sudo systemctl enable --now isc-dhcp-server
sudo journalctl -u isc-dhcp-server -f

日志是排错的第一工具，一定要养成开了服务就盯日志的习惯。

3.3 交换机/路由器端中继配置：三种厂商命令对照

服务器这边只负责“等着收单播、发IP”，它不关心客户端广播怎么到达自己。让广播“升维”成单播的活儿，是三层交换机干的。下面以核心交换机上配置VLAN10和VLAN20的中继为例，给出三家主流厂商的常见写法。

华为（V200R系列常见写法）：

text复制dhcp enable
interface Vlanif10
    dhcp select relay
    dhcp relay server-ip 192.168.100.254
interface Vlanif20
    dhcp select relay
    dhcp relay server-ip 192.168.100.254

锐捷（命令行风格接近思科）：

text复制interface vlan 10
    ip helper-address 192.168.100.254
interface vlan 20
    ip helper-address 192.168.100.254

华三：

text复制dhcp enable
interface Vlan-interface10
    dhcp select relay
    dhcp relay server-address 192.168.100.254
interface Vlan-interface20
    dhcp select relay
    dhcp relay server-address 192.168.100.254

不同设备型号、系统版本之间命令细节会有差异，比如华为有些版本用dhcp relay server-address，锐捷有些新平台命令也跟老版本不一样。配置前最稳妥的方式是先用?或者display dhcp relay查一下设备支持的关键字，别一上来就盲抄。

另外提醒一点：中继命令是配在三层虚接口（Vlanif / VLAN接口）下的，不是配在物理口下。如果VLAN10对应的是物理接口GE0/0/1，你得先有interface Vlanif10并给这个VLAN接口配好IP地址（比如192.168.10.1），中继才能正常工作。这个逻辑想明白，就不会把命令配错地方。

3.4 验证：不能光看“能上网”，要看租约和报文

配置完，验证方式不能只停留在“诶，终端能拿到IP了”。我建议按下面顺序做一轮完整验证。

在终端上强制重新获取IP。Windows：

bash复制ipconfig /release
ipconfig /renew

Linux：

bash复制sudo dhclient -r eth0
sudo dhclient eth0

然后在服务器上看租约文件：

bash复制cat /var/lib/dhcp/dhcpd.leases

你会看到类似记录：

text复制lease 192.168.10.100 {
    starts 2 2025/06/03 09:31:22;
    ends 3 2025/06/04 09:31:22;
    binding state active;
    next binding state free;
    hardware ethernet 00:0c:29:xx:xx:xx;
}

看到硬件地址、起止时间都对得上，说明整个链路已经通了。但如果你想看得更细，最好在服务器上抓包：

bash复制sudo tcpdump -i eth0 -n port 67 or port 68 -vv

因为有中继，你会在服务器接口上看到Discover报文的源IP是中继设备的接口IP，而不是客户端的0.0.0.0。这是正常现象，别慌，这就是中继已经生效的标志。如果抓包里只有Discover，没有Offer发出去的迹象，那大概率是服务器没有对应网段的subnet声明，或者地址池已经耗尽。日志里会明确写。

3.5 进阶：保留地址和Option自定义

除了普通动态分配，DHCP还能帮你做另一件很实用的事：根据MAC地址固定分配IP。打印机、门禁机、考勤机这类设备，你希望它永远是同一个IP，但又不想去设备上手动配。在dhcpd.conf里加一个host段就行：

text复制host printer-01 {
    hardware ethernet 00:1e:0d:04:12:34;
    fixed-address 192.168.10.50;
}

注意，这里指定的IP必须落在range范围之外，否则会出现服务器一边说“192.168.10.50保留给打印机”，一边又把它分配给普通终端的逻辑冲突。这就是我在3.1里规划静态区的原因——保留地址和动态池必须物理隔离，不靠运气。

如果你以后还想在DHCP里下发其他参数，比如PXE启动需要的next-server、TFTP服务器地址，或者VoIP话机需要的Option 66，套路是一样的：在subnet段里加option行。这也是为什么DHCP在企业里不只是“发IP”的工具，它实际上是一个内网参数统一下发平台，所有基于DHCP Option的自动化都建立在这个基础上。

4. 排错实录：拿不到地址、dhclient报错、地址冲突

4.1 “dhclient is already running”不是DHCP协议的问题，是系统服务打架

很多人搜索“dhclient (10109) is already running - exiting”，以为自己DHCP坏了。看到这个提示，第一反应是“完了，DHCP有问题”。其实这个报错跟网络本身没关系，它告诉你的是：系统上已经有一个dhclient进程在跑了，你又手动启动了一个，所以这个新的直接退出。

这通常发生在Linux主机上。现代Linux发行版一般会有NetworkManager或systemd-networkd这类网络管理工具在后台，它们自己就管理DHCP客户端。如果你习惯性地手动敲sudo dhclient eth0，而系统里已经有一个由NetworkManager拉起的dhclient进程占着eth0，就会出这个提示。

正确排查思路是这样：先用ps -ef | grep dhclient看看系统里到底有多少个dhclient进程。如果发现是NetworkManager在管网络，那就别手动掺和，直接用nmcli：

bash复制sudo nmcli networking off
sudo nmcli networking on

或者用系统的网络重启命令：

bash复制sudo systemctl restart NetworkManager

如果真需要在无NetworkManager的纯systemd-networkd环境里手动获取，先释放再获取：

bash复制sudo dhclient -r eth0
sudo dhclient eth0

千万别动不动就kill -9，把服务托管里的dhclient强杀可能导致网络管理状态混乱。记住一个原则：你的Linux主机上，网络归谁管，就让谁管到底，不要混着来。

4.2 ipconfig显示169.254.x.x：先分清是“没收到”还是“被拒绝”

Windows终端拿不到DHCP地址时，会给自己配一个169.254.x.x的APIPA地址。很多人在这一步直接断定“DHCP服务器挂了”，但169.254只能证明“拿IP失败”，证明不了失败发生在哪个环节。我一般建议按这个顺序排查：

先看服务器日志。journalctl -u isc-dhcp-server里有几类常见信息：

No subnet declaration for 192.168.10.1：说明服务器没配对应网段的subnet，或者giaddr跟配置对不上。这是配置遗漏，直接补subnet。
No free leases：地址池满了。可能是租约太长，也可能是设备数量远超规划。临时扩range，长期考虑调短租约。
Dynamic range 192.168.10.100-200 exhausted：同上，池子耗尽。

再看是不是请求根本没到服务器。在服务器上抓包：

bash复制sudo tcpdump -i eth0 -n port 67 or port 68 -vv

如果刷新好几分钟，服务器一个Discover都没收到，那问题出在中继或者链路上。回交换机上查中继配置有没有生效，VLAN虚接口的IP是否正确。

如果要更精确地定位，可以在终端侧抓包。Windows用Wireshark，Linux用tcpdump，过滤器写port 67 or port 68或者直接bootp。抓包能看到客户端有没有发出Discover、有没有收到Offer。常见的一种诡异情况是：Discover一直在发、Offer也有，但客户端就是拿到169.254。这时候要怀疑是不是服务器回包虽然发到了中继，但中继没有在客户端所在VLAN里广播。重新检查dhcp select relay下有没有配server-ip，以及三层虚接口是否up。

还有一些现成的工具可以模拟DHCP请求，比手动renew方便。Linux上装dhcping，可以用一条命令测试服务器是否响应，比如：

bash复制dhcping -s 192.168.100.254 -c 192.168.10.100 -h 00:0c:29:xx:xx:xx -v

不过工具版本和参数差异比较大，用之前先dhcping -h看看帮助。记住：工具只是帮你在“客户端没插网线”的情况下模拟整个流程，最终判断还是以抓包和服务器日志为准。

4.3 地址冲突与服务器“记忆”：租约表不清理，换了个设备照样分旧IP

有段时间我遇到一个很微妙的问题：一台新电脑插到工位上，能拿到IP，但内网ping不通网关，过一会儿又提示IP冲突。排查了很久，最后发现是DHCP服务器的租约表里还留着旧租约，而旧租约对应的MAC地址和这台新电脑不一样，但IP恰好被服务器从租约表里“翻出来”分配了。严格说，如果ping-check生效，这种情况是可以避免的，但如果服务器曾经异常重启，或者租约文件里有残留，就可能出意外。

生产环境里，如果你要清理租约，有几个层面可以做。Linux服务器上直接删租约文件：

bash复制sudo systemctl stop isc-dhcp-server
sudo rm -f /var/lib/dhcp/dhcpd.leases*
sudo systemctl start isc-dhcp-server

注意，这样会把所有客户端的租约全部打掉，终端续租时会重新拿到IP，如果有打印机、门禁之类的设备绑定了固定IP但放在动态池里，重启后可能短暂不稳。所以这个操作尽量安排在非工作时间，而且动手前先把旧租约文件备份一份。

如果“假DHCP服务器”是交换机本身，比如锐捷交换机上跑了DHCP服务，要释放某个IP，常见的命令是：

text复制show ip dhcp binding
clear ip dhcp binding *

华为交换机上对应的查询和清理命令一般是：

text复制display dhcp server ip-in-use
reset dhcp server ip-in-use

注意，不同系统版本差异极大，有些需要reset ip pool name xxx all，建议先用display dhcp server里的子命令挨个看，再用?扩展命令选项。

4.4 光猫和家用路由器：一个“谁来做DHCP”的家庭场景

家用场景也会遇到类似的“DHCP冲突”，只是很多人没意识到。常见情况是家里光猫开了路由模式，已经自己能拨号、能下发192.168.1.x地址，然后你又在后面接了一个家用路由器。这个路由器如果把WAN口插光猫，默认又开启了DHCP，自己再发一个192.168.0.x的网段，那整个家里的网络就出现了双重NAT加两个DHCP服务器。手机连着路由器的Wi-Fi，拿到的地址可能是路由器下发的，但网关却是光猫的，或者反过来，导致时通时断。

想让“路由器的WiFi由光猫来做DHCP”，做法很简单：把家用路由器切换成AP模式（无线AP/有线中继模式），或者手动关闭它的DHCP服务，然后用LAN口接光猫，而不是用WAN口。这样路由器就纯粹变成一台无线AP，所有IP地址由光猫统一分配。

更重要的是，你不需要记这些细节命令，只需搞清一个原则：同一个二层网络里，只保留一台DHCP服务器。不管是企业还是家庭，这个原则都一样。多台DHCP服务器同时存在又不是故意做容灾的话，大概率会给网络挖坑。

5. 进阶：多网段运营中的DHCP规划与安全

5.1 静态IP和DHCP，不是二选一，而是“定位不同”

有人问“使用静态IP还需要DHCP吗”，我的观点是：两者不是互斥关系，而是按设备身份分工。服务器、网络打印机、监控录像机这类需要“对外提供固定入口”的设备，用静态IP或DHCP保留地址；普通员工终端、访客设备，用DHCP动态分配。

原因很朴素：终端是移动的，今天在A办公室，明天在B会议室，手动配静态IP除了增加工作量，还容易发生IP冲突。而服务器需要固定IP，是为了让其他设备能稳定地找到它。如果服务器也走动态分配，明天换个IP，所有引用它的设备全得跟着改。

真正要避免的不是“用静态还是用DHCP”，而是“静态IP落在DHCP地址池范围内”。所以我在前面反复强调：地址池范围、静态区范围必须严格隔离。你把静态规划放在range之外，再把固定设备绑定MAC，那静态和DHCP就能长期和平共处，谁也不会挤到谁。

5.2 租约时长怎么设计：办公区、访客网络、无线漫游，参数完全不同

租约时间不是一个可以随便填的数字。它直接影响地址池的周转效率。

我的习惯是：

使用场景	default-lease-time	max-lease-time	说明
办公区有线终端	86400（1天）	172800（2天）	设备数量稳定，租约适中减少服务器压力
访客Wi-Fi	300~600秒	1800秒	人流大，短租约能快速回收地址
会议室/临时会场	600~1200秒	3600秒	设备集中且短期，租约调短避免池耗尽
无线办公终端	43200（半天）	86400	兼顾终端频繁漫游和地址回收

无线环境尤其要注意：终端频繁断连、漫游，如果租约太长，离开的终端一直占着地址，地址池会慢慢被“僵尸租约”填满。租约短一点，服务器能更快回收空闲地址。但租约也别短到离谱，每台终端每隔几分钟就要续租一次，DHCP服务器压力会变大，日志也会刷得飞快。找到平衡点才是正路。

5.3 别让任何人插上网线就能发IP：DHCP Snooping + Option 82

DHCP有一个天然的安全弱点：它是基于广播的，客户端无法判断回应它的是真服务器还是假服务器。如果有人在办公室里私自接了一个小路由器，而这个路由器的DHCP没关，那整层楼的终端都可能拿到它下发的错误网关地址，直接被“劫持”到错误的网络出口，轻则断网，重则被中间人截留流量。

对付这个问题的标准动作是开DHCP Snooping。它的思路很简单：在交换机上把连接合法DHCP服务器的接口设为信任端口，其他接口是非信任端口。非信任端口只允许客户端发DHCP Discover/Request，不允许发Offer/Ack。任何从非信任端口进来的DHCP服务器报文，交换机直接扔掉。华为设备上的基础配置类似这样：

text复制dhcp snooping enable
interface GigabitEthernet0/0/1
    dhcp snooping trusted

锐捷、华三的配置思路也相近，都是先把全局的Snooping打开，再标记信任端口。

除了防私搭DHCP服务器，DHCP Snooping还能自动生成一张“IP+MAC+端口+VLAN”的绑定表，这张表可以给防ARP欺骗、IP源防护等功能共用。而Option 82则是在中继场景下，让DHCP请求携带“我从哪个端口、哪个VLAN来”的信息，服务器可以根据这些信息做更细粒度的策略分配。比如同一个网段下的A会议室和B会议室，虽然IP规划相同，但可以通过Option 82区分接入位置，下发不同的网关或QoS策略。

这些安全特性看着高级，配置逻辑却很简单：先打底（开全局Snooping），再声明信任边界（合法DHCP服务器上连的端口），其余端口默认不信。别一上来就把所有端口全部信任，那就等于没有做安全防护。

我在实际配置里还有一个习惯：不管网络大小，都把DHCP租约占用率、冲突日志加入监控。DHCP服务器不只是“发IP”的工具，它更像整个内网的“身份登记处”。一旦这里出了问题，全网的终端都会一起闹罢工。每次改动配置，我都会先保存旧配置文件，再用dhcpd -t做语法检查，最后才重启服务并盯一轮日志。这些流程跑熟了，DHCP和DHCP中继就再也不是玄学，而是你手里最顺手的网络工具之一。