1. 从一台机器抢地址说起DHCP 环境到底要解决什么问题这份记录整理于 2024 年 5 月初起因很朴素——一个几十台设备的小型办公网里新到的几台机器和几台临时接入的测试终端每次迁移工位都要手工改 IP改完还得挨个记在表格里表格很快就乱了。有人把一个本该分配给打印机的地址配到了自己的笔记本上两台设备同时在线整个网段开始间歇性抽风。折腾了两天我决定把地址分配这件事收归到一台专用的 DHCP 服务器上用一套 DHCP 环境统一接管地址、网关、DNS、域名后缀这些参数的下发。DHCP 环境搭建这件事听起来像是装个包、改个配置文件的活儿但真正做过的人都知道坑基本都不在安装那一行命令上而在于网段怎么切、地址池留多少余量、租期设多长、固定绑定的 MAC 从哪儿抄、跨网段的时候中继怎么走、出问题的时候从哪一层开始查。它本质上是一个小型地址管理体系牵扯到协议细节、网络拓扑、运维习惯和故障响应速度。适合谁看刚接手内网运维的朋友、需要给自己机架搭一套稳定地址池的爱好者、以及在做虚拟化和容器网络时被地址管理折磨过的开发者应该都能从里面找到能直接抄的东西。后面我按为什么这么设计—协议里必须搞懂的点—完整可复现的搭建过程—跨网段中继—问题排查—长期运维这个顺序展开配置用的是 Linux 上最常见的那套开源服务同时给一个更轻的替代方案最后的排查表是我自己踩坑攒下来的能省掉不少瞎试的时间。2. 方案选型与前期规划别急着装包先把地址账算明白2.1 手工配地址死在哪三个真实痛点在动手之前值得把痛点说清楚因为痛点决定了你要买什么账。第一个痛点是一致性手工配 IP 的人只要漏填或者填错网关、DNS现象就是能上内网、上不了外网或者域名解析不了但能 ping 通 IP这种故障排查最费时间因为它伪装成网络时好时坏。第二个痛点是冲突没有中心的地址账本时冲突是概率事件而且冲突发生后两台设备都不会主动报错只会在业务上表现为随机断连。第三个痛点是变更成本换一台 DNS 服务器、加一个 NTP 源、给整个网段换个域名后缀手工配的环境里就是一轮全员返工。这三件事叠加起来就是网络总有点小毛病但没人说得清的典型状态。统一用 DHCP 下发之后这三件事被收敛成一次配置变更。地址池是唯一的账本参数是全局的模板改一次全网生效。顺带还能拿到一个附加好处租约记录本身就是一份谁在用哪个地址、什么时候拿的、用的什么 MAC的实时清单排查网络问题时这份清单的价值经常比日志还高。2.2 三种常见实现路线的取舍我实际用过的方案主要有三类各有明确的适用场景选之前先对着表看一眼能少走弯路。方案典型适用场景优势明显短板ISC DHCP经典 dhcpd中小规模内网、需要大量固定绑定和自定义 Option配置直观、文档沉淀多、subnet/host 语义清晰单线程、租约库是文本文件、多实例做高可用比较笨重dnsmasq单网段小环境、路由器/树莓派级别的轻量场景极轻、配置十行搞定、可顺带做本地 DNS 缓存大规模固定绑定维护吃力、审计能力弱KeaISC 新一代需要高可用、需要 REST API 或数据库后端的场景支持租约存数据库、原生主备、接口化管理学习曲线陡、配置是 JSON、迁移要重写我的选择逻辑很实在如果只有一两个网段、固定绑定不超过五十条dnsmasq 完全够用十分钟就能跑起来如果要管理三个以上网段、需要中继、还想要一份干净的租约记录做审计就用 ISC DHCP只有当出现主备不能断这种硬要求或者要把地址分配接进自动化流程里的时候才值得上 Kea。这个顺序很重要很多人一上来就冲 Kea 或者上商业控制器结果是配置复杂度翻了五倍而实际并发需求只有几十台设备。2.3 地址池规划用计算而不是感觉来切规划这一步最容易拍脑袋我见过太多整个 /24 全给地址池然后固定绑定没地方放的配置。比较稳的切法是按用途分段我给一个自己常用的模板网段假设为192.168.10.0/24.1到.19网关、交换机管理地址、带外管理口永远不进地址池.20到.59静态保留区给打印机、监控主机、无线控制器这类设备做固定绑定.60到.99预留给未来扩容或临时隔离区先空着.100到.200动态地址池也就是range语句覆盖的范围.201到.253再留一段动态备用池接入设备暴增时直接扩 range.254广播地址不动.255同理这样做的好处是固定绑定永远有干净的空位不会出现想绑个 IP 发现已经租出去了。动态池容量 101 个地址按办公网常见的同时在位设备数是总设备数的 0.6 到 0.7 倍估算能支撑 140 台左右的终端规模够不够心里立刻有数。租期要单独算。租期的核心矛盾是地址回收速度和续租报文数量之间的平衡。临时会议室、访客网这类流动性大的场景租期压到 2 小时甚至 1 小时地址能快速回流固定工位为主的办公网8 到 12 小时比较合适白天在线、下班后陆续过期第二天重新拿一次续租流量低。默认租期和最大租期要分开设我一般设成default-lease-time 4320012 小时、max-lease-time 8640024 小时让客户端想续多久有上限避免某些客户端申请超长租期把地址长期占住。注意地址池容量千万不能按总人数算要按峰值同时在线设备数。另外无线终端、手机、平板这类设备会频繁进出实际占用比预想的高宁可多留 20% 余量。3. 协议里必须搞懂的三个点报文、租期与 Option3.1 DORA 四步每一步失败对应什么现象DHCP 的交互就是经典的 DORADiscover客户端广播找服务器、Offer服务器给一个候选地址、Request客户端正式申请、Ack服务器确认。这四个报文全部走 UDP服务器监听 67 端口客户端监听 68 端口且前两步和第三步的关键部分都是广播这个细节决定了后面中继和防火墙的配置方式。把四步和故障现象对上号排查效率会高很多。只有 Discover 没有 Offer说明请求没到达服务器或者服务器上没有匹配该网段的声明或者防火墙挡了 67/udp——注意很多默认策略是放行出站、拦截入站服务端收不到广播包是很常见的坑。有 Offer 没有 Request通常是客户端收到了多个 Offer 在挑或者客户端保留了旧地址信息在尝试续租。有 Request 没有 Ack往往是服务器认为这个地址不该给它比如不在池里、或者被别的 host 声明占用了于是直接回 DHCPNAK。还有一个容易忽略的报文是 DHCPDECLINE客户端发现拿到的地址在网络上已经有别的主机在用一般通过免费 ARP 探测发现会主动发 Decline 退回地址服务器随后把这个地址标记为不可用。如果你在租约文件里看到一堆 abandoned 状态基本就是地址冲突或者有人在网络里手工配了池内的 IP这个线索非常直接。3.2 租期续租T1 和 T2 的换算不要记混客户端拿到地址后不是到期才续而是租期的 50% 时发起续租T1这时它发的是单播 DHCPREQUEST 给原来那台服务器到 87.5% 时T2如果还没续上就转为广播向任何能听见的服务器请求。这个机制的意图是分散续租流量避免所有客户端在整点集中刷服务器。举个具体数字租期 12 小时43200 秒T1 就是 6 小时T2 是 10.5 小时。也就是说一台早上 9 点拿到地址的机器下午 3 点会静默续一次续成功就重置计时。如果服务器在 T1 时刻正好挂了客户端会在 T2 时刻转广播此时如果还有备份服务器或者中继指向的服务器活着就能兜住。这个时间窗口是设计 DHCP 高可用时唯一需要关心的参数业务侧完全无感知。实际踩过的坑是租期设得太短比如设成 10 分钟结果无线客户端每次漫游、休眠唤醒都要重新走一遍完整 DORA接入设备的处理压力明显上升而且在某些终端上会表现为锁屏解锁后网络图标转圈十几秒。反过来租期设成 7 天地址池被已离职设备的残留租约占满新设备拿不到地址只能在服务器上手工清租约。所以租期是跟着场景走的没有通用最优值。3.3 Option 字段网关、DNS 之外还有哪些值得下发配置里最常写的三个 Option 是routers默认网关Option 3、domain-name-serversDNSOption 6、subnet-mask选项 1这三个是基础。但实际环境里还有几个很值钱的domain-nameOption 15下发本地域名后缀配合内部 DNS 后同事访问内部系统可以只写主机名ntp-serversOption 42统一时间源日志时间戳对齐的前提排查跨设备问题时这点太重要了broadcast-addressOption 28虽然大多数客户端能自己算出来但写上可以减少某些老设备的兼容问题mtuOption 26在存在隧道或特殊链路的网段里有用注意这个值下发后客户端会照做设错了会引发分片问题vendor-class-identifier配合条件判断给 IP 电话、网络打印机这类设备下发不同的引导服务器地址做统一配置管理时用得上关于 Option 有个实操提醒不同客户端对 Option 的遵守程度差异很大。有的设备会忽略domain-name有的设备拿到ntp-servers也不配置。所以下发完别只看服务器端配置对不对要实际登上一台客户端看它到底收没收到、用没用上。这是配置看起来对但就是不生效最常见的来源。4. 动手搭一套可以直接照抄的 DHCP 服务配置4.1 环境准备与安装我用的是 Linux 服务器两块网卡一块连管理网一块连要服务的终端网段。关键点是服务必须监听在正确的接口上否则服务器会尝试在所有网卡上应答包括管理网那块容易把不该发的地址发出去。先确认系统信息并装包命令以主流发行版的包管理器为准# 确认网卡名称与地址 ip -br addr show # 安装服务端 sudo apt update sudo apt install -y isc-dhcp-server装完之后先别急着改配置看一眼服务状态正常情况下它会因为配置不完整而起不来这是预期行为systemctl status isc-dhcp-server --no-pager然后是指定监听接口这一步很关键配置文件在/etc/default/isc-dhcp-server# 只监听面向终端的网卡示例网卡名为 eth1 INTERFACESv4eth1 INTERFACESv6选这块网卡的理由很直接DHCP 服务器会用自己的接口地址判断该给客户端分配哪个网段的地址如果监听在管理网卡上收到的请求会被匹配到管理网段的声明上去结果就是给终端发了管理网的地址全网直接不通。我见过一次这种事故排查了整整一个下午才想到去看INTERFACESv4。4.2 主配置文件逐段拆解主配置在/etc/dhcp/dhcpd.conf。写之前先备份原文件这几乎是肌肉记忆了sudo cp /etc/dhcp/dhcpd.conf /etc/dhcp/dhcpd.conf.bak.$(date %F)下面是完整的一份可用配置我按段解释每一行的意图# 全局默认值没有单独声明的网段会继承这些 option domain-name corp.internal; option domain-name-servers 192.168.10.2, 192.168.10.3; default-lease-time 43200; max-lease-time 86400; # 声明本服务器是该网络的权威服务器 authoritative; # 日志单独走一个 facility方便过滤 log-facility local7; # 主服务网段 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 subnet-mask 255.255.255.0; option domain-name-servers 192.168.10.2, 192.168.10.3; option broadcast-address 192.168.10.255; option ntp-servers 192.168.10.5; default-lease-time 43200; max-lease-time 86400; }几个关键点值得单独讲。authoritative这一行的作用是告诉服务器这个网段我说了算当客户端申请一个不该给它的地址时服务器会直接回 DHCPNAK让客户端立刻放弃旧地址重新申请而不是沉默。没有这一行客户端在换了网段之后可能会固执地抱着旧地址不放表现就是换了个工位网络死活不通重启也不一定好用。这个坑我在跨楼层搬机位的时候踩过一次印象很深。range的起止值必须落在subnet声明的网段内而且不要和任何host固定绑定的地址重叠重叠的结果是配置检查报错或者绑定静默失效。log-facility local7是为了把 DHCP 日志从系统日志里拎出来配合日志服务单独落一个文件租约发放记录查起来特别快。4.3 固定绑定与多网段声明固定绑定有两个层次如果只是想让某台设备每次拿到同一个地址用host声明host printer-floor3 { hardware ethernet aa:bb:cc:dd:ee:01; fixed-address 192.168.10.30; }如果是一整类设备比如同型号的网络打印机用group包起来会更省事group { option domain-name printer.corp.internal; host printer-a { hardware ethernet aa:bb:cc:dd:ee:02; fixed-address 192.168.10.31; } host printer-b { hardware ethernet aa:bb:cc:dd:ee:03; fixed-address 192.168.10.32; } }多个网段就是在同一个文件里并列多个subnet声明服务器会根据收到请求的那个接口地址或者中继报文里的 giaddr 字段自动匹配对应网段。这一点很重要同一个配置文件可以服务多个网段不需要部署多台服务器前提是这三个网段的流量都能到达这台服务器要么直连要么通过中继。MAC 地址的采集有个小技巧与其让用户自己抄不如先用一个临时放开的地址池让设备上网然后从租约文件/var/lib/dhcp/dhcpd.leases里一次性把 MAC 和设备名捞出来再回头做绑定。文件里的记录长这样lease 192.168.10.123 { starts 3 2024/05/01 09:12:33; ends 3 2024/05/01 21:12:33; binding state active; next binding state free; hardware ethernet aa:bb:cc:dd:ee:11; client-hostname workstation-17; }用grep -E hardware ethernet|client-hostname配合awk整理成表格几十台设备的绑定十分钟就能做完比挨个问用户高效得多。4.4 语法检查、启动与开机自启配置文件写完先做语法检查再重启这是最重要的一条纪律因为配置错误会导致服务起不来而 DHCP 一停网络上所有需要新拿地址的设备立刻受影响如果是无线环境用户会成片掉线# -t 只做配置检查-cf 指定配置文件路径 sudo dhcpd -t -cf /etc/dhcp/dhcpd.conf如果输出里没有报错有些版本会打印 No subnet declaration for...这说明某个接口没有对应声明需要处理就可以启动并设置自启sudo systemctl restart isc-dhcp-server sudo systemctl enable isc-dhcp-server sudo systemctl status isc-dhcp-server --no-pager状态里重点看两件事Active: active (running)和日志里有没有 Listening on LPF/eth1 这类行。如果服务反复重启基本上是配置语法或者是租约文件权限问题租约文件的属主需要是服务运行用户通常装包时会自动处理好手工拷贝过租约文件的话容易出问题。注意如果防火墙开着必须放行服务器侧的 67/udp。指令以ufw为例sudo ufw allow 67/udp。用firewalld的话记得放行dhcp服务或者手动开端口否则现象就是服务器日志干干净净客户端一直转圈。4.5 客户端验证与抓包看真实报文服务端配好不等于能用一定要用真实客户端验证。Linux 客户端# 先释放旧地址再强制重新申请并输出过程 sudo dhclient -r eth0 sudo dhclient -v eth0-v输出里能看到它发了 DISCOVER、收到 OFFER、发了 REQUEST、收到 ACK四个报文齐全就说明链路通了。拿到地址后用ip addr show eth0和ip route确认地址、网关都对再用cat /etc/resolv.conf或对应系统的解析配置确认 DNS 下发成功。Windows 客户端用ipconfig /release和ipconfig /renew配合ipconfig /all看 DHCP 服务器地址和租约获得、过期时间这几个字段最直观。想看清楚到底发生了什么抓包是最靠谱的# 只抓 DHCP 相关端口-vv 输出详细信息 sudo tcpdump -i eth1 -n -vv port 67 or port 68看抓包结果时重点核对三样东西Offer 报文的Your-IP字段是不是预期的地址池范围报文里的DHCP-Message Option 53是不是对应的报文类型giaddr字段是不是全零直连场景应该是零非零说明走了中继需要在服务器上有对应网段的声明。这个习惯救过我很多次尤其是配置看着全对但客户端就是拿不到的时候抓包一眼就能定位是请求没到、还是回复没回去。4.6 轻量替代十行配置跑起来的 dnsmasq如果场景只是单网段、固定绑定不多我一般直接上 dnsmasq安装与配置成本低一个数量级sudo apt install -y dnsmasq配置写到/etc/dnsmasq.conf或者/etc/dnsmasq.d/下的独立文件# 只在这个接口上提供服务 interfaceeth1 # 地址池、掩码与租期 dhcp-range192.168.10.100,192.168.10.200,255.255.255.0,12h # 网关Option 3 dhcp-option3,192.168.10.1 # DNSOption 6 dhcp-option6,192.168.10.2,192.168.10.3 # 固定绑定MAC 与地址一一对应 dhcp-hostaa:bb:cc:dd:ee:01,192.168.10.30,printer-floor3,12h它顺带还能做内部域名解析、做本地 DNS 缓存对小型环境来说一次装好两件事都解决了。但要清楚它的边界固定绑定条目一多配置文件的维护成本会明显上升而且租约的查询和审计能力比 isc-dhcp 弱不少几十条绑定以上我就不会选它了。至于要不要考虑 Kea我的判断标准是有没有高可用要求——如果主服务器停机会导致业务中断且不可接受那才值得投入时间做 JSON 配置和数据库后端否则经典 dhcpd 的稳定性和可维护性更合算。5. 跨网段怎么发地址DHCP 中继的配置要点5.1 中继为什么必须存在giaddr 是关键DHCP 的 Discover 是广播而广播不会跨路由器转发这是协议的天然限制。所以当服务器在一个网段、客户端在另一个网段的时候必须在中间的网关上开 DHCP 中继relay agent由它把广播包转成单播发给服务器同时在报文里填上自己的接口地址也就是giaddr字段。服务器收到后看giaddr就知道该从哪个地址池里挑地址这就是所谓的按中继地址选池。理解这一点之后很多排查就顺了如果服务器日志里出现 no free leases on subnet ...但那个网段的池明明是空的八成是giaddr匹配错了网段如果根本没有日志说明中继压根没把包转过来那问题在网关侧而不是服务器侧。这个分层判断能省掉大量在服务器上瞎翻配置的时间。5.2 中继配置与验证在 Linux 做网关的场景下装中继服务并指明服务器地址和监听接口sudo apt install -y isc-dhcp-relay配置文件/etc/default/isc-dhcp-relay# 指向 DHCP 服务器地址多个用空格分隔 SERVERS192.168.10.250 # 接收客户端请求的接口多个用空格分隔 INTERFACESeth1 # 额外监听选项保持默认即可 OPTIONS改完之后重启中继服务并在服务器侧确认收到带giaddr的报文sudo systemctl restart isc-dhcp-relay # 在服务器上抓包看 giaddr 是否为中继地址 sudo tcpdump -i eth1 -n -vv port 67同时服务器配置里必须有对应网段的subnet声明哪怕那个网段不是直连的。这一点很容易漏声明不是必须直连才能写而是要服务哪个网段就得写哪个网段。5.3 部署中继时的三个注意事项第一服务器到中继之间要能单播回程。中继把请求转成单播服务器把回复也发给中继中继再回给客户端。中间如果有防火墙需要放行服务器向中继方向以及中继向服务器方向的 67/udp双向都要漏一边就是请求能到、回复回不去。第二中继接口要选对。很多网关设备有多块网卡INTERFACES里写的应该是面向客户端的那些不是面向服务器的。写错的表现是中继服务起来了但完全不转发。第三同一个网段别放两个中继指不同服务器除非你明确知道自己在做什么。两台服务器同时应答应同一个网段的请求客户端会挑先到的那个结果就是同一个池子被两家同时分配冲突概率直线上升。如果真的需要冗余让两台服务器分配互不重叠的地址段这是最简单也最不容易出事的做法比任何复杂的高可用方案都实在。6. 问题排查实录从一直转圈到地址冲突6.1 客户端拿不到地址的排查顺序我按信号链路从近到远列了个顺序照着走基本不会漏顺序检查点具体动作典型结论1物理/链路看接口状态、网线灯、无线关联链路根本没起来跟 DHCP 无关2服务是否在跑systemctl status isc-dhcp-server服务崩了先看配置和租约文件3是否监听正确接口ss -lunp | grep :67监听到管理网卡上了4防火墙ufw status/firewall-cmd --list-all67/udp 被拦服务器日志干净5是否收到请求服务器抓包port 67完全收不到问题在中间链路6网段是否声明检查subnet与giaddr是否匹配声明缺失或网段写错7池是否有空位看租约文件条数与range容量池满需扩池或清残留租约8是否被 NAK抓包看 DHCPNAK地址不在池内或绑定了别的 host这张表用过很多次最常命中的其实是第 3 和第 5 行。第 3 行是因为服务器装了多块网卡改配置时忘记同步INTERFACESv4第 5 行是因为交换机上做了端口隔离或者 ACL把广播拦了服务器侧一片安静这时候盯着服务器配置看多久都没用。6.2 地址冲突与废弃租约的处理租约文件里出现abandoned状态的记录说明客户端申请到地址后发现有人在用主动退回了。处理思路分三层先查是谁在池内手工配了静态 IP这类问题必须从管理上禁止再查是不是有虚拟机克隆导致两台机器的 MAC 相同这个在虚拟化环境里非常常见最后确认是否存在多台 DHCP 服务器在分配重叠地址池。清理残留租约要谨慎。我不建议直接用文本编辑器删租约文件正确做法是先停服务再做备份然后处理最后启动sudo systemctl stop isc-dhcp-server sudo cp /var/lib/dhcp/dhcpd.leases /var/lib/dhcp/dhcpd.leases.bak.$(date %F) # 处理完再启动 sudo systemctl start isc-dhcp-server如果想加速过期租约回收更稳妥的手段是把租期调短让它自然过期而不是手工清文件。一个已经离职设备的租约最迟一个max-lease-time之后就会释放前提是服务器时间准确。顺带提一句服务器时间漂移会导致租约判断异常ntp-servers那行 Option 不只是给客户端方便服务器自己也得把时间同步好。6.3 日志里的报错对照把常见报错和真实原因对齐能省掉很多猜测日志关键字真实含义处理方向no free leases on subnet该网段地址池耗尽扩range或缩短租期或清理废弃租约no subnet declaration for ethX某接口找不到匹配网段补该网段subnet声明或关掉该接口监听DHCPDISCOVER from ... via ...: network ...: no free leases中继地址匹配到了某个网段但没有可用地址检查该网段池容量与giaddr是否对应DHCPNAK on ... to ...拒绝了客户端申请地址不在池内、或已被host绑定给别的 MACalready active lease ... but the binding state is not active租约库状态不一致检查是否有手工改过租约文件重启服务Failover peer ... : I move from normal to communications-interrupted高可用对端失联检查两台之间的网络和 519/udp 端口日志过滤我用这条命令只保留租约发放和错误journalctl -u isc-dhcp-server --since 1 hour ago | grep -Ei dhcp(discover|request|ack|nak)|error|warn6.4 一个很隐蔽的坑虚拟机克隆导致 MAC 冲突这个坑值得单独说因为在虚拟化环境里它出现得非常频繁而且现象极具迷惑性——两台机器轮流掉线每次掉线几十秒后又自己恢复用户描述是网络一会有一会没有。原因是两台虚拟机的 MAC 相同DHCP 服务器认为它们是同一台设备于是给它们发同一个 IP两边互相抢占。排查方法很土但有效把租约文件按 MAC 排一次序看有没有同一个 MAC 对应多条不同地址的记录同时让用户把两台机器的 MAC 报上来对比。根治办法是克隆之后立刻重新生成 MAC别用复制虚拟机的默认选项。我给自己的规矩是新建虚拟机模板时就把 MAC 随机化写进流程里宁可多一步也别让这个坑再出现一次。7. 长期运维防私接、做备份、盯水位7.1 防非法 DHCP 与地址盗用内网里最怕的不是服务器故障而是有人随手插了个带 DHCP 功能的家用路由器把整个网段的地址分配权抢走。这类设备的默认池往往和你的池重叠后果是全段地址混乱而且由于它还在做 NAT用户的流量路径被悄悄改掉排查起来极其痛苦。网络设备侧的手段是 DHCP Snooping在接入交换机上启用把上联口和服务器所在端口设为信任口其余接入端口设为非信任口非信任口上收到的 DHCP Offer 一律丢弃。这样即使有人私接设备也发不出有效的地址分配。同时可以配合 IP Source Guard 或者端口 MAC 绑定限制非授权 MAC 使用固定地址。这些配置在网管型交换机上都有值得花半小时配上收益远大于成本。服务器侧能做的补充是绑定关键设备的 MAC并对关键地址段设置排除。至于地址盗用最实用的手段是给关键设备做固定绑定并定期从租约文件里比对实际在线设备可以用 ARP 表交叉验证发现池内地址被非租约设备占用就及时处理。7.2 租约备份与迁移租约文件是这套环境的全部状态备份策略我定得很简单每天定时拷一份带日期的副本保留最近 30 天同时在做任何配置变更之前手动再打一个快照。变更加备份这是唯一能保证出问题时十分钟内回滚的做法。迁移到新服务器时把配置文件、租约文件、以及INTERFACESv4这三样带过去就行注意租约文件的属主和权限要跟新系统上服务运行用户一致否则服务可能起不来。迁移前先在测试网段验证一次完整流程别在业务网段上直接切。部门内部环境我一般会先在备用网段跑一天确认客户端能正常拿地址、续租、跨网段也能拿到正确地址再切主网段。7.3 容量水位与监控池子满了是渐进过程等用户报障就晚了。我给自己的监控加了两条一是定时统计租约文件里binding state active的条数除以池容量超过 75% 就提醒二是定时检查服务进程和端口ss -lunp | grep :67有输出才算健康。这两条加起来不到二十行脚本但能提前发现绝大多数问题。容量规划上有个经验值动态池使用率长期超过 70%就该考虑扩池或者缩短租期了如果连续一个月使用率都在 90% 以上说明规划本身就偏紧扩池的同时要顺手检查一下有没有大量废弃租约没回收。另外每次做网段调整、加新设备类型、或者上新一批终端之前都值得重新算一遍池子容量别让配置自然老化。我在实际使用中最深的一点体会是DHCP 这套东西配起来快但它承载的是所有人能不能上网这件事所以配置变更的心理门槛要比普通服务高得多。我的做法是所有变更先在测试网段验证dhcpd -t检查配置备份租约和配置然后挑在业务低谷改改完盯十分钟日志。这四步做下来一年多里因为 DHCP 变更引发的大面积故障是零次而在此之前光是改完配置忘了检查语法导致服务起不来这一类问题就出现过不止一次。