Welcome!

Linux Authors: Pat Romanski, Elizabeth White, Carmen Gonzalez, Hovhannes Avoyan, Imran Akbar

Related Topics: SDN Journal, Java, Linux, Virtualization, Cloud Expo, Big Data Journal

SDN Journal: Blog Feed Post

What a Network Engineer Does

Network Engineering workflow can be characterized by overlapping cycles of Activity and Modeling

In a previous article, we talked about “Short T’s.”  We talked about how, in network engineering, the “T” is very long:  Configuring a network to achieve business goals requires considerable skill and knowledge.  While we set up a conceptual model in that post to talk about what “T” means in general terms, we did not discuss in detail how to articulate “T” more specifically for network engineering.  In this post, we’ll explore this in a little more detail.

The NetEng Cycle

Figure 1: The Network Engineering Cycle

Network Engineering workflow can be characterized by overlapping cycles of Activity and Modeling.  In figure 1, I have depicted 4 cycles.  From smallest timescale to largest, these are called:  1. Referential Traversal, 2. Interactive, 3. Design, and 4. Architecture.  The crest of each of these cycles is “Activity” and the trough is “Modeling.”  Modeling on the smaller cycles is simple and correlative, while on the larger cycles it is more abstract and analytical.  Activity on the smaller cycles is characterized by direct interactivity with the network, while on larger scales it is indirect and more design oriented.

As is implied from the diagram, a network engineer will oscillate between activities and modeling.  For instance, in the interactive cycle, they may configure a QoS classification policy, but then immediately issue show commands to see if traffic is being classified appropriately.  Configuring a policy and issuing of show commands are activities, but the show commands start to transition into modeling.  The engineer is attempting to model the immediate effect of the changes they have made.  Based on this modeling of “how things are,” the engineer might start thinking about modifications to the classification policy to bring the operation of the network closer to an expected model of “how things should be.”  As far as it is possible to do so, an attempt might be made to model “how things will be” to check for possible side effects.  The cycle, then, repeats.

Referential Space
However, which show commands should they use to accurately model how the configuration is actually working?  If you were to write down the exact sequence of commands, you might find that the engineer is taking data from the output of the first command and using that as either input into the second command, or as a point of reference while examining output from the second command.  The output from the second command might be, in turn, used similarly when executing a third show command.  This is what is called Referential Traversal.  Referential Traversal is when a network engineer engages in iterative data correlation in support of a workflow.  In the context of a workflow, this data represents that workflow’s state.

Another well known referential traversal is doing a manual packet-walk of the network:  Examining nodes along the way to determine if there is a potential issue along the path between two endpoints on the edge of the network.  Here, the engineer will examine lookup tables, arp entries, and LLDP neighbor information, jumping from one node to the next.  This particular workflow can tangent in tricky ways such as examining when and what configuration changes were made to see if they could impact traffic between those two endpoints.  When tangenting into examination of a device configuration, you enter a different set of correlated data:  A route-map applied to an interface can, in turn, reference access-lists or prefix-lists.  The rules for evaluating packet flow through a policy follows different logic than the general rules for packet flow across a series of devices.

Figure 2: Referential Space

Figure 2: Referential Space

If you take the set of rules, relationships, and data points from “configuration space” and the rules, relationships, and data points from the “forwarding space,” and you combine them with all other such spaces that a network engineer must deal with in the course of their activities, the sum of these is called “referential space” (See Figure 2).  A network engineering workflow will follow some referential path through this space, examining data and following it’s relationships to yet other data.  There are numerous interconnected spaces in the management, control, forwarding, and device planes of a network each with their own logic and types of data. There are more abstract spaces as well, such as a “design” space that contains the rules and relationships that govern network design.  A network engineer’s expertise is measured by how well they can navigate referential space in support of longer time-scale cycles.

Enablement versus Obviation
The challenge of networking, and the reason that automation (and UX/UI for that matter) has not evolved terribly well, is that these referential paths vary greatly based on what the network engineer is trying to do and how a particular network is built.  There is a vast set of rules governing the many relationships that exist between the seemingly infinite array of data types.  The dynamic nature of referential traversal, and the intimidating size of referential space, should justify a healthy skepticism of vendors claiming to encapsulate network complexity or automate network workflows.  More often than not, they are simply moving the complexity around, while making it more difficult to navigate in the process.

It’s long since overdue to move innovation in networking towards enabling network engineers to be more effective instead of trying to obviate them.  Unlike the past, this should happen with a keen understanding of what network engineers actually do and how they think through their activities.  We can augment these activities to reduce time-to-completion, and reduce time-to-insight while at the same reducing risk and increasing accountability.  There are many networking workflows, which after 20 years, are still notoriously difficult and risky to model and complete.  Let’s solve these problems first.

Make Things Better
As a network engineer, how many times have you heard about the glorious wonders of a product that automates networking or encapsulates network complexity in some way?  After 20 years, we have been trained to identify this language as snake-oil, or perhaps a little nicer, “marketing speak.”  When we buy into these products or features, it’s always just a matter of time before they go unused, or the ugly realities of their operation surfaces.

Encapsulating network complexity, or automating network workflows, can’t just be about “faster.”  That’s only part of the problem.  It has to make things “better.”  This can only happen with a deeper understanding of referential space.

The post What a Network Engineer Does appeared first on Plexxi.

Read the original blog entry...

More Stories By Derick Winkworth

Derick Winkworth has been a developer, network engineer, and IT architect in various verticals throughout his career.He is currently a Product Manager at Plexxi, Inc where he focuses on workflow automation and product UX.