[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