[c-nsp] Top of Rack Switching
David J. Hughes
bambi at Hughes.com.au
Mon Apr 24 20:12:47 EDT 2006
On 25/04/2006, at 6:12 AM, Scott Altman wrote:
>
> What I would like to hear about are:
> - Issues with managing the complexity of the environment (managing 122
> switches in an IDF is not common)
Working with that number of access switches isn't a problem. We have
more than that number in each of our datacentres hanging off 6500's for
aggregation. The only real management issues are :
* config tracking (easily solved by rancid or similar)
* IOS upgrade planning (working on that number of switches at each
upgrade point can be a pain)
* Management software node count (if you are running a commercial
management app then there are $$'s to be spent here due to a
dramatically increased node count).
But, like I said, we run most of our data centre real estate using TOR
switching and it works just fine.
> - General design concerns
* ensure your STP roots are forced to where you want them (split over
your 6500's no doubt).
* with the small number of vlans you are talking about here Rapid PVST
is your friend
> - Suggestions for improvement
Is there any particular reason you've gone with a U configuration at
the access layer rather than dual-uplinking each of the access
switches? Dual uplionking does burn more ports at the aggregation
point but it gives you a cleaner path to the STP roots. I assume
you'll share the root load over the 2 6500's and in that case a bunch
of your traffic will be double switched as it traverses the U in the
long direction. Probably not a real concern for you though.
> - Experience with similar configurations
We now have an area that's using consolidated / centralised patching in
one of our datacentres. It does give you a financial win if you are
talking about using this class of access switch. Walking around our
installations it's easy to see lots of half utilised switches in our
TOR sections. Now, if you were using 2950's at $2k list then blowing
those ports isn't an issue - but using 4948's or 3560's at $18k list is
another issue altogether. Centralised patching / switching will
certainly help increase your port utilisation. That in turn will
reduce your cost per port as the extra UTP run is a one off and costs
far less than a switch port. It'll also help keep your device count
down (for your NMS licenses, maintenance costs, and upgrade pain).
Personally, I've always been a TOR type of guy but now am sitting on
the fence. There are pro's and con's for both design approaches.
David
...
More information about the cisco-nsp
mailing list