华为防火墙双机热备配置不一致排查：VGMP/HRP状态与恢复实战

1. 双机热备的底层逻辑先搞清楚“不一致”是怎么来的做运维这些年华为防火墙的双机热备我前前后后部署过几十套从USG2000到USG6000都在生产环境摸过。说实话双机热备本身配置并不复杂真正让人头疼的是那些“看起来都配好了但状态却不一致”的诡异场景。深夜接到电话说业务全断登上去一看主备状态都对配置却对不上这种时刻最考验基本功。先纠正一个说法。业内经常有人把“双机热备”念成“双击热备”早期论坛里的帖子也这么写实际上是输入法把“机”打成了“击”。华为自己的文档里标准叫法是双机热备缩写HRPHuawei Redundancy Protocol。这套机制解决的核心问题只有一个当一台防火墙故障时另一台能无缝接管流量保证业务不中断。要做到这一点靠的是两层协议配合。第一层是VGMPVGMP Group负责主备角色协商相当于两台设备在“选班长”。第二层是HRP负责配置和会话状态的同步相当于当选的班长把自己的决策实时同步给副班长。两者必须同时工作缺一个都会出问题。HRP的配置同步并不是“全量镜像”。简单说它同步的是安全策略、地址簿、NAT规则、路由配置这些核心配置。但有些东西不同步比如接口的IP地址通常要求两边手工配一致或者通过HRP同步取决于版本和场景还有一些本地无关紧要的配置也不会同步。这就埋下了“不一致”的隐患。1.1 VGMP和HRP主备是怎么协商出来的两台防火墙启动后通过专用的心跳接口互相发送VGMP报文报文里带着各自的优先级。优先级高的设备会成为主设备也就是active状态。备设备则进入standby状态正常情况下不转发业务流量只通过HRP链路接收主设备同步过来的配置和会话表。判断角色有两个关键命令。第一是display hrp state能看到当前设备是active还是standby。第二是display vgmp能看到VGMP组的详细信息包括本地优先级和对端优先级。生产环境里我见过优先级配反了导致备机一直抢主的案例就因为在两台设备的VGMP组里把priority设成了一样结果一端重启后角色反复横跳业务下一跳直接懵逼。1.2 不一致场景的高发原因配置不一致说白了就是主设备上的实际配置和备设备上的实际配置对不上。常见原因有这么几类按我踩坑的频率排序心跳线中断或质量差VGMP协商失败备机长期收不到同步报文。在备机上直接敲了配置命令虽然备机通常拒绝写入但某些版本存在漏洞或特殊命令能写进去。主备设备软件版本不一致导致某些配置项只有一边支持。配置变更时网络波动HRP同步过程被中断部分配置没同步过去。License差异导致功能不同比如攻击防御特性只在一台设备上激活。手工在备机上使用undo或reset等命令把已同步的配置删了。这些场景的共性在于表面上看两台设备都活着心跳也通但配置已经不齐了。如果此时发生主备切换业务流量被新的主设备接管却找不到对应的NAT、策略或路由用户侧的表现就是“切换了但业务全断”。2. 快速定位三分钟找出问题在哪一层遇到不一致场景第一步不是急着改配置而是先确认状态、链路、配置版本三件事。顺序错了很容易把问题扩大。2.1 用display hrp state确认角色状态登录主备两台设备分别执行display hrp state重点看状态的几个关键字段。正常的active设备会显示role: active备机显示role: standby。备机上还会有一个HRP state字段正常的备机是standby ready意思是配置已经同步完成、随时可以接管。如果备机显示的是standby abnormal说明HRP同步链路有异常。这时再往下看Peer state如果显示down基本可以确定心跳断了或对端设备挂了。如果显示up但配置状态还是abnormal那问题大概率出在配置同步本身而不是链路。我在现网里遇到过一种特别迷惑的情况两边设备显示role都是active也就是双主。这种场景通常发生在心跳线中断后备用设备在等待超时后主动升为主设备。等心跳恢复两边VGMP组开始互相抢权如果配置不一致优先级相同的两台设备会不断震荡业务时通时断。2.2 检查心跳接口和VGMP协商状态心跳接口的检查很多人容易忽略。display hrp interface能看心跳接口的收发报文统计。如果报文的发送和接收计数长时间不增长说明心跳数据根本没有正常传输。更隐蔽的问题出现在接口的物理状态正常、报文计数却不增长这种往往是心跳接口被防火墙策略拦截了或者接口所属的安全区域配置了不合理的包过滤规则。华为防火墙的心跳接口要放在单独的安全区域并且区域间安全策略要放行。因为HRP报文本质上是防火墙自己发的报文如果安全策略写得太严会把心跳报文一并拦掉。这个坑在有些同事的配置里反复出现排查时一定要先看接口下的service配置和区域间的策略。2.3 对比配置版本和核心差异确认了状态和链路之后就要进行配置对比。华为防火墙提供了display hrp config-version可以查看配置版本号。正常情况下主备设备的配置版本号是一致的或者主设备版本号领先。如果两边版本差异很大说明已经失步很久了。真正的配置对比我一般用三种方式组合第一登录主备设备分别执行display current-configuration把输出保存下来做diff第二重点看安全策略、NAT、路由三块内容因为这三块对业务影响最大第三用display hrp configuration查看HRP同步范围内的配置明细确认哪些配置属于不同步的范围避免在对比时误判。我自己的做法是先在主设备上抓一份完整配置再到备机上抓一份在本地用对比工具做差异比对。注意抓配置前要在两台设备上都执行screen-length 0 temporary防止分屏导致输出被截断。3. 逐类击破三种典型不一致场景的完整恢复流程把问题定位清楚之后操作其实就有章法了。下面按我实际处理过的三种场景展开包含具体的命令和操作顺序。每种场景我都标注清楚了关键注意事项照着做基本能稳住局面。3.1 心跳中断引起的失步恢复场景特征备机display hrp state显示standby abnormaldisplay hrp interface对端状态down但两台设备业务都正常。这种情况下业务层面可能感觉不到异常一旦切换就会出大事。第一步恢复心跳链路。检查心跳口物理状态、对端接口是否shutdown、中间设备是否配置了导致丢包的策略。心跳口物理恢复后HRP会自动开始同步配置但这个过程不会重传失败的数据块所以不能光等。第二步在主设备上手动触发一次完整配置同步。华为防火墙提供了手工同步命令不同版本命令略有差异我常用的方式是hrp sync执行后观察备机状态正常情况下配置版本会逐渐追上主设备备机状态从abnormal变为ready。第三步验证。在备机上再次执行display hrp state确认HRP state为standby ready。同时抽查几条核心配置比如安全策略和NAT规则确保已经同步过来。注意如果心跳线是临时恢复的一定要观察一段时间确认心跳报文持续正常收发避免抖动场景下再次失步。另外心跳口不要和业务口共用实在没有多余接口时至少要把心跳线走独立VLAN避免业务广播风暴干扰心跳报文。3.2 配置自动同步失败的定向修复这个场景比心跳中断更隐蔽心跳正常备机状态也显示up但配置就是差一点。典型表现是主设备上新增了一条NAT规则备机上却没有。原因通常是配置同步过程在传输过程中被中断或者这条配置本身不受HRP管理。第一步确认这条配置是否在HRP同步范围内。华为防火墙的HRP默认同步大部分公共配置但确实存在例外。例如某些接口下的子配置、个别全局参数可能需要额外配置hrp include才能纳入同步。这种情况我建议查一下产品文档里关于“HRP同步范围”的说明。第二步如果确认配置应该同步但没过去优先在主设备上做一个“最小变更”。最简单的办法是把那条配置的命令再执行一遍哪怕是重复的也相当于触发一次增量同步。很多情况下这条配置就会自动补齐到备机。第三步如果重复执行无效就要在备机上手工补配置。注意在备机上补配置的时候命令的生效行为取决于是不是主设备同步来的配置。有些版本会提示“Configuration is synchronized from the peer”这种情况下备机无法直接修改。正确的做法是在主设备上调整或者先临时中断HRP同步在备机上单独配置再恢复同步。这个场景我踩过坑为了省事直接在备机上敲命令结果提示无法配置又跑到主设备上调整来回折腾了半小时。其实最好的办法是记住一个原则——统一在主设备上改配置备机只负责接收同步。除非你明确知道自己在做什么否则不要动备机的配置文件。3.3 双主场景的强制性收敛双主是最危险的状态两台设备都认为自己是主同时转发流量会造成路由环路、NAT会话错乱。处理这种场景要果断但不能乱。第一步确认两边状态。登录两台设备执行display hrp state如果两边都是active确认双主。第二步选一台设备做“牺牲品”。优先选择当前业务流量较小的一台或者直接选择你希望作为备机的设备。在这台设备上执行hrp standby-device这条命令会把当前设备角色强制设置为备机。执行后它的VGMP优先级会主动降低另一台设备会重新成为主设备。第三步观察收敛结果。在备机上再次执行display hrp state确认已经变为standby。然后在主设备上确认业务正常运行。如果主设备上出现过配置丢失需要用display current-configuration和备机或事前备份做对比补全缺失项。第四步恢复心跳备用。如果双主的原因是心跳中断修复心跳后HRP会自动恢复同步。但注意双主期间主备设备上可能各自产生了新的会话和配置要留足时间让HRP完成全量同步不要急着做测试。注意不要在双主状态下直接重启其中一台设备。如果优先级没有区分重启后VGMP重新协商仍然可能继续双主。一定要先执行角色强制收敛命令等状态稳定后再操作设备。3.4 业务恢复后的验证清单配置和状态都恢复后很多人以为就完了其实还差一步业务验证。我的习惯是在主备设备上分别检查以下内容display firewall session table确认当前业务会话是否正常建立重点看发起方和响应方的会话是否对称。display nat session table确认NAT转换是否正常尤其是源地址转换和目的地址转换规则。display ip routing-table确认路由表是否完整特别是默认路由和回程路由。从业务侧做一次真实的连通性测试比如从内网ping外网地址或者用实际业务端口做TCP连测。验证顺序很重要。先看会话再看NAT再看路由最后做连通性测试。如果会话不对路由看了也白看。如果NAT没转对业务大概率不通。这几步走完基本能确认业务已经完全恢复到正常水平。4. 配套环境的两个高频坑规则库更新与eNSP启动故障处理完生产环境的双机热备不一致很多时候还要面对测试环境和辅助工具的问题。最近问得最多的一个是USG防火墙规则库更新不了另一个是Windows 11 25H2版本下eNSP里的防火墙设备启动不起来。这两个问题和双机热备本身不直接相关但确实会影响你搭建验证环境、复现不一致场景的工作效率。4.1 华为USG防火墙规则库更新不了的排查思路先明确“规则库更新不了”通常指什么在防火墙Web界面或命令行下触发特征库升级时设备一直提示连接更新服务器失败或者下载到一半中断。特征库包括入侵防御特征库、URL分类库、应用识别库等和双机热备的会话同步机制一样都属于防火墙的基础能力直接影响安全策略的准确性和业务放行判断。排查思路按顺序来。第一检查设备时间和时区设置。规则库下载时会校验时间戳如果设备时间和实际时间差太多服务器会拒绝响应。用display clock确认当前时间不对就手动校准或配置NTP。第二检查网络连通性。设备要能访问华为升级服务器通常需要放行出方向的HTTPS和DNS流量。这个问题很多部署在私网环境下的防火墙都有内网到外网只放行了业务端口忘了放行升级流量。在命令行用ping和tracert测试到更新服务器的连通性如果中间有NAT或者代理还要确认防火墙自己的出接口地址能正常访问外网。第三确认License状态。规则库更新需要有效的License授权。检查License是否过期以及授权是否包含特征库升级服务。华为很多低端型号或者二手设备License过期后特征库就无法升级界面上不会明显提示容易让人忽略。第四尝试离线升级。如果在线升级始终不行直接从华为官网下载离线升级包通过Web界面的“手工升级”或命令行方式导入。离线包要选择和当前设备软件版本匹配的特征库版本强制升级版本过高或过低可能导致服务异常。注意双机热备环境下如果两台设备都需要升级规则库要分别操作不能只升级主设备。备机的更新通常可以通过HRP同步部分内容但特征库文件建议在每台设备上单独升级避免同步过程出现文件不完整的问题。4.2 Win11 25H2下eNSP防火墙设备启动故障eNSP是华为官方的网络模拟器很多人在生产环境变更前都会用它搭一套测试环境来验证配置尤其是双机热备这种高危变更。最近不少人在Windows 11 25H2版本下遇到一个问题eNSP能正常打开但是启动防火墙设备时AR路由器能起来USG防火墙设备却一直卡在启动界面或者直接报错提示“启动失败”。这个问题的根源在25H2系统版本默认开启了基于虚拟化的安全性功能包括内核隔离和内存完整性。这些安全机制和eNSP依赖的VirtualBox虚拟化组件存在兼容性问题。防火墙设备比路由器对虚拟化的要求更高启动时更需要完整的虚拟化支持所以在同一套环境下表现就是路由器能起防火墙起不来。解决方案实测有效的是三步。第一步在“Windows安全中心”里关闭“内核隔离”下的“内存完整性”然后重启电脑。第二步如果还不行确认eNSP关联的VirtualBox版本建议卸载后重新安装5.2.44版本这是被eNSP官方插件认证过的稳定版本。第三步启动eNSP前确认CPU虚拟化已经在BIOS里开启并且系统内的Hyper-V没有被完全启用Hyper-V和VirtualBox同时存在会导致设备起不来。做仿真实验时还有一个小技巧如果只是验证双机热备的配置和不一致场景不一定非要启动USG防火墙设备。如果eNSP实在起不来可以用两台AR路由器模拟VGMP组里的角色协商逻辑把防火墙的HRP配置用简化的方式在路由器上做验证比如用VRRP模拟主备切换。虽然不完全等价但能把双机热备的关键逻辑跑通对排查思路的验证已经够用了。5. 实战经验几件值得养成的操作纪律几次把双机热备从崩溃边缘救回来之后我对手上每套防火墙的维护方式都做了调整。这里分享几个实际操作层面的习惯不一定写在哪本手册里但对避免不一致场景真的有用。第一变更时永远只动主设备。无论加策略、改路由还是调整NAT都登录主设备操作然后观察备机的同步状态。如果登录备机执行配置时看到拒绝提示不要强行绕过去那说明你登录错了设备或者当前环境正处于异常状态应该停下来排查而不是继续操作。第二定期做配置备份和比对。双机热备设备也一样不要以为有了HRP就不需要备份。我建议每个季度至少在每台设备上分别导出一份配置文件存档。导出的配置不光用于灾难恢复也能在排查不一致时提供基线参考。很多次我都是靠上一季度的配置文件快速定位出哪条策略是新加的。第三维护窗口做一次切换测试。双机热备最大的谎言就是“配好就能用”如果不定期做主动切换测试永远不知道真正故障时会发生什么。我一般每季度选一个低峰时段手动执行切换观察业务中断时长和状态恢复情况。测试记录里会把切换前后的配置版本号、会话数量、策略命中情况都记下来作为后续排查的参考。第四变更前做好回退点。规则库升级和版本升级这种操作升级前一定要导出当前配置、备份特征库文件。如果升级后出现异常优先回退而不是修复。这比在故障现场临时找办法要靠谱得多。第五记录每台设备的软件版本和License信息。我经手的每台设备都建了一份台账记录软件版本、补丁版本、License有效期和特征库版本。双机热备场景里设备版本不一致是最隐蔽的问题之一台账能帮你快速排除这个变量。另外再说一个小技巧关于eNSP的。如果你经常需要复现双机热备不一致场景做练习建议把主备设备的启动顺序固定成“先启动主设备再启动备设备”并且在主设备完全启动后再配置HRP。模拟器环境里如果启动顺序反了经常会看到备机的配置同步异常这和生产环境下的现象高度相似也是练习排查的好素材。双机热备不一致场景说到底是一个“确定性”问题。所有故障都有迹可循关键在于你愿不愿意在平时多花一点时间把状态检查、配置比对和切换测试变成习惯。这些动作本身不复杂但能在关键时刻帮你省下整夜的排查时间也能让业务连续性真正落到实处。