Inter-AS L3VPN Pt. 4, Option C

Option C involves cooperation between the two SPs to a much greater extent than Option A or B. In Option C, the vpnv4 unicast table becomes globally significant. The LSP is end-to-end, as the VPN label advertised by PE in SP2 is learned by SP1. To accomplish this, the RRs in each SP peer with one another. In order for the RRs to peer and for PEs to have reachability to the vpnv4 routes advertised by the PEs in the other SP, the ASBRs advertise the loopbacks of the PEs to each other. This traffic has to be labeled of course, so instead of running LDP you run BGP-LU. Each /32 loopback IP that is advertised has a label associated with it, which is allocated by each ASBR.

I’m sure this sounds a little confusing, so let’s configure this and see how it works.

Lab

First we’ll remove the vpnv4 unicast neighborship between the ASBRs. We’ll create a BGP-LU session and redistribute /32s from OSPF into BGP, allocating a label for them.

#SP1_R3
ip prefix-list LOOPBACKS_PL permit 0.0.0.0/0 ge 32
!
route-map PE_LOOPBACKS
 match ip address prefix-list LOOPBACKS_PL
!
router bgp 100
 no address-family vpnv4
 redistribute ospf 1 route-map PE_LOOPBACKS
 neighbor 100.1.1.2 send-label

#SP2_XR1
route-policy PE_LOOPBACKS
 if destination in ( 0.0.0.0/0 eq 32 ) then
  pass
 exit
end-policy
!
router bgp 200
 address-family ipv4 unicast
  allocate-label route-policy PE_LOOPBACKS
  redistribute isis 1 route-policy PE_LOOPBACKS
 neighbor 100.1.1.1
   no address-family vpnv4 unicast
   address-family ipv4 labeled-unicast
    route-policy PE_LOOPBACKS in
    route-policy PE_LOOPBACKS out

The problem is that the PEs of both SPs share the same private loopback IPs. In the real world, you would need to coordinate this which would be quite a lot of work, or you would use public IP address space for your loopbacks, which uses up valueable IPv4 space. Let’s simply change the loopbacks of SP2 to 20.X.X.X for simplicity in this lab. Right now SP2_XR1 is not acting as a PE so we’ll just remove the session to the RR as well.

#SP2_XR1
int lo0
 ip add 20.1.1.1/32
!
router bgp 200
 no neighbor 10.2.2.2

#SP2_R2
int lo0
 ip add 20.2.2.2 255.255.255.255
!
router bgp 200
 no neighbor 10.1.1.1
 no neighbor 10.3.3.3
 neighbor 20.3.3.3 remote-as 200
 neighbor 20.3.3.3 update-source Loopback0
 !
 address-family vpnv4
  neighbor 20.3.3.3 activate
  neighbor 20.3.3.3 send-community extended
  neighbor 20.3.3.3 route-reflector-client

#SP2_R3
int lo0
 ip add 20.3.3.3 255.255.255.255
!
router bgp 200
 no neighbor 10.2.2.2
 neighbor 20.2.2.2 remote-as 200
 neighbor 20.2.2.2 update-source Loopback0
 !
 address-family vpnv4
  neighbor 20.2.2.2 activate
  neighbor 20.2.2.2 send-community extended

The ASBRs have learned the PE loopbacks and labels for these loopbacks via BGP-LU

SP1_R3#show bgp ipv4 unicast labels 
   Network          Next Hop      In label/Out label
   10.1.1.1/32      10.2.3.2        17/nolabel
   10.2.2.2/32      10.2.3.2        16/nolabel
   10.3.3.3/32      0.0.0.0         imp-null/nolabel
   20.1.1.1/32      100.1.1.2       nolabel/imp-null
   20.2.2.2/32      100.1.1.2       nolabel/24007
   20.3.3.3/32      100.1.1.2       nolabel/24008

RP/0/0/CPU0:SP2_XR1#show bgp ipv4 labeled-unicast labels | be Network
Sat Aug  6 23:56:18.828 UTC
   Network            Next Hop        Rcvd Label      Local Label
*> 10.1.1.1/32        100.1.1.1       17              24004
*> 10.2.2.2/32        100.1.1.1       16              24000
*> 10.3.3.3/32        100.1.1.1       3               24002
*> 20.1.1.1/32        0.0.0.0         nolabel         3
*> 20.2.2.2/32        10.1.2.2        nolabel         24007
*> 20.3.3.3/32        10.1.2.2        nolabel         24008

Now we’ll redistribute these into the IGP.

#SP1_R3
router ospf 1
 redistribute bgp 100 route-map PE_LOOPBACKS

#SP2_XR1
router isis 1
 address-family ipv4 unicast
  redistribute bgp 200 route-policy PE_LOOPBACKS

The RRs should be able to now peer with each other on the vpnv4 unicast addres-family. We need to set the RRs to leave the nexthop unchanged so that the RRs are not inserted into the traffic flow. This is an eBGP session, so by default the router will change the nexthop to itself. (With normal Intra-AS L3VPN, the RR would not change the nexthop on an iBGP learned route that is reflected to an iBGP client, so this is not an issue).

#SP1_R2
router bgp 100
 bgp router-id int lo0
 neighbor 20.2.2.2 remote-as 200
 neighbor 20.2.2.2 ebgp-multihop
 neighbor 20.2.2.2 update-source lo0
 address-family vpnv4
  neighbor 20.2.2.2 activate
  neighbor 20.2.2.2 next-hop-unchanged

#SP2_R2
router bgp 200
 bgp router-id int lo0
 neighbor 10.2.2.2 remote-as 100
 neighbor 10.2.2.2 ebgp-multihop
 neighbor 10.2.2.2 update-source lo0
 address-family vpnv4
  neighbor 10.2.2.2 activate
  neighbor 10.2.2.2 next-hop-unchanged

CE1 can now reach CE2:

CE1#ping 10.1.2.1 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.2.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 10/10/12 ms

CE1#traceroute 10.1.2.1 source lo0 probe 1
Type escape sequence to abort.
Tracing the route to 10.1.2.1
VRF info: (vrf in name/id, vrf out name/id)
  1 100.64.0.1 3 msec
  2 10.1.2.2 [AS 65001] [MPLS: Labels 20/18 Exp 0] 28 msec
  3 10.2.3.3 [MPLS: Labels 22/18 Exp 0] 18 msec
  4 100.1.1.2 [MPLS: Labels 24008/18 Exp 0] 11 msec
  5 10.1.2.2 [AS 65001] [MPLS: Labels 19/18 Exp 0] 12 msec
  6 100.64.1.1 [MPLS: Label 18 Exp 0] 12 msec
  7 100.64.1.2 52 msec

Notice above that the VPN label (18) is carried all the way through the LSP. SP1_XR1 has the route that SP2_R3 injected into the vpnv4 unicast table.

RP/0/0/CPU0:SP1_XR1#show bgp vpnv4 uni vrf CUSTOMER | be Network
Sun Aug  7 02:28:07.513 UTC
   Network            Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 100:1 (default for vrf CUSTOMER)
*> 10.1.1.0/24        100.64.0.2               0             0 65000 i
*>i10.1.2.0/24        20.3.3.3                 0    100      0 200 65001 i

Conclusion

Option C requires a lot of trust between the two SPs, and for this reason I would assume it is not used very often. SPs have to share routes to their PE loopbacks, which in itself has some issues you must account for. Each SP then exchanges its vpnv4 table through the RRs instead of through the ASBRs. This allows for more flexibility, as the ASBRs don’t need to exchange routes for vpnv4 unicast any longer. However this has more complexity than Option B given the need to exchange PE loopbacks and labels for these loopbacks over BGP-LU.