Rob Riker/ Simplified Networking: CCIE SPv4 - MPLS L3 VPN - BGP PE-CE Routing

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]