Table Of Contents
Configuring Flow and Port Mapping Parameters
Configuring Permanent Connections for TCP or UDP Ports
Configuring TCP Maximum Segment Size
Reclaiming Reserved Telnet and FTP Control Ports
Configuring Flow Inactivity Timeouts on Content Rules and Source Groups
Displaying Flow Timeout Statistics
Displaying Content Rule and Source Group Information
Configuring Flow Processing for Fragmented IP Packets
What Is IP Packet Fragmentation?
Enabling Flow Processing for Fragmented IP Packets
Configuring the Maximum Assembled Size
Configuring the Minimum Fragment Size
Displaying IP Fragment Statistics
Resetting IP Fragment Statistics
Configuring a CSS to Send a TCP Reset if a VIP Is Unavailable
Overview of Global Port Mapping
Configuring Global Port Mapping
Displaying Global Port Mapping Statistics
Configuring No-Flow Port Mapping
Displaying No-Flow Port Mapping Statistics
Configuring Flow and Port Mapping Parameters
This chapter describes how to configure flow and port mapping parameters for the CSS. Information in this chapter applies to all CSS models, except where noted.
This chapter contains the following major sections:
•
Configuring Flow Inactivity Timeouts on Content Rules and Source Groups
•
•
Overview of CSS Flow
A flow is the transfer of a sequence of related packets over a TCP or UDP connection between a source (client) and a destination (server) through the CSS. All packets in an ingress flow (traffic entering the CSS) share a common 5-tuple consisting of:
•
•
•
•
•
TCP flows are bidirectional (Figure 5-1). Packets move from the client to the server and from the server to the client through the CSS. Strictly speaking, a TCP connection consists of two flows, one in each direction. A TCP flow begins with a SYN and ends with an ACK to a FIN/ACK, or an RST.
Figure 5-1 Example of a TCP Flow
UDP flows (Figure 5-2) are typically unidirectional (for example, streaming audio transmitted by a server to a client). A UDP flow has no definitive beginning or end and is considered completed only after a period of time has elapsed during which the destination device receives no packets that share the same addresses, protocol, and ports that defined the original flow.
Figure 5-2 Example of a UDP Flow
A CSS uses data structures called flow control blocks (FCBs) to set up and keep track of ingress flows. FCBs contain all the information the CSS needs to process and manage flows. The creation of an FCB from flow information is called flow mapping. The flow manager in each module session processor is responsible for FCB creation and flow mapping.
Each unidirectional flow uses one FCB. Therefore, a TCP flow uses two FCBs and a UDP flow typically uses one FCB. Front-end SSL, which runs over TCP, requires four FCBs and back-end SSL adds two more FCBs for a total of six FCBs per full-duplex SSL connection. For more information about SSL, refer to the Cisco Content Services Switch Security Configuration Guide.
Each client-CSS-server connection consists of two parts (Figure 5-3):
•
•
Figure 5-3 Example of a TCP Flow with Front-End and Back-End Connections
A Layer 5 flow begins with a client request for content. After the D-proxy resolves the DNS request (for example, a client types a URL in a Web browser) and points the client to the CSS virtual IP address (VIP), the CSS establishes the front-end TCP connection with the client using the TCP 3-way handshake (Figure 5-4).
Figure 5-4 Setting Up the Front-End TCP Connection - Delayed Binding
When it establishes a Layer 5 flow, a CSS "spoofs" the back-end TCP connection by acting as a proxy for the destination device (server) for the client SYN. In other words, the CSS responds to the client SYN with a SYN/ACK before the CSS sets up the back-end TCP connection with the server.
This process is referred to as delayed binding. Delayed binding causes the client to respond with an ACK and an HTTP GET request. This process allows the CSS to gather the information it needs to select the best service (a server port where content resides or an application running on a server such as FTP) for the content request.
The CSS examines the HTTP header and URL in the HTTP request method (for example, GET, HEAD, or POST). Based on the information in the HTTP header, the URL, and the content rules configured on the CSS, the CSS selects the best site and the best service to satisfy the request. A CSS bases service selection (server load balancing) on factors such as:
•
•
•
•
•
For more information about CSS server load balancing (SLB), refer to Chapter 1, Configuring Services.
After the CSS selects the best service to provide the requested content to the client, the CSS establishes the back-end connection with the service using the TCP 3-way handshake and splices the front-end and back-end connections together. The CSS forwards the content request from the client to the service (Figure 5-5). The service responds to the client through the CSS. For the remaining life of the flow, the CSS switches the packets between the client and the service, and performs network address translation (NAT) and other packet transformations as required.
Figure 5-5 Setting Up the Back-End TCP Connection - Delayed Binding
For subsequent content requests from the same client over the same TCP connection (HTTP 1.1 and higher), the CSS attempts to maintain the back-end connection with the service that provided the content for the first HTTP request by default. This condition is called persistence.
During the life of a persistent connection, a CSS must determine if it needs to move a client connection to a new service based on content rules, load balancing, and service availability. In some situations, moving the client connection is not necessary; in other situations, it is mandatory.
You can configure the CSS to perform one of the following functions when it becomes necessary to move a client to a new service:
•
Figure 5-6 Example of HTTP Redirection
•
For more information about persistence, HTTP redirection, and service remapping, refer to Chapter 6, Configuring HTTP Header Load Balancing.
Figure 5-7 Example of Remapping the Back-end Connection
Periodically, the CSS flow manager tears down old, idle flows and reclaims the system resources (FCBs). This process is called flow resource reclamation. It is also referred to as flow cleanup or garbage collection. Flow resource reclamation involves removing FCBs from the TCP and UDP lists. For optimal performance, the CSS reuses FCBs that are no longer needed for flows.
Normally, flow cleanup occurs at a rate that is directly related to the total number of flows that are currently active on a CSS. A CSS always cleans up UDP flows. For TCP flows, a CSS reclaims resources when the number of used FCBs reaches a certain percentage of the total FCBs. A CSS also cleans up long-lived TCP flows that have received a FIN or a RST, or whose timeout values have been met. You can configure various commands to change the default flow-cleanup behavior of the CSS.
In some instances it may not be desirable for the CSS to clean up idle TCP flows. For example, during a connection to a database server that must permanently remain active even when no data passes through the connection. If you observe the CSS dropping long-lived idle connections that need to be maintained you can configure the following TCP flow commands:
•
•
The remainder of this chapter describes the commands you can use to control how the CSS handles and cleans up TCP and UDP flows.
Configuring Flow Parameters
To configure flow parameters for the CSS, use the flow command. The options for this global configuration mode command are as follows:
•
•
•
•
Note
This section includes the following topics:
•
•
•
Configuring Permanent Connections for TCP or UDP Ports
The CSS allows you to configure a maximum of 20 TCP or UDP ports that have permanent connections and will not be reclaimed by the CSS when the flows are inactive. Use the flow permanent port1 portnumber (through flow permanent port 20 portnumber) commands to configure a TCP or UDP port as a permanent connection. Enter a port number from 0 to 65535. The default is 0.
A CSS may reclaim flows that have not received an ACK or content request after approximately 15 seconds. To prevent the CSS from reclaiming flows to a specific source or destination port, specify one of the flow permanent port commands and identify the TCP or UDP port number you do not want reclaimed.
For example, to configure port 80 as a permanent connection, enter:
(config) flow permanent port1 80To reset the port number for port1 to 0, enter:
(config) no flow permanent port1We recommend that when you configure a flow permanent port command you also enable the cmd-sched command to periodically remove the permanent port and allow for cleanup. For details on using the cmd-sched command to configure the scheduled execution of any CLI command, refer to the Cisco Content Services Switch Administration Guide.
Configuring TCP Maximum Segment Size
The maximum segment size (MSS) is the largest amount of TCP data that can be transmitted in one segment. The need for a smaller MSS between devices may be necessary in rare instances due to network restrictions between devices. Use the flow tcp-mss command to configure the TCP MSS that the CSS expects to receive from the transmitting device. The flow tcp-mss command changes the MSS value in the TCP header OPTIONS field of a SYN segment, to reduce the MSS from the default value of 1460 bytes.
The flow tcp-mss command applies only when the client is accessing a Layer 5 content rule. The CSS does not negotiate TCP maximum segment size for Layer 3 or Layer 4 content rules.
Enter a maximum segment size (in bytes) from 1 to 1460. The default is 1460 bytes. Use the no form of the command to reset the TCP maximum segment size back to the default value of 1460 bytes.
Caution
To configure a TCP maximum segment size of 1400 bytes, enter:
(config)# flow tcp-mss 1400To reset the TCP maximum segment size to the default value of 1460 bytes, enter:
(config)# no flow tcp-mssReclaiming Reserved Telnet and FTP Control Ports
Control ports have port numbers less than or equal to 23. When the CSS determines that one of these ports has a flow with asymmetrical routing, it reclaims the port.
Use the flow reserve-clean command to define how often the CSS scans flows from reserved Telnet and FTP control ports to reclaim them. Enter the flow reserve-clean time, in seconds, as the interval the CSS uses to scan flows. Enter an integer from 0 to 100. The default is 10. To disable the port reclaiming process, enter a flow reserve-clean value of 0.
For example, to specify an interval of 36 seconds:
(config)# flow reserve-clean 36To disable flow cleanup on Telnet and FTP control ports, enter:
(config)# no flow reserve-cleanShowing Flow Statistics
Use the flow statistics command to display statistics on active flows or Flow Control Blocks (FCBs) on the CSS interfaces.
Note
Table 5-1 describes the fields in the flow statistics output.
Configuring Flow Inactivity Timeouts on Content Rules and Source Groups
Use this feature with a CSS to configure flow inactivity timeout values for TCP and UDP flows on a per content rule and per source group basis. This timeout value is not the frequency with which a CSS reclaims flow resources, but is the time period that must elapse for an idle flow before the CSS marks the flow for cleanup.
Timeout Value Precedence
The CSS uses the following guidelines in the order presented when reclaiming flow resources:
1.
2.
3.
4.
Configuring Flow Timeouts
To specify the number of seconds for which an idle flow can exist before the CSS tears it down, use the flow-timeout-multiplier command. Specify this command in owner-content or group configuration mode. The syntax for this command is:
flow-timeout-multiplier number
Note
Enter an integer for the number variable from 0 to 65533. The CSS multiplies the value you specify by 16 to calculate the flow timeout in seconds. The default value depends on the TCP or UDP port number (see the "Displaying Flow Timeout Statistics" section). This default value applies only to flows that you create under a content rule or source group.
A value of zero (no timeout) instructs the CSS to never tear down the flow, resulting in a permanent flow and lost resources. Specifying a value of zero is equivalent to entering the flow permanent port command (see the "Configuring Permanent Connections for TCP or UDP Ports" section).
Note
Note
These two examples show flow timeout periods of 80 seconds:
(config-owner-content[cisco-rule1])# flow-timeout-multiplier 5(config-group[group1])# flow-timeout-multiplier 5To disable the configured flow-timeout-multiplier value and restore the default timeout for the port type, enter:
(config-owner-content[cisco-rule1])# no flow-timeout(config-group[group1])# no flow-timeoutDisplaying Flow Timeout Statistics
Use the show flow-timeout default command to display the default timeout values for TCP and UDP ports and applications. The default values are not user configurable. Table 5-2 shows the fields in the show flow-timeout default command output.
Use the show flow-timeout configured command to display the configured flow timeout values. The command output includes the content rule or source group for which you configured the flow timeout value.
Table 5-3 describes the fields in the show flow-timeout configured command output.
Displaying Content Rule and Source Group Information
If you configure a flow timeout value in a content rule or a source group, the show rule or show group command output includes an additional field called Flow Timeout Multiplier. This field contains the configured timeout value assigned to flows that match on the rule or group.
Configuring Flow Processing for Fragmented IP Packets
By default, a CSS does not process fragmented TCP and UDP IP packets (IP fragments) in the flow path, but simply routes them according to standard IP routing practices. As a result, IP fragments do not match on configuration items such as content rules and source groups and, therefore, the CSS does not NAT or load balance the fragments.
When you enable flow processing for IP fragments, a CSS processes the IP fragments in the flow path using the IP address and TCP port or UDP port information in the IP header and in the TCP or UDP header. The CSS then forwards and NATs the individual fragments of a packet based on the configured content rules and source groups matched by the fragments.
This feature supports only Layer 3 and Layer 4 content rules. For Layer 5 content rules, use the flow tcp-mss command. For details about the flow-tcp-mss command, see the "Configuring Flow Parameters" section.
Use this feature to support:
•
•
•
•
Note
This section describes how to configure flow processing for fragmented IP packets. It includes the following topics:
•
•
•
•
•
•
What Is IP Packet Fragmentation?
An IP fragment is a part of a larger complete IP packet. IP packets require fragmentation when the next-hop network's maximum transmit unit (MTU) is less than the incoming packet size. The transmitting device divides the packet into smaller pieces that the network medium can accommodate and copies the packet IP header into each fragment. Packets can be fragmented by the source host, intermediate routers, and other network devices.
IP packet fragmentation is generally considered an undesirable condition because fragmentation and subsequent reassembly of packets cause additional CPU and network overhead. However, despite the best efforts of network designers, some fragmentation is inevitable because of the different network media with varying MTUs that support the IP protocol.
For more information about IP packet fragmentation, refer to RFC 791 and RFC 815.
Configuration Restrictions
The following TCP applications are not supported when a CSS receives fragmented packets and flow processing for TCP IP fragments is enabled:
•
•
•
•
•
Note
Enabling Flow Processing for Fragmented IP Packets
To allow a CSS to flow-process IP fragments, use the udp-ip-fragment-enabled or the tcp-ip-fragment-enabled command in global configuration mode. By default, this feature is disabled.
Note
To reset the default behavior of the CSS to forward IP fragments, use the no form of the command.
For example, enter:
(config)# no udp-ip-fragment-enabled(config)# no tcp-ip-fragment-enabled
Note
Configuring the Maximum Assembled Size
The maximum assembled size is the total length of an IP packet if all the IP fragments were assembled into the original packet. Assembled IP packets should be no larger than 64 KB. As the CSS receives the IP fragments, it checks the fragments against the maximum assembled size value. If a fragment IP offset plus the IP payload (data) length is greater than the configured maximum assembled size, the CSS increments the Max Assembled Size error field in the show ip-fragment-stats command output and discards the packet. See the "Displaying IP Fragment Statistics" section.
Note
To specify the maximum assembled size for TCP and UDP IP fragments, use the ip-fragment max-assembled-size command. The syntax of this global configuration mode command is:
ip-fragment max-assembled-size number
The number variable specifies the maximum size of an assembled packet in bytes. Enter an integer from 2048 to 65535. The default is 5120 bytes.
For example, enter:
(config)# ip-fragment max-assembled-size 4096To restore the default maximum IP fragment assembled size to 5120 bytes, use the no form of the command.
For example, enter:
(config)# no ip-fragment max-assembled-sizeConfiguring the Minimum Fragment Size
The minimum fragment size is the smallest IP payload in an IP fragment that a CSS accepts. As the CSS receives the IP fragments, it checks the fragments against the minimum fragment size value. If a fragment IP payload length is less than the configured minimum fragment size, the CSS increments the Less Than Min Size error field in the show ip-fragment-stats command output and discards the packet. See the "Displaying IP Fragment Statistics" section.
To specify the smallest IP fragment payload for TCP and UDP IP fragments based on your applications, use the ip-fragment min-fragment-size command. This command also provides protection against fragment attacks, which can consist of a chain of valid-looking, but very small, fragments.
The syntax of this global configuration mode command is:
ip-fragment min-fragment-size number
The number variable specifies the size of the smallest IP fragment payload that the CSS supports in bytes. Enter an integer from 64 to 1024. The default is 1024 bytes.
For example, enter:
(config)# ip-fragment min-fragment-size 256
Note
To restore the default minimum IP fragment payload size to 1024 bytes, use the no form of the command.
For example, enter:
(config)# no ip-fragment min-fragment-sizeDisplaying IP Fragment Statistics
To display the status, statistics, and error counts associated with TCP and UDP IP fragment processing, use the show ip-fragment-stats command in any mode.
Table 5-4 describes the fields for the show ip-fragment-stats command output.
Resetting IP Fragment Statistics
To reset the TCP and UDP IP fragment statistics, use the zero ip-fragment-stats command in any mode. This command resets the values of the statistics in the IP Fragment Statistics and IP Fragment Errors sections of the show ip-fragment-stats command output to zero.
For more information about the show ip-fragment-stats command, see the "Displaying IP Fragment Statistics" section.
Configuring a CSS to Send a TCP Reset if a VIP Is Unavailable
If a Layer 3 or Layer 4 content rule VIP that a CSS is hosting is unavailable, the CSS, by default:
•
•
This behavior can occur when a packet:
•
•
If a CSS rejects a TCP packet, the client can retransmit the packet. If no services become available for a matching Layer 3 or Layer 4 content rule, the client application becomes unresponsive and either the connection or the application eventually times out. It takes the application a variable amount of time to time out. The latency caused by this time-out process is unacceptable for some applications.
This feature allows you to configure a CSS to send a TCP RST to the client in response to the TCP packet if the VIP is unavailable. If the application receives the TCP RST, the application stops retransmitting the packet and usually displays an error message about the failed connection attempt.
Note
Applications where this feature may be useful include:
•
•
•
To configure a CSS to send a TCP RST to a client when a VIP is unavailable, use the flow tcp-reset-vip-unavailable command in global configuration mode. The CSS sends the TCP RST only in response to a TCP packet that is destined for a VIP that the CSS is hosting and only if that VIP is unavailable.
For example, enter:
(config)# flow tcp-reset-vip-unavailableTo return the CSS behavior to the default of dropping the TCP packet if a VIP is unavailable, enter:
(config)# no flow tcp-reset-vip-unavailableTo display the number of TCP RSTs that a CSS sent because a VIP was unavailable, enter the show ip statistics command. For more information on the show ip statistics command, refer to the Cisco Content Services Switch Routing and Bridging Configuration Guide.
Configuring CSS Port Mapping
This section describes how to globally control the range of port numbers a CSS uses to perform port address translation (PAT) on TCP and UDP source port numbers specified in packets sent to the CSS from clients. The CSS assigns unique port numbers within a configurable range for the source port numbers specified in the packets, then sends the packets to the appropriate server port. When a server initiates a return flow, the packets flow through the CSS. The CSS matches the translated port number with the client that initiated the request and sends the server packets to the appropriate client.
Overview of Global Port Mapping
Each CSS module (except the SSL module) has one session processor (SP) that is responsible for mastering flows.
•
•
•
The global port mapper in a CSS is called the mega port mapper. The mega port mapper database comprises 16 banks (megamap banks) of 63488 port-map numbers each in each session processor (SP). A CSS uses a source address hash algorithm to select a megamap bank in a particular SP.
For client-side flows, the CSS sends packets to different SPs for flow processing and the flows have access to the source ports in that SP. The CSS performs a simple XOR hash of the TCP or UDP source and destination port numbers to determine the SP that becomes master for that flow. If the port numbers are the same (for example, DNS UDP port 53), then the CSS uses the low order bits of the source and destination IP addresses to calculate the hash value. The CSS uses the hash value to index into a weighted table of SPs and selects the appropriate SP.
When the CSS performs PAT, the master SP for the flow uses a source port from either the global portmapper or a source group, depending on your configuration. (For information about source groups, see Chapter 1, Configuring Services in the "Configuring Source Groups" section.) The CSS chooses a source port so that the hash of it and the destination port will select the same SP for the server-side flow as the SP that mastered the client-side flow.
For the server-side flow from a given destination port, only certain source port numbers hash to the same SP that was used for the client-side flow. For this reason, all ports available to a particular SP are not necessarily eligible for use when establishing the back-end connection. Therefore, the hash algorithm selects only a percentage of the available ports on any one SP.
Each CSS maintains a database of used and available port-map numbers. When a CSS needs to PAT a source port, it uses the next unused port number in its database.
This section includes the following topics:
•
•
•
•
Configuring Global Port Mapping
To control the global PAT for TCP flows on a CSS, use the global-portmap command . This command is always enabled.
You can use this command to specify the source-port mapping range on:
•
•
•
When you configure a source group, the portmap command parameter values take precedence over the global-portmap command parameter values. The portmap disable command has no effect on TCP flows.
The syntax for this global configuration mode command is:
global-portmap base-port number1 range number2
The options and variables for this command are:
•
Caution
•
Caution
Enter an integer from 2048 to 63488. The default is 63488. If you enter a value that is not a multiple of 32, the CSS rounds up the value to the next possible multiple of 32.
Note
For example:
(config)# global-portmap base-port 3096 range 42308To return the global-portmap command parameters to their default values, enter:
(config)# no global-portmapDisplaying Global Port Mapping Statistics
Use the show global-portmap command to display statistics for global port mapping on a CSS. This command is available in all modes except RMON, URQL, and VLAN configuration modes.
The syntax for this command is:
show global-portmap [all-banks [all-sps|slot number1]|number2 [all-sps|slot number1]]
The options and variables for this command are as follows:
•
•
•
To display the available active slots in the CSS, enter the show global-portmap all-banks slot ? command. If you enter an invalid slot number, the CLI displays values for only the first two parameters listed in Table 5-5.
•
To display port mapping statistics for all megamap banks (up to 16) on every active SP in the CSS, enter:
(config)# show global-portmap all-banks all-spsTo display global port mapping statistics for megamap bank 12 in the SP that resides in slot 3, enter:
(config)# show global-portmap 12 slot 3Table 5-5 describes the fields in the show global-portmap command output.
Configuring No-Flow Port Mapping
To control the PAT range of DNS UDP source-port numbers greater than 1023 on a CSS, use the noflow-portmap command. This command is always enabled. However, before a CSS can use this command, you must enter the dnsflow disable command to disable DNS flows on the CSS. Refer to the Cisco Content Services Switch Administration Guide for details on the dnsflow command.
Note
The syntax for this global configuration mode command is:
noflow-portmap base-port number1 range number2
The options and variables for this command are:
•
Caution
•
Caution
Enter an integer from 2048 to 63488. The default is 63488. If you enter a value that is not a multiple of 32, the CSS rounds up the value to the next possible multiple of 32.
Note
For example, to specify a port map range, starting with port 4317, enter:
(config)# noflow-portmap base-port 4317 range 35421To reset the starting port number and port-map range to their default values, enter:
(config)# no noflow-portmapDisplaying No-Flow Port Mapping Statistics
Use the show noflow-portmap command to display statistics for no-flow port mapping on a CSS. This command is available in all modes except RMON, URQL, and VLAN configuration modes.
The syntax for this command is:
show noflow-portmap [all-sps|slot number]
The options and variables for this command are as follows:
•
•
Note
For example:
(config)# show noflow-portmap slot 3Table 5-6 describes the fields in the show noflow-portmap command output.
