Manage Learn to apply best practices and optimize your operations.

Why monitoring will require a networking engineer

Despite the evolution of networking, monitoring has remained the same. And that's one reason why the role of the network engineer will remain critical.

The last few years have been abuzz with declarations like, "Networking will never be the same," "The role of the network engineer is dead," and, "All network engineers need to learn to code."

I don't buy it, and I'll tell you why: Monitoring and troubleshooting.

Monitoring the network has been largely unchanged in the entirety of my tenure as a networking engineer, which began 18 years ago.

Let's break down how monitoring is performed in a modern network. Keeping track of a production network is no easy task. I have postulated many times in the past that monitoring a network effectively is an order of magnitude more difficult that building one and keeping it running, especially in the carrier and service provider space. There are a few reasons for this, the largest of which is the mechanism for obtaining the data: the Simple Network Management Protocol (SNMP).

SNMP has been around long before I came into the industry and, unfortunately, it will likely be around a lot longer. SNMP provides the foundational elements for both polling for data and pushing events. The problem with SNMP is that it is cryptic. It's also highly interpretable by vendors. It strains network gear with weak CPUs. And if that's not enough, SNMP is clogged by poor and clunky host implementations.

Despite its problems, no reasonable SNMP alternative

Unfortunately, for a typical networking engineer, there is no reasonable alternative to obtain such network performance data as interface counters, error statistics, CPU load, ternary content-addressable memory information or power information. SNMP is the standard. Couple SNMP statistics with SNMP traps, syslog data, Internet Control Message Protocol statistics, latency information and throughput information and you have the foundations of some reasonable network monitoring.

But calling the network engineer function 'dead' is short-sighted, inflammatory, sensationalist and just plain wrong.

So where am I going with this? How does the advent of software-defined networking, DevOps and becoming a developer change network monitoring in the next five to 10 years?

Let's work through some examples. We'll make an assumption that refresh cycles for data centers and LANs are every three to five years and WAN is five to seven. Transport is generally 10.

Example 1. In a given data center, you have a typical leaf-spine deployment. How do you know when a leaf fails? Probably either via a syslog message or an SNMP trap. If the problem occurs at the edge, it may be an OpenFlow message. How does this tie into the existing network operations center (NOC) tools? Will the NOC see a failure? Sure it will, because there is a link with the legacy monitoring and alerting system. Oh, it's a greenfield, you say? Fair statement. Then the NOC will be looking at the controller topology interface. How is that built? I'd wager one of the ways I just mentioned.

Example 2. Service provider MPLS Network is using something like the Border Gateway Protocol Link-State, OpenFlow 1.3 or possibly just in-house developed DevOps tools. How do we know if there is an issue with label switched paths? How are we notified that a dark fiber path has failed over to a redundant path? How does the NOC see it? You got it: SNMP trap, syslog or topology map (and one that's likely based on SNMP).

Coding skills are valuable, but…

DevOps and coding skills are valuable. I had to learn them and so did many others who began their careers before the days of central and comprehensive network management platforms, wireless and SDN controllers, vendor-supported automation systems, and point and click management software. The only real way to get things done was to code and script it yourself.

But calling the network engineer function "dead" is short-sighted, inflammatory, sensationalist and just plain wrong. Fundamental network engineer functions will continue to be necessary for at least another decade, and even then, many of the essential skills, such as the ability to troubleshoot at a low level, will endure.

Even the most seasoned networking engineer is familiar with at least a few of the available management systems, and while the skills and knowledge required to understand and make use of them may fade some, they will not disappear. Yesterday's fundamentals may soften into a less grizzly and weathered CLI hacking expertise, but the need to understand the cogs and gears will persist in at least in a small subset of practitioners.

If anything, engineers who learn to write code only solidifies this skill set. The ingrained need to understand the guts of the network -- the deep, dark corners that others are afraid to look into -- will be embraced by those with the drive and unrelenting urge to understand it all.

With all of that being said, in IT, the only constant is change -- today's boom of SDN and DevOps only proves this. We all need to be adaptable and be able to evolve, or we will eventually go the way of the dodo. And at the core of it all, being open to change is what DevOps is really about.

Next Steps

A DevOps primer

SDN engineering and what you need to know

This was last published in March 2015

Dig Deeper on Network management and monitoring