Saturday, I tackled a beast.
It wasn’t anything of insane epic porportions, and in reality it only took a couple hours but I felt like sharing.
The picture on the far left is of a clients data rack (after I removed the non-functional and abandonded equipment). Long story short, this is what happens when you don’t have a clear plan, or a single person to make decisions.
There were more problems than the obvious mess:
- Troubleshooting connectivity problems with this tangled mess can make a grown man cry.
- With so much extra cable in such a tangled mess, your chances of Alien Crosstalk goes up, which ultimately means poor network performance.
- The weight of the unsupported cable puts kinks in the cables at the plugs, as well as can damage the connections resulting in poor conductivity (again, ultimately poor network performance).
- Its not apparent (and took me nearly an hour to fully navigate) but the switches on this rack (and there are 5 in use) are daisy chained together, which means that the network had severe bottlenecks, as well, if a device in the middle of the chain were to fail, everything below it would stop working.
The simple solution, get the right sized patch cables for the job. In my case, I was able to layout the equipment in such a way that I could do just about everything with 1′ patch cables. I also re-structured the topography into a star with the switch at the very top of the rack acting as the center of my star. It does unfortunatly mean I still have a single point of failure that could take down the network, but if any one of the other switches fail only devices connected directly to that switch will go down, so I see it as an improvement. Rebuilding the topography also means I don’t have the same bottlenecking problem I had before. Internal traffic now has a maximum of three hops, as opposed to the potentially 6 hops in the prior design.
I’ve asked the client to keep an eye on things, see if the improvements are actually noticable or not. They han’t had any serious problems before so I won’t be supprised if the changes are not readily noticable to the end users. If they do though, it’ll be in the voice quality of their VoIP phone system. At the moment on busy days they get a noticable degredation of the voice quality, and without QoS capable switches there isn’t anything I can do besides hope the drop in packet loss due to the rebuild is enough to subdue the problem until I can get new switches.
