Russ
Author Archives: Russ
- Home → Author's archive:
Russ
The Hedge Podcast 51: Tim Fiola and pyNTM
Have you ever looked at your wide area network and wondered … what would the traffic flows look like if this link or that router failed? Traffic modeling of this kind is widely available in commercial tools, which means it’s been hard to play with these kinds of tools, learn how they work, and understand how they can be effective. There is, however, an open source alternative—pyNTM. While this tool won’t replace a commercial tool, it can give you “enough to go on” for many network operators, and give you the experience and understanding needed to justify springing for a commercial product.
It Has to Work
From time immemorial, humor has served to capture truth. This is no different in the world of computer networks. A notable example of using humor to capture truth is the April 1 RFC series published by the IETF. RFC1925, The Twelve Networking Truths, will serve as our guide.
According to RFC1925, the first fundamental truth of networking is: it has to work. While this might seem to be overly simplistic, it has proven—over the years—to be much more difficult to implement in real life than it looks like in a slide deck. Those with extensive experience with failures, however, can often make a better guess at what is possible to make work than those without such experience. The good news, however, is the experience of failure can be shared, especially through self-deprecating humor.
Consider RFC748, which is the first April First RFC published by the IETF, the TELNET RANDOMLY-LOSE Option. This RFC describes a set of additional signals in the TELNET protocol (for those too young to remember, TELNET is what people used to communicate with hosts before SSH and web browsers!) that instruct the server not to provide random losses through such things as “system crashes, lost data, Continue reading
Understandability
According to Maor Rudick, in a recent post over at Cloud Native, programming is 10% writing code and 90% understanding why it doesn’t work. This expresses the art of deploying network protocols, security, or anything that needs thought about where and how. I’m not just talking about the configuration, either—why was this filter deployed here rather than there? Why was this BGP community used rather than that one? Why was this aggregation range used rather than some other? Even in a fully automated world, the saying holds true.
So how can you improve the understandability of your network design? Maor defines understandability as “the dev who creates the software is to effortlessly … comprehend what is happening in it.” Continuing—“the more understandable a system is, the easier it becomes for the developers who created it to change it in a way that is safe and predictable.” What are the elements of understandability?
Documentation must be complete, clear, concise, and organized. The two primary failings I encounter in documentation are completeness and organization. Why something is done, when it was last changed, and why it was changed are often missing. The person making the change just assumes “I’ll remember Continue reading
Weekend Reads 090420
Running a bit late this week … 
That said, Intel over the past couple of years has expanded its Continue reading
The Hedge Podcast #49: Karen O’Donoghue and Network Time Security
Time is critical for many of the systems that make the Internet and other operational networks “go,” but we often just assume the time is there and it’s right. In this episode of the Hedge, Karen O’Donoghue joins Alvaro and Russ to talk about some of the many attacks and failures that can be caused by an incorrect time, and current and ongoing work in securing network time in the IETF.
The Hedge Podcast #50: The Challenge of Growing People
Many network engineers complain about their companies not giving them opportunities—but how many think about helping the company grow in a way that allows them to have the opportunities they desire? Scott Morris, aka “evil ccie,” joins Tom and Russ on this episode of the Hedge to talk about the challenges of certifications, growing people, and people learning how to grow in a way what improves the business. Sometimes growing means creating opportunities rather than just waiting for them to knock.
History of Networking: Networking at Google with Richard Hay
Google fascinates network engineers because of the sheer scale of their operations, and their obvious influence over the way networks are built and operated. In this episode of the History of Networking, Richard Hay joins Donald Sharp and Russ White to talk about some past designs and stories of failure and success in one of the world’s largest operating networks.
Webinar: How the Internet Really Works
My next upcoming live webinar on Safari Books is How the Internet Really Works. This was originally a three-hour webinar which I’ve added some material to so it’s now four hours… I’m working with Pearson to add further material and break this into two three-hour webinars, so this will probably be the last four-hour version of this I teach.
Technologies that Didn’t: The Fiber Distributed Data Interface
Token Ring, in its original form, was—on paper—a very capable physical transport. For instance, because of the token passing capabilities, it could make use of more than 90% of the available bandwidth. In contrast, Ethernet systems, particularly early Ethernet systems using a true “single wire” broadcast domain, cannot achieve nearly that kind of utilization—hence “every device on its own switch port.” The Fiber Distributed Data Interface, or FDDI, is like Token Ring in many ways. For instance, FDDI uses a token to determine when a station connected to the ring can transmit, enabling efficient use of bandwidth.
And yet, Ethernet is the common carrier of almost all wired networks today, and even wireless standards mimic Ethernet’s characteristics. What happened to FDDI?
FDDI is a 100Mbit/second optical standard based on token bus, which used an improved timed token version of the token passing scheme developed for token ring networks. This physical layer protocol standard had a number of fairly unique features. It was a 100Mbit/second standard at a time when Ethernet offered a top speed of 10Mbits/second. Since FDDI could operate over a single mode fiber, it could support distances of 200 kilometers, or around 120 miles. Because it was Continue reading
New Livelesson: Understanding Network Transports
Safari Books Online just published my latest Livelesson—eight hours of technical yet fundamental training on network transports. I co-authored this one with Ethan Banks (yes, that Ethan Banks). I consider this video series a compliment to the transport chapters in Computer Networking Problems and Solutions.
If you ever wanted to really understand transport protocols … this is your chance.
The White Board and the Simulation
In the argument between OSPF and BGP in the data center fabric over at Justin’s blog, I am decidedly in the camp of IS-IS. Rather than lay my reasons out here, however (a topic for another blog post?), I want to focus on something else Justin said that I think is incredibly important for network engineers to understand.
I think whiteboards are the most important tool for network design currently available, which makes me sad. I wish that wasn’t true, I want much better tools. I can’t even tell you the number of disasters averted by 2-3 great network engineers arguing over a whiteboard.
I remember—way back—when I was working on the problems around making a link-state protocol work well in a Mobile Ad Hoc Network (MANET), we had two competing solutions presented to the IETF. The first solution was primarily based on whiteboarding through various options and coming up with one that should reduce flooding to an acceptable level. The second was less optimal on the whiteboard but supported by simulations showing it should reduce flooding more effectively.
Which solution “won?” I don’t know what “winning” might mean here, but the solution designed on the whiteboard has Continue reading
The Hedge Podcast 48: Chris Romeo and the State of Security
Chris Romeo is a famous application security expert who has spent the last several years building a consulting and training company called Security Journey. Chris joins Tom and Russ to talk about the state of security and what network engineers need to know about security from an application perspective.
History of Networking: An African Perspective of the Internet
Dawit Bekele began his journey with the Internet while at college—but on returning to Africa, he discovered there was very little connectivity. While he was not involved in the initial stages of engineering the Internet in Africa, he began as an early user and proponent of connecting his home continent, and is now part of the Internet Society, helping to grow connectivity.
Unsolicited Multicast: Random Thoughts on the LFN White Paper
A short while back, the Linux Foundation (Networking), or LFN, published a white paper about the open source networking ecosystem. Rather than review the paper, or try to find a single theme, I decided to just write down “random thoughts” as I read through it. This is the (rather experimental) result.
The paper lists five goals of the project which can be reduced to three: reducing costs, increasing operator’s control over the network, and increasing security (by increasing code inspection). One interesting bit is the pairing of cost reduction with increasing control. Increasing control over a network generally means treating it less like an opaque box and more like a disaggregated set of components, each of which can be tuned in some way to improve the fit between network services, network performance, and business requirements. The less a network is an opaque box, however, the more time and effort required to manage it. This only makes sense—tuning a network to perform better requires time and talent, both of which cost money.
The offsetting point here is disaggregation and using open source can save money—although in my experience it never does. Again, running disaggregated software and hardware requires time and talent, Continue reading
Weekend Reads 081420
The fundamental technologies for creating digital clones of people — text, audio, and video that sound and look like a specific person — have rapidly advanced and are within striking distance of a future in which digital avatars can sound and act like specific people, Tamaghna Basu, co-founder and chief technology officer of neoEYED, a Continue reading
Deterministic Networking and New IP
For those not following the current state of the ITU, a proposal has been put forward to (pretty much) reorganize the standards body around “New IP.” Don’t be confused by the name—it’s exactly what it sounds like, a proposal for an entirely new set of transport protocols to replace the current IPv4/IPv6/TCP/QUIC/routing protocol stack nearly 100% of the networks in operation today run on. Ignoring, for the moment, the problem of replacing the entire IP infrastructure, what can we learn from this proposal?
What I’d like to focus on is deterministic networking. Way back in the days when I was in the USAF, one of the various projects I worked on was called PCI. The PCI network was a new system designed to unify the personnel processing across the entire USAF, so there were systems (Z100s, 200s, and 250s) to be installed in every location across the base where personnel actions were managed. Since the only wiring we had on base at the time was an old Strowger mainframe, mechanical crossbars at a dozen or so BDFs, and varying sizes of punch-downs at BDFs and IDFs, everything for this system needed to be punched- or wrapped-down as physical circuits.