开头得先说清楚一件事：HCL模拟器里做防火墙主备实验，真正的难点不在配置命令本身，而在设备和镜像的坑。我最早想用HCL 2.1.2自带的F1000镜像做双机热备，结果HA命令敲进去各种不生效，后来换成HCL 3.0.1自带的F1060，实验才顺利跑通。这中间还夹杂着Win11下设备启动失败、VirtualBox版本冲突、备设备配置不同步这些糟心事。所以这篇文章我会把整个实验拆开来讲，包括模拟器的选型和排错、路由模式主备的组网逻辑、VGMP和HRP的原理、完整的命令行配置过程、主备切换的实测数据，以及HCL里做HA实验特有的坑。适合两类人：一类是想在HCL里把防火墙HA实验跑通的学生和考证党，另一类是准备在现网部署双机热备、想先在模拟器里验证配置方案的工程师。

1. 实验前必读：HCL模拟器的选型与启动问题

很多人卡在HCL的第一步就是设备起不来，尤其是Win11系统，论坛上一搜一大片启动失败的问题。这里我先说结论：HCL 3.0.1配F1060防火墙镜像，是当前做HA实验最省心的组合。

1.1 为什么选F1060而不是老版本自带的F1000

HCL老版本里自带的防火墙是F1000，部分版本的镜像对HA支持不完整，具体表现是hrp enable命令能敲进去，但hrp interface后面的参数不认，或者备设备同步配置后状态一直不对。换到HCL 3.0.1自带的F1060后，HA相关的命令全部正常，VGMP组状态也能正确显示Master和Standby。

如果你打开HCL设备列表发现能拖出一个SecPath F1060，那就用这个。F1060的接口数量够用，性能也在模拟器里绰绰有余。老版本的F1000不是说绝对不行，但为了减少变量，建议直接上F1060。

1.2 Win11下设备启动失败的处理链路

HCL设备启动失败大部分情况下不是HCL本身的问题，而是它依赖的VirtualBox和新系统不兼容。我整理一下排查顺序，按步骤走基本能解决：

1. 确认CPU虚拟化已开启。打开任务管理器，性能选项卡里看"虚拟化"是否为"已启用"。如果没启用，进BIOS开Intel VT-x或AMD-V。
2. 右键HCL，选择"以管理员身份运行"。这步不是玄学，HCL需要访问VirtualBox的驱动和服务，普通权限下经常起不来。
3. 如果设备一直停在"正在启动"，去VirtualBox里看一眼虚拟机的状态。HCL启动设备时会在VirtualBox里生成对应的虚拟机，如果VirtualBox版本不兼容，虚拟机状态会显示异常。HCL 3.0.1对VirtualBox版本有要求，版本不对直接卸载重装HCL自带的VirtualBox。
4. 检查VirtualBox Host-Only Network网卡是否存在。HCL依赖这块虚拟网卡做设备互联，如果设备启动失败后网卡没了，可以在VirtualBox的全局设定里重新添加。
5. 启动失败后想重新拖设备，建议先关闭所有正在运行的设备，再从左侧设备列表重新拖入。注意直接删设备会清空该设备的配置，如果已经配了东西，记得先导出cfg文件。

这套流程我每次在Win11上重装HCL都会走一遍，走到第四步一般都能解决。启动失败的问题不解决，后面HA实验根本没法做，所以第一步先把这个坑填平。

2. 路由模式主备的组网逻辑与IP规划

2.1 路由模式到底解决了什么问题

防火墙的转发模式通常分两种：路由模式和透明模式。透明模式相当于一台带ACL的二层交换机，接口不配IP，直接串联在原有网络链路里，对现有网络改动最小。路由模式则把防火墙当成一台三层设备，每个业务接口都配IP，数据包在防火墙内部走三层转发，适合做网络边界隔离。

本次实验用路由模式，意思就是防火墙的内外网接口都配IPv4地址，内网主机的网关指向防火墙内网口，防火墙外网口和上游路由器通过三层路由互通。主备模式下，两台防火墙对外呈现的网关地址是同一个，对内对外来说，谁在前面转发流量并不重要，重要的是任何时候都必须有一台防火墙在正常工作。

2.2 实验拓扑里每根线的用途

拓扑里需要三根关键链路：上行链路、下行链路、心跳链路。上行链路接外网侧路由器，模拟运营商环境；下行链路接内网主机或者核心交换机；心跳链路是两台防火墙之间的专属通道，专门用来协商主备状态和同步会话信息。心跳口绝对不能和业务口混用，如果心跳链路断了，两台防火墙会认为对方挂了，可能出现双主的情况，导致业务流量来回震荡。

在HCL里我习惯把心跳口放在最后一两个接口上，比如G1/0/6。这么做只是为了和业务口区分明显，浏览配置时不容易看岔。实际生产环境中，心跳口通常用专门的一对物理接口，有条件的话还会做链路聚合提高可靠性，本文实验先用单根心跳线就够了。

2.3 IP地址规划表

注意看表格里FW-B的业务口IP写的是"由主设备HRP同步"，这不是偷懒，而是这道实验的正确姿势。备设备在加入HA之前，根本不需要手动配置业务接口的IP，配置由主设备通过HRP协议自动同步过来。如果你在备设备上手动配了和主设备不同的IP，反而会对HRP同步产生干扰，这是新手最容易踩的坑。

3. VGMP和HRP：主备协商与配置同步的核心原理

网上很多教程上来就给命令，不解释为什么，结果读者配完不知道为什么备设备接口和主设备IP一样却不冲突，也不知道切换时发生了什么。我来把这层窗户纸捅破。

3.1 VGMP负责管主备状态

VGMP的全称是Virtual Group Management Protocol，它干的事就是让两台防火墙组成一个"虚拟组"，通过心跳链路互相通报状态，然后在组内选出一个Master和一个Standby。Master设备正常转发流量，Standby设备实时待命。VGMP判断主备的依据包括设备自身的优先级、接口状态和路由状态。

打个比方，VGMP就像一个团队的班长选举机制。两台防火墙商量好谁是正班长谁是副班长，正班长每天向副班长报告"我还活着"，副班长随时准备接班。正班长如果突然不吭声了，副班长等一个超时时间就自动转正。

VGMP组里会监控大量接口和路由信息，如果主设备的某个业务接口down掉了，它会在心跳报文中把接口状态的变化告诉备设备。接口数量的变化会影响VGMP组的优先级比较，最终可能触发切换。

3.2 HRP负责同步配置和会话

HRP全称是H3C Replication Protocol，它的职责是把主设备上的配置命令、会话表项实时复制到备设备。这就是为什么备设备即使没有手动配置业务口，也能在接管后直接进入工作状态——因为主设备已经把所有配置和会话状态提前"喂"给它了。

HRP的同步分为两层：第一层是配置同步，你在主设备上敲的每一条配置命令，只要是在HRP建立之后敲的，都会实时复制到备设备上；第二层是会话热备，主设备上新建立的TCP或UDP会话会同步到备设备上，一旦发生切换，备设备手里已经有完整的会话表，业务连接可以做到几乎无感知切换。

可以这么理解：VGMP决定"谁来干活的这个问题"，HRP解决"接班的人有没有准备好"这个问题。两个协议在心跳链路上协同工作，一个管状态，一个管数据，缺一不可。

3.3 为什么两台设备可以共用同一个IP

这是很多人想不通的地方。主备模式下，HRP会把主设备的接口IP同步给备设备，所以FW-B的业务口IP和FW-A一样都是1.1.1.1和10.1.1.1。但两台防火墙接在同一台路由器和同一个主机网络上，IP相同不应该冲突吗？

答案在于VGMP对接口的管控。备设备在Standby状态下，虽然物理接口是up的，但VGMP不允许接口参与数据转发，具体表现就是不会应答ARP请求，也不会转发数据帧。也就是说，备设备的业务口处于"半睡半醒"的备用状态，对网络中的其他设备来说，它只是一个沉默的备份节点，不会和主设备抢答。一旦VGMP状态切换为Master，接口才"醒"过来，立刻开始应答ARP和转发流量。

理解了这个机制，后面看display current-configuration时看到两台设备配置一模一样，就不会觉得是配置同步事故了。

4. 完整配置过程：两台防火墙的命令级操作实录

接下来是重头戏，我把两台防火墙的完整配置过程按顺序写出来。这里我必须强调一个配置顺序问题：HRP的增量同步决定了业务配置必须在HRP建立之后再做。H3C的HRP同步机制是增量式的，主设备上在hrp enable之后执行的配置命令才会实时备份到备设备，之前已有的历史配置不会批量推过去。所以正确的顺序是：

1. 主备防火墙都先只配好心跳口IP和必要的管理口
2. 主设备开启HRP
3. 备设备开启HRP并强制设置为Standby
4. 然后在主设备上配置业务接口、安全域、安全策略、路由
5. 这些配置自动同步到备设备

4.1 主设备FW-A的配置过程

先把系统名称改成FW-A，方便区分：

system-view sysname FW-A

配心跳口IP。心跳口是G1/0/6，这个接口必须确保是三层口，在F1060镜向上默认就是三层口，如果显示二层口就先执行port link-mode route切换为三层口：

interface GigabitEthernet1/0/6 port link-mode route ip address 10.10.10.1 255.255.255.0

开启HRP并指定心跳接口的远端地址。这里的remote地址就是FW-B的心跳口IP：

hrp enable hrp interface GigabitEthernet1/0/6 remote 10.10.10.2

开启HRP后，FW-A立刻开始通过G1/0/6向FW-B方向发送心跳报文，但此时FW-B还没配置好，所以状态显示不一定正常，不用管它。接着配置业务接口：

interface GigabitEthernet1/0/0 port link-mode route ip address 1.1.1.1 255.255.255.0 quit interface GigabitEthernet1/0/1 port link-mode route ip address 10.1.1.1 255.255.255.0 quit

然后配置安全域。F1060上接口必须归属到安全域，跨域流量才能被安全策略放行。Untrust域放外网接口G1/0/0，Trust域放内网接口G1/0/1：

security-zone name Untrust import interface GigabitEthernet1/0/0 quit security-zone name Trust import interface GigabitEthernet1/0/1 quit

配置安全策略。这个实验先不引入NAT，聚焦HA本身，所以策略先做全部放行，等HA跑通了再收紧也不迟。放行Trust到Untrust和Untrust到Trust两个方向的流量：

security-policy ip rule name trust-to-untrust source-zone trust destination-zone untrust action pass quit rule name untrust-to-trust source-zone untrust destination-zone trust action pass quit

配静态路由。内网主机走10.1.1.0/24网段，外网回程路由在路由器上配。FW-A上需要一条回程路由，让外网返回内网的数据包能找到路径：

ip route-static 10.1.1.0 255.255.255.0 1.1.1.2

这里其实内网口直连10.1.1.0/24，系统自动生成直连路由，不需要额外配。真正需要配的是外网的回程路由，但外网只有1.1.1.0/24这个直连网段，所以FW-A在路由部分其实没有太多事可做。为了完整演示，我在路由器上模拟一个外网服务器地址8.8.8.8，然后需要在FW-A上加一条去往8.8.8.8的静态路由：

ip route-static 8.8.8.8 255.255.255.255 1.1.1.2

所有配置完成后，在FW-A上执行display hrp state，此时因为FW-B没起来，状态可能是Master，或者是协商中的状态。不用着急，继续配FW-B。

4.2 备设备FW-B的配置过程

FW-B只需要配心跳口和管理地址，业务口完全不用碰。先改名字并配心跳口IP：

system-view sysname FW-B interface GigabitEthernet1/0/6 port link-mode route ip address 10.10.10.2 255.255.255.0 quit

然后开启HRP。注意，FW-B上也必须指定remote地址，指向FW-A的心跳口：

hrp enable hrp interface GigabitEthernet1/0/6 remote 10.10.10.1

接下来最关键的一步：把FW-B强制设置为备设备。执行这条命令后，FW-B会主动请求从FW-A同步配置，原本空白的业务接口、安全域、安全策略、静态路由会全部出现在配置里。

hrp standby-device

执行完后等几秒，让配置同步完成，然后验证一下状态：

display hrp state

正常情况下FW-A显示Master，FW-B显示Standby。如果FW-B状态不对，检查心跳线是否连接正常，或者display hrp interface确认心跳接口和remote地址配对是否正确。

4.3 验证配置同步结果

在FW-B上执行display current-configuration，你会发现G1/0/0的IP变成了1.1.1.1，G1/0/1变成10.1.1.1，安全域、安全策略、静态路由全部和FW-A一致。这就是HRP同步的功劳。很多第一次做这个实验的人到这里会慌，以为两台设备IP重复了，其实这正是主备HA的正常形态。

再上FW-A上确认一下主设备状态和会话备份情况：

system-view hrp mirror session enable

hrp mirror session enable用于开启会话快速备份，让主设备上的实时会话表能及时同步到备设备。这条命令在部分F1060镜像上可能默认开启，也可能不支持，敲进去没报错就是好的。如果提示命令不存在，也不用强求，本实验用ping来验证切换效果，会话备份不是关键路径。

5. 主备切换实测：模拟故障后的真实表现

配置完成后，我按照生产环境的验收思路，对主备切换做了完整测试。这部分数据可以让读者直观感受切换过程中会发生什么。

5.1 主备状态确认

在FW-A和FW-B上分别查看HA状态，确认FW-A是Master、FW-B是Standby后，再确认业务端到端连通性。在Host上用ping测试到外网服务器8.8.8.8的连通性：

ping 8.8.8.8

能通就说明路由模式的业务转发正常。接下来开始做切换测试。

5.2 模拟主设备上行接口故障

为了让切换过程可观测，我在Host上开一个持续ping：

ping 8.8.8.8 -t

然后在FW-A上把上行接口shutdown掉，模拟主设备外网链路中断：

system-view interface GigabitEthernet1/0/0 shutdown

观察Host上ping的输出，通常会出现3到5个丢包，然后恢复。这个丢包数量比真实设备多一些，原因后面会讲。丢包停止后，去FW-B上执行：

display hrp state

FW-B的状态已经从Standby变成Master，说明切换成功。此时FW-B顶替FW-A接管了所有业务。在HCL模拟器里，这个过程可能要几秒钟，不像真实设备那么快，但整个状态变化逻辑是完整可验证的。

5.3 恢复原主设备并验证回切

在FW-A上恢复接口：

interface GigabitEthernet1/0/0 undo shutdown

默认情况下VGMP具有抢占能力，FW-A恢复后会重新变回Master。等待一段时间后再次查看状态，FW-A应该显示Master，FW-B显示Standby。注意HCL模拟器里的回切动作不像真实设备那么坚决，有时需要等十几秒甚至更久，期间ping可能出现少量丢包，这是模拟器时序慢导致的，不用太担心。

5.4 切换过程中的丢包和ARP问题

主备切换后，网络中的路由器和主机必须知道"网关MAC地址已经变了"。FW-B变成Master后，会主动发送免费ARP，把1.1.1.1和10.1.1.1这两个网关IP对应的MAC地址更新为FW-B的接口MAC。真实设备上这个过程毫秒级完成，但在HCL模拟器里，上游路由器和主机的ARP表更新经常出现延迟，导致切换后的一段时间内数据帧仍然被发往旧的主设备MAC地址，表现为丢包。

遇到这种情况，一个简单有效的验证方法是手动清理ARP缓存。在HCL的路由器上执行：

reset arp all

在Host上如果是HCL自带的PC，清ARP的方式是打开命令行敲arp -d。清完之后再ping，丢包现象会立刻消失。这个步骤也能证明切换后网络确实由新主设备接管了，只是模拟器里的MAC学习需要人工帮忙"推一把"。

6. HCL里做HA实验的排错方法与常见坑

做完整个实验，我把过程中遇到的高频问题整理成了一份排错清单，每一条都是实际操作中会碰到的场景。

6.1 HRP状态协商不起来

现象是两台设备都敲了hrp enable，但display hrp state里状态一直不正常，比如显示Standby但接口状态是down，或者两边都是Master。

先排查心跳链路：

display hrp interface

这条命令会显示心跳接口和远端地址。接着在FW-A上ping FW-B的心跳口IP：

ping 10.10.10.2

如果ping不通，检查G1/0/6的IP是否配对，以及HCL里的连线是否接对端口。HCL里有个很隐蔽的问题：设备启动后如果拓扑连线是在设备运行中拖上去的，有时要先把设备关掉重连再启动，链路才会生效。心跳链路不通的情况下，HRP协商必然失败，排查优先级最高。

6.2 备设备没有同步到配置

FW-B执行hrp standby-device后，display hrp state显示Standby，但display current-configuration里看不到业务配置。原因是HRP主设备上执行的配置命令只有在HRP建立后才会同步，如果业务配置在开启HRP之前就敲完了，备设备不会自动补齐。

解决办法是在主设备上随意修改一条配置触发增量同步，比如重新配置某个接口的描述信息，或者最稳妥的办法是重做一遍实验，严格按照"先建HRP、后配业务"的顺序来。我第二次做实验时加深了这个教训，顺序比命令本身更重要。

6.3 切换后业务不通

切换本身成功了，但ping不通业务。优先排查安全策略是否同步到了新主设备。在切换后的Master上执行：

display security-policy ip

看策略是否完整。如果策略没同步，大概率还是HRP建立顺序的问题。其次看会话表：

display session table ipv4

如果会话表为空，说明会话热备没有生效，切换后新主设备不认识这些流量，需要重新建立连接。对于TCP业务来说，这就意味着连接中断；对于ping这类ICMP来说，重新发起一次ping就能恢复。生产环境对会话热备要求高的，务必确认hrp mirror session enable已开启。

6.4 模拟器特有的坑

HCL做HA实验还有两个和真实设备不一样的特性，提前知道能少走弯路。

第一，F1060镜像重启后HA状态可能会异常，设备的VGMP组状态在模拟器里有时不会自动恢复到上次的Master/Standby关系。实验过程中如果改了拓扑或者重启了设备，建议重新检查两台设备的状态，必要时重新执行hrp standby-device强制归位。

第二，HCL没有内置抓包工具，想确认免费ARP报文或者VGMP报文的交互细节，不容易直接操作。一个替代方案是用Wireshark观察心跳口链路上的流量，但需要把VirtualBox的host-only网络映射到Wireshark能监听的虚拟网卡，配置相对麻烦。对多数实验验证来说，用持续ping加display hrp state已经足够判断切换是否成功。

第三，VirtualBox版本变动会影响HCL里所有设备的启动和网卡连接。实验做到一半如果发现设备全部连不上，优先检查VirtualBox是否自动更新过，或者host-only网卡的IP网段是否被其他软件改过。HCL这套模拟环境比较脆弱，环境出问题时先把设备全部关闭，修好虚拟网卡再重新启动，比在设备层面排查高效得多。

7. 做完这套实验后，我对HA的真实感受

整套实验跑完之后，我最深的体会是：主备切换的核心不是那几条配置命令，而是VGMP、HRP、ARP重新学习、路由收敛这几个环节咬合在一起的结果。配置命令背下来不难，但真正发生故障的那几秒钟内整个系统如何联动，只有亲手做一次故障注入才能理解透。

HCL模拟器对HA的模拟不能说完美，免费ARP更新慢、切换丢包比真实设备多、重启后状态不稳定，这些都是模拟器的局限。但配置逻辑、排错思路、协议交互的框架是完全正确的，和真实F1060上的行为一致。做完这个实验，你再去接触真实防火墙的双机热备，心里会非常有底。

最后分享一个实用技巧：做切换测试前，一定要在主设备上先开启一个持续ping而不只是ping一次。持续ping能直观看到丢包的时段和数量，这是判断切换是否成功最直接的数据。我自己习惯是在Host上挂一个持续ping窗口，然后在FW-A上用shutdown模拟故障，观测完再恢复接口，整个过程数据说话，比在配置界面里翻状态靠谱得多。