One of my readers sent me an interesting question a while ago:

Isn’t IS-IS a better fit for building L3-only networks than BGP, particularly considering that IS-IS already has a protocol to communicate with the end systems (ES-IS)?

In theory, he’s correct (see also this blog post).

Our Data Center optimization journey has finished. We virtualized the workload, got rid of legacy technologies, reduced the number of server uplinks, replaced storage arrays with distributed file system and replaced physical firewalls and load balancers with virtual appliances.

Let’s see what’s left: it turns out you really don’t need more than two switches in most data centers.

I encountered an ancient problem during one of my ExpertExpress engagements:

• Customer network is split into two autonomous systems (core and access);
• Links within access network are way slower than links within core network;
• Customer would like to have optimal core-to-access traffic flow.

Challenge: what’s the simplest possible configuration to get it done?

Got this comment on my Network Automation RFP Requirements blog post:

Looks like you are paid shill for Brocade based on the quote earlier in your blog "The Pass/Fail information included below was collected to the best of my knowledge with extensive help from Jason Edelman, Nick Buraglio, David Barroso and several Brocade engineers (THANK YOU!)."

Hooray, one more accolade to add to my list of accomplishments. And now for a few more details:

It’s only two weeks since the last live session of the Autumn 2016 Data Center course in which Mitja Robas did a fantastic job describing a production deployment of VMware NSX on top of Cisco Nexus 9000 network, and we already have the first speakers for the Spring 2017 event:

• Scott Lowe (now at VMware) will talk about the role of open source in data center infrastructure;
• Thomas Wacker (UBS AG) will talk about their fully automated data center deployments;
• Andrew Lerner and Simon Richard (Gartner) will participate in a panel discussion on data center and networking trends.

We did a podcast describing NAPALM, an open-source multi-vendor abstraction library, a while ago, and as the project made significant progress in the meantime, it was time for a short update.

NAPALM started as a library that abstracted the intricacies of network device configuration management. Initially it supported configuration replace and merge; in the meantime, they added support for diffs and rollbacks

One of my readers left this comment (slightly rephrased) on my Network Automation RFP Requirements blog post:

Given that we look up to our *nix pioneers as standard bearers for system automation, why do we demand an API from network devices? The API requirement would make sense if the vendor OS is a closed system. If an open system vendor creates APIs for applications running on their system (say for BGP configs) - kudos to them, but I no longer think that should be mandated.

He’s right - API is not a mandatory prerequisite for reliable network automation.

Continuing the Do Enterprises Need VRFs discussion, let’s see which enterprise networks might need MPLS.

Do you need VRFs?

Read the previous blog post. If the answer is NO, you can stop reading. Otherwise, carry on.

Do you need large buffers in data center switches or not? If you’re a vendor your take obviously depends on whether you have them or not, and then there are people saying “it’s bullshit” (mostly agree) and “look, I have a shinier toy” (get lost).

Unfortunately, it’s really hard to get someone who would know what he’s talking about, and be relatively unbiased.

Here’s some mandatory reading in case you still believe redundant networking infrastructure cannot fail:

• The network is reliable – a fantastic collection of real-life failures, including all sorts of split-brain scenarios caused by hare-brained schemes to stretch a cluster just a bit too far;
• More stuff on impacts of network partitions from the same author;
• Notes on Distributed Systems for Young Bloods. A must-read for anyone who thinks that ignoring 40 years of hard-learned lessons and controlling a distributed system from a central controller makes perfect sense. Not that it would ever help.

Finally, If you're serious about deep-diving into distributed systems, here's the list of materials to master (thanks to Yuriy Babenko).