Author Archives: Russ
Author Archives: Russ
The first hour of material in my new BGP course over at Ignition dropped this week. I’m not going to talk about configuration and other operational things—this is all about understanding how BGP works, why it works that way, and thinking about design. This course will apply to cloud, Internet edge, DC fabric, and other uses of BGP. From the official site:
BGP is one of the fundamental protocols for routing traffic across the Internet. This course, taught by networking expert and network architect Russ White, is designed to take you from BGP basics to understanding BGP at scale. The 6-hour course will be divided into several modules. Each module will contain multiple video courses of approximately 15 minutes each that drill into key concepts. The first module contains four videos that describe how BGP works. They cover basics including reachability, building loop-free paths, BGP convergence, intra-AS models, and route reflectors.
At first glance, it would seem like the history of a technology would have little to do with teaching that technology. Jacob Hess of NexGenT joins us in this episode of the Hedge to help us understand why he always includes the history of a technology when teaching it—a conversation that broadened out into why learning history is important for all network engineers.
I’m doing a series of three master classes through Juniper on various DC fabric topics—
Join Juniper’s Russ White, a widely published 30-year network engineering veteran, in a three-part masterclass exploring the data center. Choose from classes on data center fabric, physical topologies, or data center security.
From the schedule—
The world of information technology is filled, often to overflowing, with those who “know better.” For instance, I was recently reading an introduction to networking in a very popular orchestration system that began with the declaration that routing was hard, and therefore this system avoided routing. The document then went on to describe a system of moving packets around using multiple levels of Network Address Translation (NAT) and centrally configured policy-based routing (or filter-based forwarding) that was clearly simpler than the distributed protocols used to run large-scale networks. I thought, for a moment, of writing the author and pointing out the system in question had merely reinvented routing in a rather inefficient and probably broken way, but I relented. Why? Because I know RFC2915, rule 4, by heart:
Some things in life can never be fully appreciated nor understood unless experienced firsthand. Some things in networking can never be fully understood by someone who neither builds commercial networking equipment nor runs an operational network.
Ultimately, the people who built this system will likely not listen to me; rather, they are going to have to experience the pain caused by large-scale failures for themselves before they will listen. Many network Continue reading
Innovation has gained a sort-of mystical aura in our world. Move fast and break stuff. We recognize and lionize innovators in just about every way possible. The result is a general attitude of innovate or die—if you cannot innovate, then you will not progress in your career or life. Maybe it’s time to take a step back and bust some of the innovation myths created by this near idolization of innovation.
You can’t innovate where you are. Reality: innovation is not tied to a particular place and time. “But I work for an enterprise that only uses vendor gear… Maybe if I worked for a vendor, or was deeply involved in open source…” Innovation isn’t just about building new products! You can innovate by designing a simpler network that meets business needs, or by working with your vendor on testing a potential new product. Ninety percent of innovation is just paying attention to problems, along with a sense of what is “too complex,” or where things might be easier.
You don’t work in open source or open standards? That’s not your company’s problem, that’s your problem. Get involved. It’s not just about protocols, anyway. What about certifications, training, and Continue reading
RAW is a new working group recently chartered by the IETF to work on:
European networks from the mid-1980’s to the late 2000’s underwent a lot of change, bolstered by the rise and fall of America Online, the laying of a lot of subsea cables, and the creation of several organizations, including EARN and RARE, to bolster the spread and use of the Internet. Daniele Bovio joins Donald Sharp and Russ White on this episode of the History of Networking to give us a good overall perspective of this history.
You can find more information about the history of EARN at https://earn-history.net.
How do you become a “senior engineer?” It’s a question I’m asked quite often, actually, and one that deserves a better answer than the one I usually give. Charity recently answered the question in a round-a-bout way in a post discussing the “trap of the premature senior.” She’s responding to an email from someone who is considering leaving a job where they have worked themselves into a senior role. Her advice?
Quit!
This might seem to be counter-intuitive, but it’s true. I really wanted to emphasize this one line—
Exactly! Knowing the CLI for one vendor’s gear, or even two vendor’s gear, is not nearly the same as understanding how BGP actually works. Quoting the layers in the OSI model is just not the same thing as being able to directly apply the RINA model to a real problem happening right now. You’re not going to gain the understanding of “the whole ball of wax” by staying in one place, or doing one thing, for the rest of Continue reading
How can managers grow teams that add value to the company? Teams are made up of people, and people need to grow, so the key is in learning how to grow people. Join us at the Hedge as we discuss learning paths, doing what’s right for the company and the person, and growing teams by growing people.
One of the common myths of the networking world is there were no “real” networks before the early days of packet-based networks. As myths go, this is not even a very good myth; the world had very large-scale voice and data networks long before distributed routing, before packet-based switching, and before any of the packet protocols such as IP. I participated in replacing a large scale voice and data network, including hundreds of inverse multiplexers that tied a personnel system together in the middle of the 1980’s. I also installed hundreds of terminal emulation cards in Zenith Z100 and Z150 systems in the same time frame to allow these computers to connect to mainframes and newer minicomputers on the campus.
All of these systems were run through circuit-switched networks, which simply means the two end points would set up a circuit over which data would travel before the data actually traveled. Packet switched networks were seen as more efficient at the time because the complexity of setting these circuits up, along with the massive waste of bandwidth because the circuits were always over provisioned and underused.
The problem, at that time, with packet-based networks was the sheer overhead of switching Continue reading
I’m teaching a webinar on troubleshooting theory on the 20th; register here. From the course description:
This training focuses on the half-split system of troubleshooting, which is widely used in the electronic and civil engineering domains. The importance of tracing the path of the signal, using models to put the system in context, and the use of a simple troubleshooting “loop” to focus on asking how, what, and why are added to the half-split method to create a complete theory of troubleshooting. Other concepts covered in this course are the difference between permanent and temporary fixes and a review of measuring reliability. The final third of the course contains several practical examples of working through problems to help in applying the theory covered in the first two sections to the real world.
I remember a time long ago—but then again, everything seems like it was “long ago” to me—when I was flying out to see an operator in a financial district. Someone working with the account asked me what I normally wear… which is some sort of button down and black or grey pants in pretty much any situation. Well, I will put on a sport jacket if I’m teaching in some contexts, but still, the black/grey pants and some sort of button down are pretty much a “uniform” for me. The person working on the account asked me if I could please switch to ragged shorts, a t-shirt, and grow a pony tail because … the folks at the operator would never believe I was an engineer if I dressed to “formal.”
Now I’ve never thought of what I wear as “formal…” it’s just … what I wear. Context, however, is king.
In other situation, I saw a sales engineer go to a store and buy an entirely new outfit because he came to the company’s building wearing a suit and tie … The company in question deals in outdoor gear, and the location was in a small midwestern town, Continue reading
Security has taken on an aura of mystery to many network engineers—why can’t we approach security in the way we do many other topics, rationally? It turns out we can. Dan Blum joins Tom Ammon and Russ White to discuss the concepts and techniques behind rational cybersecurity.
Cable networks account for the majority of the connectivity at the network edge. Given we started with dial-up over plain old telephone lines, and then with DSL, and were promised “ATM to the home,” how did cable networks grab the edge? Rouzbeh Yassini joins Russ White and Donald Sharp to give us the history of cable networks.
What, really, is “technical debt?” It’s tempting to say “anything legacy,” but then why do we need a new phrase to describe “legacy stuff?” Even the prejudice against legacy stuff isn’t all that rational when you think about it. Something that’s old might also just be well-tested, or well-worn but still serviceable. Let’s try another tack.
Technical debt, in the software world, can be defined as working on a piece of software for long periods of time by only adding features, and never refactoring or reorganizing the code to meet current conditions. The general idea is that as new features are added on top of the old, two things happen. First, the old stuff becomes a sort of opaque box that no-one understands. Second, the stuff being added to the old increasingly relies on public behavior that might be subject to unintended consequences or leaky abstractions.
To resolve this problem in the software world, software is “refactored.” In refactoring, every use of a public API is examined, including what information is being drawn out, or what the expected inputs and outputs are. The old code is then “discarded,” in a sense, and a new underlying function written Continue reading