mailing list archives
Re: Catalyst 4000 - Cisco's Response
From: Mike Caudill <mcaudill () cisco com>
Date: Tue, 18 Jun 2002 02:33:27 -0400
-----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
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
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.2
-----END PGP SIGNATURE-----
[On Mon May 20 09:38:25 2002, COULOMBE, TROY wrote]
Unicast packets flooded out switch ports they shouldn't be.
Cisco Catalyst 4000
5.5.5; 6.3.5; 7.1.2; probably all others
Single VLAN, non-default "VLAN 1"; No Spanning Tree; 10/100 48 port
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
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.
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
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 &
Setting the CAM agingtime to a larger time _helps_ but does not
completely eliminate the problem. "set cam agingtime xx 14400" where xx is
Still waiting on an official fix from Cisco..
[ ----- 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 |
- Re: Catalyst 4000 - Cisco's Response Mike Caudill (Jun 18)