Open Caveats Prior to WSG Release 3.1.3
The following caveats are unresolved in this release:
- CSCtw67551—SNMP walk of the ipv6InterfaceTable doesn't return any information
Description: When trying to SNMP walk or get the ipv6InterfaceTable IP-MIB, the WSG does not return any information:
segw-n240:9> snmpwalk -c public 220.127.116.11 .18.104.22.168.22.214.171.124
Also, the WSG does not return any information for the IPv6 addresses when walking the ipAddrTable (ipAddrEntry). If more than one RADIUS server is configured, and the first RADIUS server is not working, WSG is not able to set up an IPSec tunnel.
- CSCty03287—WSG returns incorrect values for Enhanced-Ipsec-Flow SNMP MIB objects
Description: This occurs if a SNMP getnext is the first opertation performed on the objects after the tunnel is established.
Workaround: Do not perform getnext immediately after establishing the tunnel. If the getnext operation is the first one performed, the returned values will be correct after the tunnel has been established for at least 15 minutes.
- CSCtx65537—WSG logs 16 to 21 blocked rekeys when IPSec SA rekey occurs for blacklisted peer
Description: This occurs when blacklisting is enabled or resynced after tunnel establishment, and rekey occurs for a blacklisted peer.
Workaround: None. However, since the rekey is blocked, no rekey messages are sent to the blacklisted peer.
- CSCto86729—WSG linux is not gracefully shutdown when using SAMI removal procedure
Description: WSG linux application may not shutdown when using the specific removal procedures indicated in the SAMI IOS procedure manual.
Workaround: Use no power enable in configuration mode to completely shutdown the SAMI.
- CSCtq16332—Standby WSG shows remnant IKE SA's due to missing exported delete
Description: Standby WSG shows remnant IKE SA's which no longer exist on the active WSG. The high-availability state seems to be fine. This occurs when the configured remote traffic selector has a wider subnet than the configured WSG traffic selector. During the WSG-initiated Phase 2 rekey, the smaller subnet will be sent, the rekey will fail, and the tunnel will be deleted on the active card when the SA lifetime expires. The IPSec SA on the standby card will be deleted, but the ISAKMP SA will remain. If this happens to a large number of tunnels, the standby could run out of available ISAKMP SAs.
Workaround: Reboot the standby WSG.
- CSCtr73790—WSG does not query the next available IPv6 address of the CRL
Description: If the DNS server returns both an IPv4 and IPv6 address for the domain name of the HTTP/LDAP server, the WSG will only attempt the IPv4 address. If the IPv4 address fails, the WSG won't attempt the IPv6 address, and the tunnel setup will fail.
- CSCts72607—Tunnels torn down after copy start run
Description: Normally, the “copy start run” command is used at the begining of setup. In a case where the user used this command after the tunnels were created, we observed all of the tunnels were torn down (e.g. the start and running configurations were the same). This bug was filed to find a way to avoid it.
- CSCts80965—SNMP walk on some global stats does not show correct value
Description: The values returned by snmpwalk on ceipSecGlobalStats and some cikeGlobalStats objects are not accumulated across all PPCs.
- CSCth84463—HA: snmpwalk on CISCO-ENHANCED-IPSEC-FLOW-MIB stops abrubtly on switchover
Snmpwalk on CISCO-ENHANCED-IPSEC-FLOW-MIB stops.
The HA switchover occurs during the snmpwalk.
Workaround: Re-run the snmpwalk after the switchover is complete. The required statistics are not available immediately after the switchover
- CSCti57743—HA: IKEv1 S2S tunnels with MCSA: Standby Rekey Deletion Failures
Standby Card shows Child SAs (MCSA scenario, originally associated with same IKE SA) split to different IKE SAs.
MCSA scenario: The individual child SAs originally associated with one IKE SA, splits on P1 rekey. The above IPSec SAs end up having their independent IKE's on the standby card. The condition eventually gets resolved after the next P2 rekey.
This might happen to about 5% of all the IPSec SAs.
- CSCsy93899—Small Number of IPSec Tunnels are Deleted After a Phase-2 Re-key
After a phase-2 re-key, a small number of IPSec tunnels (approx. 10-20) may be deleted.
This has been seen with large number of tunnels (8500 tunnels on each PPC) established at a high rate and the lifetime was set to a short value in an engineering environment.
- CSCta29658—Phase-1 Re-keys Stop After WSG Receives Bad CREATE_CHILD_SA Response
Description: Gateway-initiated IKE SA re-key exchanges do not occur, but IPSec SA re-key exchanges occur as expected.
– IKEv2 protocol is used.
– The IPSec client experiences a re-key overlap condition such that an IKE SA rekey exchange occurs while an IPSec SA re-key is in progress, that is, the re-key exchange is successful, but the old IPSec SA is not yet deleted.
Workaround: If the client supports re-key initiation, the IKE SA re-key is handled by the client. This is a rare situation that was only observed on one particular IPSec client.
WSG Release 3.1.3—Resolved Caveats
The following caveat is resolved in WSG Release 3.1.3:
- CSCuc65113 — LCP Sysmgr Crash Due To Proc Mem Info Corruption
Description: Core Dump File includes Proc Mem Info Details. LCP Sysmgr crashes due to Proc
Memory Info Corruption.
The following caveats were resolved in WSG Release 3.1.2:
- CSCuc45124—Traffic fails on tunnel after IPSec SA rekey on a neighboring PPC
Description: Traffic fails on an IPSec tunnel. The tunnel does not pass traffic until a subsequent IPSec SA (phase-2) rekey occurs on the same tunnel.
– Remote access tunnels are terminated on WSG.
– Tunnels are terminated on two adjacent PPCs (e.g. 3 and 4, or 7 and 8).
– Multiple traffic selectors are configured or negotiated for the tunnels terminating on the higher numbered PPC.
– A phase-2 rekey occurs on a tunnel terminating on the higher numbered PPC. This triggers the traffic loss on a tunnel terminating on the lower numbered PPC.
Workaround: If remote-access tunnels with multiple traffic selectors are needed, do not terminate tunnels on an adjacent, lower numbered PPC.
- CSCtz71369 —asciiPending SAPS 611 wipes out the WSG configuration and enters into a cfg file
Description: The WSG has no configuration after a reboot. The startup configuration is corrupted.
– An error condition is encountered which prints an error message into the running configuration when it is displayed using the show running-configuration command. A "SAP->611" error is an example of such an error.
– The user attempts to save the running configuration.
– A WSG reboot occurs.
Workaround: If an error message is displayed during the execution of the show running-configuration command, do not attempt to save the running configuration.
- CSCub32115—Standby WSG usurps the primary MAC address
Description: The standby WSG will sporadically usurp the MAC address of the active WSG and announce itself causing ARP resolution to fail. This issue can also cause a failure to pass traffic on newly added routes. This issue is seen intermittently in a redundant HA setup when there is no traffic for a period longer than 5 minutes.
Workaround: Configure mac mac-address table timeout to 4 hours on the appropriate VLAN. Adding new routes requires a WSG reload to take effect.
- CSCub82872—WSG infra should send the appropriate msg when tearing the PPC VLAN down
Description: Traffic does not pass through the WSG even though the IPSec tunnel is successfully established. This issue has been observed after configuration changes to VLAN interfaces on different WSG instances (i.e. PPCs) on the same SAMI. Typically, the VLANs are reused but moved to interfaces on different WSG instances.
Workaround: Reload the SAMI.
- CSCtz92610—WSG is dropping all traffic in IXP due to wrongly HA bit programmed
Description: ESP packets are dropped at the WSG. This issue occurs when the VLAN currently configured on a PPC was previously configured on a lower numbered PCC and the SAMI was not reset since that last configuration change. The information pertaining to the previously configured VLAN is not removed from memory when the configuration changes.
Workaround: Reload the SAMI.
- CSCsq81533—System Manager (core-server) crash - incorrect reloading system syslog
Description: The following message may appear in the system log. However, the system does not reload:
Jun 9 2008 00:53:01 : %ACE-2-443001: System experienced fatal failure.Service name:System Manager (core-server)(30822) has terminated on receiving signal 11,reloading system
This process is not supposed to initiate a system reset. It is spawned upon demand and will be re-created as necessary.
Workaround: The message for this process should read “NOT reloading system.”
The following caveats were resolved in WSG Release 3.1.1:
- CSCth85737—WSG denies IKEv2 phase 1 rekey with multiple proposals
Description: Symptom occurs when the client is configured with multiple proposals for phase 1 algorithms. The SA is negotiated properly at tunnel bring-up. Yet, the multiple proposals are sent by the client during rekeys and WSG denies that negotiation.
Workaround: Configure the client with a single proposal. Alternatively, rekeys can be initiated by configuring a shorter lifetime on the WSG.
- CSCtx84326—Removal of BGP related config off WSG may result in abnormal SAMI reload
Description: With a BGP related configuration for the WSG Reverse Route Injection (RRI) feature, the removal of the BGP configuration off the WSG may result in an abnormal SAMI reload.
Workaround: Block the BGP neighbors from sending any routes to the WSG. Remove the BGP neighbor configurations one by one before removing the BGP configuration.
- CSCty52622—WSG BGP reset for first time in config mode after card reset
Description: The WSG has just reloaded, and a tunnel is successfully established. BGP then restarts after executing the router bgp <local-asn> command.
Workaround: None. However, this only happens once after the WSG reload.
- CSCtx87552—BGP peer session stuck in “Clearing” state
Description: This occurs after connectivity is lost with the BGP neighbor for more than 3 minutes.
Workaround: Remove and re-add the BGP neighbor configuration.
- CSCty05335—WSG delay sending BGP Update to Sup/RSP when a tunnel is created
Description: A 10 to 30 second traffic loss is observed after IPSec tunnel establishment. This occurs when a WSG BGP configuration is used in an MPLS VPN environment.
- CSCty22497—Flapping BGP session between WSG and Sup when 30 or more IPv6 tunnels setup
Description: Symptoms include all BGP routes are not injected to the 7600 Sup and BGP adjacency changes are observed. This occurs when at least 30 IPv6 tunnels are established at 45 tunnels per second... and WSG interface VLAN MTU is configured to a value greater than default.
Workaround: Use default WSG VLAN interface MTU setting.
- CSCtx81465—BGP removal doesn't properly clean up the configuration
Description: The internal BGP configuration is not completely removed. This occurs when the user executes the no router bgp <local-asn> command prior to deleting the BGP neighbors from the configuration.
Workaround: Delete the underlying BGP neighbor configuration prior to executing the no router bgp <local-asn> command.
- CSCty08345—RRI route add/delete counter is increasing when RRI route Invalid occurs
Description: RRI statistics are incorrect after an invalid route is detected. Invalid routes are incorrectly shown as added or deleted. This occurs when HA configuration RRI is used on WSG and the statistics are displayed using the show crypto ha stats command.
- CSCty74802—Few RRI routes deleted by standby WSG when 16666 clients P1-P2 rekeys
Description: Some routes are deleted from the standby WSG. This occurs with an HA configuration when 16666 tunnels terminate on the WSG and rekeys initiate by client.
- CSCty92834—HA redundancy lost with 3 Gig bi-directional traffic
Description: Lost HA redundancy when traffic is transmitted. This occurs when HA redundancy has been configured. As soon as traffic of 2.6 Gig or more is transmitted, the redundant PPC is reloaded due to missed HA heartbeat messages.
Workaround: Lower the traffic rate.
- CSCtz10823—Clear traffic does not pass through WSG in Active-Active/Standby mode
Description: With HA redundancy configured, traffic does not pass through the WSG from the clear side on all established tunnels except the first tunnel. This occurs when HA redundancy has been configured. Establish 12 IPSec (S2S) tunnels and push a small amount (10 MB) of bi-directional traffic. Observe that while traffic is passing through in both directions, it only passes through from the encrypted side on all remaining tunnels. Clear traffic is being dropped by the WSG.
The following caveats were resolved in WSG Release 3.0:
- CSCtg36835—Assertion on Attempting ssh-cmpclient INITIALIZE
The CMP initialize command returns error when executed.
This occurs when the access method (as indicated in the URL) to the CA server is TCP.
Workaround: Use the HTTP access method (http://...) in the CMP initialize command to communicate with the CA server.
- CSCtg65867—snmpd on Secondary PPC Gets Stuck
sh run in entity-all fails on one or another secondary PPC. snmpd does not respond to configuration request and times out with SAPS-->28 error.
This conditiona occurs when you execute snmpwalk on UDP-MIB in continous loop with sleep 200 usecs in between two successive iterations. In entity-all mode execute the show running-config command. snmpd on one or more secondary PPCs timeouts with SAPS-->28 error.
Workaround: On the bash shell of the secondary that got stuck, issue killall -9 snmpd command. This causes snmpd to re-spawn again.
- CSCth53865—HA: WSG Deletes Tunnels After Switchover
The WSG deletes tunnels after an HA switchover.
This conditions rarely occurs when there are 100,000 remote-access tunnels established. With 100,000 tunnels established, 12 were deleted.
- CSCth86683—snmpwalk, snmpget Misses Data From Secondarys Periodically
SNMP walk may periodically fail to poll MIB instances/elements on secondary WSGs.
SNMP walk fails to poll data from secondary WSG/PPC periodically. This situation occurs when CPU utilization on primary WSG increases considerably. However, the CPU utilization on secondary WSG always remain normal. High CPU utilization situation remains for very brief time period. The whole issue is not observed on tunnels established on primary WSG.
- CSCti00586—HA: StandbyWSG Cannott Recover From Failed SA Import
In the rare instance where a tunnel is not fully imported on the standby card, the standby cannot recover the tunnel from this issue.
To see if the standby card has a tunnel in this state, issue the show crypto isakmp summary command and show crypto ha db info command. This will show if a tunnel count mismatch has occurred.
Workaround: Reboot the standby card to force a new sync of the tunnels.
- CSCti06262—HA: snmpd Process Crashed on Active/SAMI Module
Observed SNMP crashinfo on SUP related to primary WSG/PPC3.
This condition occurred when we configured an SNMP related configuration on primary WSG/PPC. Leave these commands configured on the primary WSG for overnight tests. You may observe SNMP crashinfo files (on SUP disk0) due to SNMP process crash and re-initialization.
- CSCtd27881—Site-to-Site IKEv2 Phase 2 Rekey Does Not Happen For All Child SAs
WSG Initiated IKEv2 Phase 2 rekey happens only for one child SA.
IKE SA with multiple child IPSec SAs, with Phase 2 rekeys initiated by WSG (client Phase 2 rekey lifetime > the Phase 2 lifetime configured on WSG).
Workaround: Initiate rekeys from the client side (configure client Phase 2 rekey lifetime < WSG Phase 2 lifetime).
- CSCtd82379—Source Port Field is Not Updated Under show crypto ipsec sa remote-ip Display
The UDP source port is not correctly displayed using the show crypto ipsec sa remote-ip command.
This problem occurs under the following conditions:
– IPSec tunnel is established via a device performing PAT.
– A condition triggers a source port change (for example, a timeout).
Workaround: Use the show crypto isakmp sa command to display the UDP source port.
- CSCtd87234—ipsecpm Process Failed With auto-initiate and rsa-sig authentication
The ipsecpm process failed after tunnel failure with auto-initiate.
The ipsecpm failure is observed with the following conditions:
– authentication rsa-sig
– IKE ID for the remote peer does not match the DN, and Certificate does not include a subjectALtName extension.
Workaround: Configure the remote peer to use DN as the ID.
- CSCte17787—Authentication failed sometimes with more than one trustpoint configured
Authentication sometimes fails when there is more than one trust point configured.
If you have two trust points configured, two entries of get certificate request in IKE_SA_INIT all point to the certificate in the first trust point.
Workaround: One trust point works.
The following caveat was resolved in WSG Release 2.2.2:
- CSCtr15452—Tunnel creation fails, "No Certificate Found Anywhere" is logged on WSG
Description: IPSec tunnel establishment fails when certificate based authentication is used. The messages "Certificate Path Construction Failed" or "No Certificate Found Anywhere" appear in the WSG event log. This symptom occurs when the certificates in use have an entry for "CAIssuers" in the AIA extension.
Workaround: Use certificates that do not use “CAIssuers” in the AIA extension.
The following caveats were resolved in WSG Release 2.2.1:
- CSCtq87296—WSG sends DHCP release prematurely under certain conditions
Description: The WSG sends DHCP release prematurely under certain conditions:
1. Access Point reboot on an existing IPSec tunnel.
2. The reboot cycle occurs before the WSG can delete the IPSec tunnel via dead-peer-detection.
The WSG sends the DHCP release when the old tunnel is deleted.
Workaround: The client IP address is re-assigned via DHCP when the IKE SA is rekeyed, provided
the address is still available. Otherwise, the tunnel is torn down, requiring re-establishment by the Access Point.
- CSCtq89837—WSG allows tunnels to be established with remote peer ID not matching the ID in the remote peer certificate
Description: WSG allows tunnels to be established with remote peer ID not matching the ID in the remote peer certificate. This issue is seen in 2.X images.
The following caveats were resolved in WSG Release 1.2:
- CSCta55527—show crypto isakmp summary IKE Error Counters do not Increment Though SA's Deleted
Description: Some tunnels are deleted by WSG. The corresponding IKE error counters do not show any errors.
This happens in multiple circumstances:
1. Immediately after a large number of tunnel creation (For example, when creating tunnels at 90 tunnels per second).
2. If the client does not respond to the INFORMATIONAL messages (and probably the IKE timeout happens).
- CSCtb18406—Snmpwalk Returned 0 For All Tunnel Instance Statistics
Description: The snmpwalk utility returns zero values for all instance statistics (per tunnel in/out packets and octets) for the cisco-enhanced-ipsec-flow-mib table.
Workaround: Use the snmpget utility to see valid statistics for each specific instance.
- CSCtb30242—Syslogd crashinfo File Created After SAMI Reset
Description: Crashinfo files for syslogd are created and saved to the SUP. No other problems are observed with syslog after the SAMI comes up. The files are saved to the SUP after the SAMI is reset. This could occur after upgrading the software image (a reset is required to complete the upgrade), or simply resetting the SAMI card.