Antonio Boj enjoyed the Cisco ACI webinars by Mario Rosi and sent me this feedback:

I just wanted to pass you my feedback about the documentation and content of the above webinars. Excellent content, very well organized.

My expectation is always high about your content because I’ve become used to it with other webinars you published. I always look for non-marketing content to understand the technology.

I don’t want to criticize vendors based on assumptions or personal agendas from interested people but evaluate whether or not it is the right path forward for the problem I want to solve, knowing the pros and cons. So again, both webinars about Cisco ACI have given me excellent visibility of the solution. Thank you very much!

Whenever someone asks me about LISP, I answer, “it’s a nice idea, but cache-based forwarding never worked well.” Oldtimers familiar with the spectacular failures of fast switching and various incarnations of flow switching usually need no further explanation. Unfortunately, that lore is quickly dying out, so let’s start with the fundamentals: how does packet forwarding work?

Packet forwarding used by bridges and routers (or Layer-2/3 switches if you believe in marketing terminology) is just a particular case of statistical multiplexing – a mechanism where many communication streams share the network resources by slicing the data into packets that are sent across the network. The packets are usually forwarded independently; every one of them must contain enough information to be propagated by each intermediate device it encounters on its way across the network.

Found a pointer to another you cannot beat the laws of physics or networking result: you cannot avoid latency spikes with end-to-end congestion control regardless of the amount of unicorn dust or hype you’re throwing at the problem (original paper).

Have to work with VMware SD-WAN (the entity formerly known as VeloCloud)? You might find interesting tidbits in Crazy about VMware SD-WAN by Alexander Marhold.

After a brief excursion into the ancient data link layer addressing ideas (that you can still find in numerous systems today) and LAN addressing it’s time to focus on network-layer addressing, starting with “can we design protocols without network-layer addresses” (unfortunately, YES) and “should a network-layer address be tied to a node or to an interface” (as always, it depends).

For more details, watch the Network Layer Addressing video (part of How Networks Really Work webinar).

One of the toughest hurdles to overcome when building your own virtual networking lab is the slog of downloading VM images for your favorite network devices and building Vagrant boxes¹ in case you want to use them with Vagrant or netlab.

You can find box-building recipes on the Internet – codingpackets.com has a dozen of them – but they tend to be a bit convoluted and a smidge hard-to-follow the first time you’re trying to build the boxes (trust me, I’ve been there).

One of my readers sent me an interesting pointer:

I just watched a YouTube video by a security researcher showing how a five line python script can be used to unilaterally configure a Cisco switch port connected to a host computer into a trunk port. It does this by forging a single virtual trunk protocol (VTP) packet. The host can then eavesdrop on broadcast traffic on all VLANs on the network, as well as prosecute man-in-the-middle of attacks.

I’d say that’s a “startling revelation” along the lines of “OMG, VXLAN is insecure” – a wonderful way for a security researcher to gain instant visibility. From a more pragmatic perspective, if you enable an insecure protocol on a user-facing port, you get the results you deserve¹.

While I could end this blog post with the above flippant remark, it’s more fun considering two fundamental questions.

Here’s another BGP Route Reflector myth:

In a redundant design, you should use Route Reflector Cluster ID to avoid loops.

TL&DR: No.

While BGP route reflectors can cause permanent forwarding loops in sufficiently broken topologies, the Cluster ID was never needed to stop a routing update propagation loop:

Andy Lemin sent me such a wonderful review of ipSpace.net materials that I simply couldn’t resist publishing it ;)

ipSpace.net is probably my favorite networking resource out there. After spending years with other training content sites which are geared around certifications, ipspace.net provides a totally unique source of vendor neutral opinions, information, and anecdotes – the kind of information that is just not available anywhere else. And to top it off, is presented by a wonderful speaker who is passionate, smart and really knows his stuff!

The difference between an engineer who just has certs versus an engineer who has a rounded and wide view of the whole industry is massive. An engineer with certs can configure your network, but an engineer with all the knowledge this site provides, is someone who can question why and challenge how we can configure your network in a better way.

Stumbled upon a totally unexpected fun fact:

Every server vendor either peaked or hits the peak of maximum units sold per quarter in 2015. In the years that follow, the monthly averages drop.

Keep that in mind the next time Cisco sales team comes along with a UCS presentation.

Years ago, I compared EVPN to SIP – it has a gazillion options, and every vendor implements a different subset of them, making interoperability a nightmare.

According to Andrew Alston, SRv6 is no better (while being a security nightmare). No surprise there.

I tried to wrap up my Lessons Learned presentation on a positive note: what are some of the things you can do to avoid all the traps and pitfalls I encountered in the almost four decades of working in networking industry:

• Get invited to architecture and design meetings when a new application project starts.
• Always try to figure out what the underlying actual business needs are.
• Just because you can doesn’t mean that you should.
• Keep it as simple as possible, but no simpler.
• Work with your peers and explain how networking works and why you face certain limitations.
• Humans are not perfect – automate as much as it makes sense, but no more.

Remington Loose sent me an interesting email describing his views on the right approach to network automation after reading my Network Reliability Engineering Should Be More than Software or Automation rant – he’s advocating standardizing network services and cleaning up your network before trying to deploy full-scale automation.

I think you are 100% right to start with a thorough cleanup before automation. Garbage in, garbage out. It is also the case that all that inconsistency and differentiation makes for complexity in automation (as well as general operations) that makes it harder to gain traction.

Every time I’m writing netsim-tools release notes I’m amazed at the number of features we managed to put together in just a few weeks.

Here are the goodies from netsim-tools releases 1.1.1 and 1.1.2:

New networking myths are continuously popping up. Here’s a BGP one I encountered a few days ago:

You don’t need IBGP sessions between BGP route reflectors

In general, that’s clearly wrong, as illustrated by this setup: