s happening with workloads inside software containers that host the components of modern applications.Hedge 143: Being Prepared to be Laid Off with Giovanni Messina
Forty years ago there was an implied loyalty between companies and employees—but that world is long gone. As much as companies would like their employees to be loyal, layoff culture has crept into every corner of the modern world, especially as we move into an economic downturn. Giovanni Messina joins Russ White and Tom Ammon to talk about being prepared to be laid off, including such topics as being financially prepared, building skills for the long term, and finding community.
Route Servers and Loops
From the question pile: Route servers (as opposed to route reflectors) don’t change anything about a BGP route when re-advertising it to a peer, whether iBGP or eBGP. Why don’t route servers cause routing loops (or other problems) in a BGP network?
Route servers are often used by Internet Exchange Points (IXPs) to distribute routes between connected BGP speakers. BGP route servers
- Don’t change anything about a received BGP route when advertising the route to its peers (other BGP speakers)
- Don’t install routes received through BGP into the local routing table
Shouldn’t using route servers in a network—pontentially, at least—cause routing loops or other BGP routing issues? Maybe a practical example will help.
Assume b, e, and s are all route servers in their respective networks. Starting at the far left, a receives some route, 101::/64, and sends it on to b,, which then sends the unmodified route to c. When c receives traffic destined to 101::/64, what will happen? Regardless of whether these routers are running iBGP or eBGP, b will not change the next hop, so when c receives the route, a is still the next hop. If there’s no underlying routing protocol, c won’t know how Continue reading
BGP Peering (2)
I recorded the beginnings of a BGP training series over at Packet Pushers a short while back; they’ve released these onto youtube (so you can find the entire series there). I’m highlighting one of these every couple of weeks ’til I’ve gone through the entire set of recordings. In this recording, I’m talking through some more interesting aspects of BGP peering, including challenges with IPv6 link local nexthops, promiscuous peering, and capabilities.
Hedge 142: George Michaelson and the Pace of IPv6 Deployment
IPv6 is still being deployed, years after the first world IPv6 day, even more years after its first acceptance as an Internet standard by the IETF. What is taking so long? George Michaelson (APNIC) joins Tom Ammon and Russ White on this episode of the Hedge to discuss the current pace of IPv6 deployment, where there are wins, and why things might be moving more slowly in other areas.
RFC9199: Lessons in Large-scale Service Deployment
While RFC9199 (are we really in the 9000’s?) is targeted at large-scale DNS deployments–specifically root zone operators–so it might seem the average operator won’t find a lot of value here.
This is, however, far from the truth. Every lesson we’ve learned in deploying large-scale DNS root servers applies to any other large-scale user-facing service. Internally deployed DNS recursive servers are an obvious instance, but the lessons here might well apply to a scheduling, banking, or any other multi-user application accessed from a lot of places by a lot of different users. There are some unique points in DNS, such as the relatively slower pace of database synchronization across nodes, but the network-side lessons can still be useful for a lot of applications.
What are those lessons?
First, using anycast dramatically improves performance for these kinds of services. For those who aren’t familiar with the concept, anycase turns an IP address into a service identifier. Any host with a copy (or instance) or a given service advertises the same address, causing the routing table to choose the (topologically) closest instance of the service. If you’re using anycast, traffic destined to your service will automatically be forwarded to the closest server Continue reading
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 (part 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.
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 Continue reading
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.
Privacy And Networking Part 5: The Data Lifecycle
In the previous posts in this series, I concluded that privacy is everyone’s responsibility, that IP addresses (and a lot of other information network engineers handle) are protected information, and while processing packets probably doesn’t trigger any privacy warnings, network logging should and does. In this post, I want to start answering the question—okay, what […]
The post Privacy And Networking Part 5: The Data Lifecycle appeared first on Packet Pushers.
Privacy And Networking Part 4: Logging
In the last post on this topic, I concluded that IP addresses are protected information—operators should handle users’ IP addresses according to privacy best practices. But I also concluded that because IP addresses used for forwarding— Are collected (or carried through the network) only for forwarding The user cannot reasonably expect the network to forward […]
The post Privacy And Networking Part 4: Logging appeared first on Packet Pushers.
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.