Specifications

132
Caveats for Cisco IOS Release 12.0
78-6455-12
Resolved Caveats—Cisco IOS Release 12.0(3)
• CSCdk70378
When MPOA configuration is removed under moderate to heavy traffic across a LANE network,
the RSM might crash. There is no workaround for this problem, except to not remove the MPOA
configuration once it is operational.
• CSCdk71109
When CEF is on, if an outgoing interface does not have CEF on (for example, SMDS
encapsulation), packets are process-switched. This is due to lack of IP cache creation. There is no
workaround.
• CSCdk71560
Unencrypted traffic can suffer packet payload corruption when it flows through a Cisco router as
encrypted traffic.
Workaround: Turning off fast switching.
• CSCdk72452
When an ATM uplink is broken or the remote CES sees loss of signal (LOS) or loss of frame (LOF),
an alarm must be generated to the locally connected T1/E1 link. This condition sends alarm
indication signals (all 1’s) to all the timeslots configured in the structured mode. There is no
workaround.
• CSCdk73672
When an integrated access server is under extremely high traffic loads, some modems might be
unable to answer incoming calls. This condition only occurs if the modems are set up to be
autoconfigured.
Workaround: Reenter the modem autoconfigure type command.
• CSCdk76192
Packets that have the “do not fragment” bit set do not generate an ICMP unreachable packet when
forwarded to an interface that requires the packet to be fragmented. This behavior is observed only
with Distributed Cisco Express Forwarding (DCEF) switching mode on the Cisco 7500 platform.
There is no workaround.
• CSCdk77426
If a User Datagram Protocol (UDP) packet with an invalid length is sent to port 514 (the syslog
port) on an IOS device, the device is likely to reload. In this situation, a stack trace might not be
saved. Such packets are sent by the popular nmap port scanning program.
Workaround: You can work around this vulnerability by preventing any affected Cisco IOS device
from receiving or processing UDP datagrams addressed to its port 514. This can be done by using
either packet filtering on surrounding devices, or input access list filtering on the affected IOS
device itself. If you use an input access list, that list should be applied to all interfaces to which
attackers might be able to send datagrams. This includes not only physical LAN and WAN
interfaces, but virtual subinterfaces of those physical interfaces, as well as virtual interfaces and/or
interface templates corresponding to GRE, L2TP, L2F, and other tunnelling protocols. The input
access list must block traffic destined for any of the Cisco IOS device’s own IP addresses, as well
as for any broadcast or multicast addresses on which the Cisco IOS device might be listening. It is
important to remember to block old-style “all-zeros” broadcasts as well as new-style “all-ones”
broadcasts. There is no single input access list that works in all configurations. It is very important
that you understand the effect of your access list in your specific configuration before you activate
the list. The following example shows a possible access list for a three-interface router, along with
the configuration commands needed to apply that access list. (The example assumes no need for
input filtering other than as a workaround for this vulnerability.)