-----BEGIN PGP SIGNED MESSAGE----- The MAC address learning rate in a Cisco Catalyst 4000 series switch depends on a variety of factors such as Switch load and traffic patterns. Under certain circumstances, such as a large layer 2 network deployment where a many to many traffic pattern is prevalent, the learning rate may be such that more than one packet is flooded for a given host. Flooding packets onto all LAN segments is standard behavior for devices doing transparent bridging when the destination MAC address entry does not exist within a database on the switch containing switch ports and the MAC addresses sourced behind those ports. The circumstances in which this behavior can be observed include high rates of address aging and learning, Spanning-tree Topology Changes, moderate to high Switch CPU load, Asymmetric routing, and general traffic patterns. In order to minimize the effects of this behavior address aging and learning needs to be minimized. Reducing Spanning-tree Topology Change Notifications, adjusting MAC address aging time and avoiding asymmetric routing conditions will all reduce period address aging and learning to reduce flooding of unicast packets. - -Mike- -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.2 iQEVAwUBPQ7TSg/VLJ+budTTAQEFwQf/bcgthaSiZUaiIotY5rX1OpNESjLntd3t 5NENyWstoIi3EfFbyaifAjFXlQz7wdRmbPk94UTgx54SVyOh9+gbdinZBMX6PUqI rqkIEb/dGoVwS+rixvQ3tVK1PTDxPhY1gp0eapXUB8cG3F0FJc5qpHfyvKjUoRlg eTYJXYr2XmZeQq2v1b/+J+hiHYus5bJkppeLoMTnhu3tLOarRFithr6Kxxz/yD7I MoB0RGkDMIixh3xi1ex75LMnUJqXxscGy240g+rJEoJ1tPhltc5UK2RSdnCHOEz3 TXEPzoDG9pRQtWZh++i8N4b2yuoDYY2+tcG2gdssUGPpKElfh22CWA== =OMRw -----END PGP SIGNATURE----- > [On Mon May 20 09:38:25 2002, COULOMBE, TROY wrote] > Issue: > Unicast packets flooded out switch ports they shouldn't be. > > Platform: > Cisco Catalyst 4000 > > OS: > 5.5.5; 6.3.5; 7.1.2; probably all others > > Environment: > Single VLAN, non-default "VLAN 1"; No Spanning Tree; 10/100 48 port > blades. > NO SPAN session is created. > Using a sniffer to capture broadcasts/multicasts, etc only. > > Vendor, Vendor Notified, Date Notified: > Yes, Cisco, 04/10/2002; case C579249, no fix supplied > > Detailed description: > Middle of a TCP conversation, unicast packets sent to a host are > flooded out all ports. > > Using a sniffer [EtherPeek NX for Windows, NAI Sniffer Pro], the > Cat4006 floods TCP packets out > to all ports. Packets captured are unicast-mac and are not destined for the > port the sniffer is on. > No SPAN session is created on the switch; only broadcasts/multicasts and > _initial_ session packets should be > flooded. Sniffer is on a different port than the workstation and servers. > > Given: > It is understood that if the switch doesn't know where a MAC is, it > will flood the packet out all > ports until the MAC is learned, and the CAM table is populated. Initial TCP > packets are also captured by the > sniffer, however, these packets would be indicated by the "SYN" flag, and > are considered normal. > > However, what is happening, is that TCP session packets are being flooded, > although the switch _should_ have learned > the MAC. > > Example: > > 01) workstation --> DNS server > UDP DNS request packet > 02) workstation <-- DNS server > UDP DNS response packet > 03) workstation --> Server > Initial TCP SYN packet > 04) workstation <-- Server > TCP SYN-ACK packet > 05) workstation --> Server > TCP ACK Packet > 06) workstation <-- Server > TCP Packet W > 07) workstation <-- Server > TCP Packet X > 08) workstation <-- Server > TCP Packet Y > 09) workstation <-- Server > TCP Packet Z > > Packet #01 is _not_ seen by the sniffer, and rightly so, assuming the switch > knows the MAC entry for the DNS server. > > Packet #02 is seen by the sniffer, but shouldn't have been. The switch > should have learned the workstation's MAC > entry from packet #01. > Packet #03 is _not_ seen by the sniffer, and rightly so, assuming the switch > knows the MAC entry for the Server. > > Packet #04 is seen by the sniffer, but shouldn't have been; no matter what. > The switch now has had 2 different packets > from the workstation to learn it's MAC. > > Packet #05 is _not_ seen by the sniffer, and rightly so... > > Packet #06 through #09 are seen by the sniffer, but shouldn't have been! > > Packet #10 is assumed to be an "ACK" from the workstation and suddenly the > switch registers the workstation's MAC. No > additional packets are seen for _this_ conversation. > > > I have captured telnet sessions, ftp sessions, etc; with a portion of a > telnet session's password visible. There is no > special setup required to see this other than physical Ethernet connection & > sniffer software. > > Exploit: > Patience > > Workaround: > Setting the CAM agingtime to a larger time _helps_ but does not > completely eliminate the problem. "set cam agingtime xx 14400" where xx is > VLAN #. > Still waiting on an official fix from Cisco.. > > > Thanks, > Troy Coulombe > > > > [ ----- End of Included Message ----- ] -- ---------------------------------------------------------------------------- | || || | Mike Caudill | mcaudill@cisco.com | | || || | PSIRT Incident Manager | 919.392.2855 | | |||| |||| | DSS PGP: 0xEBBD5271 | 919.522.4931 (cell)| | ..:||||||:..:||||||:.. | RSA PGP: 0xF482F607 ---------------------| | C i s c o S y s t e m s | http://www.cisco.com/go/psirt | ----------------------------------------------------------------------------
