Category: BGP

It’s interesting how the same pundits who loudly complain about the complexities of BGP (and how it will be dead any time soon and replaced by an SDN miracle) also praise the beauties of intent-based networking… without realizing that the hated BGP route selection process represents one of the first failures of intent-based approach to networking.

Let’s start with some definitions. There are two ways to get a job done by someone else:

Every now and then someone looks at a few recent BGP incidents (from fat fingers to more dubious ones) and says “we need a better BGP”.

It’s like being unable to cope with your kids or your team members because you don’t have the guts to tell them NO and trying to solve the problem by implementing new procedures and rules.

Like anything designed on a few napkins BGP has its limit. They’re well known, and most of them have to do with trusting your neighbors instead of checking what they tell you.

Two weeks ago we discussed whether it makes sense to use BGP as the routing protocol in a data center fabric. Today we’ll tackle three additional design challenges:

• Should you use IBGP or EBGP?
• When should you run BGP on the spine switches?
• Should every leaf switch have a different AS number or should they share the same AS number?

A while ago I helped a large enterprise redesign their data center fabric. They did a wonderful job optimizing their infrastructure, so all they really needed were two switches in each location.

Some vendors couldn’t fathom that. One of them proposed to build a “future-proof” (and twice as expensive) leaf-and-spine fabric with two leaves and two spines. On top of that they proposed to use EBGP as the only routing protocol because draft-lapukhov-bgp-routing-large-dc – a clear case of missing the customer needs.

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.

One of the perks of my online courses is the lifetime access to course Slack team, and you’d amazed by the variety of questions asked there. Not so long ago I got one on BGP timers:

The BGP timers I’m using in my network are 5 and 15 seconds, and I am not sure if it's a good practice to reduce them even more.

You should always ask yourself this set of questions before tweaking a nerd knob:

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:

It’s amazing how long it can take to get some sanity into networking technologies. RFC 8212 specifies that a BGP router should not announce prefixes over EBGP until its routing policy has been explicitly configured. It took us only 22 years to get there…

For more technical details, read this email by Job Snijders.