Date created: Wednesday, August 10, 2016 5:24:57 PM. Last modified: Thursday, November 22, 2018 10:55:39 AM

Inter-AS MPLS Option B RD & RT Behaviour (IOS)

It is important to note that only the PE that originates a route will add the export route-targets configured under the VRF to the route. In this example PE3 originates route 10.0.0.5/32 into BGP using "redistribute connected" under the "CUST1" VRF address family configuration within BGP. This route is not imported on PE1 into the CUST1 VRF table. PE2 imports the route and advertises it, but the "route-target export ..." statements are only applied to routes PE2 originates, since it did not originate this route, it is not adding RT 65001:250 to the route, PE1 has no matching import route targets and drops the advertised route from the BGP VPNv4 table:

! PE3
ip vrf CUST1
 rd 65001:300
 route-target export 65001:300
 route-target import 65001:300


! PE2
ip vrf CUST1
 rd 65001:300
 route-target export 65001:250
 route-target export 65001:300
 route-target import 65001:250
 route-target import 65001:300

! PE1
ip vrf CUST1
 rd 65001:250
 route-target export 65001:250
 route-target import 65001:250


PE2#show bgp vpnv4 unicast all neighbors 192.168.1.2 advertised-routes
...
     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 65001:300 (default for vrf CUST1)
 *>  10.0.0.3/32      0.0.0.0                  0         32768 ?
 *>  10.0.0.5/32      192.168.3.5              0             0 65102 ?

Total number of prefixes 2


PE2#show bgp vpnv4 unicast rd 65001:300 10.0.0.5/32
BGP routing table entry for 65001:300:10.0.0.5/32, version 38
Paths: (1 available, best #1, table CUST1)
  Advertised to update-groups:
     7
  Refresh Epoch 5
  65102
    192.168.3.5 from 192.168.3.5 (192.168.3.5)
      Origin incomplete, metric 0, localpref 100, valid, external, best
      Extended Community: RT:65001:300
      mpls labels in/out 19/16




PE1#show bgp vpnv4 unicast all
...
     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 65001:250 (default for vrf CUST1)
 *>  10.0.0.2/32      0.0.0.0                  0         32768 ?
 *>  10.0.0.3/32      192.168.1.3              0             0 65101 ?
Route Distinguisher: 65001:300
 *>  10.0.0.3/32      192.168.1.3              0             0 65101 ?


In the output below it can be observed that a the local PE uses RD 65001:250 for a VRF called "LIVE-VRF" and the same import and export RT of 65001:250. Several iBGP PEs are advertising a default route to this PE however they have learnt it over inter-AS connections, they are all ASBRs to the same external AS using Inter-AS MPLS Option B links. The external AS uses RD 65001:300 with import and export targets of 65001:300 and 65001:250. In this local AS only RD 65001:250 with RT 65001:250 is used, the VPNv4 route as it is received on the ASBRs from the external AS is 65001:300:0.0.0.0/0. Since there is no default route received from the external AS with RD 65001:250 this test PE looks at routes with a different RDs that have a valid export RT this VRF can import. This 65001:300:0.0.0.0/0 route matches the 65001:250 import RT but in the output below it is marked as "imported safety path from 65001:300:0.0.0.0/0" because the PE had to look outside of the desired RD to find a valid route to import (there was no best path with an RD of 65001:250):

TEST-PE#show run vrf BPSN-FIRE
Building configuration...

Current configuration : 102 bytes
ip vrf LIVE-VRF
 rd 65001:250
 route-target export 65001:250
 route-target import 65001:250


TEST-PE#show bgp vpnv4 unicast rd 65001:250 0.0.0.0
BGP routing table entry for 65001:250:0.0.0.0/0, version 960336
BGP Bestpath: compare-routerid
Paths: (1 available, best #1, table LIVE-VRF)
  Advertise-best-external
  Not advertised to any peer
  Refresh Epoch 2
  64999 65101, imported safety path from 65001:300:0.0.0.0/0 (global)
    10.0.0.4 (metric 2) (via default) from 10.0.0.4 (10.0.0.4)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Extended Community: RT:65001:250 RT:65001:300 , recursive-via-host
      mpls labels in/out nolabel/1554
      rx pathid: 0, tx pathid: 0x0


TEST-PE#show bgp vpnv4 unicast rd 65001:300 0.0.0.0
BGP routing table entry for 65001:300:0.0.0.0/0, version 3440443
BGP Bestpath: compare-routerid
Paths: (3 available, best #1, no table)
  Advertise-best-external
  Advertised to update-groups:
     2          4          5
  Refresh Epoch 1
  65001 47797
    10.0.0.2 (metric 2) (via default) from 10.0.0.2 (10.0.0.2)
      Origin IGP, localpref 100, valid, internal, best
      Extended Community: RT:65001:300 , recursive-via-host
      mpls labels in/out 7537/58531
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 7
  64999 65101
    10.0.0.4 (metric 2) (via default) from 10.0.0.4 (10.0.0.4)
      Origin incomplete, metric 0, localpref 100, valid, internal, backup/repair
      Extended Community: RT:65001:250 RT:65001:300 , recursive-via-host
      mpls labels in/out 7537/1554
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 7
  64999 65101
    10.0.0.254 (metric 2) (via default) from 10.0.0.254 (10.0.0.254)
      Origin incomplete, metric 0, localpref 100, valid, internal
      Extended Community: RT:65001:250 RT:65001:300 , recursive-via-host
      mpls labels in/out 7537/42413
      rx pathid: 0, tx pathid: 0


Also note in the output above for the "show bgp vpnv4 unicast rd 65001:250 0.0.0.0" command it says "(global)". This can be seen in the below output for the first command "imported path from (global)". The route 10.50.1.0/24 had RD 65001:300 attached but it, so it seems to be from a different routing table but it does have RT 65001:250 (as well as RT 65001:300). So it was imported to this VRF based on the RT but the next hop is in the global routing table, which is pretty common for an MP-BGP MPLS L3 VPN provider however the next hop PE which is the ASBR to where the route originated from, also when through the same process of importing from another RD because it also has no best path attached to RD 65001:250. This is why it is called out with the "(global)" tag.

The second route below comes from an iBGP neighbour but there is no "(global)" tag because that iBGP peer (which is an ASBR to the same external AS) has the same RD as the external ASBR and the local PE:

TEST-PE#show bgp vpnv4 unicast rd 65001:250 10.50.1.0/24
BGP routing table entry for 65001:250:10.50.1.0/24, version 7781136
BGP Bestpath: compare-routerid
Paths: (1 available, best #1, table LIVE-VRF)
  Advertise-best-external
  Not advertised to any peer
  Refresh Epoch 5
  64999 65002, imported path from 65001:300:10.50.1.0/24 (global)
    10.0.0.4 (metric 2) (via default) from 10.0.0.4 (10.0.0.4)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Extended Community: RT:65001:250 RT:65001:300 , recursive-via-host
      mpls labels in/out nolabel/14278
      rx pathid: 0, tx pathid: 0x0



TEST-PE#show bgp vpnv4 unicast rd 65001:250 10.50.0.80/30
BGP routing table entry for 65001:250:10.50.0.80/30, version 9438087
BGP Bestpath: compare-routerid
Paths: (1 available, best #1, table LIVE-VRF)
  Advertise-best-external
  Advertised to update-groups:
     2          4          5          12
  Refresh Epoch 7
  64594
    10.0.0.254 (metric 2) (via default) from 10.0.0.254 (10.0.0.254)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Extended Community: RT:65001:250 , recursive-via-host
      mpls labels in/out 32405/76642
      rx pathid: 0, tx pathid: 0x0