华为H3C实战 | 第28章 防火墙双机热备

📚 本系列共 43 篇（第 28 / 43 篇）　·　第四卷 设备与安全篇 —— 路由器与防火墙

← 上一篇：第 27 章 防火墙 NAT 与部署模式 　下一篇：第 29 章 防火墙高级功能 →

本章导读：两台防火墙做主备，一台挂了另一台在毫秒级接管——但配错就会出现"双主"，两台都以为自己是主。本章讲清华为 VRRP+HRP 双机热备、H3C 双机热备/IRF 两套方案，以及"切换时业务到底断没断"怎么验。

本章结构：

• 28.1 功能原理与业务场景 —— 主备协商、配置同步、状态同步三件事分别对应什么技术；主备备份与负载分担的取舍；双机热备"能解决什么、不解决什么"的边界
• 28.2 华为设备配置详解 —— HRP 心跳口、VRRP 备份组、hrp track 与负载分担骨架的完整配置
• 28.3 H3C 设备配置详解 —— remote-backup group 家族的 H3C 写法
• 28.4 华为 / H3C 命令对照表
• 28.5 配置验证 —— VRRP 角色、HRP 状态、会话同步情况逐项确认
• 28.6 排错与故障树 —— 双主排查顺序：心跳 → 会话同步 → VRRP 角色
• 28.7 新手踩坑与注意事项
• 28.8 本章小结

重点提示：想快速搭起来看 28.2；出现双主先看 28.6 的排查顺序，别一上来就查 VRRP 配置（十有八九是心跳口断了）。只验证了能 ping 通就以为成功是新手最常见的误判——28.1.2 第 6 步讲清了为什么必须验证"切换后旧会话还在"。选负载分担前先读 28.1.3 的 NAT 端口分段坑。 关联章节：VRRP 原理、优先级与抢占见第 7 章；防火墙区域与安全策略见第 26 章；NAT 与策略先后顺序见第 27 章；AC 侧的 VRRO+HSB 双机可类比第 23 章。

28.1 功能原理与业务场景

28.1.1 这功能是干嘛的（通俗版）

把防火墙想成公司门口的保安。只有一岗保安时，他生病请假，全公司的人就进不了门、也出不了门。双机热备就是门口站两个保安：一个当班（主），一个在旁边看着（备）。当班的一旦倒下或者被叫走，旁边的立刻顶上，门口不会空岗。

但两个保安之间不能各看各的，得有规矩：

1. 谁当班要先商量好（主备协商），否则两个都以为自己当班，就会出现「双主」——两个保安同时喊「你走这边」，队伍全乱了。
2. 规矩本要同步（配置同步），新保安上岗时手里必须有和当班的一模一样的规矩本，否则他放行的人当班的不放行。
3. 已经进门的人要接着算数（状态同步），换岗时正在排队的人不能被赶出去重新排——这一点最容易被忽视，也是业务中断的主要来源。

这三件事在技术上分别对应：VRRP 主备协商、HRP 配置同步、HRP 状态/会话同步。

28.1.2 在网络里怎么落地（设计视角）

防火墙双机热备的典型组网是「上下各一台交换机，防火墙横在中间」，两台防火墙之间用一根心跳线直连：

                 [上行交换机]（连运营商）
                   |        |
              GE1/0/1    GE1/0/1
                   |        |
            +------+------+ +------+------+
            |  防火墙 A    | |  防火墙 B   |
            |  （主）      | |  （备）     |
            | GE1/0/2  <-HRP->  GE1/0/2    |
            |  (心跳口)     | |  (心跳口)   |
            +------+------+ +------+------+
                   |        |
              GE1/0/3    GE1/0/3
                   |        |
                 [下行交换机]（连内网核心）

数据面用 VRRP 决定「谁是主」：上下行各建一个 VRRP 备份组，主设备上的 VRRP 状态是 Master，持有虚拟 IP，终端和上行路由器都把虚拟 IP 当网关；备设备是 Backup，不收发业务报文。

控制面用心跳口跑 HRP：主设备定期给备设备发心跳，同时把配置、会话表、NAT 映射表同步过去。

一个报文从内网到外网，在双机环境下的完整旅程：

第 6 步是全章的核心。如果只做了 VRRP 没做会话同步，切换后 B 手里没有旧会话，所有 TCP 连接都要重新握手，用户看到的就是「网页转圈、SSH 断开、视频卡住」。很多人只验证了「能 PING 通」就以为双机成功了，其实业务已经断了一轮。

适用版本：华为 USG6000E（VRP V500R005 及以上）；H3C F1000 系列（Comware V7 R8860 及以上，双机热备功能以 remote-backup group 命令族实现）。部分早期版本的双机热备可用性受限于型号与授权，实施前务必查型号的「双机热备」特性支持表。

28.1.3 双机热备与「负载分担」的区别

双机有两种工作模式，选错了会比不配还糟：

负载分担模式下，NAT 地址池的端口分配会出现冲突——两台设备同时从同一个公网地址里挑端口，很容易撞号。华为要求在一台设备上配 hrp nat resource primary-group、另一台上配 hrp nat resource secondary-group，把地址池的端口分成前后两段。这是负载分担模式里最容易被漏掉的一条命令，漏了就会表现为「上网时通时不通」。本章主线讲主备备份，负载分担在 27.2.6 节给骨架。

28.1.4 双机热备的边界：它解决什么、不解决什么

新手常把双机热备当成「买了就不会断网」的护身符。这个预期会害人，先把边界划清楚：

它能解决的：

• 单台设备硬件故障（电源、主板、接口卡损坏）；
• 单台设备软件崩溃或重启；
• 单条上行链路故障（接口 down）；
• 单台设备计划内维护（升级、换件）时业务不中断。

它不能解决的：

• 共用依赖故障。两台防火墙接同一个电源插排、同一条光纤路径、同一台上行交换机，任何一个共用点挂了，双机都救不了。这就是为什么真正的高可用方案强调「双电源、双链路、双上行设备」，而不是「双防火墙」。
• 配置错误。主机配错了策略，同步给备机，两台一起错，切换毫无意义。双机保证的是「一致」，不是「正确」。
• 容量击穿。主备备份模式下备机平时不转发，当主机宕机备机接管时，备机要独立承担全部流量。如果当初买备机的考量是「备机反正闲着，配个低配的就行」，那切换的一刻就是容量击穿的时刻。备机必须与主机的处理能力对等，这是选型红线。
• 链路级故障的秒级恢复。VRRP 切换永远是「检测到故障 → 重新选举 → MAC 收敛」的过程，几十毫秒到几秒的缺口不可避免。要做到接近零中断，需要链路聚合、BFD 快速检测等多层手段叠加。

一个诚实的结论：双机热备能把「设备故障导致的业务中断」从几小时压到几秒，但它压不到零，也压不住设计缺陷。把双机当成保险，而不是当成免死金牌。

28.2 华为设备配置详解

28.2.1 命令行基础速览

双机热备涉及四个命令族，先把它们认全：

注意提示符的变化：开了 hrp enable 之后，主设备的提示符会变成 HRP_M[USG6000E]，备设备变成 HRP_S[USG6000E]。看提示符就知道当前登的是主还是备，这是双机环境里最实用的一个习惯。

28.2.2 完整配置模板（主备备份 + VRRP + HRP）

下面这套配置在一台 USG6000E 上完整可用，另一台把 active 改成 standby、心跳对端地址对调即可。假设：上行接运营商（网段 203.0.113.0/24，虚拟网关 203.0.113.254），下行接核心（网段 192.168.10.0/24，虚拟网关 192.168.10.254），心跳口网段 10.200.0.0/24。

# 基础接口配置：上下行业务口 + 心跳口
system-view
sysname FW-A

interface GigabitEthernet1/0/1
 description TO-ISP
 ip address 203.0.113.10 255.255.255.0
 quit

interface GigabitEthernet1/0/3
 description TO-CORE
 ip address 192.168.10.10 255.255.255.0
 quit

interface GigabitEthernet1/0/2
 description HRP-HEARTBEAT
 ip address 10.200.0.1 255.255.255.0
 quit

# 接口加入安全区域
firewall zone untrust
 add interface GigabitEthernet1/0/1
 quit
firewall zone trust
 add interface GigabitEthernet1/0/3
 quit

# 配置 VRRP：上行 active、下行 active，表示本机为主
interface GigabitEthernet1/0/1
 vrrp vrid 1 virtual-ip 203.0.113.254 active
 quit
interface GigabitEthernet1/0/3
 vrrp vrid 2 virtual-ip 192.168.10.254 active
 quit

# 配置 HRP 心跳：指定心跳口与对端心跳地址
hrp interface GigabitEthernet1/0/2 remote 10.200.0.2

# 开启双机热备与自动同步
hrp enable
hrp auto-sync

# 保存配置
save

备机 FW-B 的差异只有三处：心跳对端地址改成 10.200.0.1；两个 VRRP 的 active 改成 standby；建议再加一条 hrp standby-device 明确声明本机是备机。

28.2.3 逐行讲解

几个必须展开讲透的细节。

第一，active / standby 看起来是「指定 VRRP 角色」，实际作用比这更深。

严格说，vrrp vrid 1 virtual-ip X active 这条命令本身只是给这个 VRRP 备份组声明「本组初始期望状态是 Master」。真正让整台设备上下行 VRRP 状态保持一致的，是 VRRP 之上的 VGMP（VRRP Group Management Protocol，VRRP 组管理协议） 机制。

VGMP 的作用可以这样理解：防火墙上下行各有一个 VRRP 备份组，它们是各自独立选举的。如果上行组选 A 当 Master、下行组选 B 当 Master，那么「从外到内的流量走 A、从内到外的流量走 B」，同一会话的两个方向被分到两台设备上，会话表对不上，业务直接瘫。

VGMP 就是来解决这个问题的：它把设备上所有 VRRP 备份组纳入一个 VGMP 组统一管理，整个组只有一个状态（Active 或 Standby），这个状态统一切换组内所有 VRRP 备份组的状态。所以「上下行的 VRRP 组必须同进同退」这件事，是由 VGMP 保证的，不是靠你两条命令都写 active 保证的。

启用双机热备后，VRRP 备份组的优先级不再独立生效，Master/Backup 的最终状态由 VGMP 的状态统一决定。理解这一点才能看懂现场为什么「VRRP 配置完全一样的两台设备，状态却不一样」。

实操结论：双机上所有 VRRP 组写同一个角色（主机全 active、备机全 standby）。 如果有一组写反，VGMP 无法把它们纳入同一个状态一致的组，就会出现「上下行都通、但特定业务不通」的诡异现象——因为两个方向的流量被分到了两台设备。

第二，心跳口配了就不要再手工对它做业务策略。 hrp interface GigabitEthernet1/0/2 remote 10.200.0.2 用于指定心跳口与对端心跳地址。关于心跳口要不要加入安全区域，不同版本与组网场景的官方指导并不完全统一（有的实施要求把心跳口加入 DMZ 等区域，有的要求保持独立），但有一条在所有场景下都成立：不要写任何会匹配到心跳报文的 NAT 规则，也不要写会拒绝心跳报文的策略。

# 心跳报文被 NAT 改写后，对端就认不出这是 HRP 报文，心跳直接断
# 同理，心跳口的源/目的地址也不能出现在任何 NAT 策略的地址条件里

按「心跳口 = 私有控制链路，不参与业务转发」这条原则处理，就不会踩到「心跳被自己拦掉」的坑。配完用 display hrp interface 确认心跳口状态是 up，用 display hrp state 确认对端可见。

第三，hrp auto-sync 同步什么？ 它同步的是配置（安全策略、NAT 策略、对象、地址池等），以及会话表和 Server-map 表。配置同步是「主设备改了自动推给备设备」，所以双机环境里只在主机上配业务，不要两台都手工敲一遍——两台都敲会互相覆盖，出现配置漂移。

第四，VRRP 的虚拟 MAC 建议开启。 vrrp virtual-mac enable 让虚拟 IP 使用固定虚拟 MAC 而不是主设备的物理 MAC，这样切换后上行交换机的 MAC 表不用重新学习，收敛更快。

# 开启虚拟 MAC，让切换后上层交换机的 MAC 表项无缝沿用
interface GigabitEthernet1/0/1
 vrrp virtual-mac enable
 quit
interface GigabitEthernet1/0/3
 vrrp virtual-mac enable
 quit

为什么这一条能显著缩短切换时间？想象上行交换机：它有张 MAC 表，记录「虚拟网关 IP 对应某个 MAC，从这个口出」。不配虚拟 MAC 时，虚拟 IP 用的是主设备的物理 MAC；切换后主设备下线，这个 MAC 不再出现，交换机要等 MAC 表老化（默认 300 秒量级）才重新学习备设备的 MAC，这期间流量被发往已经失效的口，表现就是「切换后很长一段时间不通，然后自己好了」。配了虚拟 MAC 后，两台防火墙用同一个虚拟 MAC 回应 ARP，交换机看到的 MAC 没变，只是出接口变了，通过 ARP/免费 ARP 快速更新，200 毫秒级就能收敛。

第五，VRRP 的心跳间隔与超时时间要调。 默认间隔比较保守，业务对切换时间敏感时可以调小：

# 把 VRRP 心跳间隔调到 1 秒（默认值因版本而异，按需调整）
interface GigabitEthernet1/0/3
 vrrp vrid 2 timer advertise 1
 quit

注意：间隔不是越小越好。间隔太小（比如 200 毫秒）在网络轻微拥塞时会误判主设备失效，来回切换，比不切换还糟。经验值是 1 秒间隔、3 倍超时（3 秒发现故障），再配合虚拟 MAC 的快速收敛，总体切换时间通常在 1~2 秒以内。

第六，双机模式下的路由要注意同步。 静态路由会被 HRP 自动同步，但动态路由协议（OSPF、BGP）的邻居关系不会同步——两台设备各自和上游路由器建邻居。如果只有主机建了邻居、备机没建，切换后备机没有路由，直接断网。所以双机部署时，先在两台上分别确认动态路由邻居是 Full/Established 状态，再开双机；也可以考虑用静态路由 + 浮动路由来规避这个问题。

28.2.4 配置同步与状态同步的细节控制

hrp auto-sync 是一把梭，把所有能同步的都同步。但真实环境里经常需要更细的控制，比如「配置同步但要停掉会话同步」「某个对象不同步」。常用命令如下：

# 查看当前同步状态与同步开关
display hrp configuration

# 手工执行一次配置同步（主机上）
hrp sync config

# 手工触发一次会话表同步
hrp sync session-table

# 关闭某类内容的同步（例如临时停止会话同步做演练）
undo hrp sync session-table

同步方向是单向的：主机 → 备机。 备机上的业务配置不需要手工维护，但有几类配置是每台设备独立的、不同步的：接口上的物理 IP、VRRP 的 active/standby 角色、心跳口的地址、hrp standby-device 声明。这四类你要在两台上分别配，其余的都只在主机上配。

这个区分极其重要。新手最常见的翻车方式是：登录备机想「补充」一条安全策略，敲完发现过一会儿配置又变回去了——因为主机定期同步会把它覆盖掉。记住口诀：业务配置只配主机，身份配置各配各的。

28.2.5 主备切换的触发条件

双机不会无缘无故切换，触发条件是明确的几类：

如果想排除「某个不重要的接口 down 导致误切换」，可以在主机上把它从 HRP 监控里摘掉：

# 让 HRP 监控某个接口，该接口故障时触发主备切换
hrp track interface GigabitEthernet1/0/1

命令语法已核实：hrp track interface <接口类型 接口编号>（华为热备命令参考，例 hrp track interface GigabitEthernet0/0/3）。另外官方补充了一条重要细节：当监控对象是 Eth-Trunk 时，缺省会把成员口的故障也算进来——即使 Eth-Trunk 本身还是 up，成员口 down 也会触发切换（可用 undo hrp track trunk-member enable 关闭这一行为）。所以如果不想让某条 eth-trunk 的成员抖动引起切换，要显式关掉这个联动。

同时补两个第一轮没写清的关键命令：会话同步与配置同步。

# 会话表镜像（快速备份），双机平滑切换的关键
hrp mirror session enable

# 允许在备用设备上做部分配置，并支持双向配置同步
hrp standby config enable

没有 hrp mirror session enable，切换后旧会话全丢——这是「看起来一切正常、切换时断业务」的根因，第 27.6 节的真实案例讲的就是这件事。

这个能力在双机部署里很有用：机房常常会在下行接一堆不重要的接口（监控、打印服务器），如果这些接口 down 就切主备，会造成不必要的切换抖动。

28.2.6 负载分担模式的配置骨架

把两个 VRRP 组的 active/standby 交叉配置，就得到负载分担：A 在上行是主、下行是备；B 在上行是备、下行是主。报文进来后按方向分流到不同设备。

# FW-A：上行主、下行备（FW-B 反过来配）
interface GigabitEthernet1/0/1
 vrrp vrid 1 virtual-ip 203.0.113.254 active
 quit
interface GigabitEthernet1/0/3
 vrrp vrid 2 virtual-ip 192.168.10.254 standby
 quit

# 负载分担必须分段 NAT 端口资源，否则两台设备端口撞号
# 只在主机上配这条，备机会通过 HRP 同步自动生成 secondary-group
hrp nat resource primary-group

这条命令的作用是：把地址池中每个公网地址的端口号空间一刀切两半，主机只用前半段、备机只用后半段，从根本上避免端口冲突。漏了它，负载分担模式下的故障现象是「时通时不通、重连就好了」，极难排查。

一个重要的实施细节（官方说法）：只需在主机上配置 hrp nat resource primary-group，备设备会通过 HRP 同步自动生成 hrp nat resource secondary-group，不需要在备机上手工配。 这与「只配主机」的通用纪律一致——如果你在备机上也手工敲 secondary-group，反而可能在后续同步时产生配置漂移。

另外两件事也要一起记住：

1. NO-PAT 方式的负载分担另有要求：当 NAT 方式是 NO-PAT 时，要配 nat resource load-balance enable，把地址和端口的分配集中到一台设备上执行，保证两台分配的地址端口不冲突。官方提示这条命令会增加心跳口流量。
2. NAT 地址池不能包含主机/备机的接口地址。否则上行设备请求该地址的 ARP 时，两台会同时回应，造成 ARP 冲突。同理，NAT 策略里的源/目的地址也不能包含心跳口地址，否则心跳报文被 NAT 改写。

28.2.7 双机热备的验证步骤

验证要分四层做，只做第一层就交付是常见错误。

第一层：看主备状态。 两台设备上分别执行：

# 查看 HRP 主备状态、同步状态、心跳口状态
display hrp state

正常情况下主机输出里有 Role: active，备机有 Role: standby，且 Hello packet interval 正常、Configuration synchronization 为开启。

# 看心跳口是否 up、收发计数是否增长
display hrp interface

第二层：看 VRRP 状态。 主设备上两个 VRRP 组都应是 Master，备设备上都是 Backup：

# 查看 VRRP 组成员与状态
display vrrp

第三层：看会话同步。 这是最关键的一层。在主设备上打一条持续的 PING 或者持续访问一个网页，然后到备设备上查会话表：

# 在备机上查会话表，能看到主设备上的会话才说明状态同步生效
display firewall session table

如果备机的会话表是空的，说明 hrp auto-sync 或会话同步没生效——此时切换必断业务。

第四层：真做一次切换。 把主设备的下行接口手动 shutdown（或者在业务低峰期直接断电），观察：PING 是否丢包、丢几个包、切换后 PING 是否自动恢复；同时在备机上 display hrp state 确认变成 active。

回切：把主设备接口恢复 undo shutdown，观察主设备是否自动抢回主角色（取决于是否配置了抢占），以及回切过程中业务是否再次中断。回切的质量和切换一样重要——很多现场切换是平滑的、回切却断了 30 秒，原因通常是回切时会话表已经过期。

28.2.8 双机环境的变更纪律与升级流程

双机热备最大的运维价值不在「切换」，而在「可以安全变更」。有了双机，你可以做到「业务不中断地升级一台设备」，前提是遵守纪律：

升级流程里最容易出错的一步是「切到备机之后忘了切回来」，导致长期运行在非预期的主机位置上，下次维护时按文档操作就会踩空。建议在变更记录里写清「当前主设备是哪一台」，并在设备命名上做标记（比如主机 FW-A、备机 FW-B），用一个文档记录当前主备角色。

28.3 H3C 设备配置详解

28.3.1 H3C 的两种路线：IRF 与双机热备

H3C 做防火墙高可用有两条完全不同的路线，选哪条决定后续所有配置：

本章重点讲双机热备（RBM），因为它是 H3C 官方当前主推的方案，而 IRF 与 VRRP 组网会在 27.3.4 给出骨架。这里先澄清一个常见误解：IRF 本身不是高可用方案，它把两台设备变成一台，如果这台「虚拟设备」整机故障（比如共因故障、软件 bug），两台会一起挂。IRF 解决的是「管理复杂度和链路利用」，真正的高可用还得靠上面的双机热备或 VRRP。

28.3.2 完整配置模板（RBM 双机热备）

H3C Comware V7 的双机热备核心命令族是 remote-backup group。两台设备用一组独立的以太网接口做控制通道和数据通道。

# 基础接口配置
system-view
sysname DeviceA

interface GigabitEthernet1/0/1
 description TO-ISP
 ip address 203.0.113.10 24
 quit

interface GigabitEthernet1/0/3
 description TO-CORE
 ip address 192.168.10.10 24
 quit

# HA 通道接口（控制通道 + 数据通道）
interface GigabitEthernet1/0/2
 description HA-CHANNEL
 ip address 10.200.0.1 24
 quit

# 接口加入安全域
security-zone name untrust
 import interface GigabitEthernet1/0/1
 quit
security-zone name trust
 import interface GigabitEthernet1/0/3
 quit

# 配置 Track 监控上下行业务接口
track 1 interface GigabitEthernet1/0/1
 quit
track 2 interface GigabitEthernet1/0/3
 quit

# 双机热备：本端与对端 HA 地址、数据通道接口
remote-backup group
 remote-ip 10.200.0.2
 local-ip 10.200.0.1
 data-channel interface GigabitEthernet1/0/2
 quit

# 开启双机热备
hot-backup enable

# 保存
save force

DeviceB 的差异：local-ip 与 remote-ip 对调，并声明本机为备设备：

# DeviceB：角色声明为 secondary，并关闭本机的备份报文回程（由主设备驱动）
remote-backup group
 remote-ip 10.200.0.1
 local-ip 10.200.0.2
 data-channel interface GigabitEthernet1/0/2
 device-role secondary
 undo backup-mode
 quit

28.3.3 逐行讲解与差异标注

有三条使用限制必须记牢，它们直接决定「配完能不能起来」：

1. 主备设备的型号必须一致，软件版本也必须一致。版本不一致时状态同步会失败，表现为切换后会话丢失。
2. 建立控制通道的接口必须一致（两台都用电口就都用电口，位置也要一致），对应位置的接口必须加入相同的安全域。这条限制说明 H3C 是把两台设备「按位置对齐」来理解的，接口位置错开一位，整个同步都会错乱。
3. 双机热备只能与 VRRP 标准模式配合，不支持 VRRP 负载均衡模式。这条是硬限制，想负载分担得另想办法。

28.3.4 IRF + VRRP 组网骨架

如果确实要做 IRF，H3C 防火墙的 IRF 配置在思路上与交换机一致，成员设备通过 IRF 端口互联形成一台虚拟设备。

# IRF：设置成员编号、优先级，绑定物理口到 IRF 端口
irf member 1 priority 32
irf-port 1/2
 port group interface GigabitEthernet1/0/25
 quit
interface range GigabitEthernet1/0/25
 shutdown
 quit
irf-port-configuration active

⚠ 待核实：待核实 H3C F1000 系列防火墙的 IRF 端口命令与交换机是否完全一致（防火墙多为 irf-port 1/2 + port group interface），需按 F1000 型号的 IRF 配置指导确认

IRF 起好之后，对外仍然需要 VRRP 或双机热备来做网关冗余，因为 IRF 只保证「一台虚拟设备」，不保证「一条链路」，上行交换机到 IRF 的两条线还是需要 VRRP 或者链路冗余协议来兜底。

诚实地说：「IRF + VRRP」在防火墙上并不是 H3C 的主流推荐组网，主流是「双机热备（RBM）」。教材里写 IRF，是为了解释这条路线的存在和局限，避免读者在网上看到 IRF 教程就误以为那是防火墙高可用的标准答案。

28.3.5 H3C 双机热备的验证

# 查看双机热备状态（主备角色、同步状态、通道状态）
display remote-backup-group status

# 查看 HA 通道与 track 状态
display track

# 在备机上查会话表，确认状态同步
display session table

display remote-backup-group status 里要看三个字段：Role（主/备）、Data channel state（数据通道是否 up）、Sync status（同步是否正常）。三个都对，双机才算起来。

28.3.6 H3C 双机热备的状态与切换机制

H3C 的双机热备在内部维护两套状态，理解它们才能看懂排障输出：

第一套是管理角色的主备。 两台设备协商出一个主管理设备和一个从管理设备，主管理设备负责把配置同步给从管理设备。这套状态的选举因素是：设备优先级、设备是否健康、非缺省 Context 的数量。一般企业场景没有 Context（虚拟防火墙），选举结果就是「谁先起来谁当主」，或者按配置的优先级定。

第二套是业务主备。 负责实际转发流量。业务主备的判定又与 Track 项、监控接口、监控 VLAN 相关——当主设备的被监控接口 down 掉时，业务主角色切到对端。

两套状态不一致是常见的排障迷惑点：display remote-backup-group status 显示 Role: primary 的主管理设备，业务角色可能是备，因为它的下行接口挂了。看到「管理主、业务备」不要以为配错了，去看 Track 项状态就明白了。

H3C 还有三个「触发切换」的具体条件值得记住：

1. 主设备上 HA 监控的接口故障（track / track interface / track vlan）。这是最常见的切换原因。
2. 主设备上关闭了与备设备编号相同的非缺省 Context。有虚拟防火墙的环境才涉及。
3. 主设备的健康值变化。系统根据 CPU、内存等综合评判健康值，健康值过低会触发业务主备重新竞选。

这三条里，第一条是运维能直观控制的，所以「哪些接口参与监控」这个决定要慎重：只监控真正影响业务出口的接口，把打印服务器、监控摄像头这类不影响上网的接口排除掉，否则会出现「一楼摄像头网线松了，全公司出口切换到备机」的荒唐事。

28.4 华为 / H3C 命令对照表

28.5 配置验证

28.5.1 验证清单

双机热备的验证不能只看「状态是 Master」，要按下面的清单一项项过：

第 5 项和第 7 项是真正的分水岭。只验证 1~4 就交付的现场，切换时断业务的比例非常高。

28.5.2 期望输出片段

华为主机 display hrp state 的典型输出：

The firewall's role is active.
The firewall's config state is: Candidate.

Hello interval: 1000 ms. Hello holdtime: 3000 ms.
...
HRP link status: up

备机则是 The firewall's role is standby.。如果主机显示 Role: unknown，说明心跳还没起来，两台设备谁也没收到对方，常见原因是心跳口地址配错或心跳口被加进了安全区域。

28.5.3 切换过程中的合理丢包

切换时丢几个包是正常的。经验值是：同机房直连心跳、VRRP 快速切换，丢包在 1~5 个 ICMP 报文的范围内（1 秒以内）。如果丢包超过 10 个（10 秒以上），说明切换链路有问题，按下面顺序查：

1. VRRP 是否有多个组在争抢（display vrrp）；
2. 上行交换机的 ARP/MAC 表是否需要重新学习（看是否开了 vrrp virtual-mac enable）；
3. 备机是否真正持有会话表（display firewall session table）；
4. 路由是否需要收敛（如果有动态路由协议，切换后要重新收敛，这段时间是硬损失）。

28.6 排错与故障树

28.6.1 双机热备起不来的故障树

28.6.2 一个真实的排错案例

现象：双机配置完成后一切正常，display hrp state 显示主机 active、备机 standby，VRRP 全对，PING 也通。但一个月后真的发生了切换，用户报「断网 2 分钟」。

排查过程：

1. 切回后登备机 display firewall session table，发现会话表满的——这个正常，因为切换后它接收了新会话；
2. 但继续查历史日志，发现切换前备机的会话表是空的；
3. 追查配置，hrp auto-sync 配了，但 hrp sync session-table 被前一位工程师在调试时 undo 掉了，理由是「会话表同步占心跳带宽」；
4. 恢复 hrp sync session-table，并复核心跳口带宽后，问题解决。

这个案例的教训是：验证双机必须验证「备机能不能看到主机正在使用的会话」，而不是只看状态灯。很多现场就是这样「看起来全对，切换就出事」。

第二个案例：双主（两台都是 active）

现象：配置完双机后，内网时通时断，间隔几十秒就抖一下，display hrp state 在两台上看都是 active。

排查步骤：

1. 两台都显示 active，首先怀疑心跳不通。在两台上 display hrp interface，看 Tx/Rx 计数——A 的 Tx 在涨但 Rx 为 0，B 也是 Tx 涨 Rx 为 0；
2. 说明心跳报文发出去了但对方没收到。检查心跳口配置：A 的心跳口地址是 10.200.0.1/24，B 的心跳口地址写成了 10.200.0.1/24——两台配了同一个地址；
3. 改成 10.200.0.2/24 后心跳恢复，双主消失。

这个案例的教训是：心跳口两端的地址必须在同一网段但不同地址，而且要在最后一步才配 hrp enable——先配地址、验证 PING 通，再开双机。顺序反了，双主期间可能已经把业务搞乱，还得手工恢复。

补充：双主还有另外两类原因，别只盯着心跳。

1. 心跳通但 VGMP 协商不出结果。两台设备 VGMP 组 ID 一致、优先级相同时，可能出现长时间协商不定的情况。检查 display hrp state 里的 VGMP 组信息与优先级。
2. 设备更换或重启时的角色声明错误。双机中的设备是静态声明 VRRP 角色的，更换设备或重启后必须声明与原来相同的角色（active），否则 VGMP 无法正确协商。若新设备声明成 standby，就会出现「两台都是备、谁都不转发」，全网中断。

一句话总结：查双主先看心跳，再看 VGMP 的状态与优先级，最后才看 VRRP 的配置。

第三个案例：回切后业务再断一次

现象：主设备故障切到备机，业务恢复；主设备修好后自动抢回，结果业务又断了 40 秒。

原因：回切时业务流量瞬间从备机回到主机，但主机的会话表在它下线期间是「冻结」的——它不知道这期间新建的会话，业务被踢回主机后发现会话不存在，要求重新握手；同时上行交换机的 MAC 表要重新学习。

解法：配置回切延迟，让主机修好后先观望一段时间再抢主：

# 主机上配置 300 秒（5 分钟）的回切延迟，避免故障抖动时来回切
hrp preempt delay 300

注意单位是「秒」，不是分钟。 华为官方 AR/USG 热备命令参考里的示例是 hrp preempt delay 100，说明为「Set the HRP preemption delay to 100s」（https://support.huawei.com/enterprise/en/doc/EDOC1100460862/e1f9faea ）。所以想要 5 分钟必须写 300；写 5 只是 5 秒，等于没延迟——这是很容易踩的一个坑，我第一轮就写错过。

抢占功能的开关是 hrp preempt enable / undo hrp preempt enable（默认开启）。现场另一种做法是直接关掉抢占，让故障恢复后不自动回切，由运维在业务低峰手工切换。

H3C 侧的对应命令是 delay-time（注意语义不同：H3C 叫「HA 流量回切」，且缺省是关闭的、不回切），命令已核实：

# H3C：开启 HA 流量回切并设置延迟（单位：分钟，范围 1~1440）
remote-backup group
 delay-time 5
 quit

依据 H3C 官方《双机热备（RBM）命令》（https://www.h3c.com/cn/d_202211/1715902_30005_0.htm ）：delay-time 取值范围 1~1440，单位是分钟；缺省情况下 HA 流量回切功能处于关闭状态，即原主设备恢复后流量不自动回切。官方还特别提示：HA 双主模式下必须开启此功能，否则一条链路故障恢复后流量无法回切，双主就名存实亡。

延迟抢占的实际意义是：回切比切换更该保守。切换是被动发生、必须快；回切是主动发生、可以从容，等主设备稳定运行几分钟、会话都建立起来了再切回去，业务影响最小。

28.7 新手踩坑与注意事项

1. 两台都写 active——直接双主，两台都认为自己该转发，上行交换机 MAC 表反复翻转，全网抖动。第二台必须写 standby 或配 hrp standby-device。
2. 心跳口加进了安全区域——心跳报文被当业务流量过策略，通常被默认拒绝，症状是角色一直 unknown。心跳口要独立，不加区域。
3. 备机忘配 hrp enable——两台都配了 VRRP 但备机没进双机模式，切过去就像没配。
4. 业务配置在备机上也敲了一遍——主机同步时覆盖备机，出现「配了又变回去」的灵异现象。业务配置只配主机。
5. 只验证状态不验证会话同步——最常见的「假成功」。交付前必须在备机上查会话表。
6. 上下行 VRRP 用同一个 vrid——虽然不必然出错，但排障时极易混淆，建议上下行用不同 vrid。
7. 心跳线用业务网线——心跳和业务流量抢带宽，高负载时心跳超时导致误切换。心跳必须独立链路或独立的 VLAN。
8. 备机也接了同一台交换机做业务转发——端口没隔离好会出现同一会话从两台设备发出，上行交换机端口安全会报警或丢包。
9. 升级时两台一起升——双机环境升级必须「先备后主、逐台升级、升一台恢复双机后再升另一台」，一起升等于单点。
10. 回切没测——很多人只测切换不测回切。回切时若会话已过期，业务会二次中断。建议配 hrp preempt delay 延迟抢占，等业务空闲再回切。
11. 双机模式下还开了接口的 DHCP 服务——DHCP 服务器在主机上，切换后如果 DHCP 服务没同步，新终端拿不到地址。DHCP 需要单独确认同步行为。
12. 负载分担漏配 NAT 端口分段——现象是「时通时不通」，排查一整天都找不到规律。

28.8 本章小结

28.8.1 要点清单

• 双机热备 = VRRP 定主备（数据面）+ HRP/RBM 同步（控制面），三件事：主备协商、配置同步、状态同步。
• 华为用 hrp interface + hrp enable + hrp auto-sync + VRRP active/standby；H3C 用 remote-backup group + hot-backup enable + device-role。
• 心跳口必须独立、不加安全区域。
• 业务配置只在主机上配，身份配置（IP、角色、心跳地址）两台各配。
• 验证必须做四层：主备状态 → VRRP → 会话同步 → 真实切换与回切。
• H3C 双机热备有限制：同型号同版本、控制/数据通道接口位置一致、对应接口加入相同安全域、不支持 VRRP 负载分担模式。
• 负载分担模式必须做 NAT 端口资源分段，否则端口冲突导致「时通时不通」。

28.8.2 自测题

1. 双机热备的「状态同步」和「配置同步」分别解决什么问题？只做一个会发生什么？
2. 为什么心跳口不能加入安全区域？加入了会出现什么现象？
3. 备机上手工配了一条安全策略，过一会又变回去了，原因是什么？
4. 切换时丢了 3 个 ICMP 包是正常的吗？丢 30 个说明什么？
5. H3C 双机热备的三条硬性限制是什么？
6. 备机平时不转发流量，是不是可以买低配型号省钱？
7. 为什么说「回切比切换更应该保守」？

1. 状态同步同步会话表和 NAT/Server-map 映射，保证切换后已有连接不断；配置同步把主机的策略配置推给备机，保证备机的判断规则一致。只做配置同步：切换后会话全丢，所有 TCP 断开重连；只做状态同步：备机规则不对，会话同步过来也可能被策略丢弃。
2. 心跳口是设备之间的私有控制通道，不属于任何业务区域。加入区域后心跳报文会走安全策略检查，默认被拒绝，心跳不通导致主备关系一直 unknown。
3. 主机定期把配置同步到备机，覆盖了备机上的手工修改。业务配置应只在主机上配。
4. 3 个包正常（1 秒内完成切换）；丢 30 个说明切换耗时过长，需查 VRRP 多组争抢、MAC 重新学习、备机会话是否为空、路由收敛时间。
5. 主备型号必须一致、软件版本必须一致；控制通道与数据通道接口必须位置一致且对应接口加入相同安全域；仅支持 VRRP 标准模式，不支持负载分担模式。
6. 不可以。主备备份模式下备机接管时要独立承担全部流量，备机处理能力必须与主机对等，否则切换瞬间就容量击穿。
7. 切换是被动发生、必须快；回切是主动发生、可以从容。回切时主机的会话表在离线期间是冻结的，立刻抢主会导致业务二次中断，因此应配抢占延迟，等主机稳定、会话重建完成后再回切。

关于本书：《华为 / H3C 网络设备典型功能配置详解》—— 面向国内高校/企业网络环境， 华为 VRP 与 H3C Comware 双厂商并排配置的实操教材，共 43 章。 全书所有命令尽量有官方出处，查不到的显式标注「待核实」。 返回系列目录