ExpressRoute v2

[cm103]

After some helpful feedback on my previous post, it was evident that we had to go in a different direction with this. Instead of using HA via FGCP, we are going to use VRRP as this will allow us to have different configs on each of the FortiGates (necessary due to differing /30 address spaces on incoming redundant circuits). Specific to the VRRP config, I think we are solid on the LAN side, but we also want to use it upstream so that if either of the uplinks goes down, failover will be triggered as well. Admittedly, this is the piece I have less confidence in. I hope this is viable...

[v_ceban]

Hi,

There is another solution available on VMs. You can still use FGCP HA cluster but you can exclude some parts of the config from sync. On VMs the following part of the config can be excluded from HA Sync:

# config system vdom-exception

edit 1

set object [object]
set scope [all|inclusive|exclusive]*
set vdom [name1],[name2]..*

next

  end

List of object that can be independently configured:

log.fortianalyzer.setting
log.fortianalyzer.override-setting
log.fortianalyzer2.setting
log.fortianalyzer2.override-setting
log.fortianalyzer3.setting
log.fortianalyzer3.override-setting
log.fortianalyzer-cloud.setting
log.fortianalyzer-cloud.override-setting
log.syslogd.setting
log.syslogd.override-setting
log.syslogd2.setting
log.syslogd2.override-setting
log.syslogd3.setting
log.syslogd3.override-setting
log.syslogd4.setting
log.syslogd4.override-setting
system.gre-tunnel
system.central-management
system.csf
user.radius
system.cluster-sync*
system.standalone-cluster*
system.interface*
vpn.ipsec.phase1-interface*
vpn.ipsec.phase2-interface*
router.bgp*
router.route-map*
router.prefix-list*
firewall.ippool*
firewall.ippool6*
router.static*
router.static6*
firewall.vip*
firewall.vip6*
system.sdwan*
system.saml*
router.policy*
router.policy6*

https://community.fortinet.com/t5/FortiGate/Technical-Tip-HA-FortiGate-configurations-that-will-sync...

Thanks

[Toshi_Esumi]

For VRRP config, vrdst-priority is the priority when the destination is unreachable (lost the route). So if the "blue/left" path is the primary, you need to set vrdst-priority lower than "red/right" path priority:50, like 40.
https://docs.fortinet.com/document/fortigate/7.4.1/administration-guide/237072/vrrp-failover

Then since "red/right" path is secondary, there is no use setting the vrdst/vrdst-priority on that side. When that side is primary, the "blue" path is down anyway so nowhere to failover if "red" goes down.

Also just be aware that VRRP doesn't actually prove/ping the vrdst IP. It's just monitoring if a proper route exists. In your case I don't expect 0/0 route is going into the paths so when 10.10.10.0/30 disappears the priority would change. But if 0/0 goes toward the same path, it won't fail over.

<edit>(Note: There is an option to ignore 0/0 route.)</edit>

Toshi