Skip to main content
cm103
New Member
August 26, 2021
Question

ExpressRoute v2

  • August 26, 2021
  • 2 replies
  • 3130 views

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...

    2 replies

    v_ceban
    Staff & Editor
    Staff & Editor
    September 14, 2023

    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-and/ta-p/216710

    Thanks

    Toshi_Esumi
    SuperUser
    SuperUser
    September 14, 2023

    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