Category: BGP

The featured webinar in March 2016 is the Leaf-and-Spine Designs update to the Leaf-and-Spine Fabrics webinar, and in the featured videos (the ones marked with a star) you'll find in-depth explanation of BGP features available in Cumulus Linux, including a cool trick that allows you to run EBGP sessions across unnumbered interfaces.

After explaining the basics of BGP-LS and PCEP, and a quick deep dive into BGP-LS, Julian Lucek focused on the second topic of his excellent webinar and described the details of Path Computation Element Protocol (PCEP).

My good friend Tiziano Tofoni (the organizer of wonderful autumn seminars in Rome) sent me these questions after attending the BGP-LS and PCEP Deep Dive webinar, starting with:

Are there real use cases for BGP-LS and PCEP? Are they really useful? Personally I do not think they will ever be used by ISP in their (large) networks.

There are some ISPs that actually care about the network utilization on their expensive long-distance links.

After explaining why you’d want to use BGP-LS and PCEP in your network, Julian Lucek did a quick deep dive into the intricacies of BGP-LS, including printouts relating BGP-LS updates to IS-IS topology database.

This part of the PCEP/BGP-LS webinar is already public, to watch the rest of it fill in a short form on the webinar description page.

Mr. A. Anonymous left this comment on my BGP in the data centers blog post:

BGP is starting to penetrate into servers as well. What are your thoughts on having BGP running from the servers themselves?

Finally some people got it. Also, welcome back to the '90s (see also RFC 1925 section 2.11).

One of the comments added to my Using BGP in Data Centers blog post said:

With symmetric fabric… does it make sense for a node to know every bit of fabric info or is reachability information sufficient?

Let’s ignore for the moment that large non-redundant layer-3 fabrics where BGP-in-Data-Center movement started don’t need more than endpoint reachability information, and focus on a bigger issue: is knowledge of network topology (as provided by OSPF and not by BGP) beneficial?

While the large data centers increasingly use BGP as the routing protocol within their fabrics, the enterprise engineers tend to shy away from that idea because they think BGP is too complex/scary/hard-to-configure/obsolete/unknown/whatever.

It’s time to fix that.

Julian Lucek did a fantastic job describing how NorthStar controller uses BGP-LS and PCEP, so I asked him whether he’d be willing to do a deep dive on these two topics. He gracefully agreed, and the results are already online.

Many vendors talk about network automation these days, and almost all of them gloss over an important detail: automation works best when you manage to simplify things to the bare minimum needed to get the job done.

One of the vendors that focus on simplifying the network device configuration is Cumulus Linux.

At least a dozen engineers sent me emails or tweets mentioning Project Calico in the last few weeks – obviously the project is getting some real traction, so it was high time to look at what it’s all about.

TL&DR: Project Calico is yet another virtual networking implementation that’s a perfect fit for a particular use case, but falters when encountering the morass of edge cases.

One of my readers was having an LDP argument with his colleague:

Yesterday I was arguing with someone who works for a large MPLS provider about LDP label allocation. He kept saying that LDP assigns a label to each next-hop, not to each prefix. Reading your blog, I believe this is the default behavior on Juniper but on Cisco LDP assigns a unique label for each IGP (non-BGP) prefix.

He’s absolutely right; Cisco and Juniper use different rules when allocating MPLS labels.

A long long time ago Colin Dixon wrote the following tweet in response to my Controller Cluster Is a Single Failure Domain blog post:

He’s obviously right, but I wasn’t talking about interconnected domains, but failure domains (yeah, I know, you could argue they are the same, but do read on).

One of my readers decided to build an extensive DMVPN network with BGP as the WAN routing protocol (good choice!) and configured BGP SNMP traps with snmp-server enable traps bgp command on the hub router to detect spoke router failures. It turns out that’s not exactly a good idea.

One of my readers sent me this question:

I have an Internet edge setup with two routers connected to two upstream ISPs and receiving full BGP routing table from them. I’m running iBGP between my Internet routers. Is there a formula to estimate convergence time if one of my uplinks fail? How many updates will I need to get the entire 512K routes in BGP table and also how much time it would take?

As always, the answer is it depends.

BGP is without doubt the most scalable routing protocol, which made it a popular choice for large-scale deployments from service provider networks to enterprise WAN/VPN networks and even data centers. Its only significant drawback is the tedious configuration process (which almost reminds me of writing COBOL programs decades ago).