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."
[ Also on InfoWorld.com: Read Paul Venezia's instant classic, "Nine traits of the veteran Unix admin." | Then, if you dare, join the debate about rebooting Unix-based systems. ]
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.
