Category: MPLS
VPLS Is Not Aspirin
If you’re old enough to remember the days when switches were still called bridges and were used to connect multiple sites over WAN links, you’ve probably experienced interesting network meltdowns caused by a single malfunctioning network interface card. Some of you might have had the “privilege” of encountering another somewhat failed attempt at WAN bridging: ATM LAN Emulation (LANE) service (not to mention the “famous” Catalyst 3000 switches with LANE uplink).
It looks like some people decided not to learn from others’ mistakes: years later the bridging-over-WAN idea has resurfaced in the VPLS clothes. While there are legitimate reasons why you’d want to have a bridged connection across the Service Provider network, VPLS should not be used to connect regular remote sites to a central site without on-site routers, as I explained in the VPLS: A secure LAN cloud solution for some, not all article I wrote in 2009 (republished below).
Why are there no Untagged entries in my LFIB?
One of the readers of my “When would an MPLS LSR have Untagged output label?” post made an interesting comment:
When a loopback network is advertised as 1.1.0.0/16, it's seen as »pop tag« on the neighboring router and I can't see it in the »show mpls forwarding« printout on the local router. What's going on?
As explained in the “When would an MPLS LSR have Untagged output label?” post, the Untagged (also displayed as No label in recent IOS releases) value means that the Label Switch Router (LSR) cannot use the inbound label to decide what to do with the packet and has to perform layer-3 lookup.
MPLS support on 1800-series routers
Christoph sent me an interesting question a few days ago:
I played a bit arround with 2 Cisco 1803 and I found MPLS related configurations commands in IOS 12.4(15)T (Advanced Enterprise) on this box. MPLS was not listed as a included fearture in the Cisco Feature Navigator for this image and some searching at cisco.com took me to a 2 year old document telling me that MPLS isn't supported on this series. Some more searching took me back to the Cisco Feature Navigator which lists MPLS as feature for the Cisco 1805 router (which uses the same IOS image, afaik).
So, I'm a bit confused now if MPLS is really working / supported on the low-end Cisco ISR 1800 fixed series?
MPLS was mostly available but never supported on low-end platforms (including Cisco 2600). In those days I've taken some heat for reusing existing 2600-based labs to teach Cisco-internal MPLS courses (since we were teaching the students to configure unsupported devices :).
Anyhow, the "not supported" means exactly that: it may be available (well, it is), it may work (it actually does), but if it's broken (and I've seen at least one low-end-platform-specific bug in the early days) you can't complain.
Is anyone aware whether the official support for the MPLS on 1800 series has changed? If so, please share your information with us.
If you need to offer a production-grade service to your customers, don't use unsupported equipment; if you need a solution for your personal needs or you're building a lab, go ahead.
When Would an MPLS LSR Have Untagged Output Label?
This is a nice MPLS question I’ve received from one of the readers:
I have understood the Penultimate Hop Popping (PHP) process, but I don’t understand when a router would use UNTAGGED instead of POP TAG?
Instead of answering the question directly, let's walk through a series of simple Q&A pairs that will help you understand the whole process (remember: knowledge, not recipes!).
Online sessions in December 2008: please vote!
The post describing my ideas about interactive online sessions resulted in a few comments and several off-line suggestions. Unfortunately most of the suggestions you’ve made in the comments are too generic. Remember, I was talking about 30-60 minute sessions and some suggestions would easily fill a week’s worth of training at the level of detail I’m aiming at. Running high-level introductory sessions is not my idea of fun; you could get as many of them as you want at Networkers.
Several suggestions are still “in the pipeline”: I have to envision how to structure them to make them manageable. In the meantime, the rest of the post lists the topics we can definitely cover. Please vote on them, the most popular one will be featured in December session.
MPLS on 7600: the devil is in the details
I've got a simple question recently: “Can I run MPLS on a VLAN interface on 7600?” My initial response was “Sure, why not.”, as I knew we've deployed MPLS in 7600-based networks and there should be no significant difference between a routed port and a VLAN interface on a 7600 (this box treats everything as a VLAN internally).
It turned out the problem was "a small detail" that's not advertised in any 7600-related MPLS marketing material on Cisco web site: you need Advanced IP Services software to run MPLS. To make matters worse, the only mention of 7600-series devices in the Cisco IOS Packaging Product Bulletin I've finally found within the 7600 routers product literature is in the first marketing slide.
This article is part of You've asked for it series.
Specify MPLS TE bandwidth as percentage of interface bandwidth
When configuring MPLS Traffic Engineering in your network, you have to specify the amount of bandwidth that the MPLS TE tunnels can request on each MPLS TE-enabled interface with the ip rsvp bandwidth command.
Until recently, this command accepted only fixed bandwidth (in kilobits), which could be pretty inconvenient if you wanted to use common interface templates or deployed MPLS TE on links with varying bandwidth (for example, Multilink PPP bundles). IOS release 12.2SRC introduced a variant of the same command (ip rsvp bandwidth percentage) that allows you to specify reservable bandwidth as percentage of the current interface bandwidth. Unfortunately this feature didn’t make it into 12.4(20)T.
Enhance the Traceroute Output
After working with MPLS Traffic Engineering lab for a few days and interpreting IP addresses from various traceroute outputs, I finally had enough and wrote a simple Perl script (below) that parses router configurations and produces ip host configuration commands for every interface IP address it encounters. When you paste the ip host commands into the configuration of the edge router from which you do the tests, the meaningless numbers finally make sense.
Do you need LDP with MPLS TE?
An anonymous commenter to my implicit NULL/PHP post made a very valid point:
Most Cisco documentation states that you must enable LDP before doing MPLS-TE, which is a complete fallacy.
If you're using MPLS TE simply to shift IP traffic around your network, he's absolutely right: there is no need to run LDP if you have an IP-only network. If you're running MPLS VPN or BGP on edges/MPLS in the core, the answer becomes “it depends.”
I documented the detailed rules and undesired side effects if you ignore them a long while ago, but that article disappeared into /dev/null. Fortunately archive.org caught a copy before that.
Would you like me to migrate that article to ipSpace.net? Send me a message and I just might do it...
MPLS Essentials: Implicit and explicit NULL
In one of the MPLS-related posts, I’ve described the role of implicit NULL in penultimate hop popping (PHP). To make the distinction between implicit and explicit NULL even clearer, I’ve prepared a short explanation with corresponding diagrams.
Is a label imposed in case of Penultimate Hop Popping?
I'm wondering whether a router performing penultimate hop popping (PHP) imposes an IGP label or not.The value of implicit null is 3; does it mean the router imposes this label (and adds four bytes to the packet)?The penultimate router does not impose the IGP label (that's why this behavior is called penultimate hop popping). However, the egress router has to signal to its upstream neighbor (the penultimate router) that it should NOT impose a label, so it uses "implicit null" label (= 3) in TDP/LDP updates to signal that the top label should be popped, not rewriten.
Goodbye fast switching & cell-mode MPLS
After leaving us in the dark for almost a year, Cisco finally released new functionality in IOS release 12.4(20)T. Support for a number of hardware platforms has been removed (dynamips fans are left with the 7200’s, everything else is gone). They also removed two switching features: fast switching and label-controlled ATM (cell-mode MPLS-over-ATM) together with Label Switch Controller (LSC).
I have no problem living without LC-ATM or LSC; this technology was primarily a retrofit for the old boxes by the time MPLS really took off with MPLS VPN. Fast switching is a different beast. Whenever you’d encounter bugs in more creative designs involving NAT, IPSec and GRE on low-end routers, you could turn off CEF (assuming you did not run NBAR) and things would (sometimes) miraculously start to work. Without fast switching, turning off CEF would bring you straight into process switching, resulting in an order-of-magnitude (or more) performance loss. On the other hand, it's obvious it makes no sense to maintain an obsolete switching method … and more bugs will probably get reported and fixed now that the easy escape route is gone.
Use Slow IGP Startup in LDP-only MPLS Environments
If you use LDP-based MPLS as the only means of transporting data across your network core (for example, in MPLS VPN networks or in BGP-free ISP core), a router startup might disrupt your Label Switched Paths (remember: they are always based on IGP best paths) leading to a temporary disruption in service.
For example, when the router P1 in the network shown in the following diagram is powered on, and its IGP advertises its presence, the IGP-derived path from PE1 to PE2 will go over P1. If the LDP on P1 has not exchanged labels with PE1 and PE2, there will be no LSP on the shortest path between PE1 and PE2, resulting in a loss of traffic until the labels are exchanged and LSP is built.
BGP without MPLS?
As I know some of you run large networks, could you help me understand what you're using (without giving away too much information, of course):
- Are you running a BGP network without MPLS or are you using BGP on the edges and MPLS transport in the core?
- If you have a large number of BGP routers, do you have a nice hierarchy of BGP route reflectors (or confederations) or ad-hoc implementation where every router has all neighbors as RR-clients?
Full disclosure: I might use the information you give me in an upcoming article.
The tale of the three MTUs
An IOS device configured for IP+MPLS routing uses three different Maximum Transmission Unit (MTU) values:
- The hardware MTU configured with the mtu interface configuration command
- The IP MTU configured with the ip mtu interface configuration command
- The MPLS MTU configured with the mpls mtu interface configuration command
The hardware MTU specifies the maximum packet length the interface can support … or at least that's the theory behind it. In reality, longer packets can be sent (assuming the hardware interface chipset doesn't complain); therefore you can configure MPLS MTU to be larger than the interface MTU and still have a working network. Oversized packets might not be received correctly if the interface uses fixed-length buffers; platforms with scatter/gather architecture (also called particle buffers) usually survive incoming oversized packets.
IP MTU is used to determine whether a non-labeled IP packet forwarded through an interface has to be fragmented (the IP MTU has no impact on labeled IP packets). It has to be lower or equal to hardware MTU (and this limitation is enforced). If it equals the HW MTU, its value does not appear in the running configuration and it tracks the changes in HW MTU. For example, if you configure ip mtu 1300 on a Serial interface, it will appear in the running configuration as long as the hardware MTU is not equal to 1300 (and will not change as the HW MTU changes). However, as soon as the mtu 1300 is configured, the ip mtu 1300 command disappears from the configuration and the IP MTU yet again tracks the HW MTU.
The MPLS MTU determines the maximum size of a labeled IP packet (MPLS shim header + IP payload size). If the overall length of the labeled packet (including the shim header) is greater than the MPLS MTU, the packet is fragmented. The MPLS MTU can be greater than the HW MTU assuming the hardware architecture and interface chipset support that (and the router will warn you that you might be getting into trouble). Similar to the ip mtu command, the mpls mtu command will only appear in the running configuration if the MPLS MTU is different from the HW MTU. However, contrary to the behavior of the IP MTU, any change in HW MTU with the mtu configuration command also resets the MPLS MTU to HW MTU.
The behavior as described above was tested on a 3725 router running IOS release 12.4(15)T1. Although the MPLS MTU Command Changes document claims that you cannot set MPLS MTU larger than then interface MTU from IOS release 12.4(11)T, I was still able to do it in 12.4(15)T1.