Datasheet
241
Release Notes for Cisco IOS Release 12.1E on the Catalyst 6500 and Cisco 7600 Supervisor Engine and MSFC
OL-2310-11
Caveats
• If you configure Cisco IOS SLB while creating RTR entries using SNMP, the system may generate
traceback messages similar to the following:
Feb 16 15:27:08.846: %IDMGR-3-INVALID_ID: bad id in id_to_ptr
-Traceback= 413DD97C 405C4C08 405CB12C 40E387E8 40E34DF0 401DAD1C 401DAD08
Feb 16 15:28:08.846: %IDMGR-3-INVALID_ID: bad id in id_to_ptr
-Traceback= 413DD97C 405C4C08 405CB12C 40E387E8 40E34DF0 401DAD1C 401DAD08
This problem is resolved in Release 12.1(13)E6. (CSCea21064)
• When you run the RADIUS load balancing (RLB) feature of IOS server load balancing in a
redundant configuration, the standby RLB switch may reload. This problem occurs only if stateful
replication of the RADIUS username sticky database is used. This problem is resolved in
Release 12.1(13)E6. (CSCea61966)
Resolved General Caveats in Release 12.1(13)E5
• The “do not learn” bit of an active VLAN can incorrectly become set, which prevents any more
dynamic CAM entries from being learned for that VLAN and floods all unicast traffic in that VLAN.
This problem is resolved in Release 12.(13)E5. (CSCea45950)
• The following OSM ports do not support multicast traffic:
–
OC-3 POS OSM ports 2 through 8
–
OC-12 POS OSM ports 2 through 4
–
OC-12 ATM OSM port 2
This problem is resolved in Release 12.1(13)E5. (CSCea34141)
• When some multicast RPF interfaces are tunnel interfaces, a Supervisor Engine 1 with an MSFC1
might reload when the routing table changes frequently. This problem is resolved in
Release 12.1(13)E5. (CSCea50623)
• If MMLS is not synchronized between the MSFC and the supervisor engine when you enter a clear
ip mr * command or a clear ip mroute group_address command, the MMLS entry on the supervisor
engine might not be cleared. This problem is resolved in Release 12.1(13)E5. (CSCdy51453)
• In an intermediate router where (*,G) and (S,G) traffic is RPF multicast fast dropped and the (*,G)
traffic and the (S,G) traffic have different RPF interfaces, when an RPF change happens for the (S,G)
entries, the intermediate router deletes the (S,G) entry but does not delete the (*,G) entry, which
causes the multicast traffic to use (*,G) entry in HW and get dropped as non-RPF traffic. This
problem is resolved in Release 12.1(13)E5. (CSCea60918)
• A reload might occur when you enter the show scp mcast group 127 command or the command
might wrongly display some processors to be part of group 127 that are not. This problem is resolved
in Release 12.1(13)E5. (CSCdz85864)
• With multicast support configured, a reload might occur when an interface flaps. This problem is
resolved in Release 12.1(13)E5. (CSCdy89663)
• If an output route-map in an EBGP neighbor has match ip next-hop or match ip route-source or
match ip community or match ip extcommunity commands, then BGP updates might be
incorrectly suppressed if the next-hop of the best path changes. This problem is resolved in
Release 12.1(13)E5. (CSCdv36378)
• With a network topology that creates an assert, after the assert winner prunes its outgoing interface
(which is correct), some neighbor routers might fail to override the prune with a join, which might
break dense mode auto RP groups.This problem is resolved in Release 12.1(13)E5. (CSCdv23921)