In this article, MP-BGP will not be explained since it has been explained here earlier in detail.
When BGP is used as a PE-CE routing protocol between the customer and its MPLS Layer 3 VPN Provider, it is important to say that there is no need to redistribute on the Service Provider PE. All the other routing protocol require redistribution from MP-BGP into the routing protocol and vice versa.
In this post, I will explained what are the design considerations when BGP is used as PE-CE routing protocol in MPLS Layer 3 VPN and the how you can mitigate possible routing loop problems.
Last but not least, I will share when CE (Customer Equipment) is multihomed to two PEs (Provider Edge Device), what would be the design considerations if BGP is used in MPLS Layer VPN.
I believe case studies are one of the best ways for learning, thus let’s start with the below case study to understand BGP as a PE-CE protocol in MPLS Layer 3 VPN.
MPLS Layer 3 VPN BGP as a PE-CE Protocol Case Study
Orko is an Enterprise company that has stores in seven countries throughout Middle East. Orko’s headquarters and main datacenter are in Dubai. Sixty-five of Orko’s stores are connected to the datacenter in Dubai via primary MPLS L3 VPN link.
Orko’s availability is important, so secondary connections to the datacenter are provided via DMVPN over the Internet.
Orko is working with a single service provider. MPLS and Internet circuits are terminated on the same router.
In order to have better policy control and for scalability reasons; Orko decided to run BGP with its service provider for their MPLS Layer 3 VPN connection.
Orko doesn’t have public ASN and its service provider provides its private AS 500.
Orko uses unique AS number 500 on every locations, including its datacenter. In the datacenter, Orko has two MPLS circuit for redundancy and they are terminated on different routers.
- Would this solution work with BGP as a PE-CE routing protocol? What can be done to make the solution work?
- What are the possible risks and how they can be mitigated?
Case Study Analysis
Since Orko is running BGP everywhere and it uses unique AS numbers, BGP loop prevention mechanism doesn’t allow the BGP prefixes with the same AS in the AS-path.
The solution wouldn’t work unless service provider implements AS-Override or Orko implements the every router allow-AS command. Even though both solutions would allow the BGP prefixes of Orko in the BGP table of the routers, due to multi-homing in the datacenter, the solution also creates the problem of BGP routing loop.
As can be seen In the above topology, Site 3, which is Orko’s datacenter, originates BGP prefixes that are advertised to Service Provider PE device, PE3.
PE3 advertises these prefixes to PE4. Service provider configures BGP AS Override on its PE toward Orko’s PE-CE link. This creates a problem on the PE4 to CE3. Since prefixes come as “AS 10, 10” , CE 3 would allow locally originated prefixes from the MPLS backbone, thus creating a BGP routing loop
If BGP AS override or allow-AS is configured, it creates a routing loop at the multi-homed site. One solution to this problem can be with BGP site-of-origin (SoO).
SoO 10:500 is set on the PE3-CE3 and PE3-CE4 links. When the PE4 receive the prefixes from PE3, it doesn’t advertise the prefixes to CE3.
SoO 10:500 is set on the PE1-CE1 and SoO 10:500 is set on the PE2-CE2 links.
When BGP is used as a PE-CE protocol, EBGP is used almost always. RFC 6368 explains how IBGP is used as a PE-CE protocol. You might want to take a look at that draft to understand how Service Provider domain behaves as Route Reflector. That’s an interesting piece of knowledge.
Last but not least, although with MPLS Layer 3 VPN, Service Providers control the routing of customers, with BGP, customer can manipulate the routing more compare to other routing protocols.