Re: 3750s in the Core

Pavel, this is what I was going to write in my next posting. From
enterprise and best practice point of view, I don't think there was any
focus on this.

Thanks for the clarification.

On Wed, Jun 17, 2009 at 7:50 PM, Pavel Bykov <slidersv_at_gmail.com> wrote:

> 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Wed Jun 17 2009 - 21:25:15 ART