Guest

Cisco Services Modules

Release Note for the Cisco Anomaly Guard Module (Software Version 6.0(x))

  • Viewing Options

  • PDF (212.1 KB)
  • Feedback

Table Of Contents

Release Note for the Cisco Anomaly Guard Module

Contents

New Features in Software Version 6.0(5)

Ordering and Installing a Software License Key for the 6.0-XG Software Image

Ordering a 6.0-XG Software Image License Key

Installing the XG Software Image License Key

Upgrading Module Bandwidth from 1 Gbps to 3 Gbps

Upgrading to Software Version 6.0(x)

Downgrading from Software Version 6.0(x)

Preparing for a Software Downgrade

Downgrading the Installed Software Image

Reconfiguring the Guard Module after a Software Downgrade

Maximum Number of Modules Supported in a Catalyst 6500 Chassis

Operating Considerations

MultiDevice Manager Commands Omitted from the Configuration Guide

mdm logging trap Command

mdm restore Command

show mdm Command

Software Version 6.0(10) Open and Resolved Caveats

Software Version 6.0(10) Open Caveats

Software Version 6.0(10) Resolved Caveats

Software Version 6.0(5) Open and Resolved Caveats

Software Version 6.0(5) Open Caveats

Software Version 6.0(5) Resolved Caveats

Related Documentation

Obtaining Documentation, Obtaining Support, and Security Guidelines


Release Note for the Cisco Anomaly Guard Module


July 16, 2007


Note The most current Cisco documentation for released products is available on Cisco.com.


Contents

This release note applies to software versions 6.0(10) and 6.0(5) for the Cisco Anomaly Guard Module (Guard module). The Cisco Catalyst 6500 series switch and the 7600 series router support the Guard module.

The Catalyst 6500 series switch requires IOS 12.2(18)SXD3 or later and a SUP720 or a SUP2 with an MSFC2 to support the Guard module.

The 7600 series router require IOS 12.2(18)SXE or later and a SUP720 to support the Guard module.

This release note contains the following sections:

New Features in Software Version 6.0(5)

Ordering and Installing a Software License Key for the 6.0-XG Software Image

Upgrading Module Bandwidth from 1 Gbps to 3 Gbps

Upgrading to Software Version 6.0(x)

Downgrading from Software Version 6.0(x)

Maximum Number of Modules Supported in a Catalyst 6500 Chassis

Operating Considerations

MultiDevice Manager Commands Omitted from the Configuration Guide

Software Version 6.0(10) Open and Resolved Caveats

Software Version 6.0(5) Open and Resolved Caveats

Related Documentation

Obtaining Documentation, Obtaining Support, and Security Guidelines

New Features in Software Version 6.0(5)

The following new features are available in software version 6.0(5):

Ability to set the TACACS+ sever port.

Ability to set the TACACS+ encryption key.

The Guard module can now operate at two different bandwidth performance levels: 1 Gigabit per second (Gbps) or 3 Gbps. The software image that is loaded on the Guard module determines the operating bandwidth by controlling the three physical interfaces between the module and the supervisor engine. The available software images control the interfaces in the following ways:

6.0—This software image provides 1-Gbps throughput, allowing data traffic to move between the supervisor engine and the Guard module over a single interface port that has a maximum bandwidth of 1 Gbps. A second interface port transports out-of-band management traffic only. The third interface port is not used.

6.0-XG—This software image provides 3-Gbps throughput, enabling all three of the interface ports to transport data traffic and inband management traffic. Each port has a maximum bandwidth of 1 Gbps for a total operating bandwidth of 3 Gbps. To use the XG software image, the Guard module requires a software license key.

When you order a 6.0-XG Guard module, Cisco installs the software license key with the 6.0-XG software image. When you order a 6.0-XG software image as a spare to upgrade an existing Guard module, you must obtain and install the software license key to activate the software image. For more information, see the "Ordering and Installing a Software License Key for the 6.0-XG Software Image" section.

Ordering and Installing a Software License Key for the 6.0-XG Software Image

When you order the 6.0-XG software image as a spare and install it in an existing Guard module, you must enter a software license key to activate the software image. This section contains the following topics that describe how to order and install a software license key:

Ordering a 6.0-XG Software Image License Key

Installing the XG Software Image License Key

Ordering a 6.0-XG Software Image License Key

The software license key that is required to activate the XG software image is associated with the Media Access Control (MAC) address of the Guard module where the XG software image resides. This section describes the process that you use to order the XG software license key.

You must have the XG version of the 6.0 operating software (or newer) loaded on your Guard module before ordering and installing the corresponding license. To verify the version of software currently loaded on your Guard module, use the show version command. When the XG software image is loaded, the software version number has an -XG suffix (for example, version 6.0(0.39)-XG).

To order the 3-Gbps license, perform the following steps:


Step 1 From the Guard module, enter the show license-key unique-identifier command (this command requires the admin privilege level) to view the Guard module MAC address.

Step 2 Record the MAC address information because you will need this information when placing your order for the 3-Gbps operation license.

Step 3 Order the lic-agm-3g-k9 license using any of the available Cisco ordering tools on cisco.com.

When you receive the Software License Claim Certificate from Cisco, complete the instructions that direct you to the following Cisco.com website: http://www.cisco.com/go/license. Then complete the installation procedure as described in the "Installing the XG Software Image License Key" section.


Installing the XG Software Image License Key

To install the 3-Gbps license, perform the following steps:


Step 1 When you receive the Software License Claim Certificate from Cisco, follow the instructions that direct you to the following Cisco.com website: http://www.cisco.com/go/license

Step 2 Enter the Product Authorization Key (PAK) number found on the Software License Claim Certificate as your proof of purchase.

Step 3 Provide all of the requested information to generate a license key.

Once the system generates the license key, you will receive a license key e-mail with an attached license file and installation instructions. Save the license key e-mail in a safe place in case you need it in the future.

Step 4 Open the license key file using a text editor and copy its contents into your desktop computer's clipboard.

Step 5 From the Guard module, enter the license-key add command in configuration mode. The CLI prompts you to enter the key lines.

Step 6 Paste the contents of your desktop computer's clipboard (containing the license key) and press the Enter key.

Step 7 Enter an empty line and press Enter. If the Guard module contains a previously installed license, a confirmation message displays that asks if you want to install the new license.

Step 8 Type y (yes). The XG software image is now active and ready for 3-Gbps operation.

Step 9 (Optional) Enter the show license-key command to verify that the key loaded properly and is valid.


Upgrading Module Bandwidth from 1 Gbps to 3 Gbps

If your Guard module currently operates with a maximum bandwidth of 1 Gbps, you can upgrade the bandwidth performance to 3 Gbps by installing the XG version of the software image and corresponding software license key. The software license key activates the installed XG software image. When you install the XG software image, the Guard module is not operational until you install the corresponding software license and make the necessary configuration modifications that are required for the 3-Gbps operation. Those configuration changes include the following items:

Update existing port and interface configurations—Configure the new interfaces on the supervisor engine and on the Guard module with IP addresses and VLANs. For configuration information, see the "Updating Existing Port and Interface Configurations for 3-Gbps Operation" section in the Cisco Anomaly Guard Module Configuration Guide.

Configure proxies on the interfaces—Configure the new interfaces on the Guard module with proxies. For configuration information, see the "Configuring Proxies On the Interfaces for 3-Gbps Operation" section in the Cisco Anomaly Guard Module Configuration Guide.

Regenerate the SSL certificates—Generate new SSL certificates on the Guard module and any associated Detectors. For configuration information, see the "Regenerating the SSL Certificates for the 3-Gbps Operation" section in the Cisco Anomaly Guard Module Configuration Guide.

Installing the XG software image and license does not affect the following Guard module functions:

Zone configurations—Existing zone configuration information.

Management access—During the upgrade process, configuration parameters configured on eth1 (the management port designator) for the 1-Gbps operation are automatically assigned to giga1 for the 3-Gbps operation. This configuration change does not affect management access.

For complete information on ordering and installing the XG license key, see the "Performing Maintenance Tasks" chapter in the Cisco Anomaly Guard Module Configuration Guide.

Upgrading to Software Version 6.0(x)

During the upgrade process, the Guard module changes two parameters that may affect your configuration. The following information describes the two parameters:

In software versions prior to 6.0(5), the Guard module supported loopback interfaces. In software version 6.0(5) or higher, the Guard module no longer supports loopback interfaces and deletes all loopback interface configurations during the upgrade process.

In software version 4.x, the Guard module allowed you to configure illegal subnet masks. In software version 5.1(4), the Guard module checks to ensure that subnet masks are legal. When you upgrade from a software version prior to 5.1(4) to 6.0(x), the Guard module corrupts all zone configurations that contain an illegal subnet mask. To prevent the module from corrupting a zone configuration that contains an illegal subnet mask, configure the zone configuration with a legal subnet mask by performing the following steps prior to upgrading the software:

1. Use the no ip address command to delete the subnet mask.

2. Use the ip address command to configure the subnet mask with a legal subnet.

For details on configuring zone IP addresses, see the "Configuring the Zone IP address Range" section in the Cisco Anomaly Guard Module Configuration Guide.

Software upgrade instructions are located in the "Upgrading the Guard Module Software" section in the Cisco Anomaly Guard Module Configuration Guide.

Downgrading from Software Version 6.0(x)

You can downgrade the Guard module software image version from 6.0(x) to 5.1(6) or to 5.1(5). The 6.0(x) version that you downgrade from can be either 6.0 or 6.0-XG.


Note Changing the installed software image version in the Guard module from 6.0-XG to 6.0 is considered a software downgrade. You must perform the downgrade procedure described in this section to change the installed software image version from 6.0-XG to 6.0.


This section contains the following topics:

Preparing for a Software Downgrade

Downgrading the Installed Software Image

Reconfiguring the Guard Module after a Software Downgrade

Preparing for a Software Downgrade

The software downgrade process deletes the current Guard module running configuration, logs, and reports. Before you downgrade the software image, back up the following Guard module information:

Running configuration—For more information, see the "Exporting the Configuration" section in the Cisco Anomaly Guard Module Configuration Guide.

Logs—For more information, see the "Managing Guard Module Logs" section in the Cisco Anomaly Guard Module Configuration Guide.

Reports—For more information, see the "Exporting Attack Reports" section in the Cisco Anomaly Guard Module Configuration Guide.

Downgrading the Installed Software Image

The procedure in this section describes how to downgrade the version of the software image currently installed on the Guard module. For more details about the tasks and commands used in this procedure, see the "Performing Maintenance Tasks" chapter in the Cisco Anomaly Guard Module Configuration Guide.

To downgrade the software image on the Guard module from 6.0(x) to 5.1(6) or to 5.1(5), or from 6.0-XG to 6.0, perform the following steps:


Step 1 Log on to the Catalyst 6500 series switch or the 7600 series router.

Step 2 Reboot the Guard module to the Maintenance Partition (MP) by entering the following command:

hw-module module module number reset cf:1

Step 3 Log on to the MP using the username root and password cisco.

Step 4 Clear the Application Partition (AP) configuration by entering the following command:

clear ap config

This command deletes the current Guard module running configuration, logs, and reports (see the "Preparing for a Software Downgrade" section for information about backing up these files).

Step 5 Enter y (yes) to the verification message that prompts you to approve the deletion of the configuration.

Step 6 Install the required version of the software image by using one of the following methods:

FTP or TFTP method from the Catalyst 6500 Series Switch or the 7600 series router

Inline method using the upgrade command

Step 7 Reboot the Guard module back to the AP by entering the following command:

hw-module module module number reset cf:4

After the reboot, a message displays prompting you to provide new passwords upon the first login. The prompt for new passwords verifies that the clear ap config command was executed successfully in Step 4. The initial reboot after a downgrade may include an automatic flash-burn due to a Common Firmware Environment (CFE) version change, which may cause the reboot to take longer than usual.

Step 8 Verify that the desired version is installed in the Guard module by entering the following command in the global mode of the Guard module CLI:

show version


Reconfiguring the Guard Module after a Software Downgrade

After you downgrade the software image, you must reconfigure the Guard module either manually or by using the running-config file that you saved to a network server prior to the downgrade.

If you use the running-config file to reconfigure the module, you must verify that the network configurations are configured properly according to the software version that you install. For example, the interface names may be different between the previously installed version of the software and the currently installed version. You can modify the running-config file using one of the following methods:

Edit the network configuration portion of the running-config file prior to importing the file.

Delete network configuration information from the running-config file before you import the file and then configure the network configuration manually either before or after you import the file.

Refer to the version of the Cisco Anomaly Guard Module Configuration Guide that applies to the software version you are running for more information about configuring the network parameters and to the applicable Guard module release notes for information about network configuration differences.

Maximum Number of Modules Supported in a Catalyst 6500 Chassis

The Catalyst 6500 9-slot chassis supports a combined maximum of eight Anomaly Guard modules and Traffic Anomaly Detector modules. You can install a maximum of eight Guard modules or a maximum of four Detector modules in a single chassis in any combination for a total of eight modules.

A Catalyst 6500 13-slot chassis supports a combined maximum of 10 Anomaly Guard modules and Traffic Anomaly Detector modules. You can install a maximum of eight Guard modules or a maximum of four Detector modules in a single chassis in any combination for a total of 10 modules.

Operating Considerations

The following operating considerations apply to the Guard module:

The copy ftp command supports active mode only.

The Guard module operates using a self-protection configuration to protect itself from DDoS attacks on the network. Cisco configures the self-protection configuration with a set of default parameter values, which you can modify.

When upgrading the Guard module to software version 6.0(x) from a version previous to 5.1(5), the existing self-protection configuration is overwritten by the new configuration contained in the upgrade. If you had modified the self-protection configuration of the previously installed software, you need to make the same modifications to the new self-protection configuration. Do not copy your original self-protection configuration to the Guard module because the original configuration will block access to one or both of the following ports when attempting to access the module through an inline interface:

Ports 3220 and 1334 if you upgrade from version prior to 5.1(5). Port 3220 was added to software version 5.0(x) and 5.1(x). Port 1334 was added to software version 5.1(5).

Note that if you upgrade from software version 5.1(5) or higher after modifying the self-protection configuration, your changes to the configuration remain intact. Upgrading from software version 5.1(5) to software version 5.1(x) or higher will also leave your modified self-protection configuration intact.

MultiDevice Manager Commands Omitted from the Configuration Guide

Three commands related to the Cisco DDoS MultiDevice Manager (MDM) software functionality on the Guard module were introduced in software version 5.1(5), but were omitted from the Cisco Anomaly Guard Module Configuration Guide. The following sections describe these commands:

mdm logging trap Command

mdm restore Command

show mdm Command

mdm logging trap Command

To configure traps for MDM logging, use the mdm logging trap command in global configuration mode. To disable logging functions, use the no form of this command.

The syntax for this command is as follows:

mdm logging trap {alerts | critical | debugging | emergencies | errors | informational | notifications | warnings}

The following table describes the keywords for the mdm logging trap command.

alerts

Immediate action needed (severity=1).

critical

Critical conditions (severity=2).

debugging

Debugging messages (severity=7).

emergencies

System is unusable (severity=0). This is the default.

errors

Error conditions (severity=3).

informational

Informational messages (severity=6).

notifications

Normal but significant conditions (severity=5).

warnings

Warning conditions (severity=4).


For example, to capture and log informational messages, use the mdm logging trap informational command in global configuration mode.

user@GUARD# configure 
user@GUARD-conf# mdm logging trap informational
 
 

mdm restore Command

When you enable the MDM service on the Guard module to allow you to manage the device using the MDM, the MDM automatically upgrades the RA on the device when it initiates a communication link with the device. While the MDM is upgrading the device RA, the operating state displays on the MDM as Initializing. The state changes to Connected when the RA upgrade is complete.

When a device appears to be constantly in a state of initialization, it may indicate that the MDM is attempting to upgrade the device RA but cannot do so.

Use the mdm restore command to resolve issues with upgrading and connecting the device RA. To return the device Remote Agent (RA) to the stub and force the MDM to reinstall the latest RA version, use the mdm restore command in global configuration mode.

The syntax for this command is as follows:

mdm restore

For example:

user@GUARD# configure 
user@GUARD-conf# mdm restore
 
 

show mdm Command

To check the status of MDM connections and settings, use the show mdm command in EXEC mode.

The syntax for this command is as follows:

show mdm

For example:

user@GUARD# show mdm 
 
 

The following table describes the fields in the show mdm display.

Field
Description

MDM service state

Operating state of the MDM service: enabled or disabled.

MDM servers

List of MDM servers that you define on the device (permitting them to access the device) and the state of the key exchange process with each of the servers: key exchange is complete or key exchange is required.

Connected managers

MDM server currently connected to and managing the device.

MDM syslog level

Setting of the syslog server logging level: alerts, critical, debugging, emergencies, errors, informational, notifications, warnings.


Software Version 6.0(10) Open and Resolved Caveats

The following sections contain the open and resolved caveats in software version 6.0(10):

Software Version 6.0(10) Open Caveats

Software Version 6.0(10) Resolved Caveats

Software Version 6.0(10) Open Caveats

The following caveats are open in software version 6.0(10):

CSCrh01198—After you reload the Guard module, it erases the default gateway if the gateway is on the same subnet as one of the configured VLAN interfaces on the module. Workaround: Use a static route instead of a default gateway.

CSCsa64914—The name of the Flexible Filter Drop Count counter in the WBM Zone>Configuration>General menu should be Flexible Filter Drop Rate. This counter accurately displays the drop rate of the Flex-Content filter. The General menu also contains the Flexible Filter Action and Flexible Filter Count fields. When the Flexible Filter Action value is displayed as:

Drop, the Flexible Filter Count value displays the number of dropped packets

Count, the Flexible Filter Count value displays the number of counted packets

CSCsa78440—The protect-by-packet activation interface does not apply to zones that are on the same subnet as the Guard module. Workaround: Use another activation interface.

CSCsb07081—The flex-content filter cannot find a pattern in SYN packets.

CSCsb20206—The Web-Based Manager (WBM) remains unresponsive while the pop up window waits for results from the signature generation process. Even if you close the pop up window manually, the WBM remains unresponsive while signature generation is in progress. Workaround: Wait until the pop up window receives a result or issue the no service wbm CLI command in configuration mode.

CSCsb29083—You cannot assign an identical name to manual packet dumps that you create in different zones. Workaround: Assign unique names to manual packet dumps.

CSCsc05116—The Guard module may stop functioning or start logging errors after reaching 100% anomaly detection engine memory utilization. Workaround: Use the show resources command in global mode to view the amount of anomaly detection engine memory currently being used by the Guard module. Reducing the number of active zones may free up memory.

CSCsc36095—Loopback interfaces 100 and higher disappear or become proxy interfaces when you upgrade from previous software versions to software version 6.0(x). Workaround: Renumber loopback interfaces before upgrading the Guard module to software version 6.0(x).

CSCsc51207—The Guard module does not evaluate all conditions defined in the flex-content filter when the filter is built from more than one offset-based element (for example, udp[64:4]=0x1234) with "or" between them. If one of the elements has an offset beyond the packet end, the Guard module does not evaluate the rest of elements. Workaround: Build the filter in a form in which its elements are ordered by an offset.

CSCsc69508—After importing an HTML file to serve as the login banner, some SSH clients may not be able to connect to the product.

CSCsd83077—The Guard module responds to a larger size packet than the MTU value set for its network interfaces.

CSCse08139—The CLI session terminates when you press Ctrl-Z several times after issuing the more 0 command.

CSCse19834—Activating a zone with a combination of a large number of subnets and excluded subnets may take a few seconds to several minutes, depending on the number of subnets (excluded or included).

CSCse27876—When you press Ctrl-C during an import of a new software version or configuration, you interrupt the import process and the CLI session may get disconnected. Workaround: Do not press Ctrl-C during the import process.

CSCse31042—A zone configuration that contains ip_scan or port_scan policies cannot be imported into the Guard module. Workaround: None.

CSCsf06487—This caveat applies to the 6.0-XG (3 Gbps) Guard module only. A zone that is directly connected to the Guard module does not receive traffic without an explicit injection configuration. Workaround: Create an injection configuration for the required zone.

CSCsg42338—The Guard module CPU usage may reach 100%. Workaround: Reboot the Guard module.

CSCsg94911—When a physical interface goes down, the virtual interfaces that use the physical interface are not brought down, which results in black-holing the traffic. Workaround: Manually deactivate the relevant zones on the Guard module.

CSCsh36537—This caveat applies to the 6.0-XG (3 Gbps) Guard module only. The rate limit defined on a zone or a user filter is multiplied by three. Workaround: If the traffic is equally balanced between the Guard module ports, define the rate limit as 1/3 of the desired limit. If not, there is no workaround.

CSCsi18583—The Guard module drops the last TCP ACK on the outgoing traffic. Workaround: Create a bypass filter for the source IP address that is experiencing authentication problems.

CSCsi57942—After upgrading the Guard module software to version 6.0-XG, SSH and WBM connectivity to the module may be lost. Workaround: Log in to the Guard module through the Catalyst 6500 series switch or 7600 series router and re-enter the routing configuration.

CSCsi61341—The Guard module leaves the TCP timestamp option in the SYN ACK reply. Workaround: None.

CSCsj27292—The Guard module does not count bypass filters correctly, which may cause the watchdog to reload the module. Workaround: Remove all unnecessary bypass filters.

CSCuk54606—When activating a zone by issuing the protect or the learning commands, the Guard module displays the following error message even when the configuration is correct and traffic diversion is working properly:

no injection path 
 
 

The Guard module may display this message if it does not have a default injection route and the zone injection definition consists of two or more injection routes with an IP address that does not match the zone IP address (for example, a zone IP address of 192.168.254.0/24 and zone injection routes of 192.168.254.0/25 and 192.168.254.128/25). Workaround: Configure a default injection route for the Guard module, or configure the zone injection routes to match the zone IP addresses. For example, if you configure the injection routes to be 192.168.254.0/25 and 192.168.254.128/25, configure the zone IP addresses as 192.168.254.0/25 and 192.168.254.128/25.

Software Version 6.0(10) Resolved Caveats

The following caveats were resolved in software version 6.0(10):

CSCsh81082—The Guard module does not rotate the /var/log/wtmp file, which may result in the file becoming very large.

CSCsh92933—After entering the tacacs authorization exec tacacs+ command, the show running-config command does not display the tacacs authorization exec tacacs command in the configuration output.

CSCsi2905, CSCsi17169—When accepting the thresholds during the learning process, the Guard module intermittently encounters an error when accepting some of the thresholds.

CSCsi23637—When using the Web-Based Manager (WBM), TACACS+ login authentication falls back to local authentication even if the TACACS+ server rejects the authentication.

CSCsi65071—A flex-content filter with a single byte tcpdump expression may not detect the byte in the zone traffic.

CSCsi67008—A flex-content filter tcpdump expression does not examine the last byte of a packet.

CSCsi70650—The watchdog process intermittently becomes stuck on one of the child processes.

CSCsi78741—The internal watchdog constantly reloads the Guard module. The log contains many "cannot read counters" errors.

CSCsi89346—The Guard module stops processing traffic. Traffic is not diverted to the Guard module.

Software Version 6.0(5) Open and Resolved Caveats

The following sections contain the open and resolved caveats in software version 6.0(5):

Software Version 6.0(5) Open Caveats

Software Version 6.0(5) Resolved Caveats

Software Version 6.0(5) Open Caveats

The following caveats are open in software version 6.0(5):

CSCrh01198—After you reload the Guard module, it erases the default gateway if the gateway is on the same subnet as one of the configured VLAN interfaces on the module. Workaround: Use a static route instead of a default gateway.

CSCsa64914—The name of the Flexible Filter Drop Count counter in the WBM Zone>Configuration>General menu should be Flexible Filter Drop Rate. This counter accurately displays the drop rate of the Flex-Content filter. The General menu also contains the Flexible Filter Action and Flexible Filter Count fields. When the Flexible Filter Action value is displayed as:

Drop, the Flexible Filter Count value displays the number of dropped packets

Count, the Flexible Filter Count value displays the number of counted packets

CSCsa78440—The protect-by-packet activation interface does not apply to zones that are on the same subnet as the Guard module. Workaround: Use another activation interface.

CSCsb07081—The flex-content filter cannot find a pattern in SYN packets.

CSCsb20206—The Web-Based Manager (WBM) remains unresponsive while the pop up window waits for results from the signature generation process. Even if you close the pop up window manually, the WBM remains unresponsive while signature generation is in progress. Workaround: Wait until the pop up window receives a result or issue the no service wbm CLI command in configuration mode.

CSCsb29083—You cannot assign an identical name to manual packet dumps that you create in different zones. Workaround: Assign unique names to manual packet dumps.

CSCsc05116—The Guard module may stop functioning or start logging errors after reaching 100% anomaly detection engine memory utilization. Workaround: Use the show resources command in global mode to view the amount of anomaly detection engine memory currently being used by the Guard module. Reducing the number of active zones may free up memory.

CSCsc36095—Loopback interfaces 100 and higher disappear or become proxy interfaces when you upgrade from previous software versions to software version 6.0(x). Workaround: Renumber loopback interfaces before upgrading the Guard module to software version 6.0(x).

CSCsc51207—The Guard module does not evaluate all conditions defined in the flex-content filter when the filter is built from more than one offset-based element (for example, udp[64:4]=0x1234) with "or" between them. If one of the elements has an offset beyond the packet end, the Guard module does not evaluate the rest of elements. Workaround: Build the filter in a form in which its elements are ordered by an offset.

CSCsc69508—After importing an HTML file to serve as the login banner, some SSH clients may not be able to connect to the product.

CSCsd83077—The Guard module responds to a larger size packet than the MTU value set for its network interfaces.

CSCse08139—The CLI session terminates when you press Ctrl-Z several times after issuing the more 0 command.

CSCse19834—Activating a zone with a combination of a large number of subnets and excluded subnets may take a few seconds to several minutes, depending on the number of subnets (excluded or included).

CSCse27876—When you press Ctrl-C during an import of a new software version or configuration, you interrupt the import process and the CLI session may get disconnected. Workaround: Do not press Ctrl-C during the import process.

CSCse31042—A zone configuration that contains ip_scan or port_scan policies cannot be imported into the Guard module. Workaround: None.

CSCsf06487—This caveat applies to the 6.0-XG (3 Gbps) Guard module only. A zone that is directly connected to the Guard module does not receive traffic without an explicit injection configuration. Workaround: Create an injection configuration for the required zone.

CSCsh36537—This caveat applies to the 6.0-XG (3 Gbps) Guard module only. The rate limit defined on a zone or a user filter is multiplied by three. Workaround: If the traffic is equally balanced between the Guard module ports, define the rate limit as 1/3 of the desired limit. If not, there is no workaround.

CSCuk54606—When activating a zone by issuing the protect or the learning commands, the Guard module displays the following error message even when the configuration is correct and traffic diversion is working properly:

no injection path 
 
 

The Guard module may display this message if it does not have a default injection route and the zone injection definition consists of two or more injection routes with an IP address that does not match the zone IP address (for example, a zone IP address of 192.168.254.0/24 and zone injection routes of 192.168.254.0/25 and 192.168.254.128/25). Workaround: Configure a default injection route for the Guard module, or configure the zone injection routes to match the zone IP addresses. For example, if you configure the injection routes to be 192.168.254.0/25 and 192.168.254.128/25, configure the zone IP addresses as 192.168.254.0/25 and 192.168.254.128/25.

Software Version 6.0(5) Resolved Caveats

The following caveats were resolved in software version 6.0(5):

CSCsc85020—The graph interpolates the end of an attack curve with current time instead of the real end of attack time.

CSCse64988—When you use the WBM to add a service to a zone, the service thresholds are set to zero and are not tuned.

CSCsf02506—When you use the WMB to show zone general information, the error message may appear on the first try: "Unexpected error".

CSCsg22709—When you add a service in a WBM comparison screen, the service is not added to the zone. This occurs when you compare a zone with a snapshot.

CSCsg53101—When you use the WBM excessively, the RAM disk becomes filled with logs before the logrotate policy removes old logs. This situation may cause the Guard module to become unstable and inaccessible.

CSCsg83409—You may encounter a blank page in the Safari Browser (on a MAC OS) when using the basic or redirect anti-spoofing mechanism.

Related Documentation

The following documentation is available for the Cisco Anomaly Guard Module:

Cisco Anomaly Guard Module and Traffic Anomaly Detector Module Installation Note

Cisco Anomaly Guard Module Configuration Guide

Cisco Anomaly Guard Module Web-Based Manager Configuration Guide

Obtaining Documentation, Obtaining Support, and Security Guidelines

For information on obtaining documentation, obtaining support, providing documentation feedback, security guidelines, and also recommended aliases and general Cisco documents, 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

© 2007 Cisco Systems, Inc. All rights reserved.