At least once during a heavy network configuration or troubleshooting session, some onlooker gets a quizzical look and says something to the effect of, "Gee, that seems really complicated. Isn't there an easier way?"
More often than not, this occurs while I'm knee deep in a pile of ssh or telnet sessions to various routers, switches, or firewalls, and keeping a few dozen variables in my head. "No," I reply, "there isn't."
You might think, at this point in time, we'd have magical GUI interfaces and wizard-driven configuration elements that would let any random person properly configure OSPF tunneling through GRE, EIGRP redistribution, and BGP peering. I mean, they've been around for ages -- shouldn't they be much simpler to manage now? The answer is obvious to network admins: If every network was identical, then yes, that would be fine. Reality dictates otherwise.
The power of these protocols and tools is in their scope and range of application. You can do things with Cisco IOS that even the folks at Cisco never really considered; at the configuration level IOS is a programming language, not simply a switching or routing platform. The reason the Linux kernel is written in C, not a VPL (visual programming language), is the same reason there isn't a stem-to-stern usable GUI for heavy routing and switching configurations. Sure, there are SNMP-based tools that make it simple to switch the VLAN assignment of a switchport or add translations and rules to a firewall, but they can go only so far. Inevitably, they run up against the wall of what they've been built to handle versus what is actually possible via the underlying OS.
It's not just fresh configurations that go beyond what these tools can handle; debugging and troubleshooting established networks tend to demand even more understanding and skill. There's no such thing as Clippy for heavy routing problems or even for simple problems like a misconfigured link in an LACP bundle. In short, there's no safety net for network configurations. There's no handy IDE that would somehow know you've transposed two numbers in an OSPF network statement, which is causing routing protocol failures at a remote site.
None of this is news to network administrators, but it's shocking to the uninitiated. For some reason, many people think that configuring a 9-slot core switch or constructing an MPLS network works the same way as configuring their Netgear home router's Wi-Fi parameters. In some cases, I've even heard rumblings that network administrators "make it seem harder than it is" in order to ensure job security. While I'm sure it's happened from time to time, I can assure you the vast majority of network administrators working through enormous packet traces to determine why traffic on a WAN link is occasionally disappearing or why certain subnets aren't being properly routed through a mesh remote-site VPN configuration are not overstating the problem just to increase their status.
Even beyond the configuration interface and the complexity (yet necessity) of configuration elements like
same-security-traffic permit intra-interface is the fact that wielding these tools requires a thorough understanding of how they function, which results from a lifelong learning process. And unlike many other IT tasks, there's no undo button when you inadvertently cut off access to a remote site and can't get back into the remote device to fix the problem.
Yes, network administration is difficult. It's possibly the most challenging aspect in modern IT. That's just the way it has to be -- at least until someone develops network devices that can read minds.
This story, "Why network administration is so bleeping hard," 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.