Inter-AS MPLS Option B Route Retention (IOS & IOS-XR)


An IOS ASBR will only advertise to iBGP peers (by default) routes that it has learnt from an eBGP peer that are installed into the FIB. In the case of an Inter-AS MPLS Option B (eBGP VPN peering), every VRF must exist on the IOS ASBR (no local interface is required in each VRF) before the eBGP learnt route will be advertises to an iBGP neighbour of the ASBR.

To break this and advertise all routes received over the Inter-AS VPN session configure “no bgp default route-target filter”. This can be configured under the VPN address family. Now the ASBR will store the routes in the RIB and enter them into the FIB. For example, running “show mpls forwarding-table” will show that LFIB entries exist for all those routes with local labels assigned. However this command affects all VPN peers under the address-family, it can not be applied per-neighbour.

ASBR2-IOS#show bgp vpnv4 unicast all
BGP table version is 10, local router ID is
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 200:1
 *>                0             0 200 ?
Route Distinguisher: 200:2
 *>                0             0 200 ?
Route Distinguisher: 200:3
 *>                0             0 200 ?
Route Distinguisher: 200:4
 *>                0             0 200 ?
Route Distinguisher: 200:5
 *>                0             0 200 ?

ASBR2-IOS#show mpls forwarding-table
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
16         Pop Label     0             Fa0/1
17         Pop Label      0             Fa0/0
18         Pop Label     0             Fa0/0
19         16         200:1: 0             Fa0/1
20         17         200:2: 0             Fa0/1
21         18         200:3: 0             Fa0/1
22         19         200:4: 0             Fa0/1
23         20         200:5: 0             Fa0/1


The same behaviour is true for IOS-XR as well as IOS. With IOS-XR for an Option B one must also add the /32 static route pointing to the peer IP via the next-hop interface. For IOS-XR the equivalent command is "retain route-target all" which again is applied to the VPN address-family under BGP and affects all VPN peers advertising VPN routes to this ASBR (iBGP and eBGP) just like IOS. Just like with IOS, an IOS-XR ASBR will only store and advertise to iBGP neighbours routes for which is also has the VRF defined so they can be put in the FIB, and thus LFIB and a local label assigned.

On IOS-XR one can use a route-policy with the retain route-target option to filter RTs without having to have all the VRFs defined locally on the ASBR (this is the preferred design for scalability) and still advertise the inter-AS route within the local iBGP. One can also set the label timeout to 5 minutes (for example) for the Option B MP-BGP labels, to ensure that during a failure scenario traffic sent to the local ABSR (assuming it was the primary path) will still be accepted and although the local ASBR to forward to the new ABSR (assuming BGP PIC is in place so that the backup path was already present on the local ASRB):

extcommunity-set rt my-rt-set
  ios-regex '65001:20[0-9][0-9]',

route-policy retain-rt
  if extcommunity rt matches-any my-rt-set then

router bgp 12345
 address-family vpnv4 unicast
  retain route-target route-policy retain-rt
  retain local-label 5