Inter-AS MPLS L3VPN – Option C – BGP + Label

This is the third post based on my topology over here

The full name of this in Cisco’s terms is ‘MPLS VPN Inter-AS with ASBRs Exchanging IPv4 Routes and MPLS Labels’ Let’s take a look at the topology again

R12 and R8 are route-reflectors in each AS. Option C allows you to get the route-reflectors to peer directly with each other over VPNv4. Note that these don’t HAVE to be route-reflectors, but it’s far more likely that they are.

The ASBRs of R13, R14, R5, and R6 are peering over regular IPv4. One slight difference is that they are sending labels as well.

If you though the Option B post was long, this post is going to be about twice as long so hopefully you won’t fall asleep.

I’ve removed all BGP config from the ASBR routers. At the moment R2 is peering with R12 over VPNv4 and R8 is peering with R9 over VPNv4. As always I’ll concentrate on a single ASBR, R13.

ASBR Config

First let’s set up a regular eBGP session over to R14. I’ll also ensure we are sending labels:

router bgp 100
 neighbor 10.13.14.14 remote-as 200
 !
 address-family ipv4
  neighbor 10.13.14.14 activate
  neighbor 10.13.14.14 send-label
 exit-address-family

The next step is to get R12 and R8 to peer with each other. In order to peer, they need routes to each other. I’ll match R12’s loopback interface in a route-map and redistribute into BGP:

ip prefix-list PE_ADDRESS seq 5 permit 12.12.12.12/32
!
route-map LEAK_PE permit 10
 match ip address prefix-list PE_ADDRESS
!
router bgp 100
 !
 address-family ipv4
  redistribute isis level-2 route-map LEAK_PE

I’ve done a similar config for R14. This means that R13 should see 8.8.8.8 as a BGP route:

R13#sh ip route 8.8.8.8
Routing entry for 8.8.8.8/32
  Known via "bgp 100", distance 20, metric 3
  Tag 200, type external
  Last update from 10.13.14.14 00:44:02 ago
  Routing Descriptor Blocks:
  * 10.13.14.14, from 10.13.14.14, 00:44:02 ago
      Route metric is 3, traffic share count is 1
      AS Hops 1
      Route tag 200
      MPLS label: 23

Notice that I’ve also got a transport label to use. this was learned through BGP. We can verify R13 will use it when sending traffic to R8:

R13#sh mpls forwarding-table 8.8.8.8
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
24         23         8.8.8.8/32       46625         Gi1/0      10.13.14.14

R13 is not peering with R12 over BGP, so I need to get those BGP routes into the IGP. Always a good idea to use a route-map for this:

ip prefix-list AS200_PREFIXES seq 5 permit 8.8.8.8/32
!
route-map AS200_PREFIX_MAP permit 10
 match ip address prefix-list AS200_PREFIXES
!
router isis
 redistribute bgp 100 route-map AS200_PREFIX_MAP

Once this is also done on the ASBRs I should be able to ping between the route-reflectors:

R12#ping 8.8.8.8 so lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 12.12.12.12
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/29/36 ms

Route-Reflector VPNv4 set up

As the route-reflectors now have IP reachability, I can configure a VPNv4 session between them. Let’s concentrate on R12 for this example:

router bgp 100
 no bgp default ipv4-unicast
 neighbor 8.8.8.8 remote-as 200
 neighbor 8.8.8.8 ebgp-multihop 255
 neighbor 8.8.8.8 update-source Loopback0
 !
 address-family vpnv4
  neighbor 8.8.8.8 activate
  neighbor 8.8.8.8 send-community extended

The session should come straight up:

R12#show bgp vpnv4 unicast all sum  | beg Nei
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
2.2.2.2         4          100      71      77       27    0    0 01:02:03        2
8.8.8.8         4          200      17      17       27    0    0 00:09:03        4

It has. And we are learning prefixes already so that’s all good. Let’s check R12’s CUS2 vrf table to see if we see R10’s loopback:

R12#sh ip route vrf CUS2 10.10.10.10

Routing Table: CUS2
% Subnet not in table

No. And the reason can be seen here. We had the same issue with the option B post if you remember.

R12#show bgp vpnv4 un all 10.10.10.10
BGP routing table entry for 9.9.9.9:2:10.10.10.10/32, version 7
Paths: (1 available, best #1, no table)
  Advertised to update-groups:
     5
  200
    8.8.8.8 (metric 20) from 8.8.8.8 (8.8.8.8)
      Origin incomplete, localpref 100, valid, external, best
      Extended Community: RT:200:2 OSPF DOMAIN ID:0x0005:0x000000020200
        OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.109.9:0
      mpls labels in/out nolabel/27

The RT for this NLRI is 200:2. We are importing 100:2 on the ISP1 side. In my previous post we did a quick fix of getting the PE to import/export both targets, but let’s try another way.
I’d like R12 and R8 to change the RT value inbound. So if R12 learns a route with a RT value of 200:2, I want it replaced with 100:2. This can be done with a route-map:

ip extcommunity-list standard 200:1 permit rt 200:1
ip extcommunity-list standard 200:2 permit rt 200:2
!
route-map CHANGE_COMMUNITY permit 10
 match extcommunity 200:1
 set extcommunity rt  100:1
route-map CHANGE_COMMUNITY permit 20
 match extcommunity 200:2
 set extcommunity rt  100:2
!
router bgp 100
!
 address-family vpnv4
  neighbor 8.8.8.8 route-map CHANGE_COMMUNITY in

This should work:

R12#show bgp vpnv4 un all 10.10.10.10 | include Community
      Extended Community: RT:100:2 OSPF DOMAIN ID:0x0005:0x000000020200
      Extended Community: RT:100:2 OSPF DOMAIN ID:0x0005:0x000000020200

Which means that 10.10.10.10/32 should be in the CUS2 VRF table:

R12#show ip route vrf CUS2 10.10.10.10

Routing Table: CUS2
Routing entry for 10.10.10.10/32
  Known via "bgp 100", distance 20, metric 0
  Tag 200, type external
  Redistributing via ospf 2
  Advertised by ospf 2 subnets
  Last update from 8.8.8.8 00:01:31 ago
  Routing Descriptor Blocks:
  * 8.8.8.8 (default), from 8.8.8.8, 00:01:31 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 200
      MPLS label: 27
      MPLS Flags: MPLS Required

Initial verification

Let’s check is R7 can get to R10:

R7#ping 10.10.10.10 so lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:
Packet sent with a source address of 7.7.7.7
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/40/60 ms

Yes it can. However don’t be so quick. Let’s do a traceroute to see if all is okay:

R7#traceroute 10.10.10.10 so lo0

Type escape sequence to abort.
Tracing the route to 10.10.10.10

  1 10.0.127.12 4 msec 4 msec 8 msec
  2 10.0.123.3 [MPLS: Labels 32/26/27 Exp 0] 32 msec 52 msec 40 msec
  3 10.0.33.13 [MPLS: Labels 26/27 Exp 0] 88 msec 48 msec 52 msec
  4 10.13.14.14 [MPLS: Labels 23/27 Exp 0] 48 msec 44 msec 52 msec
  5 10.0.146.6 [MPLS: Labels 19/27 Exp 0] 40 msec 52 msec 28 msec
  6 10.0.68.8 [MPLS: Label 27 Exp 0] 60 msec 12 msec 52 msec
  7 10.0.68.6 [MPLS: Labels 16/24 Exp 0] 48 msec 40 msec 36 msec
  8 10.0.109.9 [MPLS: Label 24 Exp 0] 16 msec 28 msec 36 msec
  9 10.0.109.10 56 msec *  36 msec

The packets gets to R10 eventually, but check the path. the packet goes from R7 to R12, R3, R13, R14, R6, R8, back to R6, R9, R10

Let’s draw it out:

The reason this is happening is because R8 is setting the next-hop to iself when advertising the VPNV4 route over:

R12#show bgp vpnv4 un rd 9.9.9.9:2 10.10.10.10
BGP routing table entry for 9.9.9.9:2:10.10.10.10/32, version 7
Paths: (1 available, best #1, no table)
  Advertised to update-groups:
     8
  200
    8.8.8.8 (metric 20) from 8.8.8.8 (8.8.8.8)
      Origin incomplete, localpref 100, valid, external, best
      Extended Community: RT:100:2 OSPF DOMAIN ID:0x0005:0x000000020200
        OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.109.9:0
      mpls labels in/out nolabel/27

Setting the next-hop to itself is the default behaviour when running eBGP VPNv4. What we need is to ensure that the route-reflectors do not change the next-hop to themselves when advertising. However if R8 advertises R9’s loopback as the next-hop, we need to adjust our earlier route-maps to allow 9.9.9.9/32 to come through as a route. I’ll show R13 here again. R14 is doing a very similar job.

ip prefix-list AS200_PREFIXES seq 10 permit 9.9.9.9/32
ip prefix-list PE_ADDRESS seq 10 permit 2.2.2.2/32

Now configure the route-reflectors not to change the next-hop:

router bgp 100
 !
 address-family vpnv4
  neighbor 8.8.8.8 next-hop-unchanged

This should change the next-hop value:

R12#sh bgp vpnv4 unicast rd 9.9.9.9:2 10.10.10.10
BGP routing table entry for 9.9.9.9:2:10.10.10.10/32, version 7
Paths: (1 available, best #1, no table)
  Advertised to update-groups:
     4
  200
    9.9.9.9 (metric 20) from 8.8.8.8 (8.8.8.8)
      Origin incomplete, localpref 100, valid, external, best
      Extended Community: RT:100:2 OSPF DOMAIN ID:0x0005:0x000000020200
        OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.109.9:0
      mpls labels in/out nolabel/24

Final verification

So here we are at last. Let’s run this traceroute again:

R7#traceroute 10.10.10.10 so lo0

Type escape sequence to abort.
Tracing the route to 10.10.10.10

  1 10.0.127.12 8 msec 16 msec 4 msec
  2 10.0.123.3 [MPLS: Labels 23/25/24 Exp 0] 36 msec 12 msec 32 msec
  3 10.0.33.13 [MPLS: Labels 25/24 Exp 0] 52 msec 16 msec 24 msec
  4 10.13.14.14 [MPLS: Labels 22/24 Exp 0] 20 msec 16 msec 32 msec
  5 10.0.109.9 [MPLS: Label 24 Exp 0] 16 msec 24 msec 24 msec
  6 10.0.109.10 24 msec *  24 msec

Much better. A route-reflector is often not in the transit path so it’s essential that this last step be done.

© 2009-2019 Darren O'Connor All Rights Reserved -- Copyright notice by Blog Copyright