Category: IP routing

Reading academic articles about Internet-wide routing challenges you might stumble upon valley-free routing – a pretty important concept with applications in WAN and data center routing design.

If you’re interested in the academic discussions, you’ll find a pretty exhaustive list of papers on this topic in the Informative References section of RFC 7908; here’s the over-simplified version.

Using EBGP instead of an IGP (OSPF or IS-IS) in leaf-and-spine data center fabrics is becoming a best practice (read: thing to do when you have no clue what you’re doing).

The usual argument defending this design choice is “BGP scales better than OSPF or IS-IS”. That’s usually true (see also: Internet), and so far, EBGP is the only reasonable choice in very large leaf-and-spine fabrics… but does it really scale better than a link-state IGP in smaller fabrics?

Our good friend mr. Anonymous has too many buzzwords and opinions in his repertoire, at least based on this comment he left on my Using 4-byte AS Numbers with EVPN blog post:

But IGPs don't scale well (as you might have heard) except for RIFT and Openfabric. The others are trying to do ECMP based on BGP.

Should you be worried about OSPF or IS-IS scalability when building your data center fabric? Short answer: most probably not. Before diving into a lengthy explanation let's give our dear friend some homework.

One of my friends sent me this question:

Do you remember if VLANs came first or was it VRFs?

I remember VLANs using ISL (pre-802.1q encapsulation) on early Cisco Ethernet switches (mid 90s), the earliest reference I could track down on Wikipedia is from 1988.

Continuing the series of data center routing protocol podcasts, we sat down with Russ White (of the CCDE fame), author of another proposal: OpenFabric.

As always, we started with the “what’s wrong with what we have right now, like using BGP as a better IGP” question, resulting in “BGP is becoming the trash can of the Internet”.

Years ago Petr Lapukhov decided that it’s a waste of time to try to make OSPF or IS-IS work in large-scale data center leaf-and-spine fabrics and figured out how to use BGP as a better IGP.

In the meantime, old-time routing gurus started designing routing protocols targeting a specific environment: highly meshed leaf-and-spine fabrics. First in the list: Routing in Fat Trees (RIFT).

One of my readers sent me this question:

I'm in the process of researching SD-WAN solutions and have hit upon what I believe is a consistent deficiency across most of the current SD-WAN/SDx offerings. The standard "best practice" seems to be 60/180 BGP timers between the SD-WAN hub and the network core or WAN edge.

Needless to say, he wasn’t able to find BFD in these products either.

Does that matter? My reader thinks it does:

Linux operating system is used as the foundation for numerous network operating systems including Arista EOS and Cumulus Linux. It provides most networking constructs we grew familiar with including interfaces, VLANs, routing tables, VRFs and contexts, but they behave slightly differently from what we’re used to.

In Software Gone Wild Episode 86 Roopa Prabhu and David Ahern explained the fundamentals of packet forwarding on Linux, and the differences between Linux and more traditional network operating systems.

Level3 had a pretty bad bad-hair-day just a day before Pete Lumbis talked about Continuous Integration on the Building Network Automation Solutions online course (yes, it was a great lead-in for Pete).

According to messages circulating on mailing lists it was all caused by a fumbled configuration attempt. My wild guess: someone deleting the wrong route map, causing routes that should have been tagged with no-export escape into the wider Internet.

Omer asked a pretty common question about BFD on one of my blog posts (slightly reworded):

Would you still use BFD even if you have a direct router-to-router physical link without L2 transport in the middle to detect if there is some kind of software failure on the other side?

Sander Steffann quickly replied:

One of my readers sent me an interesting DMVPN routing question. He has a design with a single DMVPN tunnel with two hubs (a primary and a backup hub), running BGP between hubs and spokes and IBGP session between hubs over a dedicated inter-hub link (he doesn’t want the hub-to-hub traffic to go over DMVPN).

Here's (approximately) what he's trying to do:

In case you’re not familiar with RFC 1925, Rule 5 states:

It is always possible to agglutinate multiple separate problems into a single complex interdependent solution. In most cases, this is a bad idea.

Most routing protocols are a perfect demonstration of this rule.

A month ago I told you how dr. Olivier Bonaventure starts his networking course with IPv6. But there’s more: the full textbook for the undergraduate course (Computer Networking: Principles, Protocols and Practice) is open-sourced and available (in source form) on GitHub.

You might wonder why I’m so enthusiastic, so let me tell you another story…

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:

Finally a group of engineers figured out it’s a good idea to make things less complex instead of heaping layers of complexity on top of already-complex kludges.

RFC 8196 specifies default values and extensions to IS-IS that make it a true plug-and-play routing protocol. I wonder when we’ll see it implemented now that everyone is obsessed with intent-based hype.