防火墙高可靠性技术
0. 高可靠解决方案
（1）高可靠性技术背景
· 网络架构中硬件的不可靠主要源自于设备不可靠与链路不可靠两方面。
· 防火墙高可靠性技术分为两类：设备高可靠性和链路高可靠性。
（2）设备高可靠性
· 双机热备：两台防火墙组成双机热备，当一台防火墙发生故障时，另一台防火墙接替工作，保障业务的连续性。
· 跨数据中心集群：当某一个数据中心发生故障或灾难的情况下，其他数据中心防火墙可以对其业务实现接管，达到互为备份的效果。
· 硬件Bypass：当防火墙工作失效时，会导致网络中断，而硬件Bypass则能让防火墙在工作失效后，对流量不作任何处理，直接转发。
（3）链路高可靠性技术
· Eth-Trunk：绑定多个物理接口为一个逻辑接口，提高链路的可靠性。
· IP-Link：周期性发送ARP或ICMP报文，检测链路的可用性。
· BFD：周期性发送BFD控制报文，检测设备或系统之间链路的可用性。
· Link-Group：Link-Group功能是将多个接口的状态相互绑定，组成一个逻辑组。
· 健康检查：防火墙上的功能，对服务可用性、链路可用性或链路时延等进行探测，目前与防火墙智能选路特性结合使用。
1. 双机热备技术原理
（1）概述
· 传统组网方式如下左图所示，内外用户的报文交互全部通过防火墙A。
· 如果防火墙A出现故障，通讯将中断。
· 为了防止一台设备出现意外故障而导致网络业务中断，可以采用两台防火墙形成双机备份。
（2）双机热备技术架构的3个协议
· VRRP：Virtual Router Redundancy Protocol，虚拟路由冗余协议。
· VGMP：VRRP Group Management Protocol，VRRP组管理协议。
· HRP：Huawei Redundancy Protocol，华为冗余协议。
（3）双机热备工作模式
· 防火墙支持主备备份和负载分担两种工作模式。
= 主备备份模式
· 两台设备一主一备。正常情况下业务流量由主用设备处理。当主用设备故障时，备用设备接替主用设备处理业务流量，保证业务不中断。
· 流量由单台设备处理，相较于负载分担模式，路由规划和故障定位相对简单。
· 主备备份模式中，备用设备不承载任何业务流量，资源利用率不高。
= 负载分担模式
· 两台设备互为主备。正常情况下两台设备共同分担整网的业务流量。当其中一台设备故障时，另一台设备会承担其业务，保证原本通过该设备转发的业务不中断。
· 相较于主备备份模式，组网方案和配置相对复杂。
· 负载分担模式组网中流量由两台设备共同处理，可以提高防火墙整体的业务吞吐量。
· 负载分担模式组网中设备发生故障时，只有一半的业务需要切换，故障切换的速度更快。
（4）双机热备部署场景
· 根据防火墙组网方式不同，可以将双机热备分为以下场景，每种场景都支持主备备份/负载分担模式。
= 基于VRRP的双机热备：
· 防火墙的业务接口工作在三层模式，上下行与交换机互联，运行VRRP协议。
= 基于路由协议的双机热备：
· 防火墙的业务接口工作在三层模式，上下行与路由器互联，运行OSPF协议。
= 透明模式的双机热备：
· 防火墙的业务接口工作在二层模式，上下行与路由器/交换机互联。
（5）双机热备系统要求
· 硬件要求：组成双机热备的两台防火墙的型号必须相同，安装的单板类型、数量以及单板安装的位置必须相同。
· 软件要求：组成双机热备的两台防火墙的系统软件版本、系统补丁版本、动态加载的组件包、特征库版本都必须相同。
· 授权要求：两台防火墙之间不能共享授权。两台防火墙的授权控制项种类、资源数量、升级服务到期时间都要相同。
2. VRRP
（1）概述
· VRRP技术是一种容错协议。
· 它保证当主机的下一跳路由器出现故障时，由备份路由器自动代替出现故障的路由器完成报文转发任务。
· 同一VRRP备份组内的路由器有两种角色：Master设备（活动状态）、Backup设备（备份状态）。
（2）VRRP切换-正常流程
1> 选举出主用设备和备用设备。
2> 主用设备发送免费ARP，ARP中包含虚拟IP和虚拟MAC。
3> 交换机刷新MAC地址表。
4> 涉及跨网段通信时，内部终端发送ARP请求网关的MAC地址。
5> 交换机泛洪。
6> 主用路由器回复ARP应答，应答内包含虚拟IP和虚拟MAC。
7> 内部终端的流量走主用设备。
8> 交换机查MAC地址表，将流量转发到设备A。
（3）VRRP切换-故障流程
1> 备用设备连续三个周期没有收到Hello包，自动切换为Master。
2> 同时发送免费ARP，刷新交换机MAC地址表，ARP中包含虚拟IP和虚拟MAC。
3> 涉及跨网段通信时，内部终端发送ARP请求网关的MAC地址，后续一致。
（4）VRRP技术细节
1> 主用设备选举规则：
· 首先比较优先级的大小，优先级的范围为0-255，优先级高者当选为Master设备。
· 其次比较接口IP地址大小，接口IP地址较大的设备当选为Master设备。
· 成为Master的设备运行优先级自动变为255。
2> 当主用设备正常工作时，网络内主机通过主用设备与外部网络通信。
· Master设备拥有VRRP备份组的虚拟IP地址和虚拟MAC地址。
· Master设备收到目的IP地址是虚拟IP地址的ARP请求时，会响应这个ARP请求。
· 在同一个备份组中的多个路由器中，只有一台处于活跃状态。
· 只有主路由器能转发以虚拟IP地址作为下一跳的报文。
3> 当主用设备出现故障时，备用设备会成为新的主用设备，保证网络不中断。
· Backup设备不会响应目的IP地址为虚拟IP地址的ARP请求。
· 当Master设备出现故障时，剩下的Backup设备中将会选举出新的Master设备。
· 主路由器通过组播放书定期（224.0.0.18）向备份路由器发送通告报文（Hello报文，间隔15）。
· 由于Hello报文为组播报文，所以要求备份组中的各路由器通过二层设备相连。
（5）VRRP技术在多区域防火墙组网中的应用
· 为防火墙上多个区域提供双机备份功能时，需要在每一台防火墙上配置多个VRRP备份组。
（6）VRRP在防火墙应用中存在的缺陷
· 传统VRRP方式无法实现主、备防火墙状态信息和多组VRRP状态的一致性。
3. VGMP
（1）VGMP三大作用
· 状态一致性管理
· 抢占管理
· 通道管理
（2）状态一致性管理
= 概述
· 为了保证所有VRRP备份组切换的一致性，推出了VGMP来弥补此局限。
· 将同一台防火墙上的多个VRRP备份组都加入到一个VGMP管理组。
· 由管理组统一管理所有VRRP备份组的状态，来保证管理组内所有VRRP备份组状态都是一致的。
= 选举与状态机制
· VGMP的Hello报文用于协商防火墙主备状态。
· VGMP设备会定期通过心跳线向对端发送Hello报文，缺省为1秒/次。
· Hello报文中包含：设备优先级、接口状态、VRRP成员状态等。
· 若连续三个周期，均没有收到对端设备发送的Hello报文，则判定对端故障。
· 启动VGMP功能后，VRRP主用设备由VGMP指定。
· 每台防火墙都有一个VGMP组，用户不能删除这个VGMP组，也不能再创建其他的VGMP组。
· VGMP优先级是不可配置的，设备正常启动后，会根据设备的硬件配置自动生成一个VGMP组优先级。
· 中低端设备，初始优先级与CPU个数有关，具体如下：
| 类型 | 型号 | 初始优先级 |
| 单CPU机型 | 除USG6635E/6640E-K/6655E、USG6680E和USG6712E6716E外 | 45000 |
| 双CPU机型 | USG6635E/6640E-K/6655E、USG6680E和USG6712E6716E外 | 45002 |
· 高端设备，例如USG12K，计算公式完全不同，具体去看说明。
· 选举流程概要
1> 比较优先级：默认情况下，两台防火墙VGMP组的优先级相同，优先级为45000/45002。
2> 依据配置决定主备：根据防火墙配置决定防火墙VGMP组的状态。
· 主用设备也会免费发送ARP来刷新交换机表项。
· VGMP四个状态具体如下：
| 状态名 | 状态解释 |
| initialize | 设备未启用双机热备功能时，VGMP组属于该状态 |
| load-balance/normal | 两台防火墙优先级一致时，负载分担 |
| active | 一台防火墙优先级大于对端防火墙时，主用 |
| standby | 一台防火墙优先级小于对端防火墙时，备用 |
（3）状态切换
· 如下故障会引起防火墙VGMP状态切换，不同故障降低的优先级数值不同：
1> VGMP组监控的接口故障。
2> VGMP监控的链路故障。
3> 接口板、业务板、交换网板故障
· 接口故障：
（4）抢占管理
· 当激活了“主动抢占”功能时。
· 当原主设备故障恢复时，优先级也恢复，将重新发送Hello包来协商主备。
· 主用设备故障恢复后不会立即进行主动抢占，默认是要等待60s后再进行主动抢占。
· 抢占延迟时间是给网络路由收敛、两台设备表项备份预留的时间。
· 延迟抢占能有效地防止网络震荡导致的双机热备状态震荡。
（5）通道管理
· 通道管理指当存在心跳线时，VGMP会自动判断和选择可用的接口来发送报文。
4. HRP
（1）概述
· HRP协议用来实现防火墙双机之间状态信息和关键配置命令的动态备份。
· 备份方向
1> 配置命令默认只能配置在主设备上执行，这些命令会自动备份到备设备上。
2>
3>
标签：双机,HCIE,备份,防火墙,VRRP,VGMP,高可靠性,设备 From： https://www.cnblogs.com/FFSec/p/17770000.html