Networking Humor

July 15, 2013 | InfoWorld

Born or made, network admins share certain defining characteristics. Here are but nine

A few years ago, I wrote a somewhat tongue-in-cheek piece detailing nine traits of the veteran Unix admin. It enjoyed quite a reception and sparked all kinds of debate across the Internet, with people discussing each trait point by point and sparking skirmishes between rival factions. Since then, I've thought about giving network admins the same treatment, but never got around to it. It seems that this is the week. Here are a few of the many traits of the veteran network admin.

Veteran network admin trait No. 1: We already know it's down
Few things are more annoying than having your phone blow up with automated alert messages from your monitoring systems, scrambling to dig into the issue, only to be continually bombarded with humans texting/talking/emailing/calling with the same "Is x down?" question, or even worse, "The network's down!" If the outage is significant, we already know about it, and we are trying to work on it as fast as we possibly can. Continued attempts to deliver elderly information will only impede that effort.

Veteran network admin trait No. 2: If we don't know it's down, it's probably not down
Conversely, if we get a message claiming, "The network's down!" yet we have not been notified by any monitoring system, then the problem is almost certainly the complaining user in question. To users, if there is any resource that cannot be contacted, whether that resource is internal to the network, on the Internet, or perhaps orbiting the earth, that means the network is "down." This apparently includes 404 errors from shady websites, mistyped URLs, or the lack of any sort of network connection on the user's laptop. Nothing is more grating to a network admin than someone claiming the network is "down." No, it isn't -- reboot your laptop.

Veteran network admin trait No. 3: We will ping and test several times before digging into the problem

If we begin looking into a problem, especially across a WAN or long-haul link with several providers in the middle, we will reserve judgment for the first several minutes. This is because these connections are subject to the vagaries of their path, and connectivity problems can come and go like ghosts in the night. A fiber WAN link that was stable a minute ago but is now exhibiting 30 percent packet loss will more than likely fix itself in short order. Only after a probationary period will we start digging deeper into the issue.

Veteran network admin trait No. 4: Believe it or not, we've tried turning it off and back on again

Many times, we will "fix" a problem by turning an interface off and back on again. In fact, this may be the first thing we try when troubleshooting an issue. Whether it's a problem with auto-negotiation, a sketchy cable, or sunspots, you'd be surprised at how often dropping and restarting an interface will restore proper operation. While networking may be a science, it's not without its white whale.

Veteran network admin trait No. 5: During an outage, we're not just staring at the screen -- we're following a path in our heads

If you come across a network admin working on a problem, looking at a routing table with a 1,000-yard stare, he's not experiencing performance anxiety or somehow "lost." He's running through dozens of possible scenarios in his head, following the routing and switching paths, and calculating possible problem scenarios. The uninitiated can't quite grok the way a network admin's mind works, but a parallel might be to imagine an intangible maze, then try to solve it. Somewhere in that maze lies a dead end that shouldn't be there. We're looking for that -- then we can take steps to open up the path again.

Veteran network admin trait No. 6: We calculate subnet masks and CIDR as easily as breathing

I think it's safe to say that perhaps outside of the common Class C netmask, the overwhelming majority of humans do not understand subnetting, or CIDR. For network admins, this is as intrinsic and involuntary to our brain as breathing. It's not just knowing that a /28 is a netmask of 255.255.255.240, and that it describes 16 addresses, 14 usable, or where subnet boundaries lie. It's the ability to collapse large numbers of smaller subnets into larger descriptors in order to reduce routing table sizes, ACL applications, and a wide variety of other internal networking tasks. When we see contiguous networks sliced into smaller chunks in an ACL, yet with identical rules applied, we get agita. A /19 is a much better idea than a collection of /24s. The same applies to wildmasks.

Veteran network admin trait No. 7: We do not tolerate bugs; they are of the devil

On occasion, conventional troubleshooting or building new networks run into an unexplainable blocking issue. After poring over configurations, sketching out connections, routes, and forwarding tables, and running debugs, one is brought no closer to solving the problem. This is the unholy area of networking inhabited by the software bug. Network admins think of switching and routing software bugs as personal attacks, and they will usually excoriate a vendor when one is discovered. This is because before the determination is made that the problem is due to a bug, nothing makes sense whatsoever. It completely violates years of experience and knowledge, throws waste to logic, and causes immense amounts of stress and turmoil. You might think of it as if you spontaneously transmogrified into a difference species. Everything you've ever known suddenly does not apply, yet here you are.

Veteran network admin trait No. 8: We can read live packet streams and write highly complex filters in our sleep

Few items in networking and computing are even remotely similar to how they're portrayed on TV and in movies. The terminal window with text rapidly scrolling past, however, is one of them. In the sys admin world, that's usually a log file tail. In the networking world, it's usually a packet dump. Depending on what we're trying to do, we may quickly call up a packet capture on a live circuit and watch packets fly by in real time. It's not gibberish. We're looking for telltale signs, and we'll winnow down our capture using filters until we've found what we're looking for. Speed is usually of the essence in these cases, so we're well versed in BPF filtering syntax. Also, we tend to notice really strange things like IP headers that "just don't look right" and other oddities that may as well be alphabet soup to most people. Some people speak Klingon. We speak IP.

Veteran network admin trait No. 9: We take big risks all the time

Network admins tend to work on many remote devices. Unlike server admins who can pull up a console if the server is otherwise inaccessible via the network, we usually have no such luxury. This means that changes we make to certain devices carry with them the ever-present threat of the loss of connection. Basically, we're always a missed keystroke or two away from making a problem worse, or causing a big problem where none previously existed.

While making a change to a remote switch and applying that change to port 34 instead of port 35, say, we could inadvertently cause a complete lack of connectivity to the remote site, taking who knows what offline until the device is power-cycled or we -- or worse, someone else -- drive over to fix it manually. Ideally, this shouldn't happen in the middle of the night, but given the usual timing of network maintenance windows, it often does. Oh, and we sometimes have to make changes to remote devices knowing that if anything goes slightly wrong, we will lose connectivity -- such as when changing Internet providers at a remote site and reconfiguring the firewall with a script because we have no other persistent connection to it. We live with this understanding all day, every day.

I hope that this insight into the extremely logical, yet consistently dangerous world of the network admin has shed some light on how we work and how we think. I don't expect it to curtail the repeated claims of the network being down, but maybe it's a start. In fact, if you're reading this and you are not a network admin, perhaps you should find the closest one and buy him or her a cup of coffee. They could probably use it.

This story, "Nine traits of the veteran network admin," was originally published at InfoWorld.com. Read more of Paul Venezia's The Deep End blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.

[ Also on InfoWorld: Nine traits of the veteran Unix admin | How to become a certified IT ninja | Get expert networking how-to advice from InfoWorld's Networking Deep Dive PDF special report. | Subscribe to InfoWorld's Data Center newsletter to stay on top of the latest developments. ]

Todd's Humor Archive

Newsgroups: rec.humor.funny
From: [email protected] (Mike ``Hammer'' Hammond)
Date: Wed, 5 Mar 97 19:30:02 EST

********************************* * * * Cyberwocky * * * *********************************

(With Apologies to Lewis Carroll)

'Twas e-mail, and the ftp Did route and telnet to the node. All rlogin to Xterms free To let gopher download.

``Beware the Internet, my son! The posts that spam, the speech that's free! Beware the Netscape cache, and shun The AOL mail id!''

He took his HP mouse in hand. Long time a higher bandwidth sought -- And wished had he for his old PC A faster modem bought.

And, as that wistful thought he gripped, The Internet, with bait of flame, Ran applets through the Javascript, And mailbombed as it came!

The war he waged! As on each page The HP mouse he double-clicked! And 'twas absurd, the hype he'd heard 'Bout sites that he had picked.

``And, hast thou surfed the Internet? Come link my page, my newbie bud! O Lycos night! Yahoo! Excite!'' He messaged on his MUD.

'Twas e-mail, and the ftp Did route and telnet to the node. All rlogin to Xterms free To let gopher download.

by Mike ``Hammerwocky'' Hammond

(First appeared in Volume 71, Issue 4 of mathNEWS, the University of Waterloo Faculty of Mathematics student newsletter/humour publication. Check us out at http://www.undergrad.math.uwaterloo.ca/~mathnews Submitted with permission of authour --- me!)

RFC 1925 The Twelve Networking Truths by R. Callon

It Has To Work.
No matter how hard you push and no matter what the priority, you can't increase the speed of light. (2a) (corollary). No matter how hard you try, you can't make a baby in much less than 9 months. Trying to speed this up *might* make it slower, but it won't make it happen any quicker.
With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead.
Some things in life can never be fully appreciated nor understood unless experienced firsthand. Some things in networking can never be fully understood by someone who neither builds commercial networking equipment nor runs an operational network.
It is always possible to aglutenate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea.
It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it. (6a) (corollary). It is always possible to add another level of indirection.
It is always something (7a) (corollary). Good, Fast, Cheap: Pick any two (you can't have all three).
It is more complicated than you think.
For all resources, whatever it is, you need more. (9a) (corollary) Every networking problem always takes longer to solve than it seems like it should.
One size never fits all.
Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works. (11a) (corollary). See rule 6a.
In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away.

rfc3252 Binary Lexical Octet Ad-hoc Transport.

This document defines a reformulation of IP and two transport layer protocols (TCP and UDP) as XML applications.

RFC3251Electricity over IP

Mostly Pointless Lamp Switching (MPLampS) is an architecture for carrying electricity over IP (with an MPLS control plane). According to our marketing department, MPLampS has the potential to dramatically lower the price, ease the distribution and usage, and improve the manageability of delivering electricity. This document is motivated by such work as SONET/SDH over IP/MPLS (with apologies to the authors). Readers of the previous work have been observed scratching their heads and muttering, "What next?". This document answers that question.

Softpanorama May the source be with you, but remember the KISS principle ;-)	Home	Switchboard	Unix Administration	Red Hat	TCP/IP Networks	Neoliberalism	Toxic Managers
	(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix

Humor Chronicle	RMS	Linus Torvalds	Larry Wall & Perl	Top 10 Classic Unix Humor	Softpanorama Humor Archive
C	Assembler	Perl	Shell	Java	GPL	Debugging
Admin	Algorithms	Networking	Solaris	Windows	Linux	Office
skeptical humor	OFM Humor	SE	vi	Viruses	Eric Raymond	outsourcing