Home page logo

bugtraq logo Bugtraq mailing list archives

Re: Catalyst 4000 - Cisco's Response
From: Mike Caudill <mcaudill () cisco com>
Date: Tue, 18 Jun 2002 02:33:27 -0400


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-

Version: PGP 6.5.2


[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

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.

      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.  

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.


      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..

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                  |

  By Date           By Thread  

Current thread:
  • Re: Catalyst 4000 - Cisco's Response Mike Caudill (Jun 18)
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]