一.环境说明
此次在测试环境中模拟部署fortigate VM的HA架构，这里选择镜像版本为v7.2.0，因为该版本及之前的版本均使用旧的trial license，有效期15天，之后的版本使用新的license方式，需要有一个fortinet care (forticloud )账号，目前这2个账号的服务已经all in one了，新的方式会有一个永久的trial license，但是一个account只能注册一个试用许可，所以多台设备还是建议使用7.2.0及之前版本，除非你有多个forticloud account。
trial license说明如下：
二.部署拓扑图
拓扑说明：
三. 部署过程
3.1 Active-Active
console方式给FW接口配置一个管理IP后，通过web登录，配置HA（本文中配置双活模式）
第二台设备以同样的方式进行配置，配置后可以在第二泰设备看到，2台设备在进行同步了（可以通过设备序列号区分）
几分钟后2台设备同步完成后，之前的2台设备各自的web管理IP就不再有效，此时需要通过新的IP登录，本文中前期的接口IP是通过dhcp获取的，所以HA配置完成后也会通过dhcp获取一个新的IP（可以在任意一台的console中查看），然后通过HA IP登录Web页面.
登录后可以看到2台设备的已完成同步状态，
此时2台物理设备已经成为了一台逻辑上的单台设备，接下来对HW 的上游设备进行基本配置，上游的2台交换机为运营商线路接入二层冗余设备，每台设备都接入全部的运营商线路，都接入到下游的防火墙，以vlan来隔离不同运营商，无其它配置。
此时防火墙同ISP的线路就已经打通，接下来配置防火墙下游设备，
防火墙同下游设备互联采用svi三层方式，通常连接设备为核心或者区域边界设备，
防火墙下联接口配置：
核心交换机和接入交换机之间同样使用hsrp联通，
测试win10中配置测试IP，测试外网联通正常。
3.1.1 全链路HA数据走向检测
接入层到网关为vrrp 网关冗余，配置是Core1 hsrp优先级160高于Core2 150，故接入层数据优先发往Core1,这里网关冗余切换track还未配置，所以网关故障切换待后续逐步调整。
防火墙HA采用FGCP模式(详细说明参加官文http://docs.fortinet.com/document/fortigate/7.2.0/administration-guide/62403/fgcp)，2台设备优先级都为默认128，该节部署的HA模式AA双主要，这里虽然优先级相同，但是2台设备角色还是有primary和secondary的区别，具体看数据的收发情况，
从核心1上查看10.10.100.1的arp和mac表，关联到了连接FW1的上联口，
从核心2上查看10.10.100.1的arp和mac表，也关联到了FW1的上连口，
这里核心往上的流量是转发给了当前为primary角色的FW1。
再看看从防火墙向上的流量转发路径，这里ISP1接口的IP地址为192.168.207.178 mac 为00:09:0f:09:00:00
在运营商接入交换机中查看想信息，
ISP1虚拟IP只在ISP-SW-1中存在。
ISP2 的虚拟接口信息如下，
同样查看相关信息，
同样ISP2的mac表项信息只和FW1互联接口关联。
这里看出FW向外转发的流量同样是从FW1向上分别向2个ISP线路转发。
3.2 Active-Passive
防火墙其它配置不调整，修改HA部分参数，
1分钟左右可以看到2台设备状态完成同步，
3.2.1 数据链路查看
防火墙FW1（secondary）和FW2（primary）中的arp表项分别为，
核心交换机Core还是主网关，
2台核心arp和mac表项信息，
上图可以看出核心去往防火墙10.10.100.1的出接口是Core1 连接 FW2(primary)的Eth3口。
ISP接入交换机的相关信息为，
从图中也可以看出2台交换机最终去往ISP1 防火墙地址192.168.207.128，最后是通过ISP-SW-2连接FW2的eth0回包。
四. 防火墙主备切换验证
4.1 防火墙主备切换
在FGCP的HA模式下，HA的failover 主要有如下4种场景，
https://docs.fortinet.com/document/fortigate/7.2.0/administration-guide/489324/failover-protection
测试机预先长ping外网IP，先通过调整FW优先级来触发，切换过程中只有一个异常数据包，
现在FW1为主，
再通过触发设备down验证切换，关闭FW1 后，FW2切换为主，中间丢包3-5。
五. 核心上联冗余架构优化
5.1 二层接口配置优化
前文中防火墙下联冗余接口 port 3 和port4 使用防护墙的software switch 来bond， 但是这里有一个问题就是，被software switch bond后的逻辑接口以及物理接口均不能添加为HA monirot 的接口，所以在防火墙下游设备故障后，防火墙无法检测感知，这里将防火墙port 3和port4口修改为 lacp aggregate接口进行捆绑，
2台核心交换机对于互联接口也配置为lacp port-channel 口，
配置完成后，2台核心交换机对于的etherchannel 状态(Core1先配置)，
在经过多此配置实验后发现，先配置的交换机会优先和互联的FW之间建立正常的port channel，且这里的接口只能配置为 active mode，passive 和on 均不能正常协商建立，只有在已经建立port-channe的接口或者是所在设备down掉大约1分钟以后，另一台设备的port-channel才会建立正常。
这种互联架构满足了FW下游接口的冗余和探测要求，以及核心故障切换上游冗余。且无论是单个防火墙或者是单个核心交换机故障都能快速自动恢复（最长2mins以内）,这里的恢复时间主要是lacp port-channel 切换触发时间。防火墙故障后，核心流量无缝衔接转发上游，核心故障后vrrp会迅速切换，上游流量切换同样几乎无感。
5.2 二层互联架构优化
原本架构是核心和防火墙之间为完全互联"X"架构，现在修改为“＃”型架构，防火墙下联接口不做调整，
将互联FW接口绑一个port-channel ，2台核心同时可以和对的协商成功，
此时的，FW1是主 核心1到10.10.100.1直达，Core2经过Core1到达。
之后再配置hsrp track ，联动FW状态实现FW和Core Switch主设备的同步切换，这里核心之前走的是二层流量，非严格情况下其实也没有必要非的上下主设备保持一致。
六. 后续
另外在防火墙上下游中如果有负载均衡设备需要对流经防火墙的流量将进行loadbalance，则可以在FSCP的基础上启用FGSP(会话同步支持)，减少防火墙HA切换时对现有流量session的影响。
对于防火墙HA架构中上下游设备的互联互通，除了上述softswitch和lacp aggregate外，同意也可以使用vrrp来实现。根据以往的经验来看，设备的HA中常用的堆叠技术，虽然配置简单，同样也简化了网络拓扑，在实现冗余的情况下也扩展了设备硬件容量，但是确实不太推荐使用堆叠（仅限路由转发角色的设备），堆叠脑裂的问题是该技术致命的缺陷，无法探测无法避免。
具体采用哪种方式取决于实际的网络架构和业务流量sla要求，没有最好的架构只有最合适的架构。
