Feedback
Table Of Contents
Configuring TCP/IP Normalization and IP Reassembly Parameters
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
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 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 the Window Scale Factor
Enabling the TCP Slow Start Algorithm
Configuring How the ACE Handles TCP SYN Segments That Contain Data
Configuring How the ACE Handles TCP Options
Setting the Urgent Pointer Policy
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 the TCP 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
Disabling the ICMP Security Checks on an Interface
Configuring How the ACE Handles the Don't Fragment Bit
Configuring How the ACE Handles IP Options
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
Example of a TCP/IP Normalization and IP Reassembly Configuration
Displaying Configurations and Statistics for TCP/IP and UDP Connections and IP Reassembly
Displaying TCP/IP and UDP Connection Configurations
Displaying a Connection Parameter Map
Displaying TCP/IP and UDP Connection Statistics
Displaying IP Traffic Information
Displaying IP Fragmentation and Reassembly Statistics
Displaying Service Policy Statistics
Clearing IP, TCP, and UDP Statistics
Clearing IP Fragmentation and Reassembly Statistics
Clearing Connection Statistics
Configuring TCP/IP Normalization and IP Reassembly Parameters
This chapter describes how to configure TCP/IP normalization and termination parameters to protect your Cisco 4700 Series Application Control Engine (ACE) appliance and the data center from attacks. It also describes IP fragmentation and reassembly parameters. The chapter contains the following major sections:
•
TCP/IP Normalization and Termination Configuration Quick Start
•
•
•
•
•
•
•
•
•
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:
•
•
•
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 Cisco 4700 Series Application Control Engine Appliance Administration Guide.
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:
•
•
•
•
•
If a packet fails one of these checks, the ACE takes action (including discarding a packet) depending on the IP parameters that you configure.
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.
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 pertain 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
You can create a connection parameter map for TCP/IP, UDP, and ICMP by using the parameter-map type connection command in global configuration mode. The syntax of this command is as follows:
parameter-map type connection map_name
For the map_name argument, enter a unique name as an unquoted text string 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_MAPhost1/C1(config-parammap-conn)#To remove the connection parameter map from the configuration, enter:
host1/C1(config)# no parameter-map type connection TCPIP_PARAM_MAPUse 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:
•
•
Make sure that you assign the current context to the resource class. For details about resource classes, see the Cisco 4700 Series Application Control Engine Appliance Virtualization Configuration Guide.
Setting the Maximum Receive or Transmit Buffer Share
You can set the maximum receive or transmit buffer size for each TCP connection by using the set tcp buffer-share command in parameter map connection configuration mode. To improve throughput and overall performance, the ACE buffers the number of bytes that you specify before processing received data or transmitting data. For large bandwidth and delay network connections, you may want to increase the default buffer size to improve your network performance. The syntax of this command is as follows:
set tcp buffer-share {rx | tx} number
The keywords and arguments are as follows:
•
•
•
For example, enter:
host1/C1(config-parammap-conn)# set tcp buffer-share rx 16384To reset the buffer limit to the default value of 32768 bytes, enter:
host1/C1(config-parammap-conn)# no set tcp buffer-share rxSetting 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 options and arguments are as follows:
•
•
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).
The default of 1380 bytes allows room for header information so that the total packet size does not exceed 1500 bytes, which is the default MTU for Ethernet. See the following calculation:
1380 data + 20 TCP + 20 IP + 24 AH + 24 ESP_CIPHER + 12 ESP_AUTH + 20 IP = 1500 bytes
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.
If you set the MSS to be greater than 1380, packets might become fragmented, depending on the MTU size (which is 1500 by default for Ethernet). Large numbers of fragments can impact the performance of the ACE. Setting the minimum size prevents the TCP server from sending many small TCP data packets to the client and impacting the performance of the server and the network.
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 1500To reset the minimum MSS to the default value of 536 bytes and the maximum MSS to the default value of 1380, enter:.
host1/C1(config-parammap-conn)# no set tcp mss min 768 max 1500Configuring 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:
•
•
For example, to configure the ACE to allow segments that exceed the MSS, enter:
host1/C1(config-parammap-conn)# exceed-mss allowTo 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 allowSetting 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 6. The default is 4.
For example, to set the maximum TCP SYN retries to 3, enter:
host1/C1(config-parammap-conn)# set tcp syn-retry 3To reset the TCP SYN retries to the default value of 4, enter:
host1/C1(config-parammap-conn)# no set tcp syn-retryEnabling 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)# nagleTo disable Nagle's algorithm, enter:
host1/C1(config-parammap-conn)# no nagleEnabling 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. To enable TCP sequence number randomization after it has been disabled, 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-numberTo disable sequence number randomization, enter:
host1/C1(config-parammap-conn)# no random-sequence-numberConfiguring 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:
•
•
•
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 clearTo 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 clearConfiguring 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 policy-map class configuration mode. The syntax of this command is as follows:
set tcp timeout embryonic seconds
For the seconds argument, enter 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.
For example, enter:
host1/C1(config-pmap-c)# set tcp timeout embryonic 24To reset the TCP embryonic connection timeout to the default value of 5 seconds, enter:
host1/C1(config-parammap-conn)# no set tcp timeout embryonicConfiguring 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 policy-map class configuration mode. The syntax of this command is as follows:
set tcp timeout half-closed seconds
For the seconds argument, enter 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-pmap-c)# set tcp timeout half-closed 2400To reset the TCP half-closed connection timeout to the default value of 3600 seconds, enter:
host1/C1(config-pmap-c)# no set tcp timeout half-closedConfiguring the Connection Inactivity Timeout
The ACE uses the connection inactivity timer to disconnect established TCP/IP, UDP, and ICMP 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 4294967294 seconds. The defaults are as follows:
•
•
•
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-pmap-c)# set timeout inactivity 2400To reset the connection inactivity timeout to the default values, enter:
host1/C1(config-pmap-c)# no set timeout inactivitySetting 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.
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
For the number argument, enter an integer from 0 to 14. The default is 0.
For example, to set the TCP window-scale factor to 5, enter:
host1/C1(config-parammap-conn)# set window-scale-factor 5To reset the window-scale factor to the default value of 0, enter:
host1/C1(config-parammap-conn)# no set tcp window-scaleEnabling 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 enabled by default. For further details about the TCP slow start algorithm, see RFC 3390.
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, enter:
host1/C1(config-parammap-conn)# slowstartTo disable the slow start algorithm, enter:
host1/C1(config-parammap-conn)# no slowstartSetting 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
For the number argument, enter 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 400To reset the ACK delay timer to the default value of 200 ms, enter:
host1/C1(config-parammap-conn)# no set ack-delayConfiguring 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:
•
•
For example, to discard SYN segments that contain data, enter:
host1/C1(config-parammap-conn)# syn-data dropTo reset the ACE behavior to the default of allowing SYN segments that contain data, enter:
host1/C1(config-parammap-conn)# no syn-data dropConfiguring 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:
•
•
•
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}}
The order of precedence for the actions in this command is as follows:
1.
2.
3.
The keywords, options, and variables are as follows:
•
–
–
•
•
•
•
•
•
Table 4-2 lists the TCP options available for the tcp-options range command.
Table 4-3 lists the TCP options explicitly supported by this command.
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 allowTo 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-ackYou 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 allowhost1/C1(config-parammap-conn)# tcp-options range 9 18 clearhost1/C1(config-parammap-conn)# tcp-options range 19 26 dropTo remove the TCP option ranges from the configuration, enter:
host1/C1(config-parammap-conn)# no tcp-options range 6 7 allowhost1/C1(config-parammap-conn)# no tcp-options range 9 18 clearhost1/C1(config-parammap-conn)# no tcp-options range 19 26 dropSetting 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 Cisco 4700 Series Application Control Engine Appliance Server Load-Balancing Configuration Guide, 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 options are as follows:
•
•
For example, to clear the Urgent flag and allow the segment, enter:
host1/C1(config-parammap-conn)# urgent-flag clearTo reset the ACE behavior to the default of allowing the Urgent flag, enter:
host1/C1(config-parammap-conn)# no urgent-flagSetting 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 20To 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 20Configuring a Traffic Policy for TCP/IP Normalization and Termination
Configuring a traffic policy for TCP/IP normalization and termination involves:
•
•
•
•
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 global configuration mode. For details about configuring a class map, see the Cisco 4700 Series Application Control Engine Appliance Administration Guide.
The syntax of this command is as follows:
class-map [match-all | match-any] name
The keywords, arguments, and options are as follows:
•
–
–
•
For example, enter:
host1/C1(config)# class-map match-any TCP_CLASShost1/C1(config-cmap)#To remove the class map from the configuration, enter:
host1/C1(config)# no class-map match-any TCP_CLASSDefining 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
For the text argument, enter 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_CLASShost1/C1(config-cmap)# description filter tcp connectionsTo remove the description from the class map, enter:
host1/C1(config-cmap)# no description filter tcp connectionsContinue 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} ip_address netmask
The keywords, arguments, and options are as follows:
•
•
•
•
•
•
You can have multiple match address commands within a single class map. Also, you can combine other match commands in the same class map.
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_CLASShost1/C1(config-cmap)# match destination-address 172.27.16.7To remove the destination IP address match criteria from the class map, enter:
host1/C1(config-cmap)# no match destination-address 172.27.16.7Defining the TCP Port Number or Port Range Match Criteria
You can specify a TCP port number or port range as the Layer 4 network traffic match criteria by using the match port command in class-map configuration mode. The syntax of this command is as follows:
[line_number] match port tcp {eq port1 | range port2 port3}
The keywords, arguments, and options are as follows:
•
•
•
•
You can have multiple 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.
The following example specifies that the network traffic must match on TCP port number 23 (Telnet client):
host1/C1(config)# class-map TCP_CLASShost1/C1(config-cmap)# match port tcp eq 23To remove the TCP port number match criterion from the class map, enter:
host1/C1(config-cmap)# no match port tcp eq 23Configuring 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 global 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, 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 Cisco 4700 Series Application Control Engine Appliance Administration Guide.
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_POLICYhost1/C1(config-pmap)#To remove a policy map from the configuration, enter:
host1/C1(config)# no policy-map multi-match TCP_POLICYAssociating 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:
•
•
•
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_CLASSAssociating 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
For the name argument, enter the name of an existing parameter map as an unquoted text string with no spaces and a maximum of 64 alphanumeric characters.
For example, enter:
host1/C1(config-pmap-c)# connection advanced-options TCP_PARAM_MAPTo dissociate the TCP parameter map from a policy map, enter:
host1/C1(config-pmap-c)# no connection advanced-options TCP_PARAM_MAPAssociating 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 global configuration mode. The syntax of this command is as follows:
service-policy input name
The keywords and arguments are as follows:
•
•
For example, enter:
host1/C1(config)# service-policy input TCP_POLICYTo dissociate a policy map from a service policy, enter:
host1/C1(config)# no service-policy input TCP_POLICYConfiguring Interface Normalization Parameters
This section describes how to configure IP normalization parameters in interface configuration mode. It contains the following topics:
•
•
•
•
•
Disabling TCP Normalization on an Interface
By default, TCP normalization is enabled. To disable TCP normalization on an interface, use 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:
•
•
Note
Caution
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 100host1/C1(config-if)# no normalizationTo reenable TCP normalization, enter:
host1/C1(config-if)# normalizationDisabling 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 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 Cisco 4700 Series Application Control Engine Appliance Server Load-Balancing Configuration Guide.
The syntax of this command is as follows:
no icmp-guard
Caution
For example, to disable ICMP security checks on interface VLAN 100, enter:
host1/C1(config)# interface vlan 100host1/C1(config-if)# no icmp-guardTo reenable ICMP security checks, enter:
host1/C1(config-if)# icmp-guardConfiguring 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:
•
•
For example, to clear the DF bit and permit the packet, enter:
host1/C1(config-if)# ip df clearTo instruct the ACE to ignore the DF bit, enter:
host1/C1(config-if)# no ip dfConfiguring How the ACE Handles IP Options
The ACE can process IP options and perform specific actions when an IP option is set in a packet. To configure how the ACE handles IP 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:
•
•
•
•
For example, enter:
host1/C1(config-if)# ip options allowTo reset the ACE behavior to the default of clearing all IP options if the appliance encounters one or more invalid or unsupported IP options, enter:
host1/C1(config-if)# no ip optionsSetting 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
For example, to set the TTL to 15, enter:
host1/C1(config-if)# ip ttl minimum 15To 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 minimumConfiguring 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 RPF 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
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-pathTo disable reverse-path forwarding, enter:
host/C1(config-if)# no ip verify reverse-pathConfiguring IP Fragment Reassembly Parameters
You can configure several parameters that control how the ACE performs IP fragment reassembly. This section contains the following topics:
•
•
•
•
•
IP Fragment Reassembly Configuration Quick Start
Table 4-5 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-5.
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.
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 1000To reset the MTU block size to 1500 bytes, use the no mtu command. For example, enter:
host1/admin(config-if)# no mtuConfiguring 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 fragment chain command in interface configuration mode. The syntax of this command is as follows:
fragment chain number
For the number argument, enter a 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 126To reset the maximum number of fragments in a packet to the default of 24, enter:
host1/C1(config-if)# no fragment chainConfiguring the Minimum Fragment Size for Reassembly
You can configure the minimum fragment size that the ACE accepts for reassembly by using the fragment min-mtu command in interface configuration mode. The syntax of this command is as follows:
fragment min-mtu number
For the number argument, enter the minimum fragment size as an integer from 68 to 9216 bytes. The default is 576 bytes.
For example, enter:
host1/C1(config-if)# fragment min-mtu 1024To reset the minimum fragment size to the default value of 576 bytes, enter:
host1/C1(config-if)# no fragment min-mtuConfiguring 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. The syntax of this command is as follows:
fragment timeout seconds
For the seconds argument, enter an integer from to 1 to 30 seconds. The default is 5 seconds.
For example, enter:
host1/C1(config-if)# fragment timeout 15To reset the fragment timeout to the default value of 5 seconds, enter:
host1/C1(config-if)# no fragment timeoutExample 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 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:
•
•
•
access-list ACL1 line 10 extended permit ip any anyparameter-map type connection TCPIP_PARAM_MAPset timeout inactivity 30set ip tos 20tcp-options timestamp allowsyn-data dropurgent-flag clearclass-map match-all L4_TCP_CLASSdescription Filter TCP Connections2 match destination-address 172.27.16.73 match port tcp eq 21policy-map multi-match L4_TCPIP_POLICYclass L4_TCP_CLASSconnection advanced-options TCP_PARAM_MAPinterface vlan 50access-group input ACL1ip address 192.168.1.100 255.255.255.0service-policy input L4_TCPIP_POLICYip ttl mimimum 15ip options clearip df allowfragment size 400fragment chain 126fragment min-mtu 1024fragment timeout 15no shutdownDisplaying Configurations and Statistics for TCP/IP and UDP Connections and IP Reassembly
This section describes the show commands that you can use to display configurations and statistics for the following:
•
•
•
•
This section contains the following topics:
•
•
•
•
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:
•
•
•
For example, to display all policy maps in the current context, enter:
host1/C1# show running-config policy-mapDisplaying 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_PMAPTable 4-6 describes the fields in the show parameter-map command output.
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] netmask mask} | count | detail | {port number1 [number2]} | {protocol {tcp | udp}}
The keywords, arguments, and options are as follows:
•
•
•
•
•
•
For 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.0Table 4-7 describes the fields in the show conn detail command output.
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.
Displaying IP Traffic Information
You can display IP 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 trafficTable 4-8 describes the fields in the show ip traffic command output.
Displaying IP Fragmentation and Reassembly Statistics
You can display IP 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 IP fragmentation and reassembly statistics for all interfaces in the ACE, enter:
host1/C1# show fragmentTable 4-9 describes the fields in the show fragment command output.
Displaying TCP Statistics
You can display TCP statistics by using the show tcp statistics 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 statisticsTable 4-10 describes the fields in the show tcp statistics command output.
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 statisticsTable 4-11 describes the fields in the show udp statistics command output.
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
For the name argument, enter the identifier of an existing service policy as an unquoted text string with a maximum of 64 alphanumeric characters.
Note
For example, to display service-policy statistics for the current context, enter:
host1/C1# show service-policy POLICY1Table 4-12 describes the fields in the show service-policy command output.
.
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} | rserver]
The keywords are as follows:
•
•
•
For example, to clear all TCP connections in the current context, enter:
host1/C1# clear conn flow tcpClearing 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
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
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
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
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 [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 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
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
