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.geo...@lumison.net] Sent: Friday, August 21, 2009 3:40 AM To: nanog@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.
