Posts from ‘MPLS’
In this blog post we’re going to discuss the fundamental logic of how MPLS tunnels allow applications such as L2VPN & L3VPN to work, and how MPLS tunnels enable Service Providers to run what is known as the “BGP Free Core”. In a nutshell, MPLS tunnels allow traffic to transit over devices that have no knowledge of the traffic’s final destination, similar to how GRE tunnels and site-to-site IPsec VPN tunnels work. To accomplish this, MPLS tunnels use a combination of IGP learned information, BGP learned information, and MPLS labels.
In this blog post we are going to review a number of MPLS scaling techniques. Theoretically, the main factors that limit MPLS network growth are:
- IGP Scaling. Route Summarization, which is the core procedure for scaling of all commonly used IGPs does not work well with MPLS LSPs. We’ll discuss the reasons for this and see what solutions are available to deploy MPLS in presence of IGP route summarization.
- Forwarding State growth. Deploying MPLE TE may be challenging in large network as number of tunnels grow like O(N^2) where N is the number of TE endpoints (typically the number of PE routers). While most of the networks are not even near the breaking point, we are still going to review techniques that allow MPLS-TE to scale to very large networks (10th of thousands routers).
- Management Overhead. MPLS requires additional control plane components and therefore is more difficult to manage compared to classic IP networks. This becomes more complicated with the network growth.
The blog post summarizes some recently developed approaches that address the first two of the above mentioned issues. Before we begin, I would like to thank Daniel Ginsburg for introducing me to this topic back in 2007.
Last week we wrapped up the MPLS bootcamp, and it was a blast! A big shout out to all the students who attended, as well as to many of the INE staff who stopped by (you know who you are ). Thank you all.
Here is the topology we used for the class, as we built the network, step by step.
The class was organized and delivered in 30 specific lessons. Here is the “overview” slide from class: Continue Reading
Can you solve this puzzle?
R2, R3 and R4 create the service provider network, with MPLS on all three routers, and iBGP at the PE routers. R1 and R5 are the CE routers.
R2, prefers the BGP next hop of 18.104.22.168 for network 22.214.171.124 (R5 loopback). R4, at 126.96.36.199 is an iBGP neighbor.
R2#show ip route vrf v | inc 188.8.131.52 B 184.108.40.206 [200/409600] via 220.127.116.11, 00:06:47
Is R2 preferring an iBGP learned route, which has an AD of 200, over a EIGRP route, which would have an AD of 90?
Can you identify why the routing for 18.104.22.168 on the VRF of R2 is using BGP instead of EIGRP?
Below are the relevant portions of the configuration, which also can serve as a great review of how to configure MPLS VPNs. Continue Reading
In the previous MPLS Components post, we discussed the many benefits that MPLS can bring to the network, and we detailed the typical components found in a Layer 3 MPLS VPN design. In this post, we will provide more details for the MPLS components and their important, inner workings. We will make reference to the previous diagram in this post as well:
When PE1 receives a packet from CE1, it will engage in what we call a Push operation. PE1 is considered the ingress PE router and engages in label imposition. (Notice that we like to speak in fancy terminology here; when we add a label to a packet, it is termed a push or an imposition).
We know from the 5-Day QoS bootcamp that Differentiated Services is one of the three major overall approaches to providing Quality of Service in an enterprise. The other options are Integrated Services and Best Effort.
When we studied Differentiated Services, we saw that the primary marking technology approach was the Differentiated Services Code Point (DSCP) concept. These are the high order 6 bits in the IP packet ToS Byte. But how can MPLS use these markings in order to provide QoS treatment (Per Hop Behaviors (PHBs)) to various traffic forms?
The first major issue to solve is the fact that Label Switch Routers (LSRs) rely solely on the MPLS header when making forwarding decisions. These devices will no longer analyze the IP Header information, thus negating the use of the ToS Byte. This was solved through the creation of the Experimental Bits field in the MPLS header. The IETF has now renamed the field to the Traffic Class field. See RFC 5462.
Probably one of the most confusing topics for people studying BGP/MPLS VPNs are EIGRP SoO and Cost communities. Not the concepts themselves, but rather their purpose. Lack of clear documentation makes it hard to understand why and how the specific features are implemented. In this blog post we discuss the BGP Cost community and EIGRP SoO attribute. First, a brief overview of MP-BGP is given along with general concepts of route redistribution in MPLS/BGP VPNs. Next, the problems that arise when using EIGRP in multihomed VPN environment are demonstrated. Lastly, the two specific EIGRP features are described and their use demonstrated. As usual, a reader is assumed to have basic understanding of fundamental L3 VPNs and PE-CE routing concepts. You may download the post in PDF format at the following link: Understanding EIGRP SoO and BGP Cost Community
One of our students in the INE RS bootcamp today, asked about an OSPF sham-link. I thought it would make a beneficial addition to our blog, and here it is. Thanks for the request Christian!
Reader’s Digest version: MPLS networks aren’t free. If a customers is using OSPF to peer between the CE and PE routers, and also has an OSPF CE to CE neighborship, the CE’s will prefer the Intra-Area CE to CE routes (sometimes called the “backdoor” route in this situation), instead of using the Inter-Area CE to PE learned routes that use the MPLS network as a transit path. OSPF sham-links correct this behavior.
This blog post walks through the problem and the solution, including the configuration steps to create and verify a sham-link.
To begin, MPLS is set up in the network as shown with R2 and R4 acting as Provider Edge (PE) routers, and MPLS is enabled throughout R2-R3-R4.
R1 and R5 are Customer Edge (CE) routers, and the Serial0/1.15 interfaces of R1 and R5 are temporarily shut down, (this means the backdoor route isn’t in place yet, and at the moment, there is no problem).
Currently, R1 and R5 see the routes to each others local networks through the VPNv4 MPLS network, and the routes show up as Inter-Area OSPF routes with the PE routers as the next hop. Continue Reading
In this post, we will examine the Control Plane and for Forwarding Plane components in more detail and discuss their interaction. This post will reference the following diagram:
Let us start at the top of this illustration and work our way down, reviewing these components and focusing on their interaction.
First, notice the Routing Protocol is responsible for building the IP Routing Table ( or Routing Information Base RIB). This used to be our only real concern for this lab! (Ahh, the good ole’ days.) For your current lab exam, this is where we configure or repair OSPF, RIP version 2, EIGRP, or BGP.
In the last blog post, we discussed key mechanisms found in the MPLS Forwarding Plane. In this post, we are going to examine a key element of the Control Plane – LDP (Label Distribution Protocol).
We remember from the previous discussions that the Forwarding Equivalence Class (FEC) represents the path that packets are going to take through the MPLS cloud based on a criteria like the iBGP next-hop address (in the common case of L3 MPLS VPNs). Data moves efficiently through the MPLS tunnel thanks to the label swapping behavior of the MPLS devices. But how are these labels distributed and maintained throughout the MPLS cloud?
Well, an administrator could certainly “hand pick and assign” the labels, but this would only be in an environment where the admin is paid by the hour! It is obvious that a dynamic process is needed. There are three dynamic options that are used today:
- Label Distribution Protocol (LDP)
- Resource Reservation Protocol (RSVP)
- Border Gateway Protocol (BGP)