Specifications

83
Release Notes for Cisco IOS Release 12.0 S
78-7130-11 Rev. B0
Caveats
Resolved Caveats—Cisco IOS Release 12.0(11)S
All the caveats listed in this section are resolved in Cisco IOS Release 12.0(11)S. This section describes
only severity 1 and 2 caveats.
Interfaces and Bridging
• CSCdp08975
A Cisco 7200 router that is configured for RFC1577 and is not acting as an Address Resolution
Protocol (ARP) server might experience a condition in which the status of ATM VCs might change
in spite of the traffic flowing on them. This condition occurs if RFC1577 is configured on the main
interface.
Workaround: Configure RFC1577 on a subinterface.
• CSCdp71620
A Cisco Packet OC-3 Interface Processor (POSIP) might reload with a bus error. There is no
workaround.
IP Routing Protocols
• CSCdp95210
Under rare circumstances, a link-state advertisement (LSA) on a neighboring router might get stuck
in MAXAGE state and not be deleted. In this situation, the LSA cannot be originated again on this
router, and the route might become unavailable or cause packets to take another route that is less
than optimal. This situation has been seen to occur when an OSPF neighbor ran out of memory and
OSPF tables are corrrupted.
Workaround: Restart the OSPF process by entering the clear ip ospf proc command.
• CSCdr07966
On a Cisco 7500 series router, many Virtual Private Networks (VPNs) configured in combination
with a large number of channelized interfaces might result in a FIBDISABLE message.
The FIBDISABLE message indicates that the Route Processor (RP) has not received a Forwarding
Information Base (FIB) “keepalive”message from the line card in the expected amount of time.
When this situation occurs, the RP acts as if the interprocess communication (IPC) mechanism had
malfunctioned and disables Cisco Express Forwarding (CEF) on that line card.
Workaround: Disable distributed switching.
• CSCdr27994
When tearing down a link-state packet (LSP) reservation, Resource Reservation Protocol (RSVP)
sends the upstream neighbor a ResvTear message that contains a RESV_CONFIRM object. RSVP
maintains the reservation and continues to send this message periodically until the upstream
neighbor responds with a ResvTearConf message or the reservation times out.
If the downstream neighbor continues to send Resv refreshes for the LSP, the reservation will never
time out. In this situation, if the upstream neighbor never sends a ResvTearConf message, the
reservation remains in this state indefinitely. The ResvTearConf mechanism is no longer defined in
the RSVP-TE IETF draft and is no longer used by some non-IOS implementations. There is no
workaround.