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 Monitoring



Find more PRO+ content and other member only offers, here.

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Do you think the era of the network engineer is over?
No, I don't. However, I do think the job will be changing a little. I expect to see larger companies retaining people with this skill set, simply because they have their own internal networks that need to be run, and data centers hosting cloud-based services will almost certainly need to keep a number of engineers on staff. If nothing else, they'll need to have in-house experts to guide new companies through the setup and connection process.
Thanks for your note, Jamesz243
Even with Virtual networks and with abstraction applied at so many levels, there needs to be someone who will be able to untangle issues and architect solutions. It may not require as much "cable monkey" skills as the past (and please note, I'm not using the term cable monkey disparagingly, I was one at the start of my career and am hugely proud of that fact ;) ), but I do think the ability of understanding how all the pieces fit together will require real network engineers for quite some time to come.
The move in network monitoring is currently going towards automation. It's unlikely that SNMP will ever go anywhere, but the admin needs less and less technical knowledge every year, at least to get by. Something like NetCrunch ( is built around ease of use and automation, and once the first hurdle of installation and permissions is cleared, the actual usage becomes easier.
Depends on how you define monitoring. If everything stays at layer 3, I mostly agree with this article. But networking/monitoring is moving up the stack.