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

[Mark ZZZ Smith]

Path MTU is a direction specific path attribute, so it is possible that PMTUD will be working correctly in one direction but not the other. The symptom of that is file downloads working but uploads failing or vice-versa, or being able to receive larger emails but not send them or vice versa. Another symptom is that small emails work in both directions, because they're so small that they don't encounter the PMTU, where as large emails in one of the directions don't.
It sounds to me like you've got those sorts of symptoms, so check that the devices at both ends of the tunnel are generating ICMP Packet Too Big messages, and check that the sending hosts on both ends are receiving them. That can be a little bit of work, so another way to confirm that this is the likely cause is to lower the interface MTUs on your test hosts to that of the tunnel's MTU, and conduct your tests in both directions. That avoids the hosts sending any packets large enough to trigger PMTUD, and if your tests completely pass, then you definitely know that your problem is PMTUD related.


 


      From: Damien Gardner Jnr <rendrag at rendrag.net>
 To: "ausnog at lists.ausnog.net" <ausnog at lists.ausnog.net> 
 Sent: Wednesday, 3 June 2015, 8:44
 Subject: [AusNOG] MTU debugging? (Or possibly just a fault with Amazon SES?)
   
Hi Folks,
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.
If I send various sized pings from amazon and linode instances in the US, they work perfectly up until the point where they hit the MTU of our US->AU tunnel, and then get back a Frag-Needed packet, so that's all working perfectly as expected. e.g.:
ubuntu at ip-172-31-4-204:~$ ping -M do -s 1425 plesk03.rendrag.net.auPING plesk03.rendrag.net.au (103.235.52.251) 1425(1453) bytes of data.From rtr01-e0.lax01.ca.rendrag.net.au (174.136.108.50) icmp_seq=1 Frag needed and DF set (mtu = 1452)ping: local error: Message too long, mtu=1452ping: local error: Message too long, mtu=1452
ubuntu at ip-172-31-4-204:~$ ping -M do -s 1424 plesk03.rendrag.net.auPING plesk03.rendrag.net.au (103.235.52.251) 1424(1452) bytes of data.1432 bytes from plesk03.rendrag.net.au (103.235.52.251): icmp_seq=1 ttl=111 time=167 ms1432 bytes from plesk03.rendrag.net.au (103.235.52.251): icmp_seq=2 ttl=111 time=170 ms
As as far as I can see, things are working as they should.  However the body using Amazon SES has contacted Amazon support and received a 'This usually signifies an MTU misconfiguration on the remote end, we cannot help with this' reply.  Which leaves me at something of a stalemate..
Are there any other tests I can run to make sure it's not my issue?
I can pull down files no problems at all with http, torrents, etc.  Although one interesting exception is that speedtest does not work - https requests to c.speedtest.net just block after the initial request with no response until the connection is brought down by RST.  (Although that happens in multiple regions in my upstreams' network as well, so I've been assuming it was a problem with speedtest for the last 6 months..)
Any ideas?
-- 
Damien Gardner Jnr
VK2TDG. Dip EE. GradIEAust
rendrag at rendrag.net -  http://www.rendrag.net/
--
We rode on the winds of the rising storm,
 We ran to the sounds of thunder.
We danced among the lightning bolts,
 and tore the world asunder
_______________________________________________
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/493b4445/attachment.html>