先交代一个背景。去年我接手维护的一套办公网络设备规模从几十台一路涨到一百多台网管员的日常工作慢慢变成了一句话改IP。共享文档里维护着一张静态IP登记表但总有人不按表填打印机掉线、监控连不上、新同事的电脑上不去网问题一个接一个。真正让我下决心动手的是某个周一早上连续三台电脑弹“IP地址冲突”查了半天才发现是有人手填了一个已经被占用的地址。后来我把整个网络改成由一台Linux服务器统一分配地址也就是标题里说的“配置DHCP服务器”。这篇文章把我从原理、选型到配置、排错的全过程记录下来给同样被网段规划折磨的人一份可以照着抄的作业。1. 家用路由器免费送我为什么还要自建DHCP服务器1.1 一台路由器撑起百人网络的代价很多人一听“配置DHCP服务器”就觉得没必要因为家用路由器、企业级路由器、甚至一些二层交换机都自带DHCP功能。表面上确实“能用”但等你设备超过几十台或者网络里出现了多个VLAN、多个网段路由器自带的那点分配能力就完全不够看了。我接手时的网络就是这么个状态。路由器地址池是默认的100到199一共一百个地址设备一多就不够分。有人手动填IP来绕过地址池限制结果把网关地址占了有人把打印机IP改了没告诉别人所有打印任务全部丢失路由器上的租约列表只有“已分配”“空闲”这种简单状态连“哪个地址曾经被谁用过”都查不到。最要命的是它没有任何日志出问题只能靠猜。我自己搭DHCP服务器最直接的动机就是三个字可维护。我想要的不只是“把地址分出去”而是“我知道这些地址是怎么分出去的、现在分给谁了、出了问题能不能查到”。1.2 静态IP的“伪稳定”能通不代表可维护团队规模不大的时候很多人都会选择静态IP。每台机器填一个固定地址一眼看去“清清楚楚”似乎也没有DHCP什么事。但这种“稳定”是有代价的代价大小取决于你的网络什么时候需要变化。换一次网关、加一台DNS服务器、调整子网划分静态IP环境下的工作量是灾难级的。一百多台设备你需要一台一台远程登录或者亲自走到面前去改。有人出差半年回来忘了更新配置还拿着旧参数上不了网又不知道问题在哪。我说的不是理论而是真实发生过的情况——那时候办公室里最忙的不是业务人员是那个拿着笔记本到处跑着改网络参数的同事。DHCP的另一个隐形价值是标准化。客户机开机、拿到参数、入网整个过程不需要人干预。网关变了服务器改一行配置客户端过段时间自己续租就能拿到新网关。DNS变了同样只需要改服务端配置。这种“参数集中下发”的能力是静态IP永远给不了的。1.3 自建DHCP服务器到底能换来什么把话说明白自建DHCP服务器不是因为它“更高级”而是因为它能解决以下几个具体问题地址池规划可控你可以任意划分网段、设置保留地址、限定分配范围而不是用路由器里写死的那一段。租约可查可审计每一笔分配都有记录哪个MAC在什么时间拿到了哪个IP全在租约文件里能追溯。策略可下发除了IP和网关还能同时下发DNS、域名、NTP服务器甚至PXE启动参数。跨网段分配配合三层设备的中继功能一台服务器可以为多个VLAN服务不需要每个网段单独放一台。高可用可设计DHCP服务本身支持故障转移可以做到主备切换而不是“这台挂了整个网断”。如果你只是家里七八台设备我完全不建议折腾这件事。但如果你的网络里有几十台、上百台设备或者你已经在规划多VLAN那自建DHCP服务器就不是可选项而是刚需。2. 动手前的必修课DHCP四次握手背后的租约逻辑2.1 Discover、Offer、Request、Ack 一次会话到底发生了什么配置DHCP之前我建议先把它的工作流程理清楚。很多人配置失败问题恰恰出在“只知道填地址池不理解分配过程”。DHCP最基本的交互是四步握手。客户端开机或者网卡启用后会先发一个DHCP Discover广播意思是“我在这条链路上有没有人给我分配一个地址”。DHCP服务器收到之后会回应一个DHCP Offer里面携带一个建议的IP地址和相关参数。客户端如果接受就发一个DHCP Request再广播一次等于说“我就要这个地址”。服务器最后回一个DHCP Ack确认这单交易完成。这里有一个容易被忽略的细节为什么Request阶段还是广播。因为客户端可能同时收到多个服务器的Offer它要告诉所有服务器“我选了A的那份其他B、C可以收回了”。如果这里用单播其他服务器就不知道客户端已经选了别人就会一直保留这个地址造成地址浪费。所以这个“广播确认”不是多余的它本身就是协议设计的一部分。如果服务器认为客户端不该用这个地址或者地址已经被占用它不会回Ack而是回一个DHCP NAK。客户端收到NAK之后只能老实回到Discover阶段重新申请。这个NAK行为在后面多VLAN排错时非常关键下面会专门讲。2.2 租约不是“到期就断网”T1和T2才是关键IP地址不是永久分配的这叫“租约”lease。但很多人对租约的理解是错的觉得“到期了我就断网要重新申请”。真实情况复杂一点。每份租约有两个续租时间点分别叫T1和T2。T1是租约时间走到50%的时刻客户端会尝试向当初分配地址的那台服务器发单播续租请求如果成功服务器回复新的Ack租约时间重新起算。如果T1时联系不上原服务器客户端不会坐以待毙等到T2也就是租约时间的87.5%它会改用广播方式发续租请求让链路上任何一台DHCP服务器都能响应。到了租约时间100%还没续上客户端才会放弃这个地址重新从Discover开始。我举个例子。default-lease-time设成86400秒也就是24小时。那么T1大约是第12小时T2大约是第21小时。前12小时客户端用原服务器续租21小时之后广播求援24小时后还不行就重来。理解了这一点你就能明白为什么租约时间不能随便拍脑袋设置——太短会让网络里到处是广播续租太长又会让地址变动非常迟缓。办公网络我建议默认租约时间设为24小时最长租约时间设7天。这样日常设备每天都会续租一次服务器能及时发现失联设备出差回来的设备也能在7天内继续用旧地址不至于换个地方就重新分配。2.3 为什么配置里一定要写 authoritative这个参数是我第一次配置时完全没注意的东西但后来它坑了我一整个上午。DHCP服务器分“权威”和“非权威”两种态度。如果不写authoritative服务器收到一个它不认识的Request请求时会选择沉默不回任何包。这在某些场景下是保护机制但在你自己搭建的服务器上这反而是大坑。举个例子。你有一台服务器管理10.10.10.0/24网段网络里某个客户端突然从别的网段拿了个旧地址然后跑到这个网段里来续租。非权威模式下服务器不搭理它客户端就一直傻等直到超时重来期间网络不可用。而权威模式下服务器会直接对这个请求回一个DHCP NAK客户端收到后立刻明白“我得重新申请”马上开始新的Discover流程几秒钟就能恢复正常。所以我给所有初次配置dhcpd的人都会强调一句配置里务必写authoritative;除非你有明确的特殊需求。后面排错部分提到的很多“客户端卡在获取IP”问题其实都和这一行有关。3. 选型与安装我为什么选择dhcpd以及环境准备3.1 三种常用DHCP服务的真实差异Linux环境下常见的DHCP服务大致有三种选型之前先看清楚差异。服务特点适合场景局限性dhcpd经典实现配置成熟功能全面大多数企业办公网、多VLAN场景配置语法相对传统需要学习成本dnsmasq轻量配置简单内置DNS转发小规模、几十台内、个人实验室租约管理简单无真正的failover机制Kea新一代架构JSON配置支持高并发大型园区、运营商级环境配置思路和dhcpd完全不同上手成本高我最后选了dhcpd原因是它最“标准”。网上绝大多数DHCP教程、排错经验都基于这一套服务你碰到问题能搜到的答案更多。另外它支持failover故障转移这一点对需要高可用的办公网很重要。dnsmasq虽然省事但规模一上来容易吃力而且在多VLAN和复杂策略上支持偏弱。3.2 安装前的网卡规划一个最容易踩的坑安装之前先规划好服务器的网络角色。DHCP服务器自身必须使用静态IP绝对不能靠DHCP自己给自己分配地址——这是个逻辑悖论装完网卡拿不到地址直接翻车。同时要注意网卡选择。如果服务器上有多个网卡DHCP服务默认会监听所有接口这可能导致配置错误。Debian系的发行版里安装完isc-dhcp-server之后有个配置文件叫/etc/default/isc-dhcp-server你需要在INTERFACESv4那里指定监听哪块网卡比如INTERFACESv4eth0。RHEL系发行版对应的是/etc/sysconfig/dhcpd里面通过DHCPDARGSeth0来指定。这一步很容易漏漏了的后果就是服务起不来或者起来之后监听在错误的接口上日志里一堆“not configured to listen on”的报错。安装命令本身不复杂。Debian系执行apt install isc-dhcp-serverRHEL系执行yum install dhcp安装后服务名都叫dhcpd。3.3 最小可运行配置先把服务跑起来再谈精细化装好之后别急着写完整配置。我习惯先写一份最小配置确认服务能启动、客户端能拿到IP再逐项加上参数。这样出问题时可以缩小排查范围。一份最小配置长这样default-lease-time 86400; max-lease-time 604800; authoritative; subnet 10.10.10.0 netmask 255.255.255.0 { range 10.10.10.100 10.10.10.200; option routers 10.10.10.1; }改完之后先做语法检查这个习惯我从一开始就养成了每次改配置都必须跑一遍dhcpd -t语法没问题就启动服务然后在客户端网卡上执行dhclient -v eth0Windows下是ipconfig /renew能看到分配过程才算第一步成功。如果这里就失败多半是网卡监听、防火墙UDP 67端口、配置文件路径这三件事别急着往下配多VLAN。4. 手把手配置全局参数、地址池、保留地址的完整示例4.1 从零写一份靠谱的dhcpd.conf下面这份配置是一个比较完整的办公网示例。我把它拆开讲每一行的作用都说清楚这样你拿去改的时候知道哪些是不能动的骨架哪些是可调整的参数。ddns-update-style none; authoritative; log-facility local7; option domain-name corp.local; option domain-name-servers 10.10.10.53, 8.8.8.8; default-lease-time 86400; max-lease-time 604800; subnet 10.10.10.0 netmask 255.255.255.0 { option routers 10.10.10.1; option broadcast-address 10.10.10.255; option domain-name-servers 10.10.10.53; range 10.10.10.100 10.10.10.200; host printer-1 { hardware ethernet 00:11:22:33:44:55; fixed-address 10.10.10.50; } host dev-server { hardware ethernet aa:bb:cc:dd:ee:ff; fixed-address 10.10.10.60; } }ddns-update-style none;是关闭动态DNS更新。除非你专门配置了和DNS服务器的联动密钥否则这一行必须写成none不然启动时会有一堆关于DDNS的报错。log-facility local7用来把DHCP日志单独打到指定的syslog设备方便后续排查。option domain-name和option domain-name-servers是给客户端下发域名后缀和DNS服务器。这里我把内网DNS放在了第一个位置客户端解析内网主机名时会先问内网DNS速度更快。第二个地址填公共DNS防止内网DNS故障时连外网解析也全部失效。4.2 地址池分段与保留地址先规划再分配很多人配置DHCP时最大的问题是直接拿整个网段当地址池。比如10.10.10.0/24范围写成10.10.10.1 10.10.10.254把所有可用地址全塞进去。这样做表面省事实际埋雷。我更习惯把网段分成几段。第一段是固定设备区比如1到99专门给路由器、交换机、打印机、服务器这些需要稳定的设备使用。这些地址不写进range。第二段是动态分配区比如100到200给普通办公电脑、手机、临时设备。第三段是预留区比如201到254留给未来扩容或者特定项目临时使用。固定设备虽然不在range里但我仍然会给它们写host保留段。原因是服务器不知道哪些地址被手动配置了如果这些地址落在range内它可能分配出去然后和固定设备冲突。所以凡是不希望被自动分配的地址要么你手工指定到host表里要么就不要放在range内。这个习惯能在源头上消灭大量IP冲突问题。4.3 参数怎么定租约时间、DNS、网关必须算清楚很多人直接抄网上的配置租约时间跟着默认值走也不管合不合适。我建议你结合自己网络的实际情况来定。办公网络的default-lease-time我习惯设86400也就是24小时。理由前面说过T1在12小时足够适应大部分早出晚归的办公节奏。max-lease-time设6048007天是为了照顾那些出差回来的设备让它们的旧地址还能续上。如果是访客WiFi这类临时网络租约时间建议大幅缩短比如30分钟到2小时避免访客设备占用地址池太久。option routers就是网关地址这个没什么好说的。但要注意option broadcast-address不是所有场景都需要显式写。大多数情况下网段广播地址可以由子网掩码自动算出来但显式写出来能避免某些客户端实现计算不一致的问题。关于option ntp-servers如果公司有内网时间服务器建议一并下发。很多人忽略这个参数结果设备时间全靠外网NTP一旦外网受限日志时间戳全部错乱后续排错会非常痛苦。4.4 启动验证别急着改更多参数先把基础服务跑稳配置文件写好后按我的习惯步骤是固定的dhcpd -t systemctl restart dhcpd systemctl status dhcpd如果服务正常再看日志。Debian系日志一般在/var/log/syslogRHEL系在/var/log/messages。用grep dhcpd /var/log/syslog搜索能看到每个请求的处理记录。我每次改完配置都会抓一次日志确认客户端真实拿到了地址而不是只在服务端看着“运行正常”。如果你手头没有现成的测试客户端命令行里用dhclient -v eth0强制续租一次输出会直接显示Discover、Offer、Request、Ack四个阶段一眼就能看出协议走到哪一步断掉。5. 多VLAN场景DHCP中继配置与跨网段地址分配的坑5.1 为什么VLAN一多DHCP服务器就“听不见”广播网络规模一大很多人会按部门或者用途划分VLAN。这时候你会发现一个现象DHCP服务器明明运行正常但其他VLAN里的客户端就是拿不到地址。原因很简单。DHCP Discover是广播包而路由器默认会隔离广播域。VLAN本质上就是广播域广播包只在同一个VLAN内传播不会跨VLAN转发。DHCP服务器挂在VLAN 10VLAN 20里的客户端广播请求到了三层设备就停了服务器根本听不见自然不会回包。要让服务器为多个VLAN服务有两种思路。一种是在每个VLAN里各放一台DHCP服务器维护成本高、地址池重复管理显然不划算。另一种是在三层设备上启用DHCP中继relay转发跨网段的DHCP请求。后者更合理一台DHCP服务器就能覆盖所有VLAN。5.2 中继配置要点与常见错误在三层交换机上配置DHCP中继核心命令是ip helper-address。以常见的交换机为例你要在每一个需要分配地址的VLAN接口上都指向DHCP服务器的地址interface vlan 10 ip address 10.10.10.1 255.255.255.0 ip helper-address 10.10.0.10 interface vlan 20 ip address 10.10.20.1 255.255.255.0 ip helper-address 10.10.0.10这里的逻辑是VLAN 20的客户端广播请求到达交换机后交换机把这个广播转成单播发给10.10.0.10这台DHCP服务器同时在报文的giaddr字段里标注“这个请求是来自10.10.20.0/24网段”。DHCP服务器看到giaddr为10.10.20.1就知道应该从subnet 10.10.20.0 netmask 255.255.255.0对应的配置块里选地址。所以服务器端必须为每个VLAN配置对应的subnet块。中继配置好了但dhcpd.conf里没有对应网段服务器收到请求后只会默默丢弃客户端照样拿不到地址。这个问题下面排错章节还会详细展开因为它是多VLAN环境里最常被忽视的一环。5.3 常见中继故障现象对照我自己调试多VLAN时整理过一个错误对照表给你参考。现象可能原因排查方向其他VLAN拿不到IP本VLAN正常中继未配置或配置到了错误接口检查VLAN接口下的helper-address服务器日志出现network not found服务器端缺少对应subnet配置检查dhcpd.conf是否包含该网段客户端一直提示“找不到DHCP服务器”请求根本没有到达服务器抓包确认UDP 67端口是否收到能拿到IP但无法上网网关或VLAN配置错误检查option routers和三层设备路由表这里有个容易犯的经验主义错误看到客户端报“DHCP服务器不可达”第一反应是服务器挂了。实际上服务器完全正常问题往往出在中继路径上。先抓包确认请求到底到没到服务器再判断是服务端问题还是链路问题。5.4 同一网段出现多个DHCP服务器的冲突隐患多VLAN环境下有时会出现“一个网段里既有自建服务器又有路由器自带DHCP”的情况。比如路由器默认开着DHCP没关你又自己搭了一台两台服务器同时应答客户端只会选择先收到的那份Offer。先到先得的后果就是一部分设备从路由器那边拿了网关一部分设备从自建服务器这边拿网关整个网段乱成一锅粥。我的建议是任何一个网段里只保留一台权威的DHCP服务器其他一律关闭。如果确实需要多台服务器做冗余不要简单跑两个相同配置的进程要用后面讲到的failover机制否则就会出现更隐蔽的地址冲突问题。6. 高可用failover配置以及那些年我见过的“伪高可用”6.1 两台DHCP同时跑不叫高可用叫事故现场说到高可用很多人第一个念头是“再起一台服务器不就行了”。如果只是各自运行一份相同的配置你得到的不是高可用而是一个定时炸弹。我自己就在类似场景上踩过坑。当时为了省事有人拿两台服务器跑了同一个DHCP地址池完全一样。平时看着没事一旦其中一台先给某客户端分配了10.10.10.150另一台不知道这个地址已经分配出去过一会儿又把同一个地址给了别的设备。结果就是IP冲突时好时坏排查起来极其痛苦。后来看日志才发现两台服务器的租约记录完全对不上客户端在两边反复横跳。DHCP高可用的核心不是“两台机器都在跑”而是“两台机器对地址分配状态达成一致”。只有租约信息能互相同步才能真正实现故障转移。6.2 failover的配置骨架dhcpd本身支持failover机制主备服务器会持续同步租约状态。所有地址池被划分为两个部分主服务器负责一部分备服务器负责另一部分正常情况下各分各的互不冲突当一台服务器故障时另一台自动接管全部或其他部分地址的分配。以最简单的双机配置为例。主服务器的failover配置大致是这样的failover peer office-dhcp { primary; address 10.10.0.10; port 519; peer address 10.10.0.11; peer port 520; max-response-delay 60; max-unacked-updates 10; mclt 600; split 128; load balance max seconds 3; }备服务器只需要把primary改成secondary本机地址和peer地址对调其他核心参数保持一致。然后在子网配置里地址池不再直接写在subnet大括号里而是放进pool段subnet 10.10.10.0 netmask 255.255.255.0 { pool { failover peer office-dhcp; range 10.10.10.100 10.10.10.200; } }split 128表示两个服务器分配地址的权重各占一半你可以改成其他值来调整负载比例。mclt是“最大客户端租约时间”的缩写主备切换后客户端地址的延续时间靠它兜底。这些参数初次接触会觉得绕但你先按标准配置跑熟再去调细节也不迟。6.3 验证failover切换别等服务挂了才试配置完failover之后必须主动验证不能指望故障真的来了才发现是坏的。我的测试流程很简单先看日志确认主备之间建立了连接。日志里会出现failover peer状态相关的记录看到两个服务器处于正常通信状态说明同步链路是通的。然后人为停掉主服务器的DHCP服务在客户端上执行一次dhclient -r再dhclient -v正常的话备用服务器能在几秒内完成地址分配。再把主服务器拉起来观察它能否重新和备用服务器同步租约数据。我习惯把这一套测试写成文档每次变更配置后都跑一遍。高可用这种基础设施等出事才想起来验证代价往往很难接受。6.4 如果你暂时用不了failover还有两条退路不是所有人都能一步到位搞双机。如果你只有一台服务器但担心单点故障两个折中做法值得考虑。第一利用虚拟化平台的漂移能力把DHCP服务器做成虚拟机借助虚拟机高可用功能实现故障迁移。这种方式不需要配置DHCP本身的failover但切换时间取决于虚拟化平台的检测速度不是秒级。第二把地址池拆分主备两台服务器各自管理不重叠的网段客户端在哪个VLAN就用哪台服务器。这样至少避免了两台机器分配同一地址的冲突代价是故障时无法接管对方网段属于“伪冗余”只能应付部分场景。7. 上线后的第一周五种典型故障的排查链路7.1 客户端拿到169.254开头的地址问题通常不在服务端很多人的第一反应是“服务器挂了”但我要说的是169.254开头的地址恰恰说明客户端根本没有收到任何DHCP响应。这只是一个结果不是原因。我的排查习惯是从客户端往服务器方向一层一层走而不是一开始就怀疑服务端配置。先用systemctl status dhcpd确认服务进程是活着的再看端口监听ss -lunp | grep :67端口在监听就下到客户端侧抓包在出问题的网卡上执行tcpdump -i eth0 port 67 or port 68 -nn如果这里能看到客户端的Discover反复重发但没有任何Offer回包说明请求要么没到服务器要么到了服务器但被静默丢弃。前者查链路、中继、防火墙后者查服务端配置和日志。如果连Discover都看不到问题就不在DHCP而在客户端网卡、交换机端口或者VLAN划分上。7.2 租约文件权限导致的诡异掉线有一个问题特别隐蔽就是租约文件权限不对。dhcpd默认以dhcpd用户运行它必须能读写租约文件。如果租约文件权限被改动或者目录被占用服务能启动但每当要写新租约时就会失败表现是“一部分设备能拿到IP一部分设备间歇性失败”。日志里会明确出现类似这样的记录无法打开租约文件进行写入。解决办法很简单把租约文件的所有者改回来chown dhcpd:dhcpd /var/lib/dhcp/dhcpd.leases chmod 644 /var/lib/dhcp/dhcpd.leases别小看这种问题。我遇到过好几次莫名其妙“过几天掉线一次”的情况最后定位到都是租约文件在系统日志轮转时权限被改了。基础权限问题往往比高级配置问题更容易被忽略。7.3 用抓包还原一条“被吃掉”的DHCP请求多VLAN里最常见的故障是服务器日志里出现这样一行DHCPDISCOVER from 00:11:22:33:44:55 via 10.10.20.1: network 10.10.20.0/24 not found这行日志非常直白请求从中继器转发了过来携带的giaddr是10.10.20.1但服务器配置里没有10.10.20.0/24这个网段。服务器不知道该从哪个地址池选地址只能丢弃。客户端那边自然一直卡在Discover重发状态。遇到这种情况解决方式不是调中继也不是重启服务而是回到dhcpd.conf补上对应的subnet配置。看到“network not found”的时候不要再怀疑链路和防火墙了问题就在配置文件里。7.4 DHCP服务器把正在被使用的地址分了出去这是另一种让人头疼的情况。网络里有人手动配置了一台设备的IP为10.10.10.150但DHCP服务器不知道这个地址被占用了仍然把同一个地址分配给了另一台客户端。结果就是地址冲突两台设备轮流掉线。dhcpd在较新版本里支持ping-check参数。在subnet段里加上一行ping-check true;服务器在分配地址之前会先发一个ICMP探测请求如果发现这个IP有人响应就跳过这个地址换下一个。代价是每次分配会多一点延迟但对办公网络来说完全值得。不过要明白ping-check只能减少冲突不能根治冲突。根治的办法还是回到规划把所有手动配置的固定设备登记进host表让服务器知道这些地址不能动。7.5 用租约文件还原一场“地址被抢”事故最后说一个我自己觉得特别有用的排查技巧。当出现设备频繁掉线、ARP表里IP地址在多个MAC之间横跳的时候不要只看实时状态去翻租约文件。租约文件里记录了每个IP地址当前的租约归属包括MAC地址、IP、租约开始和结束时间。把出事设备的MAC提出来在租约文件里搜一下你能看到这台设备的租约时间线什么时候拿到地址、什么时候续租、什么时候地址被其他MAC抢走。grep -A5 10.10.10.150 /var/lib/dhcp/dhcpd.leases结合交换机上的MAC地址表还能进一步定位到设备接在哪个物理端口。整个链路下来我不光能找到“是谁抢了地址”还能找到“它接在哪”处理问题就不再是盲猜了。8. 安全加固与日常巡检别让DHCP变成网络的薄弱点8.1 交换机配合做DHCP Snooping防私搭DHCPDHCP服务上线后安全层面最现实的风险是有人拿一台家用路由器或者小交换机随手插到办公网里自己开一个DHCP。这种“私搭DHCP服务器”会把错误的网关和DNS下发到客户端轻则部分设备上不了网重则全网DNS被劫持数据被引流到错误的方向。对付这个问题的标准手段是DHCP Snooping。思路并不复杂交换机把端口分为信任端口和非信任端口。连接合法DHCP服务器的端口配置为信任端口其他所有终端端口是非信任端口。非信任端口只允许客户端发DHCP Discover凡是试图从非信任端口发出DHCP Offer、Ack报文交换机直接丢弃。以主流交换机为例配置思路大致是ip dhcp snooping ip dhcp snooping vlan 10,20 interface Ethernet0/1 ip dhcp snooping trust不同厂商的具体命令有差异但核心就这三步全局开启、指定VLAN、标记信任端口。这部分我强烈建议你在网络设备上落实否则你的DHCP服务器配置得再完善一个随手插进来的小路由器就能让整个规划白费。8.2 巡检清单地址池余量、租约文件、日志缺一不可DHCP服务器不是配完就能一直不管的。我给自己定了一个固定巡检周期每次花不到十分钟。第一是看地址池余量。租约文件和当前活动租约能帮你判断是否有耗尽风险。一个简单的统计方法是用awk过滤租约文件里的IP段粗略估算活跃租约数量。地址池使用率长期超过80%就要考虑扩大range或者清理残留租约了。第二是看日志里有没有规律性报错。比如DHCP NAK次数突然变多通常意味着有人私搭了DHCP或者静态IP规划出了冲突。日志不会说谎它比任何监控工具都更接近真相。第三是检查服务端时间同步。DHCP租约时间依赖服务器时钟如果服务器时间偏差大租约的起止时间会错乱客户端续租行为也会变得异常。顺手配置时间同步属于成本极低、收益极高的基础维护。8.3 一个顺带的收获PXE网络装机也能顺理成章自建DHCP服务器还有一个隐藏收益就是给后续的PXE网络装机留好了入口。PXE启动本质上靠DHCP下发启动文件位置服务器只要在配置里加上对应的启动参数比如指定TFTP服务器地址和启动文件名同一网段的机器重启后就能直接从网络引导系统镜像。我最初纯粹为了解决IP冲突问题才搭的DHCP后来发现网络装机、批量系统初始化这些工作都因为它而变得顺畅了。基础设施就是这样你把它做扎实了很多后续工作会跟着受益。最后分享一点个人体会配置DHCP服务器这件事最难的往往不是那几行配置而是对整个分配逻辑的透彻理解。你只有明白了Discover、Offer、Request、Ack背后的意图理解了租约续期的T1/T2机制配置起来才不会是“照抄网上的模板”。每次改完配置养成跑语法检查、看日志、抓包确认的习惯这套网络就能长期稳定地运行下去。