ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

华为交换机DHCP配置与中继排障实战:从DORA原理到虚拟机vNIC

华为交换机DHCP配置与中继排障实战:从DORA原理到虚拟机vNIC 开头搞网络的谁没被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.254DNS给到运营商或内网解析服务器。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下配不用单独建poolinterface 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 200IP是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.10dhcp 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默认无VLANVM2的vNIC VLAN ID为10Trunk/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 /renewWindows或者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 10192.168.10.0/24、VLAN 20192.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.0VLAN 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 ip pool总地址数、已分配、冲突数查看指定池的分配明细display ip pool name vlan10 used所有IP对应的MAC、租约剩余时间看DHCP报文收发统计display dhcp server statisticsDISCOVER/OFFER/REQUEST/ACK计数是否异常查看当前DHCP中继配置display dhcp relay interface Vlanif10是否正确指向服务器IP查看Snooping状态display dhcp snoopingtrust口配了没有、丢弃报文数是否在涨查看告警日志display logbuffer有没有地址冲突、分配失败的记录查看ARP表display arpinclude 192.168.10.150提示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换设备不换思路换版本不换流程都能快速上手。不要迷信网上那些“一段命令搞定”的捷径把原理吃透你才能在自己踩坑的时候知道坑在哪。
返回列表