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
This archive was generated by hypermail 2b30 : Tue May 21 2002 - 14:11:35 PDT