Im an enterprise guy, so this is what I see for our clients. I don't have exact info but if for example a TCP sessions stays up between two end hosts (whether they are routers or windows boxes whatever..) and a path changes from say a P2P to a routed VPN, quick enough that the tcp session between the endpoints doesn't time out (I hope so) - the MSS is NOT recalculated as, it is only set in the TCP handshake - which is what Adam is referring to when you set the MSS on the interface.
The exact path mtu discovery technique doesn't seem to be well documented - the RFC is 26 years old - and unless your hosts are actively "checking" mtu using DF bit the whole time a session is up (for changes) - I don't believe even half of RFC-1191 is implemented in the real world. If someone has knowledge of how cisco routers do it exactly - I would love to hear. -----Original Message----- From: cisco-nsp [mailto:[email protected]] On Behalf Of CiscoNSP List Sent: 24 February 2016 10:08 To: Dan Peachey; [email protected] Subject: Re: [c-nsp] transport path-mtu-discovery - ME3600....too unpredictable to use? Cheers Dan (apologies for top post, on phone) - Ill check all Ints for no ip unreachables (I dont believe any have it configured)...We have some relatively unpredictable carriers that supply interpop links unfortunately, and no matter how many assurances they provide that circuit X will support MTU Y, and will not change....6 months down the track, someone fat fingers a transit device, and defaults MTU to 1500, and we are left with all sorts of fun and games with OSPF/MPLS/BGP...so unfortunately, we deal with each link individually, hope it doesnt change, and set MTU based on carriers provisioning docs....hence why I think that living with disabling PMTUD/default MSS is the "safest" option for us (At least for BGP :) ) Is having a much smaller segment size going to pose that much of an issue in a small network? we take 4-6 full tables, have a number of peering links, and also have 50-100 customer BGP sessions in VRF's predominantly Side note - Im still a little uncertain "when/how often" PMTUD calculates, or re-calculates it values....If someone could point me to some docco that details it, that would be fantastic. Thanks. Hi, Make sure that you don't have 'no ip unreachables' configured on any of your core interfaces. This can screw up PMTUD as it relies on routers in the path sending back 'ICMP type 3 Fragmentation Needed' packets to the source when the egress interface MTU is too small to send the packet. Having circuit MTU's that are smaller than defined interface MTU's will also screw it up. Can you not set a consistent MTU across the network that you know will be supported on every core circuit? If not, then I think you will have to disable PMTUD and live with the default MSS. Cheers, Dan _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
