Table Of Contents

Configuring Flow and Port Mapping Parameters

Overview of CSS Flow

Configuring Flow Parameters

Configuring Permanent Connections for TCP or UDP Ports

Configuring Long-Lived Flows

Configuring Flow Timeouts for TCP or UDP Ports

Resetting Fast Ethernet and Gigabit Ethernet Ports

Configuring TCP Maximum Segment Size

Reclaiming Reserved Telnet and FTP Control Ports

Showing Flow Statistics

Configuring the Flow-State Table

Configuring the Flow State of a Port

Resetting the Flow-State Table Hit Counters

Displaying the Flow-State Table

Where to Go Next

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:

•Overview of CSS Flow

•Configuring Flow Parameters

•Configuring the Flow-State Table

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:

•Source address

•Destination address

•Protocol

•Source port

•Destination port

TCP flows are bidirectional (Figure 9-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 9-1 Example of a TCP Flow

UDP flows (Figure 9-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 9-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 switch fabric processor (SFP) 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 SLL, refer to the Cisco Content Services Switch Advanced Configuration Guide.

Each client-CSS-server connection consists of two parts (Figure 9-3):

•Front-end - Connection between a client and the CSS

•Back-end - Connection between the CSS and a server

Figure 9-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.

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 (Figure 9-4).

Figure 9-4 Setting Up the Front-End TCP Connection - Delayed Binding

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:

•Content rule match

•Service availability

•Service load

•Cookies

•Source IP address

For more information about CSS server load balancing (SLB), refer to the Cisco Content Services Switch Basic Configuration Guide.

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 9-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 9-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:

•HTTP redirection - Using the persistence reset redirect command, a CSS closes the back-end connection by sending a RST to the service (Figure 9-6). The CSS sends a 302 redirect to the client's browser to tell the browser to reconnect using the same DNS name, but this time the HTTP request matches on a different content rule. The CSS then establishes a new flow between the client and the best service.

Figure 9-6 Example of HTTP Redirection

•Service remapping - Using the persistence reset remap command, a CSS closes only the back-end connection by sending a RST to the service (server 1 in Figure 9-7), then establishes a new back-end connection with service server 2 and splices the back-end and front-end connections together. The CSS forwards the content request from the client to server 2. Packets now flow between the client and server 2.

For more information about persistence, HTTP redirection, and service remapping, refer to the Cisco Content Services Switch Basic Configuration Guide.

Figure 9-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:

•flow permanent command - Creates permanent TCP or UDP ports that are not reclaimed. See the "Configuring Permanent Connections for TCP or UDP Ports" section for details.

•flow long-lived command - Delays flow reclamation on a lightly loaded CSS. See the "Configuring Long-Lived Flows" section for details.

•flow port timeout command - Configures a flow timeout value for a maximum of 10 ports. See the "Configuring Flow Timeouts for TCP or UDP Ports" section for details.

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

Use the flow command to configure flow parameters for the CSS. The options for this global configuration mode command are as follows:

•flow permanent - Creates permanent TCP or UDP ports that are not reclaimed

•flow long-lived - Delays flow reclamation on a lightly loaded CSS

•flow port1 timeout to flow port10 timeout - Configures a flow timeout value for a maximum of 10 ports

•flow port-resets - Resets Fast Ethernet and Gigabit Ethernet ports automatically when the CSS detects that they are not responding

•flow reserve-clean - Reclaims interval flows with port numbers less than or equal to 23

•flow tcp-mss - Configures the TCP maximum segment size that the CSS expects to receive from the transmitting device

•flow statistics - Displays statistics on currently allocated flows

---

Note Flow parameter setup by the CSS is restricted on the following TCP or UDP ports: 67 (BOOTP server), 68 (BOOTP client), 137 (NETBIOS name service), 138 (NETBIOS datagram service), 161 (SNMP), 162 (SNMP traps), 520 (RIP), and 8089 (restricted UDP only).

---

This section includes the following topics:

•Configuring Permanent Connections for TCP or UDP Ports

•Configuring Long-Lived Flows

•Configuring Flow Timeouts for TCP or UDP Ports

•Resetting Fast Ethernet and Gigabit Ethernet Ports

•Configuring TCP Maximum Segment Size

•Reclaiming Reserved Telnet and FTP Control Ports

•Showing Flow Statistics

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.

The CSS may reclaim:

•TCP flows that have not received an ACK or content request after approximately 15 seconds

•UDP flows that have not received an ACK or content request after approximately 16 seconds

To prevent the CSS from reclaiming TCP or UDP flows to a specific source or destination port, use the flow permanent command and specify 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 80

To reset the port number for port1 to 0, enter:

(config) no flow permanent port1

We 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 Advanced Configuration Guide.

Configuring Long-Lived Flows

By default, flow reclamation is always running. Use the flow long-lived command to delay flow reclamation on lightly loaded CSSs so as to allow long-lived flows to continue even during a large period of inactivity. This command delays flow reclamation until one-fourth of the total Flow Control Blocks (FCBs) are in use.

Use the flow long-lived command only if the CSS reclaims flows too quickly and the number of flows on the CSS is relatively low. You may find this command particularly useful for a database application.

For example, to delay flow reclamation on a lightly loaded CSS, enter:

(config) flow long-lived

To disable the flow reclamation delay on the CSS, enter:

(config) no flow long-lived

For information about other methods of delaying flow reclamations, see the "Configuring Permanent Connections for TCP or UDP Ports" and "Configuring Flow Timeouts for TCP or UDP Ports" sections.

Configuring Flow Timeouts for TCP or UDP Ports

Use the flow port[1|2|3|4|5|6|7|8|9|10] timeout command to configure a flow timeout value for a TCP or UDP port. The timeout value you configure specifies the time that elapses before the CSS reclaims the flow. You can configure a flow timeout value for a maximum of ten TCP or UDP ports.

The syntax for this global configuration mode command is:

flow port[1|2|3|4|5|6|7|8|9|10] port_number timeout value

The syntax and options for this command are as follows:

•portnumber - The number of the port. Enter an integer from 0 to 65535. The default is 0.

•timeout value - The flow timeout value for the TCP or UDP port. Enter an integer from 1 to 600 seconds (10 minutes).

A configured flow permanent port takes precedence over a configured flow timeout value. If you do not configure a flow timeout value, the default timeout value takes effect, as follows:

•Default TCP - 15 seconds

•Default UDP - 16 seconds

•NFS (port 2049), CHAT (port 5190), HTTP (port 80) - 8 seconds

•FTPDATA (port 20), FTPCTRL (port 21), TELNET (port 23),
SSHD (port 22), SOCKS (port 1080), FWGUI1(port 258),
SQLSRV (port 156), ORACLE1 (port 1521), ORACLE2 (port 1526), and SMTP (port 25) - 600 seconds

For example, to configure a timeout value of 200 seconds for port 8, HTTP port 80, enter:

(config) flow port8 80 timeout 200

To disable the flow timeout value for a TCP or UDP port, enter:

(config) no flow port8 timeout

Resetting Fast Ethernet and Gigabit Ethernet Ports

You can configure a CSS to reset its Fast Ethernet and Gigabit Ethernet ports automatically when it detects the ports are nonresponsive during operation. Use the flow port-resets command to enable this function. By default, port resetting is enabled on a CSS.

---

Caution Do not disable port-resets without guidance from Cisco Systems Technical Assistance Center (TAC).

---

For example:

(config)# flow port-resets

To disable port resets on the CSS, enter:

(config)# no flow port-resets

Configuring TCP Maximum Segment Size

Use the flow tcp-mss command to configure the TCP maximum segment size (MSS) that the CSS expects to receive from the transmitting device. The 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. 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 Do not define a smaller than necessary TCP maximum segment size with the flow tcp-mss command. Smaller payloads may be less efficient due to increased overhead.

---

To configure a TCP maximum segment size of 1400 bytes, enter:

(config)# flow tcp-mss 1400

To reset the TCP maximum segment size to the default value of 1460 bytes, enter:

(config)# no flow tcp-mss

Reclaiming Reserved Telnet and FTP Control Ports

Use the flow reserve-clean command to define how often the CSS scans flows from reserved Telnet and FTP control ports to reclaim them. 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.

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 36

To disable flow cleanup on Telnet and FTP control ports, enter:

(config)# no flow reserve-clean

Showing Flow Statistics

Use the flow statistics command to display statistics on currently allocated flows.

For example:

(config)# flow statistics

Flow Manager Statistics:

                         Current   High     Avg

UDP Flows per second     0         0        0

TCP Flows per second     0         4        0

Total Flows per second   0         4        0

Hits per second          0         0        0

-------------------------------------------------------------

Port      Active      Total         TCP     UDP

-------------------------------------------------------------

1         13          43339169      13      0

2         16          43337519      16      0

5         18          3167362       18      0

6         9           33483528      9       0

Configuring the Flow-State Table

A CSS sets up flows for most TCP and UDP traffic. However, for packets that contain certain specific ports or applications, a CSS may decide not to set up flows. The default behavior for a CSS is to not set up flows for the applications and ports listed in Table 9-1.

Table 9-1 Default CSS Flow-Disabled Applications and Ports 

Application	Port
BOOTP Server	67
BOOTP Client	68
NETBIOS Name Service	137
NETBIOS Datagram Service	138
SNMP	161
SNMP Traps	162
RIP	520
Inktomi-UDP	8089

S

To keep track of the flow states of certain TCP and UDP ports, a CSS maintains a flow-state table. You can configure the flow states of the TCP and UDP applications and ports shown in Table 9-2.

Table 9-2 Configurable Flow-State Table Ports and Protocols 

Application	Port	IP Protocol
DNS	53	TCP and UDP
SNMP	161	TCP and UDP
SNMP traps	162	TCP and UDP
SIP	5060	UDP only

S

In addition, you can set the network address translation (NAT) state for flow-disabled UDP ports. By default, Domain Name Service (DNS) port 53 (TCP and UDP) and SIP port 5060 (UDP) are flow-enabled.

Use the flow-state table:

•For applications that do not use a random client port. For example, DNS between two authorities that use port 53 for both ports. If a flow were set up, all traffic would appear to be the same connection and no load balancing would occur.

•To avoid flow setup overhead for one-time UDP packets.

•To avoid flow setup overhead for known non-NATed packets.

For details on SNMP, refer to Chapter 12, Configuring Simple Network Management Protocol (SNMP). For details on NAT and SIP, refer to the Cisco Content Services Switch Basic Configuration Guide. For details on DNS, refer to the Cisco Content Services Switch Advanced Configuration Guide.

Configuring the Flow State of a Port

Use the flow-state command to set the flow state of the port and IP protocol you want to use. When you set the flow state of a port to flow-enable, the CSS performs content-rule and source-group matching. For flow-disabled UDP ports, you can enable the NAT state independent of the flow state so that the CSS performs NATing and port mapping.

The syntax of this global configuration mode command is:

flow-state number tcp [flow-enable|flow-disable]

flow-state number udp [flow-enable|flow-disable {nat-enable|nat-disable}]

The options and variables for this global configuration mode command are as follows:

•number - Specifies the TCP or UDP port number whose flow state you want to configure.

•tcp - Specifies a TCP port.

•udp - Specifies a UDP port.

•flow-enable - Enables flows on the specified TCP or UDP port. With this option, the CSS performs full content-rule and source-group matching, including Layer 5 (URL string) content-based load balancing and sticky.

•flow-disable - Disables flows on the specified TCP or UDP port. When you disable flows on a port, the CSS does not perform content rule and source group matching. The benefit is no flow setup overhead.

•nat-enable - For flow-disabled UDP ports, enables content-rule and source-group lookups for NAT. With this option, you can use Layer 3 (IP address) and Layer 4 (IP address and destination port) content rules and the sticky table (for example, sticky-srcip). However, without the benefit of a flow, the CSS cannot spoof the back-end connection, which is required to make Layer 5 content-based decisions.

•nat-disable - For flow-disabled UDP ports, the CSS does not perform content-rule and source-group lookups for NAT.

---

Caution If you configure the flow-disable and nat-disable options simultaneously on a particular port, content-rule and source-group lookups are no longer available for that port. In this case, the CSS drops packets directed to a VIP address associated with the port and sends an ICMP port unreachable message to the client. The CSS continues to forward packets directed to other IP addresses.

---

Example 1:

To enable flows for SNMP TCP port 161, enter:

(config)# flow-state 161 tcp flow-enable

To disable flows for SNMP TCP port 161, enter:

(config)# no flow-state 161 tcp

Example 2:

To enable flows for SIP UDP port 5060, enter:

(config)# flow-state 5060 udp flow-enable

To disable flows for SIP UDP port 5060, enter:

(config)# no flow-state 5060 udp

Example 3:

To disable the flow state of SNMP UDP port 162 (SNMP traps) and enable NAT for that port, enter:

(config)# flow-state 162 udp flow-disable nat-enable

To reset the flow state and the NAT state of SNMP port 161 to the default settings of flow-disable and nat-disable, respectively, enter:

(config)# no flow-state 161 udp

Resetting the Flow-State Table Hit Counters

The flow-state table contains hit counters that total the number of hits for each port entry in the table. Use the zero flow-state-counters command to reset all the hit counters in the table to zero. For example:

(config)# zero flow-state-counters

Displaying the Flow-State Table

Use the show flow-state-table command to display the flow-state table entries.

Table 9-3 shows the default settings in the flow-state table. DNS port 53 (TCP and UDP) and SIP port 5060 (UDP only) are flow enabled by default. Dashes (---) in the NAT-State column indicate that either you cannot modify the field or that the field is not relevant in combination with the Flow-State field.

Table 9-3 Flow-State Table Default Values 

Port	Protocol	NAT-State	Flow-State	Hit-Count
53	TCP	------------	flow-enable	0
53	UDP	------------	flow-enable	0
161	TCP	------------	flow-disable	0
161	UDP	nat-disable	flow-disable	0
162	TCP	------------	flow-disable	0
162	UDP	nat-disable	flow-disable	0
5060	UDP	------------	flow-enable	0

Table 9-4 describes the fields in the show flow-state-table command output.

Table 9-4 Field Descriptions for the show flow-state-table Command 

Field	Description
Port	Number of the port for which you are displaying flow-state data.
Protocol	IP protocol associated with the port number.
NAT-State	Status of network address translation for the port. Possible states are nat-enable, nat-disable, or --------- (not relevant). The nat-enable and nat-disable states are available only for flow-disabled UDP ports 53, 161, 162, and 5060.
Flow-State	Status of flows for a particular port. Possible states are flow-enable and flow-disable.
Hit-Count	Number of hits on a particular port.

Where to Go Next

Chapter 10, Configuring User Profiles provides information about how to configure CSS user profiles in the default-profile file.