Table Of Contents
Specifications and System Limitations
Firewall Module and PIX Differences
Open Caveats in Release 1.1(4)
Resolved Caveats in Release 1.1(4)
Open Caveats in Release 1.1(3)
Resolved Caveats in Release 1.1(3)
Open Caveats in Release 1.1(2)
Resolved Caveats in Release 1.1(2)
Open Caveats in Release 1.1(1)
Resolved Caveats in Release 1.1(1)
Cisco IOS Software Documentation Set
Obtaining Technical Assistance
Cisco Technical Support Website
Definitions of Service Request Severity
Obtaining Additional Publications and Information
Release Notes for Catalyst 6500 Series and
Cisco 7600 Series Firewall Services Module Software Release 1.1(4)
Current Release: 1.1(4)—August 10, 2004
Previous Releases: 1.1(3), 1.1(2), 1.1(1)This publication describes the features, modifications, and caveats for the Catalyst 6500 series and Cisco 7600 series Firewall Services Module (FWSM) software release 1.1(4) running Cisco IOS Software Release 12.1(13)E or higher and Catalyst operating system software release 7.5 or later.
Note
For detailed installation and configuration procedures for the FWSM, refer to the Catalyst 6500 and Cisco 7600 Series Firewall Services Module Installation and Configuration Note at http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/mod_icn/fwsm/index.htm
Note
Note
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/relnotes/index.htm
Note
Contents
•
•
System Requirements
This section describes the system requirements for the Catalyst 6500 series and Cisco 7600 series Firewall Services Module software release 1.1(4).
Memory Requirements
The Catalyst 6500 series and Cisco 7600 series Firewall Services Module memory is not configurable.
Hardware Supported
Before you can use the Catalyst 6500 series and Cisco 7600 series Firewall Services Module, you must have a Supervisor Engine 1a (Catalyst operating system only) and an MSFC 2, or a Supervisor Engine 2 (Catalyst operating system and Cisco IOS) and an MSFC 2, and any module with ports to connect server and client networks.
Software Compatibility
Table 1 lists the FWSM software versions supported by Catalyst operating system software and Cisco IOS software.
Feature Set
The Firewall Services Module (FWSM) is a high performance firewall used on the Catalyst 6500 series switch and Cisco 7600 series router. The FWSM can occupy a single slot in the Catalyst 6500 series and Cisco 7600 series chassis or two slots in a redundant configuration. Two modules can also reside in separate chassis in a failover configuration.
The Firewall Services Module provides the following features:
•
•
•
•
•
•
•
•
•
•
Note
•
•
The stateful, connection-oriented ASA creates session flows based on source and destination addresses, TCP sequence numbers (which are non-predictable), port numbers, and additional TCP flags. You can control all inbound and outbound traffic by applying security policies to each connection table entry.
•
•
•
•
–
–
When the Firewall Services Module software is the platform, PDM will display modified screens for features not supported by the module. To use the PDM to configure the module, refer to the Cisco PIX Device Manager Installation Guide, Version 2.1.
The following PIX firewall features are not supported by the module:
•
•
•
•
•
Specifications and System Limitations
Table 2 lists the specifications and system limitations of the FWSM.
Table 2 FWSM Specifications and System Limitations
Modules per switch
Maximum of four modules per switch
If you are using failover, you can still have only four modules per switch, even if two of them are in standby mode.
Memory
•
•
Bandwidth
CEF256 module with a 6-Gbps path to the Switch Fabric Module (if present) or the 32-Gbps shared bus
Filtering servers
16 Websense Enterprise filtering servers
IPSec management connections, concurrent
5 connections
TCP1 or UDP2 connections between any two hosts, including connections between one host and multiple other hosts, concurrent and rate
999,900 connections
100,000 connections per second
Fixup connections, rate
10,000 per second
PC based fixup connections, rate
10,000 per second
Host connections, concurrent
256,000
SSH3 management connections, concurrent
5 connections
System messages, rate
20,000 per second
Telnet management connections, concurrent
5 connections
NAT translations, concurrent
256,000
NAT statements
1,000 statements
High-performance firewall
5 GBps (aggregated)
Concurrent connections.
1 million
Packets-per-second.
3 million pps
New connections per second for HTTP, DNS, and enhanced Simple Mail Transfer Protocol (SMTP).
7,000
VLAN interfaces (no physical interfaces on the module).
100
Static NAT statements
1,000 statements
Global statements
1,000 statements
Shun statements
2,000 statements. The FWSM supports at most 2000 shuns - that number is contingent upon finite hardware resources and cannot be increased.
Alias statements
1,000 statements
User authentication sessions, concurrent
5,000 sessions
User authorization sessions, concurrent
150,000 sessions
Maximum 15 sessions per user.
ARP4 table entries, concurrent
64,000 entries.
Route table entries, concurrent
32,000 entries.
Packet reassembly, concurrent
30,000 fragments.
Filter Rules, Fixup and Filter statements combined.
3,000 rules and statements.
Established CLI Rules
1,000 rules.
Established data
1,000 implicit rules used by TCP and UDP fixups to allow back channels.
3,000 statements.
AAA Rules
3,000 rules, 1,000 rules for authentication, 1K rules for authorization, and 1,000 rules for accounting.
1,000 rules.
ACEs
72,000 ACEs (best case).
1 Transmission Control Protocol
2 User Datagram Protocol
3 Secure Shell
4 Address Resolution Protocol
5 Internet Control Message Protocol
6 HyperText Transfer Protocol
Firewall Module and PIX Differences
The FWSM is a separate implementation from the PIX and has these differences:
•
•
•
•
•
The FWSM behavior has been changed. Overlapping or redundant static address translation entries are no longer accepted. An error is generated and the overlapping or redundant static address is not added to the configuration.
Workaround: None.
•
The FWSM tears down all the connections from or to the shunned IP address, even if specific connection parameters have been specified in the applied shun command. This behavior is different from that of PIX. In the FWSM implementation, when the shun is applied with full connection parameters (source IP, destination IP, source port, destination port and protocol), all connections from or to the source IP address are torn down.
Workaround: None.
•
An attempt to assign an access list to the nat (interface) 0 access-list command that contains protocol or port numbers fails and generates an error message. The behavior for the nat (interface) 0 access-list command differs from that of PIX. For the FWSM, the access list being configured with the nat 0 access-list command cannot contain protocol or port numbers. Only access lists that have no rules with protocols or port numbers will be accepted as part of the nat (interface) 0 access-list command.
•
•
The FWSM does not report the most used connection count. This value is also not reported by the SNMP agent Firewall MIB. The show connection count command displays only the current number of connections and not the most used connections.
Workaround: None.
•
The clear nameif command is not supported and displays an error message.
Workaround: Use the no nameif command. (See caveat CSCdx14699).
•
You cannot change the interface name once it is assigned using a nameif command. Trying to change the name of the interface using the nameif command results in an error message.
Workaround: Delete the old interface using the no nameif command, and assign it with a new name. All configuration parameters tied to that interface are lost when you run the no nameif command. (See caveat CSCdx14768).
New and Changed Information
•
•
•
Note
To create multiple VLAN interfaces on the switch, use these commands:
For Cisco IOS software:
firewall multiple-vlan-interfacesno firewall multiple-vlan-interfacesFor the Catalyst operating system software:
set firewall multiple-vlan-interfaces {enable|disable}•
•
The command-line interface in the FWSM contains changes that add new functionality to manually trigger ACL compiling.
Workaround: None.
•
Error Message Syslog:440520 - ILS <msg_id> from <interface>:<ip/port> to <interface>:<ip/port> has wrong embedded addressExplanation The ILS message source IP does not match the IP address embedded in the payload. This means that the client is more likely behind another NAT device that does not recognize ILS. The message is allowed through the firewall.
Recommended Action This is a warning informational message. No action is required.
Limitations and Restrictions
The following apply:
•
–
–
–
•
A patch will be released for PIX MC to address this issue. The patch version will be PIX MC 1.1(1). With the patch, the PIX MC will not generate the two additional static commands if the device operating system is FWSM Release 1.1(1) or FWSM Release 1.1(2).
Caveats
These sections describe the following release caveats:
•
•
•
•
•
•
•
•
Open Caveats in Release 1.1(4)
Note
This section describes known limitations that exist in the FWSM software release 1.1(4).
•
302001 and 302002 TCP connection system messages are not being generated consistently.
Workaround: None.
•
System message 304001 is not being generated consistently.
Workaround: None.
•
The maximum number of the translation slots (xlates) limit has been reached in the FWSM, and all resources are used.
Workaround: Enter the show xlate count command to determine if the maximum limit of translation slots (xlates) is reached.
•
DNS connections that are initiated by an outbound DNS resolve request are not closing as soon as the reply from the server is received. Instead, the connections are subjected to general UDP timeouts.
Workaround: None.
•
Under stress traffic continuing for long periods of time with SNMP traps and logging enabled may cause the FWSM to lose memory with no recovery.
Workaround: None.
•
Fixup RPC does not work with the NFS version 2 UDP port mapper.
Workaround: None.
•
If you have a Global Pool defined for NAT and one global statement for PAT, the FWSM intermittently begins assigning the same NAT address to multiple inside hosts.
Workaround: Enter the clear xlate command to resolve the issue.
•
When using the FWSM software release 1.1(2), an error stating "The flash device is in use by another task" may occur when you enter the show conf or write mem commands. When this message is logged, the module has only one session active (console), which cannot be halted.
Workaround: Reload the FWSM
Resolved Caveats in Release 1.1(4)
Note
This section describes the resolved caveats in FWSM software release 1.1(4).
•
The NP 3 loses its ingress buffers and gets stuck.
•
Use of manual commit mode with large ACLs may cause the FWSM to crash.
•
After several days of normal operation of FWSM 1.1(3.17) all NPs (including NP 3) may get stuck and no further packet processing is possible.
The show tech command displays the following errors"
------------------ show interface stats -------------Interface stats query failed. Try again.------------------ Fast Path (1) Stats --------------ERROR: np_logger_query request for FP Stats failed------------------ Fast Path (2) Stats --------------ERROR: np_logger_query request for FP Stats failed------------------ Slow path info ------------------ERROR: np_logger_query request for retreiving Slow Path Stats failedIf the FWSM that crashes is used in a failover pair, then both modules become active, causing interruption of networks services. The traffic causing this situation is currently unknown.
Workaround: None.
•
The ACL memory in NP 3 gets depleted with a 400 line ACL and 200 AAA entries. The AAA statements which are the last set of entries added to ACL memory are deleted when the module runs out of ACL memory.
Whenever the ACL memory is exhausted, a message is printed on the console and a syslog message with ID: 106024 is generated. In this case the message did not get printed. Improved memory utilization with some minor optimizations fixes this problem.
Workaround: None.
•
If you configure the FWSM to permit TFTP or Oraserv (ports 69,1525), the module opens up a UDP vulnerability in the Firewall (1.1.x release). This vulnerability can lead to any UDP packets making it across the firewall even if there are ACLs configured to deny such packets.
Workaround: Deny ports 69 and 1525 using access-lists.
•
The FWSM stops logging to syslog server(s), and crashes in the logger thread.
•
Standby FWSM crashed and remained in failed state after reloading
•
With logical update enabled, in some rare situations, a standby blade may experience a watchdog timeout while processing a specific message. Standby encounters a watchdog timeout and crashes. Problem seen in some very rare situations with logical update enabled.
Workaround: None.
•
Large ACL compilation cause failover problem. The problem does not occur when you reload the standby FWSM. It is only when you reload the active FWSM (and it does not make a difference if it is the secondary or the primary unit) that this problem occurs.
Workaround: Use the no fail active command on the active FWSM.
•
The fixup H323, H225, and 1720 is not working properly when it is disabled at bootup. If you run a no fixup h323 h225 1720 command, save the configuration, reload the FWSM, and then run the fixup h323 h225 1720 command the fixup appear to not be working properly. Debug h323 events will not display.
Workaround: Reboot the FWSM to resolve this issue.
•
The FWSM crashes one or two times per day on FIXUP SIP. with the following traceback:
------------Thread Name: udp_sip (Old pc 0x00235cf2 ebp 0x0c51934c)Traceback:0: 005142e51: 00229dae2: 0022a6283: 0022cafa4: 00138c1e5: 001390676: 0013e9d37: 00140d07------------Workaround: None.
•
When running the show console command (included in the show tech command) from a remote SSH management session, the SSH session may hang and cause high CPU use on the module until the SSH session is terminated through another management session.
Using another management tool for example Telnet, console through the switch, and so on), allows you to get the show console command that displays that a very long line is present.
Workaround: Use the Telnet or console to manage the module instead of SSH.
•
FWSM running 1.1.3 crashed during a simultaneous multi-user access.
•
When pushing big configurations with custom scripts, the inside interface stops responding to ICMP. Oracle cluster fails over because the Oracle database servers use ICMP as the keep-alive mechanism. Also when both FWSMs are on-line, as master and slave modules, the push takes much longer than when only one module is online.
Workaround: Break the configuration into smaller parts and push the smaller parts. Or, use a pause between pushes of ACLs to the different interfaces.
•
Standby FWSMs running software release 1.1.3.14 crash at bootup with the logical update (LU) enabled.
Workaround: Disable the logical update (LU) or failover module. We recommend that you upgrade to a later software version.
•
FWSM crashed in h323_ras thread.
Workaround: Disable the H323 RAS fixup with the no fixup protocol h323 ras 1718-1719 command
•
The sysopt connection tcpmss bytes command has no effect on the FWSM.
Workaround: None.
•
Some UPS devices with network management through a Telnet session have an unusual TCP/IP stack. The SYN-ACK segment from such devices may also have the PUSH flag set. The FWSM drops these packets causing the Telnet session through the FWSM to the UPS to fail.
Workaround: None.
•
When connecting a FWSM as the standby module, the active module detects the standby module and sends the configuration to it. However, the compilation fails with a memory error. The compilation will complete properly if compilation is done through the config net command.
Workaround: None.
•
Standby FWSM crashes at the send_xlate_query_to_np.
•
Compilation of ACL fail with no error. Uploading several ACLs or ACEs to the FWSM fails the compilation with no errors sent. Using big files with ACLs or ACEs with groups, may exhaust No errors are displayed until the module is reloaded.
Workaround: Use fewer ACLs or ACEs.
•
The FWSM syslog does not display the UDP connection ID. There is no UDP connection ID displayed at UDP logs so it is not possible to determine which teardown message belongs to which built message.
Workaround: None.
•
The FWSM syslog does not show the UDP syslog information. Duration of UDP connections and transferred bytes are not displayed.
Workaround: None.
•
The FWSM syslog prints incorrect information. The syslog shows connection duration is 0 although a finite time has elapsed for that connection.
Workaround: None.
•
When using FWSM with WS-X6816-DFC3A module, it may take up to 5 minutes for the failover and the stateful failover does not work.
Workaround: None.
•
The output of the show pdm history feature xlate command does not always display the correct number of xlates in use and the most used xlates. The numbers differ from the actual number of xlates represented in the output of the show xlate count command. Because of this situation, when you graph the number of xlates in use, and those xlates most used in the PDM, the output is incorrect.
Workaround: Use the output from the show xlate count command. There is no current workaround when graphing PDM xlates.
•
The show xlate command does not always display all xlates. You can count the number of xlates in the output of the show xlate command and it does not add up to the number represented in the output of the show xlate count command.
Workaround: Use the show local-host command, or use show xlate interface interface command.
•
The aaa accounting include tcp/0 inside 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 TACACS+ command when used on the FWSM causes all TCP traffic to stop passing through the module. UDP traffic still operates correctly. This situation only occurs when AAA accounting is used without AAA authentication or authorization. When all three AAA methods are used together, TCP traffic does not appear affected. This defect occurs on FWSM software releases 1.1(2)5 and 1.1(3).
Workaround: None.
•
When the active FWSM is powered down, the traffic does not resume through the new active module.
Workaround: None.
•
Sometimes during a corner case, the FWSM crashes in the i82543_timer thread when receiving a message on the EOBC port.
Workaround: None.
•
The FWSM does not currently support OSPF Type 10 (Opaque) LSAs. If the FWSM has OSPF neighbors that are passing Type 10 LSAs, the FWSM currently advertises that it will accept them, but drops them when they are received. This situation causes the FWSM to stay in a loading state with the OSPF neighbor that is sending the Type 10 LSAs.
Workaround: Remove traffic engineering configurations on the FWSM's OSPF neighbors. Or, place the FWSM and it's neighbors in their own OSPF area, so that Type 10 LSAs are not included in that area. The FWSM can now advertise that it does not support Type 10 LSAs.
•
During the initial TCP session established through the FWSM, if the inside server NAT responds with 2 simultaneous SYN-ACK packets, the final ACK for session establishment is not permitted back through the FWSM.
Workaround: None.
•
When using cut-through authentication and you configure a finite value for the inactivity timer, you must re-authenticate each time the configured inactivity timer has elapsed, though the inactivity timer has not yet expired. For example, connections you have set up have not been idle or you have set up new connections. This problem was observed in FWSM software release 1.1.3.
Workaround: None.
•
Applying configuration changes to ACLs using the manual-commit mode causes traffic on the interface to which that ACL had been bound to be dropped for some time This problem exists only while using manual-commit mode.
This problem applies to users or the management tools running in the manual-commit mode to apply ACL configuration changes to the module.
Workaround: Use the following command sequence ensure that traffic loss is not observed while making changes with manual-commit mode until the fix is available in a later release.
1.
2.
3.
4.
5.
In this sequence, traffic on the interface to which blah was attached is getting dropped in step2 until the access-group binding is reapplied in step5.
•
Fixup lookup fails with port ranges.
Workaround: None.
•
The FWSM drops WINS traffic if the packets are sourced from a client on a higher security level interface, destined to a server on a lower security level interface.
Workaround: If you are not using NAT, disable the NetBIOS fixup using the no fixup protocol netbios command.
•
When using Policy based NAT (NAT ifc 0 access-list) on FWSMs, not all connections are copied to the standby. In particular fixup specified connections (for example, FTP data connections from the FIXUP protocol FTP) do not appear in the xlate table of the secondary module and they fail following a failover event.
Workaround: Use straight NAT ifc n network,mask constructs.
•
Some traffic stops passing through the FWSM that relies on statics in a failover environment. If the no failover active command is run, the statics disappear on the FWSM on which this command was run. If this command is run on the primary or active module and then run on the secondary or active module, the primary module resumes the role of the active module and the statics will not exist.
If the statics are reconfigured into the active FWSM, the Unable to download Static Entry message is displayed. This problem only exists in fWSM software release 1.1(3.4).
Workaround: Reload both FWSMs at the same time then ensure that the statics remain by running the show config command.
•
If you are using a stateful failover pair of FWSMs running software releases 1.1.(3) and 1.1.(3)3 and you initiate an a FTP session through the active blade, when the primary blade fails the FTP session stays up but the data transfer is terminated. Observing the host's connection through the secondary module only the control channel can be seen as open. Connecting through the active secondary module, and then initiating a GET for the file the transfer begins. When you observe the connection status between the two FWSMs, the secondary module is lacking the data connection which is present on the primary module.
Workaround: None.
•
When configuring a FWSM running software release 1.1.x with the service resetinbound or service resetoutside commands the module does not send a reset back when the denied SYN packet is received. The module however, will perform the standard reset for non-syn packets where no connection is built for this flow.
Workaround: None.
•
Normal priority threads are being starved. If this situation occurs, a counter is incremented allowing you to determine what conditions result in starvation and perhaps implement some corrective actions. You must allow the normal priority queue to process for every 8 processing runs of the high priority queue in which there are still high priority threads that have not yet run. If there are no high priority threads hogging the CPU, the behavior is the same as the currently running scheduler.
Workaround: Change the process scheduler to allow the normal priority threads to run.
•
Under rare circumstances, the FWSM may crash with a thread name: h323_ras. In some cases a packet was intended for the FWSM for a connection which should have been outdated.
Workaround: If you are not passing H323 RAS messages through the FWSM, then disable the H323 RAS fixup using the no fixup protocol h323 ras 1718-1719 command.
•
Sessions drop on TN3270 users running through the FWSM. The TCP timeout was changed from 1 hour to 8 hours and the connections time ranged from dropping within 5 minutes to staying up to just over 1 hour.
Workaround: None.
•
Some access-lists failed to be downloaded to then network processor causing the FWSM to fail at the next reboot.
Workaround: None.
•
Only the first established command entered into the FWSM will actually take effect. All other established commands are ignored. For example, if these commands are entered into the FWSM:
FWSM(config)# established tcp 514 0 permitto tcp 6000-6010 permitfrom tcp 1024-65535FWSM(config)# established tcp 513 0 permitto tcp 6000-6010 permitfrom tcp 1024-65535FWSM(config)# established tcp 512 0 permitto tcp 6000-6010 permitfrom tcp 1024-65535FWSM(config)# established tcp 23 0 permitto tcp 6000-6010 permitfrom tcp 1024-65535FWSM(config)# established tcp 22 0 permittto tcp 6000-6010 permitfrom tcp 1024-65535FWSM(config)# established tcp 21 0 permitto tcp 6000-6010 permitfrom tcp 1024-65535Only the first command for the outbound TCP connection port 514 works.
Workaround: None.
•
The FWSM stops forwarding traffic at the slow path when AAA authentication and authorization are configured, and there is a high number of users generating traffic.
Workaround: Reload the FWSM.
•
When using FWSM software release 1.x currently the syslogs all denied packets when using syslog ID: 106023. This situation includes packets that are dropped because of the implicit deny ip any any statement at the end of every access-list. This syslog also is logged if no access-list is applied to an interface, because the FWSM defaults to deny all traffic if no ACL is applied. This behavior is inconsistent with PIX and Cisco IOS.
Workaround: The behavior of the FWSM will be modified in a future release so it no longer logs implicitly denied packets. If you want to syslog all denied packets you can add an explicit deny all ACE as the last entry in their ACLs. For example:
WSM(config)# access-list <acl> deny ip any any•
TFTP connections may begin to fail through the FWSM because there is a limit of 1,000 TFTP connections through the FWSM at any one time. The FWSM has a system limitation of 1,000 established nodes and each TFTP connection uses an established node. When the TFTP connection is torn down, the established node should also be removed.
Because of this caveat, TFTP connections can be torn down without removing their associated established node. If this happens several times, no new TFTP connections can be created because no established nodes are available. In this situation, no syslog is generated to alert you that this has occurred. The TFTP connection fails, with no indication as to why. To verify that this problem has occurred, run the show np 3 stats command, and look for the following line:
--> Est<->HO Errors : 850 <---If this number is non-zero, there is a good chance you are running into this problem.
Workaround: Clear the local-host table using the clear local-host command.
Note
•
New vulnerabilities in the OpenSSL implementation for SSL have been announced. An affected network device, running an SSL server based on the OpenSSL implementation, may be vulnerable to a Denial of Service (DoS) attack when presented with a malformed certificate by a client. The network device is vulnerable, to this vulnerability, even if it is configured to not authenticate certificates from the client.
This advisory is posted at this URL:
http://www.cisco.com/warp/public/707/cisco-sa-20030930-ssl.shtml.
Workaround: Refer to the advisory URL for work arounds that are available to mitigate the effects of these vulnerabilities.
•
In rare circumstances, two instances of the same network object might be observed in an object group. The object group is involved in complex access-lists, which requires a lot of CPU resources during the addition of the new members to object group.
The root cause of this problem is that too processing continued too long during the access-list compilation.
Workaround: To dramatically decrease the ACL compile time, delete the object that is listed multiple times, from the CLI, then replace that object. Wait until the operation completes.
•
The FWSM performs through-traffic authentication by matching traffic against an access-list. Caveat CSCeb83847 indicated that the only valid ACEs in a aaa authentication match ACL statement are for FTP, Telnet, HTTP, or TCP/0 which is not correct. Any ACE that is created should be valid when applied to a aaa authentication match ACL command statements. The FWSM should behave as follows:
–
–
–
–
Workaround: None.
•
The FWSM write standby command on the primary FWSM causes failover to occur on the secondary module.
Workaround: None.
•
If the FWSM is started up with the configuration having an interface in the shut down state, error messages appear on the console during startup.
Workaround: None.
•
The NFS mount takes a long time to succeed or fails because the NFS client is on a lower security interface relative to the NFS server.
Workaround: Configure the NFS client on a higher security interface relative to the NFS server.
•
When making calls using gateways to the SIP (SMDS Interface Protocol) proxy, UDP and TCP proxy calls fail to set up, or there is no voice path.
Workaround: Do not use gateways with the SIP proxy.
•
When you enter the config net command with the tftp-server outside 172.17.241.99 /we command in the configuration, the FWSM crashes when the configuration file contains a write mem command.
Workaround: None.
•
Configuring different ICMP types in an access- list not accepted
Workaround: None.
•
When running in a failover configuration, the FWSM does not replicate connections at the second failover because the state of the connection is lost. This condition applies only to those connections that remain alive through both failovers. Both the FTP and RSH connections consist of a control and data channel that are linked. All other connections are considered as control channel only. Connections are being replicated for one of the following reasons:
a.
b.
c.
Workaround: None.
Open Caveats in Release 1.1(3)
Note
This section describes known limitations that exist in the FWSM software release 1.1(3).
•
During failover interface testing when the shutdown command is sent manually, testing continues, and the interface state is reported as "unknown." The interface status should be reported as "Link Down," and the test should not be performed on the interfaces.
Workaround: None.
•
The no routerid ip add routing command does not remove the router identification under OSPF because the routerid syntax is incorrect.
Workaround: Use the no router-id syntax.
•
When the message digest key is configured it cannot be removed using the no ospf message-digest-key key md5 cisco command because the syntax is incorrect.
Workaround: Use the no ip ospf message-digest-key keyid command syntax.
•
No video can be seen using IP TV. The UDP packets seem to be dropped when access-lists are applied to allow only the needed traffic to flow through the FWSM.
Workaround: None.
•
The NFS mount takes a long time to succeed or fails because the NFS client is on a lower security interface relative to the NFS server.
Workaround: Configure the NFS client on a higher security interface relative to the NFS server.
•
When making calls using gateways to the SIP (SMDS Interface Protocol) proxy, UDP and TCP proxy calls fail to set up, or there is no voice path.
Workaround: Do not use gateways with the SIP proxy.
•
The FWSM does not reply to the Address Resolution Protocol (ARP) if ARP is sourced from a non-connected network.
Workaround: Add a specific route or static ARPs on the MSFC.
•
The PIX Device Manager (PDM) performance monitor graphs display only zero values except for the performance monitor intervals. This condition occurs because the performance monitor interval and the PDM poll interval are set to different values.
Workaround: Configure the PDM poll and performance monitor interval to the same value.
•
When the interface IP address is modified, the interface static entry continues working with the old IP address but not with the new IP address.
Workaround: Remove and reconfigure the interface static line after the interface IP address has been changed.
•
When running in a failover configuration, the FWSM does not replicate connections at the second failover because the state of the connection is lost. This condition applies only to those connections that remain alive through both failovers. Both the FTP and RSH connections consist of a control and data channel that are linked. All other connections are considered as control channel only. Connections are being replicated for one of the following reasons:
a.
b.
c.
Workaround: None.
•
When overlapping static statements are specified, the static entries cannot be removed from the configuration.
Workaround: Avoid using overlapping network addresses in different static statements, or change the order of the static statements in the configuration.
•
The maximum idle time that can be configured for a connection is 18 hours and 12 minutes. If a timeout is configured for a time that is greater than 18 hours and 12 minutes, the timeout wraps around and has a value of 18 hours and 12 minutes.
Workaround: Configure a maximum idle time value lower than 18 hours and 12 minutes.
•
The show conn command displays connections with the idle timeout larger than the timeout configured.
Workaround: None.
•
When configuring the OSPF processes and the SVI interfaces on both the MFSC and the FWSM to perform MD5 authentication, the OSPF process in the FWSM becomes stuck in the loading state and cannot reach the full state. The output of the show ip ospf neighbor command displays this information:
Neighbor ID Pri State Dead Time Address Interfacex.x.x.x 1 LOADING/DR 0:00:33 y.y.y.y outsideThis syslog message displays:
409005: Invalid length 1504 in OSPF packet from y.y.y.y (ID x.x.x.x), outsideThis situation occurs when the LS update packets from the MFSC are fragmented and both of the OSPF neighbors are configured to perform MD5 authentication.
Workaround: Do not use MD5 authenticating. Use clear text authentication, or do not configure authentication. Cisco IOS releases that do not fragment LS updates do not cause this problem on the FWSM.
•
If a protocol is not associated to the AAA server group when using the aaa-server tag protocol tacacs/radius command, any new server group is always considered as the TACACS server.
If a radius server is specified with the aaa-server tag [(if_name)] host ip_address [key] [timeout seconds] command and the tag used is not associated with the radius protocol, AAA authentication, authorization, or accounting fail because the firewall assumes that the AAA server is a TACACS server and attempts to make requests to port 49 on the specified server.
Workaround: Always create a server group by associating it with the required protocol before assigning servers to that group, as in this example:
FWSM(config)# sh aaaFWSM(config)# sh aaa-aaa-server radius-authport 1812aaa-server radius-acctport 1813aaa-server TACACS+ protocol tacacs+aaa-server RADIUS protocol radiusaaa-server LOCAL protocol localFWSM(config)# aaa- TEST_RADIUS (dmz) host 10.6.0.3 ciscoradius time 2FWSM(config)# sh aaa-aaa-server radius-authport 1812aaa-server radius-acctport 1813aaa-server TACACS+ protocol tacacs+aaa-server RADIUS protocol radiusaaa-server LOCAL protocol localaaa-server TEST_RADIUS protocol tacacs+aaa-server TEST_RADIUS (dmz) host 10.6.0.3 ciscoradius timeout 2 [ACTIVE]FWSM(config)#•
If SIP messages are split across multiple TCP segments, the FWSM does not take any action (such as NAT or connection pre-allocation) on them.
Workaround: Do not use Network Address Translation (NAT) or Port Address Translation (PAT) and disable the fixup SIP using the no fixup protocol sip 5060 command.
•
Outbound TFTP requests fail if PAT is using an interface IP address that is configured on the FWSM. The TFTP file download works correctly with other PAT IP addresses.
Workaround: None.
•
If the FWSM is started up with the configuration having an interface in the shut down state, error messages appear on the console during startup.
Workaround: None.
Resolved Caveats in Release 1.1(3)
Note
This section describes the resolved caveats in FWSM software release 1.1(3).
•
When failover is configured, using a write standby command resets the configurations on the secondary FWSM.
Workaround: None.
•
With some configuration and with fragmented ICMP, HTTP, FTP traffic, and RTSP, the network processors lose their ingress buffers, causing both FWSMs to become active or causing the secondary FWSM to report as failed.
Workaround: None.
•
When using show run and write mem commands from two simultaneous sessions into the FWSM, and when the show run command completes first, the write mem command fails in cfglck.c line 76 upon completion.
Workaround: Perform CLI commands from only one session at a time.
•
The FWSM in a stateful failover configuration may not replicate TCP connections correctly. This behavior shows up in configurations where the NAT 0 ACL is used.
Workaround: Use NAT 0 or statics.
•
When two FWSMs are used with stateful failover, unnecessary failovers can occur, caused by the garbage collection thread on the standby module. When a translate (xlate) process ages to one hour, the standby FWSM constantly queries the process to verify if the process is still in use or if the process can be torn down. During this time, the failover hello messages are dropped, resulting in a failover.
Workaround: Disable stateful failover.
•
Stateful synchronization does not operate correctly after switchover. When there is a switchover due to a short communication failure between the active and the standby FWSM, the logical unit (LU) flag is not set correctly on the network processors (NPs) after the switchover, which stops the stateful synchronization from the active FWSM to the standby FWSM.
Workaround: Remove the stateful link configuration, and add it back on the active FWSM with the no failover link stateful and failover link stateful commands.
•
If there is an ACL with an access-list entry using object-groups, and it expands to a large number of ACL lines (up to 10,000-12,000), then when this configuration is synchronized through failover, some commands that follow after the ACE might be missing on the standby FWSM after the synchronization.
Workaround: Do not use ACE with object groups that expand to a large number (up to 10,000-12,000).
Guest
