One topic of constant discussion among network engineers is the basic problems surrounding network modeling, which leads to configuration, telemetry, and troubleshooting. In this episode of the Hedge, Ryan Beckett, Tom Ammon, and Russ White discuss Zen, a general framework for compositional network modelling.
Before you give in to your impulses and wipe your screen with whatever you have at hand, let us stop you right there. Your display is way more delicate than you think, and if you want it to last you a long time in optimal conditions, you’ll need to treat it with Continue reading
Many service providers have the feeling that they “didn’t do anything wrong, but somehow we still lost.” How are providers reacting to the massive changes in the networking field, and how are they trying to regain their footing so they can move into the coming decades better positioned to compete? Join Johan Gustawsson, Tom Ammon, and Russ White as we discuss the impact of merchant silicon and changing applications on the architecture of service providers.
Automation is often put forward as the answer to all our problems—but without a map, how can we be certain we are moving in the right direction? David Gee joins Tom Ammon and Russ White on this episode of the Hedge to talk about automata without a map. Where did we come from, what are we doing with automation right now, and what do we need to do to map out a truly better future?
On Thursday the 19th of October at 1PM ET, I’ll be joining Keith Bogart for the em>INE Live live stream. You can find the details on their web site.
In this session, Keith Bogart will interview prolific author and Network Architect, Russ White Ph.D. One of only a handful of people who have attained CCAr status, Russ White has authored several books such as “Practical BGP”, “The Art of Network Architecture” and “Computer Networking Problems And Solutions”. During this session we’ll find out about his journey to becoming a Network Architect and how his passion for technology can inspire you!
On the 14th (this Thursday), I’ll once again be a guest on a live stream with Jeff T and Jeff D on Between -x2 Nerds.. I think this is the URL, but you can check on their web page later to make certain.
first, a few interesting stories on the facebook outage
and other stories, as usual
I’m sitting with Jeff Doyle and Jeff Tantsura to talk about network complexity on the Between 0x2 Nerds podcast today at 1PM ET today. The link is here—
Join us if you can.
Our community has been talking about BGP security for over 20 years. While MANRS and the RPKI have made some headway in securing BGP, the process of deciding on a method to provide at least the information providers need to make more rational decisions about the validity of individual routes is still ongoing. Geoff Huston joins Alvaro, Russ, and Tom to discuss how we got here and whether we will learn from our mistakes.
download
Our community has been talking about BGP security for over 20 years. While MANRS and the RPKI have made some headway in securing BGP, the process of deciding on a method to provide at least the information providers need to make more rational decisions about the validity of individual routes is still ongoing. Geoff Huston joins Alvaro, Russ, and Tom to discuss how we got here and whether we will learn from our mistakes.
I sometimes reference Keith’s Law in my teaching, but I don’t think I’ve ever explained it. Keith’s Law runs something like this:
Any large external step in a system’s capability is the result of many incremental changes within the system.
The reason incremental changes within a system appear as a single large step to outside observers is the smaller changes are normally hidden by abstraction. This is, in fact, the purpose of abstraction—to hide small changes inside a system from external view. Keith’s law is closely related to Clarke’s third law that “Any sufficiently advanced technology is indistinguishable from magic.” What looks like magic from the outside is really just a bunch of smaller things—each easier to understand on its own—combined into one single “thing” through abstraction.
If you’ve read this far, you’re probably thinking—what does this have to do with network engineering?
Well, several things, really.
First—the network is just an abstraction that moves packets to its users. Moving packets seems so … simple … to network users. You put data in here, and data comes out over there. All the little stuff that goes into making a network work are lost in the abstraction of the virtual Continue reading
Understanding the flow of a packet is difficult in modern networks, particularly data center fabrics with their wide fanout and high ECMP counts. At the same time, solving this problem is becoming increasingly important as quality of experience becomes the dominant measure of the network. A number of vendor-specific solutions are being developed to solve this problem. In this episode of the Hedge, Frank Brockners and Shwetha Bhandari join Alvaro Retana and Russ White to discuss the in-situ OAM work currently in progress in the IPPM WG of the IETF.
One of the designs I’ve been encountering a lot of recently is a “collapsed spine” data center network, as shown in the illustration below.
In this design, and B are spine routers, while C-F are top of rack switches. The terminology is important here, because C-F are just switches—they don’t route packets. When G sends a packet to H, the packet is switched by C to A, which then routes the packet towards F, which then switches the packet towards H. C and F do not perform an IP lookup, just a MAC address lookup. A and B are responsible for setting the correct next hop MAC address to forward packets through F to H.
What are the positive aspects of this design? Primarily that all processing is handled on the two spine routers—the top of rack switches don’t need to keep any sort of routing table, nor do any IP lookups. This means you can use very inexpensive devices for your ToR. In brownfield deployments, so long as the existing ToR devices can switch based on MAC addresses, existing hardware can be used.
This design also centralizes almost all aspects of network configuration and management on the spine routers. Continue reading
Most network engineers don’t spend a lot of time thinking about their supply chain—you must call your favorite vendor, order, and a few weeks later the hardware shows up on your loading dock. It’s not so simple any more. If you disaggregate, you need to manage your software and hardware supply chains separately. You need to think about security in your supply chain—is that software package backdoored? Moving to the cloud might seem to solve these problems, but they don’t. Even virtual networks have physical limits.
Listen in as Mike Bushong, Brooks Westbrook, Eyvonne Sharp, Tom Ammon, and Russ White discuss supply chain diversity and security.