Life's too short for 'fragile' networks

The solutions to problematic networks are generally simple -- if you know where to look, or whom to ask

If you're a consultant, you've probably seen more than your fair share of "fragile" networks. Usually, you're introduced to them in a meeting with various IT people searching for a solution to their woes. Typically, they're all looking to you for salvation.

It has always puzzled me how both users and IT come to think that the network is somehow delicate and breaks without warning at a whim. IT folks are gun-shy about making any changes to routers, switches, or firewalls for fear of awakening the kraken that will bring about death and pestilence on unsuspecting users, causing IT's collective hair to catch fire.

[ Get expert networking how-to advice from InfoWorld's Networking Deep Dive PDF special report. | For the latest practical data center info and news, check out InfoWorld's Data Center newsletter. ]

The fact of the matter is that these networks are fragile by choice. They break because they're poorly designed, poorly constructed, and poorly maintained. Unless there's a serious flaw in some piece of network hardware, all of these problems stem from a lack of knowledge and understanding of basic networking concepts.

Rather than root out those problems and bring peace, love, and stability back to the infrastructure, however, many times people will shrug and accept the fact that the network is problematic. The users will roll their eyes and make excuses to clients and customers, saying, "My computer's acting up," or "Computers, what can you do?" The answer, of course, is that you can do plenty of things, but someone has to have either the skills to do those things or the initiative to bring in someone who does.

Many times, I've found the cause of problems on larger networks is a complete ignorance of Spanning Tree. With various cores and edge switching in place, nobody ever bothered to set fixed priorities and logical path costs. This means it's up to the switches to figure out where VLAN root bridges should be, a calculation based on a variety of default settings that are usually close to the worst possible scenario. I've walked into 5,000-port networks where the root bridge for a main server VLAN was an elderly Cisco 1900 100-megabit switch sitting in a lab. It had no live links other than an uplink to another edge switch, but its old MAC address caused it to win the election for that VLAN because all the other switches had default priorities.

This is how networks get deemed fragile. It should never be the case that a switch like that becomes the root bridge for a VLAN, yet there we were. Another common problem is wireless networks that were built without any kind of survey or testing. Those tend to be problematic due to either an overabundance or a dearth of access points -- basically the result of a complete lack of planning.

There are other causes as well, such as inadvertent routing loops or edge switch uplinks with poor punch-downs that cause gigabit uplinks to fall to 100Mbit/half-duplex. Or admins who disable Spanning Tree entirely because "it causes more problems than it fixes," or misconfigured VRRP or HSRP settings that cause duplicate DEFROUTE IPs in a VLAN, and a whole host of other nonsense. It's all preventable, usually easily discovered, and relatively easy to remedy.

In this day and age, there's no excuse for a fragile network, especially a campus network. The vagaries of physics and clueless backhoe operators can still wreak havoc on fiber and WAN links, but a campus network should be rock-solid, all the time. If your network isn't, it's time to stop accepting your fate and fix it. Life's too short for fragile networks.

This story, "Life's too short for fragile networks," 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.

Mobile Security Insider: iOS vs. Android vs. BlackBerry vs. Windows Phone
Recommended
Join the discussion
Be the first to comment on this article. Our Commenting Policies