Why You Need A Network Engineer To Monitor?

Despite the evolution of the network, surveillance remains the same. And that's one of the reasons why the role of a network engineer is still important.

 Supervision of the network has changed little during my tenure as a network engineering, which started 18 years ago.

Let's look at how monitoring is done in modern networks. Tracking a production network is not an easy task. In the past, it has been hypothesized that effectively monitoring a network is much more difficult than building and keeping it running, especially in the area of ​​operators and service providers. There are several reasons for this, but the most important is the mechanism to obtain the data: Simple Network Management Protocol (SNMP).

SNMP has been around long before it entered the industry, but unfortunately it can be quite long. SNMP provides the basic building blocks for data polling and event forwarding. The problem with   

Despite That Problem, There Is No Reasonable SNMP Alternative

Unfortunately, there is no reasonable alternative for a typical network engineer to obtain network performance data, such as interface counters, error statistics, CPU load, ternary associative memory information, or power information. SNMP is the standard. The combination of SNMP statistics with SNMP traps, syslog data, Internet Control Message Protocol statistics, latency information, and performance information provides the basis for rational network monitoring.

So where do I go with this? How software defined networks, the advent of DevOps, and becoming a developer will change network oversight in the next 5-10 years.

Let's see some examples. Suppose the data center and LAN update cycles are every 3-5 years and the WAN is 5-7. Transportation is usually 10.

Example 1. A particular data center has a typical backbone implementation. How do you know when a sheet is broken? It will probably use syslog messages or SNMP traps. If the problem occurs at the edge, it could be an OpenFlow message. How does this relate to existing Network Operations Center (NOC) tools? Will the NOC fail? It is certainly because there is a link to the legacy monitoring and alert systems. Oh do you think it is a green field? Fair Statement The NOC then examines the controller topology interface. How is built? Bet one of the methods we just mentioned.

Example 2. The MPLS network of a service provider uses the link state of the Border Gateway Protocol, OpenFlow 1.3 or internally developed DevOps tools. How do I know if I have a problem with tag change paths? How do I report that a dark fiber route has failed a redundant route? How does the NOC see it? Good: SNMP traps, syslogs, or topology maps (and most likely SNMP-based).

Coding Skills Have Some Value, But ...

DevOps and coding skills are valuable. I need to learn them, as well as many others who started their careers before the era of core and comprehensive network management platforms, wireless and SDN controllers, vendor-compatible automation systems, point-and-do management software click. I have learned. The only real way to do things was to code it and write it yourself.

However, calling the role of a network engineer "dead" is short-sighted, inflamed, sensational, and false. The basic functionality of the Network Engineer is required for at least another decade and still retains many of the basic skills, including the ability to troubleshoot at a low level.

Even the most experienced network engineers are familiar with at least some of the management systems available, and some of the skills and knowledge required to understand and use them may disappear, but disappear. It is not. Yesterday's fundamentals could be softened to a less grizzly and less eroded CLI hacking experience, but the need to understand gears and gears persists for at least some practitioners.

If anything, engineers learning to write code only solidify this skill set. The deep-seated need to understand the root of the web, the deep, dark corners that others fear to look at, is welcomed by those with a compelling urge to understand everything.

With all this in mind, the only constant element of IT is change. The rise of SDN and DevOps today just proves this. We all need to be adaptable and capable of evolution. Otherwise, you will end up on the path of the dodo. And at the heart of it all, being open to change is the true purpose of DevOps.