Most of the time both the commands are used as ingress on the LAN interface at the CE Router.
Need to know why exactly is IP Tcp adjust-mss is used, most of the answers I found were that TCP adjust-mss command is used when we need to avoid fragmentation, how does it affect a frame coming on an interface, how does it change the size of the segment and avoid if from getting fragmented.
I expect an in depth answer at the OSI layers when a frame arrives at the LAN interface and how does adjust-mss command work on that frame and how does ip mtu command work on that frame.
Also i know the difference that ip mtu works only egress and adjust-mss works both ingress and egress.
Many times I have come across, customer complains of application issues and it gets resolved by using the command ip tcp adjust-mss on the incoming interface of PE that connects to the CE or on the incoming LAN interface of CE or on the egress WAN interface of CE that connects to the PE.
Also i need to know what is the best recommended value to be set for ip tcp adjust-mss and where it should be applied as said above.
i don't know what you mean with "an in-depth" answer because indeed there is not much to say about what these commnads are, maybe a little bit more about the mtu discovery mechanisms and mss settings. By the way MTU and MSS are pretty much the same thing wih a quite important difference:
MTU = Layer 2
MSS= Layer 4
ip tcp mss-adjust is a brilliant command because in the moment you coordinate the values of layer two frames and layer four segments you greatly reduce fragmentation that can be a quite big issue considering the environment you are talking about (ISP-MPLS VPN and CE-CE || CE-PE routing).
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
The purpose of tcp mss-adjust is to avoid any packet fragmentation from the initial TCP handshake. If PMTUD is active and working correctly, fragmentation will be detected, but you still take a slight performance hit as packets are rejected then retransmitted; then repeat. (NB: also the older version of PMTUD doesn't inform the sender of the actual MTU and slows the process even more doing trial and error.)
Normally you set the tcp mss-adjust to reduce the normal MSS by whatever your MTU reduction is. So, for example if sending "normal" size Ethernet across a typical GRE tunnel, MTU is 1500 and MSS is 1460, so you subtract 24 (GRE overhead) from MSS and use a setting of 1436. Even smaller might be set to allow for expected, or unexpected, header options.
As to where to set it, best is anywhere along the path where only the necessary traffic will be modified. If you have a router with only such traffic passing through it, you could set on the LAN side or WAN side. However, if the router has multiple interfaces, and might be routing LAN to LAN traffic, then you, ideally, only want to apply command on the necessary WAN interface.
The command only affects TCP traffic, and only TCP during it's initial handshake. If traffic has different paths, with different MTUs, especially if the path selection can vary dynamically, it's possible either traffic won't be adjusted that should be or conversely traffic is adjusted that shouldn't be.
PMTUD should still be used in conjunction with tcp mss-adjust.
Standard L2 and L3 headers are 20 bytes each. So 1500 - 20 - 20 = 1460 (for MSS).
A "gocha", is the standard L2 and L3 headers are 20 bytes each, which means one or both, due to additional L2 or L3 option fields, might be bigger. The sending source will "know" this, but a transit tcp adjust-mss doesn't. This means it's possible TCP packets might be too large when tcp adjust-mss is only configured to MTU less 40.
This document gives several answers on frequently asked questions for PFRv3 channel state behavior.
Q1: What are all the channel operational states from a BR (border role) perspective and what are the rules/conditions to be in each st...
The need was to reach an host inside a LAN through a VPN connection managed by the LAN gateway (Cisco 1921).
The LAN gateway performs NAT and there was a dedicate nat rule for the host i wanted to reach through VPN.
I couldn't connect to the hos...
We have 3 identical switches configured by someone else and would like to claim some of the Gigabit ports(G1/G2/G3/G4) for use on servers. When we try to change the wiring and configuration, we run in to connectivity issues. Attached is a des...