CSS Administration Guide (Software Version 7.20)
Configuring Flow and Port Mapping Parameters
Downloads: This chapterpdf (PDF - 368.0KB) The complete bookPDF (PDF - 4.68MB) | Feedback

Configuring Flow and Port Mapping Parameters

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 TCP Maximum Segment Size

Reclaiming Reserved Telnet and FTP Control Ports

Showing Flow Statistics

Configuring Flow Inactivity Timeouts on Content Rules and Source Groups

Timeout Value Precedence

Configuring Flow Timeouts

Displaying Flow Timeout Statistics

Displaying Content Rule and Source Group Information

Configuring Flow Processing for Fragmented UDP IP Packets

What Is IP Packet Fragmentation?

Enabling Flow Processing for Fragmented UDP IP Packets

Configuring the Maximum Assembled Size

Configuring the Minimum Fragment Size

Resetting IP Fragment Statistics

Displaying IP Fragment Statistics

Configuring CSS Port Mapping

Configuring Global Port Mapping

Displaying Global Port Mapping Statistics

Configuring No-flow Port Mapping

Displaying No-Flow Port Mapping Statistics

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 Flow Inactivity Timeouts on Content Rules and Source Groups

Configuring Flow Processing for Fragmented UDP IP Packets

Configuring CSS Port Mapping

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

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

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-timeout-multiplier command - Configures flow inactivity timeout values for TCP and UDP flows on a per content rule and per source group basis. See the "Configuring Flow Timeouts" 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 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 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 10 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 10 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 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 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 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. If a flow matches on a content rule, the CSS checks for a user-configured timeout value and uses that timeout value if one exists.

2. If the flow matches on a source group, the CSS checks for a user-configured timeout value and uses that timeout value if one exists.

3. If you have configured a permanent port using the flow permanent port command (see the "Configuring Permanent Connections for TCP or UDP Ports" section), the CSS sets the flow timeout value to 0, which means that the flow should never time out.

4. If none of the above conditions are met, then the CSS uses the default timeout value for the protocol type. For more information, see the "Displaying Flow Timeout Statistics" section.

Configuring Flow Timeouts

Use the flow-timeout-multiplier command to specify the number of seconds for which an idle flow can exist before the CSS tears it down. Specify this command in owner-content or group configuration mode.

The syntax for this command is:

flow-timeout-multiplier number

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 We do not recommend that you set the flow-timeout multiplier command to 0 for UDP flows on Layer 3 and Layer 4 content rules. If the value is set to 0, the CSS does not clean up the resources for the UDP flows.


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 5

To 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-timeout

Displaying 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 9-1 shows the fields in the show flow-timeout default command output.

Table 9-1 Field Descriptions for show flow-timeout default Command 

Field
Description

TCP/IP Port

Default TCP or UDP port numbers.

Application

Names of the default TCP or UDP applications.

Inactivity Timeout Seconds

Default flow inactivity timeouts, in seconds, for the TCP or UDP port. If a flow is idle for the amount of time specified in the timeout value, the CSS tears down the flow and reclaims the flow resources.


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 9-2 describes the fields in the show flow-timeout configured command output.

Table 9-2 Field Descriptions for the show flow-timeout configured Command 

Field
Description

Port

TCP or UDP port number.

Content Rule

Name of the content rule for which the flow timeout is configured.

Source Group

Name of the source group for which the flow timeout is configured.

Timeout

Configured inactivity timeout in 16-second increments for the TCP or UDP port. When this time period elapses for an idle flow, the CSS tears down the connection and reclaims the FCBs.


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.

For details on the show rule command and the show group command, refer to the Cisco Content Services Switch Basic Configuration Guide.

Configuring Flow Processing for Fragmented UDP IP Packets

By default, a CSS does not process fragmented 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.

When you enable flow processing for IP fragments, a CSS processes the IP fragments in the flow path using the IP address and UDP port information in the IP and UDP headers. 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.


Note Whenever possible, avoid applications or network configurations that create IP fragments. This feature provides support for those edge conditions where IP fragmentation is unavoidable.


Use this feature to support:

Microsoft Media Server using Microsoft Media Server UDP (MMSU) protocol

Network configurations where UDP IP packets must be fragmented to traverse the network

This section describes how to configure flow processing for fragmented IP UDP packets. It includes the following topics:

What Is IP Packet Fragmentation?

Enabling Flow Processing for Fragmented UDP IP Packets

Configuring the Maximum Assembled Size

Configuring the Minimum Fragment Size

Resetting IP Fragment Statistics

Displaying IP Fragment Statistics

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, such as the CSS.

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 and reassembly, refer to RFC 791 and RFC 815.

Enabling Flow Processing for Fragmented UDP IP Packets


Note This feature supports only IP UDP fragment. Using this feature, the CSS does not process IP TCP fragments and IP fragments from other protocols, but it will continue to route such fragments.



Note This feature performs content rule-based forwarding using the Layer 3 (IP address) and Layer 4 (UDP port) information in the IP and UDP headers. Layer 5 forwarding decisions for IP UDP fragments, based on the packet payload (data), are not supported.


To allow a CSS to flow-process IP UDP fragments, use the ip-fragment-enabled command in global configuration mode. By default, this feature is disabled.

To reset the default behavior of the CSS to forward IP fragments, use the no form of the command.

For example, enter:

(config)# no ip-fragment-enabled

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.

To specify the maximum assembled size, 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 4096

To 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-size

Configuring 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 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 Requiring that the minimum fragment size be at least 64 bytes guarantees that the IP and UDP header information is present in the first fragment.


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-size

Resetting IP Fragment Statistics

To reset the 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.

Displaying IP Fragment Statistics

To display the status, statistics, and error counts associated with IP fragment processing, use the show ip-fragment-stats command in any mode.

Table 9-3 describes the fields for the show ip-fragment-stats command output.

Table 9-3 Field Descriptions for the show ip-fragment-stats Command 

Field
Description
IP Fragment Status

State

Configured state of the IP fragment feature.

Min Fragment Size

Configured minimum fragment IP payload size.

Max Assembled Size

Configured maximum assembled IP packet size.

IP Fragment Statistics

Packets Tracked

Number of fragmented IP packets tracked. This field contains the number of actual packets tracked, not the number of fragments.

Fragments Buffered

Number of buffered IP fragments from all tracked packets.

Packets Completed

Number of successfully processed IP packets that were fragmented.

Longest Frag Chain

Longest IP fragment chain that constituted any one fragmented IP packet. An IP fragment chain is the number of fragments that make up the original packet.

Largest Asm Packet

Largest IP length of an IP fragmented packet that the CSS received.

Smallest Fragment

Smallest fragment IP payload length that the CSS received. This field does not include the last fragment in any IP fragment because its payload can be any size.

IP Fragment Errors

No Tracking Entry

While receiving a fragment of a new packet, the CSS could not obtain a fragment tracking entry. This error can occur if the CSS memory is low or used completely.

Could Not Buffer

CSS received a fragment, but could not buffer it because the CSS was low on buffers.

Duplicate Fragment

CSS detected a duplicate offset or last fragment.

Validating Fragments

After the CSS received all the IP fragments, it attempted to validate the fragments, but found overlapping offsets, short offsets, or other possible denial of service (DoS) fragment attack conditions.

Inserting Fragment

While the CSS was inserting fragments into the fragment chain on the tracking entry, it encountered duplicate fragments, fragments of less than the configured minimum fragment size, or a total assembled size greater than the configured maximum assembled size.

Less Than Min Size

CSS received an IP fragment (not the last fragment) with an IP payload that was less than the configured minimum fragment size.

Max Assembled Size

After the CSS received a fragment, the calculated total length of the assembled IP packet was greater than the configured maximum assembled size.

Collection Timeout

While the CSS was waiting to receive IP fragments, too much time elapsed.

Flow Timeout

After the CSS received all fragments of an IP packet and a fragment was sent to flow processing, the entry timed out before the fragment returned.

IPv4 Header

The CSS received a fragment with an invalid IPv4 header length compared with the total IP fragment size.

RxQueue Full

The CSS flow-processing receive queue for IP fragments was full. The CSS discarded the IP fragments.


Configuring CSS Port Mapping

This section describes how to globally control the range of port numbers a CSS uses to translate (port map) 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.

Each CSS maintains a database of used and available port-map numbers. When a CSS needs to port map a source port, it uses the next unused port number in its database.

For information about port mapping with source groups, refer to the Cisco Content Services Switch Basic Configuration Guide.

This section includes the following topics:

Configuring Global Port Mapping

Displaying Global Port Mapping Statistics

Configuring No-flow Port Mapping

Displaying No-Flow Port Mapping Statistics

Configuring Global Port Mapping

The global port mapper in a CSS is called the mega port mapper. The mega port mapper database comprises 16 banks of port-map numbers (megamap banks) in each session processor (SP) with unique ranges. A CSS uses a source port hash algorithm to select a megamap bank.

Use the global-portmap command to control the global source-port translation (port mapping) for TCP flows on a CSS. This command is always enabled.

You can use this command to specify the source-port mapping range on:

A CSS when you configure a service that uses a nondefault destination port number. A CSS changes a TCP destination port number configured on a service in a content rule when a request hits the content rule and the CSS sends a packet to the selected server. The CSS uses the global-portmap command parameters to translate the corresponding client source port number to distinguish it from other clients requesting the same service.

Redundant Cisco 11500 series CSS peers in an Adaptive Session Redundancy (ASR) configuration. Refer to the Cisco Content Services Switch Advanced Configuration Guide for information about ASR.

A CSS with back-end server remapping enabled (refer to the Cisco Content Services Switch Basic Configuration Guide.

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 as follows:

base-port number1 - The starting port number for global port mapping on a CSS. Enter an integer from 2016 to 63456. The default is 2016.

range number2 - The number of ports in the port-map range. Enter an integer from 2048 to 63488. The default is 63488.


Note If you enter a port-map range that exceeds the number of available ports, you get an error. To determine the number of available ports, subtract the starting port number you specify from 65504.


For example:

(config)# global-portmap base-port 3096 range 42308

To return the global-portmap command parameters to their default values, enter:

(config)# no global-portmap

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

all-banks - Specifies the display of global port-map information for all port-map banks (0 to 15).

all-sps - Specifies the display of global port-map information for all session processors (SPs) in the CSS.

slot number1 - Specifies the chassis slot where the module resides. For a CSS 11503, enter an integer from 1 to 3. For a CSS 11506, enter an integer from 1 to 6.

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

number2 - Specifies the global port-map bank number. Enter an integer from 0 to 15.

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-sps

To display global port mapping statistics for megamap bank 12 in the SP that resides in slot 3, enter:

(config)# show global-portmap 12 slot 3

Table 9-4 describes the fields in the show global-portmap command output.

Table 9-4 Field Descriptions for show global-portmap Command 

Field
Description

MegaMap Banks in Use Per SP

The number of global port mapping banks being used in each session processor (SP). There are 16 banks available in each SP. A CSS selects a bank by hashing the source address contained in a packet.

Configured Base Port

The base-port (starting port number) specified with the global-portmap command or the default of 2016.

Total Configured Ports

The total number of ports specified with the global-portmap range command or the default of 63488.

Slot

The number of the slot in the CSS 11503 or CSS 11506 where the specified SP resides.

MegaMap Bank #

The number of the port mapping bank. Possible values are 0 to 15 for a total of 16 banks for each SP.

Number Normal Avail Ports

The number of ports available for use by the network address translation algorithm when the source port number is different from the destination port number in a TCP packet.

Current Mapped Ports

The total number of ports currently in use or mapped.

Last Normal Mapped Port

The most recent port number used by the network algorithm when the source port number is different from the destination port number in a TCP packet.

Equal Port Base Port

The starting port number that the network address translation algorithm uses when the source port number is the same as the destination port number in a TCP packet.

Number Equal Avail Ports

The number of ports available for use by the network address translation algorithm when the source port number is the same as the destination port number in a TCP packet.

High Water Mark

The largest number of ports mapped or in use at one time since the last CSS reboot.

Last Equal Mapped Port

The last port number used by the network address translation algorithm when the source port number is the same as the destination port number in a TCP packet.

No Portmap Errors

The number of times that a failure occurred because no ports were available (all ports were mapped).


Configuring No-flow Port Mapping

Use the noflow-portmap command to control the port translation (port mapping) range of DNS UDP source-port numbers greater than 1023 on a CSS. 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 Chapter 6, Configuring CSS Network Protocols for details on the dnsflow command.


Note The portmap command values configured in a source group take precedence over the noflow-portmap command values, unless you configure the portmap disable command. Refer to the Cisco Content Services Switch Basic Configuration Guide for details on configuring the portmap commands in a source group.


The syntax for this global configuration mode command is:

noflow-portmap base-port number1 range number2

The options and variables for this command are as follows:

base-port number1 - The starting port number for no-flow (DNS flows are disabled) port mapping on a CSS. Enter an integer from 2016 to 63456. The default is 2016.

range number2 - The number of ports in the port-map range. Enter an integer from 2048 to 63488. The default is 63488.


Note If you enter a value for the port-map range that exceeds the number of available ports, you get an error. To determine the number of available ports, subtract the starting port number from 65504.


For example, to specify a port map range, starting with port 4317, enter:

(config)# noflow-portmap base-port 4317 range 35421

To reset the starting port number and port-map range to their default values, enter:

(config)# no noflow-portmap

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

all-sps - Specifies the display of no-flow port-map information for all session processors (SPs) in the CSS.

slot number - The chassis slot number where the module resides. For a CSS 11503, enter an integer from 1 to 3. For a CSS 11506, enter an integer from 1 to 6.


Note To display the available active slots in the CSS, enter the show noflow-portmap slot ? command. If you enter an invalid slot number, the CLI displays values for only the first two parameters listed in Table 9-5.


For example:

(config)# show noflow-portmap slot 3

Table 9-5 describes the fields in the show noflow-portmap command output.

Table 9-5 Field Descriptions for show noflow-portmap Command 

Field
Description

Configured Base Port

The starting port number specified by the noflow-portmap base-port command or the default of 2016

Total Configured Ports

The total number of ports specified by the noflow-portmap range command or the default of 63488

Slot

The number of the slot in the CSS 11503 or CSS 11506 where the specified SP resides

Number Normal Avail Ports

The number of ports available for use by the network address translation algorithm when the source port number is different from the destination port number in a UDP packet

Current Mapped Ports

The total number of ports currently in use or mapped

Last Normal Mapped Port

The most recent port number used by the network address translation algorithm when the source port number is different from the destination port number in a UDP packet

Equal Port Base Port

The starting port number that the network address translation algorithm uses when the source port number is the same as the destination port number in a UDP packet

Number Equal Avail Ports

The number of ports available for use by the network address translation algorithm when the source port number is the same as the destination port number in a UDP packet

High Water Mark

The largest number of ports mapped or in use at one time since the last CSS reboot.

Last Equal Mapped Port

The last port number used by the network address translation algorithm when the source port number was the same as the destination port number in a UDP packet

No Portmap Errors

The number of times that a failure occurred because no ports were available (all ports were mapped)


Where to Go Next

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