Downloads |
Table Of Contents
TCP Explicit Congestion Notification
TCP Applications Flags Enhancement
Configuring TCP Performance Parameters
Configuring the MSS Value and MTU for Transient TCP SYN Packets
Verifying TCP Performance Parameters
Configuration Examples for TCP
Verifying the Configuration of TCP ECN: Example
Configuring the TCP MSS Adjustment: Examples
Configuring the TCP Application Flags Enhancement: Example
Displaying Addresses in IP Format: Example
Configuring TCP
First Published: October 23, 2006Last Updated: November 19, 2008The Transmission Control Protocol (TCP) is a protocol that specifies the format of data and acknowledgments used in data transfer. TCP is a connection-oriented protocol because participants must establish a connection before data can be transferred. By performing flow control and error correction, TCP guarantees reliable, in-sequence delivery of packets. It is considered a reliable protocol because if an IP packet is dropped or received out of order, TCP will request the correct packet until it receives it.
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Feature Information for TCP" section.
Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
Configuration Examples for TCP
Prerequisites for TCP
TCP Time Stamp, TCP Selective Acknowledgment, and TCP Header Compression
Because TCP time stamps are always sent and echoed in both directions and the time-stamp value in the header is always changing, TCP header compression will not compress the outgoing packet. To allow TCP header compression over a serial link, the TCP time-stamp option is disabled. If you want to use TCP header compression over a serial line, TCP time stamp and TCP selective acknowledgment must be disabled. Both features are disabled by default. Use the no ip tcp selective-ack command to disable TCP selective acknowledgment once it is enabled.
Information About TCP
To configure TCP, you should understand the following concepts:
•
•
TCP Services
TCP provides reliable transmission of data in an IP environment. TCP corresponds to the transport layer (Layer 4) of the OSI reference model. Among the services TCP provides are stream data transfer, reliability, efficient flow control, full-duplex operation, and multiplexing.
With stream data transfer, TCP delivers an unstructured stream of bytes identified by sequence numbers. This service benefits applications because they do not have to chop data into blocks before handing it off to TCP. Instead, TCP groups bytes into segments and passes them to IP for delivery.
TCP offers reliability by providing connection-oriented, end-to-end reliable packet delivery through an internetwork. It does this by sequencing bytes with a forwarding acknowledgment number that indicates to the destination the next byte the source expects to receive. Bytes not acknowledged within a specified time period are retransmitted. The reliability mechanism of TCP allows devices to deal with lost, delayed, duplicate, or misread packets. A time-out mechanism allows devices to detect lost packets and request retransmission.
TCP offers efficient flow control, which means that, when sending acknowledgments back to the source, the receiving TCP process indicates the highest sequence number it can receive without overflowing its internal buffers.
TCP offers full-duplex operation and TCP processes can both send and receive at the same time.
TCP multiplexing allows numerous simultaneous upper-layer conversations to be multiplexed over a single connection.
TCP Connection Establishment
To use reliable transport services, TCP hosts must establish a connection-oriented session with one another. Connection establishment is performed by using a "three-way handshake" mechanism.
A three-way handshake synchronizes both ends of a connection by allowing both sides to agree upon initial sequence numbers. This mechanism also guarantees that both sides are ready to transmit data and know that the other side is ready to transmit as well. The three-way handshake is necessary so that packets are not transmitted or retransmitted during session establishment or after session termination.
Each host randomly chooses a sequence number used to track bytes within the stream it is sending. Then, the three-way handshake proceeds in the following manner:
•
•
•
TCP Connection Attempt Time
You can set the amount of time the Cisco IOS software will wait to attempt to establish a TCP connection. Because the connection attempt time is a host parameter, it does not pertain to traffic going through the device, just to traffic originated at the device. To set the TCP connection attempt time, use the ip tcp synwait-time command in global configuration mode. The default is 30 seconds.
TCP Selective Acknowledgment
The TCP Selective Acknowledgment feature improves performance in the event that multiple packets are lost from one TCP window of data.
Prior to this feature, with the limited information available from cumulative acknowledgments, a TCP sender could learn about only one lost packet per round-trip time. An aggressive sender could choose to resend packets early, but such resent segments might have already been successfully received.
The TCP selective acknowledgment mechanism helps improve performance. The receiving TCP host returns selective acknowledgment packets to the sender, informing the sender of data that have been received. In other words, the receiver can acknowledge packets received out of order. The sender can then resend only the missing data segments (instead of everything since the first missing packet).
Prior to selective acknowledgment, if TCP lost packets 4 and 7 out of an 8-packet window, TCP would receive acknowledgment of only packets 1, 2, and 3. Packets 4 through 8 would need to be resent. With selective acknowledgment, TCP receives acknowledgment of packets 1, 2, 3, 5, 6, and 8. Only packets 4 and 7 must be resent.
TCP selective acknowledgment is used only when multiple packets are dropped within one TCP window. There is no performance impact when the feature is enabled but not used. Use the ip tcp selective-ack command in global configuration mode to enable TCP selective acknowledgment.
Refer to RFC 2018 for more detailed information about TCP selective acknowledgment.
TCP Time Stamp
The TCP time-stamp option provides better TCP round-trip time measurements. Because the time stamps are always sent and echoed in both directions and the time-stamp value in the header is always changing, TCP header compression will not compress the outgoing packet. To allow TCP header compression over a serial link, the TCP time-stamp option is disabled. Use the ip tcp timestamp command to enable the TCP time-stamp option.
Refer to RFC 1323 for more detailed information on TCP time stamp. Refer to the "Configuring TCP Header Compression" chapter of the Cisco IOS Quality of Service Solutions Configuration Guide for more information about TCP header compression.
TCP Maximum Read Size
The maximum number of characters that TCP reads from the input queue for Telnet and rlogin at one time is a very large number (the largest possible 32-bit positive number) by default. To change the TCP maximum read size value, use the ip tcp chunk-size command in global configuration mode.
We do not recommend that you change this value.
TCP Path MTU Discovery
Path MTU Discovery is a method for maximizing the use of available bandwidth in the network between the endpoints of a TCP connection, which is described in RFC 1191. IP Path MTU Discovery allows a host to dynamically discover and cope with differences in the maximum allowable maximum transmission unit (MTU) size of the various links along the path. Sometimes a router is unable to forward a datagram because it requires fragmentation (the packet is larger than the MTU you set for the interface with the interface configuration command), but the "don't fragment" (DF) bit is set. The intermediate gateway sends a "Fragmentation needed and DF bit set" ICMP message to the sending host, alerting it to the problem. Upon receiving this ICMP message, the host reduces its assumed path MTU and consequently sends a smaller packet that will fit the smallest packet size of all the links along the path.
By default, TCP Path MTU Discovery is disabled. Existing connections are not affected when this feature is enabled or disabled.
Customers using TCP connections to move bulk data between systems on distinct subnets would benefit most by enabling this feature. Customers using remote source-route bridging (RSRB) with TCP encapsulation, serial tunnel (STUN), X.25 Remote Switching (also known as XOT or X.25 over TCP), and some protocol translation configurations might also benefit from enabling this feature.
Use the ip tcp path-mtu-discovery global configuration command to enable Path MTU Discovery for connections initiated by the router when it is acting as a host.
For more information about Path MTU Discovery, refer to the "Configuring IP Services" chapter of the Cisco IOS IP Application Services Configuration Guide.
TCP Window Scaling
The TCP Window Scaling feature adds support for the Window Scaling option in RFC 1323. A larger window size is recommended to improve TCP performance in network paths with large bandwidth-delay product characteristics that are called Long Fat Networks (LFNs). The TCP Window Scaling enhancement provides that support.
The window scaling extension in Cisco IOS software 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. The window size can increase to a scale factor of 14. Typical applications use a scale factor of 3 when deployed in LFNs.
The TCP Window Scaling feature complies with RFC 1323, TCP Extensions for High Performance. The maximum window size has been increased to 1,073,741,823 bytes. The larger scalable window size will allow TCP to perform better over LFNs. Use the ip tcp window-size command in global configuration mode to configure the TCP window size.
TCP Sliding Window
A TCP sliding window provides more efficient use of network bandwidth because it enables hosts to send multiple bytes or packets before waiting for an acknowledgment.
In TCP, the receiver specifies the current window size in every packet. Because TCP provides a byte-stream connection, window sizes are expressed in bytes. A window is the number of data bytes that the sender is allowed to send before waiting for an acknowledgment. Initial window sizes are indicated at connection setup, but might vary throughout the data transfer to provide flow control. A window size of zero means "Send no data." The default TCP window size is 4128 bytes. We recommend you keep the default value unless you know your router is sending large packets (greater than 536 bytes). Use the ip tcp window-size command to change the default window size.
In a TCP sliding-window operation, for example, the sender might have a sequence of bytes to send (numbered 1 to 10) to a receiver who has a window size of five. The sender then places a window around the first five bytes and transmits them together. The sender then waits for an acknowledgment.
The receiver responds with an ACK = 6, indicating that it has received bytes 1 to 5 and is expecting byte 6 next. In the same packet, the receiver indicates that its window size is 5. The sender then moves the sliding window five bytes to the right and transmit bytes 6 to 10. The receiver responds with an ACK = 11, indicating that it is expecting sequenced byte 11 next. In this packet, the receiver might indicate that its window size is 0 (because, for example, its internal buffers are full). At this point, the sender cannot send any more bytes until the receiver sends another packet with a window size greater than 0.
TCP Outgoing Queue Size
The default TCP outgoing queue size per connection is 5 segments if the connection has a TTY associated with it (such as a Telnet connection). If no TTY connection is associated with a connection, the default queue size is 20 segments. Use the ip tcp queuemax command to change the 5-segment default value.
TCP Congestion Avoidance
The TCP Congestion Avoidance feature enables the monitoring of acknowledgment packets to the TCP sender when multiple packets are lost in a single window of data. Previously the sender would exit Fast-Recovery mode, wait for three or more duplicate acknowledgment packets before retransmitting the next unacknowledged packet, or wait for the retransmission timer to slow start. This could lead to performance issues.
Implementation of RFC 2581 and RFC 3782 addresses the modifications to the Fast-Recovery algorithm that incorporates a response to partial acknowledgments received during Fast Recovery, improving performance in situations where multiple packets are lost in a single window of data.
This feature is an enhancement to the existing Fast Recovery algorithm. There are no commands used to enable or disable this feature.
To monitor the acknowledgment packets, the output of the debug ip tcp transactions command has been enhanced to show the following conditions:
•
•
•
TCP Explicit Congestion Notification
The TCP Explicit Congestion Notification (ECN) feature provides a method for an intermediate router to notify the end hosts of impending network congestion. It also provides enhanced support for TCP sessions associated with applications that are sensitive to delay or packet loss including Telnet, web browsing, and transfer of audio and video data. The benefit of this feature is the reduction of delay and packet loss in data transmissions. Use the ip tcp ecn command in global configuration mode to enable TCP ECN.
TCP MSS Adjustment
The TCP MSS Adjustment feature enables the configuration of the maximum segment size (MSS) for transient packets that traverse a router, specifically TCP segments with the SYN bit set. Use the ip tcp adjust-mss command in interface configuration mode to specify the MSS value on the intermediate router of the SYN packets to avoid truncation.
When a host (usually a PC) initiates a TCP session with a server, it negotiates the IP segment size by using the MSS option field in the TCP SYN packet. The value of the MSS field is determined by the maximum transmission unit (MTU) configuration on the host. The default MSS value for a PC is 1500 bytes.
The PPP over Ethernet (PPPoE) standard supports a MTU of only 1492 bytes. The disparity between the host and PPPoE MTU size can cause the router in between the host and the server to drop 1500-byte packets and terminate TCP sessions over the PPPoE network. Even if the path MTU (which detects the correct MTU across the path) is enabled on the host, sessions may be dropped because system administrators sometimes disable the ICMP error messages that must be relayed from the host in order for path MTU to work.
The ip tcp adjust-mss command helps prevent TCP sessions from being dropped by adjusting the MSS value of the TCP SYN packets.
The ip tcp adjust-mss command is effective only for TCP connections passing through the router.
In most cases, the optimum value for the max-segment-size argument of the ip tcp adjust-mss command is 1452 bytes. This value plus the 20-byte IP header, the 20-byte TCP header, and the 8-byte PPPoE header add up to a 1500-byte packet that matches the MTU size for the Ethernet link.
See the "Configuring the MSS Value and MTU for Transient TCP SYN Packets" section for configuration instructions.
TCP Applications Flags Enhancement
The TCP Applications Flags Enhancement feature enables the user to display additional flags with reference to TCP applications. There are two types of flags: status and option. The status flags indicate the status of TCP connections such as retransmission timeouts, application closed, and synchronized (SYNC) handshakes for listen. The additional flags indicate the state of set options such as whether or not a virtual private network (VPN) routing and forwarding (VRF) instance is set, whether or not a user is idle, and whether or not a keepalive timer is running. Use the show tcp command to display TCP application flags.
TCP Show Extension
The TCP Show Extension feature introduces the capability to display addresses in IP format instead of hostname format and to display the virtual private network (VPN) routing and forwarding (VRF) table associated with the connection. To display the status for all endpoints with the addresses in IP format, use the show tcp brief numeric command.
How to Configure TCP
This section contains the following procedures:
•
•
•
Configuring TCP Performance Parameters
Perform the following task to configure TCP performance parameters.
Prerequisites
•
•
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
DETAILED STEPS
Configuring the MSS Value and MTU for Transient TCP SYN Packets
Perform this task to configure the maximum segment size (MSS) for transient packets that traverse a router, specifically TCP segments with the SYN bit set, and to configure the MTU size of IP packets.
If you are configuring the ip mtu command on the same interface as the ip tcp adjust-mss command, we recommend that you use the following commands and values:
•
•
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Verifying TCP Performance Parameters
This task shows you how to verify configured TCP performance parameters.
SUMMARY STEPS
1.
2.
3.
DETAILED STEPS
Step 1
Displays the status of TCP connections. The arguments and keyword are as follows:
•
•
•
The following is sample output from the show tcp tcb command that displays detailed information by hexadecimal address about an ECN-enabled connection:
Router# show tcp tcb 0x62CD2BB8Connection state is LISTEN, I/O status: 1, unread input bytes: 0Connection is ECN enabledLocal host: 10.10.10.1, Local port: 179Foreign host: 10.10.10.2, Foreign port: 12000Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)Event Timers (current time is 0x4F31940):Timer Starts Wakeups NextRetrans 0 0 0x0TimeWait 0 0 0x0AckHold 0 0 0x0SendWnd 0 0 0x0KeepAlive 0 0 0x0GiveUp 0 0 0x0PmtuAger 0 0 0x0DeadWait 0 0 0x0iss: 0 snduna: 0 sndnxt: 0 sndwnd: 0irs: 0 rcvnxt: 0 rcvwnd: 4128 delrcvwnd: 0SRTT: 0 ms, RTTO: 2000 ms, RTV: 2000 ms, KRTT: 0 msminRTT: 60000 ms, maxRTT: 0 ms, ACK hold: 200 msFlags: passive open, higher precedence, retransmission timeoutTCB is waiting for TCP Process (67)Datagrams (max data segment is 516 bytes):Rcvd: 6 (out of order: 0), with data: 0, total data bytes: 0Sent: 0 (retransmit: 0, fastretransmit: 0), with data: 0, total databytes: 0Cisco IOS Software Modularity
The following is sample output from the show tcp tcb command from a Software Modularity image:
Router# show tcp tcb 0x1059C10Connection state is ESTAB, I/O status: 0, unread input bytes: 0Local host: 10.4.2.32, Local port: 23Foreign host: 10.4.2.39, Foreign port: 11000VRF table id is: 0Current send queue size: 0 (max 65536)Current receive queue size: 0 (max 32768) mis-ordered: 0 bytesEvent Timers (current time is 0xB9ACB9):Timer Starts Wakeups Next(msec)Retrans 6 0 0SendWnd 0 0 0TimeWait 0 0 0AckHold 8 4 0KeepAlive 11 0 7199992PmtuAger 0 0 0GiveUp 0 0 0Throttle 0 0 0irs: 1633857851 rcvnxt: 1633857890 rcvadv: 1633890620 rcvwnd: 32730iss: 4231531315 snduna: 4231531392 sndnxt: 4231531392 sndwnd: 4052sndmax: 4231531392 sndcwnd: 10220SRTT: 84 ms, RTTO: 650 ms, RTV: 69 ms, KRTT: 0 msminRTT: 0 ms, maxRTT: 200 ms, ACK hold: 200 msKeepalive time: 7200 sec, SYN wait time: 75 secGiveup time: 0 ms, Retransmission retries: 0, Retransmit forever: FALSEState flags: noneFeature flags: NagleRequest flags: noneWindow scales: rcv 0, snd 0, request rcv 0, request snd 0Timestamp option: recent 0, recent age 0, last ACK sent 0Datagrams (in bytes): MSS 1460, peer MSS 1460, min MSS 1460, max MSS 1460Rcvd: 14 (out of order: 0), with data: 10, total data bytes: 38Sent: 10 (retransmit: 0, fastretransmit: 0), with data: 5, total data bytes: 76Header prediction hit rate: 72 %Socket states: SS_ISCONNECTED, SS_PRIVRead buffer flags: SB_WAIT, SB_SEL, SB_DEL_WAKEUPRead notifications: 4Write buffer flags: SB_DEL_WAKEUPWrite notifications: 0Socket status: 0Step 2
(Optional) Displays addresses in IP format.
Use the show tcp brief command to display a concise description of TCP connection endpoints. The keywords are as follows. Use the optional all keyword to display the status for all endpoints with the addresses in a Domain Name System (DNS) hostname format. Without this keyword, endpoints in the LISTEN state are not shown. Use the optional numeric keyword to display the status for all endpoints with the addresses in IP format.
The following is sample output from the show tcp brief command while a user is connected to the system by using Telnet:
Router# show tcp briefTCB Local Address Foreign Address (state)609789AC Router.cisco.com.23 cider.cisco.com.3733 ESTABThe following example shows the IP activity by using the numeric keyword to display the addresses in IP format.
Router# show tcp brief numericTCB Local Address Foreign Address (state)6523A4FC 10.1.25.3.11000 10.1.25.3.23 ESTAB65239A84 10.1.25.3.23 10.1.25.3.11000 ESTAB653FCBBC *.1723 *.* LISTENStep 3
Use the debug ip tcp transactions command to display information about significant TCP transactions such as state changes, retransmissions, and duplicate packets. This command is particularly useful for debugging a performance problem on a TCP/IP network that you have isolated above the data-link layer.
The following is sample output from the debug ip tcp transactions command:
Router# debug ip tcp transactionsTCP: sending SYN, seq 168108, ack 88655553TCP0: Connection to 10.9.0.13:22530, advertising MSS 966TCP0: state was LISTEN -> SYNRCVD [23 -> 10.9.0.13(22530)]TCP0: state was SYNSENT -> SYNRCVD [23 -> 10.9.0.13(22530)]TCP0: Connection to 10.9.0.13:22530, received MSS 956TCP0: restart retransmission in 5996TCP0: state was SYNRCVD -> ESTAB [23 -> 10.9.0.13(22530)]TCP2: restart retransmission in 10689TCP2: restart retransmission in 10641TCP2: restart retransmission in 10633TCP2: restart retransmission in 13384 -> 10.0.0.13(16151)]TCP0: restart retransmission in 5996 [23 -> 10.0.0.13(16151)]The following line from the debug ip tcp transactions command output shows that TCP has entered Fast Recovery mode:
fast re-transmit - sndcwnd - 512, snd_last - 33884268765The following lines from the debug ip tcp transactions command output show that a duplicate acknowledgment is received when in Fast Recovery mode (first line) and a partial acknowledgment has been received (second line):
TCP0:ignoring second congestion in same window sndcwn - 512, snd_1st - 33884268765TCP0:partial ACK received sndcwnd:338842495Configuration Examples for TCP
This section provides the following configuration examples:
•
•
•
•
Verifying the Configuration of TCP ECN: Example
The following example shows how to verify that ECN is configured:
Router# show running-configBuilding configuration......ip tcp ecn ! ECN is configured....The following example shows how to verify that TCP is ECN enabled on a specific connection (local host):
Router# show tcp tcb 123456A!Local host!Connection state is ESTAB, I/O status: 1, unread input bytes: 0Connection is ECN EnabledLocal host: 10.1.25.31, Local port: 11002Foreign host: 10.1.25.34, Foreign port: 23The following example shows how to display concise information about one address:
Router# show tcp brief!TCB Local address Foreign Address (state)609789C Router.cisco.com.23 cider.cisco.com.3733 ESTABThe following example show how to enable IP TCP ECN debugging:
Router# debug ip tcp ecn!TCP ECN debugging is on!Router# telnet 10.1.25.31Trying 10.1.25.31 ...!01:43:19: 10.1.25.35:11000 <---> 10.1.25.31:23 out ECN-setup SYN01:43:21: 10.1.25.35:11000 <---> 10.1.25.31:23 congestion window changes01:43:21: cwnd from 1460 to 1460, ssthresh from 65535 to 292001:43:21: 10.1.25.35:11000 <---> 10.1.25.31:23 in non-ECN-setup SYN-ACKBefore a TCP connection can use ECN, a host sends an ECN-setup SYN (synchronization) packet to a remote end that contains an Echo Congestion Experience (ECE) and Congestion window reduced (CWR) bit set in the header. Setting the ECE and CWR bits indicates to the remote end that the sending TCP is ECN capable, rather than an indication of congestion. The remote end sends an ECN-setup SYN-ACK (acknowledgment) packet to the sending host.
In the example above, the "out ECN-setup SYN" text means that a SYN packet with the ECE and CWR bit set was sent to the remote end. The "in non-ECN-setup SYN-ACK" text means that the remote end did not favorably acknowledge the ECN request and, therefore, the session is not ECN capable.
The following debug output shows that ECN capabilities are enabled at both ends. In response to the ECN-setup SYN, the other end favorably replied with an ECN-setup SYN-ACK message. This connection is now ECN capable for the rest of the session.
Router# telnet 10.10.10.10Trying 10.10.10.10 ... OpenPassword required, but none set!1d20h: 10.1.25.34:11003 <---> 10.1.25.35:23 out ECN-setup SYN1d20h: 10.1.25.34:11003 <---> 10.1.25.35:23 in ECN-setup SYN-ACKThe following example shows how to verify that the hosts are connected:
Router# show debugging!TCP:TCP Packet debugging is onTCP ECN debugging is on!Router# telnet 10.1.25.234!Trying 10.1.25.234 ...!00:02:48: 10.1.25.31:11001 <---> 10.1.25.234:23 out ECN-setup SYN00:02:48: tcp0: O CLOSED 10.1.25.234:11001 10.1.25.31:23 seq 1922220018OPTS 4 ECE CWR SYN WIN 412800:02:50: 10.1.25.31:11001 <---> 10.1.25.234:23 congestion window changes00:02:50: cwnd from 1460 to 1460, ssthresh from 65535 to 292000:02:50: tcp0: R SYNSENT 10.1.25.234:11001 10.1.25.31:23 seq 1922220018OPTS 4 ECE CWR SYN WIN 412800:02:54: 10.1.25.31:11001 <---> 10.1.25.234:23 congestion window changes00:02:54: cwnd from 1460 to 1460, ssthresh from 2920 to 292000:02:54: tcp0: R SYNSENT 10.1.25.234:11001 10.1.25.31:23 seq 1922220018OPTS 4 ECE CWR SYN WIN 412800:03:02: 10.1.25.31:11001 <---> 10.1.25.234:23 congestion window changes00:03:02: cwnd from 1460 to 1460, ssthresh from 2920 to 292000:03:02: tcp0: R SYNSENT 10.1.25.234:11001 10.1.25.31:23 seq 1922220018OPTS 4 ECE CWR SYN WIN 412800:03:18: 10.1.25.31:11001 <---> 10.1.25.234:23 SYN with ECN disabled00:03:18: 10.1.25.31:11001 <---> 10.1.25.234:23 congestion window changes00:03:18: cwnd from 1460 to 1460, ssthresh from 2920 to 292000:03:18: tcp0: O SYNSENT 10.1.25.234:11001 10.1.25.31:23 seq 1922220018OPTS 4 SYN WIN 412800:03:20: 10.1.25.31:11001 <---> 10.1.25.234:23 congestion window changes00:03:20: cwnd from 1460 to 1460, ssthresh from 2920 to 292000:03:20: tcp0: R SYNSENT 10.1.25.234:11001 10.1.25.31:23 seq 1922220018OPTS 4 SYN WIN 412800:03:24: 10.1.25.31:11001 <---> 10.1.25.234:23 congestion window changes00:03:24: cwnd from 1460 to 1460, ssthresh from 2920 to 292000:03:24: tcp0: R SYNSENT 10.1.25.234:11001 10.1.25.31:23 seq 1922220018OPTS 4 SYN WIN 412800:03:32: 10.1.25.31:11001 <---> 10.1.25.234:23 congestion window changes00:03:32: cwnd from 1460 to 1460, ssthresh from 2920 to 292000:03:32: tcp0: R SYNSENT 10.1.25.234:11001 10.1.25.31:23 seq 1922220018OPTS 4 SYN WIN 4128!Connection timed out; remote host not respondingConfiguring the TCP MSS Adjustment: Examples
Figure 1 Example Topology for TCP MSS Adjustment
The following example shows how to configure and verify the interface adjustment value. Configure the interface adjustment value on router B:
Router_B(config)# interface ethernet2/0Router_B(config-if)# ip tcp adjust-mss 500Telnet from router A to router C, with B having the MSS adjustment configured.
Router_A# telnet 192.168.1.1Trying 192.168.1.1... OpenObserve the debug output from router C:
Router_C# debug ip tcp transactionsSep 5 18:42:46.247: TCP0: state was LISTEN -> SYNRCVD [23 -> 10.0.1.1(38437)]Sep 5 18:42:46.247: TCP: tcb 32290C0 connection to 10.0.1.1:38437, peer MSS 500, MSS is 500Sep 5 18:42:46.247: TCP: sending SYN, seq 580539401, ack 6015751Sep 5 18:42:46.247: TCP0: Connection to 10.0.1.1:38437, advertising MSS 500Sep 5 18:42:46.251: TCP0: state was SYNRCVD -> ESTAB [23 -> 10.0.1.1(38437)]The MSS gets adjusted to 500 on Router_B as configured.
The following example shows the configuration of a PPPoE client with the MSS value set to 1452:
vpdn enableno vpdn logging!vpdn-group 1request-dialinprotocol pppoe!interface Ethernet0ip address 192.168.100.1.255.255.255.0ip tcp adjust-mss 1452ip nat inside!interface ATM0no ip addressno atm ilmi-keepalivepvc 8/35pppoe client dial-pool-number 1!dsl equipment-type CPEdsl operating-mode GSHDSL symmetric annex Bdsl linerate AUTO!interface Dialer1ip address negotiatedip mtu 1492ip nat outsideencapsulation pppdialer pool 1dialer-group 1ppp authentication pap callinppp pap sent-username sohodyn password 7 141B1309000528!ip nat inside source list 101 Dialer1 overloadip route 0.0.0.0.0.0.0.0 Dialer1access-list permit ip 192.168.100.0.0.0.0.255 anyConfiguring the TCP Application Flags Enhancement: Example
The following output shows the flags (status and option) displayed using the show tcp command.
Router# show tcp...Status Flags: passive open, active open, retransmission timeoutApp closedOption Flags: vrf id setIP Precedence value: 6...SRTT: 273 ms, RTTO: 490 ms, RTV: 217 ms, KRTT: 0 msminRTT: 0 ms, maxRTT: 300 ms, ACK hold: 200 msDisplaying Addresses in IP Format: Example
The following example shows the IP activity by using the numeric keyword to display the addresses in IP format.
Router# show tcp brief numericTCB Local Address Foreign Address (state)6523A4FC 10.1.25.3.11000 10.1.25.3.23 ESTAB65239A84 10.1.25.3.23 10.1.25.3.11000 ESTAB653FCBBC *.1723 *.* LISTENAdditional References
The following sections provide references related to TCP.
Related Documents
IP addressing and services configuration tasks
Cisco IOS IP Addressing and Services Configuration Guide
IP application services commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples
Path MTU Discovery
TCP security features
TCP Out-of-Order Packet Support for Cisco IOS Firewall and Cisco IOS IPS
Configuring TCP Intercept (Preventing Denial-of-Service Attacks)
TCP Header Compression,
Class-based TCP Header CompressionConfiguring Class-Based RTP and TCP Header Compression
Troubleshooting TCP
"Troubleshooting TCP/IP" part of the Internetwork Troubleshooting Handbook
Standards
No new or modified standards are supported, and support for existing standards has not been modified.
—
MIBs
CISCO-TCP-MIB
To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:
RFCs
RFC 793
RFC 1191
RFC 1323
RFC 2018
RFC 2581
RFC 3168
The Addition of Explicit Congestion Notification (ECN) to IP
RFC 3782
RFC 4022
Management Information Base for the Transmission Control Protocol (TCP)
Technical Assistance
Feature Information for TCP
Table 1 lists the features in this module and provides links to specific configuration information. Only features that were introduced or modified in Cisco IOS Release 12.2(1) or a later release appear in the table.
For information on a feature in this technology that is not documented here, see the "Cisco IOS IP Application Services Features Roadmap" or the "FHRP Features Roadmap."
Not all commands may be available in your Cisco IOS software release. For release information about a specific command, see the command reference documentation.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which Cisco IOS and Catalyst OS software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note
Table 1 Feature Information for TCP
TCP Application Flags Enhancement
12.4(2)T,
12.2(31)SB2
Cisco IOSThe TCP Applications Flags Enhancement feature enables the user to display additional flags with reference to TCP applications. There are two types of flags: status and option. The status flags indicate the status of TCP connections; for example, retransmission timeouts, application closed, and synchronized (SYNC) handshakes for listen. The additional flags indicate the state of set options; for example, whether or not a virtual private network (VPN) routing and forwarding (VRF) identification is set, whether or not a user is idle, and whether or not a keepalive timer is running.
The following sections contain information about this feature:
•
•
•
The following command was modified by this feature: show tcp.
TCP Congestion Avoidance
12.3(7)T
The TCP Congestion Avoidance feature enables the monitoring of acknowledgment packets to the TCP sender when multiple packets are lost in a single window of data. Previously the sender would exit Fast-Recovery mode, wait for three or more duplicate acknowledgment packets before retransmitting the next unacknowledged packet, or wait for the retransmission timer to slow start. This could lead to performance issues.
Implementation of RFC 2581 and RFC 3782 addresses the modifications to the Fast-Recovery algorithm that incorporates a response to partial acknowledgments received during Fast Recovery, improving performance in situations where multiple packets are lost in a single window of data.
This feature is an enhancement to the existing Fast Recovery algorithm. There are no commands used to enable or disable this feature.
To monitor the acknowledgment packets, the output of the debug ip tcp transactions command has been enhanced to show the following conditions:
•
•
•
The following sections provide information about this feature:
•
The following command was modified by this feature: debug ip tcp transactions.
TCP Explicit Congestion Notification
12.3(7)T
12.2(31)SB2The TCP Explicit Congestion Notification (ECN) feature provides a method for an intermediate router to notify the end hosts of impending network congestion. It also provides enhanced support for TCP sessions associated with applications that are sensitive to delay or packet loss including Telnet, web browsing, and transfer of audio and video data. The benefit of this feature is the reduction of delay and packet loss in data transmissions.
The following sections provide information about this feature:
•
•
•
•
The following commands were introduced or modified by this feature: debug ip tcp ecn, ip tcp ecn, show debugging, show tcp.
TCP MSS Adjust
12.2(4)T
12.2(8)T
12.2(28)SB
12.2(33)SRA
12.2(18)ZU2
12.2(33)SXHThe TCP MSS Adjust feature enables the configuration of the maximum segment size (MSS) for transient packets that traverse a router, specifically TCP segments in the SYN bit set.
In 12.2(4)T, this feature was introduced.
In 12.2(8)T, the command that was introduced by this feature was changed from ip adjust-mss to ip tcp adjust-mss.
In 12.2(28)SB and 12.2(33)SRA, this feature was enhanced to be configurable on subinterfaces.
The following sections provide information about this feature:
•
•
The following command was introduced by this feature: ip tcp adjust-mss.
TCP Show Extension
12.4(2)T
12.2(31)SB2The TCP Show Extension feature introduces the capability to display addresses in IP format instead of hostname format and to display the virtual private network (VPN) routing and forwarding (VRF) table associated with the connection.
The following sections contain information about this feature:
•
•
The following command was modified by this feature: show tcp brief.
TCP Window Scaling
12.2(8)T
12.2(31)SB2The TCP Window Scaling feature adds support for the Window Scaling option in RFC 1323. A larger window size is recommended to improve TCP performance in network paths with large bandwidth, long-delay characteristics that are called Long Fat Networks (LFNs). This TCP Window Scaling enhancement provides that support.
The following sections provide information about this feature:
•
•
The following commands were introduced or modified by this feature: ip tcp window-size.
Glossary
LFN—Long Fat Networks. Large bandwidth, long-delay networks where the throughput is high and the transmission distance is long. Networks with satellite connections are one example of an LFN. Satellite links always have high propagation delays and typically have high bandwidth.
TCP—Transmission Control Protocol. Connection-oriented transport layer protocol that provides reliable full-duplex data transmission. TCP is part of the TCP/IP protocol stack.
CCDE, CCSI, CCENT, Cisco Eos, Cisco HealthPresence, the Cisco logo, Cisco Lumin, Cisco Nexus, Cisco Nurse Connect, Cisco Stackpower, Cisco StadiumVision, Cisco TelePresence, Cisco WebEx, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn and Cisco Store are service marks; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0903R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
© 2008 Cisco Systems, Inc. All rights reserved.
