Previous posts in this series (DHCP relaying principles, inter-VRFs relaying, relaying in VXLAN segments and relaying from EVPN VRF) used a single DHCP server. It’s time to add another layer of complexity: redundant DHCP servers.

Lab Topology

We’ll use a lab topology similar to the VXLAN DHCP relaying lab, add a second DHCP server, and a third switch connecting the two DHCP servers to the rest of the network.

The “beauty” (from an attacker perspective) of the original shared-media Ethernet was the ability to see all traffic sent to other hosts. While it’s trivial to steal someone else’s IPv4 address, the ability to see their traffic allowed you to hijack their TCP sessions without the victim being any wiser (apart from the obvious session timeout). Really smart attackers could go a step further, insert themselves into the forwarding path, and inject extra payload into unencrypted sessions.

A recently-discovered WiFi vulnerability brought us back to that wonderful world.

A friend sent me a video demo of his AI-driven network device configuration proof-of-concept. Before commenting on that idea, I wanted to see how well AI works as an assistant. Once Kristian Larsson mentioned he was using GitHub Copilot, it was obvious what to do next: try it out while working on the next netlab release.

TL&DR:

• It works.
• Some Copilot suggestions are uncannily accurate; others are fishing expeditions.
• It’s bland.

Years ago I loved ranting about the stupidities of building stretched VLANs to run high-availability network services clusters with two nodes (be it firewalls, load balancers, or data center switches with centralized control plane) across multiple sites.

I collected pointers to those blog posts and other ipSpace.net HA cluster resources on the new High Availability Service Clusters page.

netlab release 1.5.1 makes it easier to create topologies with lots of VRF- or VLAN access links, or topologies with numerous similar links. It also includes support for D2 diagram scripting language in case you prefer its diagrams over those generated by Graphviz.

Even if you don’t find those features interesting (more about them later), you might want to upgrade to fix a nasty container-related behavior I discovered in recently-upgraded Ubuntu servers.

After figuring out how DHCP relaying works and testing it with VRFs and in VXLAN segments, it seems like a no-brainer to make it work with EVPN.

TL&DR: It works, at least when using Arista vEOS as the relay and Cisco CSR 1000v as the DHCP server.

Lab Topology

We’ll keep using the exact same “physical” topology we used in the VXLAN DHCP relaying lab, add EVPN and BGP to the control-plane cocktail, and put the VXLAN segment into a VRF. We’ll use CSR 1000v as the DHCP server because Cisco IOSv doesn’t support some of the DHCP option-82 sub-options we need.

Jeff McLaughlin wrote a nice blog post on the death of CLI (and why it has been greatly exaggerated):

The GUI-based layout tool [for iOS app development] is going away in favor of UI-as-code! The black screen always comes back!

As I’ve been saying for ages: people optimizing their productivity use CLI.

It’s time for another Kubernetes video. After Stuart Charlton explained the Kubernetes SDN architecture, he described architectural approaches of Kubernetes SDN implementations, using Flannel as a sample implementation.

I wanted to include a few examples of BGP bugs causing widespread disruption in the Network Security Fallacies presentation. I tried to find what happened when someone announced beacon prefixes with unknown optional transitive attributes (which should have been passed without complaints but weren’t) without knowing when it happened or who did it.

Trying to find the answer on Google proved to be a Mission Impossible – regardless of how I structured my query, I got tons of results that seemed relevant to a subset of the search words but nowhere near what I was looking for. Maybe I would get luckier with a tool that’s supposed to have ingested all the world’s knowledge and seems to (according to overexcited claims) understand what it’s talking about.

An ipSpace.net subscriber sent me this question:

I am on job hunting. I have secured an interview and they will probably ask me about VxLAN BGP EVPN fabrics. If you have some time, it would be a great help for me if you could tell me 1 or 2 questions that you would ask in such interviews.

TL&DR: He got the job. Congratulations!

The last time I spent days poring over vendor datasheets collecting information for the overview part of Data Center Fabrics webinar a lot of 1RU data center leaf switches came in two form factors:

• 48 low-speed server-facing ports and 4 high-speed uplinks
• 32 high-speed ports that you could break out into four times as many low-speed ports (but not all of them)

I expected the ratios to stay the same when the industry moved from 10/40 GE to 25/100 GE switches. I was wrong – most 1RU leaf data center switches based on recent Broadcom silicon (Trident-3 or Trident-4) have between eight and twelve uplinks.

After I got the testing infrastructure in place (simple DHCP relay, VRF-aware DHCP relay), I was ready for the real fun: DHCP relaying in VXLAN (and later EVPN) segments.

TL&DR: It works exactly as expected. Even though I had anycast gateway configured on the VLAN, the Arista vEOS switches used their unicast IP addresses in the DHCP relaying process. The DHCP server had absolutely no problem dealing with multiple copies of the same DHCP broadcast relayed by different switches attached to the same VLAN. One could only wish things were always as easy in the networking land.

I have blog post ideas sitting in my to-write queue for over a decade. One of them is why would you need a VRF (and associated router) between virtual servers and a firewall?

Andrea Dainese answered at least part of that question in his Off-Path firewall with Traffic Engineering blog post. Enjoy!

Another interesting take on ChatGPT in networking, this time by Tom Hollingsworth in The Dangers of Knowing Everything:

In a way, ChatGPT is like a salesperson. No matter what you ask it the answer is always yes, even if it has to make something up to answer the question.

To paraphrase an old joke: It’s not that ChatGPT is lying. It’s just that what it knows isn’t necessarily true. See also: the difference between bullshit and lies.

Did you know most chassis switches look like leaf-and-spine fabrics¹ from the inside? If you didn’t, you might want to watch the short Chassis Architectures video by Pete Lumbis (author of ASICs for Networking Engineers part of the Data Center Fabric Architectures webinar).