From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb
Complexity – My Friend, My Enemy
Over my years of network engineering, I've learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer

OECG – Appendix C

960 Words. Plan about 6 minute(s) to read this.

Moving along in our study of MPLS, this post will close out frame-mode (i.e. unicast routing application) MPLS operations. Sort of a grab-bag here, but we’ll hit convergence, penultimate hop popping, and MPLS interaction with BGP. All powered by my shiny, new wireless mouse. I actually wore out my old Intellimouse – the left-click button was flaky. I was sad to see it go, but I like the new mouse fine. Wireless is good. Oh, and accompanying my study is Beethoven’s Piano Concerto No. 5 “Emporer”. Man, I love Play Classical UK.Convergence in a Frame-Mode MPLS Network

  • Some MPLS applications will not work correctly, unless all the packets for that application are making it from edge to edge. Thus, convergence time after a link failure is important.
  • The convergence time relies heavily on the underlying interior gateway protocol. Remember that TDP/LDP isn’t going to have a label for a particular prefix, if that prefix isn’t in the routing table. So how long it takes your chosen IGP to converge will directly impact how long it takes TDP/LDP to converge.
  • LSRs running with policies of liberal retention, independent label control and unsolicited downstream label distribution (as Cisco routers do by default) are going to fare better than other, more conservatively configured LSRs during a convergence event. Why? There’s a good chance that the LSR already knows about labels from other TDP/LDP neighbors. Thus, when the underlying prefix has a new next-hop in the FIB, the LFIB already knows the appropriate label.
  • So, let’s say an interface has failed on your LSR. Goodness knows – interface failures happen from time to time. Especially if Verizon is your carrier. So what’s the impact to LSR labeled packet forwarding?
    • The LFIB is scoured of any entries that was using the failed interface.
    • The failed interface is removed from the routing table, and IP routes associated with that interface are also removed.
    • Assuming there were no equal-cost routes to the destination, the route is removed altogether from the routing table, along with the entry in the LFIB.
    • The IGP will converge, installing a new route in the routing table to the destination (assuming there’s one to install).
    • CEF and LFIB entries will be created once the new route has been installed by the IGP. Assuming a liberal retention LSR, the new LFIB entry will be installed without TDP/LDP having to do a thing.
    • The TDP neighbor on the other side of the failed link will have also failed. Therefore, all of those entries corresponding to that unreachable router will also be removed from the Label Information Base.

Penultimate Hop Popping (PHP)

  • Penultimate Hop Popping (PHP) was created to help solve a problem. Specifically, the problem of the double-lookup that an egress edge LSR does to forward a packet out of the MPLS cloud and into regular IP space.
    • The LSR performs the label lookup, and realizes he needs to pop (i.e. remove) the label. Note that the packet hasn’t been forwarded anywhere.
    • The LSR now performs an L3 lookup on the destination IP, and forwards the packet.
  • This double-lookup process can be hard on a router, especially one designed to do these sorts of things in hardware. Thus, PHP was born and made a part of the MPLS world.
  • Okay – so “penultimate” means “next to last”, right? Assuming the edge egress LSR is the LAST hop in the MPLS cloud for a given packet, PHP has something to do with the LSR that’s just upstream, right? Right – the next to last router.
  • PHP is therefore a way that the edge LSR can ask the upstream LSR to pop the label. The edge LSR therefore doesn’t have the double-lookup problem, as he’ll receive a pure IP packet. The penultimate router will receive a labeled packet, perform a lookup, determine where the packet is to go, pop the label, and forward the IP packet to the next-hop as instructed by the label.
  • How does the edge router request that the penultimate router pop the label?
    • PHP is requested via TDP/LDP.
    • A label value known as the “implicit-null” value will be included in the advertisement for a particular prefix.
    • For TDP, the imp-null value is 1. For LDP, the imp-null value is 3.
  • On the penultimate LSR, IP prefixes that are to be popped before forwarding to the edge LSR will show value of “imp-null” in the LIB (show tag tdp binding) , and the LFIB will show that the label is to be popped (show tag forwarding tags).

MPLS Interaction with BGP

  • Labels are assigned to every prefix in the routing table, with one notable exception: routes learned through BGP.
  • For routes learned through BGP, the ingress edge LSR will use the same label assigned to the BGP next-hop for these destinations. Remember that with BGP, the “next-hop” assigned to the prefix won’t be the next router away for an iBGP route. The “next-hop” will be the next-hop of an eBGP router outside of the AS.
  • This allows for some design flexibility. Running BGP used to mean that you had BGP end-to-end. But if you layer MPLS on top of your backbone, it’s possible to remove BGP from the core routers, allowing MPLS to handle the forwarding. Since BGP is a beast, this should ease up on the CPU and memory requirements of the core route. There’s a big assumption to making this work: there’s an IGP underlying BGP. The IGP will know how to get to the BGP next-hop. And thus, we can dump BGP in the core, and let MPLS carry the packet through the core, using the label for the BGP next-hop to get the packet from one side of the AS to the other, rather than iBGP.