Security Guide vA5(1.0), Cisco ACE Application Control Engine
Configuring TCP/IP Normalization and IP Reassembly Parameters
Downloads: This chapterpdf (PDF - 610.0KB) The complete bookPDF (PDF - 6.83MB) | Feedback

Configuring TCP/IP Normalization and IP Reassembly Parameters

Table Of Contents

Configuring TCP/IP Normalization and IP Reassembly Parameters

TCP Normalization Overview

IP Normalization Overview

TCP/IP Normalization and Termination Configuration Quick Start

Configuring a Connection Parameter Map for TCP/IP Normalization and Termination

Creating a Connection Parameter Map for TCP/IP, UDP, and ICMP

Defining a Description of the Connection Parameter Map

Configuring Rate Limits for a Policy Map

Setting the Maximum Receive or Transmit Buffer Share

Setting a Range for the Maximum Segment Size

Configuring ACE Behavior for a Segment That Exceeds the Maximum Segment Size

Setting the Maximum Number of TCP SYN Retries

Enabling Nagle's Algorithm

Enabling Random TCP Sequence Numbers

Configuring How the ACE Handles Reserved Bits

Configuring the Timeout for an Embryonic Connection

Configuring the Timeout for a Half-Closed Connection

Setting the TCP Reassembly Timeout

Configuring the Connection Inactivity Timeout

Setting How the ACE Applies TCP Optimizations to Packets

Setting the Window Scale Factor

Enabling the TCP Slow Start Algorithm

Setting the ACK Delay Timer

Configuring How the ACE Handles TCP SYN Segments that Contain Data

Configuring How the ACE Handles TCP Options

Setting the Urgent Pointer Policy

Setting the Type of Service

Configuring a Traffic Policy for TCP/IP Normalization and Termination

Configuring a Layer 4 Class Map

Defining a Class Map Description

Specifying IP Address Match Criteria

Defining a TCP or UDP Port Number or Port Range Match Criteria

Configuring a Layer 3 and Layer 4 Policy Map

Associating a Layer 3 and Layer 4 Class Map with a Policy Map

Associating a Connection Parameter Map with a Policy Map

Associating a Layer 3 and Layer 4 Policy Map with a Service Policy

Configuring Interface Normalization Parameters

Disabling TCP Normalization on an Interface

Enabling Normalization Send Reset on an Interface

Disabling the ICMP Security Checks on an Interface

Configuring SYN-Cookie Denial-of-Service Protection

Overview of SYN Cookie DoS Protection

Configuration and Operational Considerations

Configuring SYN Cookie DoS Protection on an Interface

Configuring IPv6 Extension Header Processing

Configuring How the ACE Handles the Don't Fragment Bit

Configuring IPv4 Header Options Processing

Setting the IP Packet TTL

Configuring Unicast Reverse-Path Forwarding

Configuring IP Fragment Reassembly Parameters

IP Fragment Reassembly Configuration Quick Start

Configuring the MTU for an Interface

Configuring the Maximum Number of Fragments in a Packet

Configuring the Minimum Fragment Size for Reassembly

Configuring an IP Reassembly Timeout

Configuring the Switch Mode Feature

Example of a TCP/IP Normalization and IP Reassembly Configuration

Displaying Configurations and Statistics for TCP/IP and UDP Connections, IP Reassembly, and SYN Cookie

Displaying TCP/IP and UDP Connection Configurations

Displaying a Connection Parameter Map

Displaying TCP/IP and UDP Connection Statistics

Displaying Global Context Connection Statistics

Displaying IP Statistics

Displaying IP Traffic Information

Displaying IP Fragmentation and Reassembly Statistics

Displaying TCP Statistics

Displaying UDP Statistics

Displaying Service Policy Statistics

Displaying SYN Cookie Statistics

Clearing TCP/IP and UDP Connections and Statistics

Clearing Connections

Clearing Connection Statistics

Clearing IP, TCP, and UDP Statistics

Clearing IP Statistics

Clearing TCP Statistics

Clearing UDP Statistics

Clearing IP Fragmentation and Reassembly Statistics

Clearing SYN Cookie Statistics


Configuring TCP/IP Normalization and IP Reassembly Parameters



Note The information in this chapter applies to both the ACE module and the ACE appliance unless otherwise noted.


This chapter describes how to configure TCP/IP normalization and termination parameters to protect your ACE and the data center from attacks. It also describes IP fragmentation and reassembly parameters. The chapter contains the following major sections:

TCP Normalization Overview

IP Normalization Overview

TCP/IP Normalization and Termination Configuration Quick Start

Configuring a Connection Parameter Map for TCP/IP Normalization and Termination

Configuring a Traffic Policy for TCP/IP Normalization and Termination

Configuring Interface Normalization Parameters

Configuring IP Fragment Reassembly Parameters

Configuring the Switch Mode Feature

Example of a TCP/IP Normalization and IP Reassembly Configuration

Displaying Configurations and Statistics for TCP/IP and UDP Connections, IP Reassembly, and SYN Cookie

Clearing TCP/IP and UDP Connections and Statistics

TCP Normalization Overview

This section describes how the ACE uses TCP normalization to protect itself and the data center from a variety of network-based attacks.

TCP normalization is a Layer 4 feature that consists of a series of checks that the ACE performs at various stages of a flow, from the initial connection setup to the closing of a connection.You can control many of the segment checks by configuring one or more advanced TCP connection settings. The ACE uses these TCP connection settings to decide which checks to perform and whether to discard a TCP segment based on the results of the checks. The ACE discards segments that appear to be abnormal or malformed.

With TCP normalization, the ACE checks for segments that have invalid or suspect conditions (for example, a SYN sent to the client from the server or a SYNACK sent to the server from the client) and takes actions based on the configured parameter settings. The ACE uses TCP normalization to block certain types of network attacks (for example, insertion attacks and evasion attacks). Insertion attacks occur when the inspection module accepts a packet that the end system rejects. Evasion attacks occur when the inspection module rejects a packet while the end system accepts it.

The ACE always discards segments when the following conditions exist:

Bad segment checksum

Bad TCP header or payload length

Suspect TCP flags (for example, NULL, SYN/FIN, or FIN/URG)

TCP normalization is enabled by default. If you are migrating to, or replacing legacy products with the ACE, disable normalization using the no ipv6 normalization or the no normalization command in interface configuration mode until you are sure that everything is working properly. Then, reenable normalization using the ipv6 normalization or the normalization command in interface configuration mode.

To configure TCP normalization on the ACE, you assemble various TCP commands into a parameter map. After you create the connection parameter map, you associate it with a multi-match policy map, and activate the traffic policy globally across all interfaces in the context using a service policy. For details about configuring traffic policies, see the "Configuring a Traffic Policy for TCP/IP Normalization and Termination" section.

IP Normalization Overview

In addition to TCP normalization, the ACE uses a Layer 3 feature called IP normalization to protect itself and the data center from a variety of attacks.

IP normalization performs the following series of checks on IP packets:

General security checks

ICMP security checks

Fragmentation security checks

IP fragment reassembly

IP fragmentation if a packet exceeds the outbound maximum transmission unit (MTU)

If a packet fails one of these checks, the ACE takes action (including discarding a packet) depending on the IP parameters that you configure.


Note Because IP normalization is always enabled on the ACE, if you have a Layer 2 connected server that sends traffic with a source MAC address that is not the one advertised by the ARP reply to received traffic, the ACE drops this traffic.


To configure the type of service (ToS) for IP traffic, use the set ip tos command in a connection parameter map.

To configure interface-related IP normalization parameters, see the "Configuring Interface Normalization Parameters" section.

TCP/IP Normalization and Termination Configuration Quick Start

Table 4-1 provides a quick overview of the steps required to configure TCP normalization. Each step includes the CLI command or a reference to the procedure required to complete the task. For a complete description of each feature and all the options associated with the CLI commands, see the sections following Table 4-1.

Table 4-1 TCP/IP Normalization and Termination Configuration Quick Start 

Task and Command Example

1. If you are operating in multiple contexts, observe the CLI prompt to verify that you are operating in the desired context. If necessary, change to the correct context.

host1/Admin# changeto C1
host1/C1#
 
        

The rest of the examples in this table use the C1 user context, unless otherwise specified. For details on creating contexts, see the Virtualization Guide, Cisco ACE Application Control Engine.

2. Enter configuration mode.

host1/C1# config
host1/C1(config)#

3. Create a connection parameter map to group together TCP/IP normalization and termination parameters.

host1/C1(config)# parameter-map type connection TCPIP_PARAM_MAP
host1/C1(config-parammap-conn)#

4. Configure TCP/IP normalization parameters in the connection parameter map as required. For example, enter:

host1/C1(config-parammap-conn)# set timeout inactivity 2400
host1/C1(config-parammap-conn)# set ip tos 20
host1/C1(config-parammap-conn)# exit
host1/C1(config)#

5. Create a Layer 3 and Layer 4 TCP class map, and then configure match criteria as required.

host1/C1(config)# class-map match-any TCP_CLASS
host1/C1(config-cmap)# match destination-address 2001:DB8:1::/64
or
host1/C1(config-cmap)# match destination-address 172.27.16.7
 
        
host1/C1(config-cmap)# match port-v6 tcp eq 21
or
host1/C1(config-cmap)# match port tcp eq 21
host1/C1(config-cmap)# exit

6. Create a Layer 3 and Layer 4 policy map and associate the class map with it.

host1/C1(config)# policy-map multi-match TCPIP_POLICY
host1/C1(config-pmap)# class TCP_CLASS
host1/C1(config-pmap-c)# exit
host1/C1(config-pmap)# exit

7. Associate the connection parameter map as an action in the TCP/IP policy map.

host1/C1(config-pmap-c)# connection advanced-options 
TCPIP_PARAM_MAP
host1/C1(config-pmap-c)# exit
host1/C1(config-pmap)# exit

8. Apply the policy map globally across all interfaces in the context using a service policy.

host1/C1(config)# interface vlan 50
host1/C1(config-if)# service-policy input TCPIP_POLICY
host1/C1(config-if)# exit

9. Configure additional IP normalization parameters in interface configuration mode.

host1/C1(config-if)# ip ttl 15
host1/C1(config-if)# ip options clear
host1/C1(config-if)# ip df allow
host1/C1(config-if)# exit
host1/C1(config)# exit

10. (Optional) Save your configuration changes to flash memory.

host1/C1# copy running-config startup-config

11. Display the TCP/IP normalization configuration information.

host1/C1# show running-config policy-map
host1/C1# show running-config parameter-map
host1/C1# show running-config interface
host1/C1# show service-policy name

Configuring a Connection Parameter Map for TCP/IP Normalization and Termination

You can configure a parameter map to group TCP/IP connection-related commands that apply to normalization and termination. After you configure the parameter map, associate it with a specific action statement in a policy map using the connection tcp advanced-options command. For details about associating a parameter map with a policy map, see the "Associating a Connection Parameter Map with a Policy Map" section. This section contains the following topics:

Creating a Connection Parameter Map for TCP/IP, UDP, and ICMP

Defining a Description of the Connection Parameter Map

Configuring Rate Limits for a Policy Map

Setting the Maximum Receive or Transmit Buffer Share

Setting a Range for the Maximum Segment Size

Configuring ACE Behavior for a Segment That Exceeds the Maximum Segment Size

Setting the Maximum Number of TCP SYN Retries

Enabling Nagle's Algorithm

Enabling Random TCP Sequence Numbers

Configuring How the ACE Handles Reserved Bits

Configuring the Timeout for an Embryonic Connection

Configuring the Timeout for a Half-Closed Connection

Configuring the Connection Inactivity Timeout

Setting How the ACE Applies TCP Optimizations to Packets

Setting the Window Scale Factor

Enabling the TCP Slow Start Algorithm

Setting the ACK Delay Timer

Configuring How the ACE Handles TCP SYN Segments that Contain Data

Configuring How the ACE Handles TCP Options

Setting the Urgent Pointer Policy

Setting the Type of Service

Creating a Connection Parameter Map for TCP/IP, UDP, and ICMP

You can create a connection parameter map for TCP/IP, UDP, and ICMP by using the parameter-map type connection command in configuration mode. The syntax of this command is as follows:

parameter-map type connection map_name

The map_name argument is a unique name as an unquoted text string with no spaces with a maximum of 64 alphanumeric characters.

For example, to create a connection parameter map, enter:

host1/C1(config)# parameter-map type connection TCPIP_PARAM_MAP
host1/C1(config-parammap-conn)#
 
   

To remove the connection parameter map from the configuration, enter:

host1/C1(config)# no parameter-map type connection TCPIP_PARAM_MAP
 
   

Use one or more of the commands in the sections that follow to define the connection parameter map.

To limit the maximum number of ACE connections, create a resource class and then use the following commands:

Through-the-ACE connections—limit-resource conc-connections

To-the-ACE connections—limit-resource mgmt-connections

Make sure that you assign the current context to the resource class. For details about resource classes, see the Virtualization Guide, Cisco ACE Application Control Engine.


Note If you configure switch mode and you configure any connection parameter-map commands (for example, set tcp buffer-share, rate-limit, exceed-mss, nagle, random-sequence-number, reserved-bits, set tcp wan-optimization, timeout inactivity, slowstart, and so on) either locally on a specific interface or globally on all interfaces, switch mode will override these commands for certain types of traffic. This behavior applies only to non-VIP, non-inspection, non-NATed, and non-management traffic. The ACE continues to apply local, global, and VIP-specific connection parameter maps to load-balanced (VIP), inspected, NATed, and management traffic. For details about switch mode, see the "Configuring the Switch Mode Feature" section.


Defining a Description of the Connection Parameter Map

You can provide a brief summary of the connection parameter map by using the description command in parameter map connection configuration mode. The syntax of this command is as follows:

description text

For the text argument, enter an unquoted text string with a maximum of 240 alphanumeric characters including spaces.

For example, to specify a description of a connection parameter map, enter the following command:

host1/Admin(config)# parameter-map type conn TCPIP_PARAM_MAP
host1/Admin(config-parammap-conn)# description TCPIP parameter map
 
   

To remove the description from the connection parameter map, enter:

host1/Admin(config-parammap-conn)# no description
 
   

Configuring Rate Limits for a Policy Map

The ACE allows you to limit the connection rate and the bandwidth rate of a policy map. The connection rate is the number of connections per second that match the policy. The bandwidth rate is the number of bytes per second that match the policy. The ACE applies these rate limits to each class map that you associate with the policy at the virtual server level.

When the connection-rate limit or the bandwidth-rate limit is reached, the ACE blocks any further traffic that matches that policy until the connection rate or bandwidth rate drops below the configured limit. By default, the ACE does not limit the connection rate or the bandwidth rate of a policy.

You can also limit the connection rate and the bandwidth rate of a real server in a server farm. For details, see the Server Load-Balancing Guide, Cisco ACE Application Control Engine.

To limit the connection rate or the bandwidth rate of a policy, use the rate-limit command in parameter map connection configuration mode. The syntax of this command is as follows:

rate-limit {connection number1 | bandwidth number2}

The keywords and arguments are as follows:

connection number1—Specifies the connection-rate limit for a policy in connections per second. Enter an integer from 0 to 350000. There is no default value.

bandwidth number2—Specifies the bandwidth-rate limit for a policy in bytes per second. Enter an integer from 0 to 300000000. There is no default value.

For example, to limit the connection rate of a policy to 100000 connections per second, enter:

host1/Admin(config)# parameter-map type connection RATE-LIMIT
host1/Admin(config-parammap-conn)# rate-limit connection 100000
 
   

To return the behavior of the ACE to the default of not limiting the policy connection rate, enter:

host1/Admin(config-parammap-conn)# no rate-limit connection 100000
 
   

For example, to limit the policy bandwidth rate to 5000000 bytes per second, enter:

host1/Admin(config)# parameter-map type connection RATE-LIMIT
host1/Admin(config-parammap-conn)# rate-limit bandwidth 50000000
 
   

To return the behavior of the ACE to the default of not limiting the policy bandwidth rate, enter:

host1/Admin(config-parammap-conn)# no rate-limit bandwidth 50000000

Setting the Maximum Receive or Transmit Buffer Share

To improve throughput and overall performance, the ACE checks the number of buffered bytes on each TCP and UDP connection against the configured buffer setting before accepting new receive or transmit data. By default, the maximum size of the receive or transmit buffer for each TCP or UDP connection is 32768 bytes. For large bandwidth and delay network connections, you may want to increase the default buffer size to improve your network performance. To set the maximum receive or transmit buffer size for each TCP and UDP connection, use the set tcp buffer-share command in parameter map connection configuration mode. The syntax of this command is as follows:

set tcp buffer-share number

The number argument is the maximum size of the receive or transmit buffer in bytes for each TCP and UDP connection. Enter an integer from 8192 to 262143 bytes. The default is 32768 bytes.


Caution If you are using the ACE to terminate SSL traffic, do not decrease the buffer share value below the default value of 32 KB. With a buffer share value of less than 32 KB, SSL connections are significantly slower.


Note If you set the set content-maxparse-length or set header-maxparse-length command in HTTP parameter-map configuration mode to a value that is greater than 32 KB, you must configure the set tcp buffer-share command in a connection parameter map to a value that is greater than either of the other command's value. If you do not, even if you configure length-exceed continue command, the ACE may not completely parse a content string or a header packet that is greater than 32 KB. The reason is that the default value of the set tcp buffer-share command buffer size (32 KB) will not accommodate the larger content string size.


For example, enter:

host1/C1(config-parammap-conn)# set tcp buffer-share 16384
 
   

To reset the buffer limit to the default value of 32768 bytes, enter:

host1/C1(config-parammap-conn)# no set tcp buffer-share

Setting a Range for the Maximum Segment Size

The maximum segment size (MSS) is the largest amount of TCP data that the ACE accepts in one segment. To prevent the transmission of many smaller segments that waste bandwidth or very large segments that may require fragmentation, you can set the minimum and maximum acceptable sizes of the MSS. To set the MSS, use the set tcp mss command in parameter map connection configuration mode. The syntax of this command is as follows:

set tcp mss min number1 max number2

The keywords and arguments are as follows:

min number1—Specifies the smallest segment size that the ACE will accept. Enter an integer from 0 to 65535 bytes. The default is 0 bytes. The min number value must be less than or equal to the max number value. A value of 0 instructs the ACE to not perform a minimum MSS check on the incoming segment.

max number2—Specifies the largest segment size that the ACE will accept. Enter an integer from 0 to 65535 bytes. The default is 1460 bytes. The max number value must be greater than or equal to the min number value. A value of 0 instructs the ACE to not perform a maximum MSS check on the incoming segment.


Caution If you configure a Layer 7 policy map and set the maximum transmit unit (MTU) of the ACE server-side VLAN lower than the client maximum segment size (MSS), ensure that the maximum value of the MSS that you set for the ACE using the set tcp mss max command is at least 40 bytes (the size of the TCP header plus options) less than the MTU of the ACE server-side VLAN. Otherwise, the ACE may discard incoming packets from the server.

Both the host and the server can set the MSS when they first establish a connection. If either maximum exceeds the value that you set with the set tcp mss max command, the ACE overrides the maximum value and inserts the value that you set. If either maximum is less than the value that you set with the set tcp mss min command, the ACE overrides the maximum and inserts the minimum value that you set (the minimum value is actually the smallest maximum allowed). For example, if you set a maximum size of 1200 bytes and a minimum size of 400 bytes, when a host requests a maximum size of 1300 bytes, the ACE alters the packet to request 1200 bytes (the maximum). If another host requests a maximum value of 300 bytes, the ACE alters the packet to request 400 bytes (the minimum).

If the host or server does not request an MSS, the ACE assumes that the RFC 793 default value of 536 bytes is in effect.

For example, to set the minimum acceptable MSS size to 768 bytes, and the maximum acceptable MSS size to 1500, enter:

host1/C1(config-parammap-conn)# set tcp mss min 768 max 1500
 
   

To reset the minimum MSS to the default value of 0 bytes and the maximum MSS to the default value of 1460, enter:.

host1/C1(config-parammap-conn)# no set tcp mss

Configuring ACE Behavior for a Segment That Exceeds the Maximum Segment Size

You can configure the ACE behavior for a segment that exceeds the configured maximum segment size (MSS) by using the exceed-mss command in connection parameter map configuration mode. The syntax of this command is as follows:

exceed-mss {allow | drop}

The keywords are as follows:

allow—Permits segments that exceed the configured MSS

drop—(Default) Discards segments that exceed the configured MSS

For example, to configure the ACE to allow segments that exceed the MSS, enter:

host1/C1(config-parammap-conn)# exceed-mss allow
 
   

To reset the ACE behavior to the default of discarding segments that exceed the MSS set by a peer, enter:

host1/C1(config-parammap-conn)# no exceed-mss allow

Setting the Maximum Number of TCP SYN Retries

You can set the maximum number of attempts that the ACE makes to transmit a TCP segment when initiating a Layer 7 connection by using the set tcp syn-retry command in connection parameter map configuration mode. The syntax of this command is as follows:

set tcp syn-retry number

The number argument is the number of SYN retries. Enter an integer from 1 to 15. The default is 4.


Note When you set the maximum number of TCP SYN retries using the above command, the syn-retry counter includes the initial SYN in the count of retries. If you set the number as 5, the ACE sends only 4 retries. Ensure that you increment the number of retries you want by 1.


For example, to set the maximum TCP SYN retries to 5, enter:

host1/C1(config-parammap-conn)# set tcp syn-retry 6
 
   

To reset the TCP SYN retries to the default value of 4, enter:

host1/C1(config-parammap-conn)# no set tcp syn-retry

Enabling Nagle's Algorithm

Nagle's algorithm instructs a sender to buffer any data to be sent until all outstanding data has been acknowledged or until there is a full segment of data to send. The algorithm automatically concatenates a number of small buffer messages transmitted over the TCP connection. This process increases the throughput by decreasing the number of segments that need to be sent over the network. However, the interaction between the Nagle algorithm and the TCP delay acknowledgment may increase latency in your TCP connection. You should disable the Nagle algorithm when you observe an unacceptable delay in a TCP connection.

You can enable Nagle's algorithm by using the nagle command in parameter map connection configuration mode. By default, this command is disabled. The syntax of this command is as follows:

nagle

For example, enter:

host1/C1(config-parammap-conn)# nagle
 
   

To disable Nagle's algorithm, enter:

host1/C1(config-parammap-conn)# no nagle

Enabling Random TCP Sequence Numbers

Randomizing TCP sequence numbers adds a measure of security to TCP connections by making it more difficult for a hacker to guess or predict the next sequence number in a TCP connection. This feature is enabled by default and you cannot disable this feature for Layer 7 flows. To enable TCP sequence number randomization after it has been disabled for Layer 4 flows, use the random-sequence-number command in parameter map connection configuration mode.

The syntax of this command is as follows:

random-sequence-number

For example, to enable the use of random sequence numbers if you have disabled the feature, enter:

host1/C1(config-parammap-conn)# random-sequence-number
 
   

To disable sequence number randomization for Layer 4 flows, enter:

host1/C1(config-parammap-conn)# no random-sequence-number
 
   

Note The no random-sequence-number command has no effect on Layer 7 flows.


Configuring How the ACE Handles Reserved Bits

You can configure how an ACE handles segments with the reserved bits set in the TCP header by using the reserved-bits command in parameter map connection configuration mode. The six reserved bits in the TCP header are for future use and usually have a value of 0. The syntax of this command is as follows:

reserved-bits {allow | clear | drop}

The keywords are as follows:

allow—(Default) Permits segments with the reserved bits set in the TCP header

clear—Clears the reserved bits in the TCP header and allows the segment

drop—Discards segments with reserved bits set in the TCP header

For example, to configure the ACE to clear the reserved bits set in the TCP header of segments, enter:

host1/C1(config-parammap-conn)# reserved-bits clear
 
   

To reset the ACE behavior to the default of allowing reserved bits set in the TCP header of a segment, enter:

host1/C1(config-parammap-conn)# no reserved-bits clear

Configuring the Timeout for an Embryonic Connection

Occasionally, the TCP three-way handshake for a connection may not complete for some reason. This type of connection is called an embryonic connection. To configure a timeout for embryonic connections, use the set tcp timeout embryonic command in parameter map connection configuration mode. The syntax of this command is as follows:

set tcp timeout embryonic seconds

The seconds argument is an integer from 0 to 4294967295 seconds. The default is 5 seconds. A value of 0 specifies that the ACE does not time out an embryonic connection.


Note This command affects only Layer 4 flows and not Layer 7 flows.


For example, enter:

host1/C1(config-parammap-conn)# set tcp timeout embryonic 24
 
   

To reset the TCP embryonic connection timeout to the default value of 5 seconds, enter:

host1/C1(config-parammap-conn)# no set tcp timeout embryonic

Configuring the Timeout for a Half-Closed Connection

A half-closed connection is a connection in which the client (or server) sends a FIN and the server (or client) ACKs the FIN without sending a FIN itself. The timer starts once this condition has occurred. To configure a timeout for a half-closed connection, use the set tcp timeout half-closed command in parameter map connection configuration mode. The syntax of this command is as follows:

set tcp timeout half-closed seconds

The seconds argument is an integer from 0 to 4294967295 seconds. The default is 3600 seconds (1 hour). A value of 0 specifies that the ACE does not time out a half-closed TCP connection.

For example, enter:

host1/C1(config-parammap-conn)# set tcp timeout half-closed 2400
 
   

To reset the TCP half-closed connection timeout to the default value of 3600 seconds, enter:

host1/C1(config-parammap-conn)# no set tcp timeout half-closed

Setting the TCP Reassembly Timeout

The ACE uses the TCP reassembly timeout to stop reassembling TCP packets that have remained idle for the specified timeout period. To set the TCP reassembly timeout, use the set tcp reassembly-timeout command in parameter map connection configuration mode. The syntax of this command is:

set tcp reassembly-timeout seconds

The seconds argument is the time period after which the ACE stops reassembling TCP packets. Enter an integer from 1 to 255. The default is 60 seconds.

For example, to set the TCP reassembly timeout to five minutes, enter the following command:

host1/Admin(config-parammap-conn)# set tcp reassembly-timeout 300
 
   

To reset the timeout to the default value of 60 seconds, enter the following command:

host1/Admin(config-parammap-conn)# no set tcp reassembly-timeout
 
   

Configuring the Connection Inactivity Timeout

The ACE uses the connection inactivity timer to disconnect established HTTP/SSL, ICMP, TCP/IP, and UDP connections that have remained idle for the duration of the specified timeout period. To configure the connection inactivity timer, use the set timeout inactivity command in parameter map connection configuration mode. The syntax of this command is as follows:

set timeout inactivity seconds

The seconds argument is the time period after which the ACE disconnects idle established connections. Enter an integer from 0 to 3217203 seconds. The defaults are as follows:

HTTP/SSL—300 seconds

ICMP—2 seconds

TCP—3600 seconds (1 hour)

UDP—10 seconds

A value of 0 specifies that the ACE does not time out a TCP connection. The ACE rounds up the value that you enter to the nearest 30-second interval.

For example, to set the connection inactivity timeout to 2400 seconds (40 minutes), enter:

host1/C1(config-parammap-conn)# set timeout inactivity 2400
 
   

To reset the connection inactivity timeout to the default values, enter:

host1/C1(config-parammap-conn)# no set timeout inactivity

Setting How the ACE Applies TCP Optimizations to Packets

You can control how the ACE applies TCP optimizations to packets on a connection associated with a Layer 7 policy map using a round-trip time (RTT) value by using the set tcp wan-optimization rtt command in parameter map connection configuration mode.

TCP optimizations include the following connection parameter-map configuration mode operations:

Nagle optimization algorithm (see the "Enabling Nagle's Algorithm" section)

Slow-start connection behavior (see the "Enabling the TCP Slow Start Algorithm" section)

Acknowledgement (ACK) delay timer (see the "Setting the ACK Delay Timer" section)

Window-scale factor (see the "Setting the Window Scale Factor" section)

Retry settings (see the "Setting the Maximum Number of TCP SYN Retries" section)

The syntax of this command is as follows:

set tcp wan-optimization rtt number

The number argument is the round-trip time (RTT) in milliseconds and controls how the ACE applies TCP optimizations as follows:

For a value of 0, the ACE applies TCP optimizations to packets for the life of a connection.

For a value of 65535 (the default), the ACE performs normal operations (no optimizations) for the life of a connection.

For values from 1 to 65534, the ACE applies TCP optimizations to packets based on the client RTT to the ACE as follows:

If the actual client RTT is less than the configured RTT, the ACE performs normal operations for the life of the connection.

If the actual client RTT is greater than or equal to the configured RTT, the ACE performs TCP optimizations on the packets for the life of a connection.

For example, to specify the ACE applies TCP optimizations to packets for the life of a connection, enter:

host1/C1(config-parammap-conn)# set tcp wan-optimization rtt 0
 
   

To restore the ACE behavior to the default of not optimizing TCP connections, enter:

host1/C1(config-parammap-conn)# no set tcp wan-optimization rtt 0

Setting the Window Scale Factor

The TCP window scaling feature adds support for the Window Scaling option in RFC 1323. We recommend that you increase the window size to improve TCP performance in network paths with large bandwidth, long-delay characteristics. This type of network is called a long fat network (LFN).

The window scaling extension expands the definition of the TCP window to 32 bits and then uses a scale factor to carry this 32-bit value in the 16-bit window field of the TCP header. You can increase the window size to a maximum scale factor of 14. Typical applications use a scale factor of 3 when deployed in LFNs.

For Layer 7 connections (where the ACE terminates the connection), the ACE forwards the original window scale factor from the client to the server. The ACE sends the window scale factor that you configure in the SYN-ACK to the client. The ACE window scale factor must match the server window scale factor or the tcp-options command must be set to clear the window scale option. Otherwise, unexpected results may occur. For more information about the tcp-options command, see the "Configuring How the ACE Handles TCP Options" section.

For Secure Sockets Layer (SSL) connections or for configurations where the WAN optimization RTT is set to zero (see the "Setting How the ACE Applies TCP Optimizations to Packets" section), window scale mismatches between the ACE and a server are allowed. For all other connections, the ACE window scale factor must match the server window scale factor.

To set the TCP window scale factor, use the set tcp window-scale command in parameter map connection configuration mode. The syntax of this command is as follows:

set tcp window-scale number

The number argument is an integer from 0 to 14. The default is 0.

For example, to set the TCP window scale factor to 3, enter:

host1/C1(config-parammap-conn)# set tcp window-scale factor 3

To reset to the default value of 0, enter:

host1/C1(config-parammap-conn)# no set tcp window-scale

Enabling the TCP Slow Start Algorithm

The slow start algorithm is a congestion avoidance method in which TCP increases its window size as ACK handshakes arrive. It operates by observing that the rate at which new segments should be injected into the network is the rate at which the acknowledgments are returned by the host at the other end of the connection. This feature is disabled by default. For details about the TCP slow start algorithm, see RFC 2581 and RFC 3782.

To enable the slow start algorithm, use the slowstart command in parameter map connection configuration mode. The syntax of this command is as follows:

slowstart

For example, to enable the slow start feature, enter:

host1/C1(config-parammap-conn)# slowstart
 
   

To disable the slow start algorithm, enter:

host1/C1(config-parammap-conn)# no slowstart

Setting the ACK Delay Timer

You can configure the ACE to delay sending the ACK from a client to a server. Some applications require delaying the ACK for best performance. Delaying the ACK can also help reduce congestion by sending one ACK for multiple segments rather than ACKing each segment individually. To configure an ACK delay, use the set tcp ack-delay command in parameter map connection configuration mode. The syntax of this command is as follows:

set ack-delay number

The number argument is an integer from 0 to 400 ms. The default is 200 ms.

For example, to delay sending an ACK from a client to a server for 400 ms, enter:

host1/C1(config-parammap-conn)# set ack-delay 400
 
   

To reset the ACK delay timer to the default value of 200 ms, enter:

host1/C1(config-parammap-conn)# no set ack-delay

Configuring How the ACE Handles TCP SYN Segments that Contain Data

Occasionally, the ACE may receive a TCP SYN segment that contains data. You can configure the ACE to either discard the segment or flag the segment for data processing. To set the ACE behavior for SYN segments with data, use the syn-data command in parameter map connection configuration mode. The syntax of this command is as follows:

syn-data {allow | drop}

The keywords are as follows:

allow—(Default) Permits the SYN segments that contain data and marks them for data processing

drop—Discards the SYN segments that contain data

For example, to discard SYN segments that contain data, enter:

host1/C1(config-parammap-conn)# syn-data drop
 
   

To reset the ACE behavior to the default of allowing SYN segments that contain data, enter:

host1/C1(config-parammap-conn)# no syn-data drop

Configuring How the ACE Handles TCP Options

The ACE permits you to allow or clear the following explicitly supported TCP options specified in a SYN segment:

Selective Acknowledgement (SACK)

Time stamp

Window Scale

You can also specify a range of TCP option numbers for those TCP options not explicitly supported by the ACE. To configure TCP options, use the tcp-options command in parameter map connection configuration mode. The syntax of this command is as follows:

tcp-options {range number1 number2 {allow | drop}} | {selective-ack | timestamp | window-scale} {allow | clear | drop}

The order of precedence for the actions in this command is as follows:

1. Drop

2. Clear

3. Allow

The keywords, options, and variables are as follows:

range—Specifies the TCP options not explicitly supported by the ACE using a range of option numbers. This command enables you to allow or discard segments associated with the TCP options specified in the option range.

number1—Lower limit of the TCP option range. Enter either 6 or 7 or an integer from 9 to 255. See Table 4-2.

number2—Upper limit of the TCP option range. Enter either 6 or 7 or an integer from 9 to 255. See Table 4-2.

allow—Allows any segment with the specified option set.

drop—Used with the range or window-scale option only. Causes the ACE to discard any segment with the specified option set.

selective-ack—Allows the ACE to inform the sender about all segments that it received. The sender needs to retransmit the lost segments only, rather than wait for a cumulative acknowledgement or retransmit segments unnecessarily. Selective ACK (SACK) can reduce the number of retransmitted segments and increase the throughput under some circumstances.

timestamp—Measures the round-trip time (RTT) of a TCP segment between two nodes on a network. Time stamps are always sent and echoed in both directions.

window-scale—Allows the ACE to use a window scale factor that essentially increases the size of the TCP send and receive buffers. The sender specifies a window scale factor in a SYN segment that determines the send and receive window size for the duration of the connection.

clear—Default for the explicitly supported options. Clears the specified option from any segment that has it set and allows the segment.

Table 4-2 lists the TCP options available for the tcp-options range command.

Table 4-2 TCP Options for the tcp options range Command 

Kind
Length
Description
Reference

6

6

Echo (obsoleted by option 8)

[RFC1072]

7

6

Echo reply (obsoleted by option 8)

[RFC1072]

9

2

Partial order connection permitted

[RFC1693]

10

3

Partial order service profile

[RFC1693]

11

 

CC

[RFC1644]

12

 

CC.NEW

[RFC1644]

13

 

CC.ECHO

[RFC1644]

14

3

TCP alternate checksum request

[RFC1146]

15

N

TCP alternate checksum data

[RFC1146]

16

 

Skeeter

[Knowles]

17

 

Bubba

[Knowles]

18

3

Trailer checksum option

[Subbu & Monroe]

19

18

MD5 signature option

[RFC2385]

20

 

SCPS capabilities

[Scott]

21

 

Selective negative acknowledgements (SNACK)

[Scott]

22

 

Record boundaries

[Scott]

23

 

Corruption experienced

[Scott]

24

 

SNAP

[Sukonnik]

25

 

Unassigned (released 12/18/00)

 

26

 

TCP compression filter

[Bellovin]


Table 4-3 lists the TCP options explicitly supported by this command.

Table 4-3 TCP Options Explicitly Supported by the ACE 

Kind
Length
Description
Reference

0

-

End of option list

[RFC793]

1

-

No operation

[RFC793]

3

3

WSOPT—Window Scale

[RFC1323]

4

2

Selective acknowledgement (SACK) permitted

[RFC2018]

5

N

SACK

[RFC2018]

8

10

Time stamp option (TSOPT)

[RFC1323]


You can specify this command multiple times to configure different options and actions. If you specify the same option with different actions, the ACE uses the order of precedence described earlier in this section to decide which action to use.

For example, to allow a segment with the SACK option set, enter:

host1/C1(config-parammap-conn)# tcp-options selective-ack allow
 
   

To reset the ACE behavior to the default of clearing the SACK option and allowing the segment, enter:

host1/C1(config-parammap-conn)# no tcp-options selective-ack
 
   

You can specify a range of options for each action. If you specify overlapping option ranges with different actions, the ACE uses the order of precedence described earlier in this section to decide which action to perform for the specified options.

For example, enter:

host1/C1(config-parammap-conn)# tcp-options range 6 7 allow
host1/C1(config-parammap-conn)# tcp-options range 19 26 drop
 
   

To remove the TCP option ranges from the configuration, enter:

host1/C1(config-parammap-conn)# no tcp-options range 6 7 allow
host1/C1(config-parammap-conn)# no tcp-options range 19 26 drop

Setting the Urgent Pointer Policy

If the Urgent control bit (flag) is set in the TCP header, it indicates that the Urgent Pointer is valid. The Urgent Pointer contains an offset that indicates the location of the segment that follows the urgent data in the payload. Urgent data is data that should be processed as soon as possible, even before normal data is processed. The ACE permits you to allow or clear the Urgent flag. If you clear the Urgent flag, you invalidate the Urgent Pointer.

The ACE clears the Urgent flag for any traffic above Layer 4. If you have enabled TCP server connection reuse (see the Server Load-Balancing Guide, Cisco ACE Application Control Engine, Chapter 2, Configuring Traffic Policies for Server Load Balancing), the ACE does not pass the Urgent flag value to the server.

To set the Urgent Pointer policy, use the urgent-flag command in parameter map connection configuration mode. The syntax of this command is as follows:

urgent-flag {allow | clear}

The keywords are as follows:

allow—(Default) Permits the status of the Urgent flag. If the Urgent flag is set, the offset in the Urgent Pointer that indicates the location of the urgent data is valid. If the Urgent flag is not set, the offset in the Urgent Pointer is invalid.

clear—Sets the Urgent flag to 0, which invalidates the offset in the Urgent Pointer and allows the segment.

For example, to clear the Urgent flag and allow the segment, enter:

host1/C1(config-parammap-conn)# urgent-flag clear
 
   

To reset the ACE behavior to the default of allowing the Urgent flag, enter:

host1/C1(config-parammap-conn)# no urgent-flag

Setting the Type of Service

The type of service (ToS) for an IP packet determines how the network handles the packet and balances its precedence, throughput, delay, reliability, and cost. This information resides in the IP header. To set the ToS for packets in a particular traffic class, use the set ip tos command in parameter map connection configuration mode. The syntax of this command is as follows:

set ip tos number

Use the number argument to replace a packet's ToS byte value with the specified value. Enter an integer from 0 to 255. For details about the ToS byte, see RFCs 791, 1122, 1349, and 3168.

For example, to set a packet's ToS byte value to 20, enter:

host1/C1(config-parammap)# set ip tos 20
 
   

To reset the ACE behavior to the default of not rewriting the ToS byte value of an incoming packet, enter:

host1/C1(config-parammap)# no set ip tos 20

Configuring a Traffic Policy for TCP/IP Normalization and Termination

This section describes how to configure a traffic policy for TCP/IP normalization and termination and contains the following topics:

Configuring a Layer 4 Class Map

Configuring a Layer 3 and Layer 4 Policy Map

Associating a Connection Parameter Map with a Policy Map

Associating a Layer 3 and Layer 4 Policy Map with a Service Policy

Configuring a Layer 4 Class Map

You can use a Layer 4 class map to classify network traffic for TCP/IP normalization and termination. To match the traffic class, the network traffic must satisfy the match criteria that you specify in the class map.

To configure a class map for TCP/IP normalization and termination, use the class-map command in configuration mode. For details about configuring a class map, see the Administration Guide, Cisco ACE Application Control Engine.

The syntax of this command is as follows:

class-map [match-all | match-any] name

The keywords, arguments, and options are as follows:

match-all | match-any—(Optional) Determines how the ACE evaluates Layer 4 network traffic when multiple match criteria exist in a class map. The class map is considered a match if the match commands meet one of the following conditions.

match-all—(Default) To match the traffic class, network traffic must satisfy all the match criteria listed in the class map, typically, match commands of different types.

match-any—To match the traffic class, network traffic must match only one of the match criteria listed in the class map, typically, match commands of the same type.

name—Identifier of the class map. Enter an unquoted text string with no spaces and a maximum of 64 alphanumeric characters. The class name is used for both the class map and to configure policy for the class in the policy map.

For example, enter:

host1/C1(config)# class-map match-any TCP_CLASS
host1/C1(config-cmap)#
 
   

To remove the class map from the configuration, enter:

host1/C1(config)# no class-map match-any TCP_CLASS
 
   

This section contains the following topics:

Defining a Class Map Description

Specifying IP Address Match Criteria

Defining a TCP or UDP Port Number or Port Range Match Criteria

Defining a Class Map Description

You can use the description command in class-map configuration mode to provide a brief description of the Layer 4 class map. The syntax of this command is as follows:

description text

The text argument is an unquoted text string with a maximum of 256 alphanumeric characters.

The following example specifies a description that the class map is to filter network traffic to the server:

host1/C1(config)# class-map TCP_CLASS
host1/C1(config-cmap)# description filter tcp connections
 
   

To remove the description from the class map, enter:

host1/C1(config-cmap)# no description filter tcp connections
 
   

Continue with the following section to enter match criteria as required using the match command in class-map configuration mode.

Specifying IP Address Match Criteria

You can specify a source address, destination address, or VIP address as the Layer 3 network traffic match criteria by using the match command in class-map configuration mode. The syntax of this command is as follows:

[line_number] match {source-address | destination-address | virtual-address} ipv6_address /prefix_length | ip_address netmask

The keywords, arguments, and options are as follows:

line_number—(Optional) Argument that assists you in editing or deleting individual match commands. For example, you can enter no line_number to delete long match commands instead of entering the entire line.

source-address—Specifies the source IP address as the match criteria.

destination-address—Specifies the destination IP address as the match criteria.

virtual-address—Specifies the virtual IP (VIP) address as the match criteria.

ipv6_address—IPv6 address of the source, destination, or VIP.

/prefix_length—(Optional) Specifies the length of the IPv6 prefix.

ip_address—IP address of the source, destination, or VIP. Enter an IP address in dotted-decimal notation (for example, 192.168.12.15). You can also specify 0.0.0.0 as a wildcard that will match any IP address.

netmask—(Optional) Subnet mask for the IP address. Enter a subnet mask in dotted-decimal notation (for example, 255.255.255.0). The default subnet mask is 255.255.255.255. You can also specify 0.0.0.0 as a wildcard that will match any netmask.

There can be multiple match address commands within a single class map. Also, you can combine other match commands in the same class map.

IPv6 Example

The following example specifies that the network traffic must match destination IPv6 address 2001:DB8:1::7/64:

host1/C1(config)# class-map match-any IP_CLASS
host1/C1(config-cmap)# match destination-address 2001:DB8:1::7/64
 
   

To remove the destination IPv6 address match criteria from the class map, enter:

host1/C1(config-cmap)# no match destination-address 2001:DB8:1::7/64
 
   

IPv4 Example

The following example specifies that the network traffic must match destination IP address 172.27.16.7:

host1/C1(config)# class-map match-any IP_CLASS
host1/C1(config-cmap)# match destination-address 172.27.16.7
 
   

To remove the destination IP address match criteria from the class map, enter:

host1/C1(config-cmap)# no match destination-address 172.27.16.7

Defining a TCP or UDP Port Number or Port Range Match Criteria

You can specify a TCP or UDP port number or port range as the Layer 4 network traffic match criteria by using the match port-v6 or the match port command in class-map configuration mode. The syntax of this command is as follows:

[line_number] match {port-v6 | port} {tcp | udp {eq port1 | range port2 port3}}

The keywords, arguments, and options are as follows:

line_number—(Optional) Argument that assists you in editing or deleting individual match commands. For example, you can enter no line_number to delete long match commands instead of entering the entire line.

tcp—Specifies TCP.

udp—Specifies UDP.

eq port1—Specifies that the TCP or UDP port number of the network traffic must match the specified value. Enter an integer from 0 to 65535. A value of 0 instructs the ACE to match any port. Alternatively, you can enter a protocol keyword that corresponds to a TCP or UDP port number. See Table 4-4 for a list of supported well-known TCP port names and numbers. See Table 4-5 for a list of supported well-known UDP port names and numbers.

Table 4-4 Well-Known TCP Port Numbers and Keywords 

Keyword
Port Number
Description

domain

53

Domain Name System

ftp

21

File Transfer Protocol

ftp-data

20

File Transfer Protocol Data

h323

1720

H.323 Call Signaling Protocol

http

80

Hypertext Transfer Protocol

https

443

HTTP over TLS/SSL

irc

194

Internet Relay Chat

matip-a

350

Mapping of Airline Traffic over Internet Protocol (MATIP) Type A

nntp

119

Network News Transport Protocol

pop2

109

Post Office Protocol v2

pop3

110

Post Office Protocol v3

rtsp

554

Real Time Streaming Protocol

sip

5060

Session Initiation Protocol

skinny

2000

Skinny Client Control Protocol (SCCP)

smtp

25

Simple Mail Transfer Protocol

telnet

23

Telnet

www

80

World Wide Web


Table 4-5 Well-Known UDP Port Numbers and Keywords 

Keyword
Port Number
Description

domain

53

Domain Name System

ras

1719

H.323 RAS protocol

sip

5060

Session Initiation Protocol (SIP)

wsp

9200

Connectionless Wireless Session Protocol (WSP)

wsp-wtls

9202

Secure Connectionless WSP

wsp-wtp

9201

Connection-based WSP

wsp-wtp-wtls

9203

Secure Connection-based WSP


range port2 port3—Specifies a port range to use for the TCP or UDP port. Enter an integer from 0 to 65535. A value of 0 instructs the ACE to match any port.

You can have multiple match port-v6 or match port commands within a single class map. Also, you can combine other match commands with the match port command in the same class map.

IPv6 Examples

The following example specifies that the network traffic must match on TCP port number 23 (Telnet client):

host1/C1(config)# class-map TCP_CLASS
host1/C1(config-cmap)# match port-v6 tcp eq 23
 
   

To remove the TCP port number match criterion from the class map, enter:

host1/C1(config-cmap)# no match port-v6 tcp eq 23

IPv4 Examples

The following example specifies that the network traffic must match on TCP port number 23 (Telnet client):

host1/C1(config)# class-map TCP_CLASS
host1/C1(config-cmap)# match port tcp eq 23
 
   

To remove the TCP port number match criterion from the class map, enter:

host1/C1(config-cmap)# no match port tcp eq 23

Configuring a Layer 3 and Layer 4 Policy Map

You can configure a Layer 4 traffic policy for TCP normalization, termination, and reuse by using the policy-map command in configuration mode. The ACE attempts to match multiple classes within a Layer 4 policy map, but can match only one class within each feature. If a classification matches more than one class map, then the ACE executes all the corresponding actions. However, for a specific feature, the ACE executes only the first matching classification action. For more information about policy maps, see the Administration Guide, Cisco ACE Application Control Engine.

The syntax of this command is as follows:

policy-map multi-match name

The name argument is the identifier of the policy map. Enter an unquoted text string with no spaces and a maximum of 64 alphanumeric characters.

For example, enter:

host1/C1(config)# policy-map multi-match TCP_POLICY
host1/C1(config-pmap)#
 
   

To remove a policy map from the configuration, enter:

host1/C1(config)# no policy-map multi-match TCP_POLICY

Associating a Layer 3 and Layer 4 Class Map with a Policy Map

You can associate a Layer 4 class map with a Layer 4 policy map by using the class command in policy-map configuration mode. The syntax of this command is as follows:

class {name1 | class-default} [insert-before name2]

The keywords, arguments, and options are as follows:

name1—Name of a previously defined traffic class configured with the class-map command. Enter an unquoted text string with no spaces and a maximum of 32 alphanumeric characters.

class-default—Specifies a reserved, well-known class map created by the ACE. You cannot delete or modify this class. All traffic that fails to meet the other matching criteria in the named class map belongs to the default traffic class. If none of the specified classifications match the traffic, then the ACE performs the action specified under the class class-default command. The class-default class map has an implicit match any statement in it that enables it to match all traffic.


Note When you configure a connection parameter map with a class-default class map in a Layer 3 policy map, it is applied to all other Layer 3 class maps in the same Layer 3 policy map.


insert-before name2—(Optional) Places the current class map ahead of an existing class map specified by the name2 argument in the policy-map configuration. The ACE does not save the sequence reordering as part of the configuration.

The following example shows how to use the insert-before command to define the sequential order of two class maps in the policy map:

(config-pmap)# 10 class TCP_CLASS insert-before IP_CLASS
(config-pmap-c)#
 
   

To remove a class map from a Layer 4 policy map, enter:

(config-pmap)# no 10 class TCP_CLASS

Associating a Connection Parameter Map with a Policy Map

You can associate a connection parameter map with a policy map by using the connection advanced-options command in policy-map class configuration mode. For details about configuring a connection parameter map, see the "Configuring a Connection Parameter Map for TCP/IP Normalization and Termination" section. The syntax of this command is as follows:

connection advanced-options name

The name argument is a unique identifier of an existing parameter map, specified as an unquoted text string with a maximum of 64 alphanumeric characters.

For example, enter:

host1/C1(config-pmap-c)# connection advanced-options TCP_PARAM_MAP
 
   

To dissociate the TCP parameter map from a policy map, enter:

host1/C1(config-pmap-c)# no connection advanced-options TCP_PARAM_MAP

Associating a Layer 3 and Layer 4 Policy Map with a Service Policy

After you configure a Layer 4 policy map with a class map, a connection parameter map, and connection parameters, you must associate the policy map with a service policy to activate it. To associate a policy map with a service policy, use the service-policy command in configuration mode. The syntax of this command is as follows:

service-policy input name

The keywords and arguments are as follows:

input—Specifies that the service policy is to be applied to the incoming traffic

name—Identifier of the policy map that you want to associate with the service policy

For example, enter:

host1/C1(config)# service-policy input TCP_POLICY
 
   

To dissociate a policy map from a service policy, enter:

host1/C1(config)# no service-policy input TCP_POLICY
 
   

Configuring Interface Normalization Parameters

This section describes how to configure TCP/IP normalization parameters in interface configuration mode. It contains the following topics:

Disabling TCP Normalization on an Interface

Enabling Normalization Send Reset on an Interface

Disabling the ICMP Security Checks on an Interface

Configuring SYN-Cookie Denial-of-Service Protection

Configuring IPv6 Extension Header Processing

Configuring How the ACE Handles the Don't Fragment Bit

Configuring IPv4 Header Options Processing

Setting the IP Packet TTL

Configuring Unicast Reverse-Path Forwarding

Disabling TCP Normalization on an Interface

By default, TCP normalization is enabled. To disable TCP normalization on an interface, use the no ipv6 normalization command or the no normalization command in interface configuration mode. Disabling TCP normalization affects only Layer 4 traffic. TCP normalization is always enabled for Layer 7 traffic.

Use this command when you encounter the following two types of asymmetric flows, which would otherwise be blocked by the normalization checks that the ACE performs:

ACE only sees the client-to-server traffic. For example, for a TCP connection, the ACE sees the SYN from the client, but not the SYN-ACK from the server. In this case, apply the no ipv6 normalization or the no normalization command to the client-side VLAN.

ACE only sees the server-to-client traffic. For example, for a TCP connection, the ACE receives a SYN-ACK from the server without having received the SYN from the client. In this case, apply the no ipv6 normalization or the no normalization command to the server-side VLAN.


Note With TCP normalization disabled, the ACE still sets up flows for the asymmetric traffic described above and makes entries in the connection table. Note that the ACE does not check the TCP flags and TCP state of the connection. If a connection is in the half-closed state and a new SYN arrives, the connection is still used but the states do not change. Once the connection is closed properly, the extra ACK from the server goes through as a routed connection and the address is not masked to originate from the VIP.

With TCP normalization enabled, when the ACE receives the final ACK, the ACE removes the entry from the connection table. Even if FIN/ACK retransmission occurs, the ACE drops this packet due to TCP normalization feature. This means that the client cannot receive the final ACK and keeps the LAST_ACK state until half-close timeout occurs by the client.



Caution Disabling TCP normalization may expose your ACE and your data center to potential security risks. TCP normalization helps protect the ACE and the data center from attackers by enforcing strict security policies that are designed to examine traffic for malformed or malicious segments.

IPv6 Syntax and Examples

The syntax of this command is as follows:

no ipv6 normalization

For example, to disable TCP normalization on interface VLAN 300, enter:

host1/C1(config)# interface vlan 300
host1/C1(config-if)# no ipv6 normalization
 
   

To reenable TCP normalization, enter:

host1/C1(config-if)# ipv6 normalization

IPv4 Syntax and Examples

The syntax of this command is as follows:

no normalization

For example, to disable TCP normalization on interface VLAN 100, enter:

host1/C1(config)# interface vlan 100
host1/C1(config-if)# no normalization
 
   

To reenable TCP normalization, enter:

host1/C1(config-if)# normalization

Enabling Normalization Send Reset on an Interface

By default, the ACE silently drops any non-SYN packet when there is no flow. To enable sending a RST to the peer so it can reset its TCP connections for any non-SYN packets that are a connection miss, use the normalization send-reset command. This feature is disabled by default. Use the no form of this command to disable the normalization send-reset function.

The syntax of this command is as follows:

normalization send-reset

Prior to enabling the normalization send-reset command, ensure the following:

TCP normalization is enabled through the normalization command. By default, TCP normalization is enabled. Normalization must be enabled to use the normalization send-reset command.

Switch mode feature is disabled (see the "Configuring the Switch Mode Feature" section).

For example, to enable sending a RST to the peer so it can reset its TCP connections for any non-SYN packets, enter:

host1/Admin(config)# interface vlan 200
host1/Admin(config-if)# normalization send-reset

To disable the normalization send-reset function, enter:

host1/Admin(config-if)# no normalization send-reset

Disabling the ICMP Security Checks on an Interface

The ACE provides several ICMP security checks by matching ICMP reply packets with request packets and using mismatched packets to detect attacks. Also, the ACE forwards ICMP error packets only if a connection record exists pertaining to the flow for which the error packet was received. By default, the ACE ICMP security checks are enabled.

To disable the ICMP security checks, use the no ipv6 icmp-guard or the no icmp-guard command in interface mode. Use this command as part of an overall strategy to operate the ACE as a pure server load balancer. For details, see Chapter 1, Overview, in the Server Load-Balancing Guide, Cisco ACE Application Control Engine.

IPv6 Syntax and Examples

The syntax of this command is as follows:

no ipv6 icmp-guard


Caution Disabling the ACE ICMPv6 security checks may expose your ACE and your data center to potential security risks. After you enter the no ipv6 icmp-guard command, the ACE no longer performs NAT translations on the ICMPv6 header and payload in error packets, which potentially can reveal real host IPv6 addresses to attackers.

When the ipv6 icmp-guard command is enabled, only the "Packet Too Big" ICMPv6 message is allowed. To allow other ICMPv6 error messages (for example, the "Time Exceeded" message or the "Parameter Problem" message), the ipv6 icmp-guard command should be disabled.

For example, to disable ICMPv6 security checks on interface VLAN 100, enter:

host1/C1(config)# interface vlan 100
host1/C1(config-if)# no ipv6 icmp-guard
 
   

To reenable ICMPv6 security checks, enter:

host1/C1(config-if)# ipv6 icmp-guard
 
   

IPv4 Syntax and Examples

The syntax of this command is as follows:

no icmp-guard


Caution Disabling the ACE ICMPv4 security checks may expose your ACE and your data center to potential security risks. After you enter the no icmp-guard command, the ACE no longer performs NAT translations on the ICMPv4 header and payload in error packets, which potentially can reveal real host IPv4 addresses to attackers.

For example, to disable ICMPv4 security checks on interface VLAN 100, enter:

host1/C1(config)# interface vlan 100
host1/C1(config-if)# no icmp-guard
 
   

To reenable ICMPv4 security checks, enter:

host1/C1(config-if)# icmp-guard

Configuring SYN-Cookie Denial-of-Service Protection

This section describes the SYN cookie feature that the ACE uses to protect itself and devices in the data center from Denial of Service (DoS) attacks. It covers the following topics:

Overview of SYN Cookie DoS Protection

Configuration and Operational Considerations

Configuring SYN Cookie DoS Protection on an Interface

Overview of SYN Cookie DoS Protection

Occasionally, a TCP three-way handshake (SYN, SYN-ACK, ACK) may not complete for some reason. These incomplete or half-open connections are known as embryonic connections. Such occurrences are normal if the frequency is low. However, a large number of embryonic connections could indicate a DoS attack (SYN flood attack) by a hacker.

A SYN flood attack is characterized by a large number of SYNs sent to a server or other host from one or more hosts with source IP addresses that are invalid and unreachable. Such an attack causes half-open connections on the target host that must time out before the host can service other connection requests. When multiple hosts in different networks are used to attack a server or other host, the attack is known as a Distributed Denial of Service (DDoS). The goal of the attacker is to overwhelm the target host, consume its resources, and cause it to deny service to legitimate connection requests.

The ACE allows you to protect it and the servers and other hosts in the data center from SYN flood attacks by configuring SYN-cookie-based DoS protection for TCP connections. You configure an embryonic connection threshold, beyond which the ACE applies SYN cookie protection.

When the configured embryonic connection threshold is reached, the ACE intercepts the next SYN packet from a client. The ACE responds to the SYN with a SYN-ACK using a sequence number that is the actual SYN cookie value. The SYN cookie consists of the following:

A 32-bit timer that increases every second. Because there are two cookie tables (current and shadow), the client has a maximum of two seconds to respond correctly to the SYN cookie-generated SYN-ACK.

An encoding of the client MSS, which the ACE forwards to the server.

An ACE-selected secret that is a randomly generated number.

Normally, if the SYN queue fills up, the ACE drops additional connection requests. If the SYN queue fills up on the ACE with SYN cookies enabled, the ACE continues to service a client request normally by sending a SYN-ACK to the requesting client as if the SYN queue was actually larger. The ACE uses the calculated SYN cookie value as the sequence number (n) and discards the SYN queue entry.

When it receives an ACK (sequence number = n+1) from the client, the ACE verifies the validity of the secret and the SYN cookie value for a recent value of the SYN cookie timer. If the secret or the sequence number is not valid, the ACE drops the packet. If the secret and the sequence number are valid, the ACE rebuilds the SYN queue entry based on the encoded MSS and the ACK from the client. At this point, the connection process proceeds normally; the ACE sends the newly built SYN to the server and establishes the back-end TCP connection.

(ACE module only) The following information is for the ACE module only.
When you configure SYN cookie protection, the ACE module calculates the internal embryonic connection threshold value for each network processor (NP) as configured_threshold ÷ 4 (fractions are not disregarded). For example, if you configure the threshold as 6, the ACE module applies the threshold to each NP in a round-robin fashion in the order shown, which results in the following threshold distribution:

NP1=2

NP2=2

NP3=1

NP4=1

Because of this internal division of the threshold value, you may occasionally observe that SYN cookie protection is applied before the embryonic connection count reaches the configured threshold value. For example, suppose that you configure a threshold value of 4. Because the threshold value is divided by four internally for each NP, the internally calculated threshold is 1. After one incomplete connection attempt (SYN) is sent to an NP, the ACE module activates SYN cookie protection and intercepts the second SYN going to that same NP.

Configuration and Operational Considerations

When you use the SYN cookie feature, be aware of the following considerations:

If the server drops the SYN that the ACE sent to it, the ACE retries the connection up to three times by default. The retry value is configurable. For more information, see the "Setting the Maximum Number of TCP SYN Retries" section.

When you enable the SYN cookie feature on an interface, and there is a configured ACL applied to that interface, once the SYN cookie threshold is reached the ACL will not block traffic on the interface until after the three-way handshake completes.

SYN cookie supports only the MSS TCP option. The ACE ignores all other TCP options, even if there are problems with those other options.

The ACE returns an MSS of 536 to the client, which is the RFC-specified default.

After the client-side three-way handshake completes, the ACE will use the minimum and maximum MSS that are specified in a parameter map when it sends a SYN to the server.

If SYN cookie is enabled, you cannot disable TCP normalization. Conversely, if TCP normalization is disabled, you cannot enable SYN cookie.

The ACE does not generate any syslogs for SYN cookie, even if the number of embryonic connections exceeds the configured threshold, which may indicate a SYN-flood attack.

If you are configuring the SYN cookie feature on a bridged VLAN with non-loadbalanced flows, you must configure static routes for non-loadbalanced destinations that do not reside in the same subnet as the bridge-group virtual interface (BVI).

IPv6 Configuration

For example, assuming the following IPv6 configuration:

BVI IPv6 address is 2001:DB8:1::1

Gateway1 IPv6 address 2001:DB8:1::/64 to reach external network 2001:DB8:2::/64

Gateway2 IPv6 address 2001:DB8:3::/64 to reach external network 2001:DB8:4::/64

Configure the following static routes:

ip route 2001:DB8:2::/64 2001:DB8:1::

ip route 2001:DB8:4::/64 2001:DB8:3::

IPv4 Configuration

For example, assuming the following IPv4 configuration:

BVI IPv4 address is 192.168.1.1

Gateway1 IPv4 address 192.168.1.2 to reach external network 172.16.1.0

Gateway2 IPv4 address 192.168.1.3 to reach external network 172.31.1.0

Configure the following static routes:

ip route 172.16.1.0 255.255.255.0 192.168.1.2

ip route 172.31.1.0 255.255.255.0 192.168.1.3

Configuring SYN Cookie DoS Protection on an Interface

To configure SYN-cookie-based DoS protection, use the syn-cookie command in interface configuration mode. The syntax of this command is as follows:

syn-cookie number

The number is the embryonic connection threshold above which the ACE applies SYN-cookie DoS protection. Enter an integer from 1 to 65535.

For example, to configure SYN-cookie DoS protection for servers in a data center connected to VLAN 100, enter:

host1/C1(config)# interface vlan 100
host1/C1(config-if)# syn-cookie 4096
 
   

To remove SYN-cookie DoS protection from the interface, enter:

host1/C1(config-if)# no syn-cookie

Configuring IPv6 Extension Header Processing

To configure how the ACE processes IPv6 extension headers, use the ipv6 extension-header command in interface configuration mode. The default option is drop. There is no provision to selectively choose which extension header to act on. The syntax of this command is as follows:

ipv6 extension header {allow | clear | clear-invalid | drop}

The options are:

allow—If a packet contains an IPv6 extension header, the ACE allows the packet with all the header options

clear—If the packet contains an IPv6 extension header, the ACE clears all the IPv6 extension header options and allows the packet

clear-invalid—If the packet contains an IPv6 extension header and one of the header options is invalid, the ACE clears all the extension header options and allows the packet

drop—(Default) If the packet contains an IPv6 extension header and one of the header options is invalid, theACE drops the packet

For example, to configure the ACE to clear IPv6 extension headers and allow the packet, enter the following commands:

host1/Admin(config)# interface vlan 200
host1/Admin(config-if)# ipv6 extension-header clear
 
   

To reset the behavior of the ACE to the default of dropping packets with invalid IPv6 extension headers, enter the following command:

host1/Admin(config-if)# no ipv6 extension-header
 
   

Configuring How the ACE Handles the Don't Fragment Bit

Occasionally, an ACE may receive a packet that has its Don't Fragment (DF) bit set in the IP header. This flag tells network routers and the ACE not to fragment the packet and to forward it in its entirety. To configure how the ACE handles the DF bit, use the ip df command in interface configuration mode. The syntax of this command is as follows:

ip df {clear | allow}

The keywords are as follows:

clear—Clears the DF bit and permits the packet. If the packet is larger than the next-hop MTU, the ACE fragments the packet.

allow—Permits the packet with the DF bit set. If the packet is larger than the next-hop MTU, the ACE discards the packet and sends an ICMP unreachable message to the source host.

For example, to clear the DF bit and permit the packet, enter:

host1/C1(config-if)# ip df clear
 
   

To instruct the ACE to ignore the DF bit, enter:

host1/C1(config-if)# no ip df

Configuring IPv4 Header Options Processing

The ACE can process IPv4 header options and perform specific actions when an IPv4 option is set in a packet. To configure how the ACE handles IP header options, use the ip options command in interface configuration mode. The syntax of this command is as follows:

ip options {allow | clear | clear-invalid | drop}

The keywords are as follows:

allow—Allows the packet with IPv4 options set

clear—Clears all IPv4 options from the packet and allows the packet

clear-invalid—(Default) Clears all IPv4 options from the packet if the ACE encounters one or more invalid or unsupported IPv4 options and allows the packet

drop—Instructs the ACE to discard the packet regardless of any IPv4 options that are set

For example, enter:

host1/C1(config-if)# ip options allow
 
   

To reset the ACE behavior to the default of clearing all IPv4 options if the ACE encounters one or more invalid or unsupported IPv4 options, enter:

host1/C1(config-if)# no ip options 

Setting the IP Packet TTL

The packet time to live (TTL) specifies the number of hops that a packet is allowed to reach its destination. Each router along the packet's path decrements the TTL by one. If the packet's TTL reaches zero before the packet reaches its destination, the packet is discarded.

To specify the minimum TTL value that the ACE accepts in the IP header of an incoming packet, use the ip ttl command in interface configuration mode. The default behavior of the ACE is to not rewrite the TTL value of a packet. The syntax of this command is as follows:

ip ttl minimum number

The number argument is the minimum number of hops that a packet is allowed to reach its destination. Enter an integer from 1 to 255 hops.


Note If the TTL value of the incoming packet is lower than the configured minimum value, the ACE rewrites the TTL with the configured value. Otherwise, the ACE transmits the packet with its TTL unchanged or discards the packet if the TTL equals zero. This command applies to both IPv4 and IPv6 flows. The configured value replaces the TTL in an IPv4 packet and the hop limit in an IPv6 packet if the original value is lower.


For example, to set the TTL to 15, enter:

host1/C1(config-if)# ip ttl minimum 15
 
   

To reset the behavior of the ACE to the default of not overwriting the TTL of an incoming IP packet, enter:

host1/C1(config-if)# no ip ttl minimum

Configuring Unicast Reverse-Path Forwarding

Unicast reverse-path forwarding (URPF) helps to mitigate problems caused by the introduction of malformed or forged (spoofed) IP source addresses into a network by allowing the ACE to discard IP packets that lack a verifiable source IP address. This feature enables the ACE to filter both ingress and egress packets to verify addressing and route integrity. It is called URPF because the route lookup is typically based on the destination address, not the source address.

When you enable this feature, the ACE discards packets if there is no route found or if the route does not match the interface on which the packet arrived.


Note If you configure the mac-sticky command on the interface, you cannot configure the ip verify reverse-path command. For details about the mac-sticky command, see the Routing and Bridging Guide, Cisco ACE Application Control Engine.


IPv6 Syntax and Examples

To enable this feature, use the ipv6 verify reverse-path command in interface configuration mode. The syntax of this command is as follows:

ipv6 verify reverse-path

For example, to enable URPF, enter:

host/C1(config-if)# ipv6 verify reverse-path
 
   

To disable URPF, enter:

host/C1(config-if)# no ipv6 verify reverse-path
 
   

IPv4 Syntax and Examples

To enable this feature, use the ip verify reverse-path command in interface configuration mode. The syntax of this command is as follows:

ip verify reverse-path

For example, to enable reverse-path forwarding, enter:

host/C1(config-if)# ip verify reverse-path
 
   

To disable reverse-path forwarding, enter:

host/C1(config-if)# no ip verify reverse-path

Configuring IP Fragment Reassembly Parameters

You can configure several parameters that control how the ACE performs IPv6 and IPv4 fragment reassembly. This section contains the following topics:

IP Fragment Reassembly Configuration Quick Start

Configuring the MTU for an Interface

Configuring the Maximum Number of Fragments in a Packet

Configuring the Minimum Fragment Size for Reassembly

Configuring an IP Reassembly Timeout

IP Fragment Reassembly Configuration Quick Start

Table 4-6 provides a quick overview of the steps required to configure IP fragment reassembly. Each step includes the CLI command or a reference to the procedure required to complete the task. For a complete description of each feature and all the options associated with the CLI commands, see the sections following Table 4-6.

Table 4-6 IP Fragment Reassembly Configuration Quick Start 

Task and Command Example

1. If you are operating in multiple contexts, observe the CLI prompt to verify that you are operating in the desired context. If necessary, change to the correct context.

host1/Admin# changeto C1
host1/C1#
 
        

The rest of the examples in this table use the C1 context, unless otherwise specified. For details on creating contexts, see the Virtualization Guide, Cisco ACE Application Control Engine.

2. Enter configuration mode.

host1/C1# config 
host1/C1(config)#

3. Enter interface configuration mode for the interface on which you want to configure fragment reassembly parameters.

host1/C1(config)# interface vlan 100
host1/C1(config-if)# 

4. Configure the maximum number of fragments belonging to the same packet that the ACE accepts for reassembly.

host1/C1(config-if)# ipv6 fragment chain 126
or
host1/C1(config-if)# fragment chain 126

5. Configure the minimum fragment size that the ACE will accept for reassembly.

host1/C1(config-if)# ipv6 fragment min-mtu 1024
or
host1/C1(config-if)# fragment min-mtu 1024

6. Configure a fragment reassembly timeout to specify the period of time after which the ACE abandons the fragment reassembly process if it does not receive any outstanding fragments for the current fragment chain (fragments that belong to the same packet).

host1/C1(config-if)# ipv6 fragment timeout 15
or
host1/C1(config-if)# fragment timeout 15

7. (Optional) Save your configuration changes to flash memory.

host1/C1# copy running-config startup-config

8. Display the IP fragment reassembly configuration information.

host1/C1# show interface vlan 100

Configuring the MTU for an Interface

The default maximum transmission unit (MTU) is 1500 bytes in a block for Ethernet interfaces. This value is sufficient for most applications, but you can pick a lower number if network conditions require it. Data that is larger than the MTU value is fragmented before being sent to the next hop router.


Caution If you configure a Layer 7 policy map and set the maximum transmit unit (MTU) of the ACE server-side VLAN lower than the client maximum segment size (MSS), ensure that the maximum value of the MSS that you set for the ACE using the set tcp mss max command is at least 40 bytes (size of the TCP header plus options) less than the MTU of the ACE server-side VLAN. Otherwise, the ACE may discard incoming packets from the server.

To specify the MTU for an interface, use the mtu command in interface configuration mode. This command allows you to set the data size that is sent on a connection. The syntax of this command is as follows:

mtu  bytes

The bytes argument is the number of bytes in the MTU. Enter a number from 68 to 9216 bytes. The default is 1500 bytes.

To specify the MTU data size of 1000 bytes for an interface, enter:

host1/admin(config-if)# mtu 1000 
 
   

To reset the MTU block size to 1500 bytes, use the no mtu command. For example, enter:

host1/admin(config-if)# no mtu

Configuring the Maximum Number of Fragments in a Packet

You can configure the maximum number of fragments belonging to the same packet that the ACE accepts for reassembly by using the ipv6 fragment chain or the fragment chain command in interface configuration mode.

IPv6 Syntax and Examples

The syntax of this command is as follows:

ipv6 fragment chain number

The number argument specifies the fragment chain limit as an integer from 1 to 256 fragments. The default is 24 fragments.

To set the IPv6 fragment chain limit as 48, enter the following command:

host1/C1(config-if)# ipv6 fragment chain 48
 
   

To reset the maximum number of fragments in a packet to the default of 24, enter the following command:

host1/C1(config-if)# no ipv6 fragment chain
 
   

IPv4 Syntax and Examples

The syntax of this command is as follows:

fragment chain number

The number argument specifies the fragment chain limit as an integer from 1 to 256 fragments. The default is 24 fragments.

For example, enter:

host1/C1(config-if)# fragment chain 126
 
   

To reset the maximum number of fragments in a packet to the default of 24, enter:

host1/C1(config-if)# no fragment chain
 
   

Configuring the Minimum Fragment Size for Reassembly

You can configure the minimum fragment size that the ACE accepts for reassembly by using the ipv6 fragment min-mtu or the fragment min-mtu command in interface configuration mode.

IPv6 Syntax and Examples

The syntax of this command is as follows:

ipv6 fragment min-mtu number

The number argument specifies the minimum fragment size as an integer from 56 to 1280 bytes. The default is 1280 bytes.

For example, enter:

host1/C1(config-if)# ipv6 fragment min-mtu 1024
 
   

To reset the minimum fragment size to the default value of 1280 bytes, enter:

host1/C1(config-if)# no ipv6 fragment min-mtu
 
   

IPv4 Syntax and Examples

The syntax of this command is as follows:

fragment min-mtu number

The number argument is the minimum fragment size as an integer from 28 to 9216 bytes. The default is 576 bytes.

For example, enter:

host1/C1(config-if)# fragment min-mtu 1024
 
   

To reset the minimum fragment size to the default value of 576 bytes, enter:

host1/C1(config-if)# no fragment min-mtu
 
   

Configuring an IP Reassembly Timeout

The IP reassembly timeout specifies the period of time after which the ACE abandons the fragment reassembly process if it does not receive any outstanding fragments for the current fragment chain (fragments that belong to the same packet). To configure a reassembly timeout, use the fragment timeout command in interface configuration mode.

IPv6 Syntax and Examples

The syntax of this command is as follows:

ipv6 fragment timeout seconds

The seconds argument is an integer from to 1 to 60 seconds. The default is 60 seconds.

For example, enter:

host1/C1(config-if)# ipv6 fragment timeout 30
 
   

To reset the fragment timeout to the default value of 60 seconds, enter:

host1/C1(config-if)# no ipv6 fragment timeout
 
   

IPv4 Syntax and Examples

The syntax of this command is as follows:

fragment timeout seconds

The seconds argument is an integer from to 1 to 30 seconds. The default is 5 seconds.

For example, enter:

host1/C1(config-if)# fragment timeout 15
 
   

To reset the fragment timeout to the default value of 5 seconds, enter:

host1/C1(config-if)# no fragment timeout
 
   

Configuring the Switch Mode Feature

Use the switch mode feature to change the way that the ACE handles:

Connections that are not destined to a particular class map.

Connections that do not have any policies (a policy map and service policy) associated with their traffic.

Connections that do not have load-balance (VIP), inspection, NAT, or management traffic actions associated with a traffic policy.

When you enable the switch mode feature, the ACE processes these connections as stateless connections. Stateless TCP connections do not undergo any TCP normalization checks (for example, TCP window, TCP state, TCP sequence number, and other normalization checks). All stateless connections (such as, TCP, UDP, ICMP) have a default inactivity timeout of 2 hours and 15 minutes.


Note The switch mode default timeout of 2 hours and 15 minutes applies only to non-VIP, non-inspection, non-NATed, and non-management traffic. The ACE continues to apply local, global, and VIP-specific connection parameter maps to load-balanced (VIP), inspected, NATed, and management traffic.


The ACE also creates stateless TCP connections for non-SYN TCP packets if they satisfy all other configured requirements (for example, ACLs and other policies). This process ensures that a long-lived persistent connection passes through the ACE successfully, even if the connection times out, by being reestablished by any incoming packet related to the connection. When a stateless TCP connection times out, the ACE does not send a RST packet but instead closes the connection silently. Even though these connections are stateless, the TCP RST and FIN-ACK flags are honored and the connections are closed when the ACE sees these flags in the received packets.

To change the default timeout for stateless connections associated with a traffic policy, configure a connection parameter map and include the set timeout inactivity command to set the connection inactivity timeout (see the "Configuring the Connection Inactivity Timeout" section), then configure a traffic policy for TCP/IP normalization and termination (see the "Configuring a Traffic Policy for TCP/IP Normalization and Termination" section).


Note To configure the default timeout stateless for connections that are not associated with a traffic policy, use the timeout option of the switch-mode command.


The SYN cookie feature still operates normally for stateless TCP connections that are not destined to any traffic policy.

To enable the switch mode feature, use the switch-mode command in configuration mode. The syntax of this command is as follows:

switch-mode [timeout seconds]

Use the optional timeout keyword to configure the inactivity timeout for connections in switch mode. The seconds argument is the time period in seconds for idle connections after which the ACE disconnects the connection. Enter an integer from 1 to 65535. By default, the timeout is 8100 seconds.

Because UDP connections do not have a close protocol, this timeout defines their minimum lifetime. This option was introduced to minimize the number of old connections, particularly UDP connections.

For example, to enable the switch mode feature, enter the following command:

host1/Admin(config)# switch-mode
 
   

To enable the switch mode feature with a timeout of 300 seconds (5 minutes), enter the following command:

host1/Admin(config)# switch-mode timeout 300
 
   

To reset the switch-mode timeout to the default value of 8100 seconds after you have enabled switch mode and configured a timeout, enter the following command:

host1/Admin(config)# switch-mode
 
   

To disable the switch mode feature, enter the following command:

host1/Admin(config)# no switch-mode
 
   

Example of a TCP/IP Normalization and IP Reassembly Configuration

The following example illustrates a running-configuration in which the ACE uses TCP normalization to perform checks for Layer 4 packets that have invalid or suspect conditions and to take the appropriate actions based on the configured TCP connection parameter map settings. The ACE uses TCP normalization to block certain types of network attacks. This configuration also includes IP fragment reassembly parameters. The TCP/IP normalization and IP fragment reassembly configuration appears in bold in the example.

In the following configuration, the ACE does the following:

Includes a connection parameter map that groups together TCP/IP normalization and termination parameters, such as a connection inactivity timer, ToS for an IP packet, and discarding the SYN segments that contain data. The connection parameter map is associated as an action in the TCP/IP policy map.

Configures additional IP normalization parameters for a specific VLAN interface, such as clearing all IP options from the packet, define the number of hops that a packet is allowed to reach its destination, and permit the packet with the DF bit set.

Configures IP fragment reassembly parameters for a specific VLAN interface, such as the minimum fragment size that the ACE accepts for reassembly, the maximum number of fragments that belong to the same packet that the ACE accepts for reassembly, and the minimum fragment size that the ACE accepts for reassembly.

access-list ACL1 line 10 extended permit ip any any
 
   
parameter-map type connection TCPIP_PARAM_MAP
  set timeout inactivity 30
  set ip tos 20
  tcp-options timestamp allow
  syn-data drop
  urgent-flag clear
 
   
class-map match-all L4_TCP_CLASS
  description Filter TCP Connections
  2 match destination-address 172.27.16.7
  3 match port tcp eq 21
policy-map multi-match L4_TCPIP_POLICY
  class L4_TCP_CLASS
    connection advanced-options TCP_PARAM_MAP
 
   
interface vlan 50
  access-group input ACL1
  ip address 192.168.1.100 255.255.255.0
  service-policy input L4_TCPIP_POLICY
  ip ttl minimum 15
  ip options clear
  ip df allow
  fragment size 400
  fragment chain 126
  fragment min-mtu 1024
  fragment timeout 15
  no shutdown

Displaying Configurations and Statistics for TCP/IP and UDP Connections, IP Reassembly, and SYN Cookie

This section describes the show commands that you can use to display configurations and statistics for the following:

TCP connections parameters

IP connections parameters

UDP connection parameters

IP fragment reassembly

This section contains the following topics:

Displaying TCP/IP and UDP Connection Configurations

Displaying a Connection Parameter Map

Displaying TCP/IP and UDP Connection Statistics

Displaying Global Context Connection Statistics

Displaying IP Statistics

Displaying TCP Statistics

Displaying UDP Statistics

Displaying Service Policy Statistics

Displaying SYN Cookie Statistics

Displaying TCP/IP and UDP Connection Configurations

You can display TCP, IP, and UDP connection configurations by using the following show commands in Exec mode:

show running-config class-map—Displays all traffic classifications configured in the current context, including match statements for IP addresses and TCP or UDP ports

show running-config policy-map—Displays all policy maps configured in the current context, including the associated class maps

show running-config interface—Displays all interface VLAN configurations in the current context

For example, to display all policy maps in the current context, enter:

host1/C1# show running-config policy-map

Displaying a Connection Parameter Map

You can display a connection parameter map configuration by using the show parameter-map command in Exec mode. The syntax of this command is as follows:

show parameter-map name

The name argument is the name of an existing connection parameter map. Enter the name as an unquoted text string with no spaces and a maximum of 64 alphanumeric characters.

For example, to display a connection parameter map configuration, enter:

host1/C1# show parameter-map CONN_PMAP
 
   

Table 4-7 describes the fields in the show parameter-map command output.

Table 4-7 Field Descriptions for the show parameter-map Command Output 

Field
Description

Parameter map

Name of the connection parameter map.

Type

Connection.

Nagle

Status of the nagle command: enabled or disabled.

Slow start

Status of the slow start command: enabled or disabled.

Inactivity timeout (seconds)

Configured number of seconds after which an inactive connection times out. Possible values are from 0 to 3217203. If the set timeout inactivity command is not configured, the default values in seconds appear, as follows:

HTTP/SSL—300

ICMP—2

TCP—3600

UDP—10

Embryonic timeout (seconds)

Configured number of seconds after which an incomplete TCP handshake times out. Possible values are from 0 to 4294967295.

Ack-delay

Configured number of seconds that the ACE delays sending an ACK from a client to a server.

WAN optimization RTT (milliseconds)

Configured number of milliseconds that determines how the ACE applies TCP optimizations to packets on a connection that is associated with a Layer 7 policy.

Half-closed timeout (seconds)

Number of seconds after which a half-closed connection times out. Possible values are from 0 to 4294967295.

TOS rewrite

State of the set ip tos command: enabled or disabled.

SYN retry count

State of the set tcp syn-retry command: enabled or disabled.

TCP MSS min

Minimum value of the TCP maximum segment size that the ACE accepts. Possible values are from 0 to 65535.

TCP MSS max

Maximum value of the TCP maximum segment size that the ACE accepts. Possible values are from 0 to 65535.

Tcp-options drop range

Range of numbers representing the TCP options that the ACE drops.

Tcp-options allow range

Range of numbers representing the TCP options that the ACE allows. Possible values are 6 or 7 and from 9 to 255.

Tcp-options clear range

Range of numbers representing the TCP options that the ACE clears. Possible values are 6 or 7 and from 9 to 255.

Selective-ack

Configured action that the ACE performs for the selective acknowledgement TCP option. Possible actions are allow or clear.

Timestamp

Configured action that the ACE performs for the time-stamp TCP option. Possible actions are allow or clear.

Window-scale

Configured action that the ACE performs for the window scale TCP option. Possible actions are allow, clear, or drop.

Window-scale
factor

Value of the set tcp window-scale command. Possible values are from 0 to 14.

Reserved-bits

Configured action for the reserved-bits command. Possible actions are allow, clear, or drop.

Random-seq-
num

Configured state of the random-sequence-number command. Possible states are enabled or disabled.

SYN data

Configured action for the syn-data command. Possible actions are allow or drop.

Exceed-mss

Configured action for the exceed-mss command. Possible actions are allow or drop.

urgent-flag

Configured action for the urgent-flag command. Possible values are allow or clear.

conn-rate-limit

Configured maximum number of connections per second that the ACE allows.

bandwidth-rate-
limit

Configured maximum number of bytes per second that the ACE allows.

reassembly timeout (seconds)

Timeout configured by entering the set tcp reassembly-timeout command.


Displaying TCP/IP and UDP Connection Statistics

This section describes the show commands that you can use to display TCP/IP and UDP connection statistics. To display connection statistics, use the show conn command in Exec mode. The syntax of this command is as follows:

show conn {address ip_address1 [ip_address2 [/prefix_length | netmask mask]] [detail]} | count | detail | {port number1 [number2] [detail]} | {protocol {tcp | udp} [detail]}

The keywords, arguments, and options are as follows:

address ip_address1 [ip_address2]—Displays connection statistics for a single source or destination IPV6 or IPv4 address or, optionally, for a range of source or destination IP addresses. To specify a range of IP addresses, enter an IP address for the lower limit of the range and a second IP address for the upper limit of the range.

/prefix_length—Displays connection statistics for the IPv6 address or range of IPv6 addresses that you specify. Enter an IPv6 prefix (for example, /64).

netmask mask—Displays connection statistics for the IPv4 address or range of IPv4 addresses that you specify. Enter a network mask in dotted-decimal notation (for example, 255.255.255.0).

count—Displays the total current connections to the ACE.

detail—Displays detailed connection information.

port number1 [number2]—Displays connection statistics for a single source or destination port or, optionally, for a range of source or destination ports.

protocol {tcp | udp}—Displays connection statistics for TCP or UDP.

IPv6 Example

To display connection statistics for a range of IP addresses, enter:

host1/C1# show conn address 2001:DB8:1::15 2001:DB8:1::35/64
 
   

IPv4 Example

To display connection statistics for a range of IP addresses, enter:

host1/C1# show conn address 192.168.12.15 192.168.12.35 netmask 
255.255.255.0
 
   

Table 4-8 describes the fields in the show conn detail command output.

Table 4-8 Field Descriptions for the show conn detail Command Output 

Field
Description

Total Current Connections

Total number of current connections to the ACE.

Note The total current connections is the number of connection objects. There are two connection objects for each flow and complete connection.

Conn-ID

Identifier of the inbound or outbound connection.

NP

Number of the network processor (NP) responsible for the connection.

Dir

Direction of the connection: in(bound) or out(bound).

Prot

Protocol used for the connection: TCP or UDP.

VLAN

Identifier of the interface used for the connection.

Source

Source IP address and port.

Destination

Destination IP address and port.

State

For TCP connections, the current state of the connection (for example, ESTAB).

Idle Time

Length of time that this connection has been idle.

Byte Count

Number of bytes that have traversed the connection.

Elapsed Time

Length of time that has elapsed since the connection was established.

Packet Count

Number of packets that have traversed the connection.

Conn in Reuse Pool

Indication of whether the ACE has placed the connection in the pool for possible reuse. Valid values are TRUE or FALSE.

Total Active Connections

Total number of active connections to the ACE. The active connection count is a snapshot of the active connections to the ACE at that point in time. This value does not guarantee the exact information about the connections at this moment.


Displaying Global Context Connection Statistics

You can display global connection statistics for the current context by using the show stats connection command in Exec mode. The syntax of this command is as follows:

show stats connection

For example, to display global connection statistics for the Admin context, enter the following command:

host1/Admin# show stats connection
 
   

Table 4-9 describes the fields in the show stats connection command output.

Table 4-9 Field Descriptions for the show stats connection Command Output 

Field
Description

Total Connections Created

Total number of connections that were created in the current context. This number is the sum of the Total Connections Current, Total Connections Destroyed, Total Connections Timed-out, and Total Connections Failed.

Total Connections Current

Total number of existing connections to the current context.

Total Connections Destroyed

Total number of connections that were torn down in the current context.

Total Connections Timed-out

Total number of connections that exceeded the configured timeout in the current context.

Total Connections Failed

Total number of connection attempts that failed to complete.


Displaying IP Statistics

This section describes the show commands that you can use to display IP statistics, including fragmentation, ICMP, TCP, and UDP, and ARP statistics. It contains the following topics:

Displaying IP Traffic Information

Displaying IP Fragmentation and Reassembly Statistics

Displaying IP Traffic Information

You can display IPv4 and IPv6 traffic information by using the show ip traffic command in Exec mode. Aside from fragmentation, reassembly and ARP statistics, this command displays statistics for traffic destined to the ACE, rather than through the ACE. The syntax of this command is as follows:

show ip traffic

For example, enter:

host1/C1# show ip traffic
 
   

Table 4-10 describes the fields in the show ip traffic command output.

Table 4-10 Field Descriptions for the show ip traffic Command
Output 

Field
Description

IP Statistics

Rcvd

Total number of packets received by the ACE, number of bytes received by the ACE, number of input errors, number of packets received by the ACE with no route, and the number of packets received by the ACE that had an unknown protocol.

Frags

Number of fragments that the ACE reassembled, number of fragments that the ACE could not reassemble, number of packets that the ACE fragmented, and the number of packets that the ACE could not fragment.

Bcast

Number of broadcast packets received and sent.

Mcast

Number of multicast packets received and sent.

Sent

Total packets sent, number of bytes sent, and the number of packets sent with no route.

Drop

Number of packets discarded because they had no route, and number of packets discarded.

IPv6 Statistics

Rcvd

Total number of packets received by the ACE, number of bytes received by the ACE, number of input errors, and number of packets received by the ACE with no route.

Frags

Number of fragments that the ACE reassembled, number of fragments that the ACE could not reassemble, number of packets that the ACE fragmented, and the number of packets that the ACE could not fragment.

Mcast

Number of multicast packets received and sent.

Sent

Total packets sent, number of bytes sent, and the number of packets sent with no route.

Drop

Number of packets discarded because they had no route, and number of packets discarded.

ICMP Statistics

Rcvd

Reports statistics for the following ICMP messages received by the ACE:

Redirects

ICMP Unreachable

ICMP Echo

ICMP Echo Reply

Mask Requests

Mask Replies

Quench

Parameter

Timestamp

Sent

Reports statistics for the following ICMP messages sent by the ACE:

Redirects

ICMP Unreachable

ICMP Echo

ICMP Echo Reply

Mask Requests

Mask Replies

Quench

Timestamp

Parameter

Time Exceeded

ICMPv6 Statistics

Rcvd

input—Number of packets received by the ACE.

errors—Number of received packet errors.

unreach—Number of ICMPv6 Unreachable messages received by the ACE.

parameter problem—Number of packets that were dropped by the ACE because of a problem with the IPv6 header or extension header fields.

hopcount expired—Number of packets whose hop counts went to zero that were received by the ACE. This message is the same as the Time Exceeded message in RFC4443.

too big—Number of packets received by the ACE that elicited a "packet too big" response because they were too long and could not be sent to their destination.

echo request—Number of ICMPv6 Echo Request packets received by the ACE.

echo reply—Number of ICMPv6 Echo Reply packets received by the ACE.

group query—Number of multicast group query messages received by the ACE.

group report—Number of group report messages received by the ACE. Group report messages are generated when a host joins a multicast group.

group reduce—Number of group reduce messages received by the ACE. Group reduce messages are sent by a member when it leaves a multicast group.

router solicit—Number of Router Solicitation messages received by the ACE.

ICMPv6 Statistics (cont.)

Rcvd (cont.)

router solicit drops—Number of Router Solicitation messages that were dropped by the ACE.

router advert—Number of Router Advertisement messages received by the ACE.

redirects—Number of Redirect messages received by the ACE.

neighbor solicit—Number of Neighbor Solicitation messages received by the ACE.

neighbor advert—Number of Neighbor Advertisements received by the ACE.

Sent

output—Number of packets sent by the ACE

unreach—Number of Destination Unreachable messages sent by the ACE

parameter problem—Number of packets sent by the ACE that had a problem with the IPv6 header or extension header fields

hopcount expired—Number of packets whose hop counts went to zero that were sent by the ACE

too big—Number of packets sent by the ACE that elicited a "packet too big" response because they were too long and could not be sent to the destination

echo reply—Number of Echo Reply messages sent by the ACE

group report—Number of group report messages sent by the ACE. Group report messages are generated when a member joins a multicast group.

group reduce—Number of group reduce messages sent by the ACE. Group reduce messages are sent by a member when it leaves a multicast group.

Sent (cont.)

router solicit—Number of Router Solicitation messages sent by the ACE.

router advert—Number of Router Advertisement messages sent by the ACE.

redirects—Number of Redirect messages sent by the ACE.

neighbor solicit—Number of Neighbor Solicitation messages sent by the ACE.

neighbor advert—Number of Neighbor Advertisements sent by the ACE.

TCP Statistics

Rcvd

Total number of TCP segments and errors received by the ACE.

Sent

Total number of TCP segments sent by the ACE.

UDP Statistics

Rcvd

Total number of UDP segments, UDP errors, and segments with no port number received by the ACE.

Sent

Total number of UDP segments sent by the ACE.

ARP Statistics

Rcvd

Number of ARP packets, errors, requests, and responses received by the ACE.

Sent

Number of ARP packets, errors, requests, and responses sent by the ACE.


Displaying IP Fragmentation and Reassembly Statistics

You can display IPv6 and IPv4 fragmentation and reassembly statistics for all interfaces in the ACE or the specified interface by using the show fragment command in Exec mode. The syntax of this command is as follows:

show fragment [vlan vlan_id]

For the optional vlan_id argument, enter the unique identifier of an existing interface as an integer from 2 to 4094. If you omit the vlan keyword and vlan_id argument, you can display statistics for all interfaces in the ACE.

For example, to display IPv6 and IPv4 fragmentation and reassembly statistics for all interfaces in the ACE, enter:

host1/C1# show fragment
 
   

Table 4-11 describes the fields in the show fragment command output.

Table 4-11 Field Descriptions for the show fragment Command Output

Field
Description

Interface

VLAN ID of the interface.

Fragment Stats

Required

Number of IPv4 packets that were sent to the ACE for fragmentation.

OK

Number of IPv4 fragments that the ACE successfully created.

Failed

Number of IPv4 fragmentation attempts that were unsuccessful.

Created

Total number of IPv4 fragments that the ACE created.

IP Reassembly Stats

Required

Number of IPv4 packets that were sent to the ACE for reassembly.

OK

Number of IPv4 packets that the ACE successfully reassembled.

Failed

Number of IPv4 packet reassembly attempts that were unsuccessful.

IPv6 Fragment Stats

Required

Number of IPv6 packets that were sent to the ACE for fragmentation.

OK

Number of IPv6 fragments that the ACE successfully created.

Failed

Number of IPv6 fragmentation attempts that were unsuccessful.

Created

Total number of IPv6 fragments that the ACE created.

IPv6 Reassembly

Required

Number of IPv6 packets that were sent to the ACE for reassembly.

OK

Number of IPv6 packets that the ACE successfully reassembled.

Failed

Number of IPv6 packet reassembly attempts that were unsuccessful.


A TCP reassembly timeout can cause a TCP connection to be unexpectedly reset. To display the Reassembly timeouts counter, enter the following command:

host1/Admin# show np 1 me-stats "-s tcp" | inc Reassembly

Displaying TCP Statistics

You can display TCP statistics by using the show tcp statistics command in Exec mode. This command display statistics for traffic destined to the ACE, rather than through the ACE. The syntax of this command is as follows:

show tcp statistics

For example, to display TCP statistics for the current context, enter:

host1/C1# show tcp statistics
 
   

Table 4-12 describes the fields in the show tcp statistics command output.

Table 4-12 Field Descriptions for the show tcp statistics Command Output 

Field
Description

Rcvd

Total number of TCP segments and errors received by the ACE.

Sent

Total number of TCP segments, reset flag segments, active opens, and passive opens sent by the ACE.

Connections

Number of failed connection attempts, established connections that were reset, and currently established connections.


Displaying UDP Statistics

You can display UDP statistics by using the show udp statistics command in Exec mode. This command displays statistics for traffic destined to the ACE, rather than through the ACE. The syntax of this command is as follows:

show udp statistics

For example, to display UDP statistics for the current context, enter:

host1/C1# show udp statistics
 
   

Table 4-13 describes the fields in the show udp statistics command output.

Table 4-13 Field Descriptions for the show udp statistics Command Output 

Field
Description

Rcvd

Total number of UDP segments, errors, and segments with no port specified that the ACE received.

Sent

Total number of UDP segments sent by the ACE.


Displaying Service Policy Statistics

You can display service-policy statistics by using the show service-policy command in Exec mode. The syntax of this command is as follows:

show service-policy name

The name argument is a unique identifier for an existing service policy, specified as an unquoted text string with a maximum of 64 alphanumeric characters.

For example, to display service-policy statistics for the current context, enter:

host1/C1# show service-policy POLICY1
 
   

Table 4-14 describes the fields in the show service-policy command output.

Table 4-14 Field Descriptions for the show service-policy Command Output 

Field
Description

Interface

VLAN identifier of the interface associated with the service policy.

Service-Policy

Identifier of the service policy.

Class

Identifier of the class map associated with the service policy.

NAT

Configuration

For example: nat dynamic 1 vlan 102

Curr Conns

Number of active connections.

Hit Count

Number of connections that matched a policy in the ACE.

Dropped Conns

Number of connections that the ACE discarded.

Client Pkt Count

Number of packets received from clients.

Client Byte Count

Number of bytes received from clients.

Server Pkt Count

Number of packets received from servers.

Server Byte Count

Number of bytes received from servers.

Conn Rate Limit

Configured connection rate limit.

Bandwidth Rate Limit

Configured bandwidth rate limit.

Drop Count

Number of times that a connection was dropped because the connection rate limit or the bandwidth rate limit was reached.

Loadbalance

L7 Loadbalance Policy

Identifier of the Layer 7 load-balancing policy map associated with the service policy.

Regex dnld status

Status of the current regular expression (regex) download.

VIP Route Metric

(ACE module only) Configured distance metric for the route that needs to be entered in the routing table.

VIP Route Advertise

(ACE module only) State of route health injection (RHI) using the loadbalance vip advertise command. Possible values are ENABLED or DISABLED.

VIP ICMP Reply

State of the VIP's ability to reply to ICMP requests. Possible values are ENABLED or DISABLED.

VIP State

Current status of the virtual IP address. Possible values are INSERVICE or OUTOFSERVICE.

VIP DWS state

State of the VIP associated with the dynamic workload scaling (DWS) feature.

VIP DAD state

Duplicate address detection (DAD) state of the IPv6 VIP. Possible values are:

DUPLICATE—IPv6 address is already owned by another device. The address is inactive.

INACTIVE—Address is not installed.

N/A—Address is installed and DAD was not done. DAD is not done for multiple-address VIPs (those with prefix lengths less than 128) or for out-of-subnet VIPs. In this case, the VIP immediately transitions to active. The interface addresses do not use this state.

PASSED—Address successfully passed DAD and is active. This state can occur only for in-subnet /128 VIPs.

TENTATIVE—address is installed and presently undergoing DAD. DAD is done only for single-address VIPS in the same subnet, and for interface addresses. The address is inactive when in this state.

Persistence Rebalance

State of the persistence rebalance feature: ENABLED or DISABLED.

Curr Conns

Number of active connections.

Hit Count

Number of connections that matched a policy in the ACE.

Dropped Conns

Number of connections that the ACE discarded.

Client Pkt Count

Number of packets received from clients.

Client Byte Count

Number of bytes received from clients.

Server Pkt Count

Number of packets received from servers.

Server Byte Count

Number of bytes received from servers.

Conn Rate Limit

Configured connection rate limit.

Bandwidth Rate Limit

Configured bandwidth rate limit.

Drop Count

Number of times that a connection was dropped because the connection rate limit or the bandwidth rate limit was reached.

Compression

bytes_in

Number of bytes of data in the server response that was eligible for compression by the ACE.

bytes_out

Number of compressed bytes of data sent to the client by the ACE.

Compression ratio

Between the byte count of the traffic that was sent to the ACE for compression and that traffic's byte count after the ACE performed the compression. This value indicates how well the ACE applied the compression algorithm.

Bandwidth gain ratio

Ratio of bytes_in/bytes_out expressed as a percentage. This value indicates how compression influences the overall bandwidth because it also takes into consideration the traffic that is not being compressed.

Gzip

Number of gzip requests from the client.

Deflate

Number of deflate requests from the client.

Compression Errors

User-Agent

Number of times that compression did not occur because of a user-agent match.

Accept-Encoding

Number of times that compression did not occur because of an Accept-Encoding error.

Content size

Number of times that compression did not occur because of a response size error. This error occurs when the content size of a packet is less than what the ACE can compress. The minimum and default content size is 512 bytes.

Content type

Number of times that compression did not occur because of a response content error. This error occurs when the packet contains a content type that the ACE does not compress.

Not HTTP 1.1

Number of times that compression did not occur because the HTTP version is not 1.1.

HTTP response error

Number of times that compression did not occur because of a server response error. This error occurs when the server response is not 200 OK.

Others

Reserved for future use.

Parameter maps

Names of parameter maps associated with the service policy.


.

Displaying SYN Cookie Statistics

To display SYN cookie statistics, use the show syn-cookie command in Exec mode. To display SYN cookie statistics for all VLANs that are configured in the current context, enter the command with no arguments. The syntax of this command is as follows:

show syn-cookie [vlan number]

The optional vlan number keyword and argument instruct the ACE to display SYN cookie statistics for the specified interface. Enter an integer from 2 to 2024.

For example, to display SYN cookie statistics for VLAN 100, enter:

host1/C1# show syn-cookie vlan 100
 
   

Table 4-15 describes the fields in the show syn-cookie command output.

Table 4-15 Field Descriptions for the show syn-cookie Command Output 

Field
Description

Interface

Name of the VLAN interface configured on the ACE.

Configured TCP Embryonic Connection Limit

Configured embryonic connection threshold above which the ACE applies SYN-cookie DoS protection.

Current TCP Embryonic Connection Limit

Number of embryonic connections that the ACE is currently tracking.

Number of TCP SYNs Intercepted by SYN COOKIE

Number of client SYN packets that the ACE intercepted because the SYN-cookie embryonic connection threshold was exceeded.

Number of TCP ACKs Successfully Processed by SYN COOKIE

Number of client ACK packets that the ACE saw and that matched a given SYN cookie. Each client ACK that matches a cookie creates a valid embryonic connection on the ACE.

Failed Number of TCP ACKs Processed by SYN COOKIE

Number of client ACK packets that did not match a SYN cookie.


.

Clearing TCP/IP and UDP Connections and Statistics

The following sections describe the commands that you can use to clear connections and statistics related to TCP/IP and UDP connections, IP reassembly, and SYN Cookie.

Clearing Connections

Clearing Connection Statistics

Clearing IP, TCP, and UDP Statistics

Clearing IP Fragmentation and Reassembly Statistics

Clearing SYN Cookie Statistics

Clearing Connections

You can clear ICMP, TCP, and UDP connections by using the clear conn command in Exec mode. The syntax of this command is as follows:

clear conn [all | flow {icmp | tcp | udp} | id number np number | rserver name [port_number] serverfarm name | state clsrst]

The keywords are as follows:

all—(Optional) Clears all connections to and through the ACE in the current context.

flow {icmp | tcp | udp}—(Optional) Clears all connections of the specified flow type: ICMP, TCP, or UDP.

id number—(Optional) Clears the connection with the specified connection ID number as displayed in the show conn command output.

np number—Clears all the connections to the specified network processor with the specified connection ID.

rserver name—(Optional) Clears all connections for the specified real server.

port_number—(Optional) Port number associated with the specified real server. Enter an integer from 1 to 65535.

serverfarm name—(Optional) Clears all connections to the specified real server associated with this server farm.

state clsrst—Clears all connections that are in the CLOSE_RESET state. Sometimes, these connections may appear to be stuck and do not close after a day or more. This command clears those connections.

For example, to clear all TCP connections in the current context, enter:

host1/C1# clear conn flow tcp

Clearing Connection Statistics

You can clear all connection statistics in the current context by using the clear stats conn command in Exec mode. The syntax of this command is as follows:

clear stats conn

For example, to clear all connection statistics in the Admin context, enter:

host1/Admin# clear stats conn

Clearing IP, TCP, and UDP Statistics

Use the commands in this section to clear IP, TCP, and UDP statistics. This section contains the following topics:

Clearing IP Statistics

Clearing TCP Statistics

Clearing UDP Statistics

Clearing IP Statistics

You can clear IP statistics by using the clear ip statistics command in Exec mode. This command clears all statistics associated with IP normalization, fragmentation, and reassembly in the current context. The syntax of this command is as follows:

clear ip statistics

For example, to clear IP statistics in the current context, enter:

host1/C1# clear ip statistics

Note If you configured redundancy, then you need to explicitly clear IP statistics on both the active and the standby ACEs. Clearing statistics on the active ACE alone will leave the standby ACE's statistics at the old values.


Clearing TCP Statistics

You can clear TCP statistics by using the clear tcp statistics command in Exec mode. This command clears all statistics associated with TCP connections and normalization in the current context. The syntax of this command is as follows:

clear tcp statistics

For example, to clear TCP statistics in the current context, enter:

host1/C1# clear tcp statistics
 
   

Note If you configured redundancy, then you need to explicitly clear TCP statistics on both the active and the standby ACEs. Clearing statistics on the active ACE alone will leave the standby ACE's statistics at the old values.


Clearing UDP Statistics

You can clear UDP statistics by using the clear udp statistics command in Exec mode. This command clears all statistics associated with UDP connections in the current context. The syntax of this command is as follows:

clear udp statistics

For example, to clear UDP statistics in the current context, enter:

host1/C1# clear udp statistics
 
   

Note If you configured redundancy, then you need to explicitly clear UDP statistics on both the active and the standby ACEs. Clearing statistics on the active ACE alone will leave the standby ACE's statistics at the old values.


Clearing IP Fragmentation and Reassembly Statistics

You can clear IP fragmentation and reassembly statistics by using the clear interface command in Exec mode. The syntax of this command is as follows:

clear interface [bvi bvi_id | vlan vlan_id | gigabitEthernet slot_number]

The keywords and arguments are as follows:

bvi bvi_id—(Optional) Clears the statistics for the specified Bridge Group Virtual Interface (BVI).

vlan vlan_id—(Optional) Clears the statistics for the specified VLAN.

gigabitEthernet slot_number—(Optional, ACE appliance only) Clears the statistics for the specified Gigabit Ethernet slot and port.

The slot_number represents the physical slot on the ACE containing the Ethernet ports. This selection is always 1.

The port_number represents the physical Ethernet port on the ACE. Valid selections are 1 through 4.

This keyword is available in the Admin context only.

If you omit the interface keywords and arguments, you can clear fragmentation and reassembly statistics for all interfaces in the context.

For example, to clear IP fragmentation and reassembly statistics for all interfaces in the C1 context, enter:

host1/C1# clear interface
 
   

Note If you configured redundancy, then you need to explicitly clear IP fragmentation and reassembly statistics on both the active and the standby ACEs. Clearing statistics on the active ACE alone will leave the standby ACE's statistics at the old values.


Clearing SYN Cookie Statistics

To clear the SYN cookie statistics, use the clear syn-cookie command. To clear SYN cookie statistics for all VLANs that are configured in the current context, enter the command with no arguments. The syntax of this command is as follows:

clear syn-cookie [vlan number]

The optional number argument instructs the ACE to clear SYN cookie statistics for the specified interface. Enter an integer from 2 to 2024.

For example, to clear SYN cookie statistics for VLAN 100, enter:

host1/C1# clear syn-cookie vlan 100