MTU issues

[mindlesstux]

Ok the fun topic we all love to bang our heads on the wall for...

I have uverse and I am affected by their current "nation wide" "outage".  I use "'s on the term outage, as my connection is up with an IP but some ATT engineer thought dropping the MTU down to 576 (dialup packet size anyone?) would help the problem till they solve the issue.  This of course impacts my 6to4 tunnel from my mikrotik router.  I can ping and ssh into the router over ssh on the tunnel assigned address but not the routed address nor am I able to pull web pages, which is given if I can ping the routed.

I have not changed anything on my mikrotik that was working pre-"outage" so this leads me to believe it is a MTU issue.  So I added a couple mangle rules to clamp the mss down under 576 on all outgoing ipv4 tcp packets.  Still no luck in IPv6 land but the ipv4 got more stable behind my router.

I am open to suggestions as to where to head next, but I think I am SOL with IPv6 till the "outage" is done.

I'll open up a read only account to the router to any HE employee or forum guru that wants to poke the config of the router upon asking.

[mindlesstux]

Of course as soon as I post this, they declare the "outage" as resolved.

Kicked the modem remotely, MTU set to 1500 again... So time to experiment over lunch I think...

[kasperd]

some ATT engineer thought dropping the MTU down to 576 (dialup packet size anyone?) would help the problem till they solve the issue.

That's a double edged sword. The situation where lowering the link MTU can help on PMTU issues is if the ICMP errors produced by that causes the sender to fragment packets before sending. But in some situations the lower MTU may be a problem by itself. So though it may solve some problems, it may introduce others.

In some cases, if you do have to send an ICMP error due to a packet exceeding the MTU, it may help to actually advertise a lower MTU in the error message than what you actually support. For example you could have a link where packets below 1400 bytes are forwarded and packets above 1400 bytes get an error indicating a link MTU of 576 bytes. This gives many of the benefits of the lower MTU and fewer of the drawbacks.

In many cases one is better off leaving the MTU alone and just mangling the MSS. But you seem to know that already.

Both approaches are hacks, that wouldn't be necessary if other nodes handled PMTU discovery correctly. Sometimes resorting to such hacks is the more productive approach.

So I added a couple mangle rules to clamp the mss down under 576 on all outgoing ipv4 tcp packets.  Still no luck in IPv6 land but the ipv4 got more stable behind my router.

You would have needed to clamp the MSS on both IPv4 and IPv6 TCP packets, and you'd have needed to clamp them to proper values. For the IPv4 case, you need to subtract 40 from the MTU in order to compute the proper MSS value (20 bytes IPv4 header plus 20 bytes TCP header). For the IPv6 case, you need to subtract 80 from the MTU. That is because with tunnelling you have both an IPv4 and IPv6 header on your packets, so in total you need to account for 20+40+20 bytes. That means an MSS of 536 or less should work for IPv4 and an MSS of 496 or less should work for IPv6. If it turns out to be easier to use the same value, then using 496 for both should work.

Hope this helps, next time your ISP has such an outage.

[mindlesstux]

I did not even think to clamp the v6 traffic.

Let's hope that there will  never be that kind of outage again.