Specifications

1124
Cross-Platform Release Notes for Cisco IOS Release 12.0S
OL-1617-14 Rev. Q0
Resolved Caveats—Cisco IOS Release 12.0(28)S2
Workaround: If the LSA is an external LSA (type5/type7), enter the clear ip ospf redistribution
command on the neighboring router. In all other cases, enter the clear ip ospf process command on
the neighboring router.
• CSCee67164
Symptoms: A router LSA is not generated for a loopback address.
Conditions: This symptom is observed when you assign an IP address to an unnumbered interface.
Workaround: Enter the shutdown command followed by the no shutdown command on the
loopback interface.
• CSCee85676
Symptoms: When VPNv4 route advertisement are received after BGP has converged, the existing
path is updated but imported paths from the original path are not updated accordingly.
Conditions: This symptom is observed on a Cisco router that functions as a PE router when the
maximum-paths number-of-paths import number-of-paths command is enabled. The symptom
occurs when the path attributes are changed dynamically instead of the path being completely
withdrawn and readvertised.
Workaround: Withdraw the prefix from the remote PE router and then readvertise the prefix.
• CSCee86530
Symptoms: A BGP update that is sent to a connected P router fails to report the martian next-hop
log message when the next-hop field in the attribute of the BGP update is set to 255.255.255.255
(that is, all 1’s). The P router does deny the advertisement of the MP_REACH_NLRI attribute to the
other PE routers, but there is no log message to indicate that it is denying the advertisement and why
it does so.
Conditions: This symptom is observed during MP-BGP negative testing for the MP_REACH
attribute.
Workaround: There is no workaround.
• CSCee88542
Symptoms: A Cisco router may reload unexpectedly when you enter the show ip msdp peer
command.
Conditions: This symptom is observed when the MSDP session flaps while you enter the show ip
msdp peer command.
Workaround: There is no workaround.
• CSCef91275
Symptoms: An MPLS TE tunnel stays stuck in the “Path Half Admitting” state, as is shown by the
output of the show mpls traffic-eng tunnel command, thereby preventing the tunnel from coming
up.
Conditions: This symptom may be observed when a particular third-party router that functions as
the headend for the MPLS TE tunnel sends a Path message to a Cisco router that functions as the
midpoint for the router MPLS TE tunnel and that does not have the mpls traffic-eng tunnels
interface configuration command enabled on the outbound interface that would be used to forward
the Path message.
Workaround: Enter the mpls traffic-eng tunnels interface configuration command on the outbound
interface of the Cisco router. Then, enter the shutdown interface configuration command followed
by the no shutdown interface configuration command on this interface, and save the configuration.