MPLS is widely used technology within Service Providers and sometimes also within Enterprise networks. One of the mostly used application of MPLS is MPLS VPN. There are two flavors of MPLS VPN which is Layer 2 and Layer3 VPNs.
Basically layer2 VPNs, service provider gives layer2 connectivity to the customer and PW established for each customer circuits, there is no Customer to Service provider routing protocol interaction.
PseudoWire is created for each of the customer VPN site with the ATOM based MPLS service so scalability can be an issue. With Layer2 VPN connectivity given by the Service Provider , Customer CE devices can setup direct neighborship with each other.
With the L3 MPLS option which is also known as BGP MPLS VPN since Service Provider runs MP-BGP over its core network and carry customer data separate from each other with L3 control plane. Customer runs routing protocol with the Service Provider. This can be static route, IGP or BGP depends on customer requirements. Below in this post you will read what these requirements and what is the pros and cons and caveats.
Just compare L2 and L3 VPN from very high level view, if fast convergence is requirements, if customer want to control its own core network, if customer doesn’t trust Service Provider stuff’s technical knowledge and they have their trained network stuff L2 would be better option compare to L3 BGP VPN option.
To connect multiple sites of the VPN customers VPN Service Providers use special types of connections between them. RFC 2547 defines standard MPLS VPN to carry customer prefixes over the MPLS backbone.
2547bis also defines Inter AS VPNs which is known as Multi AS VPNs and CSC which is also known as Carrier Supporting Carrier with the Cisco terminology and Carrier of Carrier with the Juniper definition.
With basic MPLS VPN, Enterprise customer can carry its multiple site over SP backbone. It is point to cloud fashion. With the ATOM based MPLS solution, customer sites connected as point to point and with VPLS multipoint to multipoint.
Basic difference with the VPLS and IP/VPN from customer point of view, with VPLS all attached sites within same subnet which mean same L3 network. Site-1 CE sees Site-2 CE as connected. SP behaves like big bridge for the customer sites.
With the IP/VPN also known as BGP or L3 VPN , customer runs IP routing protocol or static route with the Service provider and Customer equipment which is known as CE in the MPLS don’t see other CE as connected like in VPLS or ATOM based MPLS.
Depending on expectations of the customer from Service Provider for the MPLS L3/VPN case, Customer can run any of the IGP include IS-IS , BGP or static route. Ospf , Eigrp and even RIP can be a choice. Some service provider may nor support all of the options , so before deciding to your routing protocol within you network it is good idea to talk with the Service Provider.
If customer and Service Provider wants very granular policy and site is dual homed , fast convergence is not a main requirement and customer network stuff well-trained, best choice would be BGP.
All IGPs metric can be carried over SP MPLS backbone end to end. In this case SP core behaves differently. For OSPF there is Superbackbone and for ISIS there is L3 backbone concepts. This is out of the scope of this post so I will not explain in this post.
One another caveat for PE-CE protocol, for almost all protocol , if customer has backdoor link to another customer site , loop or suboptimal path usage condition may occur. We prefer generally MPLS link when there is need to have low latency , secure , reliable connection compare to Internet based option.
If customer has backup link through Internet and our requirement is low latency, predictable delay variation which is called as jitter , reliable and secure ( Relative ) connection , We want to use MPLS connection as primary and Internet connection as backup
Lets think this enterprise customer needs to connect its one of the site to the MPLS VPN backbone but its SP doesn’t have a POP or virtual POP for this new connection. In this case SP can use another SP to connect this new site to existing MPLS/VPN environment.
This can be achievable with 4 different ways. These are briefly known Option A, Option B, Option C and CSC which is Carrier Supporting Carrier.
Option A, B and C also called as 10 A 10 B and 10 C. They are the same thing. I will not mention specific vendor implementation but I will write their strengths and weakness from security, scalability, manageability, complexity, basically all design related point of view.
In this first post of the series I will explain the Option A also known as Back to Back VRF Approach.
Back to Back VRF, Two Service Provider is connected to each other via either just one physical link or for each customer VPN separate physical connection.
Within each Service Provider AS, ASBR routers are either directly connected or connected via GRE tunnels and treat each other as Customer. Therefore in each ASBR for each customer VPN, separate VRF is created and interface is assigned to the VRF.
- We need separate interface for each customer!
- We need separate VRF for each customer!
It is obvious if VPN site and route increase, then scalability and manageability might be a problem with back to back VRF approach.
If we are provisioning these VPN from centralize tool , this tool may not accept after some amount of VPN so scalability is a problem.
Also all VPNs might be manually configured by Network Operators, so manageability is a challenge with this approach.
We need all the VPN for every Inter AS customer (If customer does not require Inter AS service we don’t have to extend VPN information to Inter AS ASBR ) so memory and CPU consumption will be a consideration.
Memory and CPU consumption since every customer’s VPNv4 unicast or multicast or VPNv6 prefixes is installed into MP-BGP table and then RIB table for customer own VRF and FIB table that VRF, at least 3 memory structure will consume memory. With another Inter AS option we will see how we can reduce this consumption.
- For CPU; general design rule apply, for edge We need performance so CPU , for core we need throughput so memory is important component.
ASBR with back to back VRF needs much more CPU compare to Memory need , since we need to create separate VRFs for each customer , MP-BGP updates with the internal PEs , most probably routing protocol instance for each and every VRF , ACL , Prefix filter and other control plane and security mechanism , all of these are consume CPU.
Among all other Inter AS option, Option A is the most secure one. Since there is no label distribution , no BGP VPN address family neighbor ship only IP routing between the AS. Security actually is coming from its simplicity. It is also the easiest option to implement between the AS since doesn’t require another control plane mechanism between two or more AS.
Still it is open for IP Spoofing attack but even successful attacker can comprise only its own VPN. Here I assume there is no operational mistake in the MPLS core of Service Provider such as VRF to Global leakage so on.
- So far we have covered security, complexity, scalability. Generally Option A is used between the two different Service Provider AS since it is considered as secure and Service Provider does not have to trust the other AS like in Option C. Option B and Option C might be used between two AS of the same company like big enterprise or Service provider but Option A is preferred between two different companies AS.
We will exactly delve this trust ship when we talk Option C and at the end of the series, I will compare all three options.
Also since there is only IP routing between the AS easiest QoS implementation is achieved with Option A.
In All Inter AS technologies, customer has to trust to the Service Provider for data integrity, confidentiality and so on. If not other security mechanism needs to be thought for data privacy such as IPSEC. GET VPN is the most fit over MPLS/VPN for protecting data since it runs over private infrastructure only since it does not support NAT because it preserve IP header , and also there is no point to point IPSEC SA so from scalability point of view GET VPN would be the best choice.