Re: 3750s in the Core

Joseph, he meant 3750Es, which are around 20k a pop, so then it'll come down
to mentioned 60k for 3 of them. Gs are of course scheaper.
P.S.: that's why we have 2960 lan lite. And 2960Gs are not that bad at all.
Actually, internally 2960 and 3750 differ only slightly - simpler CAM with
more rigid registers and lack of StackWise controller in case of 2960.
That's why features that don't depend on TCAM/CAM are exactly alike. Like
QoS - it's exactly the same. 2960 even have a ring architecture and all
traffic goes from input ring to output ring via a loopback.

Ryan, my question was a bit different. Yes, there are 6G/slot for Non-E and
24G/slot for E-cards w(with the right SUP of course) but it's very important
how the bandwidth is going to be used. Who is communicating with whom, and
where does the information flow. You can have 6509 with 720-3C full of 6748
with DFC3Cs (that would cost you a small fortune) but if all connected
devices would communicate via one 1G uplink - all the backplane capacity is
no good at all. And that was my point. Total design oversubscribtion should
have the highest importance. Just like Joseph pointed out - if you have
hundreds of users, all using one bogged down internet connection and not
communicating horizontally at all, it won't matter for them if they are
connected to Nexus 7k via 10G or to 2900XL via 100M.

On Wed, Jun 17, 2009 at 9:41 PM, Joseph L. Brunner
<joe_at_affirmedsystems.com>wrote:

> Not even close dude..
>
> 3 x 3750G's 48 port are around $30k with discounts;
>
> The 6509 with sup-720 and 3 x 48 port 10/100/1000G blades is around $60k
> with discounts...
>
> They complement each other they don't compete with each other;
>
> But there is a need and requirement for each one; many companies even with
> 500 seats are now working on outsourced applications in remote datacenters,
> so like I said before you can probably run many 500+ seat deployments now
> with just a
> Stack of 2900XL's (and many people saving $$$ try to)
>
> :)
>
>
>
> -----Original Message-----
> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
> Piyoush Sharma
> Sent: Wednesday, June 17, 2009 3:19 PM
> To: Ryan West
> Cc: Pavel Bykov; Ahsan Mohiuddin; loopback99_at_gmail.com;
> ccielab_at_groupstudy.com
> Subject: Re: 3750s in the Core
>
> From my experience it is more cost effective to have a 6500 (6506/6509) if
> there is a requirement for more than 3 3750E switches.
> Of course, if using 3750G then the dynamics are altered. But 3 3750E
> switches cost as much as a 6500 chassis with Sup32 or 720 and has enough
> room for future growth. Not to mention the advantages of the backplane
> capacity with a 6500
>
>
> Piyoush.
>
> On Wed, Jun 17, 2009 at 8:02 AM, Ryan West <rwest_at_zyedge.com> wrote:
>
> > Pavel,
> >
> > Here is a small example to illustrate what I was talking about. There is
> a
> > sweet spot of using 3750G-24TS's vs a 4503 or 4506 with WS-X4548-GB-RJ45
> > (Bandwidth is allocated across six 8-port groups, providing 1 Gbps per
> port
> > group, 8:1) or WS-X4524-GB-RJ45V (Bandwidth is allocated across six
> 4-port
> > groups, providing 1 Gbps per port group, 4:1). The switching fabric on
> the
> > 3750's is 32 Gbps with 32 Gbps stackwise, with the model I listed above,
> the
> > forwarding rate is 38.7 mpps. With the 4500 (non E, again), you're
> > switching capacity per slot is 6 Gbps, it just won't go any faster than
> > that. Once the packets are there, that's another story and the 4500 is
> > going to win the battle with the Sup IV forwarding at 48 mpps and 64
> Gbps.
> >
> > So it's not a definitive use the 3750's vs the 4500 argument, but each
> can
> > have its place, even at the core.
> >
> > -ryan
> >
> > -----Original Message-----
> > From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
> > Pavel Bykov
> > Sent: Wednesday, June 17, 2009 5:50 AM
> > To: Ahsan Mohiuddin
> > Cc: loopback99_at_gmail.com; ccielab_at_groupstudy.com
> > Subject: 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
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> > 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>

-- 
Pavel Bykov
----------------
Don't forget to help stopping the braindumps, use of which reduces value of
your certifications. Sign the petition at http://www.stopbraindumps.com/
Blogs and organic groups at http://www.ccie.net