Russ

Author Archives: Russ

On the ‘web: How to Bridge the Network Skills Gap

The landscape is littered with training for all these new skills, but there is little time, or guidance, through the process of retraining into these new skills. The process of retraining, far too often, feels like leaving all your old skills behind and learning completely new ones. The seeming wide array of paths the average engineer faces, combined with the uncertainty of which of these paths forward represent the real future, can seem overwhelming. @TechTarget

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 positive feedback loop leading to a failure. We describe positive feedback loops in Computer Networking Problems and Solutions, and in Navigating Network Complexity, but clear cut examples are hard to find in the wild. Feedback loops almost always contribute to, rather than independently cause, failures.

Many years ago, in a network far away, I was called into a case because EIGRP was failing to converge. The immediate cause was neighbor flaps, in turn caused by Stuck-In-Active (SIA) events. To resolve the situation, someone in the past had set the SIA timers really high, as in around 30 minutes or so. This is a really bad idea. The SIA timer, in EIGRP, is essentially the amount of time you are willing to allow your network to go unconverged in some specific corner cases before the protocol “does something about it.” An SIA event always represents a situation where “someone didn’t answer my query, which means I cannot stay within the state machine, so I Continue reading

Weekend Reads 040618: Kernel Programming, Secure Messaging, and Icebergs

Programming in user space is safer for a very small number of reasons, not the least of which is the virtual memory system, which tricks programs into believing they have full control over system memory and catches a small number of common C-language programming errors, such as touching a piece of memory that the program has no right to touch. Other reasons include the tried-and-true programming APIs that operating systems have now provided to programs for the past 30 years. All of which means programmers can possibly catch more errors before their code ships, which is great news—old news, but great news. What building code in user space does not do is solve the age-old problems of isolation, composition, and efficiency. —George V. Neville-Neil @ACM

There is no such thing as a perfect or one-size-fits-all messaging app. For users, a messenger that is reasonable for one person could be dangerous for another. And for developers, there is no single correct way to balance security features, usability, and the countless other variables that go into making a high-quality, secure communications tool. @EFF

Breaches of private information in hospital records are serious and expensive security events but remediating them can be deadly. Continue reading

On the ‘net: Openness and Composable Systems

Openness, it seems, is “in the air.” While the Liqid folks were over at OCP, I was over at the Open Networking Summit (ONS), where I (primarily) attended the Linux Foundation (Networking), or LF(N), board meeting. What was interesting at this year’s summit is just how little the focus of open network is on bare metal routers and switches, and how much of the focus is on server-based and overlay networking. @GestaltIT

Reaction: The NRE as the new architect

Over at the Packet Pushers, Anthony Miloslavsky suggests that network architects have outlived their usefulness, so it is time to think of a new role. He describes a role called the “NRE” to replace the architect; the NRE would—

…spend no less than 50% of their time focusing on automation, while spending the other 50% deeply embedded in the operations/engineering/architecture realms of networking. They participate in an on-call rotation to stay in touch with the ops side of the house, with a focus on “treating operations as if it’s a software problem” in response. NREs would provide a expert big picture view of BOTH the development/automation and network operation/design sides of the house.

The author goes on to argue that we need someone who will do operations, engineering, architecture, and development because “pure architecture” folks tend to “lose touch” with the operations side of things. It is too easy to “throw a solution over the cubicle wall” without considering the implementation and operational problems. But, as a friend used to ask of everything when I was still in electronics, will it work? I suspect the answer is no for several reasons.

First, there is no such person as described, and Continue reading

1 … 60 61 62 63 64 … 162