Table Of Contents
Upgrading or Downgrading the Software
Catalyst 6500 Series Requirements
Cisco 7600 Series Requirements
New Features in Release 4.0(5) through 4.0(17)
New Features in Release 4.0(4)
New Features in Release 4.0(3)
New Features in Release 4.0(2)
New Features in Release 4.0(1)
Resolved Caveats in Software Release 4.0(17)
Resolved Caveats in Software Release 4.0(16)
Resolved Caveats in Software Release 4.0(15)
Resolved Caveats in Software Release 4.0(14)
Resolved Caveats in Software Release 4.0(13)
Resolved Caveats in Software Release 4.0(12)
Resolved Caveats in Software Release 4.0(11)
Resolved Caveats in Software Release 4.0(10)
Resolved Caveats in Software Release 4.0(8)
Resolved Caveats in Software Release 4.0(7)
Resolved Caveats in Software Release 4.0(6)
Resolved Caveats in Software Release 4.0(5)
Resolved Caveats in Software Release 4.0(4)
Resolved Caveats in Software Release 4.0(3)
Resolved Caveats in Software Release 4.0(2)
Resolved Caveats in Software Release 4.0(1)
Obtaining Documentation and Submitting a Service Request
Release Notes for the Catalyst 6500 Series and Cisco 7600 Series Firewall Services Module, Software Release 4.0(x)
November 2011
This document contains release information for FWSM Release 4.0(1) through 4.0(17).
Note
Release 4.0(9) is no longer available. See the "Important Notes" section for more information.
This document includes the following sections:
•
•
Important Notes
•
•
•
•
•
•
Upgrading or Downgrading the Software
To upgrade from 2.x or 3.x to 4.0, see the "Managing Software, Licenses, and Configurations" chapter in the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using the CLI. Be sure to save a copy of your 2.x or 3.x configuration if you later want to downgrade.
After you reload the FWSM with the 4.0 image, the configuration is converted (for example, the http-map commands are converted to policy-map type inspect http commands). This converted configuration is not saved to memory until you enter the write memory command (or the write memory all command from the system execution space in multiple context mode).
If you try to downgrade using a converted configuration, many commands will be rejected. Moreover, if you add access lists to the 4.0 configuration to take advantage of larger access list memory space, then downgrading could result in an inability to load all the new access lists.
If you want to downgrade, be sure to copy a saved 2.x or 3.x configuration to the starting configuration before you reload with the 2.x or 3.x image.
Chassis System Requirements
You can install the FWSM in the Catalyst 6500 series switches or the Cisco 7600 series routers. The configuration of both series is identical, and the series are referred to generically in this guide as the "switch." The switch includes a switch (the supervisor engine) as well as a router (the MSFC 2).
The switch supports Cisco IOS software on both the switch supervisor engine and the integrated MSFC router.
Note
The FWSM does not support a direct connection to a switch WAN port because WAN ports do not use static VLANs. However, the WAN port can connect to the MSFC, which can connect to the FWSM.
The FWSM runs its own operating system.
This section includes the following topics:
•
•
Catalyst 6500 Series Requirements
Table 1 shows the supervisor engine version and software.
Table 1 Support for FWSM 4.0 on the Catalyst 6500
12.2(33)SXI7
720-10GE
No
Yes
Yes
12.2(33)SXI7
720
No
Yes
No
12.2(33)SXJ1
720-10GE
No
Yes
Yes
12.2(33)SXJ1
720
No
Yes
No
12.2(33)SXJ1
32
No
Yes
No
12.2(33)SXJ
720-10GE
No
Yes
Yes
12.2(33)SXJ
720
No
Yes
No
12.2(33)SXJ
32
No
Yes
No
12.2(33)SXI6
720-10GE
No
Yes
Yes
12.2(33)SXI6
720
No
Yes
No
12.2(33)SXI4
720
No
Yes
No
12.2(33)SXI4
720-10GE
No
Yes
Yes
12.2(18)SXF and higher
720, 32
No
No
No
12.2(18)SXF2 and higher
2, 720, 32
No
No
No
12.2(33)SXI
720-10GE
No
Yes
Yes
12.2(33)SXI
720
No
Yes
No
12.2(33)SXI
32
No
Yes
No
12.2(18)ZYA
32-PISA
Yes
No
No
12.2(18)SXF4
720, 32
No
No
No
1 The FWSM does not support the supervisor 1 or 1A.
Cisco 7600 Series Requirements
Table 2 shows the supervisor engine version and software.
Table 2 Support for FWSM 4.0 on the Cisco 7600
12.2(33)SRD6
720-3C-1GE
No
No
No
12.2(33)SRA
720, 32
No
No
No
12.2(33)SRB
720, 32
No
No
No
12.2(33)SRC
720, 32, 720-1GE
No
No
No
12.2(33)SRD
720, 32, 720-1GE
No
No
No
12.2(33)SRE2
720, 720-3C-1GE
No
No
No
1 The FWSM does not support the supervisor 1 or 1A.
Management Support
The FWSM supports the following management methods:
•
•
New Features
This section lists new features for each maintenance release and includes the following topics:
•
•
•
•
•
New Features in Release 4.0(5) through 4.0(17)
There were no new features in Release 4.0(5) through 4.0(17).
New Features in Release 4.0(4)
The following Cisco IOS-integrated features are now officially supported in FWSM:
New Features in Release 4.0(3)
The SCCP (Skinny) inspection has been enhanced to do the following:
•
•
The following is not supported:
•
•
New Features in Release 4.0(2)
There were no new features in Release 4.0(2).
New Features in Release 4.0(1)
Table 3 lists the new features for Release 4.0(1).
Software License Information
The FWSM supports the following licensed features:
•
–
–
–
–
•
•
Limitations and Restrictions
Note
See the following limitations and restrictions on the FWSM:
•
–
–
•
•
•
•
•
•
•
•
•
•
Open Caveats
This section contains open caveats in the latest maintenance release.
If you are running an older release, and you need to determine the open caveats for your release, then add the caveats in this section to the resolved caveats from later releases. For example, if you are running Release 4.0(1), then you need to add the caveats in this section to the resolved caveats from 4.0(2) and later to determine the complete list of open caveats.
•
When an FWSM is participating in a PIM multicast network, and the FWSM has been configured to only register certain groups with the PIM RP via an access list, registration for groups might fail even through registration should be allowed. For example, the pim rp-address command is used in conjunction with an access list like the following:
access-list pim1 standard permit 209.165.200.224 255.255.255.224access-list pim1 standard permit 209.165.201.0 255.255.255.224access-list pim1 standard deny 209.165.202.128 255.255.255.224pim rp-address 192.168.33.43 pim1This configuration should only allow the groups associated with the 209.165.200.224/27 and 209.165.201.0/27 networks to register with the RP. However, the FWSM might fail to register these groups with the RP.
Workaround: Remove the acl argument from the pim rp-address command. This will allow the FWSM to register all groups with the RP.
•
The FWSM does not send EIGRP summarized routes under some conditions immediately after a reload even though auto-summary is enabled. This occurs when EIGRP network statements exist for 40 or more interfaces.
Workaround: After the reload, wait for some amount of time (depending on the number of network statements configured) and issue the clear eigrp neighbors command.
•
When an access list has more than one access list remark command, and other ACEs form an optimization scenario, one or more remark statements are removed from the optimized output.
Workaround: None.
•
Voice traffic for SCCP calls does not go through when the FWSM is configured for NAT exemption (nat 0 access-list).
Workaround: Use identity NAT (nat 0) or static identity NAT instead of NAT exemption. Alternatively, if the configuration allows, you can disable NAT control using the no nat control command.
•
The output for the show np 3 aaa stats command shows AAA lookup failures incrementing even though all the AAA requests are successful.
Workaround: None.
•
The number of rejects shown in the show aaa-server command is incorrect; the RADIUS server reject counter is incrementing even though the RADIUS server is not sending any Reject messages.
Workaround: None.
•
When applying an inspection service policy, the FWSM shows the following error: portmap_index: unable to locate fixup. This occurs when the class map contains any match statements other than match port.
Workaround: Use a class-map that matches a port or use the class-inspection-default class map.
•
The FWSM blocks certain RTSP streams.
Workaround: Permit all RTSP ports.
•
ICMP Traceroute does not work across an FWSM when the traffic is routed asymmetrically between two physical FWSMs in failover. ICMP Type 11 (Time Exceeded) responses are arriving at a location that is different from the originating FWSM. This happens because the ICMP connections are not statefully replicated to the failover peer even with ICMP inspection enabled.
Workaround: Do not route traffic asymmetrically; or use UDP Traceroute instead.
•
After the FWSM fails over with H.323 inspection enabled, active H.323 connections through the FWSM might be disconnected. You have to re-establish the connections.
Workaround: If no NAT is being performed by the FWSM, disable the H.323 inspection and permit all necessary connectivity between the H.323 endpoints explicitly via the access lists on the FWSM.
•
With Skinny inspection enabled, some returning traffic does not get through. Therefore, phone calls only get unidirectional voice (the flow does not go through from outside to inside). This issue appears more frequently with a large number of calls.
Note
Workaround: None.
•
With a large number of ACEs configured (for example, 51,000 for single mode or 14,000 for multiple mode), if you disable access list optimization, the console might hang for 5 to 6 minutes.
Workaround: None. If you wait, the console will return.
•
When using failover, if you copy new configurations with access list and object group changes to multiple contexts simultaneously, it can result in failed synchronization to the standby unit.
Workaround: Copy context configurations one at a time.
Resolved Caveats
This section includes the following topics:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Resolved Caveats in Software Release 4.0(17)
The following caveats were resolved in Release 4.0(17) and were not previously documented. If you are a registered Cisco.com user, you can view more information about a caveat using the Bug Toolkit at the following website:
Resolved Caveats in Software Release 4.0(16)
The following caveats were resolved in Release 4.0(16) and were not previously documented. If you are a registered Cisco.com user, you can view more information about a caveat using the Bug Toolkit at the following website:
Resolved Caveats in Software Release 4.0(15)
The following caveats were resolved in Release 4.0(15) and were not previously documented. If you are a registered Cisco.com user, you can view more information about the caveat using the Bug Toolkit at the following website:
•
Symptom:
The device may be affected by an OpenSSL vulnerabilities described in CVE-2010-4180 and CVE-2010-4252.
Conditions:
Device configured with any feature that uses SSL.
Workaround:
Not available
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 5.1/3.8:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:N/AC:L/Au:N/C:C/I:C/A:C/E:H/RL:U/RC:C
CVE IDs CVE-2010-4180 and CVE-2010-4252 have been assigned to document this issue.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
•
Symptom:
Certain commands like 'show running-config', 'show interface' are allowed to be executed by users with lower privilege-level when fallback has occurred.
Conditions:
1. Fallback to LOCAL is configured
2. All FWSM commands are assigned their default privilege levels in LOCAL db.
3. Users with lower privilege-level than 15 login into privileged-exec mode and execute 'show running-config' or 'show interface' commands, and some config commands.
Workaround:
none.
PSIRT Evaluation:
The Cisco PSIRT has assigned this bug the following CVSS version 2
score. The Base and Temporal CVSS scores as of the time of evaluation are 6.0/5.0:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:L/AC:H/Au:S/C:C/I:C/A:C/E:F/RL:OF/RC:C
CVE ID CSCtl94142 has been assigned to document this issue.
Additional information on Cisco's security vulnerability policy can befound at the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
•
A vulnerability exists in the Cisco Firewall Services Module (FWSM) for Cisco Catalyst 6500 Series Switches and Cisco 7600 Series Routers that may cause the Cisco FWSM to reload after processing a malformed Skinny Client Control Protocol (SCCP) message. Devices are affected when SCCP inspection is enabled.
Cisco has released free software updates that address this vulnerability.
This advisory is posted at
http://www.cisco.com/warp/public/707/cisco-sa-20110223-fwsm.shtml
Note: Cisco ASA 5500 Series Adaptive Security Appliances are affected by the vulnerability described in this advisory. A separate Cisco Security Advisory has been published to disclose this and other vulnerabilities that affect the Cisco ASA 5500 Series Adaptive Security Appliances. The advisory is available at
http://www.cisco.com/warp/public/707/cisco-sa-20110223-asa.shtml
Resolved Caveats in Software Release 4.0(14)
•
When the FWSM is in single mode and running Version 4.0.11 or later, output of the show version command may show "<system>," even when in single context mode.
Workaround: None. This situation is cosmetic only.
•
In all versions of FWSM in major builds 3 and 4, the term pager ## command in privileged EXEC mode changes the pager for all current sessions and future sessions. According to the purpose of this command, it should only affect the session in which it is run.
Workaround: None.
•
When you have an FWSM with TCP state bypass configured, the FWSM does not send back an RST-ACK packet when it receives a non-syn TCP packet that does not match a currently-established connection. We are seeing many of syslogs, such as 106015 - "Deny TCP (no connection)" for endpoints, related to this connection.
The FWSM should be sending a RST-ACK back to this endpoint to have it open a NEW connection with a SYN. Instead, the client never gets a RST-ACK and continues to retransmit before opening a new connection.
Workaround: Remove the TCP state bypass configuration.
•
When you try to perform RTSP streaming from SonyEricsson K801i and C702, and so on, then FWSM does not open pin holes.
Workaround: Define the specific routes for client and server for a bridge group.
•
When the configured interface is removed on FWSM version 4.1.2 the management-access command is left behind and incomplete if the interface configured for management access is removed. This orphaned command cannot be removed using the no form of the command.
This condition may exist on other software builds, as well.
Workaround: Remove the management access configuration with the clear configure management-access command.
•
When state-bypass was configured at one time and had been removed from the configuration, FWSM does not log the Deny TCP no connection or send RST back for a non-syn TCP packet.
Workaround: Ensure that state-bypass is not in the startup-configuration, and reload the FWSM.
•
When an FWSM is running Version 4.0, and the service reset no-connection command is configured (in admin context if multi-mode), then the FWSM does not send RSTs back to the host for outbound non-syn TCP segments when no connection exists.
The following is sample output from the show np [1|2] global-table command:
`- Tcp Reset Enabled: 00 = do not send RST1 = send RSTWorkaround: Remove and reapply the service reset no-connection command.
•
When you enter the copy optimized-running-config command on an FWSM with optimized ACLs, the resulting ACL copied into the running-config is corrupted and missing large portions.
Workaround: Do not run the copy optimized-running-config command. This command serves only to copy the optimized ACL back into the running configuration. It is not required for ACL optimization to function.
•
When you have two separate class-maps configured, one for "application inspection" and the other for "tcp-state-bypass" with deny ACEs for traffic that need "application inspection," though the traffic hits the deny ACE for the class-map whose action is "tcp-state-bypass," the same traffic still does not pass through any other application inspection configuration leading to protocols like FTP, which need dynamic ports to be opened to not work.
Workaround: Either open all ports for the hosts that need application inspection, which is a security concern, or remove the tcp-state-bypass configuration, both of which might lead to connectivity issues.
Resolved Caveats in Software Release 4.0(13)
•
The standby device reloads when you add TCP to an object group within an access list in port 0.
Workaround: Do not use port 0 for TCP.
•
Multiple policy NAT statements might not match right until you recompile the ACL. If you configure two policy NAT statements that overlap, and the first policy NAT ACL uses object groups, when a second policy NAT statement is added that overlaps (the ACL could also match the traffic but is less specific), the xlate is built using the new NAT entry.
Workaround: Edit either one of the policy NAT ACLs in any way and then recompile. The problem disappears.
•
When FWSMs are configured for failover mode with dynamic NAT, and failover is triggered after a considerable amount of dynamic NAT xlate's have been created or deleted, an error message appears on the newly-formed active blade.
Workaround: Entering the clear xlate or clear local-host can resolve the issue.
•
A "FWSM np completion-unit disabled" operation that is performed after reboot is not activated; however, it appears in the startup configuration.
Workaround: Disable and enable again after startup.
•
Performing an snmpwalk on the admin context shows only the failover IP address in the "ipAdEntAddr" table.
Workaround: Use another context to perform the snmpwalk.
•
When the FWSM is running Version 4.0(x) with skinny inspection enabled, FWSM may reload with traceback in Thread Name: skinny.
Workaround: Disable skinny inspection.
•
This caveat communicates a change to the way the firewall handles flows (after a failover) that are subjected to the TCP proxy.
The TCP proxy feature on the firewall is active for connections that require higher-level inspection. For example, if the inspection engines are enabled for certain traffic flows, such as SQLnet or voice signalling traffic, the TCP proxy feature on the firewall ensures that the firewall receives the complete TCP data to perform complete traffic inspection.
This code change implements a change whereby if a failover takes place as the active firewall is processing TCP traffic subjected by the proxy. When the old standby firewall becomes active, it will update the state of the TCP connection when traffic is received on that TCP. Therefore, it will update its TCP state for the connection according to the traffic received from the TCP endpoints, and the TCP connection should continue to flow correctly.
Before this change, if a failover occurred while the firewall was processing traffic subjected to the TCP proxy, the new active firewall might not have an up-to-date connection state for that TCP, causing the firewall to send inappropriate ACKs to the TCP endpoints and to update their TCP state to match that of the firewall. This situation could cause a storm of traffic, as the firewall and the TCP endpoints both try to update each other with their version of the "correct" TCP state, the CPU on the firewall might be high, and the connectivity through the firewall for these flows might suffer.
Workaround: None.
•
When you try to log into the FWSM through SSH when primary TACACS fails, the first try always fails.
Workaround: Reconnect after the failure, and log in again. The second try succeeds.
•
In FWSM Version 3.2(10), entering the sunrpc-server command will only work with /32 masks defined if using Server IP host. If you want to use the network mask, then you need to define the network IP. If you are using the Server IP address and the network mask, it will not work. It will not trigger the sunrpc-server.
Workaround: Define mask /32 is using Server IP host. Define network IP is using network mask
•
A FWSM that running Version 4.0(11) might crash at Thread Name: PAT XlateCache.
Workaround: None.
•
After you upgrade an FWSM from Version 4.0(8) to Version 4.0(12) in an IPV6 environment, the CPU usage is high, about 99%.
Workaround: Temporarily downgrade to Version 4.0(8). The CPU usage should return to the normal baseline usage.
Resolved Caveats in Software Release 4.0(12)
•
When using SIP inspection, the connection table continuously increases with stuck SIP media connections. The SIP inspection does not clear them automatically.
Workaround: Enter the clear xlate command to clear all connections.
•
With failover enabled, OSPF takes a long time to reach fully loaded state with OSPF neighbors.
Workaround: Use static routes.
•
When you have a large number of access lists (over 100,000) and access-list optimization is enabled, access lists may not compile as expected.
Workaround: Disable access-list optimization.
•
The snmpget command is failing for the following parameter:
CISCO-UNIFIED-FIREWALL-MIB::cufwUrlfServerStatus
snmpwalk responds back with a value, but snmpget fails for the same OID.
For example:
# snmpwalk -On -v 2c -c SEGE sdhq-fwm-02-01.1.3.6.1.4.1.9.9.491.1.3.3.1.1.5.1.3.6.1.4.1.9.9.491.1.3.3.1.1.5.1.4.10.80.24.103.15868 = INTEGER:online(1)# snmpget -v 2c -c SEGE sdhq-fwm-02-01.1.3.6.1.4.1.9.9.491.1.3.3.1.1.5.1.4.10.80.24.103.15868CISCO-UNIFIED-FIREWALL-MIB::cufwUrlfServerStatus.ipv4."10.80.24.103".15868 = No Such instance currently exists at this OIDWorkaround: Use snmpwalk instead of snmpget.
The caveats listed in Table 6 were resolved in software Release 4.0(12), and were not previously documented. If you are a registered Cisco.com user, view more information about each caveat using the Bug Toolkit at the following website:
http://www.cisco.com/support/bugtools
Resolved Caveats in Software Release 4.0(11)
•
When the FWSM is configured for PAT with failover, and you force a failover, then the portmap translation fails (syslog message 305006 appears).
Workaround: None.
•
If an additional firewall (such as the Cisco ASA 5500 series or another FWSM) is between a client and a transparent mode FWSM, then cut-through proxy/network authentication fails:
client ---- ASA --- FWSM (transparent mode/cut through proxy) --- cloudWorkaround: Disable TCP-state checking on the intermediate device (the "ASA" in the above example) by configuring TCP state bypass, or move the client to the directly-connected inside interface of the FWSM.
•
The access list optimization feature causes missing access-list entries. It appears that the problem is triggered when there is a combination of merge up and merge down access-list rules.
Workaround: Disable the access-list optimization feature using the no access-list optimization enable command. Otherwise, a potential workaround is to avoid a merge up + merge down by arranging the order of the entries.
•
With DNS guard enabled, the FWSM software sometimes reloads while deleting a DNS session.
Workaround: Disable DNS guard using the no dns-guard command.
•
Multicast bidirectional forwarding fails on the FWSM due to an incorrect forwarding entry, which can be seen with the show np 3 mroute command. This problem can be seen when using OSPF in redundant FWSM environments where the FWSM is between the multicast source and the RP. This problem was not reproducible with a single FWSM.
Workaround: Enter the clear ospf process command.
•
The TCP Sequence Number Randomization feature is not disabled on packets injected into a TCP State Bypassed connection from an interface other than the original pair and destined to a higher-security interface.
Workaround: None.
•
In failover, if you change the access list mode from manual commit to auto commit, the standby unit starts to compile the access lists again, and experiences high CPU.
Workaround: None.
The caveats listed in Table 7 were resolved in software Release 4.0(11), and were not previously documented. If you are a registered Cisco.com user, view more information about each caveat using the Bug Toolkit at the following website:
http://www.cisco.com/support/bugtools
Resolved Caveats in Software Release 4.0(10)
•
When the FWSM is configured with a static PAT command on the outside interface, if you remove the command, traffic from inside to outside is blocked. This occurs even when nat-control is disabled. To recover, you need to reload the FWSM.
Workaround: None.
•
The FWSM corrupts the ICMP checksum of ICMP unreachable traffic that passes through the FWSM. This causes the destination host to discard the packet because the checksum is not correct.
Workaround: None.
The caveats listed in Table 8 were resolved in software Release 4.0(10), and were not previously documented. If you are a registered Cisco.com user, view more information about each caveat using the Bug Toolkit at the following website:
http://www.cisco.com/support/bugtools
Resolved Caveats in Software Release 4.0(8)
•
The capture output of inspected traffic is not readable.
Workaround: None.
•
In multiple context mode, the FWSM might experience a depletion in the 16384 byte blocks if multiple contexts are subjected to SNMP polling simultaneously. Once in this condition, you must reload the FWSM.
To detect if the FWSM is in this state, enter the show blocks command and look for the line starting with "Slow Path." If the CNT column is 0 and stays 0, this issue might be the cause.
For example:
hostname# show blocksSIZE MAX LOW CNT4 1800 1790 180080 1000 976 983256 1600 1529 15861550 11575 10483 115402048 1384 1349 138316384 8192 2181 2182Additional Block pools for 16384 size blocksIP Stack 1024 1023 1024ARP Stack 512 510 512Slow Path 5500 0 0 <--- Problem hereNP-CP 1024 1017 1024Others 132 132 132Additionally, the output of the show blocks old | begin 16384 command will show output relating to SNMP:
For example:
hostname# show blocks old | b 16384Class 8, size 16384Block allocd_by freed_by data size alloccnt dup_cnt oper location0x0a7f0aa0 0x00411557 0x00a30608 44 101 0 put udp_usr_input/ifc:65535/snmp0x0a7ec780 0x00411557 0x00a30608 39 123 0 put udp_usr_input/ifc:65535/snmp0x0a7e8460 0x00411557 0x00a30608 39 132 0 put udp_usr_input/ifc:65535/snmp0x0a7e4140 0x00411557 0x00a30608 39 128 0 put udp_usr_input/ifc:65535/snmp0x0a7dfe20 0x00411557 0x00a30608 39 85 0 put udp_usr_input/ifc:65535/snmp0x0a7dbb00 0x00411557 0x00a30608 44 100 0 put udp_usr_input/ifc:65535/snmp0x0a7d77e0 0x00411557 0x0041dcc5 39 123 0 put udp_usr_input/ifc:65535/snmp...Workaround: Configure the SNMP management server to not query the following OIDs:
–
1.3.6.1.2.1.6.19.1.
–
1.3.6.1.2.1.7.7.1.
–
1.3.6.1.2.1.123.1.8.1.1.
•
Some web pages with long URLs (the length of the URL is greater than 1159 bytes) might fail to load through the FWSM when it is configured for URL filtering. This occurs when the HTTP GET is segmented across multiple TCP packets by the HTTP client, and the HOST portion of the HTTP request is not present in the first TCP packet of the GET request. This might occur with Internet Explorer, but not with Firefox.
Workaround: To mitigate this problem, do one or more of the following:
–
filter url http 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 longurl-truncate–
The caveats listed in Table 9 were resolved in software Release 4.0(8), and were not previously documented. If you are a registered Cisco.com user, view more information about each caveat using the Bug Toolkit at the following website:
http://www.cisco.com/support/bugtools
Resolved Caveats in Software Release 4.0(7)
•
With SCCP V17, the FWSM becomes inaccessible when dual stack or IPv6 traffic passes through.
Call flow:
Phone A (dual stack) --> FWSM --> CUCM (dual stack) --> FWSM -- Phone B
When Phone A calls Phone B via the FWSM and CUCM, the FWSM unexpectedly reloads.
Workaround: Remove the dual stack or IPv6 configuration on the Phones and CUCM.
•
The FWSM unexpectedly reloads with a high RTSP traffic load when RTSP inspection is enabled. This occurs with a large amount of RTSP traffic, around 42K connections/sec including RTSP traffic through the box. This software reload is not seen with a single RTSP connection.
Workaround: Disable RTSP inspection or reduce the amount of traffic.
•
When trying to distribute a large number of GLOBAL lines into OSPF on an FWSM, the OSPF process may stop processing new LSAs and no longer update the routing table of its peers.
Workaround: If possible, summarize the routes you are trying to distribute, thereby decreasing the load on the OSPF process.
The caveats listed in Table 10 were resolved in software Release 4.0(7), and were not previously documented. If you are a registered Cisco.com user, view more information about each caveat using the Bug Toolkit at the following website:
http://www.cisco.com/support/bugtools
Resolved Caveats in Software Release 4.0(6)
•
If you configure an access list allowing TFTP and attach it to a capture command configured on an interface, then for a TFTP file transfer, the capture output shows that the transfer is happening to an incorrect port on the client. Also, the size of the transferred file is not shown properly.
Workaround: None.
•
When the Auto Update Server has an action such as a replace or merge, it does not receive the Next poll message. In the output of the show auto-update command, "Next poll" information is missing even after waiting for more than 3 minutes.
Workaround: None.
•
When you configure the logging ftp-bufferwrap command, the FTP process might stop working after a period of normal operation. This happens when the FTP server is not able to open the data connection during the active FTP transfer. The FWSM FTP process will sit idle indefinitely.
Workaround: Reload the FWSM, or enter the logging host command instead of logging ftp-bufferwrap.
•
If you configure a policy static NAT statement with an access-list with the protocol of icmp and an icmp-type of echo, then when you ping through the FWSM, a static xlate is not created.
For example:
Inside PC (10.2.1.1) ------FWSM------Outside PC (10.1.1.65)
access-list test permit icmp host 10.2.1.1 any echoaccess-list test permit icmp host 10.2.1.1 any echo-replystatic (inside,outside) 10.1.1.68 access-list testThen when you ping from 10.2.1.1 to 10.1.1.65, a static xlate is not created.
Workaround: Add an ACE without the ICMP type specified.
•
SNMP polling when a user deletes an access list in manual mode causes 99% CPU and a nonresponsive console on the FWSM. When the FWSM console is nonresponsive, the following messages are seen continuously in snmp-polling pc:
SNMPv2-SMI::enterprises.9.9.278.1.1.1.1.2.3.110.101.119 = INTEGER: 2
SNMPv2-SMI::enterprises.9.9.278.1.1.1.1.2.3.97.108.112 = INTEGER: 2
Workaround: Change the commit mode to auto using the access-list mode auto-commit command.
•
Occasionally, the FWSM unexpectedly reloads when you enter the show failover history command.
Workaround: None.
•
The snmpwalk fails when the SNMP agent on the FWSM sends the response in a non-lexicographical order.
Workaround: Use the -Cc option while doing a snmpwalk.
•
In transparent mode, snmpwalk on the TCP and UDP MIB does not display all the connections in the connection table.
Workaround: None.
•
In some cases, the route-monitor uses the route metric of a previously configured route instead of the present metric.
Workaround: Configure the static routes first and then add the route-monitor command.
•
In a same-security inter-interface configuration, NAT is not required. But for connections to virtual Telnet/HTTP/SSH IP addresses between same-security interfaces when NAT control is enabled, if the NAT configuration is absent, the FWSM fails to create the connection. You see the following syslog message:
%FWSM-3-305005: No translation group found for tcp src inside:<ip>/37249 dst outside:<ip>/23
Workaround: Disable NAT control using the no nat-control command, or configure NAT for the virtual IP addresses.
•
Syslog message 106100 does not show the correct access list hit count. When logging is enabled for the access list, and the access list is hit by the first packet, the syslog message shows the correct hit-count as 1, but on subsequent hits, the syslog message does not increment the access list hit count. It always shows the hit-count as 1.
Workaround: To see the correct hit count, enter the show access-list command.
The caveats listed in Table 11 were resolved in software Release 4.0(6), and were not previously documented. If you are a registered Cisco.com user, view more information about each caveat using the Bug Toolkit at the following website:
http://www.cisco.com/support/bugtools
Resolved Caveats in Software Release 4.0(5)
•
Even though SCCP inspection drops the registration message for phones containing IPv6 addresses (dual mode), the FWSM creates an entry for the SCCP phone as seen in the show skinny command output. This entry is not cleared until the FWSM is reloaded. After the registration message is dropped, if the phones keep retrying for registration, then a large number of entries are created for these phones that do not get cleared. Eventually when a large number of false entries are created, the FWSM will be unable to add further entries for phones that try to register later.
Workaround: None.
•
When using Active/Active failover, during configuration replication, the active FWSM might unexpectedly reload. When the reload occurs, the FWSM becomes unresponsive.
Workaround: To reset the FWSM, enter the hw-module module module_number reset command at the switch CLI, or power cycle the FWSM in configuration mode by entering the no power enable module module_number command, then the power enable module module_number command.
•
When you have an FWSM Active/Active failover pair, with one in an active VSS switch and the other in the standby VSS switch, then if you shut down the FWSM failover VLAN on the active switch and then enter redundancy force-switchover on the switch, you cannot session to FWSM on the standby switch from the active switch.
This issue also occurs if you shut down the failover VLAN, and then reload the FWSM in the active switch.
This issue also occurs if you change from VSS to standalone, and then back to VSS.
Workaround: For the two conditions associated with shutting down the failover VLAN, enter no shutdown for the FWSM failover VLAN on the active switch. For the condition related to changing from VSS to standalone, then you need to disable failover on both FWSMs by entering clear configure failover on the standby unit, and no failover on the active unit after you change from VSS to standalone. After you change back from standalone to VSS, you can reenable failover.
•
When using route health injection, if you perform an SSO switchover on the switch, followed by a failover of FWSMs, static routes associated with the FWSMare not seen on the newly active switch.
Workaround: Remove the route-inject command from the newly active FWSM and re-add it. Static routes will then get populated on the switch.
The caveats listed in Table 12 were resolved in software Release 4.0(5), and were not previously documented. If you are a registered Cisco.com user, view more information about each caveat using the Bug Toolkit at the following website:
http://www.cisco.com/support/bugtools
Resolved Caveats in Software Release 4.0(4)
•
Access list optimization might create an access list that is inaccurate compared to the original access list. This may cause packets to be denied when they should be permitted by the access list.
Workaround: Disable access list optimization with the no access-list optimization enable command.
The caveats listed in Table 13 were resolved in software Release 4.0(4), and were not previously documented. If you are a registered Cisco.com user, view more information about each caveat using the Bug Toolkit at the following website:
http://www.cisco.com/support/bugtools
Resolved Caveats in Software Release 4.0(3)
•
Performing a capture on the FWSM egress interface might show corrupted packets. This effect does not impact real traffic going through the FWSM.
Workaround: None.
•
After the supervisor has an SSO switchover (where the secondary supervisor now becomes primary), if you reload the FWSM, then the FWSM will hang.
Workaround: To reset the FWSM, enter the hw-module module module_number reset command at the switch CLI, or power cycle the FWSM in configuration mode by entering the no power enable module module_number command, then the power enable module module_number command.
•
If you use a time range in an access list and use manual commit of access lists, access list optimization may not take place correctly even when the access list is active.
Workaround: Use auto-commit mode for access lists.
•
When the access list is configured with the interface keyword, and the access list commit mode is manual, then if you change the interface IP address, the access list optimization will not happen correctly.
Workaround: Use auto-commit mode for access lists.
The caveats listed in Table 14 were resolved in software Release 4.0(3), and were not previously documented. If you are a registered Cisco.com user, view more information about each caveat using the Bug Toolkit at the following website:
http://www.cisco.com/support/bugtools
Resolved Caveats in Software Release 4.0(2)
•
When an outside NAT rule is configured on the FWSM and NAT control is enabled, inbound traffic not matching that rule is being silently dropped.
Workaround: There are two options for getting around this. If possible, disable NAT control by entering the no nat-control command. If there are a limited number of networks on the outside coming in, a static outside NAT rule can be configured for those specific networks. For example:
static (outside,inside) 192.168.10.0 192.168.10.0 netmask 255.255.255.0•
FWSM gives an error and discards the configuration when overlapping static commands are configured. For example:
static (inside,outside) tcp 192.168.1.100 www 192.168.2.100 www netmask 255.255.255.255static (dmz,outside) 192.168.1.100 192.168.3.100 netmask 255.255.255.255Workaround: None.
•
In rare circumstances, traffic matching a static policy NAT statement may fail with a "no translation group found" syslog message even though it matches the policy access list.
Workaround: Try redefining the policy access list with a different access list name and applying that to the static command.
•
An extra xlate (between the wrong interfaces) gets created when using static policy NAT and the no nat-control command. This seems to occur when the policy NAT access list overlaps with a network on another interface.
Workaround: If applicable, use static NAT without an access list, and filter with an access-group command.
•
In multiple context mode, if you change the system configuration and a context configuration, and reload without first saving, then you are prompted to save the configurations; the configurations get saved even after typing N at the confirm prompt.
Workaround: None.
•
When you configure TCP state bypass and match an access list in the class map that uses the time-range option, then a Telnet connection does not have TCP state bypass applied when the access list becomes active from an inactive state.
Workaround: In the class map, remove the match access-list command and add match any.
•
A crash could occur if the following conditions are met:
–
–
Workaround: Delete the ACE first and wait for optimization to complete then add the remark.
•
In an Active/Active failover configuration, you cannot disable access list optimization in a context that is active on the secondary FWSM; the CLI prompt to disable optimization appears on the primary FWSM, and not the secondary.
Workaround: On the primary unit, do the following:
a.
b.
c.
The caveats listed in Table 15 were resolved in software Release 4.0(2), and were not previously documented. If you are a registered Cisco.com user, view more information about each caveat using the Bug Toolkit at the following website:
http://www.cisco.com/support/bugtools
Table 15 Resolved Caveats in Release 4.0(2)
CSCsq71071
FWSM crash in Thread Name: doorbell_poll 0x5d05 NP2 thread
Resolved Caveats in Software Release 4.0(1)
•
Under rare circumstances when you configure AAA for network access using a RADIUS server, the FWSM might crash due to processing of authentication requests through the FWSM.
Workaround: None.
The caveats listed in Table 16 were resolved in software Release 4.0(1), and were not previously documented. If you are a registered Cisco.com user, view more information about each caveat using the Bug Toolkit at the following website:
http://www.cisco.com/support/bugtools
Related Documentation
See the following sections for related documentation:
Hardware Documents
See the following related hardware documentation:
•
•
•
Software Documents
See the following related software documentation:
•
•
•
•
•
•
•
•
Obtaining Documentation and Submitting a Service Request
For information on obtaining documentation, submitting a service request, and gathering additional information, see the monthly What's New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation, at:
http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html
Subscribe to the What's New in Cisco Product Documentation as an RSS feed and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free service. Cisco currently supports RSS Version 2.0.
This document is to be used in conjunction with the documents listed in the "Related Documentation" section.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
©2011 Cisco Systems, Inc. All rights reserved.
