Rob Riker/ Simplified Networking: PE-CE

Showing posts with label PE-CE. Show all posts

Saturday, January 14, 2017

CCIE SPv4 - MPLS L3 VPN - IS-IS PE-CE Routing

Software versions:
IOS XE 15.5
IOS XR 5.3

The topology for this demo:

In this post we will hit the last dynamic protocol, IS-IS, which has the least support as well. VRF Aware IS-IS isn't supported in IOS XR, so we'll be demoing this setup on just a few routers. Overall, very simple to get working. Like RIPv2, just the configs and a quick verification are all that is needed.

router isis 115

vrf IS-IS

net 49.0000.0000.0000.0001.00

is-type level-2-only

metric-style wide

redistribute bgp 50693

address-family ipv6

multi-topology

redistribute bgp 50693

exit-address-family

interface GigabitEthernet1.1115

encapsulation dot1Q 1115

vrf forwarding IS-IS

ip address 131.0.0.1 255.255.255.0

ip router isis 115

ipv6 address 2131:CC1E::1/64

ipv6 router isis 115

router bgp 50693

address-family ipv4 vrf IS-IS

redistribute isis 115 level-2

exit-address-family

address-family ipv6 vrf IS-IS

redistribute isis 115 level-2

exit-address-family

R13

router isis 115

vrf IS-IS

net 49.0000.0000.0000.0013.00

is-type level-2-only

metric-style wide

address-family ipv6

multi-topology

exit-address-family

interface GigabitEthernet1.1115

encapsulation dot1Q 1115

vrf forwarding IS-IS

ip address 131.0.0.13 255.255.255.0

ip router isis 115

ipv6 address 2131:CC1E::13/64

ipv6 router isis 115

So now that we have the configuration in place, we can take a look at the verification. We'll start R13, then R1 and go from there.

R13#sh ip route vrf IS-IS isis | b Gateway

Gateway of last resort is not set

172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks

i L2 172.16.110.0/24

[115/10] via 131.0.0.1, 00:21:34, GigabitEthernet1.1115

i L2 172.16.114.0/24

[115/10] via 131.0.0.1, 00:21:34, GigabitEthernet1.1115

i L2 172.16.119.0/24

[115/10] via 131.0.0.1, 00:21:34, GigabitEthernet1.1115

R13#sh ipv6 route vrf IS-IS isis | b App

ld - LISP dyn-eid, a - Application

I2 FC00::8/128 [115/10]

via FE80::20C:29FF:FE11:973F, GigabitEthernet1.1115

I2 FC00:110::8/128 [115/10]

via FE80::20C:29FF:FE11:973F, GigabitEthernet1.1115

I2 FC00:114::8/128 [115/10]

via FE80::20C:29FF:FE11:973F, GigabitEthernet1.1115

I2 FC00:119::8/128 [115/10]

via FE80::20C:29FF:FE11:973F, GigabitEthernet1.1115

As you can see, I have routes from both AFIs in the applicable RIBs. Let's do some verification on the PE side.

R1#sh bgp vpnv4 unicast vrf IS-IS 172.16.110.0/24

BGP routing table entry for 115:50693:172.16.110.0/24, version 698

Paths: (2 available, best #2, table IS-IS)

Not advertised to any peer

Refresh Epoch 1

Local

192.168.1.6 (metric 5) (via default) from 192.168.1.14 (192.168.1.14)

Origin incomplete, metric 20, localpref 100, valid, internal

Extended Community: RT:115:50693

Originator: 192.168.1.6, Cluster list: 192.168.1.14

mpls labels in/out nolabel/47

rx pathid: 0, tx pathid: 0

Refresh Epoch 2

Local

192.168.1.6 (metric 5) (via default) from 192.168.1.2 (192.168.1.2)

Origin incomplete, metric 20, localpref 100, valid, internal, best

Extended Community: RT:115:50693

Originator: 192.168.1.6, Cluster list: 192.168.1.2

mpls labels in/out nolabel/47

rx pathid: 0, tx pathid: 0x0

R1#sh bgp vpnv6 unicast vrf IS-IS FC00::8/128

BGP routing table entry for [115:50693]FC00::8/128, version 1755

Paths: (2 available, best #1, table IS-IS)

Not advertised to any peer

Refresh Epoch 1

Local

::FFFF:192.168.1.3 (metric 4) (via default) from 192.168.1.2 (192.168.1.2)

Origin incomplete, metric 20, localpref 100, valid, internal, best

Extended Community: RT:115:50693

Originator: 192.168.1.3, Cluster list: 192.168.1.2

mpls labels in/out nolabel/35

rx pathid: 0, tx pathid: 0x0

Refresh Epoch 1

Local

::FFFF:192.168.1.3 (metric 4) (via default) from 192.168.1.14 (192.168.1.14)

Origin incomplete, metric 20, localpref 100, valid, internal

Extended Community: RT:115:50693

Originator: 192.168.1.3, Cluster list: 192.168.1.14

mpls labels in/out nolabel/35

rx pathid: 0, tx pathid: 0

As you can see, the metric (20) is copied from IS-IS.

Let's verify connectivity.

R8#traceroute vrf IS-IS 172.16.115.13 source 172.16.114.8

Type escape sequence to abort.

Tracing the route to 172.16.115.13

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

1 83.0.0.3 3 msec 1 msec 1 msec

2 10.14.3.14 [MPLS: Labels 24007/32 Exp 0] 8 msec 6 msec 5 msec

3 10.11.14.11 [MPLS: Labels 24000/32 Exp 0] 33 msec 32 msec 76 msec

4 131.0.0.1 [MPLS: Label 32 Exp 0] 8 msec 8 msec 6 msec

5 131.0.0.13 7 msec * 11 msec

R8#traceroute vrf IS-IS ipv6

Target IPv6 address: FC00:115::13

Source address: FC00:114::8

Insert source routing header? [no]:

Numeric display? [no]:

Timeout in seconds [3]:

Probe count [3]:

Minimum Time to Live [1]:

Maximum Time to Live [30]:

Priority [0]:

Port Number [0]:

Type escape sequence to abort.

Tracing the route to FC00:115::13

1 2038:CC1E::3 3 msec 1 msec 0 msec

2 ::FFFF:10.3.4.4 [MPLS: Labels 25/42 Exp 0] 49 msec 5 msec 19 msec

3 2016:15:4::15 [MPLS: Labels 24031/42 Exp 0] 36 msec 35 msec 34 msec

4 2131:CC1E::1 [MPLS: Label 42 Exp 0] 17 msec 15 msec 25 msec

5 2131:CC1E::13 23 msec 14 msec 15 msec

As you can see we have reachability.

Thanks for stopping by!

Rob Riker, CCIE #50693

CCIE SPv4 - MPLS L3 VPN - EIGRP PE-CE Routing

Software versions:
IOS XE 15.5
IOS XR 5.3

The topology for this demo:

In this post we will be taking a look at EIGRP as PE-CE Routing protocol. Like BGP and OSPF, both IPv4 and IPv6 are supported. This allows us to leverage EIGRP to do the same, there are a few unique details we will have to cover as we have with BGP and OSPF. EIGRP being a distance vector protocol, like RIPv2, normally would have to identify a method when redistributing routes into EIGRP, to calculate DUAL. In our case here, that isn't necessary, this is due to the "cost community" that is leveraged to copy the EIGRP metrics into BGP extended communities, carried in VPNv4/VPNv6 updates to the remote PE and then copied back into EIGRP. Very similar to how the IGP metric is copied to the BGP MED.

We will be leveraging "named mode" EIGRP in our scenario, I rarely ever use the "classic mode" EIGRP anymore. If you ask why, centralized configuration, I can do everything I need to under the Named mode process. At the same time, this is the only place where EIGRPv6 in a VRF is supported. I plan on showing you IOS and IOS XR syntax for the scenario, so we'll start with R14 and XR3, then take a look at R3 and R8.

R14

router eigrp CCIE

address-family ipv4 unicast vrf EIGRP autonomous-system 90

topology base

exit-af-topology

network 113.0.0.0 0.0.0.255

exit-address-family

address-family ipv6 unicast vrf EIGRP autonomous-system 90

topology base

exit-af-topology

exit-address-family

XR3

router eigrp CCIE

vrf EIGRP

address-family ipv4

autonomous-system 90

redistribute bgp 50693

interface GigabitEthernet0/0/0/0.1090

address-family ipv6

autonomous-system 90

redistribute bgp 50693

interface GigabitEthernet0/0/0/0.1090

router bgp 50693

vrf EIGRP

rd 90:50693

address-family ipv4 unicast

redistribute eigrp 90

address-family ipv6 unicast

redistribute eigrp 90

router eigrp CCIE

address-family ipv4 unicast vrf EIGRP autonomous-system 90

topology base

redistribute bgp 50693

exit-af-topology

network 83.0.0.0 0.0.0.255

network 131.0.0.0 0.0.0.255

exit-address-family

address-family ipv6 unicast vrf EIGRP autonomous-system 90

topology base

redistribute bgp 50693

exit-af-topology

exit-address-family

router bgp 50693

address-family ipv4 vrf EIGRP

redistribute eigrp 90

exit-address-family

address-family ipv6 vrf EIGRP

redistribute eigrp 90

exit-address-family

router eigrp CCIE

address-family ipv4 unicast vrf EIGRP autonomous-system 90

topology base

exit-af-topology

network 83.0.0.0 0.0.0.255

network 90.90.90.0 0.0.0.255

exit-address-family

address-family ipv6 unicast vrf EIGRP autonomous-system 90

topology base

redistribute connected route-map CONNECTED

exit-af-topology

exit-address-family

As you can see the configuration is relatively straightforward and easy to implement.

The part we need to focus on now is the PE EIGRP breakdown for the BGP VPNv4/VPNv6 info to see how that is all put together.

R3#sh bgp vpnv4 unicast vrf EIGRP 113.0.0.0/24

BGP routing table entry for 90:50693:113.0.0.0/24, version 381

Paths: (2 available, best #1, table EIGRP)

Not advertised to any peer

Refresh Epoch 2

Local

192.168.1.13 (metric 3) (via default) from 192.168.1.2 (192.168.1.2)

Origin incomplete, metric 0, localpref 100, valid, internal, best

Extended Community: RT:90:50693 Cost:pre-bestpath:128:10240

0x8800:32768:0 0x8801:90:256 0x8802:65280:2560 0x8803:1:1500

0x8806:0:3232235789

Originator: 192.168.1.13, Cluster list: 192.168.1.2

mpls labels in/out nolabel/24017

rx pathid: 0, tx pathid: 0x0

Refresh Epoch 1

Local

192.168.1.13 (metric 3) (via default) from 192.168.1.14 (192.168.1.14)

Origin incomplete, metric 0, localpref 100, valid, internal

Extended Community: RT:90:50693 Cost:pre-bestpath:128:10240

0x8800:32768:0 0x8801:90:256 0x8802:65280:2560 0x8803:1:1500

0x8806:0:3232235789

Originator: 192.168.1.13, Cluster list: 192.168.1.14

mpls labels in/out nolabel/24017

rx pathid: 0, tx pathid: 0

The majority of the above output has been covered in previous post, R2 is the best path since it has a lower Router ID. I want to focus on the Extended community information and break that down.

0x8800 is route information used for the Route Flag and tag

0x8801 is route metric and AS used for the ASN and dely

0x8802 is route metric and is used for Reliability, next-hop and bandwidth

0x8803 is route metric and is used for Reserve, load and MTU

0x8804 is external route metric and is used for Remote AS and Remote ID

0x8805 is external route metric and is used for Remote protocol and Remote metric

0x8806 is Originating Router ID

I'll add a loopback on R14 and give an IPv4 and IPv6 address, matching in it a route-map and redistributing it into IPv4/IPv6 EIGRP.

router eigrp CCIE

address-family ipv4 unicast vrf EIGRP autonomous-system 90

topology base

redistribute connected route-map LO1000

exit-af-topology

exit-address-family

address-family ipv6 unicast vrf EIGRP autonomous-system 90

topology base

redistribute connected route-map LO1000

exit-af-topology

exit-address-family

route-map LO1000 permit 10

match interface Loopback1000

R3#sh bgp vpnv4 unicast vrf EIGRP 192.168.100.0

BGP routing table entry for 90:50693:192.168.100.0/24, version 388

Paths: (2 available, best #1, table EIGRP)

Not advertised to any peer

Refresh Epoch 2

Local

192.168.1.13 (metric 3) (via default) from 192.168.1.2 (192.168.1.2)

Origin incomplete, metric 10880, localpref 100, valid, internal, best

Extended Community: RT:90:50693 Cost:pre-bestpath:129:10880 0x8800:0:0

0x8801:90:288 0x8802:65281:2560 0x8803:1:1500 0x8804:0:1895825422

0x8805:11:0

Originator: 192.168.1.13, Cluster list: 192.168.1.2

mpls labels in/out nolabel/24020

rx pathid: 0, tx pathid: 0x0

Refresh Epoch 1

Local

192.168.1.13 (metric 3) (via default) from 192.168.1.14 (192.168.1.14)

Origin incomplete, metric 10880, localpref 100, valid, internal

Extended Community: RT:90:50693 Cost:pre-bestpath:129:10880 0x8800:0:0

0x8801:90:288 0x8802:65281:2560 0x8803:1:1500 0x8804:0:1895825422

0x8805:11:0

Originator: 192.168.1.13, Cluster list: 192.168.1.14

mpls labels in/out nolabel/24020

rx pathid: 0, tx pathid: 0

As you can see, the outputs changed a bit. We no longer see the 8806 as it is replaced with an 8805 and 8804. These metrics are received as BGP extended communities, when BGP is redistributed into EIGRP, those extended communities are copied as well, EIGRP understands what is being handed off and is able to use those values to populate metrics and run DUAL.

R8#sh ip route vrf EIGRP eigrp | b Gateway

Gateway of last resort is not set

59.0.0.0/24 is subnetted, 1 subnets

D 59.0.0.0 [90/15360] via 83.0.0.3, 00:29:57, GigabitEthernet1.1090

106.0.0.0/24 is subnetted, 1 subnets

D 106.0.0.0 [90/15360] via 83.0.0.3, 00:28:04, GigabitEthernet1.1090

113.0.0.0/24 is subnetted, 1 subnets

D 113.0.0.0 [90/15360] via 83.0.0.3, 00:37:09, GigabitEthernet1.1090

131.0.0.0/24 is subnetted, 1 subnets

D 131.0.0.0 [90/15360] via 83.0.0.3, 5d05h, GigabitEthernet1.1090

D EX 192.168.100.0/24

[170/16000] via 83.0.0.3, 00:08:37, GigabitEthernet1.1090

R8#sh ipv6 route vrf EIGRP eigrp | b App

ld - LISP dyn-eid, a - Application

D 2113:CC1E::/64 [90/15360]

via FE80::20C:29FF:FE06:2644, GigabitEthernet1.1090

D 2913:CC1E::/64 [90/16000]

via FE80::20C:29FF:FE06:2644, GigabitEthernet1.1090

D FC00::9/128 [90/16000]

via FE80::20C:29FF:FE06:2644, GigabitEthernet1.1090

D FC00::90/128 [90/16000]

via FE80::20C:29FF:FE06:2644, GigabitEthernet1.1090

D FC00:100::/64 [90/16000]

via FE80::20C:29FF:FE06:2644, GigabitEthernet1.1090

As you can see, all is well.

Thanks for stopping by!

Rob Riker, CCIE #50693

Wednesday, January 11, 2017

CCIE SPv4 - MPLS L3 VPN - OSPFv2 and OSPFv3 PE-CE Routing

Software versions:
IOS XE 15.5
IOS XR 5.3

The topology for this demo:

In this post we will implement OSPFv2 and OSPFv3 as the PE to CE routing protocol. There are several caveats when rolling out OSPF in this type of deployment, not advisable in a production environment. OSPF has some unique challenges when deployed the way we will be rolling it out. We will leveraging the "Multi VRF CE" design where our connection to the provider is in a VRF. We'll focus on setting up the PEs and the CEs first.

router ospf 110 vrf OSPF

redistribute bgp 50693 subnets

network 131.0.0.0 0.0.0.255 area 0

router ospfv3 110

address-family ipv6 unicast vrf OSPF

redistribute bgp 50693

interface GigabitEthernet1.1110

encapsulation dot1Q 1110

vrf forwarding OSPF

ip address 131.0.0.1 255.255.255.0

ipv6 address 2131:CC1E::1/64

ospfv3 110 ipv6 area 0

router bgp 50693

address-family ipv4 vrf OSPF

redistribute ospf 110

exit-address-family

address-family ipv6 vrf OSPF

redistribute ospf 110 include-connected

exit-address-family

R13

router ospfv3 110

address-family ipv6 unicast vrf OSPF

exit-address-family

router ospf 110 vrf OSPF

network 131.0.0.0 0.0.0.255 area 0

interface GigabitEthernet1.1110

encapsulation dot1Q 1110

vrf forwarding OSPF

ip address 131.0.0.13 255.255.255.0

ipv6 address 2131:CC1E::13/64

ospfv3 110 ipv6 area 0

XR3

router ospf 110

vrf OSPF

redistribute bgp 50693

area 0

interface GigabitEthernet0/0/0/0.1110

router ospfv3 110

redistribute bgp 50693

area 0

vrf OSPF

redistribute bgp 50693

area 0

interface GigabitEthernet0/0/0/0.1110

router bgp 50693

vrf OSPF

rd 110:50693

address-family ipv4 unicast

redistribute ospf 110

address-family ipv6 unicast

redistribute ospfv3 110

R14

router ospfv3 110

address-family ipv6 unicast

exit-address-family

address-family ipv6 unicast vrf OSPF

exit-address-family

router ospf 110 vrf OSPF

network 113.0.0.0 0.0.0.255 area 0

interface GigabitEthernet1.1110

encapsulation dot1Q 1311

vrf forwarding OSPF

ip address 113.0.0.14 255.255.255.0

ipv6 address 2113:CC1E::14/64

ospfv3 110 ipv6 area 0

Now that we have our configuration in place, we need to verify the configuration.

R13#sh ip ospf 110 neighbor

Neighbor ID Pri State Dead Time Address Interface

131.0.0.1 1 FULL/DR 00:00:34 131.0.0.1 GigabitEthernet1.1110

R13#sh ospfv3 vrf OSPF neighbor

OSPFv3 110 address-family ipv6 vrf OSPF (router-id 110.110.110.13)

Neighbor ID Pri State Dead Time Interface ID Interface

131.0.0.1 1 FULL/DR 00:00:39 20 GigabitEthernet1.1110

As you can see our peerings to the PE are up and operational. Let's take a look at the VRF aware RIB to see what we have reachability to.

R13#sh ip route vrf OSPF | b Gateway

Gateway of last resort is not set

110.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

C 110.110.110.0/24 is directly connected, Loopback110

L 110.110.110.13/32 is directly connected, Loopback110

131.0.0.0/16 is variably subnetted, 2 subnets, 2 masks

C 131.0.0.0/24 is directly connected, GigabitEthernet1.1110

L 131.0.0.13/32 is directly connected, GigabitEthernet1.1110

We haven't learned any routes, there is a reason why this is happening. I've added an interface into the global RIB on R13 to show a scenario where the CE interface is not in a VRF.

interface GigabitEthernet1.10

encapsulation dot1Q 11

ip address 11.0.0.13 255.255.255.0

ipv6 address 2001:11::13/64

ospfv3 110 ipv6 area 0

router ospf 1

network 11.0.0.0 0.0.0.255 area 0

R13#sh ip route ospf | b Gateway

Gateway of last resort is not set

83.0.0.0/24 is subnetted, 1 subnets

O IA 83.0.0.0 [110/2] via 11.0.0.1, 00:02:56, GigabitEthernet1.10

110.0.0.0/32 is subnetted, 3 subnets

O IA 110.110.110.8 [110/3] via 11.0.0.1, 00:02:56, GigabitEthernet1.10

O 110.110.110.13 [110/3] via 11.0.0.1, 00:02:56, GigabitEthernet1.10

O E2 110.110.110.14 [110/2] via 11.0.0.1, 00:02:56, GigabitEthernet1.10

113.0.0.0/24 is subnetted, 1 subnets

O E2 113.0.0.0 [110/1] via 11.0.0.1, 00:02:56, GigabitEthernet1.10

As you can see we've learned routes from our other CE routers and have installed them in the RIB.

Now to identify the issue with the CE VRF configuration.

R13#sh ip ospf database summary adv-router 131.0.0.1

OSPF Router with ID (131.0.0.13) (Process ID 110)

Summary Net Link States (Area 0)

LS age: 749

Options: (No TOS-capability, DC, Downward)

LS Type: Summary Links(Network)

Link State ID: 83.0.0.0 (summary Network Number)

Advertising Router: 131.0.0.1

LS Seq Number: 80000091

Checksum: 0xA49

Length: 28

Network Mask: /24

MTID: 0 Metric: 1

LS age: 749

Options: (No TOS-capability, DC, Downward)

LS Type: Summary Links(Network)

Link State ID: 110.110.110.8 (summary Network Number)

Advertising Router: 131.0.0.1

LS Seq Number: 8000008D

Checksum: 0x7FD6

Length: 28

Network Mask: /32

MTID: 0 Metric: 2

The key piece that needs to be zeroed in on here is the "downward" bit that is set from R1 (131.0.0.1) who is the advertising router and is the PE. The PE device will set the downward bit in an effort to prevent the route from being propagated inside the customer network and then readvertised back to the provider. The only drawback with this is the route is in the LSDB but because the DN bit is set, SPF can't be ran on the LSA and won't be installed in the RIB. There is a simple fix for this and is applicable for OSPFv2 and OSPFv3, configured on the CE. Capability vrf-lite is used to disable the "DN" bit check and let's SPF run on those LSAs and installs the routes in the RIB. This bit is set on Type 3, 5 and 7 LSAs when BGP routes are redistributed into OSPF.

R13#debug ip opsf spf

R13#debug ip ospf rib local

R13#debug ip ospf rib global

R14#sh ip ospf 110 | in VPN

Connected to MPLS VPN Superbackbone, VRF OSPF

This means that R14 is connected to the MPLS backbone via OSPF, where the MPLS backbone is acting has a superior Area 0, the CEs take on an ABR style role where they are the connection into the MPLS backbone. You will see on R13 for the non VRF OSPF connection that there is no connection like that. According to the Cisco Docs, the MPLS Super backbone is only applicable in Multi VRF CE.

R13#sh ip ospf 1 | in VPN

#no output.

These debugs will let you see the SPF run get kicked off and the RIB get the best routes installed. I'll now configure "capability vrf-lite" on R13 for both OSPFv2 and OSPFv3.

router ospfv3 110

address-family ipv6 unicast vrf OSPF

capability vrf-lite

exit-address-family

router ospf 110 vrf OSPF

capability vrf-lite

R13#sh ip ospf database summary adv-router 131.0.0.1

OSPF Router with ID (131.0.0.13) (Process ID 110)

Summary Net Link States (Area 0)

LS age: 1437

Options: (No TOS-capability, DC, Downward)

LS Type: Summary Links(Network)

Link State ID: 83.0.0.0 (summary Network Number)

Advertising Router: 131.0.0.1

LS Seq Number: 80000091

Checksum: 0xA49

Length: 28

Network Mask: /24

MTID: 0 Metric: 1

LS age: 1437

Options: (No TOS-capability, DC, Downward)

LS Type: Summary Links(Network)

Link State ID: 110.110.110.8 (summary Network Number)

Advertising Router: 131.0.0.1

LS Seq Number: 8000008D

Checksum: 0x7FD6

Length: 28

Network Mask: /32

MTID: 0 Metric: 2

As you can see the downward bit is showing up, it doesn't actually "go away", the check for it is simply disabled. Allowing SPF to be run and those routes to get installed in the RIB.

R13# sh ip route vrf OSPF ospf | b Gateway

Gateway of last resort is not set

11.0.0.0/24 is subnetted, 1 subnets

O 11.0.0.0 [110/2] via 131.0.0.1, 00:07:03, GigabitEthernet1.1110

83.0.0.0/24 is subnetted, 1 subnets

O IA 83.0.0.0 [110/2] via 131.0.0.1, 00:07:03, GigabitEthernet1.1110

110.0.0.0/8 is variably subnetted, 4 subnets, 2 masks

O IA 110.110.110.8/32

[110/3] via 131.0.0.1, 00:07:03, GigabitEthernet1.1110

O E2 110.110.110.14/32

[110/2] via 131.0.0.1, 00:07:03, GigabitEthernet1.1110

113.0.0.0/24 is subnetted, 1 subnets

O E2 113.0.0.0 [110/1] via 131.0.0.1, 00:07:03, GigabitEthernet1.1110

Now we have routes installed in the RIB. I'll now go ahead and do some ping/traces from R13. You'll notice that some of the OSPF routes are O IA and some are O E2. Our configuration on all the PEs requires us to redistribute OSPF and BGP bidirectionally. The PEs that are IOS XE, R3, R6 R1. The CEs attached will see anything advertised to them from the PEs as Inter Area or O IA. IOS XR advertises routes as O E2.

Let's go ahead and verify the reachability.

R13#ping vrf OSPF 110.110.110.14

Type escape sequence to abort.

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

!!!!!

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

R8#traceroute vrf OSPF 110.110.110.14 source 110.110.110.8 num

Type escape sequence to abort.

Tracing the route to 110.110.110.14

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

1 83.0.0.3 3 msec 1 msec 1 msec

2 10.3.4.4 [MPLS: Labels 20/24012 Exp 0] 12 msec 5 msec 8 msec

3 10.4.5.5 [MPLS: Labels 20/24012 Exp 0] 14 msec 20 msec 29 msec

4 10.5.6.6 [MPLS: Labels 20/24012 Exp 0] 24 msec 13 msec 19 msec

5 10.2.6.2 [MPLS: Labels 17/24012 Exp 0] 21 msec 31 msec 32 msec

6 10.13.2.13 [MPLS: Label 24012 Exp 0] 23 msec 9 msec 8 msec

7 113.0.0.14 7 msec * 8 msec

As you can see, both ping and traces are functioning.

Thanks for stopping by!

Rob Riker, CCIE #50693

Monday, January 9, 2017

CCIE SPv4 - MPLS L3 VPN - BGP PE-CE Routing - Multiple Customer sites w/ same ASN

Software versions:
IOS XE 15.5
IOS XR 5.3

The topology for this demo:

In this blog post we will be taking a look at a common issue I personally have ran into several times working on both the SP side and the Enterprise/Consulting side. A customer has several sites that connect to the MPLS network via BGP, whether unknowingly or otherwise misunderstood, configure all or most of their BGP attached sites with the same BGP ASN, whether it is a public or private ASN block is irrelevant. If 2 or more sites have the same ASN configured and receive eBGP updates in from the provider, if the AS_PATH list contains the locally configured ASN, BGP will deny the route due to their own AS in the AS_PATH list.

BGP(0): 37.0.0.3 rcv UPDATE about 112.0.0.0/24 -- DENIED due to: AS-PATH contains our own AS;

BGP(1): 2037:CC1E::3 rcv UPDATE about FC00:7::/64 -- DENIED due to: AS-PATH contains our own AS;

This is easily fixed by configuring each site with its own unique BGP ASN. However, there are 2 different solutions to fix this issue, one is PE specific and the other is CE specific.

NOTE - IOS XR by default will inspect the AS_PATH list of outgoing routes and will not advertise a route to a peer if it knows it will violate the loop prevention techique. IOS does not do that, it just sends the update out, I want to say blindly since that is what it's doing, just sending the update. This feature can be disable on IOS XR, which we'll take a look at later.

The CE side configuration uses the "allowas-in" command to allow the locally configured AS to receive BGP updates that contain the locally configured AS in the AS_PATH list. For a small setup in a private WAN design, I see validity, but this can be detrimental if used on the Internet BGP configuration.

The PE side configuration uses the "as-override" command to remove the customer advertised ASN from the AS_PATH list and replace it with the providers ASN in the AS_PATH list. When the provider overrides the information, the remote CE site is none the wiser and accepts the routes/updates because it sees the providers ASN in the AS_PATH list.

NOTE - If IOS XR is the PE device, this command is required on the PE-CE BGP peering configuration. If IOS is the PE device, the command is also configurable, but the customer could use the "allowas-in" option.

In our design, R3 peers with R7 and XR1 peers with R12. R7 and R12 are in BGP ASN 127 and both peer with AS 50693 for IPv4 and IPv6. R7 will use "allowas-in" and XR1 will use "as-override". I will later on disable the outbound AS_PATH check on IOS XR and R12 will receive the later denied update. You technically don't need to configure "allowas-in" if you have already configured "as-override", I have it configured for testing purposes.

R12#sh bgp vpnv4 unicast vrf BGP | b Network

Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 20:50693 (default for vrf BGP)

*> 10.10.10.0/24 112.0.0.11 0 50693 10 ?

*> 13.13.13.0/24 112.0.0.11 0 50693 134 ?

*> 37.0.0.0/24 112.0.0.11 0 50693 50693 i

*> 59.0.0.0/24 112.0.0.11 0 50693 9 i

*> 83.0.0.0/24 112.0.0.11 0 50693 8 i

*> 106.0.0.0/24 112.0.0.11 0 50693 10 i

*> 112.0.0.0/24 0.0.0.0 0 32768 i

*> 113.0.0.0/24 112.0.0.11 0 50693 143 i

*> 131.0.0.0/24 112.0.0.11 0 50693 134 i

*> 192.168.7.0 112.0.0.11 0 50693 50693 i

*> 192.168.12.0 0.0.0.0 0 32768 i

You'll notice that the routes 37.0.0.0/24 and 192.168.7.0/24 both have AS_PATH lists of 50693 50693. This is an indication of "as-override" in action, let's take a closer look at the 192.168.7.0/24 since it is an internal route on R7.

R12#sh bgp vpnv4 unicast vrf BGP 192.168.7.0

BGP routing table entry for 20:50693:192.168.7.0/24, version 12

Paths: (1 available, best #1, table BGP)

Not advertised to any peer

Refresh Epoch 1

50693 50693

112.0.0.11 (via vrf BGP) from 112.0.0.11 (192.168.1.11)

Origin IGP, localpref 100, valid, external, best

Extended Community: RT:20:50693

rx pathid: 0, tx pathid: 0x0

As you can see, the AS the route originated in was replaced with the SPs ASN.

RP/0/0/CPU0:XR1#sh bgp vpnv4 unicast vrf BGP 192.168.7.0/24

Mon Jan 9 22:15:31.605 UTC

BGP routing table entry for 192.168.7.0/24, Route Distinguisher: 20:50693

Versions:

Process bRIB/RIB SendTblVer

Speaker 243 243

Last Modified: Jan 9 21:59:32.688 for 00:15:58

Paths: (2 available, best #1)

Not advertised to any peer

Path #1: Received by speaker 0

Not advertised to any peer

127

192.168.1.3 (metric 3) from 192.168.1.2 (192.168.1.3)

Received Label 47

Origin IGP, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported

Received Path ID 0, Local Path ID 1, version 243

Extended community: RT:20:50693

Originator: 192.168.1.3, Cluster list: 192.168.1.2

Source VRF: BGP, Source Route Distinguisher: 20:50693

Path #2: Received by speaker 0

Not advertised to any peer

127

192.168.1.3 (metric 3) from 192.168.1.14 (192.168.1.3)

Received Label 47

Origin IGP, metric 0, localpref 100, valid, internal, import-candidate, imported

Received Path ID 0, Local Path ID 0, version 0

Extended community: RT:20:50693

Originator: 192.168.1.3, Cluster list: 192.168.1.14

Source VRF: BGP, Source Route Distinguisher: 20:50693

XR1's BGP VPNv4 table shows that the route learned in from R7 indeed had the original ASN of 127. The exact same thing is true for IPv6.

R12#sh bgp vpnv6 unicast vrf BGP | b Network

Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 20:50693 (default for vrf BGP)

*> 2038:CC1E::/64 2112:CC1E::11 0 50693 8 i

*> 2059:CC1E::/64 2112:CC1E::11 0 50693 9 i

*> 2106:CC1E::/64 2112:CC1E::11 0 50693 10 i

*> 2113:CC1E::/64 2112:CC1E::11 0 50693 143 i

*> 2131:CC1E::/64 2112:CC1E::11 0 50693 134 i

*> FC00::10/128 2112:CC1E::11 0 50693 10 ?

*> FC00::13/128 2112:CC1E::11 0 50693 134 ?

*> FC00:7::/64 2112:CC1E::11 0 50693 50693 i

*> FC00:12::/64 :: 0 32768 i

R12#sh bgp vpnv6 unicast vrf BGP FC00:7::/64

BGP routing table entry for [20:50693]FC00:7::/64, version 17

Paths: (1 available, best #1, table BGP)

Not advertised to any peer

Refresh Epoch 1

50693 50693

2112:CC1E::11 (FE80::20C:29FF:FED2:5AF8) (via vrf BGP) from 2112:CC1E::11 (192.168.1.11)

Origin IGP, localpref 100, valid, external, best

Extended Community: RT:20:50693

rx pathid: 0, tx pathid: 0x0

The IPv6 BGP table on R12 has the exact same AS PATH list as the IPv4 table does.

R12#sh ip route vrf BGP bgp | b Gateway

Gateway of last resort is not set

10.0.0.0/24 is subnetted, 1 subnets

B 10.10.10.0 [20/0] via 112.0.0.11, 21:23:46

13.0.0.0/24 is subnetted, 1 subnets

B 13.13.13.0 [20/0] via 112.0.0.11, 21:23:46

37.0.0.0/24 is subnetted, 1 subnets

B 37.0.0.0 [20/0] via 112.0.0.11, 21:12:53

59.0.0.0/24 is subnetted, 1 subnets

B 59.0.0.0 [20/0] via 112.0.0.11, 21:23:46

83.0.0.0/24 is subnetted, 1 subnets

B 83.0.0.0 [20/0] via 112.0.0.11, 21:23:46

106.0.0.0/24 is subnetted, 1 subnets

B 106.0.0.0 [20/0] via 112.0.0.11, 21:23:46

113.0.0.0/24 is subnetted, 1 subnets

B 113.0.0.0 [20/0] via 112.0.0.11, 21:23:46

131.0.0.0/24 is subnetted, 1 subnets

B 131.0.0.0 [20/0] via 112.0.0.11, 21:23:46

R12#sh ipv6 route vrf BGP bgp | b App

ld - LISP dyn-eid, a - Application

B 2038:CC1E::/64 [20/0]