Rob Riker/ Simplified Networking

Monday, November 7, 2016

MPLS Inter AS L3 VPN Carrier Supporting Carrier or CSC

In this post we will take a look at CSC or Carrier Supporting Carrier. This is a really involved configuration and will take sometime to break down all the individual steps in order to get our Customer sites to be able to talk to each other.

First, lets cover what CSC is. The really basic part is we're connecting regional Tier 2 POPs together via a Tier 1 Backbone provider. That's pretty much it, a bit oversimplified but if you have never seen, heard of or worked with CSC, it's one of the more advanced and configuration intensive IAS capabilities out there.

So what is really going, I know what your thinking, jee.... connecting Tier 2 POPs together via a Tier 1 backbone, jee.... way to make it sound not complicated. That's kind of the point. There are 3 individual MPLS L3 VPN providers in our setup here, 2 of which are in the same BGP AS (Tier 2 POPs) and the 3rd is the Tier 1 Backbone. The Backbone provider treats both Tier 2 POPs as CE sites, the Tier 2 POPs treat their customer as regular CEs. Pretty much a hierarchical L3 VPN at the end of the day. Sort of like the MPLS Superbackbone with OSPF.

Out Topology:

The ASN 50693 is our T1 backbone, R1, R2, R3, XR1, XR2 and XR3.

The ASN 1000 is 2 Regions, R4, R5 and XR4; R13, R14 and R16.

R7 and R15 are our customer sites that need to reach each other.....

First and foremost, IGP/LDP, VPNv4 PE-PE iBGP peerings, and VRFs need to be configured in each site. In my first rollout, I leveraged R1, R5 and R16 as RR for BGP. I kept this design until the very end, we'll discuss this later.

Once you have Intra AS L3 VPN setup and ready to go, the Inter AS setup comes. We'll start with the Backbone configuration. ****For whatever reason, haven't figured out why, IOS XRv 5.3.0 would not pass VPNv4 traffic down to the CSC_CEs.**** I ended up routing around XRv and using all IOS XE (CSR1000v) to get this up and running. I'll add in the applicable configuration for XRv.

On the connection from XR2 to R13 I placed g0/0/0/0.1312 into VRF CSC.

XR2, XR3

vrf CSC

address-family ipv4 unicast

import route-target

3:3

export route-target

3:3

XR2

int g0/0/0/0.1312

vrf CSC

ipv4 address 13.12.0.12 255.255.255.0

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

XR3

interface GigabitEthernet0/0/0/0.134

vrf CSC

ipv4 address 13.4.0.13/24

ipv6 address 2001:13:4::13/64

Now on to the BGP configuration

XR2

vrf CSC

rd 3:3

address-family ipv4 unicast

neighbor 13.12.0.13

remote-as 1000

address-family ipv4 labeled-unicast

route-policy PASS in

route-policy PASS out

as-override

The RD is placed under the VRF configuration under BGP

Labeled-unicast is used to advertise BGP labels

AS-override is to remove the AS received from the Customer Carrier and replace it with the Core Carrier AS

XR3

vrf CSC

rd 3:3

address-family ipv4 unicast

neighbor 13.4.0.4

remote-as 1000

address-family ipv4 labeled-unicast

route-policy PASS in

route-policy PASS out

as-override

Now we need to make sure that any routes that are learned in the IPv4 Unicast AFI get labels associated to them

XR2 and XR3

router bgp 50693

address-family ipv4 unicast

allocate-label all

Allocate label all is used to allocate labels to global BGP routes

Now we have one more issue, the prefix that XR2 and XR3 peer with is /24 to the CSC_CE. No labels will be allocated for a /24, we need to make this a /32.

XR2

show mpls forwarding-table

120012 Aggregate 13.12.0.0/24[V] CSC 0

XR2

router static

vrf CSC

address-family ipv4 unicast

13.12.0.13/32 GigabitEthernet0/0/0/0.1312

XR2

show mpls forwarding-table

120003 Pop 13.12.0.13/32[V] Gi0/0/0/0.1312 13.12.0.13 6480

You can see how now there is a "Pop" now. That's how we'll get label allocation for this connected prefix that is a /24.

XR3

router static

vrf CSC

address-family ipv4 unicast

13.4.0.4/32 GigabitEthernet0/0/0/0.134

Like I mentioned, XRv wasn't advertising routes to the Customer Carrier, so I modified the configuration and removed XR from the demo. The above configuration is still applicable, use it if you can.

IOS Based setup from here out.

I created the VRF CSC on R3 and R1, then under BGP I peered with R4 to R3 and R1 to R13.

int g1.34

vrf for CSC

en do 34

ip add 3.4.0.3 255.255.255.0

int g1.34

en do 34

ip add 3.4.0.4 255.255.255.0

int g1.13

en do 13

vrf for CSC

ip add 1.13.0.1 255.255.255.0

R13

int g1.13

en do 13

ip add 1.13.0.13 255.255.255.0

Now we can configure the BGP IPv4 Unicast peerings and advertise BGP Labels. IGP+LDP is applicable here but not demo'd. It would have been easier but who likes easy?

router bgp 50693

no bgp default ipv4-unicast

address-family ipv4 vrf CSC

neighbor 1.13.0.13 remote-as 1000

neighbor 1.13.0.13 activate

neighbor 1.13.0.13 as-override

neighbor 1.13.0.13 send-label

Send-label is the equivalent to labeled-unicast in XR, it advertises BGP labels. Both R1 and R13 need this configured. AS Override is configured since both Tier 2 POPs are in the same ASN.

R13

router bgp 1000

no bgp default ipv4

neighbor 1.13.0.1 remote-as 50693

address-family ipv4

redistribute ospf 1

neighbor 1.13.0.1 activate

neighbor 1.13.0.1 allowas-in

neighbor 1.13.0.1 send-label

router bgp 50693

bgp log-neighbor-changes

no bgp default ipv4-unicast

address-family ipv4 vrf CSC

neighbor 3.4.0.4 remote-as 1000

neighbor 3.4.0.4 activate

neighbor 3.4.0.4 as-override

neighbor 3.4.0.4 send-label

router bgp 1000

bgp log-neighbor-changes

no bgp default ipv4-unicast

address-family ipv4

neighbor 3.4.0.3 activate

neighbor 3.4.0.3 allowas-in

neighbor 3.4.0.3 send-label

Now routes are propagating via BGP.

show ip bgp sum

3.4.0.3 4 50693 302 288 77 0 0 04:08:16 8

show ip bgp

*> 14.14.14.14/32 3.4.0.3 0 50693 50693 ?

I omitted everything but R14's loopback, it's all we care about.

R13

show ip bgp sum

1.13.0.1 4 50693 262 265 59 0 0 03:54:21 8

show ip bgp

*> 114.114.114.114/32 1.13.0.1 0 50693 50693 ?

Now we need to be able to ping/trace R14 to XR4 loopbacks.

R14#ping 114.114.114.114 source lo0

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 2/6/20 ms

R14#traceroute 114.114.114.114 source lo0 num

VRF info: (vrf in name/id, vrf out name/id)

1 13.14.0.13 [MPLS: Labels 29/44 Exp 0] 5 msec 7 msec 5 msec

2 1.13.0.1 [MPLS: Label 44 Exp 0] 30 msec 31 msec 152 msec

3 10.1.2.2 [MPLS: Labels 24/30 Exp 0] 31 msec 32 msec 31 msec

4 3.4.0.3 [AS 50693] [MPLS: Label 30 Exp 0] 32 msec 30 msec 29 msec

5 3.4.0.4 [AS 50693] [MPLS: Label 18 Exp 0] 21 msec 20 msec 20 msec

6 10.4.14.14 [AS 50693] 21 msec * 3 msec

Now we need to peer R14 to XR4 via VPNv4.

R14

router bgp 1000

bgp log-neighbor-changes

no bgp default ipv4-unicast

neighbor 114.114.114.114 remote-as 1000

neighbor 114.114.114.114 update-source Loopback0

address-family vpnv4

neighbor 114.114.114.114 activate

neighbor 114.114.114.114 send-community extended

XR4

router bgp 1000

neighbor 14.14.14.14

remote-as 1000

update-source Loopback0

address-family vpnv4 unicast

R13 and R4 have to redistribute BGP into OSPF

router ospf 1

redistribute bgp 1000 subnets

RP/0/0/CPU0:XR4#sh bgp vpnv4 unicast summary

14.14.14.14 0 1000 264 239 5 0 0 03:56:05 1

R14 and XR4 are now peered via VPNv4 iBGP. You can also see that "1" route is being propagated.

RP/0/0/CPU0:XR4#sh bgp vpnv4 unicast

*> 14.7.0.0/24 14.7.0.7 0 0 7 i

*>i14.15.0.0/24 14.14.14.14 0 100 0 15 i

XR4 sees the route of 14.15.0.0/24 that R14 advertised it.

R15

show ip route

B 14.7.0.0/24 [20/0] via 14.15.0.14, 00:14:47

R15 sees the R7 route.

Now lets see if we can ping from R15 to R7

R15#ping 14.7.0.7

.....

Success rate is 0 percent (0/5)

WHAT!!!! Ok, calm down, easily fixed. But first explained. XR4 is learning the 14.7.0.0/24 prefix from R7. XR4 generates a VPNv4 label for it. That info is propagated via VPNv4 to R14. The problem is that XR4 to R4 is IGP+LDP. Therefore, when XR4 goes to forward the traffic, R4 won't know what do with it. The problem is that R13 is receving BGP labels from R1, there has to be a way to bridge the LSP from XR4 to R14, but we can't since R13 terminates the LSP via BGP and R13 to R14 is LDP. So.... we have to extend BGP to R14.

R13

router bgp 1000

bgp log-neighbor-changes

no bgp default ipv4-unicast

neighbor 14.14.14.14 remote-as 1000

neighbor 14.14.14.14 update-source Loopback0

address-family ipv4

neighbor 14.14.14.14 activate

neighbor 14.14.14.14 send-label

R14

router bgp 1000

bgp log-neighbor-changes

no bgp default ipv4-unicast

neighbor 13.13.13.13 remote-as 1000

neighbor 13.13.13.13 update-source Loopback0

address-family ipv4

neighbor 13.13.13.13 activate

neighbor 13.13.13.13 send-label

Now R13 can advertise BGP labels to R14

R15

R15#ping 14.7.0.7

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 3/7/18 ms

R15#traceroute 14.7.0.7 num

VRF info: (vrf in name/id, vrf out name/id)

1 14.15.0.14 71 msec 3 msec 1 msec

2 13.14.0.13 [MPLS: Labels 29/44/24006 Exp 0] 29 msec 16 msec 4 msec

3 1.13.0.1 [MPLS: Labels 44/24006 Exp 0] 12 msec 32 msec 51 msec

4 10.1.13.13 [MPLS: Labels 130002/30/24006 Exp 0] 122 msec 81 msec 23 msec

5 10.13.3.3 [MPLS: Labels 30/24006 Exp 0] 32 msec 52 msec 33 msec

6 3.4.0.4 [MPLS: Labels 18/24006 Exp 0] 20 msec 26 msec 21 msec

7 10.4.14.14 20 msec 77 msec 15 msec

8 14.7.0.7 [AS 7] 35 msec * 6 msec

VIOLA! Ok, it's a bit dirty but it's working. You can see there are 3 label stacks on hops 2 and 4

24006 is the VPNv4 label XR4 allocated the 14.7.0.0/24 prefix. This never changes. The 29/44 in our first hop is 44 of the LDP label and 29 of the BGP label.

That is pretty much it. OK, I know what your thinking. Jee Rob, long enough post? This is the last long one for a while. Not much left to cover for CCNP stuff. I plan on doing a ton of posts for CCIE prep.

Thanks for stopping by!

Rob Riker, CCIE #50693

Friday, November 4, 2016

MPLS L3 VPN Inter AS Option C Multihop EBGP VPNv4 Peering

In our last post we took a look at Option B where we had R1 and XR1 form a VPNv4 BGP peering and exchange labels, the LSP is then end to end and not broken up at the ASBRs.

In this post we will take a look at Option C or Multihop EBGP VPNv4 Peerings between the different ASs Route Reflectors. Not to be mistaken, we are not form RR peerings between the RRs rather using the RR as a way to propagate routing info from the remote ASs into the local AS. The configuration is pretty straightforward for the most part, it's more a matter of understanding the individual functions and the role each serves that will help bring this config altogether.

The PE-PE connectivity is the first piece, which is going to be between BGP ASN 1000 and BGP ASN 50693, this will be done in the global table with some minor modifications made later. I'm using a different topology than the last couple Inter AS rollouts but the process is the same:

R3 and XR4 need to form EBGP IPv4 Unicast peerings with each other. The send-label config is used to send BGP routes plus BGP labels to the remote PE, XR4 in this case. The labeled-unicast on XR4 does the same thing as the send-label, adds a BGP label.

R3:

router bgp 50693

neighbor 143.0.0.14 remote-as 1000

address-family ipv4

neighbor 143.0.0.14 activate

neighbor 143.0.0.14 send-label

XR4:

router bgp 1000

neighbor 143.0.0.3

remote-as 50693

address-family ipv4 labeled-unicast

route-policy PASS in

route-policy PASS out

As soon as this peering is up and running, we move to the next step of advertising the route reflector loopbacks of BGP ASN 1000 and 50693 into IPv4 BGP in their respective ASN.

XR4:

RP/0/0/CPU0:XR4#sh run router bgp

router bgp 1000

address-family ipv4 unicast

network 4.4.4.4/32

network 114.114.114.114/32

R4:

router bgp 1000

address-family ipv4

network 4.4.4.4 mask 255.255.255.255

router bgp 50693

address-family ipv4

network 1.1.1.1 mask 255.255.255.255

Now, we should see on R4 and XR4, the 1.1.1.1/32 in BGP

XR4:

show route

B 1.1.1.1/32 [20/30] via 143.0.0.3, 20:35:22

B 1.1.1.1 [20/20] via 13.4.0.13, 00:10:41

One of the issues I ran into with having 2 BGP external connections is that the AD of eBGP is 20 and OSPF is 110. So I ended up having to shutdown the connection between XR3 and R4.

What needs to happen next is the IGP needs to redistribute the BGP Loopback /32 address into IGP. We'll use some filtering to make sure only the loopbacks are learned.

XR4:

prefix-set BGP

1.1.1.1/32

end-set

route-policy BGP_TO_IGP

if destination in BGP then

pass

endif

end-policy

router ospf 1

redistribute bgp 1000 route-policy BGP_TO_IGP

R3:

router isis 1

redistribute bgp 50693 route-map BGP_TO_IGP

ip prefix-list BGP seq 5 permit 4.4.4.4/32

ip prefix-list BGP seq 10 permit 114.114.114.114/32

route-map BGP_TO_IGP permit 10

match ip address prefix-list BGP

Now to verify that R1, R4 and XR4 are learning the remote RR loopback(s).

R1:

sh ip route

i L2 4.4.4.4 [115/20] via 10.1.13.13, 20:41:53, GigabitEthernet1.113

[115/20] via 10.1.2.2, 20:41:53, GigabitEthernet1.12

i L2 114.114.114.114

[115/20] via 10.1.13.13, 20:41:53, GigabitEthernet1.113

[115/20] via 10.1.2.2, 20:41:53, GigabitEthernet1.12

XR4 is a bit unique, but it still works ;)

show route

B 1.1.1.1/32 [20/30] via 143.0.0.3, 20:42:58

R4:

show ip route

O E2 1.1.1.1 [110/1] via 10.4.14.14, 20:43:16, GigabitEthernet1.414

Now, the next step here is to verify that R1, R4 and XR4 can ping/trace to and from each other's loopback addresses.

R1:

R1#ping 4.4.4.4 source lo0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 4.4.4.4, 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 = 3/8/24 ms

R1#ping 114.114.114.114 source lo0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 114.114.114.114, 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 = 2/5/18 ms

R4#ping 1.1.1.1 source lo0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:

Packet sent with a source address of 4.4.4.4

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 2/6/20 ms

XR4:

RP/0/0/CPU0:XR4#ping 1.1.1.1 source 114.114.114.114

Fri Nov 4 21:33:53.914 UTC

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/9 ms

Alright! Now we can form the eBGP VPNv4 Multihop peerings!

R1:

router bgp 50693

neighbor 4.4.4.4 remote-as 1000

neighbor 4.4.4.4 ebgp-multihop 255

neighbor 4.4.4.4 update-source Loopback0

neighbor 114.114.114.114 remote-as 1000

neighbor 114.114.114.114 ebgp-multihop 255

neighbor 114.114.114.114 update-source Loopback0

address-family vpnv4

neighbor 4.4.4.4 activate

neighbor 4.4.4.4 send-community extended

neighbor 114.114.114.114 activate

neighbor 114.114.114.114 send-community extended

exit-address-family

R4:
router bgp 1000
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 1.1.1.1 remote-as 50693
neighbor 1.1.1.1 ebgp-multihop 255
neighbor 1.1.1.1 update-source Loopback0
address-family vpnv4
neighbor 1.1.1.1 activate
neighbor 1.1.1.1 send-community extended
exit-address-family

XR4:

router bgp 1000

neighbor 1.1.1.1

remote-as 50693

ebgp-multihop 255

update-source Loopback0

address-family vpnv4 unicast

route-policy PASS in

route-policy PASS out

next-hop-unchanged

Let's verify that the BGP peerings are formed and exchanging routes.

R1:

sh bgp vpnv4 unicast all summary

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

4.4.4.4 4 1000 1407 1419 515 0 0 20:52:56 4

114.114.114.114 4 1000 1259 1394 515 0 0 20:48:00 4

R4:

sh bgp vpnv4 unicast all summary

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

1.1.1.1 4 50693 1420 1408 519 0 0 20:53:32 24

XR4:

sh bgp vpnv4 unicast summary

Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd

1.1.1.1 0 50693 1421 1275 1223 0 0 20:49:06 24

Now that we have routes being learned and propagated we can now begin the next step, which is setting up XR4 for the XR specific configuration.

R3 on the peering to XR4 needs to have the "send-label" configuration under the IPv4 unicast AFI.

R3:

router bgp 50693

address-family ipv4

neighbor 143.0.0.14 send-label

XR4:

router static

address-family ipv4 unicast

143.0.0.3/32 GigabitEthernet0/0/0/0.143

Needed for a /32 host route to the next hop towards R3, hence the 143.0.0.3/32 configuration.

XR4:

router bgp 1000

address-family ipv4 unicast

allocate-label all

To trigger BGP to allocate labels for all global routes

We should be good to go at this point, routes should be propagated and LSPs should be built. Lets see what R7 and R5 see as route counts via BGP

R7:

show ip bgp summary

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

14.7.0.14 4 1000 3012 3285 273 0 0 2d01h 18

R5:

show ip bgp summary

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

54.0.0.4 4 1000 1641 1624 99 0 0 1d00h 6

Great! Now lets trace from R9 to R7 and see the output:

R9#traceroute 7.7.7.7 source lo0 num

Type escape sequence to abort.

Tracing the route to 7.7.7.7

VRF info: (vrf in name/id, vrf out name/id)

1 12.9.0.12 2 msec 1 msec 0 msec

2 10.11.12.11 [MPLS: Labels 111017/24 Exp 0] 9 msec 8 msec 7 msec

3 10.1.11.1 [MPLS: Labels 55/24 Exp 0] 28 msec 31 msec 32 msec

4 10.1.13.13 [MPLS: Labels 130027/24 Exp 0] 32 msec 31 msec 32 msec

5 10.13.3.3 [MPLS: Labels 56/24 Exp 0] 71 msec 77 msec 21 msec

6 143.0.0.14 [MPLS: Labels 24000/24 Exp 0] 22 msec 21 msec 22 msec

7 10.4.14.4 [MPLS: Label 24 Exp 0] 22 msec 21 msec 21 msec

8 10.4.14.14 [MPLS: Label 24025 Exp 0] 22 msec 21 msec 21 msec

9 14.7.0.7 [AS 7] 21 msec * 74 msec

As you can see the LSP is maintained, it changes when the Inter AS link comes into play on hop 8, the VPNv4 label changes from 24 to 24025. But that is an expected outcome. What we do see but is a sub optimal path is that R4, or hop 7 is in the data plane. The reason behind that is the next hops via bgp vpnv4 unicast is R1, R4 and XR4. Since the VPNv4 next hop is the remote AS RR, that is where the LSP will terminate for 7.7.7.7, at least in this particular case.

We can change this by issuing the next-hop-unchanged under the VPNv4 unicast AFI.

router bgp 50693

address-family vpnv4

neighbor 4.4.4.4 next-hop-unchanged

router bgp 1000

address-family vpnv4

neighbor 1.1.1.1 next-hop-unchanged

XR4

router bgp 1000

neighbor 4.4.4.4

address-family vpnv4 unicast

next-hop-unchanged

Now we can retrace from R9 to R7 and see the difference

R9#traceroute 7.7.7.7 source lo0 num

Type escape sequence to abort.

Tracing the route to 7.7.7.7

VRF info: (vrf in name/id, vrf out name/id)

1 12.9.0.12 1 msec 1 msec 1 msec

2 10.11.12.11 [MPLS: Labels 111018/24025 Exp 0] 9 msec 8 msec 9 msec

3 10.1.11.1 [MPLS: Labels 54/24025 Exp 0] 29 msec 32 msec 37 msec

4 10.1.2.2 [MPLS: Labels 17/24025 Exp 0] 22 msec 31 msec 31 msec

5 10.2.3.3 [MPLS: Labels 57/24025 Exp 0] 32 msec 39 msec 23 msec

6 14.7.0.7 [AS 7] 21 msec * 8 msec

Notice now that the VPNv4 label of 24025 is now maintained end to end. This is the expected output since we aren't having to leave one LSP and join another one, we are no longer terminating on R4 and then using LDP between R4 and XR4 to label switch the VPNv4 label to XR4.

As you can see, this is a rather involved configuration. I didn't bother showing the base setup of IGP/LDP, VPNv4 peerings, VRF configuration or the PE-CE routing. It is assumed you already know how to do that.

Thanks for stopping by!

Rob Riker, CCIE #50693

Tuesday, June 14, 2016

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(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(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(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(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

Friday, June 3, 2016

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