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
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).
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.
