Russ White recently wrote about IT skills and the need to be more valuable to the business. He also touches on something he’s spilled a lot of ink on in the past: Good engineers think like engineers, not just know all of the commands.
I frequently hear people complain about network engineer interviews that play out like CCIE exams. Random questions like “What does the PSH flag in TCP do”? Or “What commands are required to enable $feature”.
But at the same time interviewers feel at a loss on how to ask questions of candidates that truly tease out their skills and ability to think through problems without absurd scenarios like “How many ping pong balls fit in a 747?”
Having spent my entire career with Cisco (working with IOS and NX-OS), until recently, I never realized there was a difference between the state of a system and the configuration applied to it.
Now that I spend my days in Linux I see there is a difference between the two.
I want to share a story of a recent issue I encountered with a customer. The customer is using Namespaces, which act like a VRF for the management interface. This operates just fine, but in the release the customer is running, 2.1, when you upgrade your interface configuration is lost. In 2.5 a feature was added to backup the configuration, but now I’m in a bit of a Catch-22: I need to upgrade to get my bug fix, but I trigger the bug by upgrading.
I just need to figure out a way to upgrade only that feature before we upgrade the platform.
(Initial Disclaimer: At the time of writing this I work for Cumulus Networks)
A few weeks ago I started at Cumulus Networks doing pre-sales and consulting. My background is almost entirely Cisco based with only a generic user-level knowledge of Linux. I wanted to start a series describing some of the things that have struck me or I’ve struggled with in learning my way around a switch running Cumulus.
In this first post I wanted to describe just what is Cumulus Linux?
A little over a year ago I wrote an article on Cisco.com on how to take the OSPF topology table and turn it into a diagram. The goal of that document was to really show how each LSA interacts and creates a network. What has been missing from that document is how Virtual Links work in this context.
We know every ethernet frame has a source and destination MAC address, but most of us probably don’t think about the third field in the header, the ethertype. In frame or packet headers every field (usually) has a reason for being, the ethertype’s purpose is a surprisingly important one.
In the image below you can see how each protocol presents itself to the routing table (RIB). The RIB uses AD to determine which route to install. But what about how the protocol chooses which route to present to the RIB?