Installation guide

44
Release Notes for Catalyst5000 Family Software Release4.x
OL-2306-01
Open and Resolved Caveats in Software Release 4.5(2)
In a switch with one or more 24-port 10/100BASE-TX Fast Ethernet module (WS-X5225R) or the
12-port 100BASE-FX Ethernet (WS-X5201R) modules, the swBusSBDErrorDrop counter in the
show counters output increments if the module detects invalid frames on the backplane. Such
frames are discarded and have no effect on the normal operation of the switch. This counter has been
renamed swBusSBDEvent in software release4.5(2). (CSCdm02396)
In some cases, if the primary UplinkFast link goes down, when it comes back up it can take 20 to
25seconds to begin forwarding traffic instead of the usual one to five seconds, depending on the
remote hardware.
Workaround: Connect to a different port on the remote device if the problem occurs. This problem
is resolved in software release4.5(2). (CSCdm26273)
In some cases, UplinkFast does not function correctly between a Catalyst5000 family switch and a
Catalyst 4000family switch, a Catalyst 2948G switch, or a Catalyst 5000 family Gigabit
EtherChannel module (WS-X5410). This problem is resolved in software release4.5(2).
(CSCdm34341)
When you configure dynamic VLAN membership for any EtherChannel-capable port, spanning tree
convergence time is 7 to 8 seconds longer than usual for those ports. This problem is resolved in
software release4.5(2). (CSCdm40338)
In some cases, when you connect a port on the 24-port 10/100 BASE-TX Fast Ethernet module
(WS-X5225R) to an end station, the port might loop data back to itself. If spanning tree is disabled
on the port, this problem can negatively affect switch performance. If spanning tree is enabled, the
port is automatically disabled. You can verify that the problem is occurring, and identify the
problem port, by entering the show cdp neighbors command and checking to see if the switch itself
is listed as a neighbor.
Workaround: Di sable and reenable the problem port. This problem is resolved in software
release4.5(2). (CSCdm26889)
In some cases, if you configure a port as a SPAN source port and subsequently configure the same
port as the SPAN destination, the SPAN destination port might be unable to receive traffic if any
other SPAN-related commands are executed on the port. To avoid the problem, disable SPAN before
changing the SPAN configuration. If the problem occurs, reset the module with the problem SPAN
port. This problem is resolved in software release4.5(2). (CSCdm43384)
On the 24-port 10/100BASE-TX Fast Ethernet module (WS-X5225R) and 12-port 100BASE-FX
Ethernet (WS-X5201R) modules, if you configure a port as a SPAN destination for both transmit
and receive traffic, and then you connect an analyzer to the port (bringing the link up), only receive
traffic on the SPAN source port is mirrored to the SPAN destination port. The problem only occurs
if the source and destination SPAN ports are both in the same group of four ports (1–4, 4–8, 9–12,
13–16, 17–20, or 21–24). This problem is resolved in software release4.5(2). (CSCdm25471)
Under certain circumstances, an ISL packet can get corrupted in such a way that a blocked spanning
tree port will forward the packet. The packet can get flooded again, leading to packet storms in
certain network topologies. This problem is resolved in software release4.5(2). (CSCdm34970)
In some cases, if you boot a switch with a user-defined TrCRF VLAN configured but no active end
user ports or trunk ports in that TrCRF, an RSM VLAN interface in that TrCRF is not properly added
to the parent TrBRF, preventing routing for the TrCRF.
Workaround: Do not define a TrCRF without active ports in the TrCRF, add the TrCRF to an active
trunk port, add an active port to the TrCRF, or disable RSM autostate. This problem is resolved in
software release 4.5(2). (CSCdm23217)
If you delete the RMON alarmEntry or if you modify the alarmVariable of the RMON alarmEntry
while that alarmVariable is being sampled, the switch might reset. This problem is resolved in
software release 4.5(2). (CSCdm49575)