I got this design improvement suggestion after publishing When Is BGP No Better than OSPF blog post:

Putting all the leafs in the same ASN and filtering routes sent down to the leafs (sending just a default) are potential enhancements that make BGP a nice option.

Tony Przygienda quickly wrote a one-line rebuttal: “unless links break ;-)”

In 2014, we did a series of podcasts on Snabb Switch (Snabb Switch and OpenStack, Deep Dive), a software-only switch delivering 10-20 Gbps of forwarded bandwidth per x86 core. In the meantime, Snabb community slowly expanded, optimized the switching code, built a number of solutions on top of the packet forwarding core, and even forked a just-in-time Lua compiler to get better performance.

To find out the details, listen to Episode 91 of Software Gone Wild in which Luke Gorrie explained how far the Snabb project has progressed in the last four years.

This blog post was initially sent to the subscribers of my SDN and Network Automation mailing list. Subscribe here.

A while ago I complained how the GUI- or API-based orchestration (or intent-based) systems make it hard to figure out what exactly has been configured because they can’t give you a single text configuration file that you could track with version-control software.

Dirk Feldhaus found the situation so ridiculous that he decided to create an Ansible playbook that collects and dumps tenant parameters configured on a Cisco ACI tenant as a homework assignment in the Building Network Automation Solutions online course. As he explained the problem:

After figuring out how packet forwarding really works within AWS VPC (here’s an overview, the slide deck is already available to ipSpace.net subscribers) the next obvious question should be: “and how do I integrate a network services device like a next-generation firewall I have to use because $securityPolicy into that environment?”

Please don’t get me started on whether that makes sense, that’s a different discussion.

Christer Swartz, an old-time CCIE and occasional guest on Software Gone Wild podcast will show you how to do it with a Palo Alto firewall during my Amazon Web Services Networking Deep Dive workshop on June 13^th in Zurich, Switzerland (register here).

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?

Here’s a response I got from Simon Milhomme on my Why Is Network Automation So Hard article:

Traditional networking engineers, or virtualization engineers familiar with vSphere or VMware NSX, often feel like Alice in Wonderland when entering the world of Amazon Web Services. Everything looks and sounds familiar, and yet it all feels a bit different

I decided to create a half-day workshop (first delivery: June 13^th in Zurich, Switzerland) to make it easier to grasp the fundamentals of AWS networking, and will publish high-level summaries as a series of blog posts. Let’s start with an overview of what’s different:

As discussed in a previous blog post, IETF designed EVPN to be next-generation BGP-based VPN technology providing scalable layer-2 and layer-3 VPN functionality. EVPN was initially designed to be used with MPLS data plane and was later extended to use numerous data plane encapsulations, VXLAN being the most common one.

Design Requirements

Like any other BGP-based solution, EVPN uses BGP to transport endpoint reachability information (customer MAC and IP addresses and prefixes, flooding trees, and multi-attached segments), and relies on an underlying routing protocol to provide BGP next-hop reachability information.

Wow. Where did the spring 2018 go? It’s almost June… and time for a refreshed list of upcoming webinars:

• Christoph Jaggi will run do another free webinar – this time on Ethernet Encryptors– on June 5^th;
• I’ll run an Amazon Web Services Networking workshop in Zurich on June 13^th;
• We had to change the schedule a little bit: the last webinar before the summer break will be an overview of real-life automation wins on June 19^th.

In Moving Complexity to Application Layer I discussed the idea of trying to use all addresses returned in a DNS response when trying to establish a connection with a server, concluding with “I don’t think anyone big enough to influence browser vendors is interested in reinventing this particular wheel.”

I’m really glad to report I was wrong ;) This is what RFC 8305 (Happy Eyeballs v2) says:

BGP is the kitchen-sink of networking protocols, right? Whatever control-plane information you need to transport around, you can do it with BGP… including the battleship coordinates carried in BGP communities.

On the more serious front, it's nice to see at least some ISPs still care enough about the stability of the global Internet to use BGP route flap dampening.

As part of his “how does Avaya implement data center fabrics” presentation, Roger Lapuh talked about use cases for SPB in data center fabrics.

I have no idea what Extreme decided to do with the numerous data center fabric solutions they bought in the last few years, so the video might have just a historic value at this point… but it’s still nice to see what you can do with smart engineering.

Someone left a comment on my Zero-Touch Provisioning post claiming how Big Switch Networks solved ZTP challenge using just IPv6 Link-Local Address and Neighbor Discovery instead of the complicated DHCP/TFTP/whatever sequence.

Here’s what he wrote:

This blog post was initially sent to the subscribers of my SDN and Network Automation mailing list. Subscribe here.

Every now and then someone asks me “Why are we making so little progress on network automation? Why does it seem so hard?”

There are some obvious reasons:

• Tightly-coupled components and humongous blast radius;
• Lack of good tools and programming interfaces;
• Lack of transactional consistency (in some cases even simple commits);

However, there’s a bigger elephant in the room: every network is a unique snowflake.

Networking engineers familiar with Junos love to tell me how easy it is to configure and operate IBGP EVPN overlay on top of EBGP IP underlay. Krzysztof Szarkowicz was kind enough to send me the (probably) simplest possible configuration (here’s another one by Alexander Grigorenko)