<html><body><div style="color:#000; background-color:#fff; font-family:Helvetica Neue-Light, Helvetica Neue Light, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif;font-size:16px"><div dir="ltr" id="yui_3_16_0_1_1433221832124_26428"><span id="yui_3_16_0_1_1433221832124_26427">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.</span></div><div dir="ltr" id="yui_3_16_0_1_1433221832124_26428"><span><br></span></div><div dir="ltr" id="yui_3_16_0_1_1433221832124_26428"><span id="yui_3_16_0_1_1433221832124_26759">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.</span></div><div dir="ltr" id="yui_3_16_0_1_1433221832124_26428"><span><br></span></div><div dir="ltr" id="yui_3_16_0_1_1433221832124_26428"><br></div><div dir="ltr" id="yui_3_16_0_1_1433221832124_26428"><span><br></span></div><div dir="ltr" id="yui_3_16_0_1_1433221832124_26428"><span id="yui_3_16_0_1_1433221832124_26527"> </span></div><div dir="ltr" id="yui_3_16_0_1_1433221832124_26426"><span><br></span></div><div dir="ltr" id="yui_3_16_0_1_1433221832124_26425"><span><br></span></div><br> <div style="font-family: Helvetica Neue-Light, Helvetica Neue Light, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif; font-size: 16px;" id="yui_3_16_0_1_1433221832124_26424"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif; font-size: 16px;" id="yui_3_16_0_1_1433221832124_26423"> <div dir="ltr" id="yui_3_16_0_1_1433221832124_26422"> <hr size="1"> <font size="2" face="Arial" id="yui_3_16_0_1_1433221832124_26809"> <b><span style="font-weight:bold;">From:</span></b> Damien Gardner Jnr <rendrag@rendrag.net><br> <b><span style="font-weight: bold;">To:</span></b> "ausnog@lists.ausnog.net" <ausnog@lists.ausnog.net> <br> <b><span style="font-weight: bold;">Sent:</span></b> Wednesday, 3 June 2015, 8:44<br> <b><span style="font-weight: bold;">Subject:</span></b> [AusNOG] MTU debugging? (Or possibly just a fault with Amazon SES?)<br> </font> </div> <div class="y_msg_container" id="yui_3_16_0_1_1433221832124_26528"><br><div id="yiv2915392966"><div dir="ltr" id="yui_3_16_0_1_1433221832124_26530">Hi Folks,<div id="yui_3_16_0_1_1433221832124_26531"><br></div><div id="yui_3_16_0_1_1433221832124_26532">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.</div><div id="yui_3_16_0_1_1433221832124_26533"><br></div><div id="yui_3_16_0_1_1433221832124_26573">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.:</div><div id="yui_3_16_0_1_1433221832124_26534"><br></div><div id="yui_3_16_0_1_1433221832124_26536"><div id="yui_3_16_0_1_1433221832124_26568">ubuntu@ip-172-31-4-204:~$ ping -M do -s 1425 <a rel="nofollow" target="_blank" href="http://plesk03.rendrag.net.au/">plesk03.rendrag.net.au</a></div><div id="yui_3_16_0_1_1433221832124_26567">PING <a rel="nofollow" target="_blank" href="http://plesk03.rendrag.net.au/" id="yui_3_16_0_1_1433221832124_29783">plesk03.rendrag.net.au</a> (103.235.52.251) 1425(1453) bytes of data.</div><div id="yui_3_16_0_1_1433221832124_26535">From <a rel="nofollow" target="_blank" href="http://rtr01-e0.lax01.ca.rendrag.net.au/" id="yui_3_16_0_1_1433221832124_29784">rtr01-e0.lax01.ca.rendrag.net.au</a> (174.136.108.50) icmp_seq=1 Frag needed and DF set (mtu = 1452)</div><div id="yui_3_16_0_1_1433221832124_26566">ping: local error: Message too long, mtu=1452</div><div id="yui_3_16_0_1_1433221832124_26570">ping: local error: Message too long, mtu=1452</div><div id="yui_3_16_0_1_1433221832124_26537"><br></div><div id="yui_3_16_0_1_1433221832124_26571">ubuntu@ip-172-31-4-204:~$ ping -M do -s 1424 <a rel="nofollow" target="_blank" href="http://plesk03.rendrag.net.au/">plesk03.rendrag.net.au</a></div><div id="yui_3_16_0_1_1433221832124_26572">PING <a rel="nofollow" target="_blank" href="http://plesk03.rendrag.net.au/">plesk03.rendrag.net.au</a> (103.235.52.251) 1424(1452) bytes of data.</div><div id="yui_3_16_0_1_1433221832124_26538">1432 bytes from <a rel="nofollow" target="_blank" href="http://plesk03.rendrag.net.au/">plesk03.rendrag.net.au</a> (103.235.52.251): icmp_seq=1 ttl=111 time=167 ms</div><div id="yui_3_16_0_1_1433221832124_26556">1432 bytes from <a rel="nofollow" target="_blank" href="http://plesk03.rendrag.net.au/">plesk03.rendrag.net.au</a> (103.235.52.251): icmp_seq=2 ttl=111 time=170 ms</div><div id="yui_3_16_0_1_1433221832124_26557"><br></div><div id="yui_3_16_0_1_1433221832124_26558">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..</div><div id="yui_3_16_0_1_1433221832124_26559"><br></div><div id="yui_3_16_0_1_1433221832124_26560">Are there any other tests I can run to make sure it's not my issue?</div><div><br></div><div>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 <a rel="nofollow" target="_blank" href="http://c.speedtest.net/">c.speedtest.net</a> 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..)</div><div><br></div><div>Any ideas?</div><div><br></div>-- <br><div class="yiv2915392966gmail_signature"><div dir="ltr">
<div>Damien Gardner Jnr<br>VK2TDG. Dip EE. GradIEAust<br><a rel="nofollow" ymailto="mailto:rendrag@rendrag.net" target="_blank" href="mailto:rendrag@rendrag.net">rendrag@rendrag.net</a> - <span><a rel="nofollow" target="_blank" href="http://www.rendrag.net/">http://www.rendrag.net/</a><u><br></u></span>--<br>We rode on the winds of the rising storm,<br> We ran to the sounds of thunder.<br>We danced among the lightning bolts,<br> and tore the world asunder</div></div></div>
</div></div></div><br>_______________________________________________<br>AusNOG mailing list<br><a ymailto="mailto:AusNOG@lists.ausnog.net" href="mailto:AusNOG@lists.ausnog.net">AusNOG@lists.ausnog.net</a><br><a href="http://lists.ausnog.net/mailman/listinfo/ausnog" target="_blank">http://lists.ausnog.net/mailman/listinfo/ausnog</a><br><br><br></div> </div> </div> </div></body></html>