Technical Tip: Configuring BGP overlay for ADVPN 2.0

[Nivedha]

Description	This article discusses BGP overlay configuration for ADVPN 2.0.
Scope	FortiGate v7.4.2+.
Solution	ADVPN 2.0 was introduced in FortiGate version 7.4.2 onwards. This is an addition to the existing configuration of ADVPN1.0 and is extremely useful for ADVPN with SD-WAN setup. To convert ADVPN1.0 to ADVPN2.0, refer to Differences between ADVPN2.0 and ADVPN1.0 and ADVPN2.0 configuration. With any ADVPN setup, it is recommended to use BGP and this article focuses on BGP on overlay configuration. The following topology will be used for this article: By using the route map preferable command, it will be ensured that the spokes send a community tag to indicate when the IPSec tunnel goes out of SLA: Spoke configuration: The route map has two communities advertised: 65001:1 when SLA passes and 65001:11 when SLA fails. Spoke1 # config router route-map     edit "sla_pass"         config rule             edit 1                 set set-community "65001:1"                 unset set-ip-prefsrc             next         end     next     edit "sla_fail"         config rule             edit 1                 set set-community "65001:11"                 unset set-ip-prefsrc             next         end     next end BGP configuration reflects route map preferable as SLA pass which means when SLA meet, the spoke will advertise the 65001:! community. Spoke1 # config router bgp     set as 65400         config neighbor             edit "10.254.255.1"                 set remote-as 65400                 set route-map-out "sla_fail"                 set route-map-out-preferable "sla_pass"                 set additional-path both             next             edit "10.250.255.1"                 set ebgp-enforce-multihop enable                 set remote-as 65400                 set route-map-out "sla_fail"                 set route-map-out-preferable "sla_pass"                 set additional-path both             next end SD-WAN has neighbour configuration that specifies which health check and SLA to consider to determine the community to advertise. Spoke1 # config system sdwan     set status enable         config zone             edit "IPSec"                 set advpn-select enable                 set advpn-health-check "HUB"             next         end         config members             edit 3                 set interface "hub1-Pri"                 set zone "IPSec"                 set transport-group 1             next             edit 4                 set interface "hub1-Sec"                 set zone "IPSec"                 set transport-group 1             next         end         config health-check             edit "HUB"                 set server "192.167.1.1"                 set members 3 4                     config sla                         edit 1                             set latency-threshold 100                             set jitter-threshold 100                         next                     end             next         end         config neighbor             edit "10.250.255.1"                 set member 3                 set health-check "HUB"                 set sla-id 1             next             edit "10.254.255.1"                 set member 4                 set health-check "HUB"                 set sla-id 1             next         end end Hub is simply configured to match the community and to set a local preference for the route. This local preference will be forwarded to another spoke as all members are in iBGP setup. Hub configuration: The community list has 2 communities to match 65001:1 and 65001:11. Hub1 # config router community-list     edit "65001:1"         config rule             edit 1                 set action permit                 set match "65001:1"             next         end     next     edit "65001:11"         config rule             edit 1                 set action permit                 set match "65001:11"             next         end     next end Route map matches the community and sets a local pref of 200 for 65001:1 and 100 (default) for 65001:11. This will ensure that the route on the link that matches SLA will be preferred. Hub1 # config router route-map     edit "AllowAll"         config rule             edit 1                 set match-community "65001:1"                 set match-community-exact enable                 unset set-ip-prefsrc                 set set-local-preference 200             next             edit 2                 set match-community "65001:11"                 set match-community-exact enable                 unset set-ip-prefsrc             next         end     next end BGP configuration is implemented to match the route map accordingly for incoming routes: Hub1 # config router bgp     set as 65400     set ibgp-multipath enable     set additional-path enable     set additional-path-select 3         config neighbor-group             edit "PrimarySpoke"                 set soft-reconfiguration enable                 set remote-as 65400                 set route-map-in "AllowAll"                 set additional-path both                 set route-reflector-client enable             next             edit "SecondarySpoke"                 set soft-reconfiguration enable                 set remote-as 65400                 set route-map-in "AllowAll"                 set additional-path both                 set route-reflector-client enable             next         end end Implementation of these can be seen in the output below: In Spoke1, PrimaryVPN is out of SLA: Spoke1 # diag sys sdwan health-check status Health Check(HUB): Seq(3 hub1-Pri): state(alive), packet-loss(0.000%) latency(151.009), jitter(5.137), mos(4.289), bandwidth-up(9999999), bandwidth-dw(9999999), bandwidth-bi(19999998) sla_map=0x0 Seq(4 hub1-Sec): state(alive), packet-loss(0.000%) latency(0.813), jitter(0.144), mos(4.404), bandwidth-up(9999999), bandwidth-dw(9999999), bandwidth-bi(19999998) sla_map=0x1 Hub now receives the community tag of 65001:11 for PrimaryVPN and 65001:1 for SecondaryVPN: Hub1 # get router info bgp network 192.168.2.0 VRF 0 BGP routing table entry for 192.168.2.0/24 Paths: (2 available, best #2, table Default-IP-Routing-Table) Advertised to peer-groups: PrimarySpoke SecondarySpoke Original VRF 0 Local, (Received from a RR-client) 10.250.255.2 from 10.250.255.2 (192.168.2.1) Origin IGP metric 0, localpref 100, valid, internal Community: 65001:11 Receive Path ID: 1 Last update: Sun Mar 9 13:41:16 2025 Original VRF 0 Local, (Received from a RR-client) 10.254.255.2 from 10.254.255.2 (192.168.2.1) Origin IGP metric 0, localpref 200, valid, internal, best Community: 65001:1 Receive Path ID: 1 Advertised Path ID: 1 Last update: Sun Mar 9 13:18:27 2025 Spoke 2 now gets the routes but installs the route via Secondary on its routing table as it is most preferred: Spoke2 # get router info bgp network 192.168.2.0 VRF 0 BGP routing table entry for 192.168.2.0/24 Paths: (2 available, best #2, table Default-IP-Routing-Table) Not advertised to any peer Original VRF 0 Local 10.254.255.2 from 10.254.255.1 (192.168.2.1) Origin IGP metric 0, localpref 200, valid, internal, best Community: 65001:1 Originator: 192.168.2.1, Cluster list: 192.167.1.1 Receive Path ID: 1 Advertised Path ID: 2 Last update: Sun Mar 9 13:41:32 2025 Original VRF 0 Local 10.254.255.2 from 10.250.255.1 (192.168.2.1) Origin IGP metric 0, localpref 200, valid, internal, best Community: 65001:1 Originator: 192.168.2.1, Cluster list: 192.167.1.1 Receive Path ID: 1 Advertised Path ID: 1 Last update: Sun Mar 9 13:41:29 2025 Spoke2 # get router info routing-table details 192.168.2.0 Routing table for VRF=0 Routing entry for 192.168.2.0/24 Known via "bgp", distance 200, metric 0, best Last update 00:04:17 ago * vrf 0 10.254.255.2 priority 1 (recursive via hub1-Sec tunnel 30.0.0.1) * vrf 0 10.254.255.2 priority 1 (recursive via hub1-Sec tunnel 30.0.0.1)