How to be a [good] Network Engineer (and network engineer appreciation day)

My personal background in computing (specifically networking) is atypical.  I have a bachelors in visual arts and only took a handful of computing classes in my relatively long tenure in college.  However, I did learn one valuable lesson that has served me pretty well over the 15 or so years I have been doing networking and I’d bet money any good network engineer that has more than 10 years of experience will nod their head at this and agree.
A really good Network Engineer knows enough about any discipline to successfully function in that role.
A network engineer is the “grout” of nearly every place I have ever worked.  They fill in all the gaps left behind by departures, lack of funding or just general need.  It takes a certain kind of personality to be a good one and when you find a good one, you should keep them, they’re hard to come by.
As an example, in the course of my career, it has been necessary for me to:
1. Be a UNIX and Linux sysadmin.  This includes such things as:

a. being a mail server admin

b. maintaining web servers

c. running monitoring systems

d. administrating virtual machine hosts (and guests)

e. creating, managing, troubleshooting and upgrading DNS and DHCP servers

2. Function as a network security policy writer

3. Act in a desktop support role
4. Modify, debug and create code.
5. Work as a windows server admin
6. Perform as a network security engineer (evaluate, install, debug and maintain firewall, IDS, IPS and VPN devices and platforms)
7. Install, test and debug physical infrastructure such as inside and outside plant fiber and copper.
8. Act as a facility coordinator for power, heat and cooling
9. Test, evaluate and maintain phone systems, PBX, CentrEx and VoIP
10. Aid in the creation of grant proposals
11. Present as a subject matter expert to internal and public audiences
12. Operate as a trusted source of knowledge on nearly everything IT related (and if we don’t know, we find out).
13. Oh yeah, keep the network running by having intimate knowledge of networking equipment like routers, switches, customer provisioning gear, DWDM equipment and the interfaces and protocols that make them work.
That is just scratching the surface…..and I absolutely love what I do.  The packet pushers said it well.  “Too much networking would never be enough”.
For all of the up and coming network engineers [and the seasoned veterans, too], I offer this bit of unsolicited advice:
Don’t be a Luddite.
Love what you do.  In IT the only constant is change.  Embrace it.  Learn new technology.  Think outside of the box and step outside of your comfort zone.  Never be comfortable with “good enough”.  Strive to know more about whatever it is you are working on.  Be positive.  Help others learn.  Don’t worry about credit and recognition and just do great work, if you do the rest will work itself out.
This post is my ode to the network engineer.  On Network Engineer appreciation day (which should be a thing.  if it doesn’t exist, I decree it is every November 12th), think of these things and remember that even if no one remembers network engineer appreciation day, we’ll still keep the packets moving and fill in the rest of the gaps too.
Cheers.
 
 

7 thoughts on “How to be a [good] Network Engineer (and network engineer appreciation day)

  1. So what you might be saying is: many times network engineers are born out of necessity because nobody else wanted to do the job or enough of a generalist, curious and/or intrigued enough to take action or even understand the networking problems.
    I’ve always called myself a problem solver or even a debugger first, network engineer is just part of my job. When people can’t figure out for themselves what is going I get called in to solve the problem.
    So this makes a lot of sense to me.
    On the point of too much networking would never be enough. Well, I have a feeling there is going to be a lot more networking because the hosts at the edge are going to perform more and more networking tasks.
    It used to be pretty much the only distributed networking protocol that the edge participated in was TCP (the distributed algorithm and protocol to fairly share the available bandwidth).
    But now we are seeing: more sensors, more mobile, Multi Path-TCP and overlay networking, sometimes combined with switching, firewalling, loadbalancing and routing. And even WebRTC (a peer2peer protocol for browsers and other applications that want to exchange: audio, video and data).
    So there will be a lot more devices in the network practicing more networking tasks and it’s all based on the IP protocols. The people at the FCC are saying PSTN is going the way of the dodo. It’s all IP-based. That means everything will depend on IP.
    For example did you know LTE is IP-based, for everything, including voice ? And did you know the encryption protocol for the signaling and data protocol is IPSEC ? Even more interesting: did you know that IPSEC for LTE is optional ?

  2. “Problem solver” is a very apt description of a good network engineer. Those are the ones that you want to keep around.
    I actually had no idea that LTE was all IP. I think that’s great. I also love that most of the LTE networks are now IPv6 dual stacked.

  3. What I’m always surprised about is that sometimes you talk to people who do only routing at large providers also only know routing.
    Like some Microsoft Exchange admin that only knows Microsoft Exchange and nothing about Windows.
    Most of the other networking people I have interacted with have a lot broader interests.

  4. On broad interests, what has me really excited right now is: Linux containers like Docker and for some strange reason WebRTC (well, only slightly strange, because I’m a webguy too).
    I’m thinking, maybe, just maybe, I can use more Linux routing on our network: http://containerops.org/2013/11/19/lxc-networking/
    Not Docker specifically, or even containers, but network namespaces. Network namespaces in Linux supports: forwarding, bridging, static routing and dynamic routing (for example Quagga), iptables, looks like it even supports iptables conntrackd and even IPSEC.
    Think about it, in the data center you should be deploying small, per application VMs and networks:
    http://blog.ipspace.net/2013/11/typical-enterprise-application.html
    http://blog.ipspace.net/2013/11/make-every-application-independent.html
    What have we learned from the Internet and ‘cloud’: stateless scales.
    So I’m thinking about playing with: deploying network namespaces.

    1. I think this makes a lot of sense. Principals like KISS are as valid today as they were 15 years ago, see Ivan’s post. Name spaces are a logical next step in simplifying things like simplification of service deployment. Scott Lowe has a great write up on it, and it looks like we have both commented on it.
      It’s a logical part of a larger migration of how networking as a whole is done in my humble opinion.

    2. There is a reason that wasn’t mentioned to keep it KISS is it makes it easier to automate, because KISS is more predicatable.

Comments are closed.