In this post, we will look into setting up MPLS VPN and use BGP as our routing protocol between the PE router and the CE router. We won’t go deeper into the MPLS VPN backbone configuration but just the PE-CE segment. At this point, if you are unfamiliar with MPLS VPN, please read this post here.

To be consistent, we will use the same MPLS diagram we’ve been using…

MPLS is fully configured except the links between the PEs and the CEs. We will utilize the already configured BGP AS 65111 on the PE routers and BGP AS 1 on RouteLeak offices. Let’s hop on the consoles and configure our PE routers…

Here, we have to establish a neighbor relationship between both routers under the appropriate vrf context. Also, note that we have to activate the TCP session with the keyword “activate”. Let’s do the same on the other side…

Good ! Let’s now hop on the CE routers and configure BGP AS 1 and advertise our connected prefixes…

Good ! We have our neighbor command pointing to the peer here. We also have our network command which advertises our prefixes. Remember the rule to advertise prefixes using the network command ? We have to have a component route in the routing table in order to successfully advertise a prefix to a peer. If you are unfamiliar with the BGP rules, please read this post here. Okay, let’s do the same on the other side…

Good ! At this point, we should see the customer routes in VRF RouteLeak routing table on the PE routers on both sides. Let’s confirm…

Very good ! Let’s check the remote side…

Fantastic ! Let’s hop on the CE router and check the routing table now…

Here we clearly have a problem ! We are not getting the prefixes advertised by the remote CE router locally. Let’s check to see why. Let’s run a debug for BGP updates…

Ah ! We can see the notifications above indicating that the route has been rejected because the AS-PATH contains the local AS number.

The reason why we are seeing this is because BGP has a Split-Horizon feature which is a routing loop avoidance mechanism that discards route advertisements propagated by a CE device to the same CE device. In our case here, RouteLeak is using BGP AS 1 at the HeadQuarter as well as the Remote Office. When the route advertisement comes in on one side, the CE router see its own AS embedded in the BGP updates then discards the packet.

We have 2 options to solve this problem. One of them is to configure BGP AS-Override at the Service provider side. By using the keyword “AS-Override”, we are basically telling the Service Provider to strip AS 1 before sending the updates to the RouteLeak CE router. Let’s do that now…

Good ! Let’s do the same at remote side…

All right ! Let’s check our BGP routing table at the CE router again…

Ah ! This is what we needed to see. We are now seeing the prefixes advertised by the remote side. Let’s ping the loopback address from the HeadQuarter…

Good ! This is working. let’s now remove the “AS-Override” command and I’ll show you another way of fixing this…

Let’s do the same on R5…

Let’s check the CE side again and make sure the prefixes are gone…

All right, they are gone. Our 2nd option is to send the updates as is by using the keyword “allowas-in” on the CE routers. by doing so, we are instructing the router to accept the routes even if it sees its own AS in the updates. Let’s do that…

All right ! Let’s do the same at the remote side…

Note that the “1” here does not refer to the BGP AS number but the “number of occurrences of AS number”. Let’s check our routing table again…

Great ! We now have our prefixes back ! Those are the 2 options we can leverage to counter the default loop prevention mechanism with BGP.

That’s what I wanted to show you today. Please leave me a comment if you have any questions.