Reaction: Network software quality
Over at IT ProPortal, Dr Greg Law has an article up chiding the networking world for the poor software quality. To wit— When networking companies ship equipment out containing critical bugs, providing remediation in response
On the ‘net: Simplifying Network Design
For various reasons, humans tend to prefer complex resolutions to simple ones. The combined effect of many humans preferring more complex resolutions over time means large-scale systems tend to accrue complexity, until they fall into
On the ‘net: The Tradeoffs of Information Hiding
I recently joined Ethan Banks for a Packet Pushers episode around the trade offs of hiding information in the control plane. This was a terrific show; you can listen to it by clicking on the
The Universal Fat Tree
Have you ever wondered why spine-and-leaf networks are the "standard" for data center networks? While the answer has a lot to do with trial and error, it turns out there is also a mathematical reason
The EIGRP SIA Incident: Positive Feedback Failure in the Wild
Reading a paper to build a research post from (yes, I'll write about the paper in question in a later post!) jogged my memory about an old case that perfectly illustrated the concept of a
Network Collective: Building Resilient Networks
On this community roundtable at the Network Collective, we're talking about building resilient networks with Pete Welcher, Jody Lemoine, and John Herbert. This was a terrific discussion of all those things you might not think
Giving the Monkey a Smaller Club
Over at the ACM blog, there is a terrific article about software design that has direct application to network design and architecture. The problem is that once you give a monkey a club, he is
Learning to Ask Questions
One thing I'm often asked in email and in person is: why should I bother learning theory? After all, you don't install SPF in your network; you install a router or switch, which you then
Applying Software Agility to Network Design
The paper we are looking at in this post is tangential to the world of network engineering, rather than being directly targeted at network engineering. The thesis of On Understanding Software Agility—A Social Complexity Point
If you haven’t found the tradeoff…
This week, I ran into an interesting article over at Free Code Camp about design tradeoffs. I'll wait for a moment if you want to go read the entire article to get the context of
What Kind of Design?
In this short video I work through two kinds of design, or two different ways of designing a network. Which kind of designer are you? Do you see one as better than the
Complexity and the Thin Waist
In recent years, we have become accustomed to—and often accosted by—the phrase software eats the world. It's become a mantra in the networking world that software defined is the future. full stop This research paper
Nonblocking versus Noncontending
"We use a nonblocking fabric..." Probably not. Nonblocking is a word that is thrown around a lot, particularly in the world of spine and leaf fabric design—but, just like calling a Clos a spine and
Design Resource: Shared Workspace Infrastructure
This white paper outlines solutions that can provide secure connectivity for Public Sector agencies over shared wired and wireless network infrastructures. This guide is targeted at network professionals and other personnel who assist in the
MegaSwitch: an interesting new data center fabric
Data center fabrics are built today using spine and leaf fabrics, lots of fiber, and a lot of routers. There has been a lot of research in all-optical solutions to replace current designs with something
The Perfect and the Good
Perfect and good: one is just an extension of the other, right? When I was 16 (a long, long, long time ago), I was destined to be a great graphis—a designer and/or illustrator
Mitigating DDoS
Your first line of defense to any DDoS, at least on the network side, should be to disperse the traffic across as many resources as you can. Basic math implies that if you
Dispersing a DDoS: Initial thoughts on DDoS protection
Distributed Denial of Service is a big deal—huge pools of Internet of Things (IoT) devices, such as security cameras, are compromised by botnets and being used for large scale DDoS attacks. What are
The Back Door Feature Problem
In Don’t Forget to Lock the Back Door! A Characterization of IPv6 Network Security Policy, the authors ran an experiment that tested for open ports in IPv4 and IPv6 across a wide swath of the
IPv6, DHCP, and Unintended Consequences
I ran into an interesting paper on the wide variety of options for assigning addresses, and providing DNS information, in IPv6, over at ERNW. As always, with this sort of thing, it started me thinking
On the ‘Net: Engineer Versus Complexity
https://www.youtube.com/watch?v=pvuQHkyh8sg&feature=youtu.be&w=600
I2RS and Remote Triggered Black Holes
In our last post, we looked at how I2RS is useful for managing elephant flows on a data center fabric. In this post, I want to cover a use case for I2RS that is outside
Fabric versus Network: What’s the Difference?
We often hear about fabrics, and we often hear about networks—but on paper, an in practice, they often seem to be the same thing. Leaving aside the many realms of vendor hype, what's really the
Enough with “firewalls”
A mythical conversation on firewalls, and some observations "Let's put the firewall here, so it can protect the servers in this part of the network." "How would you define a firewall?" "You know, the appliance
DC Fabric Segment Routing Use Case (5)
In this, the last post on DC fabrics as a Segment Routing use case, I mostly want to tie up some final loose ends. I will probably return to SR in the future to discuss
DC Fabric Segment Routing Use Case (3)
In the second post in this series, we considered the use of IGP-Prefix segments to carry a flow along a specific path in a data center fabric. Specifically, we looked at pulling the green flow
DC Fabric Segment Routing Use Case (2)
In the first post we covered a bit of the basics around segment routing in the data center. Let's return to the first use case to see if we can figure out how we'd actually
DC Fabric Segment Routing Use Case (1)
A couple of weeks ago, I attended a special segment routing Networking Field Day. This set me to thinking about how I would actually use segment routing in a live data center. As always, I'm
Getting to the point of dual homing
I wonder how many times I've seen this sort of diagram across the many years I've been doing network design? It's usually held up as an example of how clever the engineer running the network
When prepend fails, what next? (3)
We began this short series with a simple problem—what do you do if your inbound traffic across two Internet facing links is imbalanced? In other words, how do you do BGP load balancing? The first
When prepend fails, what next? (2)
This week's post was written by Johnny Britt over at FreedomPay. I've edited in some small places to add more information, etc., but I think Johnny needs to start blogging... Once you have determined that
When prepend fails, what next? (1)
So you want to load share better on your inbound 'net links. If you look around the 'web, it won't take long to find a site that explains how to configure AS Path Prepending. So
What is a Failure Domain?
"No, I wouldn't do that, it will make the failure domain too large..." "We need to divide this failure domain up..." Okay, great—we all know we need to use failure domains, because without them our
DR versus DIS: What’s the Diff?
OSPF and IS-IS, both link state protocols, use mechanisms that manage flooding on a broadcast link, as well as simplify the shortest path tree passing through the broadcast link. OSPF elects a Designated Router (or
Flooding Domains versus Areas
At a fundamental level, OSPF and IS-IS are similar in operation. They both build neighbor adjacencies. They both use Dijkstra's shortest path first (SPF) to find the shortest path to every destination in the network.
Something Old, Something New…
Some time back a reader sent this question in— Is there some list of design fundamentals which were "true" or at least "good rules of thumb" in the past (2 months to 20 years and
The Design Mindset (5)
So far, in our investigation of the design mindset, we've— Observed, specifically asking what, applying questions about state, surface, and optimization in our examination of the network as it's actually deployed. Oriented, asking why, really
The Design Mindset (4)—Interaction Surfaces
Before talking the final point in the network design mindset, ,act, I wanted to answer an excellent question from the comments from the last post in this series: what is surface? The concept of interaction
The Design Mindset (3)
So you've spent time asking what, observing the network as a system, and considering what has actually been done in the past. And you've spent time asking why, trying to figure out the purpose (or
CAP Theorem and Routing
In 2000, Eric Brewer was observing and discussing the various characteristics of database systems. Through this work, he observed that a database generally has three characteristics— Consistency, which means the database will produce the same
The Design Mindset (2)
In a comment from last week's post on the design mindset, which focuses on asking what through observation, Alan asked why I don't focus on business drivers, or intent, first. This is a great question.
The Design Mindset (1)
How does a network designer, well, actually design something? What process do you use as a designer to get from initial contact with a problem to building a new design to deploying a solution? What
Slicing and Dicing Flooding Domains (2)
The first post in this series is here. Finally, let's consider the first issue, the SPF run time. First, if you've been keeping track of the SPF run time in several locations throughout your network
Slicing and Dicing Flooding Domains (1)
This week two different folks have asked me about when and where I would split up a flooding domain (IS-IS) or area (OSPF); I figured a question asked twice in one week is worth a
Why you should care about complexity
If you look across a wide array of networking problems, you will see what is an apparently wide array of dissimilar and unrelated problems engineers deal with on a daily basis. For instance— Should I
Network scale is more than size
"Judge me by my size, do you?" I've had several discussions with people over the years about the concept of scale in the world of network engineering. Most often, when network engineers think of a