This article describes prioritizing BGP routes on one VPN tunnel over another using route maps.
Scope
FortiGate.
Solution
In this example, two VPN tunnels are configured with their own BGP peering. The requirement is to use VPN2 as the primary tunnel and VPN1 as the secondary tunnel.
FortiGate1 has learned the routes for 192.168.2.0/24 via VPN1 (10.0.0.2) and VPN2 (10.0.0.6) but the best route chosen is through VPN1.
FortiGate1 # get router info bgp network VRF 0 BGP table version is 4, local router ID is 1.1.1.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight RouteTag Path *> 192.168.1.0 0.0.0.0 100 32768 0 i <-/1> *>i192.168.2.0 10.0.0.2 0 100 0 0 i <-/1> * i 10.0.0.6 0 100 0 0 i <-/-> Total number of prefixes 2 FortiGate1 # get router info routing-table detail 192.168.2.0/24 Routing table for VRF=0 Routing entry for 192.168.2.0/24 Known via "bgp", distance 200, metric 0, best Last update 00:00:19 ago * 10.0.0.2 (recursive via VPN1 tunnel 172.16.1.2)
Using route maps, FortiGate can prioritize VPN2 as the primary route and VPN1 as the secondary route. There are several options for making one prefix/route preferred over another, but this article focuses on using the BGP Weight and Local Preference attributes.
A route map can be used to apply a higher weight or local preference to a prefix advertised by a BGP peer, and these attributes will signal to BGP which route is more preferred. Setting a weight will stay local to the FortiGate and will not be propagated to the rest of the Autonomous System (AS). Meanwhile, by setting a local preference, it will be propagated within the same AS.
Step 1: (Optional) Create a prefix-list so the route-map will only apply to the subnet(s) specified. Otherwise, this step can be skipped so the route-map weight or local preference will be applied to all routes received by the BGP peer.
config router prefix-list edit "VPN2_PrefixList" config rule edit 1 set prefix 192.168.2.0 255.255.255.0 unset ge unset le next end next end
Step 2: Create the route-map. Weight OR local-preference will work depending on the requirement. In this case, a weight of 1 or a local preference of 101 will make the routes being learned on VPN2 more preferred. This is because the routes currently being learned on both VPN1 and VPN2 have a weight of 0 and a local preference of 100 as indicated by the output of ‘get router info bgp network’.
config router route-map edit "VPN2_RouteMap" config rule edit 1 set match-ip-address "VPN2_PrefixList" set set-weight 1 set set-local-preference 101 next end next end
Step 3: Apply the route map to the BGP neighbor in the inbound direction
config router bgp set as 64512 set router-id 1.1.1.1 config neighbor edit "10.0.0.2" set remote-as 64512 next edit "10.0.0.6" set remote-as 64512 set route-map-in "VPN2_RouteMap" next end end
Step 4: Soft reset the BGP peering on VPN2 for the new route map to take place if soft-reconfiguration is enabled on the BGP neighbor.
FortiGate1 # exe router clear bgp ip 10.0.0.6 soft
Otherwise, do a hard reset on VPN2 for the new route map to take place.
FortiGate1 # exe router clear bgp ip 10.0.0.6
Repeat steps 1-4 for FortiGate2, otherwise, there could be asymmetric routing.
After the soft/hard reset, VPN2 will be chosen as the best route for 192.168.2.0/24.
FortiGate1 # get router info bgp network VRF 0 BGP table version is 3, local router ID is 1.1.1.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight RouteTag Path *> 192.168.1.0 0.0.0.0 100 32768 0 i <-/1> * i192.168.2.0 10.0.0.2 0 100 0 0 i <-/-> *>i 10.0.0.6 0 100 1 0 i <-/1> Total number of prefixes 2 FortiGate1 # get router info routing-table detail 192.168.2.0/24 Routing table for VRF=0 Routing entry for 192.168.2.0/24 Known via "bgp", distance 200, metric 0, best Last update 00:00:09 ago * 10.0.0.6 (recursive via VPN2 tunnel 172.16.1.6)