[AusNOG] MTU debugging? (Or possibly just a fault with Amazon SES?)

[Mark ZZZ Smith]

MSS hacking is definitely a hack, it doesn't work on non-TCP protocols, and involves looking far deeper into each and every packet to
-  see if they're TCP-  find the TCP header (which in theory may not always be in the same place because of IP options)  
-  then see of they're TCP SYNs, -  find the TCP MSS option, if it exists (it's optional), and if it does,  find where it is, because it isn't required to be in the same place,-  update the TCP MSS value-  since the contents of the TCP header has been intentionally changed, recalculate the TCP header checksum and update that too.  
and after all that, you still haven't fixed your PMTUD problem, you've just pasted over it for just one of the possible protocols that can be used end-to-end over the Internet (which could include TCP hidden inside some other protocol e.g. GRE, PPTP, IPsec, so you haven't even fixed it for all TCP traffic either). MSS hacking should really only be used when it isn't possible or feasible to fix or avoid PMTUD issues.

If you want to avoid the cost of PMTUD for dumbbell MTU paths, it is better to lower the interface MTU on the source and destination hosts, as it will then work for all protocols the hosts' use, not just TCP. There is a DHCPv4 MTU option that can be used to do this, although some hosts may not support it, so it'd be best to check it, and manually change the MTUs on hosts that don't. IPv6 RAs have an MTU option that can be used to lower hosts' interface MTUs, and support for that option by IPv6 hosts is mandatory. You'll lose some performance for transfers between hosts attached to the same LAN with lower host MTUs, but if the majority of traffic is to or from off-link destinations or sources, as most traffic is for most LANs, the loss of LAN performance won't occur very often, and when it does, it may not be significant anyway.

      From: Jeremy Visser <jeremy at sunriseroad.net>
 To: ausnog at lists.ausnog.net 
 Sent: Wednesday, 3 June 2015, 10:51
 Subject: Re: [AusNOG] MTU debugging? (Or possibly just a fault with Amazon SES?)
   
On 03/06/15 08:44, Damien Gardner Jnr wrote:
> This one is doing my head in somewhat.  I have a customer who needs 
> to receive emails from a body who use Amazon SES in the US to send 
> emails.  I can see the connections coming into the customer 
> mailserver, however they then timeout with no data after connecting.

Sounds like one or both ends are filtering the ICMP Packet Too Big messages.

If this error is specific to Amazon SES, then they could well be the ones doing this and it will be beyond your control.

If it comes to it, a hack is to lower the TCP MSS by mangling the TCP SYN packets on both ends of the tunnel.  This has the added bonus of saving a RTT by not needing to wait for the ICMP message.

Linux example:

  # iptables -t mangle -A FORWARD \
    -o tun0 \
    -p tcp \
    --tcp-flags SYN,RST SYN \
    -j TCPMSS --set-mss=1412

Cisco example:

  interface Tunnel0
  ip tcp adjust-mss


_______________________________________________
AusNOG mailing list
AusNOG at lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20150603/6826760b/attachment.html>