Russ

Author Archives: Russ

BGP Training on Ignition

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.

Available here.

The Hedge Podcast #62: Jacob Hess and the Importance of History

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.

download

You can find the history of networking here.

Data Center Master Classes

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.

You can register here.

From the schedule—

  • Class 1: Data Center Fabric, December 2, 12 PM EST
  • Class 2: Physical Topologies, January 13, 12 PM EST
  • Class 3: Security in the Data Center, February 10, 12 PM EST

The EXPERIENCE HAS SHOWN THAT Keyword (RFC2915, Rule 4)

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 Myths

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

The History of EARN, RARE, and European Networks (part 1)

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.

download

The Senior Trap

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—

There is a world of distance between being expert in this system and being an actual expert in your chosen craft. The second is seniority; the first is merely .. familiarity

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

Technologies that Didn’t: Asynchronous Transfer Mode

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

Upcoming Webinar: Network Troubleshooting

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.

Casual Dress Considered Harmful?

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

History of Cable Networks with Rouzbeh Yassini

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.

download

Technical Debt (or Is Future Proofing Even a Good Idea?)

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

1 27 28 29 30 31 162