Author Archives: Russ
Author Archives: Russ
Automation is surely one of the best things to come to the networking world—the ability to consistently apply a set of changes across a wide array of network devices has speed at which network engineers can respond to customer requests, increased the security of the network, and reduced the number of hours required to build and maintain large-scale systems. There are downsides to automation, as well—particularly when operators begin to rely on automation to solve problems that really should be solved someplace else.
In this episode of the Hedge, Andrew Wertkin from Bluecat Networks joins Tom Ammon and Russ White to discuss the naïve reliance on automation.
I’m teaching a webinar on router internals through Pearson (Safari Books Online) on the 23rd of July. From the abstract—
A network device—such as a router, switch, or firewall—is often seen as a single “thing,” an abstract appliance that is purchased, deployed, managed, and removed from service as a single unit. While network devices do connect to other devices, receiving and forwarding packets and participating in a unified control plane, they are not seen as a “system” in themselves.
What is the first thing almost every training course in routing protocols begin with? Building adjacencies. What is considered the “deep stuff” in routing protocols? Knowing packet formats and processes down to the bit level. What is considered the place where the rubber meets the road? How to configure the protocol.
I’m not trying to cast aspersions at widely available training, but I sense we have this all wrong—and this is a sense I’ve had ever since my first book was released in 1999. It’s always hard for me to put my finger on why I consider this way of thinking about network engineering less-than-optimal, or why we approach training this way.
This, however, is one thing I think is going on here—
We believe that by knowing ever-deeper reaches of detail about a protocol, we are not only more educated engineers, but we will be able to make better decisions in the design and troubleshooting spaces.
To some degree, we think we are managing the Continue reading
Bluecat, in cooperation with an outside research consultant, jut finished a survey and study on the lack of communication and divisions between the cloud and networking teams in deployments to support business operations. Dana Iskoldski joins Tom Ammon and Russ White to discuss the findings of their study, and make some suggestions about how we can improve communication between the two teams.
Please find a copy of the study at http://bluecatnetworks.com/hedge.
I often feel like I’m “behind” on what I need to get done. Being a bit metacognitive, however, I often find this feeling is more related to not organizing things well, which means I often feel like I have so much to do “right now” that I just don’t know what to do next—hence “processor thrashing on process scheduler.” Todd Palino joins this episode of the Hedge to talk about the “Getting Things Done” technique (or system) of, well … getting things done.
It’s not unusual in the life of a network engineer to go entire weeks, perhaps even months, without “getting anything done.” This might seem odd for those who do not work in and around the odd combination of layer 1, layer 3, layer 7, and layer 9 problems network engineers must span and understand, but it’s normal for those in the field. For instance, a simple request to support a new application might require the implementation of some feature, which in turn requires upgrading several thousand devices, leading to the discovery that some number of these devices simply do not support the new software version, requiring a purchase order and change management plan to be put in place to replace those devices, which results in … The chain of dominoes, once it begins, never seems to end.
Or, as those who have dealt with these problems many times might say, it is more complicated than you think. This is such a useful phrase, in fact, it has been codified as a standard rule of networking in RFC1925 (rule 8, to be precise).
Take, for instance, the problem of sending documents through electronic mail—in the real world, there are various Continue reading
The network monitoring world is rife with formats for packets being measured—every tool has its own format. What would make things a lot better for network engineers is a standard data representation for packet analysis, no matter what format packets are captured in. Jordan Holland joins Russ White and Tom Ammon on this episode of the Hedge to discuss the problem and nprint, a standard packet analysis format and tools for converting from other formats.
TCP and QUIC are the two primary transport protocols in use on the Internet today—QUIC carries a large part of the HTTP traffic that makes the web work, while TCP carries most everything else that expects reliability. Why can’t we apply the lessons from QUIC to TCP so we can merge these two protocols, unifying Internet transport? TCPLS is just such an attempt at merging the most widely used reliable transport protocols.
Fear sells. Fear of missing out, fear of being an imposter, fear of crime, fear of injury, fear of sickness … we can all think of times when people we know (or worse, a people in the throes of madness of crowds) have made really bad decisions because they were afraid of something. Bruce Schneier has documented this a number of times. For instance: “it’s smart politics to exaggerate terrorist threats” and “fear makes people deferential, docile, and distrustful, and both politicians and marketers have learned to take advantage of this.” Here is a paper comparing the risk of death in a bathtub to death because of a terrorist attack—bathtubs win.
But while fear sells, the desire to appear unafraid also sells—and it conditions people’s behavior much more than we might think. For instance, we often say of surveillance “if you have done nothing wrong, you have nothing to hide”—a bit of meaningless bravado. What does this latter attitude—“I don’t have anything to worry about”—cause in terms of security?
Several attempts at researching this phenomenon have come to the same conclusion: average users will often intentionally not use things they see someone they perceive as paranoid using. Continue reading
The NSFNET followed the CSNET, connecting the campuses of several colleges and supercomputing systems with a 56K core in 1986. The NSFNET was the first large-scale implementation of Internet technologies in a complex environment of many independently operated networks, and forced the Internet community to iron out technical issues arising from the rapidly increasing number of computers and address many practical details of operations, management and conformance. The NSF eventually became the “seed” of the commercialized core of the Internet, playing an outsized role in the current design of routing, transport, and other Internet technologies.
In this episode of the History of Networking, Dennis Jennings joins Donald Sharp and Russ White to discuss the origins and operation of the NSFNET.
You can find out more about Dennis and the NSFNET in the following links.
https://internethalloffame.org/inductees/dennis-jennings
https://en.wikipedia.org/wiki/National_Science_Foundation_Network
https://www.nsf.gov/news/news_summ.jsp?cntn_id=103050
http://arvidc.weebly.com/nsfnet.html
It’s easy to assume automation can solve anything and that it’s cheap to deploy—that there are a lot of upsides to automation, and no downsides. In this episode of the Hedge, Terry Slattery joins Tom Ammon and Russ White to discuss something we don’t often talk about, the Return on Investment (ROI) of automation.
I cannot count the number of times I’ve heard someone ask these two questions—
While these questions have always bothered me, I could never really put my finger on why. I ran across a journal article recently that helped me understand a bit better. The root of the problem is this—what does best common mean, and how can following the best common produce a set of actions you can be confident will solve your problem?
Bellman and Oorschot say best common practice can mean this is widely implemented. The thinking seems to run something like this: the crowd’s collective wisdom will probably be better than my thinking… more sets of eyes will make for wiser or better decisions. Anyone who has studied the madness of crowds will immediately recognize the folly of this kind of state. Just because a lot of people agree it’s a good idea to jump off a cliff does not mean it is, in fact, a good idea to jump off a cliff.
Perhaps it means something closer to this is no worse than our competitors. If that’s the meaning, though, it’s a pretty cynical Continue reading