1. 为什么我在三层接口场景下选了负载分担而不是主备切换先说说这次项目的背景。某公司核心业务区需要部署两台USG6000防火墙做双机热备业务流量从核心交换机接入经过防火墙安全过滤后再回到交换机下连服务器区。典型的串联部署但业务量不低领导要求不能让防火墙成为瓶颈同时还得保证设备故障时业务不中断。最开始方案评审时大家默认的想法都是做主备模式也就是一台设备转发流量另一台设备空闲等待通过VRRP或者HRP的主备备份机制保证切换。这个方案的好处是配置简单、逻辑清晰出问题也容易排查。但我看了实际业务模型之后觉得主备模式在这个场景下有点浪费——两台设备性能一样结果只让一台扛所有流量另一台常年空转关键业务高峰期防火墙CPU动不动就到60%以上扩容又得花钱。所以我最终选择了负载分担模式也就是HRP的Load-balance工作方式两台防火墙同时转发流量各自处理一部分会话。这里有个容易误解的点需要先澄清负载分担模式下两台防火墙依然是“双机热备”关系不是两台完全独立的设备。它们之间照样跑HRP协议照样做配置备份和会话备份区别只在于业务流量不再只走一台而是通过交换机侧的负载分担策略分散到两台设备上。这个方案适合什么场景我总结了几条判断标准防火墙三层接口承载业务流量路径是“交换机—防火墙—交换机”不是在防火墙上做透明桥接或二层转发业务并发会话数较高单台设备虽然能扛住但CPU或会话表项利用率长期偏高希望故障切换时丢包尽量少甚至做到会话无损切换交换机支持基于源目的IP的负载分担最好还能配合策略路由做精细分流如果业务量本来就很小一台设备轻轻松松就能搞定那负载分担带来的复杂度和维护成本反而划不来老老实实做主备更稳妥。这一点后面我会再展开说。2. 三层业务接口下的组网拓扑与地址规划思路这次项目的实际拓扑大致是这样的核心交换机上划分了两个业务VLAN区域一个区域是“外联区”暂且这么叫实际就是需要访问外部网络的业务网段另一个是“服务器区”部署了多台应用服务器。防火墙双机分别用三层接口接入交换机的不同VLAN通过OSPF或者静态路由引导业务走向。用三层接口意味着防火墙和交换机之间的链路是路由口或者子接口跑的不是透明模式。这里有个核心设计点两台防火墙各自有独立的接口IP但必须通过HRP虚IPVirtual IP对外呈现一个统一的网关或下一跳。这样交换机上的业务路由才能指向同一个地址不管流量实际走到哪台防火墙逻辑上都是同一个“防火墙网关”。具体的地址规划表格如下以模拟项目X为例实际IP我做了脱敏处理网络区域交换机VLAN防火墙接口实IPHRP虚IP外联区上行VLAN 100USG-A GE1/0/1192.0.2.1/24192.0.2.254/24外联区上行VLAN 100USG-B GE1/0/1192.0.2.2/24192.0.2.254/24服务器区下行VLAN 200USG-A GE1/0/2198.51.100.1/24198.51.100.254/24服务器区下行VLAN 200USG-B GE1/0/2198.51.100.2/24198.51.100.254/24心跳互联VLAN 300USG-A GE1/0/3203.0.113.1/30无心跳互联VLAN 300USG-B GE1/0/3203.0.113.2/30无交换机侧也是两层设计连接防火墙的端口划分到对应业务VLAN同时交换机上配置等价路由或者策略路由把业务流量按照源或目的地址哈希到两台防火墙的实IP上。负载分担的效果本质上取决于交换机侧分流策略做得好不好。这个设计的核心逻辑是业务网关用HRP虚IP保证任何一台防火墙故障时交换机侧路由不用变因为虚IP始终存在而实际流量通过交换机的负载分担算法分散到两台防火墙实现双机同时工作。换句话讲HRP负责“热备”的可靠性交换机负责“分担”的流量调度两者缺一不可。3. HRP双机热备配置核心流程从接口加入到策略备份这一节是整个方案落地的关键。配置顺序很重要HRP不是配完就万事大吉先后顺序错了会引发莫名其妙的故障。我按实际操作顺序整理了一份可直接照抄的配置流程。3.1 心跳接口与HRP域的基本配置两台USG6000之间需要至少一条心跳链路最好独立VLAN、独立物理链路不要和业务流量混在一起。心跳链路承载的是HRP协议报文、配置备份数据和会话备份数据如果带宽不够或者链路不稳定会导致双机状态频繁抖动切换误判。心跳接口配置参考如下USG-A和USG-B的配置对称IP不同interface GigabitEthernet1/0/3 ip address 203.0.113.1 255.255.255.252 undo shutdown // 进入HRP配置模式 hrp interface GigabitEthernet1/0/3 remote 203.0.113.2 hrp enable hrp session-mirror enable quithrp enable一敲下去两台设备就开始协商主备关系。此时如果两端配置不一致HRP状态会异常所以建议先完成所有业务配置最后再开启HRP。我见过不少人在开局阶段就急着把HRP开起来结果后续加策略的时候两边配置不同步心跳信息刷屏排查起来很痛苦。3.2 三层业务接口加入HRP管理域三层业务接口要正常参与热备必须将这些接口加入HRP管理域这样接口的IP地址、路由状态、安全策略等才会在两台设备间同步。注意不同型号和软件版本上命令略有差异但整体思路一致。interface GigabitEthernet1/0/1 ip address 192.0.2.1 255.255.255.0 hrp bind quit interface GigabitEthernet1/0/2 ip address 198.51.100.1 255.255.255.0 hrp bind quit双机配置好后可以用display hrp state查看状态正常会看到两台设备的状态为“Active”和“Standby”主备模式下的显示负载分担模式下则比较特殊两台都是主设备各自承担虚拟网关的一部分流量。状态正常后再验证display hrp interface确认心跳链路收发报文计数在增长。3.3 安全策略与地址簿的同步机制负载分担模式下安全策略、NAT策略、地址簿等配置由哪台设备负责同步答案是配置在哪台设备上做的就由哪台设备通过HRP同步到对端。所以你在USG-A上写的策略会自动同步到USG-B不需要两边各写一遍但不能两边同时修改相同功能区的配置否则会发生覆盖冲突。这里有个非常容易踩的坑HRP同步是按配置命令块进行的不是按“整套配置”一次性同步。举个实际例子你在USG-A上写了一条NAT策略引用了一个新地址组如果地址组本身没有通过HRP同步过去对端设备加载NAT策略时会找不到地址组直接报错。所以凡是策略引用的对象——地址、时间调度、服务端口组——都要确保在同步范围内。3.4 会话快速备份与负载分担的配合负载分担模式有个绕不开的问题新会话的建立可能落在USG-A上但这个会话的应答流量可能通过交换机哈希到了USG-B上。如果两台设备之间没有会话状态同步这个报文就会被USG-B当成无效流量丢弃业务直接就断了。解决这个问题靠的是hrp session-mirror enable——开启会话快速备份。开启后一台设备上新建的会话会立即镜像到对端保证两台设备的会话表基本一致。这样就算应答流量走到了另一台设备也能匹配到会话正常转发。实测下来会话备份对CPU有一定消耗大概会增加5%~10%的开销看会话速率但换来的效果是故障切换时几乎感觉不到会话中断。对于生产业务来说这点开销完全值得。4. 交换机负载分担的配合策略路由与等价路由的取舍防火墙双机配置只是方案的一半另一半在交换机上。很多人只配置了HRP结果发现流量全都涌向一台防火墙另一台设备流量几乎为零——这不叫负载分担这叫“主备模式跑了两台设备的配置”。要让流量真正分散到两台USG上交换机侧必须做分流。4.1 原理解释为什么交换机不会自动把流量分到两台防火墙上交换机收到去往服务器区的流量路由表里如果只有一条出接口指向USG-A以太网口的缺省路由或明确路由那所有流量都会走USG-A。想让流量同时走USG-A和USG-B交换机上必须同时存在两条等价路由或者用策略路由分别指定下一跳。等价路由ECMP是常用的做法但ECMP按五元组哈希粒度较粗可能导致两台设备上的会话分布并不均匀。我在这个项目里用的是策略路由 等价路由的组合核心交换机上基于源IP网段做策略路由。例如源地址是192.0.2.0/24的流量强制下一跳为USG-A实IP源地址是198.51.100.0/24的流量强制下一跳为USG-B实IP。这样流量分配可以精确控制两台设备的负载基本均衡——虽然灵活性可能不如逐流的ECMP哈希但对于大网段划分的场景简单、稳定、可预期。补充一个容易忽略的点如果走ECMP交换机对去往同一目的IP的流量会尽量保持相同路径避免会话乱序。但如果你在交换机上配置了基于目的IP的哈希、而防火墙又开启了会话备份链路故障时交换机重新哈希可能把大量既有会话迁到另一台防火墙触发一次大规模会话切换。设计时需要考虑到这个现象必要时把哈希算法调整为“源目的IP源目的端口”的完整五元组哈希降低重分布概率。4.2 交换机上的配置参考以某交换机CLI为例// 配置ACL匹配业务源网段 acl number 3001 rule 5 permit ip source 192.0.2.0 0.0.0.255 rule 10 deny acl number 3002 rule 5 permit ip source 198.51.100.0 0.0.0.255 rule 10 deny // 策略路由分流到两台防火墙 traffic classifier A if-match acl 3001 traffic behavior A redirect ip-nexthop 192.0.2.1 traffic policy A classifier A behavior A traffic classifier B if-match acl 3002 traffic behavior B redirect ip-nexthop 198.51.100.1 traffic policy B classifier B behavior B // 应用到防火墙接入的三层口或VLANIF interface Vlanif100 traffic-policy A inbound interface Vlanif200 traffic-policy B inbound这个配置的本质逻辑就是人为决定“流量从哪里进防火墙”。回程流量的处理也类似服务器区发出的流量要回外联区交换机的回程策略同样需要把不同网段的流量引导到对应防火墙实IP。双向分流都要做否则就会出现“去程走A、回程走B”的情况。虽然会话备份能兜底但会多消耗心跳带宽和会话同步资源能避免尽量避免。5. NAT与三层回程路径的处理细节大部分业务场景中防火墙同时承担NAT转换功能。在负载分担模式下做NAT有两个细节必须处理到位一是NAT会话的备份二是NAT转换后回程流量的对称性。5.1 NAT策略按接口域区分虚IP也要参与NAT建议把NAT策略分别绑定在上行接口和下行接口上。例如从服务器区访问外部网络的流量在USG-A上配置源NAT将内网服务器地址转换成防火墙实IP或虚IP。用虚IP做NAT转换有个明显好处即使某台设备故障对端设备的NAT会话也使用相同源地址回程流量不感知切换。具体NAT配置参考nat address-group NAT_POOL 0 mode pat address 192.0.2.254 255.255.255.255 rule name NAT_SERVER source-address 198.51.100.0 24 destination-address any action source-nat address-group NAT_POOL这里的192.0.2.254是HRP虚IP。两台设备同时持有这个虚IP对应的业务转发能力NAT后的源地址一致回程流量到达交换机后无论被引导到哪台防火墙都能正常匹配NAT会话表。如果使用各自实IP做NAT切换时回程流量很可能因源地址不匹配导致NAT转换失败业务直接就断了。5.2 回程路径的“对称性”问题我可以很坦率地讲即使会话备份开启回程路径对称性依然值得关注。因为NAT会话表、ALG应用层网关状态等在某些场景下的备份可能不完整尤其是FTP、SIP这类需要动态协商端口的协议一旦会话状态备份丢了实际流量还是可能被丢弃。为了稳妥我一般建议在交换机侧做“双向对称分流”同一个网段的去程流量和回程流量固定走同一台防火墙。这就是为什么我在策略路由里按源地址网段划分而不是随机哈希——策略路由从配置层面就保证了对称性大大减少了依赖会话备份兜底的场景。如果实在做不到完全对称建议至少保证TCP协议的双向路径一致UDP或短连接类业务对路径切换的容忍度稍高一些但也不建议长期依赖会话备份去兜底。6. 故障切换实测三层接口场景下USG与交换机的联动配置完成后不能直接上线我习惯先在模拟环境里做一轮故障演练重点验证三层接口场景下的两个问题防火墙单机故障时业务中断多久会话备份能不能保住存量连接6.1 模拟测试方案设计为了隔离变量我分了三轮测试拔掉USG-A的上行物理链路只断业务口不断心跳口观察交换机路由状态和业务恢复时间直接关闭USG-A设备模拟整机宕机同时断开心跳观察切换动作是否干净断开心跳链路制造“双主”风险场景观察业务影响测试方法很简单在内网一台测试机上持续ping服务器区网关地址同时在另一台机器上建立一条SSH长连接并保持会话判断切换过程中ping丢包数和SSH是否断开。6.2 实测数据与观察结论第一轮测试结果拔掉USG-A上行链路后交换机通过等价路由感知到USG-A不可达把原本哈希到USG-A的流量切到USG-Bping丢包在2~5个包左右。SSH连接没有断开因为会话镜像已经同步到了USG-B切换后连接复用成功。第二轮测试结果直接关闭USG-AHRP状态在毫秒级完成切换业务影响和第一轮基本一致ping丢包主要取决于交换机的路由收敛时间而不是USG的切换时间。服务器区到外联区的持续下载会话没有中断。第三轮测试结果比较特殊断开心跳链路后两台USG都认为对方失联负载分担模式下虽然虚IP功能由各自独立承担但因为没有会话同步新会话可能被哈希到任何一台设备而该设备上没有对应的正确会话会引发部分业务异常。这个场景是最危险的我在生产设计里额外加了一条约束心跳链路必须与业务物理隔离且多条心跳做捆绑比如两条GE捆绑成一个Eth-trunk最大程度降低心跳单点故障概率。6.3 一个容易忽略的配置接口监控与业务链路联动三层接口模式下防火墙本身感知不到“交换机到上游设备”的链路是否正常。举个例子USG-A的上行口连接到交换机A但交换机A的级联链路断了此时USG-A的业务口物理状态依然是upHRP认为设备正常但实际上业务流量已经出不去。如果不做接口联动故障就会表现为“USG-A还占着虚IP主节点但业务全部超时”。解决办法是使用链路监控/接口监测功能。USG系列上可以通过监控接口状态或者向某个固定目的地址发送探测报文IP-Link / BFD一旦探测失败自动将业务接口从HRP管理域中暂时隔离引导流量切换到对端设备。我当时在USG-A和USG-B上各配置了一个指向核心交换机网关地址的IP-Link探测判定条件设为连续5次探测失败才切换避免瞬断引起误切换。实测模拟“交换机级联链路断开”时业务切换时间在3秒内完成比不做监控时快了近10倍。这一步非常建议实际部署时加上。6.4 切换带来的额外开销评估负载分担模式日常运行时两台设备都在转发流量CPU负载相近切换瞬间幸存设备要接管全部流量CPU会短暂冲到80%左右。如果日常负载本来就在60%切换瞬间可能出现短暂丢包或会话创建慢。所以我建议日常让设备负载控制在40%以下留足切换余量。这个经验值在多个项目里反复验证过。7. 常见故障排查思路从HRP状态到会话表的完整链路这个方案上线后我总结了一套排查链路遇到问题按顺序查能省下大量调试时间。7.1 HRP状态与心跳检查执行display hrp state确认设备角色是否符合预期负载分担模式下两台设备的角色说明和主备模式展示不同不要误判为配置异常执行display hrp interface观察心跳接口的收发报文计数如果一段时间内报文数无增长说明心跳通道可能被策略阻断或物理链路异常查看系统日志中是否有HRP状态震荡记录反复震荡通常与心跳抖动有关7.2 交换机负载分担链路检查在交换机上查看display fib或等价路由下一跳表项确认去往业务网段的路由确实存在两条等价路径用display traffic policy查看策略路由命中计数。如果某个ACL的匹配次数为0说明该分流策略没有生效优先查ACL规则顺序和接口应用方向观察两台防火墙实接口上的流量速率是否接近预期比例如果长期严重偏斜大概率是分流策略没生效7.3 业务流量路径与会话表验证在USG上执行display firewall session table过滤源或目的IP确认新建会话落到了哪台设备在另一端设备上执行同样的会话查询确认会话镜像是否正常生成。如果对端查不到对应会话优先检查hrp session-mirror enable是否配置到位如果特定业务比如FTP流量异常重点检查ALG策略是否同步到两台设备以及NAT策略引用的地址池是否一致7.4 一个让人抓狂的“隐性”问题策略同步顺序最后补充一个我自己踩过的坑HRP同步配置是有顺序的在配置大量策略对象时如果先写了引用关系的策略、后定义了被引用的对象HRP同步时另一台设备可能加载失败并回滚部分配置。表面现象是“某台设备的安全策略丢了一半”实际根因是同步顺序乱了。我的解决办法是所有被引用对象先创建再创建引用它的策略创建策略后立即手工触发一次配置同步并到对端设备核对。宁可在上线前多花几分钟反复核对也不要等业务跑起来后发现两台设备策略不一致。8. 上线运行后的最佳实践与几点经验总结方案上线到现在平稳运行了几个月期间经历过一次交换机单链路割接、一次防火墙版本微码升级都没造成业务中断。这里把一些运行维护层面的经验整理出来供参考。8.1 设备升级和补丁操作顺序防火墙版本升级时先升级备用设备负载分担模式下可以先操作负载较轻的一台确认新版本运行正常后再手工将流量切换到这台设备再升级另一台。不要在业务高峰期同时升级两台设备也不要依赖自动切换去扛升级操作手工切换路径更可控。升级前记得导出当前配置做备份HRP配置和策略配置的备份文件分别导出避免恢复时找不到对应版本。8.2 日常监控指标我建议至少监控以下几个指标两台USG的CPU、内存、会话并发数每5分钟采样一次观察两台设备的负载差值正常应该在合理范围内心跳接口的错包计数和丢弃计数一旦持续增长优先检查物理链路或中间交换机端口协商模式HRP状态变化事件触发告警防患于未然交换机等价路由的两条下一跳对应表项确保始终存活如果发现两台设备负载长期严重不均衡不要急着怀疑配置先看交换机哈希算法与实际业务流的匹配情况。我遇到过一种情况业务流量中某个大流量源地址占比较高ECMP哈希后大量流量集中到了同一台设备两台设备负载差异高达30%。后来把交换机哈希算法从“目的IP”改为“源目IP端口”后负载分布才趋于合理。8.3 故障演练的节奏虽然设备稳定但双机热备不代表永远不出问题反而是因为有了热备很多底层故障被掩盖了。我建议每季度做一次简单的拔线演练每半年做一次完整切换演练包括断心跳、断业务口、拔电源三种场景。演练要在业务低峰期做通知相关业务方准备回退方案。演练记录保留下来作为后续网络优化和风险评估的输入。8.4 什么情况下建议退回主备模式最后说一个反向建议。如果你发现业务量本身不大单台设备CPU常年低于20%或者业务中存在大量长连接、大流量单一会话比如数据库同步、视频流转发负载分担反而可能让问题更复杂——这种单条会话无法被拆分只能固定走一台设备另一台可能空转故障切换本身也涉及会话重建。这种情况就不如主备模式干净利落。选负载分担还是主备本质上是可靠性冗余与复杂度的权衡。我这次项目选择负载分担是因为业务模型适合、设备余量充足、运维团队有能力处理更复杂的联动配置。如果你不具备这些前提主备模式反而是更稳妥的生产选择。