企业官网建设流程全解析

开头

搞网络的谁没被DHCP折磨过。新设备接上交换机，等了几秒拿不到IP，用户一句“网坏了”丢过来，你连登录交换机的心思都有了。这种时候你就知道，DHCP这玩意平时默默无闻，一旦出问题，全办公室的人都盯着你的命令行窗口。最近好几个读者问我华为交换机上的DHCP配置、跨网段怎么中继、虚拟机拿不到地址、内网已经有一台物理DHCP服务器又要怎么配合……问得多了，我索性把这段时间折腾DHCP的经验整理成一篇完整的实操笔记，从原理到配置到排障，一次讲透。

这篇内容适合刚接手网络设备的运维新人，也适合被“虚拟机拿不到IP”“跨VLAN不发地址”这类问题困住的同行。我会把DHCP的交互流程、华为交换机上的地址池配置、中继配置、虚拟化环境里的vNIC相关坑、以及内网已有物理DHCP服务器时的交换机配合方式全部过一遍。文章中涉及的命令以华为VRP平台为主，但思路对思科、H3C、锐捷同样适用。

1. 先把DHCP的“心跳”弄明白：DORA不是四个字母那么简单

1.1 DISCOVER到ACK：一次完整地址发放的全过程

很多教程喜欢甩出一句“DHCP走的是DORA四步过程”，然后就没下文了。DORA确实是四个步骤的缩写：Discover、Offer、Request、Ack。但真正干活的时候，你知道每一步客户端和服务器各自做了什么、报文是广播还是单播、端口是多少，排障思路才立得住。

客户端接入网络时，它自己也不知道谁的网段里有什么服务器，所以第一步DISCOVER只能是广播，源地址是0.0.0.0，目的地址是255.255.255.255，目标端口是UDP 67。交换机收到这个广播会怎么做？默认情况下，交换机就是个透明管道，广播会在这个VLAN内部转发。服务器收到DISCOVER后，在自己配置好的地址池里挑一个可用IP，通过OFFER报文回给客户端，如果客户端和服务器在同一个广播域内，OFFER同样是广播，因为客户端此时还没有IP，就算单播它也不知道往哪儿回。

然后客户端会收到可能多台服务器的OFFER（没错，如果你网里有好几台DHCP服务器，客户端会选最先到的那个），之后客户端广播一个REQUEST，告诉所有人“我选这个IP了”。这里有个关键点，REQUEST不光是发给选中的服务器，还要让其他服务器知道“没你们的事了，你们保留的地址可以放回去”。最后服务器发送ACK确认，整个租约才算建立。

用生活里的话打比方——DORA就像你去酒店前台领房卡，你先喊一嗓子“我来了，给我一间房”（DISCOVER），前台查了下房态说“有房，1508给你”（OFFER），你说“行，1508我要了”（REQUEST），前台把房卡递给你说“好的，1508归你住到退房时间”（ACK）。流程不难，难的是搞清楚广播域、三层路由、中继这些环节在哪一层插手。

1.2 为什么是广播四次？以及排障中可以借用的信号

有个问题常被忽略：如果客户端和服务器跨了网段，第一步的DISCOVER广播根本出不了网关，你必须在网关设备上配DHCP中继，把广播转成单播发给服务器。理解这一点，整个中继配置的逻辑就通了一半。

还有一个信号级细节：客户端发REQUEST的时候用的是广播，但服务器发ACK的时候，如果客户端已经有可用IP，服务器会直接向客户端的IP单播ACK；如果客户端还在初始状态，服务器只能继续广播。所以你在交换机上抓包时，看到连续的DISCOVER但没有OFFER，问题大概率出在“服务器根本没收到广播”或者“服务器收到了但地址池里没货”。相反，看到OFFER但客户端一直不发REQUEST，那通常是客户端自己判断OFFER里的IP有问题（比如网关不可达、ARP冲突），这个方向在排障时非常有用。

实操中我建议详细熟悉这四个阶段的报文特征，不要只知道名字。比如你可以在服务器上开抓包，看是否收到DISCOVER，来判断交换机端口VLAN有没有划错；在客户端上抓包，看有没有OFFER，来判断服务器到客户端的路径是否通畅。这些抓包信号，比你在交换机上瞎猜高效得多。

2. 华为交换机当DHCP服务器：全局池与接口池怎么选

2.1 两步搞定全局地址池（全局配置+接口配置）

华为交换机上把设备本身配成DHCP服务器，核心是“全局池”的概念——全球址池和某个VLANIF绑定后，从对应VLAN接入的客户端就能自动获取地址。注意我这里的“全球址池”是指跨接口共享的地址池，不是“全局配置”这个动作。

拿一台S5735举例，先开启DHCP服务，然后建一个名为vlan10的地址池，网段是192.168.10.0/24，网关是192.168.10.254，DNS给到运营商或内网解析服务器。

system-view dhcp enable ip pool vlan10 network 192.168.10.0 mask 255.255.255.0 gateway-list 192.168.10.254 dns-list 114.114.114.114 223.5.5.5 lease day 7 hour 0 minute 0

接着把地址池绑定到VLANIF接口上：

interface Vlanif10 ip address 192.168.10.254 255.255.255.0 dhcp select global

这样VLAN 10里的终端就能拿到192.168.10.0/24段的地址。注意DHCP服务器必须自己先有接口地址在这个网段内，否则地址池建了也白建。

2.2 接口地址池的适用场景与命令行

很多人纠结“全局池和接口池到底用哪个”。我的习惯是：只有一个VLAN的小项目，直接用接口池，配置短、直观；多VLAN、地址段多、要精细控制的场景，用全局池，因为地址池可以在多个接口间复用，管理集中。

接口池配置更简单，直接在VLANIF下配，不用单独建pool：

interface Vlanif20 ip address 192.168.20.254 255.255.255.0 dhcp select interface dns-list 8.8.8.8 lease day 3 hour 0 minute 0

接口池的网段默认就是VLANIF的接口地址所在网段，所以不用再指定network，不容易出现“网段和地址池不匹配”的问题。缺点也明显：如果你想让一个地址池跨多个VLAN共用，接口池做不到，必须上全局池。

我看到有些项目里同一台交换机既用接口池又用全局池，容易把自己绕晕。我的建议是：一台设备尽量只选一种方式，除非你能保证团队里每个人都能分清哪个VLAN用的是哪种池。不然出了问题，排查的人第一句就问“你确认这个VLAN走的是global还是interface吗”，然后大家集体沉默。

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

配置完不等于配对了，必须会查。华为设备最常用的查看命令有这么几条：

• display ip pool：查看所有地址池的配置和分配情况，包括总地址数、已分配数、冲突数、过期时间。
• display ip pool name vlan10 used：只看vlan10这个池，用了哪些IP、给谁用了（通过MAC识别）。
• display dhcp server statistics：查看DHCP服务器报文统计，能看到DISCOVER、OFFER、REQUEST、ACK各有多少，如果只有DISCOVER没有OFFER，问题出在配置或者地址资源上。
• display current-configuration | include dhcp：快速看当前设备上所有DHCP相关配置，排查的时候最实用。

我遇到过不止一次，配置看着没问题、服务也已经开启，但client就是拿不到地址。后来一查display ip pool才发现，整个池的地址全部被ARP探测标成了“冲突”。这时要检查是不是有终端手工配置了静态IP，或者别的DHCP服务器一直在和你的地址池抢地盘。华为设备默认开启地址冲突检测，发现异常会把这个地址标记为冲突，不再分配。

2.4 续租、保留地址与手动绑定的细节

DHCP不是分完地址就不管了，租约到期前客户端会续租。默认华为交换机的租约是1天，如果网络里终端不多、地址池够大，建议把租约调到3到7天，减少续租报文对网络的冲击。但如果地址池很紧张，比如一个VLAN有300台终端只有254个地址，那就把租约调短，比如4到8小时，让长期不用的终端的地址尽快释放。

还有两类特殊地址需要提前排掉。一类是保留地址（excluded-ip-address），用于网关、打印机、网络打印机、摄像头这类固定IP设备：

ip pool vlan10 excluded-ip-address 192.168.10.1 192.168.10.10 excluded-ip-address 192.168.10.250

另一类是绑定地址，特定MAC必须拿特定IP。华为华为全局池里可以这样写：

ip pool vlan10 static-bind ip-address 192.168.10.88 mac-address 5489-9831-0a5b

这个功能非常实用。比如财务软件要求某台服务器IP不能变，又不想去服务器上配静态IP，就可以用这个绑定搞定。但注意：绑定地址的IP不能落在excluded-ip-address范围内，否则会冲突，配置时系统不一定马上报错，但分配的时候可能行为怪异。

提示：全局地址池的静态绑定，只对不跨VLAN的场景有效。如果客户端通过中继获取地址，静态绑定要配置在服务器的中继地址池上，而非交换机本地的全局池里。这个坑我在第3节中继场景里吃过亏。

3. 跨VLAN发地址，必须会的中继配置

3.1 什么时候必须使用DHCP中继

把DHCP服务器放在核心机房、网关在三层交换机上，但终端分散在各个VLAN——这是最常见的企业网络结构。问题来了：终端发出的DISCOVER是广播，广播不能穿越三层设备，服务器在另一个VLAN里根本收不到。你需要在终端所在VLAN的网关（也就是VLANIF接口）上启用DHCP中继，让交换机把广播报文转成单播，转发给指定的DHCP服务器。

判断是否需要中继的一个简单标准：DHCP服务器和客户端是否在同一个广播域（同一个VLAN/同一个二层网络）内。不在同一个VLAN就必须中继；在同一个VLAN的话，二层广播可以直达，不需要任何中继配置。

有一种例外情况容易忽略：即使DHCP服务器和客户端在同一个交换机上，但处于不同VLAN且之间用VLANIF三层打通，这种情况下广播依然会被隔离在各自VLAN里，照样需要中继。别以为“同一个设备上就一定互通”，二层广播分域是按VLAN走的。

3.2 华为交换机中继配置实操（三条核心命令）

假设网络结构：终端在VLAN 100，网关是VLANIF 100，地址192.168.100.254/24；物理DHCP服务器在VLAN 200，IP是192.168.200.10。终端要通过VLAN 100网关向服务器要地址，在VLANIF 100上配置：

system-view dhcp enable interface Vlanif100 ip address 192.168.100.254 255.255.255.0 dhcp select relay dhcp relay server-ip 192.168.200.10

dhcp select relay告诉交换机这个接口不再自己发地址，只当中继；dhcp relay server-ip指定把DISCOVER转发给谁。我习惯再加一条：

dhcp relay information enable

开启Option 82填充，这样DHCP服务器能看到客户端是从哪个VLAN、哪个物理端口进来的，日志和排查非常有帮助。如果你的服务器不支持Option 82分析，开不开不影响地址发放，但建议开着，因为绝大多数情况下后面排查会用得上。

3.3 中继的常见错误：地址池网段、VLANIF、网关与relay gateway

中继场景里错得最多的，反而是服务器侧和交换机侧各自觉得“我没配错”。我列出几个高频错误，都是我现场踩过的：

第一，DHCP服务器上的地址池网段必须和客户端所在VLAN网段一致，不能和服务器自己所在网段一致。很多物理DHCP服务器默认只给同网段发地址，给中继来的请求分配时，如果服务器上没有192.168.100.0/24这个作用域，就直接不响应。这是中继排查第一顺位要查的。

第二，VLANIF接口IP必须和客户端网关一致。DHCP中继在转发DISCOVER时，会把报文中的giaddr字段（网关IP地址）填成VLANIF的IP。服务器看到giaddr是192.168.100.254，就会去对应192.168.100.0/24的作用域里选地址。如果VLANIF配的是192.168.100.253，而地址池是192.168.100.254，服务器会从两个不同网段选择，必然出问题。

第三，物理链路不通。VLANIF到DHCP服务器之间必须三层可达。这个看起来基础，但排查中继时很多人会忽略。你可以先在交换机上ping一下DHCP服务器的地址，通了你再去看配置，这一步能排除一大半“中继不生效”的假象。

注意：中继还有一种“只出不进”的坑。DHCP服务器回OFFER时是单播给giaddr（也就是交换机VLANIF的接口IP），交换机再转成广播发给客户端。如果VLANIF接口上做了ACL或者防火墙策略禁止UDP 67/68的流量，服务器能收到请求但你永远等不到OFFER回来。

4. 虚拟环境里最常见的两个DHCP问题：vNIC与多台虚拟机

4.1 “DHCP服务器为vNIC”到底是什么场景

热搜词里有一条“dhcp服务器为vnic”，第一次看到的朋友可能一头雾水。其实这里说的是虚拟化平台里，虚拟机（VM）的虚拟网卡（vNIC）通过DHCP获取IP的场景。最常见的有两种：

一种是你在一台虚拟机里装了DHCP服务，想让其他虚拟机通过它拿IP。这时候你需要注意，DHCP服务必须监听在正确的虚拟网卡接口上，并且该接口要和客户端虚拟机在同一个虚拟二层网络里。举个例子，VM1装了DHCP服务，只有它接在VM Network A上，VM2也接在VM Network A上，才能正常拿IP。如果VM1在A网络、VM2在B网络，虽然虚拟机在同一个物理宿主机上，但它们之间的广播互相看不到，DHCP照样不工作。

另一种是你在宿主机/虚拟化平台的虚拟交换机上做DHCP中继。VMware的vSwitch、华为的Virtual Switch这种虚拟交换机，默认跟物理交换机一样不转发广播到其他VLAN，跨VLAN要么靠虚拟路由器，要么靠物理三层设备去中继。实操中，我见过不少人把虚拟交换机当路由器用，然后抱怨“两台虚拟机明明在同一个宿主机上，为什么在‘不同VLAN’下互相拿不到地址”——这不是DHCP配置问题，是虚拟网络的隔离机制问题。

4.2 两台虚拟机复用DHCP：为什么总会有一台拿不到地址

这恐怕是“两台虚拟机如何用我dhcp”这个热搜词背后的真实痛点。两台VM接的是同一个虚拟交换机（同一个VM Network），其中一台跑了DHCP服务，另一台死活拿不到地址，或者时好时坏。

我的排查顺序是：先确认两台VM的vNIC是否真的在同一个广播域。虚拟交换机上的VLAN ID是硬隔离的，如果VM1的vNIC VLAN ID为0（默认无VLAN），VM2的vNIC VLAN ID为10（Trunk/access模式），即使它们在同一台物理机、同一个虚拟交换机上，广播也不会互通。你可以在VM里自己ping一下网关或者看看ARP表，来判断二层到底通不通。

再确认DHCP服务器VM本身的操作系统防火墙有没有放行UDP 67/68。Windows Server上装了DHCP角色后，防火墙一般会自动放行；但如果你是自己写脚本起的DHCP服务，或是Linux上起了个轻量DHCP服务，防火墙不放行就是最常见的原因：客户端DISCOVER到了，服务端也收到并回应了，但OFFER被防火墙挡在网卡外面。

最后，看看两台VM是不是克隆出来的。VM克隆场景经常把虚拟机的MAC地址也克隆过去，或者生成两个不同MAC但名字特别像的vNIC，地址分配时容易产生租约冲突。两台机器抢一个IP，表现就是你看到的那台“时不时断一下网”。

4.3 虚拟化网络中的MAC与租约坑

虚拟化环境下MAC地址是很容易出问题的地方。很多人以为虚拟机MAC是虚拟化平台随机生成的，不会重复，结果虚拟机迁移、克隆、快照回滚时MAC变了或者变了又还原，DHCP服务器里的旧租约还没过期，新地址就一直分配不过来。典型表现：新开的VM能拿IP，过一会儿又掉了，再重新获取要等几分钟。

碰到这种情况，我的习惯是在DHCP服务器上清理对应VM MAC的租约，再在虚拟机里执行ipconfig /release和ipconfig /renew（Windows）或者dhclient -r之后重新获取（Linux）。如果问题反复出现，检查虚拟交换机上有没有启用MAC Learning的变化限制，部分安全策略会在一段时间内锁住某个MAC到某个端口的对应关系，VM迁移后会出现“广播到了但OFFER回不去”的怪异现象。

还有一个坑：VM的vNIC如果在虚拟交换机上是Trunk模式或配置了VLAN ID，但物理交换机端口也配了VLAN，两者叠加，包会被打上双重标签（部分虚拟交换机有特殊处理），DHCP服务器收到的请求源可能就“不对”了。大厂虚拟化平台的文档里都建议：对外只走一层VLAN标签，要么在虚拟交换机上打标签，要么在物理交换机的access口上打，不要两边都干。

5. 内网本来就有物理DHCP服务器，交换机到底要怎么配合

5.1 先回答一个核心问题：交换机要不要开DHCP服务

这个问题的答案很简单，也常被忽略：如果内网已经有物理DHCP服务器，三层交换机或核心交换机不要启用DHCP服务，最多启用DHCP中继。原因有二：一是多一台DHCP服务器就多一个地址冲突源，一旦两台服务器作用域重叠，整个网段会出现客户端拿到不同网关、DNS的混乱局面；二是物理DHCP服务器通常具备更完整的日志、审计、基于MAC的策略分配能力，交换机内置的DHCP功能一般没有这些。

所以这里的“交换机如何配置”的关键是：明确交换机的定位。交换机在这个架构里是“二层转发入口 + 三层网关 + 中继转发器”，不是地址分配者。基于这个定位，你要做的就是把VLAN规划好、VLANIF配好、中继指好，然后让物理服务器去干活。

5.2 三层交换机在物理DHCP方案里的角色（网关、中继、VLANIF）

以华为交换机为例，假设内网有三层交换机，物理DHCP服务器放在服务器区，IP为10.10.10.10/24，终端分布在VLAN 10（192.168.10.0/24）、VLAN 20（192.168.20.0/24）两个业务网段。交换机上要做的事：

dhcp enable interface Vlanif10 ip address 192.168.10.254 255.255.255.0 dhcp select relay dhcp relay server-ip 10.10.10.10 interface Vlanif20 ip address 192.168.20.254 255.255.255.0 dhcp select relay dhcp relay server-ip 10.10.10.10 interface Vlanif100 ip address 10.10.10.254 255.255.255.0

VLAN 100是服务器区，终端VLAN 10、20的DISCOVER都会通过VLANIF 10、20中继到10.10.10.10。注意此时物理DHCP服务器侧的作用域中，必须分别创建192.168.10.0/24和192.168.20.0/24两个作用域，并把网关分别设为192.168.10.254和192.168.20.254。为什么？因为服务器从giaddr字段判断客户端在哪个网段，然后选择对应作用域。

如果你的物理DHCP服务器和某个终端VLAN在同一个二层网络，就完全不用在交换机上做中继，广播自己就能到。但企业网络里服务器区通常和办公区不同VLAN，所以中继才是更高频的配置。

5.3 如何避免地址冲突：租约、作用域与IP占用检查

物理DHCP服务器方案里，最容易出事故的不是配置本身，而是“规划不严”。我见过一个项目：终端网段192.168.10.0/24，物理服务器分配范围是192.168.10.100-192.168.10.200，但网络管理员顺手给另外一台打印机手工设了192.168.10.150——冲突就这样发生，而且不是立刻发现，是这台打印机每次广播ARP的时候才暴露出来。

避免冲突的操作习惯有这几个：第一，DHCP作用域内必须排除所有静态IP，包括网络设备管理口、打印机、摄像头、门禁主机等，用一个Excel或在线表格随时维护。第二，租约时长根据地址池使用率动态调整。如果地址池充裕，租约适当拉长到一周；如果紧张，就压缩到8-12小时，保证不活跃终端快速释放。第三，在交换机上开DHCP Snooping，只信任连接物理DHCP服务器的端口（一般是上联口），其他端口收到DHCP OFFER直接丢弃。这样就算员工私接一个小路由器当DHCP服务器，它也没法发地址。

dhcp snooping enable interface GigabitEthernet0/0/1 dhcp snooping trusted

另外，华为交换机的display ip pool或服务器上的租约记录，能帮你看到每个地址被哪台设备占用。出现冲突时，先在交换机上ping冲突IP，再display arp查对应MAC，就能定位到具体设备。尽量不要靠猜，三步定位法比无头苍蝇式排查快得多。

6. 常见问题排查实录速查

6.1 客户机显示“无法获取IP地址”的排查顺序

很多读者一上来就问我“DHCP服务器配置好了但客户端拿不到地址怎么查”，我给一个固定的排查顺序，按这个走，一般5分钟内能定位大部分问题。

第一步，先ping网关。网关都不通，说明二层链路或VLAN问题，DHCP当然无从谈起。第二步，在交换机上display ip pool看看地址池还有没有可用地址，以及有多少地址处于冲突状态。地址池满了是最容易被忽略的原因，一个254地址的VLAN里住了300台设备，你以为只是配置问题，其实是地址不够。第三步，确认客户端和服务器是否在同一广播域，不在就查中继，在就查VLANID有没有配错。第四步，抓包。客户端上开Wireshark抓UDP 67/68，数一下有多少DISCOVER发出、有没有OFFER回来。没有DISCOVER，查客户端网卡是不是被禁用了；有DISCOVER没OFFER，查服务器；有OFFER但没REQUEST，查客户端的网关配置和ARP冲突。

这套顺序我用了五年，排掉了大大小小上百个DHCP故障。不要一上来就东看一个西查一个，DHCP这东西牵一发动全身，固定流程能省很多时间。

6.2 排查命令速查表（华为设备）

我整理一份平时用得最频的华为DHCP排查命令速查表，贴在旁边或者存成笔记，现场直接抄作业。

提示：display dhcp server statistics的计数是累计值，不是实时增量。你可以在客户端重试获取IP之前先记录一次数值，再在客户端执行renew之后对比，看DISCOVER数量有没有增加。这样能准确判断交换机到底有没有收到请求。

6.3 我踩过的三个坑和你应该如何避免

第一个坑：把两台DHCP服务器都配了相同作用域，结果网络中一半客户端拿A服务器地址、一半拿B服务器地址，网关DNS全不一致。后来我在部署物理DHCP服务器时，永远给关键作用域开“冲突检测”（Windows DHCP里是在IPv4属性里启用“冲突检测尝试次数”），并保证服务器之间作用域不重叠。

第二个坑：在交换机上开了DHCP Snooping，却忘了把上联口的trust配好，结果所有OFFER都被交换机当成非法报文丢弃，客户端广播DISCOVER满天飞就是没有回音。这个现象特别容易误判成“DHCP服务器死了”，尤其当服务器还在另一个网段时。排查方法很简单，看display dhcp snooping里的丢弃计数，如果计数在涨，多半就是trust口没配对。

第三个坑：虚拟机的vNIC网卡驱动没装好，导致某些报文（尤其是广播OFFER）到达不了应用层。我当时在ESXi上开了一台Windows虚拟机，怎么看都拿不到地址，抓包发现DISCOVER发了、OFFER也到了网卡，但系统就是没反应。重装VMware Tools之后问题消失。所以虚拟化环境里DHCP故障，别只盯着网络设备，虚拟机的虚拟网卡驱动和VMware Tools也值得排查。

我个人操作中的体会是：DHCP这种基础服务，状态看起来简单，但真正把它搞明白的工程师并不多。你把这套从原理到配置到排障的逻辑理顺了，后面不管是华为、思科还是H3C，换设备不换思路，换版本不换流程，都能快速上手。不要迷信网上那些“一段命令搞定”的捷径，把原理吃透，你才能在自己踩坑的时候知道坑在哪。