Friday, May 24, 2013

MTU Vs MSS - Part Two

Previously I published a blog post called MTU Vs MSS - Part One. At the time the plan was to follow it up with Part Two a short time later, however, here it comes over a year late :) I do apologise for that.

What prompted me to get back to writing Part Two was an e-mail from a reader who asked how I came to the conclusion that using the "ip tcp adjust-mss" command affects a SYN packet's MSS regardless of whether it is applied to the inbound or outbound interface. The reader also asked if I have any links to documentation that describes this. The way in which I came to the conclusion was by labbing it up. Unfortunately though I do not have any documentation that backs me up.

This blog post will demonstrate the lab I used to come to the above conclusion.

Here is the topology that I used. I have marked each link with a letter to mark the points at which the proceeding packet captures were done. (Note that PC1 and PC2 are GNS3 routers with their icons changed).

No MSS Change

Before making any changes to the MSS, I'll first initiate a telnet session from PC1 to PC2.

Packet Capture from PC1's F0/0 interface ("A"):

Packet Capture from R2's F0/1 interface ("B"):

Looking at the above captures we can see that the PC1 sent an MSS of 536 in its SYN packet, and PC2 responded with an MSS of 536 in its SYN/ACK packet.

R2 F0/0 MSS Change

Now that we've done our benchmark test, let's see what happens when we set an MSS of 500 on R2's F0/0 interface.

R2(config)#int f0/0
R2(config-if)#ip tcp adjust-mss 500

Now let's repeat the telnet test:

Packet Capture from PC1's F0/0 interface ("A"):

Packet Capture from R2's F0/1 interface ("B"):

Here we can see that when the packet leaves PC1, it is sending its SYN packet with an MSS of 536, but when the packet leaves R2, the MSS has changed to 500.

R2 F0/1 MSS Change

Now I'll remove the "ip tcp adjust-mss" command from R2's F0/0 interface and will apply it to R2's F0/1, this time using an MSS of 510.

R2(config)#int f0/1
R2(config-if)#ip tcp adjust-mss 510

Now let's repeat the telnet test:

Packet Capture from PC1's F0/0 interface ("A"):

Packet Capture from R2's F0/1 interface ("B"):

Here we can see the results are the same as the ones seen when the "ip tcp adjust-mss" command was put on R2's F0/0 interface.

MSS on Both Interfaces

As you might expect, if you set the  "ip tcp adjust-mss" command on both of the router's interfaces, it will use the lower of the two.

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.


  1. Arseniy S. Ivanov8:30 PM, May 24, 2013

    Hey, first of all, thanks for the great write up.

    Although, i have the same question or say general concern regarding the mss command changing the value of tcp mss option of the syn packet.

    I've tried to replicate the same behavior in gns lab myself and found routers act all a whole lot differently compared to your results.

    So i got 3 routers:
    Or take a look at the picture of the lab:

    Then take a look at what sent and received TCP packets look like in the Wireshark:

    I would really like to know your opinion about all this.


    Best regards,
    Arseniy S. Ivanov

    1. Hi Arseniy,

      Thank you for the detailed comment and screenshots.

      The reason why we're seeing different results is because the MSS sizes your using (650, 700, 800 and 900) are all higher than the MSS the original host is setting in the SYN packet (536). As mentioned in my post, the lowest MSS will always be chosen, this is why your seeing an MSS of 536 in your captures.

      I suggest you try using lower MSS values such as 500, 510, 520 and 530. Once you do this your findings should match mine.

      Also, for what it's worth, the IOS I am using is: c3725-advipservicesk9-mz.124-4.T8

      Please let me know if you need any more information or have any other questions.

    2. Arseniy S. Ivanov9:07 PM, May 25, 2013

      oh, yes, i see it now, you are right. the only question left is why exactly the initial mss is 536 bytes. I know mtu = 576 (hence mss = 536) is by RFC 879, but why the value is so low? What if i want the initial mss to be higher, because otherwise i'm stuck playing the mss within the range of 500-536, ain't I?

      By the way, I see what my problem was in the initial setup - i tried to apply tcp adjustments to the egress interface of the very left as well as of the very right router on my topology, while ip tcp adjust-mss command affects only transient traffic, while global ip tcp mss command in conjunction with ip tcp path-mtu-discovery is for terminating traffic (, and this is exactly how i can change my initial mss value - i just double checked. And I guess i just answered my own question))

      Thank you a lot for making things clear.
      Have a great day.

    3. "but why the value is so low?"

      Because telnet traffic doesn't need a high MSS. You would need to send/receive a lot of text in order to reach the 536 bytes.

      "i'm stuck playing the mss within the range of 500-536, ain't I?"

      If you're interested in using a wider range of bytes, FTP would be the better option. For example:

      R1#copy flash:

      The above can be used even if the "a.txt" file does not exist and even if FTP is disabled on the remote router. This is because we're only interested in seeing the initial SYN packet. By default, issuing the above command on a router sets the MSS at 1460 bytes.

      The reason for the larger MSS for FTP is because when transferring a file, you're interested in sending the maximum amount of data per packet. This differs from telnet where you're interested in sending small amounts of data as quickly as possible. In this respect, telnet packets can be seen as similar to voice packets.

      "Thank you a lot for making things clear."

      Not a problem at all. I'm glad I could help :)

      You have a great day too.

  2. thanks .. very informative

    1. Not a problem at all :) Thank you for the feedback.

  3. Cisco says That:

  4. Thank you so much, very helpful :)

    1. No problem buddy. Thank you for the comment :)