Utilizing VRFs making 1 router appear as multiple routers

I had an internal struggle with myself, one as a studier and the other as an instructor. How do I make really cool labs and demos with really big topologies and not have 30 routers running. The conundrum. After an internal conversation with myself I had an epiphany. Why not use VRFs?

Ok so with VRFs you are able to make a router act like a switch. How so you may ask? Simple! What helps you breakup a switch into multiple broadcast domains? VLANs of course. So I did that very same thing except with a router. I took R11 and R12 (see the topology below this paragraph) and configured them so that R11 (Customer 1) and R12 (Customer 2) would be 1 router acting like 6 different sites.

As you can see R11 and R12 are each in 6 different locations. But R11 S1-S6 are the same CSR1000v same with R12. All you have to do is create the VRF, configure the RD (Route Distinguisher), not really needed for this but I set it up anyways. Then you place the appropriate Dot1q Sub Interface in the appropriate VRF and viola. 

So if you were to take a peak at R11S2 and R11S1 (both at the top of the topology), you'll see that each router connects to a different PE device, both of which are XRvs. I tested out the MPLS L3 VPN configuration on it. The only special thing you have to do is on R11S2, you have to send traceroutes out the R11S2 VRF. 

R11#traceroute vrf R11S2 11.21.0.11 source lo0 numeric

The output given was the MPLS labeled path from XR1 to R1 to XR2. Essentially R11S2 had trace to itself through the MPLS cloud and came in on a different interface which is in a different routing table due to the VRF config. 

I'll give you some homework, I'll give you the config for R12S1, you just have to get the rest done on your own. I give the R12 RD 2 and R11 RD 1, Site 1 is RD 2:1, Site 2 is RD 2:2 etc.

vrf definition R12S1

 rd 2:1

 !

 address-family ipv4

  route-target export 2:1

  route-target import 2:1

 exit-address-family

 !

 address-family ipv6

  route-target export 2:1

  route-target import 2:1

 exit-address-family

interface GigabitEthernet1.1213

 encapsulation dot1Q 1213

 vrf forwarding R12S1

 ip address 12.13.0.12 255.255.255.0

 ipv6 address 2001:12:13::12/64

R12(config-subif)#do sh run int g1.1213

Building configuration...

Current configuration : 134 bytes

!

interface GigabitEthernet1.1213

 encapsulation dot1Q 1213

 ip address 12.13.0.12 255.255.255.0

 ipv6 address 2001:12:13::12/64

end

When you go to apply the VRF to the interface, the IP addressing is removed since you are leaving the global routing table and entering a VRF. A sh run of the interface will ensure you have the addressing you need.

R12(config-subif)#vrf for

R12(config-subif)#vrf forwarding R12S1

% Interface GigabitEthernet1.1213 IPv4 disabled and address(es) removed due to disabling VRF R12S1

% Interface GigabitEthernet1.1213 IPv6 disabled and address(es) removed due to disabling VRF R12S1

R12(config-subif)#ip address 12.13.0.12 255.255.255.0

R12(config-subif)# ipv6 address 2001:12:13::12/64

Thanks for stopping by and I hope that this was helpful.
Rob Riker, CCIE #50693, VCP5/6-DCV

OSPFv2 Base Config on IOS and IOS XR

As I progress through my SPv4 prep I will routinely and often put together posts that may help another engineer or lone wolf studier out. I plan on breaking down the posts into into individual configuration posts, like this one where we focus on just 1 specific configuration feature, OSPFv2 between IOS and IOS XR. Then we'll take a look in a future post about OSPFv3 in the same manner.

For those with a R&S background this will be simple and almost not worth your time but it's the IOS XR configuration that is more important. The below topology is what I will be using for all of the OSPF posts.

On all the IOS devices, R4-R7 on the LAN and Loopack interfaces we'll start with configuring the network statement on the LAN interfaces to the /24 level and the interface configuration on the loopbacks, so you'll see the 2 main ways. There is a third with redistribution calling a route-map that specifies the interfaces.

R4

R4(config-router)#do sh run | sec ospf

router ospf 1

 network 10.4.7.0 0.0.0.255 area 0

 network 10.4.15.0 0.0.0.255 area 0

 network 10.5.4.0 0.0.0.255 area 0

interface Loopback0

 ip ospf 1 area 0

R5

R5(config-router)#do sh run | sec ospf

router ospf 1

 network 10.5.4.0 0.0.0.255 area 0

 network 10.5.6.0 0.0.0.255 area 0

interface Loopback0

 ip ospf 1 area 0

R6

R6(config-if)#do sh run | sec ospf

router ospf 1

 network 10.5.6.0 0.0.0.255 area 0

 network 10.6.7.0 0.0.0.255 area 0

interface Loopback0

 ip ospf 1 area 0

R7

R7(config-if)#do sh run | sec ospf

router ospf 1

 network 10.4.7.0 0.0.0.255 area 0

 network 10.6.7.0 0.0.0.255 area 0

 network 10.7.16.0 0.0.0.255 area 0

interface Loopback0

 ip ospf 1 area 0

Verification is the 2nd most important part, you can see that we have full adjacency with R4 and R6.

R7(config-if)#do sh ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface

4.4.4.4           1   FULL/DR         00:00:35    10.4.7.4        GigabitEthernet1.47

6.6.6.6           1   FULL/DR         00:00:36    10.6.7.6        GigabitEthernet1.67

Now it's time for IOS XR, the configuration is very simple, now that I've done it like 50 times it's easy. Slightly different command structure but, at the end of the day you'll see where things jive.

XR5

RP/0/0/CPU0:XR5(config-ospf-ar-if)#do sh run router ospf

Tue Jun 14 23:33:39.549 UTC

router ospf 1

 area 0

  interface Loopback0

  !

  interface GigabitEthernet0/0/0/0.415

  !

  interface GigabitEthernet0/0/0/0.1516

XR6

RP/0/0/CPU0:XR6(config-ospf-ar-if)#do sh run router ospf

Tue Jun 14 23:34:26.836 UTC

router ospf 1

 area 0

  interface Loopback0

  !

  interface GigabitEthernet0/0/0/0.716

  !

  interface GigabitEthernet0/0/0/0.1516

The functional difference is everything is configured globally under the routing process. So when you want to do anything to the protocol, go the appropriate sub feature and configure it. As we get into more configuration depth in later posts you'll see exactly what I mean. 

Verification on XR is very similar to IOS

RP/0/0/CPU0:XR6#sh ospf nei

Tue Jun 14 23:36:11.048 UTC

* Indicates MADJ interface

Neighbors for OSPF 1

Neighbor ID     Pri   State           Dead Time   Address         Interface

7.7.7.7         1     FULL/DR         00:00:36    10.7.16.7       GigabitEthernet0/0/0/0.716

    Neighbor is up for 00:01:48

15.15.15.15     1     FULL/DR         00:00:35    10.15.16.15     GigabitEthernet0/0/0/0.1516

    Neighbor is up for 00:01:49

RP/0/0/CPU0:XR6#sh ospf interface brief

Tue Jun 14 23:36:30.197 UTC

* Indicates MADJ interface, (P) Indicates fast detect hold down state

Interfaces for OSPF 1

Interface          PID   Area            IP Address/Mask    Cost  State Nbrs F/C

Lo0                1     0               16.16.16.16/32     1     LOOP  0/0

Gi0/0/0/0.716      1     0               10.7.16.16/24      1     BDR   1/1

Gi0/0/0/0.1516     1     0               10.15.16.16/24     1     BDR   1/1

There you have it. Pretty simple. I won't do a debug dump or wireshark capture at least for this as it's a base config. I will do debug outputs as we get into more interesting configs later so you can see mis-configurations and the "deltas" or differences in case you are here for troubleshooting support. 

Thanks for stopping by and stay tuned for more content in the future.

Rob Riker, CCIE #50693, VCP5/6-DCV

MPLS L3VPN Inter AS Option B or Option 2- VPN-IPv4 Addresses

In our last post we took a look at Option A where we had back to back VRF exchange.

In this post we will take a look at Option B or VPN-IPv4 Address exchange. In human terms, instead of VRF to VRF connectivity, we will form an EBGP VPNv4 peering between R1 and XR1. We will eliminate the VRFs on the PE to PE connection. At this point we have a working solution that I will show verification of toward the end. I won't be rebuilding the IGP/LDP/VPNv4 iBGP connectivity but just modifying the PE to PE connectivity.

Check this link to see the previous post and the link to the configuration.
MPLS L3 VPN Option A

So first things first, the PE to PE connectivity:
We need to remove the VRFs from the interfaces, the VRF aware IGP processes.

R1
conf t
no ip vrf A
no ip vrf B
no ip vrf C
!
int g2.100
encap dot1q 100
ip add 20.100.0.1 255.255.255.0

XR1
conf t
int g0/0/0/0.100
no ip add
int g0/0/0/0.200
no ip add
int g0/0/0/0.300
no ip add
commit
!
int g0/0/0/0.100
encap dot1q 100
ip add 20.100.0.19/24
no int g0/0/0/0.200
no int g0/0/0/0.300
commit
router ospf 1
no vrf A
no router eigrp 1
no router rip
commit
router bgp 2
no vrf A
no vrf B
no vrf C
commit

This should remove all of the VRF aware configuration.

Now to setup the BGP VPNv4 EBGP peerings
R1
router bgp 1
neighbor 20.100.0.19 remote-as 2
address-family vpnv4
  neighbor 20.100.0.19 activate

XR1
conf t
route-policy PASS
  pass
end-policy
!
router bgp 2
 address-family ipv4 unicast
 !
 address-family vpnv4 unicast
 !
 neighbor 20.100.0.1
  remote-as 1
  address-family vpnv4 unicast
   route-policy PASS in
   route-policy PASS out


Because this is VPNv4 over BGP we need to make sure that the LSP are maintained end to end

There are a couple things that need to be done. First the PEs don't have VRFs configured any more so by default we won't be receiving VPNv4 updates. We need to tell IOS and IOS XR to accept updates.

IOS
R1
router bgp 1
no bgp default route-target filter

IOS XR
router bgp 2
address-family vpnv4 unicast
  retain route-target all

This enables the extended communities to be received and maintained even if there are route target import values configured since there aren't VRFs on the R1 or XR1.

The second thing that needs to be done is R1 needs to advertise BGP labels to XR1. XR1 needs to have a way to send BGP Labels to R1. By default R1 will issue the mpls bgp forwarding command to enable label advertisement on the G2.100 interface. To enable MPLS forwarding on directly connected loopback interfaces. XR1 by default doesn't inject a /32 host route to the next hop of R1 and doesn't generate a label for that. So XR1 needs to configure a static host route to R1

R1
interface GigabitEthernet2.100
 mpls bgp forwarding

show mpls forwarding-table
24         Pop Label  20.100.0.19/32   0             Gi2.100    20.100.0.19

XR1
router static
 address-family ipv4 unicast
  20.100.0.1/32 GigabitEthernet0/0/0/0.100

sh route
S    20.100.0.1/32 is directly connected, 02:44:15, GigabitEthernet0/0/0/0.100

show mpls forwarding-table
24018  Pop         20.100.0.1/32      Gi0/0/0/0.100 20.100.0.1

The next step in the process is to look at the Route reflectors, R2 and XR2 respectively. By default, they will receive BGP VPNv4 updates from R1 and XR1 respectively and have the next hop set to the address used to form the BGP peering. R2 will have a next hop of XR1 20.100.0.19 and XR2 will have a next of R1 20.100.0.1. From R2 and XR2s perspective, these next hop values are unreachable. We need to change the next hop value for both R2 and XR2, R2 will see R1 and XR2 will see XR1.

R1
router bgp 1
address-family vpnv4
  neighbor 2.2.2.2 next-hop-self

XR1
router bgp 2
neighbor 20.20.20.20
  remote-as 2
  update-source Loopback0
  address-family vpnv4 unicast
   next-hop-self

At this point we should be in pretty good shape. All the work has been on the PEs of R1 and XR1. So let's test connectivity.

R9 to R12

R9#traceroute 12.12.12.12 source 9.9.9.9 num
Type escape sequence to abort.
Tracing the route to 12.12.12.12
VRF info: (vrf in name/id, vrf out name/id)
  1 30.4.9.4 16 msec 9 msec 6 msec
  2 20.3.4.3 [MPLS: Labels 16/30 Exp 0] 221 msec 114 msec 110 msec
  3 20.1.3.1 [MPLS: Label 30 Exp 0] 103 msec 113 msec 86 msec
  4 20.100.0.19 [MPLS: Label 24009 Exp 0] 78 msec 72 msec 62 msec
  5 20.6.19.6 [MPLS: Labels 18/24 Exp 0] 85 msec 71 msec 70 msec
  6 30.5.12.5 [MPLS: Label 24 Exp 0] 77 msec 88 msec 47 msec
  7 30.5.12.12 99 msec *  72 msec

As you can see, in Option A, Hop 4 would have been native IP since it was VRF to VRF. Now that we are allocating a label to that peering we have an LSP that is end to end. We actually have 3 different LSPs, R4-R3-R1; R1-XR1; XR1-R6-XR2.

The configs:
Option B PE Configs for R1 and XR1

MPLS L3VPN Inter AS Option A or Option 1- Back to Back VRF

MPLS L3VPN Inter AS Option A/1 Back to Back VRF is probably the easiest transition to Inter AS VPN for those that are familiar with regular Intra AS L3 VPN. The PE to PE connections are configured almost exactly the same way that you would configured a PE for a PE to CE Attachment Circuit. The only difference being that instead of connecting to a Customer, you are connecting to another provider.

I used INEs SPv3 Inter AS Topology for this, the reason is that the topology makes sense from a learning perspective. I'll walk you through the several individual steps that are needed to get this very involved configuration operational. Currently, I have this configuration operational and I have to say, after getting hung up on several steps, there is learning curve to this design.

I also am using VIRL 1.0.26 for this setup. I connect R1 through R12 on G2 to an IOSv L2 managed switch, configuring all the VLANs and setting all ports as trunks.

So, with any MPLS L3 design there are several steps, I'll cover the Intra AS ones first and then add the Inter AS steps so you can see the difference.

Intra AS design:
1. IGP, you need to have IGP operational and the PE devices need to be advertising their /32 loopbacks into IGP. A good test is to trace from PE1 to PE2 sourcing off of PE1s loopback. If you can reach it your in good shape.
2. LDP, you need LDP up and operational to build the LSP or label switch paths between the PEs. The /32 loopback is what will become the next hop for the LSP once LDP is enabled.
3. BGP VPNv4, this is how updates from PE1 will be advertised to PE2. LDP only builds the LSPs between PEs, VPNv4 is what actually advertised NLRI between the PEs.
4. VRFs, this is used to separate Customer 1 from Customer 2. Ideally 1 VRF per customer as a VRF is new routing table with a RD (Route Distinguisher - to make the route globally unique) and RT (Route Target - to determine which PEs can send and receive VPN traffic).
5. PE-CE Routing, this can be as basic as a static route to as complicated and OSPF. BGP is what I have seen as the most commonly deployed, ideally you would use BGP as the PE-CE routing protocol and not an IGP as IGP required redistribution mutually with BGP to exchange routing info. BGP doesn't need to redistribute the traffic.

Inter AS design:
1. IGP
2. LDP
3. BGP VPNv4
4. VRFs
5. PE-CE Routing
6. PE-PE Back to Back VRF exchange - AKA ASBR to ASBR VRF Exchange. Basically what's happening is you configure the PE to PE connection exactly like you would a PE to CE connection. The only difference is that instead of a CE router, your connecting to another PE. You peer with the other provider on a per VRF basis, if you have 200 customers, you have 200 separate VRF peerings with that provider for customers paying for Inter AS connectivity.

The design I have working right now is IGP as the PE to CE and PE to PE VRF exchange. Since all IGPs are IPv4 VRF aware capable, it makes it easy to set this up. I used BGP VPNv4 between the PEs and used a VPNv4 route reflector to reflect routes. Making it ideal to scale with. A common misunderstanding is that in order to have L3 VPN you need IPv4 unicast iBGP working, not the case, VPNv4 alone gets the job done.

I commonly group the configurations together to make deployments that much simpler. The first is IGP and LDP together. MPLS is configured under the IGP routing process and is applied to any interface IGP is enabled on. On IOS XR, you can enable mpls ldp auto config under the routing process, but you still have to enable the MPLS LDP globally.

IOS
R1 - sh run | sec isis
router isis 1
 net 49.0000.0000.0000.0001.00
 metric-style wide
 mpls ldp autoconfig

IOS XR
router ospf 1
 mpls ldp auto-config
 area 0
  interface Loopback0
  !
  interface GigabitEthernet0/0/0/0.619
!
mpls ldp

Once that is up and running, we need to verify basic LDP forwarding:

IOS
R1#sh mpls forwarding-table | ex No Label
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop  
Label      Label      or Tunnel Id     Switched      interface            
16         Pop Label  3.3.3.3/32       0             Gi2.13     20.1.3.3  
18         Pop Label  20.2.3.0/24      0             Gi2.13     20.1.3.3  
19         Pop Label  20.3.4.0/24      0             Gi2.13     20.1.3.3  
20         17         2.2.2.2/32       0             Gi2.13     20.1.3.3  
21         18         4.4.4.4/32       0             Gi2.13     20.1.3.3  

IOS XR
RP/0/0/CPU0:XR1#sh mpls forwarding | ex Unlabelled
Fri Jun  3 08:28:20.135 UTC
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes    
Label  Label       or ID              Interface                    Switched  
------ ----------- ------------------ ------------ --------------- ------------
24000  Pop         6.6.6.6/32         Gi0/0/0/0.619 20.6.19.6       70842    
24001  Pop         20.5.6.0/24        Gi0/0/0/0.619 20.6.19.6       0        
24002  Pop         20.6.20.0/24       Gi0/0/0/0.619 20.6.19.6       0        
24003  18          5.5.5.5/32         Gi0/0/0/0.619 20.6.19.6       2906      
24004  19          20.20.20.20/32     Gi0/0/0/0.619 20.6.19.6       33916    
24005  Aggregate   A: Per-VRF Aggr[V] A                            0        
24008  Aggregate   C: Per-VRF Aggr[V] C                            0        
24009  Aggregate   B: Per-VRF Aggr[V] B                            0        

Now it's time to setup the VRFs and apply them to the interfaces, I used the same VRF naming convention on all PEs, :

IOS
R1
ip vrf A
 rd 100:1
 route-target export 100:1
 route-target import 100:1
!
ip vrf B
 rd 100:2
 route-target export 100:2
 route-target import 100:2
!
ip vrf C
 rd 100:3
 route-target export 100:3
 route-target import 100:3

IOS XR
RP/0/0/CPU0:XR1#sh run vrf
Fri Jun  3 08:31:29.982 UTC
vrf A
 address-family ipv4 unicast
  import route-target
   100:1
  !
  export route-target
   100:1
  !
 !
!
vrf B
 address-family ipv4 unicast
  import route-target
   100:2
  !
  export route-target
   100:2
  !
 !
!
vrf C
 address-family ipv4 unicast
  import route-target
   100:3
  !
  export route-target
   100:3

BGP VPNv4 is up next, I'll show you 2 PEs, 1 is a regular PE and the other is a PE and a RR:
IOS
R1
router bgp 1
 !
 template peer-session VPNv4
  remote-as 1
  update-source Loopback0
 exit-peer-session
 !
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 2.2.2.2 inherit peer-session VPNv4
 !
 address-family vpnv4
  neighbor 2.2.2.2 activate
  neighbor 2.2.2.2 send-community extended
 exit-address-family

R2 - PE and RR
router bgp 1
 template peer-policy VPNv4
  route-reflector-client
 exit-peer-policy
 !
 template peer-session VPNv4
  remote-as 1
  update-source Loopback0
 exit-peer-session
 !
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 1.1.1.1 inherit peer-session VPNv4
 neighbor 4.4.4.4 inherit peer-session VPNv4
 !
 address-family ipv4
 exit-address-family
 !
 address-family vpnv4
  neighbor 1.1.1.1 activate
  neighbor 1.1.1.1 send-community extended
  neighbor 1.1.1.1 inherit peer-policy VPNv4
  neighbor 4.4.4.4 activate
  neighbor 4.4.4.4 send-community extended
  neighbor 4.4.4.4 inherit peer-policy VPNv4
 exit-address-family


R2#sh bgp vpnv4 unicast all summary
BGP router identifier 2.2.2.2, local AS number 1
<brevity>
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
1.1.1.1         4            1     411     416       22    0    0 06:05:42        9
4.4.4.4         4            1     405     419       22    0    0 06:04:54        4

As you can see, R1 (1.1.1.1) and R4 (4.4.4.4) are advertising routes. This is because I already had PE-CE routing configured.

IOS XR
XR1
router bgp 2
 address-family vpnv4 unicast
 !
 neighbor 20.20.20.20
  remote-as 2
  update-source Loopback0
  address-family vpnv4 unicast

XR2 - PE and RR
RP/0/0/CPU0:XR2#sh run router bgp
Fri Jun  3 08:38:20.473 UTC
router bgp 2
 address-family vpnv4 unicast
 !
 neighbor 5.5.5.5
  remote-as 2
  update-source Loopback0
  address-family vpnv4 unicast
   route-reflector-client
  !
 !
 neighbor 19.19.19.19
  remote-as 2
  update-source Loopback0
  address-family vpnv4 unicast
   route-reflector-client


RP/0/0/CPU0:XR2#sh bgp vpnv4 unicast summary
Fri Jun  3 08:38:57.521 UTC
BGP router identifier 20.20.20.20, local AS number 2
BGP scan interval 60 secs

Process       RcvTblVer   bRIB/RIB   LabelVer  ImportVer  SendTblVer  StandbyVer
Speaker              28         28         28         28          28           0

Neighbor        Spk    AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down  St/PfxRcd
5.5.5.5           0     2     325     299       28    0    0 04:47:56          4
19.19.19.19       0     2     283     290       28    0    0 04:34:06          9


Now to configure PE-CE routing:

IOS
R2
router bgp 1
address-family ipv4 vrf B
  neighbor 40.2.7.7 remote-as 7
  neighbor 40.2.7.7 activate


R2#sh bgp vpnv4 unicast all summary
BGP router identifier 2.2.2.2, local AS number 1

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
40.2.7.7        4            7     662     664       22    0    0 09:57:55        2

IOS XR
XR2
RP/0/0/CPU0:XR2#sh run router ospf
Fri Jun  3 08:41:30.290 UTC
router ospf 1
  !
 !
 vrf A
  redistribute bgp 2
  area 0
   interface GigabitEthernet0/0/0/0.820

RP/0/0/CPU0:XR2#sh route vrf A
Fri Jun  3 08:41:56.389 UTC

Gateway of last resort is not set

O    8.8.8.8/32 [110/2] via 10.8.20.8, 04:53:57, GigabitEthernet0/0/0/0.820


Now that all of that is put together, it's time to see the PE to PE exchange. I'll copy in all the configurations at the bottom so you'll have them

IOS
R1
R1#sh run | sec bgp
router bgp 1
 address-family ipv4 vrf A
  redistribute ospf 2
 exit-address-family
 !
 address-family ipv4 vrf B
  redistribute eigrp 1
 exit-address-family
 !
 address-family ipv4 vrf C
  redistribute rip metric 2
 exit-address-family

R1# sh run | sec eigrp
router eigrp 1
 !
 address-family ipv4 vrf B autonomous-system 1
  redistribute bgp 1 metric 1000000 1 255 1 1500
  network 200.200.200.0
  eigrp router-id 1.1.1.1
 exit-address-family
  redistribute eigrp 1

R1# sh run | sec ospf
router ospf 2 vrf A
 router-id 11.11.11.11
 capability vrf-lite
 redistribute bgp 1 subnets
 network 100.100.100.0 0.0.0.255 area 0
  redistribute ospf 2

One key thing about OSPF in a PE-CE or PE-PE configuration is that the Downward bit or the DN is set on the CE by the PE to prevent the CE from advertising the route back to the same or a different PE device. You an override this loop prevention technique with capability vrf-lite in IOS. This allows the LSA to get installed in the RIB

R1# sh run | sec rip
router rip
 !
 address-family ipv4 vrf C
  redistribute bgp 1 metric 1
  network 33.0.0.0
  no auto-summary
  version 2
 exit-address-family
  redistribute rip metric 2


IOS XR
XR1
RP/0/0/CPU0:XR1#sh run router bgp
Fri Jun  3 08:44:27.079 UTC
router bgp 2
  !
 !
 vrf A
  rd 100:1
  address-family ipv4 unicast
   redistribute ospf 1
  !
 !
 vrf B
  rd 100:2
  address-family ipv4 unicast
   redistribute eigrp 1
  !
 !
 vrf C
  rd 100:3
  address-family ipv4 unicast
   redistribute rip metric 2

RP/0/0/CPU0:XR1#sh run router ospf
Fri Jun  3 08:44:53.677 UTC
  !
 !
 vrf A
  disable-dn-bit-check
  redistribute bgp 2
  area 0
   interface GigabitEthernet0/0/0/0.100

One key thing about OSPF in a PE-CE or PE-PE configuration is that the Downward bit or the DN is set on the CE by the PE to prevent the CE from advertising the route back to the same or a different PE device. You an override this loop prevention technique with disable dn bit check in IOS XR. This allows the LSA to get installed in the RIB


RP/0/0/CPU0:XR1#sh run router rip
Fri Jun  3 08:48:30.002 UTC
router rip
 vrf C
  interface GigabitEthernet0/0/0/0.300
  !
  redistribute bgp 2


RP/0/0/CPU0:XR1#sh run router eigrp
Fri Jun  3 08:48:44.631 UTC
router eigrp 1
 vrf B
  address-family ipv4
   autonomous-system 1
   redistribute bgp 2
   interface GigabitEthernet0/0/0/0.200

So now to check the Each customer starting with A then B then C

R10
R10#sh ip route ospf

      8.0.0.0/32 is subnetted, 1 subnets
O E2     8.8.8.8 [110/3] via 10.4.10.4, 04:04:26, GigabitEthernet2.410
      10.0.0.0/8 is variably subnetted, 7 subnets, 3 masks
O E2     10.8.20.0/24 [110/2] via 10.4.10.4, 04:04:26, GigabitEthernet2.410
      100.0.0.0/24 is subnetted, 1 subnets
O E2     100.100.100.0 [110/1] via 10.4.10.4, 04:21:52, GigabitEthernet2.410

R8
R8#sh ip route ospf
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is 10.255.0.1 to network 0.0.0.0

      10.0.0.0/8 is variably subnetted, 7 subnets, 3 masks
O E2     10.4.10.0/24 [110/1] via 10.8.20.20, 03:55:07, GigabitEthernet2.820
O E2     10.10.10.10/32 [110/1] via 10.8.20.20, 03:55:07, GigabitEthernet2.820
      100.0.0.0/24 is subnetted, 1 subnets
O IA     100.100.100.0 [110/2] via 10.8.20.20, 03:55:07, GigabitEthernet2.820

Now lets trace R8 to R10 sourcing from R8's looback.

R8#traceroute 10.10.10.10 source 8.8.8.8 num
Type escape sequence to abort.
Tracing the route to 10.10.10.10
VRF info: (vrf in name/id, vrf out name/id)
  1 10.8.20.20 15 msec 5 msec 6 msec
  2 20.6.20.6 [MPLS: Labels 17/24007 Exp 0] 48 msec 36 msec 95 msec
  3 20.6.19.19 [MPLS: Label 24007 Exp 0] 59 msec 37 msec 48 msec
  4 100.100.100.1 39 msec 42 msec 37 msec
  5 20.1.3.3 [MPLS: Labels 18/23 Exp 0] 94 msec 65 msec 69 msec
  6 10.4.10.4 [MPLS: Label 23 Exp 0] 63 msec 72 msec 58 msec
  7 10.4.10.10 70 msec *  83 msec


VRF B
R7#sh ip route bgp

      11.0.0.0/32 is subnetted, 1 subnets
B        11.11.11.11 [20/0] via 40.2.7.2, 03:02:56
      40.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
B        40.5.11.0/24 [20/0] via 40.2.7.2, 03:02:56
B     200.200.200.0/24 [20/0] via 40.2.7.2, 03:03:44

R11#sh ip route eigrp

      7.0.0.0/32 is subnetted, 1 subnets
D EX     7.7.7.7 [170/3328] via 40.5.11.5, 03:03:13, GigabitEthernet2.511
      40.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
D EX     40.2.7.0/24 [170/3328] via 40.5.11.5, 03:03:13, GigabitEthernet2.511
D     200.200.200.0/24 [90/3072] via 40.5.11.5, 03:03:33, GigabitEthernet2.511

R11#traceroute 7.7.7.7 source 11.11.11.11 numeric
Type escape sequence to abort.
Tracing the route to 7.7.7.7
VRF info: (vrf in name/id, vrf out name/id)
  1 40.5.11.5 19 msec 10 msec 10 msec
  2 20.5.6.6 [MPLS: Labels 17/24010 Exp 0] 41 msec 48 msec 33 msec
  3 20.6.19.19 [MPLS: Label 24010 Exp 0] 69 msec 42 msec 68 msec
  4 200.200.200.1 41 msec 36 msec 44 msec
  5 20.1.3.3 [MPLS: Labels 17/22 Exp 0] 119 msec 57 msec 61 msec
  6 40.2.7.2 [MPLS: Label 22 Exp 0] 65 msec 102 msec 58 msec
  7 40.2.7.7 73 msec *  89 msec


VRF C
R9#sh ip route rip

      12.0.0.0/32 is subnetted, 1 subnets
R        12.12.12.12 [120/1] via 30.4.9.4, 00:00:23, GigabitEthernet2.49
      30.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
R        30.5.12.0/24 [120/1] via 30.4.9.4, 00:00:23, GigabitEthernet2.49
      33.0.0.0/24 is subnetted, 1 subnets
R        33.33.33.0 [120/1] via 30.4.9.4, 00:00:23, GigabitEthernet2.49


R12#sh ip route rip

      9.0.0.0/32 is subnetted, 1 subnets
R        9.9.9.9 [120/1] via 30.5.12.5, 00:00:29, GigabitEthernet2.512
      30.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
R        30.4.9.0/24 [120/1] via 30.5.12.5, 00:00:29, GigabitEthernet2.512
      33.0.0.0/24 is subnetted, 1 subnets
R        33.33.33.0 [120/1] via 30.5.12.5, 00:00:29, GigabitEthernet2.512

R12#traceroute 9.9.9.9 source 12.12.12.12 num
Type escape sequence to abort.
Tracing the route to 9.9.9.9
VRF info: (vrf in name/id, vrf out name/id)
  1 30.5.12.5 19 msec 13 msec 10 msec
  2 20.5.6.6 [MPLS: Labels 17/24012 Exp 0] 45 msec 53 msec 44 msec
  3 20.6.19.19 [MPLS: Label 24012 Exp 0] 51 msec 48 msec 39 msec
  4 33.33.33.1 47 msec 52 msec 46 msec
  5 20.1.3.3 [MPLS: Labels 18/24 Exp 0] 97 msec 89 msec 71 msec
  6 30.4.9.4 [MPLS: Label 24 Exp 0] 62 msec 63 msec 66 msec
  7 30.4.9.9 90 msec *  85 msec

One thing you see on every trace output is the following:
Hop1  - PE-CE connection - routed via IP
Hop2 - MPLS forwarded from PE to PE
Hop3 - PHP process kicks in removing outer transport label - 1 label stack
Hop4 - PE to PE connection - routed via IP
Hop5 - MPLS forwarded from PE to PE
Hop6 - PHP process kicks in removing outer transport label - 1 label stack

Hop7 - PE-CE connection - routed via IP

The LSPs are not maintained end to end as you can see. But reachability is there and we can get from Site to site easily.

Overall a pretty fun lab to go through. The main thing to keep in mind is this design is probably the easiest transition but it doesn't scale well. You'll see what I mean as we hit Option B, C and A/B then Carrier Supporting Carrier. 

Config Link:

Link to Option A configurations