Adam Hardy wrote:
Jan 'RedBully' Seiffert on 11/09/08 21:17, wrote:
[snip]
Hmmm, a mtu of 1430 looks a bit strange, but propably depends on your
link.
Some kind of VPN or PPPoA on your side? Or are you saying paypal has
some kind of Tunnel/Route/Whatever which limits THEIR mtu?
In an ideal World you would not need to fiddle with your mtu, because
a thing
called path mtu discovery should catch this. Your kernel sends packets
with the Don't Fragment-Bit (DF) set, and every router on the way to
the
target should sent you a packet back when your packet is to big, so your
kernel can lower the pmtu, till it fits. Unfortunatly, this does not
always
work, either because the setup is so complex (vpn over a tunnel over
dailup...) that errors are not properly propagated, or, and this is more
anoing, because some Admins block ICMP, which is needed for this to
work. In
their view ICMP is evil and a 1337 H4x0r protocol, neglegting that
it is a
needed part for {TCP|UDP}/IP to work. A big german freemail provider was
notoriously known for this braindamage for years.
But before you lower your clients mtu, do you know where the mtu
bottleneck
is and/or is your router by chance a Linux box? (such things can
shurely also
be done with other gear, but i don't know how)
Because there are two other and maybe more interresting solutions:
1) Linux knows an iptables target named TCPMSS. It adjusts the tcp
mss, so it
won't help you on UDP, but fixes the most commen case, that tcp
connection
hang. But only if your router sees the mtu bottleneck (PPPoE or
something
similar). Look at your iptables man-page, it comes with an example
command. Most SOHO-router-in-a-box implement this, maybe it it
switched off? This also
fixes problems with other sites, until their pmtu is lower than yours and
they do the braindamaged stuff...
2) You can try setting the pmtu early (so icmp messages reach the
client) by setting up a route with the right mtu on your router. Hmmm,
you can even set
it on the clients. Example:
Hi Jan,
I really appreciate the feedback - although I think your option (2) is
slightly beyond what I want to get into for the sake of network admin
here!
Yeah, it is a possible workaround for a one oddball situation, but if your
link is the permanent bottleneck, you will hit this problem again and again...
I must admit that I set up the iptables firewall on my gateway
machine, and I need to look at it to check whether I inadvertantly
blocked this ICMP business.
Oh, initially i wasn't even talking about you, but problems on the remote end
where you have no control how they configure their stuff. Then you are forced
to employ ugly workarounds on your side.
If you check your firewall rules, make sure there is a path for
icmp-fragmentation-needed packets.
(iptables right table -p icmp --icmp-type fragmentation-needed -j ACCEPT)
The gateway has a NIC connected to a DSL modem and that has no firewall,
it's just my machine and BT on the other side.
I read a little on BT, seems they use PPPoA, and this is terminated on the
modem...
Hmmm, ATM equipment for PCs is rare, so your router has normal ethernet to the
modem and sees an mtu of 1500, while the true mtu is hidden in the modem. And
i thought one of the benefits of pppoa was, that the mtu is kept at 1500.
Any chance your new hosting service has a funny uplink? (should not, a big site
should have a real connection and not a dsl line...)
/me is tottaly confused
Gnarf, seems this is even a bigger PITA than PPPoE ...
Searching for the right mtu turned up a lot of values, does someone know the
true mtu of a BT PPPoA link? (note: first and foremost you better find the real
mtu of the link, to get a grip on the problem, then one can think about
adjusting/tuning it to better match the ATM-part of the connection)
The modem faced interface of your router needs the MTU set to the true value.
This way your router should not send packets to big (or fragment them), your
clients should get an fragmentation-needed when they try to.
But this still leaves problems with the path back to you when the remote side is
blocking icmp (a bottleneck has two sides ;). Lowering the mtu of your clients
is a cheap trick to repair this: the clients set the right tcpmss when they
start a connection (you can only set it at the start, but the first packet (the
SYN, approx. 60 bytes) doesn't trigger the pmtu...), so the remote end will not
run into trouble on the path back. In effect you are doing their work (But this
will not help for UDP)
This is where the:
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
-j TCPMSS --clamp-mss-to-pmtu
comes into play. Your router now hopefully knows the pmtu, and will lower the
tcpmss set by the clients as a band aid, the connection will be (hopefully) the
right size from the beginning.
I had problems with SMTP and a new hosting service - a solar powered
hosting service
