OSPF as a PE–CE routing protocol can be used in the MPLS Layer 3 VPN design between customer and the service provider.
If the customer receives an MPLS Layer 3 VPN service , routing protocol is enabled between the customers and the Service Providers.
Don’t forget that static routing is a routing protocol !
This VPN connection is called a peer-to-peer.
Another VPN connection type is overlay VPN and I will explain them in a different article.
If you decide to receive an MPLS layer 3 VPN service but you don’t know which routing protocol you should use with the Service Provider, my advice; just continue with whatever protocol you use in your datacenter, campus, remote location and so on.
There are many caveats which I will explain in this post.
I will explain how OSPF as a PE-CE routing protocol works in the context of MPLS Layer 3 VPN in this article, but as always I will explain what are the business cases, technical requirements, alternative solutions and limitations as well.
Before I start to explain how OSPF works as a PE-CE routing protocol in MPLS Layer 3 VPN, please be aware that OSPF as a PE-CE may not be provided by your service provider.
Service provider can say that they only provides a static or BGP as an MPLS VPN PE-CE routing protocol.
Then you will not have an option but continue with either static or BGP.
Also CE can be managed by the Service Provider if it is managed MPLS Layer 3 VPN service.
In this case you don’t have to deal with routing over the WAN at all and all the complexity handled by service provider.
Lets start with the basic topology which I took from the cisco.com then continue with the advanced topics of MPLS Layer 3 VPN by using OSPF as PE-CE protocol.
In the topology above two companies merge. Site-1 and Site-2 using different OSPF area. On the Service Provider PE; OSPF process IDs are different.
Customer prefixes are received from the VRF, redistributed into MP-BGP.
On the another site PE; customer prefixes are seen as BGP route within that customers VRF. From that PE, BGP is redistributed into OSPF back.
Although there is BGP to OSPF redistribution, if the process ID are the same on the PEs for that customer, prefixes are advertised to customer as an OSPF Type 3 LSA (Inter Area).
In this topology since the OSPF process IDs are not the same, routes would be received as Type 5 (External LSA).
You cannot avoid this if you don’t want to change VRF and process ID for merge scenarios but OSPF domain ID attribute is used to overcome.
If OSPF domain ID is set as the same on the both PE for different VRF name, still routes are advertised as Type 3 LSA (Inter Area).
Since Site-1 and Site-2 has different OSPF area, even if you have backdoor link, MPLS VPN cloud can be used by metric adjustment.
In the above topology; even Site-1 and Site-2 would be in the same area, still route would be advertised as Type 3 LSA at best.
In the below topology customer wants to use MPLS VPN as primary link and they will setup DMVPN and use it as secondary.
Let’s examine the topology and see what are the issues and how can we solve it.
In the above topology Customer sites are in same OSPF area, Area 1.
OSPF Process IDs are the same on the PE1 and PE2.
Routes should have been advertised as Type 3, but the problem customer also has a backdoor link in the same area, Area1. Thus CE2 receives the prefixes which are coming behind CE1,as Type 1 from the backdoor link.
When CE2 receives CE1 prefixes as Type 1, CE2 floods them to the PE2.
Since PE2 receives those prefixes from CE2 as OSPF Type 1, it doesn’t advertise Type 3 LSA towards CES.
Solution can be achieved by creating an OSPF virtual link over the MPLS VPN network.
This is special type of virtual-link and called as OSPF sham-link.
In this topology you create an OSPF sham-link and put in the same area as the customer sites, which is Area 1 in this case.
When you create an OSPF sham-link and put it into an Area 1, PE2 will send CE1 prefixes to CE2 as Type 1 or Type 2 LSA. Then with the OSPF metric adjustment, MPLS VPN link can be used as primary.
How should you design your areas ?
Should you put your sites in Area 0 or non-backbone area ?
Whatever you do unless Service Provider creates a sham-link over the MPLS core, you will receive Type 3 LSA at best.So Area 0 or non-backbone area doesn’t matter.
If you don’t put the network behind CE in a different area you will not have an ABR.
In the above topology, if you use between PE-CE Area0 and switch to router link in Area 10, CE1 become an ABR, so summarisation can be done on CE1 likewise for the networks behind Switch2, CE2 becomes an ABR, so it can summarize.
If you place all subnets, including transit links and loopback in Area0, since you will not have an ABR, summarisation cannot be done on the customer site.
If you don’t summarise, you can have easily thousands of prefixes in the routing table of CE routers.
Most of the time those routers in the remote branch office has small amount of CPU and memory. You don’t want to send thousands of prefixes.
Also Service Provider most probably will tell you that they support up to some amount of prefixes, more than that you pay extra.
Still on the PE, summarisation either on the Ingress PE or at the egress PE can be done.
If you do it on ingress PE under the BGP, you can send a summary to all your locations.If you do it on the Egress PE, you can send a summary to whichever PE you want selectively. Of course it is not scalable, but can be done.
What is the problem with the above topology?
PE-CE links in the Area 1 but the switch to router link is in area 10. CE1 cannot be an ABR unless it has an interface in Area0. So this design normally doesn’t work. But if you create only a loopback interface and put it in Area0, it is enough for CE1 to be an ABR, so it works.
Although sham-link is a concept can be enabled on the service provider backbone, if you design carefully your backdoor link, you don’t have to deal with the service provider. They won’t either do it, or don’t know how to do it.
I would put PE-CE links in Area0, Local subnets and backdoor links in different areas.CE2 would get CE1 local subnets from MPLS cloud as type 3, as it would receive from backdoor link, to prefer MPLS VPN you would arrange a metric.
What about you ?
If you are a service provider engineer, do you configure sham-link for your customer ?
If you are an enterprise engineer who uses MPLS Layer 3 VPN, what is your PE-CE routing protocol ?
Let’s discuss these as always in the comment box below.