I have been having a problem when experimenting with sending large
pings with the DF bit set over a GRE tunnel.
I can send pings with a size of upto about 1450 over the tunnel, but
when they get any larger then I have problems. I send the packet and
I get the ICMP reply about not being able to send the send the packet
as it is too large and needs fragmenting. However I then try and send
a smaller packet and I still get the same reply, but now it is saying
the MTU on the tunnel interface is 552. This means that while I
should be able to send packets which are say 1000 bytes I can't until
this problem times out after a few minutes.
I suspect the problem is related to how PMTU discovery works. But I
can't work out if it supposed to work like this or there is some sort
of a bug. It seems strange that the MTU size would drop just because
one larger packet was sent.
I am doing the ping with the following: ping -s 1480 -M do w.x.y.z,
then I change the packet size to 1000 and it still doesn't work, until
this timeout happens. The inferrence from the PMTU discovery RFC is
that the maximum value to use is 576, so this is why I suspect this
could be the problem, but it seems to be a strange way of handling
this situation. I can't take the PMTU discovery off the tunnel as I
am tunnelling OSPF through the tunnel and need the ttl to be larger
otherwise the TTL is exceeded and changing the TTL is incompatable
with nopmtudisc for some reason.
Has anyone had this sort of problem before, and do they know a
workaround to either reduce the timeout or elimate it totally, as it
is causing problems with my experiments waiting for this timeout.