… updated on Wednesday, February 16, 2022 16:15 UTC
Anycast Works Just Fine with MPLS/LDP
I stumbled upon an article praising the beauties of SR-MPLS that claimed:
Yet MPLS, until recently, was deprived of anycast routing. This is because MPLS is not a pure packet switching technology, but has a control plane based on virtual circuit switching.
My first reaction was “that’s not how MPLS works,"1 followed by “that would be fun to test” a few seconds later.
Internet Traffic Gets MPLS Labels When You Deploy MPLS/VPN
A good friend of mine sent me an interesting question:
When I configure mpls ip on an interface, will all packets on that interface be labeled, or just the MPLS/VPN packets received through VRFs? I always assumed that stuff in the global routing table just got forwarded as IP packets without any labels.
Well, that’s not how MPLS works (at least not in its default incarnation on Cisco IOS).
Junos versus Cisco IOS: Explicit versus Implicit
My first Junos labbing project was an IPv6 backbone; I wanted to create a simple single-area IS-IS/BGP-free backbone running LDP and MPLS, and using 6PE for IPv6 connectivity. Needless to say, even though I read the excellent Day One books (highly recommended: Exploring IPv6, Advanced IPv6 configuration and Deploying MPLS), I stumbled on almost every step.
Junos Versus Cisco IOS: MPLS and LDP
The comments igp2bgp and Tiziano Tofoni made to my LDP-IGP Synchronization in MPLS Networks post prompted me to look deeper into basic Junos MPLS configuration and LDP behavior. As expected, there are some significant differences between Cisco’s and Juniper’s LDP implementations (and, as is usually the case, they’re both strictly conformant with RFC 5036).
… updated on Saturday, December 26, 2020 08:49 UTC
LDP-IGP Synchronization in MPLS Networks
A reader of my blog planning to migrate his network from a traditional BGP-everywhere design to a BGP-over-MPLS one wondered about potential unexpected consequences. The MTU implications of introducing MPLS in a running network are usually well understood (even though you could get some very interesting behavior); if you can, increase the MTU size by at least 16 bytes (4 labels) and check whether MTU includes L2 header. Another somewhat more mysterious beast is the interaction between IGP and LDP that can cause traffic disruptions after the physical connectivity has been reestablished.
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 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.
MPLS LDP autoconfiguration
As the careful readers of my MPLS books know, it's dangerous to run LDP with your customers; the moment you run LDP with them (Carrier's carrier model is an exception), they can insert any labeled packet into your network, bypassing inbound access lists and sending traffic where it's not supposed to go (even into another VPN). It's therefore vital that you consider security implications before deploying MPLS LDP autoconfiguration.
Using this feature on P routers is absolutely safe, as they have no customer links. You have to be more careful on the PE-routers, more so if you run routing protocols with your customers. The safest configuration method would be to configure LDP autoconfiguration inside a single OSPF area, but even then a configuration error (placing PE-CE interface in a wrong area) could open your network to MPLS-based attacks.