Alternatives to storm-control on Cat 6509.

Holmes,David A dholmes at mwdh2o.com
Mon Aug 24 18:03:47 UTC 2009


In my opinion the Sup32 platform has some limitations when the
technology is considered for high data rate, deterministic carrier
customer-facing scenarios. Cisco sells the Sup32 as a wiring closet
aggregation switch the main purpose of which is to connect desktop users
to central core switches. In addition to the lack of
storm-control/broadcast suppression mentioned below, the 61XX line cards
also have a limit of, I believe, 2 ports in an Etherchannel.
Additionally, and perhaps most significantly for deterministic network
design, the copper cards share input hardware buffers for every 8 ports.
Running one port of the 8 at wire speed will cause input drops on the
other 7 ports. Also, the cards connect to the older 32 Gbps shared bus.

In my view, with high data rates, it is difficult, if not impossible, to
build a deterministic network with Sup32s. Cisco's solution for
designing a deterministic network is the sup720 which has a 720 Gbps
crossbar bus. The 67XX 48 port copper line cards have 2 20 Gbps
connectors to the 720 Gbps bus, the 24 port fiber sfp line cards have a
single 20 Gbps connector to the crossbar bus, and the 10 GiG 67XX line
cards have 2 20 Gbps bus connectors. The crossbar bus connects line card
connectors to each other in a point-to-point fashion. 67XX line cards
are adequately provisioned with input and output buffers. There is still
40/48 (1 GiGE copper), 20/24 (1 GiGE sfp), and 40/160 (10 GiGE X2)
oversubscription of ports to switch fabric connectors, however. Sup720
routing table lookups via Ternary Content Addressable Memory (TCAM)
still use the 32 Gbps bus to access the TCAM to search for next hop for
destination IP network.        

-----Original Message-----
From: Peter George [mailto:Peter.George at lumison.net] 
Sent: Friday, August 21, 2009 3:40 AM
To: nanog at nanog.org
Subject: Alternatives to storm-control on Cat 6509.

Hello,

I have several Catalyst 6500 (Supervisor 32) aggregation switches with
WS-X6148A-GE-TX and WS-X6148-GE-TX line cards.

These line cards do not support storm-control/broadcast suppression.
This impacted us badly during a recent spanning tree event.

As it stands, we are at risk of overwhelming control planes with excess
broadcast or multicast traffic, and I need to find alternative ways to
protect these switches.

I have been researching STP enhancements, and control-plane policing in
the following documents, and would appreciate advice from engineers who
may have had to implement similar workarounds for storm-control in a
service provider setting.

* Configuring Denial of Service Protection
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/con
figuration/guide/dos.pdf

* Configuring Control Plane Policing
http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/31sga/con
figuration/guide/cntl_pln.pdf

* Configuring Optional STP Features
http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/31sga/con
figuration/guide/stp_enha.pdf

So, if we can't mitigate against STP events using storm-control or
broadcast suppression, what might be the best combination of STP
enhancements and control-plane policing?

For example, is it possible to rate-limit broadcast/multicast, STP and
ARP on a per VLAN basis? If so, how?

Many thanks,

P


--
Peter George
Lumison
t: 0845 1199 900
d: 0131 514 4022

P.S. Lumison have changed the way businesses communicate forever
http://www.unified-communications.net/



________________________________
--

This email and any files transmitted with it are confidential and
intended
solely for the use of the individual or entity to whom they are
addressed.
If you have received this email in error please notify the sender. Any
offers or quotation of service are subject to formal specification.
Errors and omissions excepted. Please note that any views or opinions
presented in this email are solely those of the author and do not
necessarily represent those of Lumison.
Finally, the recipient should check this email and any attachments for
the
presence of viruses. Lumison accept no liability for any
damage caused by any virus transmitted by this email.




More information about the NANOG mailing list