One of my subscribers sent me this question:

I’m being asked to enter a working group on RPKI and route origination. I’m doing research, listening to Jeff Tantsura, who seems optimistic about taking steps to improve BGP security vs Geoff Huston, who isn’t as optimistic. Should I recommend to the group that the application security is the better investment?

You need both. RPKI is slowly becoming the baseline of global routing hygiene (like washing hands, only virtual, and done once every blue moon when you get new IP address space or when the certificates expire). More and more Internet Service Providers (including many tier-1 providers) filter RPKI invalids thus preventing the worst cases of unintentional route leaks.

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.