Re: 3750s in the Core

4500 a NON-IOS switch?
3750s that don't fail?
Core/distribution/access model when there is just a stack of 3750s?
AVERAGE loads?
Oversubscribtion quite low?
...
I can't believe I'm hearing all this...

1. 4500 is a chasis with connectors. It's pretty dumb actually. What
controls the switch is the SUPERVISOR. So when you're looking at 4500, look
at SUPs first. Price important? Try to price 240 1Gbps PoE ports with
routing capabilities. 3750s will be considerably more expensive then 4506
with SUPV-10GE. And as for "4500" being a NON-IOS switch... well, either i'm
not understanding what does this means, or Ashan is way off. All sups
starting with III are perfectly able to run IOS. Newest SUP6 was actually
never even able to run CATOS in the first place. And have you checked the
discount on bundles, where you get free cards, PSs etc?

2. If you think that 3750 never fail, well maybe you haven't seen enough of
them or under real load. I'm not talking about having ten 3750 with insane
uptime - that's hit and miss. I'm talking about hundreds of them under
different conditions. Try loading on them 12.1(19)ea1 and connecting one
gigabit interface and one 10-mpbs interface. The whole stack will fail in
due time, with an Ethernet controller error, making any forwarding/failover
impossible with only solution to physically unplug the stack master... TAC
team for 3750s is just as active as for other devices, and there are quite a
number of failures that bring down the whole stack instead of just one
switch... And what about One PS, even when there is an RPS, it will have
problems and you need to be aware of severe limitations, etc, etc.

3. Core/distribution/access models were designed as a guideline to enable
bes HA and scalability, among other things. It is a model that solves
complex number of issues, and not just some guideline that you need to buy
three switches instead of one. If you have just some LAN with users, you
don't have to retrofit the design into that model. It's best practice, and
creating something and then saying it is best practice because you were able
to retrofit it to the model is not how it works.
http://www.cisco.com/en/US/docs/solutions/Enterprise/Campus/HA_campus_DG/hacampusdg.html

4. Joseph, average loads do not have to be the cause, but the effect. Many
times i've seen that relatively low loads were quadruppled because of
network design improvement. Network never operates in average mode. What is
it an average of? 30 seconds? 5 minutes? a year? a century? sure, i'm
exhaggerating here, but interface operation is a microsecond or
sub-microsecond matter. It's all bursty in nature, no matter how we take it,
because virtually no enterprise runs real-time operating systems. A cop does
not stop you on the street because your average speed for the past week was
above 4mph, and it does not mean that roads should be designed for such a
low speed. You need to get somewhere quickly, then stay there for a while,
then get quickly somewhere else. Designing the network for average loads is
like desiging roads for average speeds... It may seem ok in a theory of some
sort, but in practice the problems could be hiding behind every corner.

5. Ryan, you mentioned oversubscription... of what to what and where? 3750
has a lot of architectural limits. It can be oversubsribed as any other if
ports are not connected correctly evenly to port-asics and could be
ovesubscribed without any problem. When it's a stack than all
oversubscription naturally grows.

Blogs and organic groups at http://www.ccie.net
Received on Wed Jun 17 2009 - 11:50:19 ART