RE: Layer 3 switches(3550s/3750s) vs Routers (2651XMs)

From: Devi Mallampalli (Devi.Mallampalli@chubb.com.au)
Date: Tue Sep 07 2004 - 22:01:50 GMT-3


Thanks , James / Dustin / Chad & Adebola.

Your feed back is very helpful. Just to clarify further , yes I was
planning to run BGP on 3550s for dynamic fail over purposes ONLY at our
Internet boundary and will NOT be trying to exchange full BGP routing
table with our ISP peer devices. I will be negotiating similar policy
with my ISP as well so that they will only leak cut down size of
internet table. In other words , I was looking for a fail over
capability rather than Full Route specifics. Secondly TCAM related
scalability issue which James pointed out is really important one , I
guess. As I am certain that I will be doing some kind of advanced PBR ,
Qos & Security features down the track , I am now having second
thoughts about deploying 3550s as edge router at our Internet perimeter.

Having said that, I will still try to deploy 3550 as an edge router at
one of our spoke sites who does not need any fancy Qos or ACLs or 20 odd
multiple Vlans.I think they will do just fine on that kind of small 20
odd user spoke site because we can , not only eliminate Access switch
costs (typically we use 2950s closer to the users) by connecting all
user's desktops directly to 3550s, but also Router costs by connecting
BDSL WAN Ethernet interface directly to one of 3550s switch ports. And
they can happily do IGP/EIGRP routing for up to 500 odd routing table
(well I am not doing stubb routing yet at my tail sites) , I reckon:-)

Once again thanks a lot for your thoughts , Gentleman.

Cheers

Devi.

-----Original Message-----
From: James [mailto:james@towardex.com]
Sent: Wednesday, 8 September 2004 12:27 AM
To: Devi Mallampalli
Cc: ccielab@groupstudy.com
Subject: Re: Layer 3 switches(3550s/3750s) vs Routers (2651XMs)

That's okay, but remember C3550's have really small TCAM sizes, which
makes them not eligible to function as a proper edge router. Watch out
for TCAM labels and masks availability when you add ACL's, watch out
whenever you have more than
8-16 routed or SVI interfaces, watchout whenever you have few thousand
routes, watch out when you add QoS policies, etc.

3550's are fine as as long as you keep it simple and don't push it to
its limits. Push to its limits and it will resort to sloooowww software
routing.
And the limit of the hardware is clear: its TCAM is so small, unless it
is 3550-12T/G which have bigger space, but still small compared with
other models.

Also don't expect to do bgp redundancy between two isp's using full
routes.
It won't hold full routes.

I used to use c3550's as "edge router" device for colocation customers.
It did not scale for us. We ended up having more than 24 vlan's routed
(SVI's) for each customer on the box, and 3550 just smoked, since we
went past its limits. Add ACL's to the equation and situation becomes
worse by that point.

HTH,
-J

On Tue, Sep 07, 2004 at 09:22:56PM +1000, Devi Mallampalli wrote:
> Hi Group,
>
> Got a real world scenario at hand and would like to gather your
> thoughts on this :-)
>
> I am seriously planning to replace our Internet Router/2651 and its
> expensive 2MB Frame circuit with that of Layer 3 switch (either 3550
> or
> 3750) and with lesser expensive 2 MB BDSL (Business DSL) WAN circuit
> which is delivered on to "Ethernet" port on layer 3 switch directly.
> The primary reason of doing this design is to not only to derive
> direct cost savings to the tune of around US$20k per annum (Yes, 4MB
> HSSI installation cost and per annum usage cost are too high when
> compared to a 2 MB BDSL Ethernet circuit) to our corporation , but
> also to try out alternative WAN protocols which can delivered on to an

> Ethernet/RJ45 interface rather than on x25 or v35 interfaces (with a
> long term view to replace all Routers on our WAN with that of Layer 3
> switches with an MPLS core and BDSL combination at remote sites so
> that we can move away with our current HUB and SPOKE Frame relay WAN
> and instead can have one flat , one hop away WAN. Any way that is
> different story)
>
> But before I proceed I just want to have a second opinion on whether
> or not it is a good idea to assign Internet periphery responsibility
> to a Layer 3 switch , rather than a decent Router such as 2651 XM ,
> primarily from both Qos and required Redundancy point of view.
>
> Qos , because I am not 100% on whether or not I can do Shaping ,
> Policing , Policy Routing and IP Routing on Ethernet interfaces of
> 3550/3750 to the same "Degree" as that of Routers/2651XM serial
> interfaces ? And more over , I was wondering with this Layer 3 design
> , I will be loosing congestion indicators such as DEs, BECNs and FECNs

> on the wire and so from what features I can take help on Ethernet WAN
> interfaces(well in my case it is BDSL which is being delivered on to a

> RJ 45 interface at customer premises) to the similar effect ?
>
> Redundancy , since our Internet infrastructure need to support
> critical Ecommerce apps, originally I thought of deploying a back up
> 2651 as well and then run BGP between them and our ISP's Internet edge
routers.
> Unlike our current static routing , I was planning to extract more
> effective dynamic fail over between two Routers from L3 protocol/BGP.
> In addition , from L3 protocol I am hoping to do some traffic
> engineering in terms of preferred "outbound" and "inbound" in to our
> AS. And I am not 100% on whether I can do the same things on Layer 3
switches ?
>
> I have seen 3550s operating happily on our N/W in doing roles such as
> "Campus Vlan router" and "switch block aggregator" for 20 odd 7960 IP
> phones ...etc. But I have not seen them in the role of perimeter
> Routing device in doing both Routing functions as well as advanced
Qos.
>
> I am inclined towards Layer 3 switching design because 1) we can
> eliminate routers costs 2) it will save us Telco circuit costs as well

> since we are not using expensive WAN protocols such as Frame/HSSI.
>
> But I appreciate any feed back on the intended solution.
>
> Cheers
>
> Devi.
>
>
>
>
>
>
>
>
> *************************************************************
> This email and any files attached are considered confidential and
> intended solely for the use of the individual or entity to whom this
> email is addressed.
> If you have received this email in error, please send a reply message
> to this email address.
> This footnote also confirms that the above email has been scanned for
> the presence of computer viruses.
> *************************************************************
>
> ______________________________________________________________________
> _ Please help support GroupStudy by purchasing your study materials
> from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

-- 
James Jun                                            TowardEX
Technologies, Inc.
Technical Lead                        Network Design, Consulting, IT
Outsourcing
james@towardex.com                  Boston-based Colocation & Bandwidth
Services
cell: 1(978)-394-2867           web: http://www.towardex.com , noc:
www.twdx.net

************************************************************* This email and any files attached are considered confidential and intended solely for the use of the individual or entity to whom this email is addressed. If you have received this email in error, please send a reply message to this email address. This footnote also confirms that the above email has been scanned for the presence of computer viruses. *************************************************************



This archive was generated by hypermail 2.1.4 : Fri Oct 01 2004 - 15:00:39 GMT-3