Non-Optimal Multi-Homed Routing

Load vpnv4.non-optimal.routing.init.cfg

#IOS-XE
config replace flash:vpnv4.non-optimal.routing.init.cfg

#IOS-XR
configure
load bootflash:vpnv4.non-optimal.routing.init.cfg
commit replace
y

R1 and XR2 are located at the same customer site. The intention is for R1 to be used as the prefered exit point for routes to remote MPLS sites, so R1 sets LP to 110 on routes received from R2.

Currently there is asymmetric routing between R1 and XR2. Fix this without using BGP policy, and without removing the as-override command on the PEs.

R1#traceroute 20.20.20.20 so lo0
Type escape sequence to abort.
Tracing the route to 20.20.20.20
VRF info: (vrf in name/id, vrf out name/id)
  1 10.1.2.2 4 msec 0 msec 1 msec
  2 20.2.4.4 [MPLS: Labels 25/24016 Exp 0] 12 msec 12 msec 6 msec
  3 20.4.6.6 [MPLS: Labels 25/24016 Exp 0] 7 msec 6 msec 5 msec
  4 20.6.19.19 [MPLS: Label 24016 Exp 0] 6 msec 4 msec 4 msec
  5 10.19.20.20 12 msec *  6 msec

R1#tracer 2001::20:20:20:20 so lo0
Type escape sequence to abort.
Tracing the route to 2001::20:20:20:20

  1 2001:10:1:2::2 4 msec 1 msec 2 msec
  2 ::FFFF:20.2.4.4 [MPLS: Labels 25/24013 Exp 0] 24 msec 6 msec 7 msec
  3 ::FFFF:20.4.6.6 [MPLS: Labels 25/24013 Exp 0] 9 msec 8 msec 7 msec
  4  *  *  *
  5 2001::20:20:20:20 [AS 100] 31 msec 9 msec 6 msec


RP/0/0/CPU0:XR2#traceroute 1.1.1.1 so lo0

 1  10.1.19.1 19 msec  9 msec  9 msec


RP/0/0/CPU0:XR2#tracer 2001::1:1:1:1 so lo0

 1  2001:10:1:19::1 19 msec 9 msec 0 msec

Answer

#R2
router bgp 100
 address-family ipv4 vrf A
  neighbor 10.1.2.1 soo 100:65000
 address-family ipv6 vrf A
  neighbor 2001:10:1:2::1 soo 100:65000

** Note that I had to hard clear the sessions in order to get
** R2 to export VPNv4/6 routes with the SoO

#XR1
router bgp 100
 vrf A
  neighbor 10.19.20.20
   address-family ipv4 unicast
    site-of-origin 100:65000
  !
  neighbor 2001:10:19:20::20
   address-family ipv6 unicast
    site-of-origin 100:65000

Explanation

R1 is setting LP=110 on all routes received from R2. This includes prefixes that XR2 is advertising. Therefore, R1 is preferring the eBGP route over the iBGP route. (The iBGP route would normally win due to shorter AS path).

If you are not seeing XR2’s routes via eBGP on R1, this is due to the order that the BGP peering sessions came up. R2 is hiding XR2’s prefixes from R1 because it has a bestpath for XR2’s prefixes via R1 itself. You can do a hard reset on R1 so that it will initially learn the prefixes from both peers, and then will choose R2 due to the higher LP.

One way to prevent this is to simply turn off the as-override command on the PEs. The routers would reject the eBGP routes for loop prevention. However, if there are other sites in this VPN which re-use this same ASN, this might not be a good option.

A better solution is to use the SoO (Site of Origin) feature. This essentially just implements an extcommunity filter on the PEs. Routes received from the CE are tagged with the configured SoO value, and any routes to be advertised to the CEs containing this extcomm value are filtered. This is generally much easier than manually configuring a route-map which matches/sets the extcommunity value. All you need to do is associate a SoO value with the BGP neighbor.

#R2
router bgp 100
 address-family ipv4 vrf A
  neighbor 10.1.2.1 soo 100:65000
 address-family ipv6 vrf A
  neighbor 2001:10:1:2::1 soo 100:65000

#XR1
router bgp 100
 vrf A
  neighbor 10.19.20.20
   address-family ipv4 unicast
    site-of-origin 100:65000
  !
  neighbor 2001:10:19:20::20
   address-family ipv6 unicast
    site-of-origin 100:65000

On the PEs, we can see that the received VPNv4 updates now have this SoO extcommunity value:

R2 no longer advertises XR2’s prefixes to R1 because the SoO on the route matches R1’s configured SoO. So R1 only has the iBGP path left in its BGP table.

Note that this solution prevents the MPLS network from being used as a backup path. If the R1-XR2 iBGP session goes down, the routers will no longer have any reachability with each other. But in the real world, these two routers may be directly (physically) connected, so it may not be realistic to say that these routers would need to use the MPLS WAN as backup.