Archive for 2022
Hedge 141: Improving WAN Router Performance
Wide area networks in large-scale cores tend to be performance choke-points—partially because of differentials between the traffic they’re receiving from data center fabrics, campuses, and other sources, and the availability of outbound bandwidth, and partially because these routers tend to be a focal point for policy implementation. Rachee Singh joins Tom Ammon, Jeff Tantsura, and Russ White to discuss “Shoofly, a tool for provisioning wide-area backbones that bypasses routers by keeping traffic in the optical domain for as long as possible.”
BGP Peering (1)
Why does BGP use TCP for peering? What happens if two BGP speakers begin the peering process at the same time? In this video, recorded for Packet Pushers, I start looking at the BGP peering process.
https://packetpushers.net/learning-bgp-module-2-lesson-1-peering-part-1-video/
Learning to Ride
Have you ever taught a kid to ride a bike? Kids always begin the process by shifting their focus from the handlebars to the pedals, trying to feel out how to keep the right amount of pressure on each pedal, control the handlebars, and keep moving … so they can stay balanced. During this initial learning phase, the kid will keep their eyes down, looking at the pedals, the handlebars, and . . . the ground.
After some time of riding, though, managing the pedals and handlebars are embedded in “muscle memory,” allowing them to get their head up and focus on where they’re going rather than on the mechanical process of riding. After a lot of experience, bike riders can start doing wheelies, or jumps, or off-road riding that goes far beyond basic balance.
Network engineer—any kind of engineering, really—is the same way.
At first, you need to focus on what you are doing. How is this configured? What specific output am I looking for in this show command? What field do I need to use in this data structure to automate that? Where do I look to find out about these fields, defects, etc.?
The problem is—it is easy to get stuck at this level, focusing on configurations, automation, and the “what” of things.
You’re not going to be able to get your head up and think about the longer term—the trail ahead, the end-point you’re trying to reach—until you commit these things to muscle memory.
The point, with technology, is learning to stop focusing on the pedals, the handlebars, and the ground, and start focusing on the goal—whether its nailing this jump or conquering this trail or making it there.
Transitioning is often hard, of course, but its just like riding a bike. You won’t make the transition until you trust your muscle memory a bit at a time.
Learning the theory of how and why things work the way they are is a key point in this transition. Configuration is just the intersection of “how this works” with “what am I trying to do…” If you know how (and why) protocols work, and you know what you’re trying to do, configuration and automation will become a matter of asking the right questions.
Learn the theory, and riding the bike will become second nature—rather than something you must focus on constantly.
Hedge 140: Aftab S and RIR Policies
Regional Internet Registries (RIRs) assign and manage numbered Internet resources like IPv4 address space, IPv6 address, and AS numbers. If you ever try to get address space or an AS number, though, it might seem like the policies the RIRs use to determine what kin and scale of resources you can get are a bit arbitrary (or even, perhaps, odd). Aftab Siddiqui joins Russ White and Tom Ammon to explain how and why these policies are set the way they are.
Hedge 139: Open Source Supply Chain Security
There is a rising concern about the security of open source projects—particularly in terms of open source software supply chain. Alistair Woodman, who works closely with multiple open source software projects, joins Tom and Russ to discuss the reality of securing open source projects. The final answer? Essentially, buyer—or in the case of open source software, user—beware.
Hedge 138: The Robustness Principle
Most network engineers take it as a “given” that the robustness principle is the “right way” to build protocols and networks—”be conservative in what you send, and liberal in what you receive.” The idea behind the robustness principle is that implementations should implement specifications as accurately as possible, but they should also accept malformed and otherwise erroneous data, process the best they can, and drop the bits they cannot process. This should allow the network to operate correctly in the face of defects and other failures. A recent draft, draft-iab-protocol-maintenance/, challenges the assumptions behind the robustness principle. Join Tom and Russ as they discuss the robustness principle and its potential problems.
Privacy for Providers
While this talk is titled privacy for providers, it really applies to just about every network operator. This is meant to open a conversation on the topic, rather than providing definitive answers. I start by looking at some of the kinds of information network operators work with, and whether this information can or should be considered “private.” In the second part of the talk, I work through some of the various ways network operators might want to consider when handling private information.