Building network automation solutions

In November 2022 I described some of the intricacies of using EVPN to implement MLAG control plane. You might have noticed that I didn’t dive deep into EVPN details, and I had a good reason for that – Lukas Krattiger did a wonderful job describing how MLAG works with EVPN in the EVPN Deep Dive webinar.

One of my readers successfully deployed LDPv6 in their production network:

We are using LDPv6 since we started using MPLS with IPv6 because I was used to OSPF/OSPFv3 in dual-stack deployments, and it simply worked.

Not everyone seems to be sharing his enthusiasm:

Now some consultants tell me that they know no-one else that is using LDPv6. According to them “everyone” is using 6PE and the future of LDPv6 is not certain.

It didn’t make sense to update Amazon Web Services Networking webinar before the re:Invent conference – even though AWS introduced only a few networking features during the conference, at least one of them made a significant impact on the materials.

However, once the conference was over, I went over the to-do list that has been slowly accumulating for months and spent days updating over a dozen videos¹. The major changes include:

One of my readers asked for my opinion about the provocative “It’s Time to Replace TCP in the Datacenter” article by prof. John Ousterhout. I started reading it, found too many things that didn’t make sense, and decided to ignore it as another attempt of a proverbial physicist solving hard problems in someone else’s field.

However, pointers to that article kept popping up, and I eventually realized it was a position paper in a long-term process that included conference talks, interviews and keynote speeches, so I decided to take another look at the technical details.

One of the last things I did before going on the Christmas break was to push out netlab release 1.4.2. Its highlights include:

• Juniper vMX by Stefano Sasso
• BFD, VRF, MPLS, SR-MPLS, and MPLS/VPN on Junos (also by Stefano)
• Full VLAN support on vMX and routed VLAN interfaces on vSRX (yet again, Stefano’s contribution)
• VyOS containerlab support by Oleg A. Arkhangelsky
• CSR 1000v VLAN and VXLAN support

Upgrading is as easy as ever: execute pip3 install --upgrade networklab.

New to netlab? Start with the Getting Started document and the installation guide.

Two hundred forty blog posts and sixteen webinar sessions later, it’s time for yet another “year gone by” blog post – I’m shutting down my virtual office and will disappear until mid-January. I’ll read my email should someone experience an urgent support problem but won’t reply to 90% of the other stuff coming in.

I hope you’ll find a few days to disconnect from the crazy pace of the networking world, forget all the marketing shenanigans you encountered in 2022, and focus on your loved ones. I would also like to wish you all the best in 2023!

Finally, I couldn’t resist posting a few teasers of what’s coming in early 2023¹:

One of the most exciting announcements from the last AWS re:Invent was the Elastic Network Adapter (ENA) Express functionality that uses the Scalable Reliable Datagram (SRD) protocol as the transport protocol for the overlay virtual networks. AWS claims ENA Express can push 25 Gbps over a single TCP flow and that SRD improves the tail latency (99.9 percentile) for high-throughput workloads by 85%.

Ignoring the “DPUs could change the network forever” blogosphere reactions (hint: they won’t), let’s see what could be happening behind the scenes and why SRD improves TCP throughput and tail latency.

The hype generated by the “VMware supports DPU offload” announcement already resulted in fascinating misunderstandings. Here’s what I got from a System Architect:

We are dealing with an interesting scenario where a customer had limited data center space, but applications demand more resources. We are evaluating whether we could offload ESXi processing to DPUs (Pensando) to use existing servers as bare-metal servers. Would it be a use case for DPU?

First of all, congratulations to whichever vendor marketer managed to put that guy in that state of mind. Well done, sir, well done. Now for a dose of reality.

One of the tiny details Open Networking preachers conveniently forget to mention is the tendency of open-source software to use a gazillion small packages from numerous independent sources to get the job done. Vendors selling commercial products (for example, Cumulus Linux) try their best to select the correct version of every package involved in their product; open-source projects could quickly end in dependency hell.

netlab tries to solve the dependency conundrum with well-defined installation scripts. We recommend you start with a brand new Ubuntu server (or VM) and follow the four lines of instructions¹. In that case, you usually get a working system unless something unexpected breaks behind the scenes, like what we experienced a few days ago.

Here’s some common-sense view on hard-coded rules versus machine learning in network operations by Mark Seery – quite often we can specify our response to an event as a simple set of rules, but if we want to identify deviation from “normal” behavior, machine learning might not be a bad idea.

For more details, watch the Event-Driven Network Automation part of Building Network Automation Solutions online course.

Did you ever wonder why everything in IT becomes slower over time? Our changed expectations and accumulated cruft definitely play a major role.. but it could also be hardware. For more details (and fun reading), explore Fail-Slow at Scale: Evidence of Hardware Performance Faults in Large Production Systems.

Did you like the traffic filtering in the age of IPv6 video by Christopher Werny? Time for part two: IPv6 traffic filtering details.

I keep getting questions along the lines of “is network automation practical/a reality?” with arguments like:

Many do not see a value and are OK with just a configuration manager such as Arista CVP (CloudVision Portal) and Cisco DNA.

Configuration consistently is a huge win regardless of how you implement it (it’s perfectly fine if the tools your vendor providers work for you). It prevents opportunistic consistency, as Antti Ristimäki succinctly explained:

I got this question from one of ipSpace.net subscribers:

My VP is not a fan of overlays and is determined to move away from our legacy implementation of OTV, VXLAN, and EVPN¹. We own and manage our optical network across all sites; however, it’s hard for me to picture a network design without overlays. He keeps asking why we need overlays when we own the optical network.

There are several reasons (apart from RFC 1925 Rule 6a) why you might want to add another layer of abstraction (that’s what overlay networks are in a nutshell) to your network.

It took vendors like Cisco years to start supporting routing protocols between MLAG-attached routers and a pair of switches in the MLAG cluster. That seems like a no-brainer scenario, so there must be some hidden complexities. Let’s figure out what they are.

We’ll use the familiar MLAG diagram, replacing one of the attached hosts with a router running a routing protocol with both members of the MLAG cluster (for example, R, S1, and S2 are OSPF neighbors).