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—
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
The Hedge Podcast #60: Ben Andresen and Growing Teams
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.
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
The Hedge #59: Dan Blum and Rational Cybersecurity
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.
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.
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
The Dangers of Flying Pigs (RFC1925, rule 3)
There are many times in networking history, and in the day-to-day operation of a network, when an engineer has been asked to do what seems to be impossible. Maybe installing a circuit faster than a speeding bullet or flying over tall buildings to make it to a remote site faster than any known form of conveyance short of a transporter beam (which, contrary to what you might see in the movies, has not yet been invented).
One particular impossible assignment in the early days of network engineering was the common request to replicate the creation of the works of Shakespeare making use of the infinite number of monkeys (obviously) connected to the Internet. The creation of appropriate groups of monkeys, the herding of these groups, and the management of their output were once considered a nearly impossible task, similar to finding a token dropped on the floor or lost in the ether.
This problem proved so intractable that the IETF finally created an entire suite of management tools for managing the infinite monkeys used for these experiments, which is described in RFC2795. This RFC describes the Infinite Monkey Protocol Suite (IMPS), which runs on top of the Internet Protocol, the Continue reading
Strong Reactions and Complexity
In the realm of network design—especially in the realm of security—we often react so strongly against a perceived threat, or so quickly to solve a perceived problem, that we fail to look for the tradeoffs. If you haven’t found the tradeoffs, you haven’t looked hard enough—or, as Dr. Little says, you have to ask what is gained and what is lost, rather than just what is gained. This failure to look at both sides often results in untold amounts of technical debt and complexity being dumped into network designs (and application implementations), causing outages and failures long after these decisions are made.
A 2018 paper on DDoS attacks, A First Joint Look at DoS Attacks and BGP Blackholing in the Wild provides a good example of causing more damage to an attack than the attack itself. Most networks are configured to allow the operator to quickly configure a remote triggered black hole (RTBH) using BGP. Most often, a community is attached to a BGP route that points the next-hop to a local discard route on each eBGP speaker. If used on the route advertising the destination of the attack—the service under attack—the result is the DDoS attack traffic no longer Continue reading
The Hedge Podcast #58: Michael Kehoe and eBPF
Most packet processing in Linux “wants” to be in the kernel. The problem is that adding code to the kernel is a painstaking process because a single line of bad code can cause havoc for millions of Linux hosts. How, then, can new functionality be pushed into the kernel, particularly for packet processing, with reduced risk? Enter eBPF, which allows functions to be inserted into the kernel through a sort of “lightweight container.”
Michael Kehoe joins Tom Ammon and Russ White to discuss eBPF technology and its importance.
The History of Networking: John Chapman and Cable Networks
Before the large cable providers came on the scene, most people accessed the Internet through dial-up MODEMS, connecting to services like America Online, across plain old telephone lines. The entrance of cable providers, and cable MODEMs, allowed the edge of the Internet to explode, causing massive growth. Join Donald Sharp and I on this episode of the History of Networking as John Chapman discusses the origins of the cable MODEM, and the origins of the DOCSIS standards.
Random Thoughts on IoT
Let’s play the analogy game. The Internet of Things (IoT) is probably going end up being like … a box of chocolates, because you never do know what you are going to get? a big bowl of spaghetti with a serious lack of meatballs? Whatever it is, the IoT should have network folks worried about security. There is, of course, the problem of IoT devices being attached to random places on the network, exfiltrating personal data back to a cloud server you don’t know anything about. Some of these devices might be rogue, of course, such as Raspberry Pi attached to some random place in the network. Others might be more conventional, such as those new exercise machines the company just brought into the gym that’s sending personal information in the clear to an outside service.
While there is research into how to tell the difference between IoT and “larger” devices, the reality is spoofing and blurred lines will likely make such classification difficult. What do you do with a virtual machine that looks like a Raspberry Pi running on a corporate laptop for completely legitimate reasons? Or what about the Raspberry Pi-like device that can run a fully operational Continue reading
This is totally random … The Art of Charity
I don’t normally do this, but … I’d like to share a couple of images of watercolors by a friend of mine. She really does do whimsical and impressive work. Links to her site off the images below.
The Hedge Podcast #57: Brian Trammell and PANRG
Brian Trammell joins Alvaro Retana and Russ White to discuss the Path Aware Research Group in the IRTF. According to the charter page, PANRG “aims to support research in bringing path awareness to transport and application layer protocols, and to bring research in this space to the attention of the Internet engineering and protocol design community.”