Showing posts with label MPLS. Show all posts
Showing posts with label MPLS. Show all posts

Sunday, 14 February 2016

MPLS Traffic Engineering

In this post, we will discuss about MPLS Traffic Engineering. To understand where it can be used and what problems it can resolve, let's look at the below topology.

The CE1 and CE2 are customer edge devices with LAN subnet of 1.1.1.1/32 and 7.7.7.7/32 respectively. They are connected with corresponding PE1 and PE2. We are running OSPF and LDP in the service provider core. Both the PE devices exchange VPN labels via MP-BGP and transport label via LDP. 

Friday, 18 September 2015

Carrier Supporting Carrier (CSC)

In this post we will look at the Carrier Supporting Carrier design where smaller service providers use large service providers as backbone in order to connect parts of their network which eliminates the need to build and maintain their own MPLS network.

From customer's point of view, there is no difference in terms of connectivity and it will still appear as they have a normal Layer 3 MPLS connection from the provider.

Let's look at the below topology to understand how it works.



We have a Tier 2 SP who is providing services to customer sites in two different geographical locations. The service provider have their own network within specific regions but not connected with each other directly hence they are using Tier 1 SP's backbone to connect both of their networks and provide end-to-end connectivity to the customer.

Saturday, 29 August 2015

Inter-AS MPLS VPN - Option C (BGP+Label)

In this post, we will look into the Inter-AS MPLS VPN - Option C which is also known as "BGP + Label". 

Option C uses eBGP IPv4 session between ASBRs to exchange reachability to PE loopbacks. There will be a VPNv4 neighbourship between service providers VPNv4 route-reflectors (RRs).

Option C takes away the heavy reliance on ASBRs. In this case, ASBRs are only used to exchange the loopback prefixes using eBGP IPv4 sessions.

To understand how it works, let's look at our topology below.



We have two service providers. Both are connected through ASBR routers. In this specific instance, we have local VPNv4 route-reflector for each SP. The customer site CE1 is connected to SP1 and CE2 is connected to SP2.

Thursday, 13 August 2015

Inter-AS MPLS VPN - Option B (VPNv4 EBGP between ASBRs)

So far we have seen the Inter-AS MPLS VPN using "back to back VRF" method. Even though it's a relatively easy method to implement, it has few drawbacks.

This procedure doesn't require MPLS enabled on the link between ASBRs however it does not scale very well. 

There is another method in which ASBR's establish VPNv4 neighbourship, exchange MPLS labels and can maintain end-to-end LSP. It is know as "Option B".

Let's see how it works. We are going to use the same topology as we used in last post.



The IP addressing and the core routing remains the same. The only difference is the configuration on ASBR where I have removed the EBGP neighbourship statement and removed the local VRF configuration.

Friday, 7 August 2015

Inter-AS MPLS VPN - Option A (Back to Back VRF)

We have seen how standard L3 MPLS works in the previous post http://ciskonetwork.blogspot.co.uk/2015/03/layer-3-mpls-vpn.html. 

In normal implementation, customer sites are served by a single service provider. The PE routers maintain an IBGP session and the routing information gets exchanged through VPNv4 neighbourship.

What if two customer sites are connected through different service providers? The PE routers of each service provider will not be able to establish IBGP neighbourship with each other hence won't be able to exchange VPNv4 routes.

There are mainly three ways to handle this type of a situation. One of three methods is called "Option A - Back to Back VRF".


Tuesday, 14 April 2015

Layer 2 MPLS VPN (AToM)

In the previous post, we have seen the configuration of Layer 3 VPN. here we will see how we can configure Layer 2 VPN. 

Layer 3 VPN requires the PE participating in the CE routing. Sometimes PE cannot support specific routing protocol as required by the customer or the CE devices may not be IP aware.

Also customer will have to involve the service provider if they want to do any routing changes.

Layer 2 VPN resolves this issue by providing a layer 2 connectivity between CEs, effectively providing a broadcast domain. Customer can run any routing protocol between the CEs and will be in full control of the routing.

Generally it's done by using AToM (Any transport over MPLS) or L2TPV3 (Layer 2 tunnelling protocol). 

The key difference between both the methods is that AToM uses the MPLS as the transport while L2TPV3 uses IP. 

Let's look at the below scenario and see how we can implement this. We will use AToM in our example.

Wednesday, 1 April 2015

6VPE

6VPE (IPv6 VPN Provider Edge Router) is a feature which connects the customer sites configured with IPv6 addressing over the existing IPv4 MPLS backbone.

In our last post, we have seen how we can configure standard Layer 3 MPLS connection on Cisco routers and advertise customer's IPv4 prefixes over that. 

We will use the same topology for 6VPE however we will configure IPv6 addresses between PE to CE (R1-R2 and R5-R6) and on the Loopbacks of the CEs (R1 and R6).

This is how our topology looks like


Wednesday, 18 March 2015

Layer 3 MPLS VPN

In this post we will look at the steps of configuring Layer 3 MPLS VPN on Cisco routers.

As shown in the diagram, R1 and R6 are CE routers. R2 and R5 are PEs while R3 and R4 are P routers.