Russ
Author Archives: Russ
- Home → Author's archive:
Russ
Hedge 146: Leslie Daigle and Unwanted Traffic in the DFZ
How much of the traffic on the Internet is wasted—traffic no-one really wanted, and yet is being carried and paid for by providers and end users? In a world increasingly concerned about the waste of precious resources, this is an important topic to consider. Leslie Daigle joins Russ White and Tom Ammon on this episode of the Hedge to discuss the kinds of traffic she’s seeing hit their large-scale honey-trap, and the implications for the Internet.
interest in 5G private wireless,†said ABI Research. “In turn, the lack of enthusiasm has discouraged hardware suppliers from creating the necessary devices.â€Hedge 145: Roundtable on Professional Liability
The software world is known for overdue projects, costs overrun, lots of defects, and lots of failure all the way around. Many other engineering fields have stricter requirements to take on projects and liability insurance driving correct practice and care. The networking world, and the larger IT world, however, has neither of these things. Does this make IT folks less likely to “do the right thing,” or is the self-regulation we have today enough? Join Tom Ammon, Eyvonne Sharp, and Russ White as they discuss the possibilities of professional liability in information technology.
Hedge 144: IPv6 Lessons Learned
We don’t often do a post-mortem on the development and deployment of new protocols … but here at the Hedge we’re going to brave these deep waters to discuss some of the lessons we can learn from the development and deployment of IPv6, especially as they apply to design and deployment cycles in the “average network” (if there is such at thing). Join us as James Harr, Tom Ammon, and Russ White consider the lessons we can learn from IPv6’s checkered history.
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.