Inter-AS MPLS L3VPN – Option B – ASBR + VPNv4

This is the second post based on my topology over here

Option B is a little more involved. Instead of having multiple subinterfaces in VRFs on the ASBR routers, the ASBRs peer with each other directly using VPNv4 BGP.

To illustrate, the VPNv4 updates go from R2 to R12 (route-relector) and then get to R13. R13 advertises this information over to R14. R14 then advertises this to R8:

The ASBRs of R13, R14, R5, and R6 need to be able to send labelled frames to each other. However we certainly don’t want to be running LDP or RSVP with another network. We need to somehow get labels advertised for these routes. BGP can be used to do this.

ASBR config

Let’s concentrate on R13 again. R13 has a VPNv4 session with R12, the route-reflector. I’m going to remove the subinterfaces created in my last post and simply make gi1/0 a regular link:

interface GigabitEthernet1/0
 ip address 10.13.14.13 255.255.255.0

Configure a VPNv4 session with R14:

router bgp 100
 no bgp default ipv4-unicast
 neighbor 10.13.14.14 remote-as 200
 !
 address-family vpnv4
  neighbor 10.13.14.14 activate
  neighbor 10.13.14.14 send-community extended

We also need to tell IOS to not drop labelled packets coming over the inter-AS link:

interface GigabitEthernet1/0
 mpls bgp forwarding

R14 has been configured the same way. Let’s see if we see R1’s routing information on R13:

R13#show bgp vpnv4 unicast all 1.1.1.1
% Network not in table

Nothing. Why? Well currently R13 doesn’t have any interfaces in the VRF. The default on IOS is to drop VPNv4 updates for RT’s that we do not have a local VRF for. The sledgehammer to fix this is to ensure R13 won’t be dropping any of the VPNv4 routes. In a normal network this would be closely controlled outbound on the route-reflector.

R13#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R13(config)#router bgp 100
R13(config-router)#no bgp default route-target filter

Now we should have it:

R13#show bgp vpnv4 unicast all 1.1.1.1
BGP routing table entry for 2.2.2.2:1:1.1.1.1/32, version 17
Paths: (1 available, best #1, no table)
  Advertised to update-groups:
     1
  Local
    2.2.2.2 (metric 30) from 12.12.12.12 (12.12.12.12)
      Origin incomplete, metric 2, localpref 100, valid, internal, best
      Extended Community: RT:100:1 OSPF DOMAIN ID:0x0005:0x000000020200
        OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.12.2:0
      Originator: 2.2.2.2, Cluster list: 12.12.12.12
      mpls labels in/out 24/16

Let’s check R14 to ensure we are learning this information:

R14#show bgp vpnv4 unicast all 1.1.1.1 bestpath
BGP routing table entry for 2.2.2.2:1:1.1.1.1/32, version 14
Paths: (2 available, best #1, no table)
  Advertised to update-groups:
     2
  100
    10.13.14.13 from 10.13.14.13 (13.13.13.13)
      Origin incomplete, localpref 100, valid, external, best
      Extended Community: RT:100:1 OSPF DOMAIN ID:0x0005:0x000000020200
        OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.12.2:0
      mpls labels in/out 22/24

So R14 has it. So far so good. Does R14 advertise this down to R8 and does R8 have a valid route?

R8#show bgp vpnv4 unicast all 1.1.1.1
BGP routing table entry for 2.2.2.2:1:1.1.1.1/32, version 12
Paths: (2 available, no best path)
  Not advertised to any peer
  100, (Received from a RR-client)
    10.5.6.5 (inaccessible) from 6.6.6.6 (6.6.6.6)
      Origin incomplete, metric 0, localpref 100, valid, internal
      Extended Community: RT:100:1 OSPF DOMAIN ID:0x0005:0x000000020200
        OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.12.2:0
      mpls labels in/out nolabel/16
  100, (Received from a RR-client)
    10.13.14.13 (inaccessible) from 14.14.14.14 (14.14.14.14)
      Origin incomplete, metric 0, localpref 100, valid, internal
      Extended Community: RT:100:1 OSPF DOMAIN ID:0x0005:0x000000020200
        OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.12.2:0
      mpls labels in/out nolabel/24

R8 has learnt it, but look closely. Neither route is usable. A quick best-path look will show:

R8#show bgp vpnv4 unicast all 1.1.1.1 bestpath
BGP routing table entry for 2.2.2.2:1:1.1.1.1/32, version 12
Paths: (2 available, no best path)
  Not advertised to any peer

The reason is quite obvious. When R14 learns the route from R13, the next-hop is R13’s address. R8 doesn’t have this route. There are a number of ways to fix it, but the easiest is just to ensure that R14 sets the next-hop to itself when advertising to the route-reflector:

R14(config)#router bgp 200
R14(config-router)#address-family vpnv4
R14(config-router-af)#neighbor 8.8.8.8 next-hop-self

We should now have it:

R8#show bgp vpnv4 unicast all 1.1.1.1 bestpath
BGP routing table entry for 2.2.2.2:1:1.1.1.1/32, version 16
Paths: (2 available, best #2, no table)
  Advertised to update-groups:
     1
  100, (Received from a RR-client)
    14.14.14.14 (metric 3) from 14.14.14.14 (14.14.14.14)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Extended Community: RT:100:1 OSPF DOMAIN ID:0x0005:0x000000020200
        OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.12.2:0
      mpls labels in/out nolabel/22

Now that R8 has the VPNv4 information, will this get into OSPF on the PE-CE link?

R8#sh ip route vrf CUS1 1.1.1.1

Routing Table: CUS1
% Network not in table

No. Why? Take a look up again. The route-target on this NLRI has a RT value of 100:1. R8 is using 200:1 as the RT value for CUS1. I could configure R8 to import and export 100:1, I could use a route-map to manipulate the values, or get R2 to import/export 200:2 – For now I’ll just ensure R8 is importing/exporting 100:1

R8#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R8(config)#vrf def CUS1
R8(config-vrf)#route-target both 100:1

R8 should now have it in it’s table:

R8#sh ip route vrf CUS1 1.1.1.1

Routing Table: CUS1
Routing entry for 1.1.1.1/32
  Known via "bgp 200", distance 200, metric 0
  Tag 100, type internal
  Redistributing via ospf 2
  Advertised by ospf 2 subnets
  Last update from 14.14.14.14 00:00:58 ago
  Routing Descriptor Blocks:
  * 14.14.14.14 (default), from 14.14.14.14, 00:00:58 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 100
      MPLS label: 22
      MPLS Flags: MPLS Required

Verification

Are you still with me? The end result of this is that R1 should be able to ping R11 from it’s loopback:

R1#ping 11.11.11.11 so lo0

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

That we see.

If we traceroute, we will see that the inter-as link is now labelled. The VPN/VC label will change, but it’s still labelled:

R1#traceroute 11.11.11.11 so lo0

Type escape sequence to abort.
Tracing the route to 11.11.11.11

  1 10.0.12.2 12 msec 12 msec 4 msec
  2 10.0.23.3 [MPLS: Labels 19/21 Exp 0] 36 msec 24 msec 44 msec
  3 10.0.33.13 [MPLS: Label 21 Exp 0] 16 msec 24 msec 52 msec
  4 10.13.14.14 [MPLS: Label 23 Exp 0] 36 msec 12 msec 56 msec
  5 10.0.146.6 [MPLS: Labels 24/24 Exp 0] 12 msec 28 msec 52 msec
  6 10.0.118.8 [MPLS: Label 24 Exp 0] 12 msec 24 msec 20 msec
  7 10.0.118.11 28 msec *  28 msec

We can view the labels used over the BGP link like so:

R13#show bgp vpnv4 unicast all labels
   Network          Next Hop      In label/Out label
Route Distinguisher: 2.2.2.2:1
   1.1.1.1/32       2.2.2.2         16/16
   10.0.12.0/24     2.2.2.2         17/17
Route Distinguisher: 8.8.8.8:1
   10.0.118.0/24    10.13.14.14     20/22
   11.11.11.11/32   10.13.14.14     21/23
Route Distinguisher: 9.9.9.9:2
   10.0.109.0/24    10.13.14.14     22/24
   10.10.10.10/32   10.13.14.14     23/25
Route Distinguisher: 12.12.12.12:1
   7.7.7.7/32       12.12.12.12     18/16
   10.0.127.0/24    12.12.12.12     19/17

So there you have it. Option B is more scalable that Option A, but it does require inter-AS politics which is usually not fun.

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