Category: segment routing
In the Segment Routing vs LDP in Hub-and-Spoke Networks blog post I explained why you could get into interesting scaling issues when running MPLS with LDP in a large hub-and-spoke network, and how you can use Segment Routing (MPLS edition) to simplify your design.
Now imagine you’d like to offer VPLS services between hubs and spokes, and happen to be using equipment that uses targeted LDP sessions to signal pseudowires. Guess what happens next…
I got an interesting question that nicely illustrates why Segment Routing (the MPLS variant) is so much better than LDP. Imagine a redundant hub-and-spoke network with hundreds of spokes. Let’s settle on 500 spokes – IS-IS supposedly has no problem dealing with a link-state topology of that size.
Let’s further assume that all routers advertise only their loopbacks1 and that we’re using unnumbered hub-to-spoke links to minimize the routing table size. The global routing table thus contains ~500 entries. MPLS forwarding tables (LFIB) contain approximately as many entries as each router assigns a label to every prefix in the routing table2. What about the LDP table (LIB – Label Information Base)?
Years ago, I compared EVPN to SIP – it has a gazillion options, and every vendor implements a different subset of them, making interoperability a nightmare.
Etienne-Victor Depasquale sent me a pointer to an interesting NANOG discussion: why would we need Segment Routing. It’s well worth reading the whole thread (until it devolves into “that is not how MPLS works” arguments), which happens to be somewhat aligned with my thinking:
- SR-MPLS makes perfect sense (excluding the migration-from-LDP fun)
- SRv6 (in whatever incantation) is mostly a vendor ploy to sell new chipsets.
After I created the Segment Routing lab to test the relationship between Node Segment ID (SID) and MPLS labels (and added support for IS-IS, SR-MPLS, and BGP to netsim-tools), I was just a minor step away from testing BGP-free core with SR-MPLS.
I added two nodes to my lab setup, this time using IOSv as those nodes need nothing more than EBGP support (and IOSv is tiny compared to IOS XE on CSR):
In one of my introductory Segment Routing videos, I made claims along the lines of “Segment Routing totally simplifies the MPLS control plane, replacing LDP and local labels allocated to various prefixes with globally managed labels advertised in IGP”
It took two years for someone to realize the
stupidity over-simplification of what I described. Matjaž Strauss sent me this kind summary of my errors:
You’re effectively claiming that SRGB has to be the same across all devices in the network. That’s not true; routers advertise SIDs and must configure label swap operations in case SRGBs don’t match.
Wait, what? What is SRGB and why could it be different across devices in the same network? Also, trust IETF to take a simple idea and complicate it to support vendor whims.
TL&DR: If you want to test BGP, OSPF, IS-IS, or SR-MPLS in a virtual lab, you might build the lab faster with netsim-tools release 0.6.
In the netsim-tools release 0.6 I focused on adding routing protocol functionality:
- IS-IS on Cisco IOS/IOS XE, Cisco NX-OS, Arista EOS, FRR, and Junos.
- BGP on the same set of platforms, including support for multiple autonomous systems, EBGP, IBGP full mesh, IBGP with route reflectors, next-hop-self control, and BGP/IGP interaction.
- Segment Routing with MPLS on Cisco IOS XE and Arista EOS.
You’ll also get:
I wanted to write a “SRv6 makes
no little sense” blog post for a long while, but there were always more relevant topics to focus on. Fortunately I won’t have to write it anytime soon; Ethan Banks did a fantastic job with SR(x)6 - Snake Oil Or Salvation?. Make sure you read it before attending the next “SRx6 will save the world” vendor presentation.
A while ago I made a statement along the lines of “MPLS segment routing is the best thing that happened to MPLS control plane in a decade”. Obviously some MPLS-focused engineers disagree with that and a few years ago I decided to write a lengthy blog post explaining the differences between using MPLS SR with IGP (or BGP) versus more traditional IGP+LDP approach.
Obviously, I wasn’t making any progress on that front, so the only way forward was to record a short video on the topic which didn’t work well either because the end-result was a set of three videos (available with free or paid ipSpace.net subscription).
I got some interesting feedback from one of my readers on Segment Routing with IPv6 extension headers:
Some people position SRv6 as the universal underlay and overlay due to its capabilities for network programming by means of feature+locator SRH separation.
Stupid me replied “SRv6 is NOT an overlay solution but a source routing solution.”
One of my readers listened to a podcast where a $vendor described how they found another use case for
source routing IPv6 segment routing (SR): 5G networks… and wondered whether SR made a comeback or is about to.
To figure out what segment routing is, watch the webinar we did with Jeff Tantsura a while ago.
I don’t know nearly enough about mobile networks to have an opinion, however…
Rich sent me a question about temporary traffic blackholing in networks where every router is running IGP (OSPF or IS-IS) and iBGP.
He started with a very simple network diagram:
Oliver Steudler from Juniper sent me a link to an interesting Juniper blog post describing zero-bandwidth traffic engineering.
Read the blog post first and then come back for some opinionated rambling ;)
Is the problem real? Yes.
With all the hype around Segment Routing we said: “let’s chat about it, what could possibly go wrong”. The result: Episode 33 of Software Gone Wild. We didn’t get very far into the technical details, but you might still find the overview useful (or not – do tell me how good or useless it is).
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.