|
On Wed, 23 Jul 2008, Marco Lorig wrote:
If I understand correctly, nopmtudisc within GRE-tunnels masks fragmentation to
client and server.
any fragmentation inside the gre tunnel is transparent to
the networks feeding it? ie the gre tunnel just looks like a
regular 1500 byte packet carrier?
I couldn't find anything useful with google on nopmtudisc.
Everyone uses it blindly as a magic parameter. The only
posting that tried to figure anything out was
http://www.usenet-forums.com/linux-networking/62985-problem-large-pings-dont-fragment-set.html
but he didn't get any useful answers
hmm
http://www.netheaven.com/pmtu.html
shows the command for turning off pmtu discovery for Linux
about half way down the page. It's
echo 1 >/proc/sys/net/ipv4/ip_no_pmtu_disc
so I assume the gre nopmtudisc is a part of this problem.
Can you give the opposite of nopmtudisc? Can you allow
fragmentation at the src.
(I know this is a lot of pain to fix a system that was
working for 2.4.)
This article also gives the pmtu timeout as 10mins, which is
the same as your timeout.
He also says to change the mtu size for the route involved
(in his example, the default route).
new connection or the current connection as well?
The connection is terminated after the transfer, so only new connections don´t
work , I reckon.
wierd. I would have thought that the gre tunnel would handle
each packet separately, independantly of the connection. (I
thought mtu was for each packet, not per connection.)
Maybe the gre tunnel is handling the connections OK and the
src end of the tunnel is getting bad info about the mtu size
after the time out when it sends a SYN packet. Can you
filter out the "need fragmentation" icmp packets that the
src gets from the gre tunnel? (just block all icmp packets
for the moment)
Joe
--
Joseph Mack NA3T EME(B,D), FM05lw North Carolina
jmack (at) wm7d (dot) net - azimuthal equidistant map
generator at http://www.wm7d.net/azproj.shtml
Homepage http://www.austintek.com/ It's GNU/Linux!
|
