I have enjoyed quite a few book recommendations from Brian Dennis and Brian McGahan over the years. That is why I became very intrigued during a recent Open Lecture Series installment when I heard Brian McGahan state that he read an MPLS book cover to cover and it was “mind blowing”. That text – MPLS-Enabled Applications: Emerging Developments and New Technologies.

I am going to use this excellent text as the foundation for a series of blog posts that I consider to be most important for CCIE R&S and SP students as they seek to master MPLS.

One of the first questions we should ask, is why MPLS? What issues can it solve? Well, the first IETF MPLS Working Group Meeting occurred in April of 1997. At that meeting, the engineers identified four main items they sought to address with the new technology:

1. Scalability of network layer routing – this refers to the ability to aggregate forwarding information using labels. This is clearly witnessed today in the most popular application of MPLS technologies – the Layer 3 VPN. I love to watch the amazement on student’s faces when  in our bootcamps they build an L3VPN for the first time. They are initially bewildered by the BGP-free core that results, and the fact that no router in the topology requires full route information for all of the prefixes in the scenario. For many students, it is at this moment they embrace the inclusion of MPLS in their lab and written exams. OK, OK, maybe embrace is too strong a word. ;-)

2. Greater flexibility in delivering routing services – this refers to the use of labels to identify traffic that is to receive special service and pathing not based strictly on destination-based forwarding. While not a requirement for R&S track students, this gives rise to DiffServ Aware Traffic Engineering and is a concern for SP students.

3. Increased performance – refers to optimization of network performance through a new, simple paradigm of label-swapping. In his excellent book, MPLS Fundamentals for Cisco Press, Luc De Ghein refers to this as the “bogus benefit” of MPLS. He points out that thanks to technologies like Cisco Express Forwarding, the performance gains with MPLS are negligible. But Minei and Lucek quickly point out in MPLS-Enabled Applications that the performance gains of MPLS should be viewed in a greater context than just individual nodes. When one considers traffic engineering and fast rerouting of traffic in the network as a whole, performance gains thanks to MPLS are certainly significant.

4. Simplify integration of routers with cell switched based technologies – in April of 1997, many networks features a core of ATM switches surrounded by routers that were fully meshed with ATM connections. As we know, full meshing router connections gets out of hand real fast, so the idea was to allow the ATM devices to peer with routers. Today the problem has actually changed. More and more networks feature an MPLS core, with ATM switches interconnected via Layer 2. Now the number of adjacencies for ATM switches is the issue. This has all led to work on Generalized MPLS (GMPLS). This is the idea of a common control plane that covers a vast scope of devices such as routers, ATM switches, SONET/SDH equipment, optical cross-connects, etc. More information on this concept can be found in RFC 3945, Generalized Multi-Protocol Label Switching (GMPLS) Architecture.

For R&S candidates in particular, I think understanding the rationale behind MPLS technology is critical before delving into detailed study. I hope you will join me for more blog posts on key MPLS technologies.

You can leave a response, or trackback from your own site.

19 Responses to “Why Do We Need MPLS?!?!”

  1. Andrei says:

    Can’t wait. Love you INE!!!

  2. Israel says:

    In my endeavors to study and learn enough material to make passing the CCIE lab an afterthought, I am also discovering HOW the brain takes in information and consolidates it from short term to long term memory.A developmental and molecular biologist by the name of John Medina writes on this specific science of how the brain works in his book “Brain Rules.” He states that prior knowledge about a topic can shape how one memorizes and retains for long term storage future knowledge. That prior knowledge, or schema, is likened to a mental framework, a way of organizing thoughts around some aspect of the world. If a schema is triggered near the moment of learning, that learning is more permanent.

    Your post above and past posts by your peers provides a means to develop that schema; and now, as I continue in my studies on this intensive topic of MPLS, it will make the knowledge gained that much more permanent and deeply embedded in my brain.

    Keep up the impressive work IE team!!!!

  3. ospfv2 says:

    very important questions and explanations
    that every MPLS newbee MUST read.

    Many thanks A.S !

  4. Nadeem Rafi says:

    Great post.. I already start loving MPLS.

  5. jkdrouter says:

    That, is indeed a beast of a book on MPLS!
    Blog series on MPLS is a full of win.

  6. NET_OG says:

    FYI: this book is in Safari now. In the recording BD, was not sure that it was, but I can confirm that it is.

    Free trials: @ Safari.ciscopress.com

  7. Derick says:

    Network virtualization and portability of segregated routed environments.

    Although, Cisco is on the anti-MPLS warpath now that OTV/TRILL is about to arrive…

  8. @Derick

    I would not say it’s “Anti-MPLS” rather “anti-VPLS”, as OTV runs over any IP-based transport which inludes MPLS :) Overall, OTV seems like a logical evolution of overlaying Ethernet and I was sincerely thinking they would do that like 6 years ago. Not sure about the control-plane MAC learning using IGP, I dont think that would scale too well in large deployments. Probably BGP :)

    As for TRILL, I was originally impressed with the idea (even though there is 802.1aq work in parallel), but was slightly disappointed to find that data-plane learning is still there. If you want to see a truly floodless Ethernet idea, check out this paper:


    which introduces scalable Ethernet based on peer-to-peer network ideas.

  9. Joe Dennis says:

    Could some one explain in detail the difference between the Labels, VPN Label, Route-targets, RD. I dont understand the VPN Label. Thanks.

  10. timaz says:

    hi. thanks for your efforts to deliver useful information and really i appreciate you. i’m going to build my home lab according to Brian’s great article about building CCIE R&S lab. my lab contains 4*1841 – 4*3550 – 2*2600xm – 1*FR – and BB routers. but i don’t really know what kind of topics about MPLS can i practice with my home lab? CFN says that 1841 supports the MPLS. but i know that the MPLS is the mother technology and has many relative technologies that maybe don’t be supported by all of the routers.

  11. James Huang says:


    I am kind of confused by a few questions:

    (1) The uniqueness requirement of RD’s stated in the hub-and-spoke section, Chapter MPLS-VPN, of the MPLS Fundamentals book: it stated that “It is strongly advertised that you use one unique RD per spoke site.” and the section give an example of loss of routing information in case this rule is not followed. I thought the purpose of RD is just to make vpnv4 routes unique. So what is the reason one RD per VPN is not good eoungh?? A related question is “does BGP perform route selection per VRF afer per VRF RT matching or BGP route selection is done globally first before per VRF RT matching?”

    (2) The DN bit in OSPF options for loop prevention: Will the loop prevention mechanism cause the hub-and-spoke mechanism to fail in case the hub site uses OSPF as the PE-CE protocol as well as the intra-site IGP protocol?

    (3) OSPF uses DN bit and domain tag to solve the routing loop problem in BGP/MPLS VPN, are there corresponding mechanisms for RIP and EIGRP?

    James Huang

  12. @James Huang

    (1) The purpose of RD is making the site prefixes unique. One important consequence is that MP-BGP performs best-path selection amoung different RD’s *separately*.

    The problem with hub-and-spoke is as follows: the same prefix X could be tagged with hub’s RT and spoke’s RT. If they share the same RD value, a BGP speaker in transit will only select one of them. Let’s imagine this was the prefix with spoke’s RT. Then other spoke sites will not import it and reachability will be lost.

    Another use of separate RD is for load-balancing and redundancy. If a site is multihomed, and advertises the same prefix via different PE’s using the same RD, the route-reflector in the path will only select one best prefix and effectively disable load-balancing.

    For redundancy, having the same prefix with different RD’s and paths helps with fast recovery in MPLS networks, when the primary path fails and the secondary can take it place immediately in every participating BGP speaker.

    (2) Not sure what you mean under “intra-site” protocol. Normally in hub-and-spoke deployments every site runs it’s own instance of OSPF and DN bit does not cause any issues. It may only cause problems with multi-VRF devices inside any site.

    (3) EIGRP uses SoO to prevent transient routing loops and Cost community to augment optimal path selection. RIP does not have any special mechanics for loop prevention as it is not supposed to be used in multi-homed deployments with backdoor links.

  13. James Huang says:

    Hi Petr,

    (1) If we use one RD per VPN for a hub-and-spoke VPN, problem may happen in case RR or BGP confederation is deployed in the MPLS core network (i.e. PEs are not fully meshed). Also to make the problem occur, the hub site and one of the spoke sites should advertise a common prefix to their PEs (maybe by having a backdoor link.) Is this correct? The scenario described in the “MPLS Fundamentals” seems to be different. But I have hard time interprets the case in that book.

    (2) Sorry, let me rephrase the question.
    The DN bit in OSPF options for loop prevention: Will the loop prevention mechanism cause the hub-and-spoke mechanism to fail in case the hub site uses OSPF as the PE-CE protocol as well as the internal IGP protocol?

    Here is the scenario: PE-hub recieves a vpnv4 prefix from one of the PE-spoke’s with a RT=VRF1′s import RT. PE-hub imports the IP prefix into VRF1 and VRF1 advertises the prefix to CE1 using an OSPF type-3 LSA with DN-bit set. CE1 then forwards the type-3 LSA to CE2, and CE2 forwards the same type-3 LSA back to VRF2 of PE-hub. VRF2 finds that DN-bit is set and ingore the type-3 LSA. Now this prefix will not be redistributed back into iBGP and be advertised to the other PE_spokes (with RT=VRF2′s export RT.)

    (3) If SoO (a BGP extended-coomunity) can prevent all routing loops for EIGRP, why it can not be used to prevent all routing loops for OSPF? If it can, then why do we need DN-bit and domain-tag in OSPF?

    My understanding is that SoO and DN-bit/domain-tag are used to fix different routing loop scenarios. In the case of SoO, the network prefix causing the routing loop resides inside of the CE site that is in the looping path. In the case of DN-bit/domain-tag, the prefix causing the routing loop resides outside of the CE site that is in the looping path.

    James Huang

  14. (1) Correct, you need a “non-full-mesh” BGP topology for the best path selection effects to change the prefix selection. In hub and spoke topology the hub is supposed to re-originate the same prefixes as the spokes, but using its own RT. This is required that other spokes may import it and see it reachable via the hub.

    However, per BGP nature both hub and spoke prefixes may propagate through the network and be subject to best-path selection. As a result, the spoke’s prefix may be elected best, but the RT used for that one will not allow other spokes to import it.

    (2) I see what you mean, you are talking about the “loopback connection” in the hub. Indeed, loop prevention mechanics will prevent the prefixes from ever coming back in the hub-PE. This is why you normally see BGP being used along with “allow-as-in”. However, with OSPF you may either use different domain-ids or enable capability VRF-Lite to let the router accept type-3 LSAs with the DN bit set.

    (3) SoO attribute or route tagging configured manually could be used with any protocol that works in “distance-vector” style. However, this requires manual intervention. With OSPF, the use of DN bit allows for the behavior to be implemented *automatically* on ABRs only, that is on the routers connected to the superbackbone. The use of domain tag is essentially the same automatic use of route tagging, which works only on ASBRs.

    With EIGRP you dont have the “boundary” routers concept. Any router could be the “boundary” due to the protocol’s distance-vector nature. Thus, you need to implement tagging and filtering manually. SoO is just a more elegant way to do this, which interoperates with BGP.

    Also notice the use of automatic Cost community with EIGRP. OSPF does not require the use of this community, as all BGP learned OSPF routes are inter-area and thus will never be preferred by OSPF internally anyways. You need the sham-link with OSPF to resolve the problem solved with Cost community in EIGRP.

    • ccieturk says:


      For DN bit in Lsa type3 , The sham-link can be another solution to make the lsa as Type-1 . After that there is no type-3 lsa with DN bit set , hub PE can readvertise the prefix to MP-BGP.
      Domain tag can be worse solution , because of it will create Type-5 Lsa on hub CE as well as other CEs . And it is hard to store in LS database and the cpu processing comparing to Type-1.

  15. James Huang says:

    Hi Petr,

    Thanks for the suggestions on using vrf-lite on one of the PE’s vrfs to solve the hub-and-spokes issue with OSPF as the PE-CE protocol.

    James Huang

  16. appreciated this article!

  17. shivlu jain says:

    with this we can add, customers don’t need to much configuration at their end.
    2. Core is free from customer routes.

    Shivlu Jain


Leave a Reply


CCIE Bloggers