BGP PE-CE in MPLS VPN enables customer sites to exchange routes without the need for redistribution across the MPLS backbone. One important consideration in this design is that when customer sites use the same AS number, BGP may block routes due to loop prevention. To solve this, engineers apply BGP as-override on the PE or BGP allowas-in on the CE. These solutions will be discussed and demonstrated in this lesson.

BGP PE-CE Challanges in MPLS VPN

We have already discussed various routing protocols that can be used between PE and CE in an MPLS VPN architecture, including static routing, OSPF, and EIGRP. In a traditional design, the PE router learns customer routes through these protocols, redistributes them into BGP, and then advertises them to other PE routers over the MPLS backbone. On the receiving PE routers, these routes must again be redistributed back into the original PE-CE routing protocol for the remote CE to learn them.

The main advantage of using BGP directly between PE and CE is that it eliminates the need for route redistribution at both the ingress and egress PE routers, simplifying the design, reducing potential misconfigurations, and improving scalability.

# Traditional PE-CE Routing with Redistribution
CE1 --[OSPF/EIGRP/Static]--> PE1 --[Redistribute into BGP]--> MPLS Core --> PE2 --[Redistribute into CE Routing Protocol]--> CE2

# Direct BGP Between PE and CE (Optimized)
CE1 <--BGP--> PE1 <--BGP--> PE2 <--BGP--> CE2

In a typical MPLS VPN topology, the provider has its own AS number, and each customer has a single AS number shared across all their sites connected to the MPLS backbone. A common problem in this design arises when routes advertised from one customer site are rejected at other sites. This happens because BGP automatically drops any route that contains its own AS number in the AS-PATH as part of loop-prevention.

In this example, CE1 and CE2 are two sites of the same customer, both using AS 65002, while the MPLS backbone operates in AS 65001.

  1. CE1 advertises the subnet 172.16.11.0/24 with the AS-PATH 65002.

  2. PE1 receives this route and forwards it across the MPLS backbone to PE2.

  3. When PE2 advertises the route to CE2, it appends its own AS number, resulting in the AS-PATH 65001 65002.

  4. CE2 rejects the route because it detects its own AS number (65002) in the AS-PATH, which triggers BGP’s loop-prevention mechanism.

Customer Sites with Identical AS Numbers in MPLS VPN
Customer Sites with Identical AS Numbers in MPLS VPN

To resolve this problem, there are two common solutions: allowas-in and as-override.

Using "allowas-in"

With allowas-in, configured on the CE router, we permit the CE to accept BGP routes even if its own AS number appears in the AS-PATH, up to a specified number of occurrences.

In this example, allowas-in is configured on CE2, which allows it to accept the route despite seeing its own AS number in the AS-PATH (65001 65002).

Handling Customer Sites Using the Same AS Number using Allowas-in in MPLS VPN
Handling Customer Sites Using the Same AS Number using Allowas-in in MPLS VPN

Using "as-Override"

With as-override, configured on the PE router, the PE replaces the customer’s AS number in the AS-PATH with the service provider’s AS number. This ensures that the CE router does not see its own AS number in the AS-PATH and therefore does not reject the route.

In this example, as-override is configured on PE2, which replaces CE2’s AS number (65002) with the provider’s AS number (65001). As a result, the advertised route is accepted by CE2 without being dropped.

Handling Customer Sites Using the Same AS Number using AS-Override in MPLS VPN
Handling Customer Sites Using the Same AS Number using AS-Override in MPLS VPN

BGP PE-CE in MPLS VPN Configuration Example

This configuration example builds on the concepts from the previous lessons. Here, Customer A has three sites — A1, A2, and A3 — connected to the provider’s PE routers (PE1, PE2, and PE3).

The provider uses AS 65001 as its internal AS number for BGP sessions between PE routers, while Customer A uses AS 65002 across all its sites. BGP is also configured as the routing protocol between the PE and CE routers, establishing sessions between AS 65001 (provider) and AS 65002 (customer).

BGP PE-CE in MPLS VPN
BGP PE-CE in MPLS VPN

Before configuring the allowas-in or as-override solutions, we first need to verify that, in the current setup, the CE routers are indeed not learning each other’s routes. This happens because they reject BGP updates containing their own AS number in the AS-PATH.

As an example, I checked what PE1 sends to CE A1. In the BGP updates, I could clearly see that all routes belonging to sites A2 and A3 were included. However, when I checked the BGP table on A1, I found that none of these routes were actually installed.

PE1#show ip bgp vpnv4 vrf A summary
...

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
172.16.1.2      4        65002      10      11       35    0    0 00:06:02        2
PE1#show ip bgp vpnv4 vrf A neighbors 172.16.1.2 advertised-routes
...

     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1:100 (default for vrf A)
 *>i 172.16.2.0/24    10.10.10.2               0    100      0 65002 i
 *>i 172.16.3.0/24    10.10.10.3               0    100      0 65002 i
 *>i 172.16.12.0/24   10.10.10.2               0    100      0 65002 i
 *>i 172.16.13.0/24   10.10.10.3               0    100      0 65002 i

Total number of prefixes 4
A1#show ip bgp
...
     Network          Next Hop            Metric LocPrf Weight Path
 *>  172.16.1.0/24    0.0.0.0                  0         32768 i
 *>  172.16.11.0/24   0.0.0.0                  0         32768 i

To confirm, I enabled the debug command On A1. the output showed that these routes were explicitly denied. For instance:

On A1, the output showed that these routes were explicitly denied. For instance:
A1#debug ip bgp updates
BGP updates debugging is on for address family: IPv4 Unicast
A1#clear ip bgp *
A1#
*Sep  6 14:49:50.372: %BGP-5-ADJCHANGE: neighbor 172.16.1.1 Down User reset
*Sep  6 14:49:50.372: %BGP_SESSION-5-ADJCHANGE: neighbor 172.16.1.1 IPv4 Unicast topology base removed from session  User reset
*Sep  6 14:49:51.030: %BGP-5-ADJCHANGE: neighbor 172.16.1.1 Up
*Sep  6 14:49:51.038: BGP(0): 172.16.1.1 rcv UPDATE w/ attr: nexthop 172.16.1.1, origin i, originator 0.0.0.0, merged path 65001 65002, AS_PATH , community , extended community , SSA attribute
*Sep  6 14:49:51.038: BGPSSA ssacount is 0
*Sep  6 14:49:51.038: BGP(0): 172.16.1.1 rcv UPDATE about 172.16.12.0/24 -- DENIED due to: AS-PATH contains our own AS;
*Sep  6 14:49:51.038: BGP(0): 172.16.1.1 rcv UPDATE about 172.16.13.0/24 -- DENIED due to: AS-PATH contains our own AS;
*Sep  6 14:49:51.038: BGP(0): 172.16.1.1 rcv UPDATE about 172.16.2.0/24 -- DENIED due to: AS-PATH contains our own AS;
A1#
*Sep  6 14:49:51.038: BGP(0): 172.16.1.1 rcv UPDATE about 172.16.3.0/24 -- DENIED due to: AS-PATH contains our own AS;

This demonstrates that the CE router drops any route where its own AS (65002) appears in the AS-PATH, which is BGP’s built-in loop prevention mechanism.

"allowas-in" and "as-override" to Handle BGP PE-CE

In this example, I configure allowas-in on routers A1 and A3, and as-override on PE2, in order to demonstrate both solutions. In practice, however, only one of these methods would typically be applied to resolve the issue.

Below, I demonstrate how to configure allowas-in and as-override, and then show how the routes are successfully learned once these features are applied on the customer or provider routers.

A1(config-router)#neighbor 172.16.1.1 allowas-in ?
  <1-10>  Number of occurances of AS number
  <cr>

A1(config-router)#neighbor 172.16.1.1 allowas-in 1
A1(config-router)#
*Sep  6 14:53:55.872: BGP: nbr_topo global 172.16.1.1 IPv4 Unicast:base (0xF59B8698:1) rcvd Refresh Start-of-RIB
*Sep  6 14:53:55.872: BGP: nbr_topo global 172.16.1.1 IPv4 Unicast:base (0xF59B8698:1) refresh_epoch is 2
*Sep  6 14:53:55.876: BGP(0): 172.16.1.1 rcvd UPDATE w/ attr: nexthop 172.16.1.1, origin i, merged path 65001 65002, AS_PATH
*Sep  6 14:53:55.876: BGP(0): 172.16.1.1 rcvd 172.16.12.0/24
*Sep  6 14:53:55.876: BGP(0): 172.16.1.1 rcvd 172.16.13.0/24
*Sep  6 14:53:55.876: BGP(0): 172.16.1.1 rcvd 172.16.2.0/24
*Sep  6 14:53:55.876: BGP(0): 172.16.1.1 rcvd 172.16.3.0/24
*Sep  6 14:53:55.876: BGP: nbr_topo global 172.16.1.1 IPv4 Unicast:base (0xF59B8698:1)
A1(config-router)#rcvd Refresh End-of-RIB
*Sep  6 14:53:55.881: BGP(0): Revise route installing 1 of 1 routes for 172.16.2.0/24 -> 172.16.1.1(global) to main IP table
*Sep  6 14:53:55.881: BGP(0): Revise route installing 1 of 1 routes for 172.16.3.0/24 -> 172.16.1.1(global) to main IP table
*Sep  6 14:53:55.881: BGP(0): Revise route installing 1 of 1 routes for 172.16.12.0/24 -> 172.16.1.1(global) to main IP table
*Sep  6 14:53:55.881: BGP(0): Revise route installing 1 of 1 routes for 172.16.13.0/24 -> 172.16.1.1(global) to main IP table
PE2(config-router-af)#  neighbor 172.16.2.2 as-override ?
  <cr>

PE2(config-router-af)#  neighbor 172.16.2.2 as-override
PE2(config-router-af)#
A2#
*Sep  6 14:55:16.683: BGP(0): 172.16.2.1 rcvd UPDATE w/ attr: nexthop 172.16.2.1, origin i, merged path 65001 65001, AS_PATH
*Sep  6 14:55:16.683: BGP(0): 172.16.2.1 rcvd 172.16.13.0/24
*Sep  6 14:55:16.683: BGP(0): 172.16.2.1 rcvd 172.16.3.0/24
*Sep  6 14:55:16.684: BGP(0): 172.16.2.1 rcvd 172.16.1.0/24
*Sep  6 14:55:16.684: BGP(0): 172.16.2.1 rcvd 172.16.11.0/24
*Sep  6 14:55:16.684: BGP(0): 172.16.2.1 rcv UPDATE about 172.16.12.0/24 -- withdrawn
*Sep  6 14:55:16.684: BGP(0): 172.16.2.1 rcv UPDATE about 172.16.2.0/24 -- withdrawn
*Sep  6 14:55:16.684: BGP(0): Revise route installing 1 of 1 routes for 172.16.1.0/24 -> 172.16.2.1(global) to main IP table
A2#
*Sep  6 14:55:16.684: BGP(0): Revise route installing 1 of 1 routes for 172.16.3.0/24 -> 172.16.2.1(global) to main IP table
*Sep  6 14:55:16.684: BGP(0): Revise route installing 1 of 1 routes for 172.16.11.0/24 -> 172.16.2.1(global) to main IP table
*Sep  6 14:55:16.684: BGP(0): Revise route installing 1 of 1 routes for 172.16.13.0/24 -> 172.16.2.1(global) to main IP table
A2#show ip bgp
...

     Network          Next Hop            Metric LocPrf Weight Path
 *>  172.16.1.0/24    172.16.2.1                             0 65001 65001 i
 *>  172.16.2.0/24    0.0.0.0                  0         32768 i
 *>  172.16.3.0/24    172.16.2.1                             0 65001 65001 i
 *>  172.16.11.0/24   172.16.2.1                             0 65001 65001 i
 *>  172.16.12.0/24   0.0.0.0                  0         32768 i
 *>  172.16.13.0/24   172.16.2.1                             0 65001 65001 i
A3(config)#router bgp 65002
A3(config-router)# neighbor 172.16.3.1 allowas-in
A3(config-router)#
*Sep  6 14:56:43.962: BGP: nbr_topo global 172.16.3.1 IPv4 Unicast:base (0xF3A26D08:1) rcvd Refresh Start-of-RIB
*Sep  6 14:56:43.962: BGP: nbr_topo global 172.16.3.1 IPv4 Unicast:base (0xF3A26D08:1) refresh_epoch is 2
*Sep  6 14:56:43.965: BGP(0): 172.16.3.1 rcvd UPDATE w/ attr: nexthop 172.16.3.1, origin i, merged path 65001 65002, AS_PATH
*Sep  6 14:56:43.965: BGP(0): 172.16.3.1 rcvd 172.16.12.0/24
*Sep  6 14:56:43.965: BGP(0): 172.16.3.1 rcvd 172.16.2.0/24
*Sep  6 14:56:43.965: BGP(0): 172.16.3.1 rcvd 172.16.1.0/24
*Sep  6 14:56:43.965: BGP(0): 172.16.3.1 rcvd 172.16.11.0/24
*Sep  6 14:56:43.965: BGP: nbr_topo global 172.16.3.1 IPv4 Unicast:base (0xF3A26D08:1)
A3(config-router)#rcvd Refresh End-of-RIB
*Sep  6 14:56:43.969: BGP(0): Revise route installing 1 of 1 routes for 172.16.1.0/24 -> 172.16.3.1(global) to main IP table
*Sep  6 14:56:43.969: BGP(0): Revise route installing 1 of 1 routes for 172.16.2.0/24 -> 172.16.3.1(global) to main IP table
*Sep  6 14:56:43.969: BGP(0): Revise route installing 1 of 1 routes for 172.16.11.0/24 -> 172.16.3.1(global) to main IP table
*Sep  6 14:56:43.969: BGP(0): Revise route installing 1 of 1 routes for 172.16.12.0/24 -> 172.16.3.1(global) to main IP table
A3#show ip bgp
...

     Network          Next Hop            Metric LocPrf Weight Path
 *>  172.16.1.0/24    172.16.3.1                             0 65001 65002 i
 *>  172.16.2.0/24    172.16.3.1                             0 65001 65002 i
 *>  172.16.3.0/24    0.0.0.0                  0         32768 i
 *>  172.16.11.0/24   172.16.3.1                             0 65001 65002 i
 *>  172.16.12.0/24   172.16.3.1                             0 65001 65002 i
 *>  172.16.13.0/24   0.0.0.0                  0         32768 i

Configuration Results

hostname PE1
!
ip vrf A
 rd 1:100
 route-target export 1:100
 route-target import 1:100
!
ip cef
!
mpls label protocol ldp
!
interface Loopback0
 ip address 10.10.10.1 255.255.255.255
!
interface Loopback50
 ip vrf forwarding A
 ip address 1.1.1.1 255.255.255.255
!
interface Ethernet0/0
 ip address 10.0.1.1 255.255.255.0
 mpls ip
!
interface Ethernet0/1
 ip vrf forwarding A
 ip address 172.16.1.1 255.255.255.0
!
router ospf 1
 network 10.0.0.0 0.255.255.255 area 0
!
router bgp 65001
 bgp log-neighbor-changes
 neighbor 10.10.10.2 remote-as 65001
 neighbor 10.10.10.2 update-source Loopback0
 neighbor 10.10.10.3 remote-as 65001
 neighbor 10.10.10.3 update-source Loopback0
 !
 address-family vpnv4
  neighbor 10.10.10.2 activate
  neighbor 10.10.10.2 send-community both
  neighbor 10.10.10.2 next-hop-self
  neighbor 10.10.10.3 activate
  neighbor 10.10.10.3 send-community both
  neighbor 10.10.10.3 next-hop-self
 exit-address-family
 !
 address-family ipv4 vrf A
  neighbor 172.16.1.2 remote-as 65002
  neighbor 172.16.1.2 activate
 exit-address-family
!
mpls ldp router-id Loopback0
hostname PE2
!
ip vrf A
 rd 1:100
 route-target export 1:100
 route-target import 1:100
!
ip cef
!
mpls label protocol ldp
!
interface Loopback0
 ip address 10.10.10.2 255.255.255.255
!
interface Loopback50
 ip vrf forwarding A
 ip address 2.2.2.2 255.255.255.255
!
interface Ethernet0/0
 ip address 10.0.2.2 255.255.255.0
 mpls ip
!
interface Ethernet0/1
 ip vrf forwarding A
 ip address 172.16.2.1 255.255.255.0
!
router ospf 1
 network 10.0.0.0 0.255.255.255 area 0
!
router bgp 65001
 bgp log-neighbor-changes
 neighbor 10.10.10.1 remote-as 65001
 neighbor 10.10.10.1 update-source Loopback0
 neighbor 10.10.10.3 remote-as 65001
 neighbor 10.10.10.3 update-source Loopback0
 !
 address-family vpnv4
  neighbor 10.10.10.1 activate
  neighbor 10.10.10.1 send-community both
  neighbor 10.10.10.1 next-hop-self
  neighbor 10.10.10.3 activate
  neighbor 10.10.10.3 send-community both
  neighbor 10.10.10.3 next-hop-self
 exit-address-family
 !
 address-family ipv4 vrf A
  neighbor 172.16.2.2 remote-as 65002
  neighbor 172.16.2.2 activate
  neighbor 172.16.2.2 as-override
 exit-address-family
!
mpls ldp router-id Loopback0
hostname P
!
ip cef
!
mpls label protocol ldp
!
interface Loopback0
 ip address 10.10.10.10 255.255.255.255
!
interface Ethernet0/1
 ip address 10.0.1.10 255.255.255.0
 mpls ip
!
interface Ethernet0/2
 ip address 10.0.2.10 255.255.255.0
 mpls ip
!
interface Ethernet0/3
 ip address 10.0.3.10 255.255.255.0
 mpls ip
!
router ospf 1
 network 10.0.0.0 0.255.255.255 area 0
!
mpls ldp router-id Loopback0
hostname A1
!
interface Loopback0
 ip address 172.16.11.1 255.255.255.0
!
interface Ethernet0/0
 ip address 172.16.1.2 255.255.255.0
!
router bgp 65002
 bgp log-neighbor-changes
 network 172.16.1.0 mask 255.255.255.0
 network 172.16.11.0 mask 255.255.255.0
 neighbor 172.16.1.1 remote-as 65001
 neighbor 172.16.1.1 allowas-in 1
hostname A2
!
interface Loopback0
 ip address 172.16.12.1 255.255.255.0
!
interface Ethernet0/0
 ip address 172.16.2.2 255.255.255.0
!
router bgp 65002
 bgp log-neighbor-changes
 network 172.16.2.0 mask 255.255.255.0
 network 172.16.12.0 mask 255.255.255.0
 neighbor 172.16.2.1 remote-as 65001
Back to: MPLS & MPLS VPN Fundamental (in Progress) > PE-CE Routing in MPLS VPN

Leave a Reply

Your email address will not be published. Required fields are marked *


Post comment