Two Diverse LAN Ports to Every Cube - More Trouble than it's Worth?

We provide two diverse LAN ports to all of our cubes. Port A goes to Switch 1 and port B goes to Switch 2. Not only does this provide two ports, which many users need, but also provides redundancy for their primary PC. If one of the switches goes down, users can move their PC to the other port and be back online. This was a great idea to provide redundancy all the way down to the users. However, it's rarely been needed. We've had some switches go down, but not many. Cisco switches, with a quality IOS, don't go down that often. Unfortunately, there have been outages, but not because of switches going down, but because of these two ports. Many users feel the need for more than two ports in their cube. So some users bring in their own 5 or 8-port hub/switch. They then connect this switch to port A or B. That's fine. We don't particularly like it, but we understand some people do it. However, some users seem to think that if they plug this hub/switch into ports A and B at the same time they will get more bandwidth (because 1 Gbps just isn't enough!!!). Unfortunately, these hubs don't run spanning-tree - they're hubs (the cheap switches are just special hubs). So, when users connect this hub to both ports it creates a bridging loop between both access switches. This kills both access switches, taking down all users in the office. So, we have diverse LAN ports to protect users from a failure; just not a failure of both switches. Now, there are simple technologies to prevent this, like BDPU-guard, which we use and it works fine. But honestly, configurations change often and sometimes BDPU-guard gets removed or disabled. Since it's not immediately apparent that BDPU-guard gets disabled after a change it gets missed. Then we're just waiting for the next user with a hub looking for extra bandwidth. Then a few weeks ago we had everything configured right and a hub on the corporate executives' floor still took down the LAN. A Cisco bug disabled BPDU-guard when using Voice VLANs. Our good intentions keep coming back to haunt us. In the end, I think our initial goal was virtuous. We are a technology company, so having employees not connected to the network can get expensive quickly in lost production. But LAN switches don't go down that often. It seems we out-designed ourselves on this. This has been a good lesson for the future.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Related:

Copyright © 2007 IDG Communications, Inc.

IT Salary Survey: The results are in