[c-nsp] ip tcp adjust-mss

[Methsri Wickramarathna]

I have captured and analyzed the packets from wireshark and it shows MSS
agreement is set to 1460. Is there any convenient way to track the buggy
device ???


On Tue, Nov 5, 2013 at 10:39 AM, Octavio Alvarez
<alvarezp at alvarezp.ods.org>wrote:

> It could be anywhere.
>
> I remember seeing buggy devices that didn't dynamically adapt to
> intermediate TCP MSS modifications. We had to analyze the TCP headers on
> the streams to find this out. It was a reflected symptom.
>
> I've also seen it on DSL links that didn't had "ip tcp adjust-mss 1452"
> in place.
>
>
>
> On 11/04/2013 08:09 PM, Methsri Wickramarathna wrote:
> > Thanks Blake & Tony,
> >
> > Is this issue with My end core router , destination end device or
> > intermediate device ???
> >
> > Is there any way I can find this ???
> >
> >
> >
> > On Tue, Nov 5, 2013 at 7:22 AM, Blake Dunlap <ikiris at gmail.com> wrote:
> >
> >> Yes. Don't do that.
> >>
> >>
> >> On Mon, Nov 4, 2013 at 6:59 PM, Methsri Wickramarathna <
> >> mmethw2003 at gmail.com> wrote:
> >>
> >>> Thanks Tony , John and Juergan...
> >>>
> >>> This has been issue for many sites mainly towards yahoo.com. Can any
> one
> >>> explain why this is happening for particular IPs in a subnet ???
> >>> We are using access list inbound & Outbound to prevent ICMPs cumming
> >>> inside
> >>> to our network, will it be creating this problem ????
> >>>
> >>>
> >>> On Tue, Nov 5, 2013 at 3:23 AM, <cnsp at marenda.net> wrote:
> >>>
> >>>> Hi, this looks like a CPE-device
> >>>> With static IP-adresses and routing.
> >>>>
> >>>> You may really want to set "ip tcp adjust-mss 1280"
> >>>> on _both_ your WAN and your (probably natted) LAN (L3) Interfaces.
> >>>> (_both_ sides, yes !)
> >>>>
> >>>> This will help you in most cases with
> >>>> MTU restrictions on
> >>>> - your link
> >>>> - home-"web"servers behind Broadband links
> >>>> etc.
> >>>>
> >>>> Yes, the value is not optimized but very computerish ( 2**10 + 2**8 ),
> >>>> but it is good for
> >>>> - pppoe (1500-8=1492)
> >>>> - l2tp forwarded dial-in sessions (l2tp overhead+pppoe leads to 1456)
> >>>> - even with an additional vlan tag ( so MTU will be 1452 found in most
> >>>> literature)
> >>>> - some other tunneled environments
> >>>>
> >>>> Iff you are an ISP,
> >>>> you will configure this _only_ on the virtual-template interfaces
> >>>> on your LNSes for broadband-termination .
> >>>>
> >>>> Keep it out of your core,
> >>>> You will not want to modify your valued customer's ip packets
> >>>> in your core network; here you want to use a MTU greater than 1500
> >>>> while on your BGP up/downstreams will stay at Ethernet-default 1500 .
> >>>>
> >>>> Sorry, very conservative, but will avoid may problems.
> >>>>
> >>>> Just my 0.01 $ on this
> >>>>
> >>>> Juergen.
> >>>>
> >>>>> -----Ursprüngliche Nachricht-----
> >>>>> Von: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] Im Auftrag
> >>>>> von Methsri Wickramarathna
> >>>>> Gesendet: lundi 4 novembre 2013 17:55
> >>>>> An: Pete Lumbis
> >>>>> Cc: cisco-nsp at puck.nether.net
> >>>>> Betreff: Re: [c-nsp] ip tcp adjust-mss
> >>>>>
> >>>>> Thanks Pete,
> >>>>>
> >>>>> If not a problem can any one look in to following mturoute taken ???
> >>> :)
> >>>>>
> >>>>> E:\>mturoute -t www.ubnt.com
> >>>>> mturoute to www.ubnt.com, 30 hops max, variable sized packets
> >>>>> * ICMP Fragmentation is not permitted. *
> >>>>> * Speed optimization is enabled. *
> >>>>> * Maximum payload is 10000 bytes. *
> >>>>>  1  +-  host: 116.12.78.1  max: 1500 bytes
> >>>> [...]
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> --
> >>> ________´$$$$`_____________________________,,,_
> >>> _______´$$$$$$$`_________________________´$$$`
> >>> ________`$$$$$$$`______,,________,,_______´$$$$´
> >>> _________`$$$$$$$`____´$$`_____´$$`____´$$$$$´
> >>> __________`$$$$$$$`_´$$$$$`_´$$$$$`__´$$$$$$$´
> >>> ___________`$$$$$$$_$$$$$$$_$$$$$$$_´$$$$$$$´_
> >>> ____________`$$$$$$_$$$$$$$_$$$$$$$`´$$$$$$´_
> >>> ___,,,,,,______`$$$$$$_$$$$$$$_$$$$$$$_$$$$$$´_
> >>> _´$$$$$`____`$$$$$$_$$$$$$$_$$$$$$$_$$$$$$´_
> >>> ´$$$$$$$$$`´$$$$$$$_$$$$$$$_$$$$$$$_$$$$$´_
> >>> ´$$$$$$$$$$$$$$$$$$_$$$$$$$_$$$$$$$_$$$$$´_
> >>> ___`$$$$$$$$$$$$$$$_$$$$$$$_$$$$$$_$$$$$$´_
> >>> ______`$$$$$$$$$$$$$_$$$$$__$$_$$$$$$_$$´_
> >>> _______`$$$$$$$$$$$$,___,$$$$,_____,$$$$$´_
> >>> _________`$$$$$$$$$$$$$$$$$$$$$$$$$$$$$´_
> >>> __________`$$$$$$$$$$$$$$$$$$$$$$$$$$$´_
> >>> ____________`$$$$$$$$$$$$$$$$$$$$$$$$´_
> >>> _______________`$$$$$$$$$$$$$$$$$$$$´_
> >>>
> >>> ~~( ŊëŌ )~~
> >>> _______________________________________________
> >>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> >>> https://puck.nether.net/mailman/listinfo/cisco-nsp
> >>> archive at http://puck.nether.net/pipermail/cisco-nsp/
> >>>
> >>
> >>
> >
> >
>
>


-- 
-- 
________´$$$$`_____________________________,,,_
_______´$$$$$$$`_________________________´$$$`
________`$$$$$$$`______,,________,,_______´$$$$´
_________`$$$$$$$`____´$$`_____´$$`____´$$$$$´
__________`$$$$$$$`_´$$$$$`_´$$$$$`__´$$$$$$$´
___________`$$$$$$$_$$$$$$$_$$$$$$$_´$$$$$$$´_
____________`$$$$$$_$$$$$$$_$$$$$$$`´$$$$$$´_
___,,,,,,______`$$$$$$_$$$$$$$_$$$$$$$_$$$$$$´_
_´$$$$$`____`$$$$$$_$$$$$$$_$$$$$$$_$$$$$$´_
´$$$$$$$$$`´$$$$$$$_$$$$$$$_$$$$$$$_$$$$$´_
´$$$$$$$$$$$$$$$$$$_$$$$$$$_$$$$$$$_$$$$$´_
___`$$$$$$$$$$$$$$$_$$$$$$$_$$$$$$_$$$$$$´_
______`$$$$$$$$$$$$$_$$$$$__$$_$$$$$$_$$´_
_______`$$$$$$$$$$$$,___,$$$$,_____,$$$$$´_
_________`$$$$$$$$$$$$$$$$$$$$$$$$$$$$$´_
__________`$$$$$$$$$$$$$$$$$$$$$$$$$$$´_
____________`$$$$$$$$$$$$$$$$$$$$$$$$´_
_______________`$$$$$$$$$$$$$$$$$$$$´_

~~( ŊëŌ )~~