Posts from ‘CCIE SP’
Read the Label, the VPN label.
One of the frequent questions I hear regarding L3VPNs, is regarding the bottom VPN label. In this article, we will focus on the control plane that provides both the VPN and transit labels, and then look at the data plane that results because of those labels.
In the topology, there are 2 customer sites (bottom right, and bottom left). The BGP, VRFs, Redistribution, etc are all configured to allow us to focus on the control and data plane. Lets begin by verifying that R1 is sourcing the network, 1.1.1.1/32.
A debug verifies that R1 is sending the updates for 1.1.1.1 to R2.
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.
Our BGP class is coming up! This class is for learners who are pursuing the CCIP track, or simply want to really master BGP. I have been working through the slides, examples and demos that we’ll use in class, and it is going to be excellent. 
If you can’t make the live event, we are recording it, so it will be available as a class on demand, after the live event. More information, can be found by clicking here.
One of the common questions that comes up is “Why does the router choose THAT route?
We all know, (or at least after reading the list below, we will know), that BGP uses the following order, to determine the “best” path.
So now for the question. Take a look at the partial output of the show command below: Continue Reading
Abstract
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.
Tags: CCDE, ccie, hierarchical bgp, hierarchical lsp, MPLS, mpls-te, rsvp-te
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
Time is a valuable resource in the lab. In a lab task, if asked to configure a policy-map named “BOB”, it doesn’t get the same point value if we happen to accidentally name it “bob”, especially if they are looking to see if you configured what they asked for.
The challenge is, that when reviewing a lab task, and we discover that we need to change a name, it could be a hassle, as we need to remove the policy-map, recreate the policy map, and then put it in place again.
So if you are down to the last minute, here is a time saving solution, that can assist with that process.
IOS allows us to rename a policy-map, and the IOS will swap out the name in other areas of the configuration that reference that policy map. 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 4.4.4.4 for network 5.5.5.5 (R5 loopback). R4, at 4.4.4.4 is an iBGP neighbor.
R2#show ip route vrf v | inc 5.5.5.0 B 5.5.5.0 [200/409600] via 4.4.4.4, 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 5.5.5.0 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
“Why doesn’t this PING work!?!”
Here is a simple 3 router configuration, well at least it is simple on 2 of the 3 routers. R1 and R3 are configured quite traditionally, but R2 is a bit more involved.
Here is the diagram.
Here are the details.
R2 is using a VRF which includes both LAN interfaces. R2 is also acting as a Zone Based Firewall in transparent mode, allowing all ICMP traffic in both directions, as well as SSH from the inside to the outside networks. R2 has a bridged virtual interface in the 10.123.0.0/24 network. All are running OSPF, but pings issued from R2 to the loopbacks of R1 and R3 are failing.
Can you identify why? Continue Reading
Tags: ccie, troubleshooting
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:
MPLS Components
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.
Loading ...
