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

Wed Jun 3 10:38:16 EST 2015

Shouldn't be anything in the data path - goes directly from US->AU tunnel
router, into core router, and then to the various cpanel and plesk servers
- which all seem to be seeing the same problem from *.amazonses.com servers.

Lots of log entries in exim (and similar from mailenable on the plesk
boxes) that look like this:

2015-06-03 08:51:59 SMTP connection from [54.240.9.143]:51571 (TCP/IP
connection count = 4)
2015-06-03 08:52:59 SMTP connection from [54.240.27.130]:50131 (TCP/IP
connection count = 4)
2015-06-03 08:54:48 SMTP data timeout (message abandoned) on connection
from a9-143.smtp-out.amazonses.com [54.240.9.143]:51571 F=<
0000014db3aa6e4b-eac45098-5237-4f1e-a8c9-7063fc355f4a-000000 at amazonses.com>
2015-06-03 08:55:49 SMTP data timeout (message abandoned) on connection
from a27-130.smtp-out.us-west-2.amazonses.com [54.240.27.130]:50131 F=<
0000014db6492aa4-3cdf28c6-732e-4fad-aa3d-45b48f026257-000000 at us-west-2.amazonses.com
>

Good point on the tcpdump, have started a dump on 54.240/16, will see
exactly how far they're getting, and what size packets they're sending (or
not sending, as the case may be).  Might also do the same from the US
router.

pings and mtr's of various sizes all look as expected. Tracepath was a nice
suggestion from one person, haven't seen it before, but it also shows the
frag needed packets working correctly.

Will keep plugging away at it :)

On 3 June 2015 at 10:26, Seamus Ryan <s.ryan at uber.com.au> wrote:

>  Don’t suppose your client has a spam filtering appliance/device/product
> that is performing packet/protocol inspection on smtp?
>
>
>
> If so, try turning it off temporarily (the packet inspection, not the
> whole service). Ive seen some nasty issues which sound very similar to your
> description caused by smtp protocol inspection. Seems to do more harm than
> good.
>
>
>
> Regards,
>
> Seamus
>
>
>
> *From:* AusNOG [mailto:ausnog-bounces at lists.ausnog.net] *On Behalf Of *Damien
> Gardner Jnr
> *Sent:* Wednesday, 3 June 2015 8:44 AM
> *To:* ausnog at lists.ausnog.net
> *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.au
>
> PING 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=1452
>
> ping: local error: Message too long, mtu=1452
>
>
>
> ubuntu at ip-172-31-4-204:~$ ping -M do -s 1424 plesk03.rendrag.net.au
>
> PING 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 ms
>
> 1432 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
>

-- 

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20150603/2f25a585/attachment.html>