Cisco Cisco IOS Software Release 12.2(33)SRE
842
Caveats for Cisco IOS Release 12.2(33)SRD through 12.2(33)SRD8
OL-10394-05 Rev. R0
DHCP Replies from the server (DHCPOFFER and DHCPACK) are not snooped by the Catalyst
6500 or Cisco 7600 and so bindings are not established. Consequence is that clients will get their
own IP Address but ARP Inspection will fail because bindings were not learned on the device.
6500 or Cisco 7600 and so bindings are not established. Consequence is that clients will get their
own IP Address but ARP Inspection will fail because bindings were not learned on the device.
Conditions: Occurs with DHCP Snooping + DAI configured on a Catalyst 6500 or Cisco 7600 in a
routed scenario (Ingress VLAN and Egress VLAN are different) and DHCP Relay performed by a
different device.
routed scenario (Ingress VLAN and Egress VLAN are different) and DHCP Relay performed by a
different device.
Workaround: Configure DHCP Snooping on both client and server side VLANs. Problem is
applicable to both Cisco IOS Release 12.2(18)SXF and Cisco IOS Release 12.2(33)SRB.
applicable to both Cisco IOS Release 12.2(18)SXF and Cisco IOS Release 12.2(33)SRB.
•
CSCsu65189
Symptoms: If router is configured as follows:
router ospf 1 ... passive-interface Loopback0
And later is enabled LDP/IGP synchronization using command
Router(config)#router ospf 1
Router(config-router)# mpls ldp sync
Router(config-router)#^Z
MPLS LDP/IGP synchronization will be allowed on interface loopback too.
Router#sh ip ospf mpls ldp in Loopback0 Process ID 1, Area 0 LDP is not configured
through LDP autoconfig LDP-IGP Synchronization : Required < ---- NOK Holddown timer is
not configured Interface is up
If the clear ip ospf proc command is entered, LDP will keep the interface down. Down interface is
not included in the router LSA, therefore IP address configured on loopback is not propagated. If
some application like BGP or LDP use the loopback IP address for the communication, application
will go down too.
not included in the router LSA, therefore IP address configured on loopback is not propagated. If
some application like BGP or LDP use the loopback IP address for the communication, application
will go down too.
Conditions: Occurs when interface configured as passive. Note: all interface types configured as
passive are affected, not only loopbacks.
passive are affected, not only loopbacks.
Workaround: Do not configure passive loopback under OSPF. Problem only occurs during
reconfiguration.
reconfiguration.
The problem will not occur if LDP/IGP sync is already in place and: - router is reloaded with image
with fix for CSCsk48227 - passive-interface command is removed/added
with fix for CSCsk48227 - passive-interface command is removed/added
•
CSCsu65225
Symptoms: TFTP from supervisor to ACE modules fail.
Conditions: Results in the inability to copy/upgrade images to standby ACE. This is due to moving
all 127.x.x.x addresses in an internal VPN routing/forwarding (VRF), which causes TFTP to fail.
all 127.x.x.x addresses in an internal VPN routing/forwarding (VRF), which causes TFTP to fail.
Workaround: ACE modules could fail-over to make standby as active and then ftp from the server
directly.
directly.
•
CSCsu77549
Symptoms: Protocol Independent Multicast (PIM) VPN routing/forwarding (VRF) neighbors not
formed.
formed.
Conditions: Occurs after line card reload.
Workaround: Delete and add back the MVPN configuration.
•
CSCsu83563
Symptoms: Multicast rate-limiters stop working after a HA switchover.
Conditions: To see this issue you have to have a HA setup with multicast rate-limiters set. In order
to see this issue the rate-limiters must have been set before the standby is booted. If the rate-limiters
are set after standby is up in HOT state, the issue is not seen after switchover.
to see this issue the rate-limiters must have been set before the standby is booted. If the rate-limiters
are set after standby is up in HOT state, the issue is not seen after switchover.