tcp_mtu_discover causes traceroute problems on aix 4.3.3
Tom Van Overbeke
We upgraded our machines during the last months from aix 4.2.1 to aix 4.3.3
ML 10.
Now, we're faced with traceroute problems with foreign (over WAN links)
hosts (we get the * * * instead of the normal output)
I noticed that on AIX 4.2.1, the "no" option tcp_mtu_discover and
udp_mtu_discover was set to 0, meaning not to calculate the path MTU. But
since the don't fragment bit was not set either, this ofcourse caused no
problems (except for possible fragmentation of packets ofcourse).
Now, on AIX 4.3.3, these 2 no options are set to 1, and as a result, the DF
bit is set, however:
- on our local subnet, no problems are encountered.
- on a WAN link, because udp_mtu_discover is 1, the correct path MTU should
be calculated, and the don't fragment is set. However, it says :
"outgoing MTU = 1500" which is not the correct value (because the traceroute
fails).
if i manually set the MTU to 1000, it works.
- also noticed that only for traceroute traffic the DF bit is set. ping,
telnet, .... traffic never shows the DF bit ??? is this normal ???
I then tried to disable mtu_discover by putting these 2 lines in rc.net: (it
pasted some lines before and after, to indicate whereabouts in the file the
lines are put)
---> CUT
# If a diskless or dataless machine uses this configuration method, you
# may want to replace the previous line with the following.
#
# /usr/lib/methods/cfgif $*
/etc/no -o tcp_pmtu_discover=0
/etc/no -o udp_pmtu_discover=0
##################################################################
# Configure the Internet protocol kernel extension (netinet):
##################################################################
# The following commands will also set hostname, default gateway,
# and static routes as found in the ODM database for the network.
/usr/lib/methods/definet >>$LOGFILE 2>&1
/usr/lib/methods/cfginet >>$LOGFILE 2>&1
---> CUT
after I rebooted the server, i noticed the same behaviour:
- traceroute to WAN-connected hosts still doesn't work
- i still see the DF bit but still only for traceroute.
What's going on here? How can I stop the DF bit getting set on AIX 4.3.3 for
traceroute ?
On IBM's site, i noticed APAR IX75018: Traceroute fails to calculate
path-mtu which appeared to be exactly my problem, but when I selected my os
version (or even a few ML's lower), it said 'no file available, this
probably means that the fix is already on your system'. And indeed, when i
did a
instfix -i | grep IX75018, is said that all files were installed.
All help is welcome!
Thanks,
Tom.
Holger van Koll
no -o tcp_pmtu_discover=0
is enough
(until next reboot)
why do you think this traceroute-problem is related to pmtu-discovery?
traceroute (probably) set the df-bit itself
it also sends small pakets (AFAIR 38 bytes)
maybe it uses df-bit to detect illegal fragmentation (a 38-byte paket
must not be fragmented)
for udp: the app. must take care of paket-size itself. see manpage for
no command
so, what is your problem? the * * * in traceroute? did you read the
traceroute manpage for hints/explanations regarding this?
Tom Van Overbeke
"Holger van Koll" <hol...@vankoll.de> wrote in message
news:3EAFE664...@vankoll.de...
> those no-parameters are runtime-attributes, you dont need to reboot
> no -o tcp_pmtu_discover=0
> is enough
> (until next reboot)
some parameters must be set before some kernel extension is loaded.
unfortunately the no man page doesn't say which ones.
>
> why do you think this traceroute-problem is related to pmtu-discovery?
because there's no problem in aix 4.2.1 when pmtu discov. was not active and
if i manually set the path mtu of the device (with chdev) to a smaller size,
everything works.
>
> traceroute (probably) set the df-bit itself
> it also sends small pakets (AFAIR 38 bytes)
> maybe it uses df-bit to detect illegal fragmentation (a 38-byte paket
> must not be fragmented)
>
> for udp: the app. must take care of paket-size itself. see manpage for
> no command
>
> so, what is your problem? the * * * in traceroute? did you read the
> traceroute manpage for hints/explanations regarding this?
yes, if there's no responsie within 3 seconds, there's a '*'.
so i suppose that the (automatically) chosen mtu is too big for the network,
and because the DF bit is set, the packet is dropped, and this causes the
'*'
So maybe it's traceroute for aix 4.3.3 which has a bug: it should be able to
determine the right path mtu itself, but apparently it doesn't.
I noticed that if i specify a smaller size manually (like in "traceroute
somehost 1000"), it does work.
I still think that this is a bug in traceroute. Other applications behave
well.
Although i do not understand why, with path mtu discovery enabled, i only
see the DF bit set for traceroute traffic ? shouldn't this be set also for
telnet etc ?
thx,
Tom.
Keith Wansbrough
first time:]
"Tom Van Overbeke" <tom.van....@pandora.be> writes:
> So maybe it's traceroute for aix 4.3.3 which has a bug: it should be able to
> determine the right path mtu itself, but apparently it doesn't.
Traceroute doesn't use TCP, it uses UDP (or optionally ICMP). Neither
of these protocols have path MTU discovery, only TCP does.
> I noticed that if i specify a smaller size manually (like in "traceroute
> somehost 1000"), it does work.
On my (Linux) traceroute, the default is 40 bytes, so 1000 would be a
*larger* size.
> Although i do not understand why, with path mtu discovery enabled, i only
> see the DF bit set for traceroute traffic ? shouldn't this be set also for
> telnet etc ?
I think that is surprising - normally TCP implementations will set DF
on all datagrams, and this is necessary for PMTU discovery. But it
has nothing to do with traceroute.
--KW 8-)
--
Keith Wansbrough <kw...@cl.cam.ac.uk>
http://www.cl.cam.ac.uk/users/kw217/
University of Cambridge Computer Laboratory.
Dale Talcott
>> I noticed that if i specify a smaller size manually (like in "traceroute
>> somehost 1000"), it does work.
>On my (Linux) traceroute, the default is 40 bytes, so 1000 would be a
>*larger* size.
AIX is a little strange with traceroute. For example here is a traceroute
from an AIX 5.1 box on FDDI out to the world. Note the messages about MTU.
$ traceroute www.apple.com
trying to get source for www.apple.com
source should be 128.210.250.54
traceroute to www.apple.com.akadns.net (17.112.152.32) from 128.210.250.54 (128.210.250.54), 30 hops max
outgoing MTU = 4352
1 cisco2-250.tcom.purdue.edu (128.210.250.1) 21 ms 3 ms 3 ms
2 cisco2-250.tcom.purdue.edu (128.210.250.1) 4 ms
fragmentation required, trying new MTU = 4332
2 * 4 ms
fragmentation required, trying new MTU = 2048
2 * 8 ms
fragmentation required, trying new MTU = 2028
2 * 4 ms
fragmentation required, trying new MTU = 2002
2 * 4 ms
fragmentation required, trying new MTU = 1982
2 * 4 ms
fragmentation required, trying new MTU = 1536
2 * 3 ms
fragmentation required, trying new MTU = 1516
2 * 4 ms
fragmentation required, trying new MTU = 1500
2 128.210.252.201 (128.210.252.201) 4 ms 7 ms 3 ms
3 cisco-tel3-242.tcom.purdue.edu (128.210.242.24) 2 ms 2 ms 3 ms
4 switch-data.tcom.purdue.edu (192.5.40.34) 4 ms 6 ms 5 ms
5 so-1-0-0.iplvin1-hcr5.bbnplanet.net (4.24.115.1) 5 ms 5 ms 5 ms
6 p8-0.iplvin1-br2.bbnplanet.net (4.0.2.5) 5 ms 4 ms 4 ms
7 p13-0.phlapa1-br1.bbnplanet.net (4.24.10.181) 22 ms 20 ms 19 ms
8 p13-0.nycmny1-nbr2.bbnplanet.net (4.24.10.178) 21 ms 21 ms 21 ms
9 so-7-0-0.nycmny1-hcr3.bbnplanet.net (4.0.7.13) 21 ms 21 ms 21 ms
10 genuity-gw.n54ny.ip.att.net (192.205.32.157) 21 ms 21 ms 21 ms
...
My guess is that the original poster's problem has to do with a router
somewhere that needs to fragment, but doesn't return the ICMP message
to tell traceroute about it. I think the OP could figure out which
router that is by comparing "traceroute host" with "traceroute host 0".
The first router that shows up in the 0 traceroute, but not the normal
one is suspect.
--
Dale Talcott, IT Research Computing Services, Purdue University
a...@quest.cc.purdue.edu http://quest.cc.purdue.edu/~aeh/
Barry Margolin
Dale Talcott <a...@quest.cc.purdue.edu> wrote:
>My guess is that the original poster's problem has to do with a router
>somewhere that needs to fragment, but doesn't return the ICMP message
>to tell traceroute about it.
More likely, a router in between has a packet filter that blocks ICMP
messages. This is an all-too-common problem these days for Path MTU
Discovery.
--
Barry Margolin, barry.m...@level3.com
Genuity Managed Services, a Level(3) Company, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Holger van Koll
> from an AIX 5.1 box on FDDI out to the world. Note the messages about MTU.
>
What is strange here? You got a mtu of >4000 bytes on fddi and as soon
as your packets reach an ethernet, the corresponding router tells your
app (traceroute) to defrag to ethernet-mtu 1500.
Detlef Bosau
zum Thema "tcp_mtu_discover causes traceroute problems on aix 4.3.3":
> MTU should be calculated, and the don't fragment is set. However,
> it says : "outgoing MTU = 1500" which is not the correct value
> (because the traceroute fails).
> if i manually set the MTU to 1000, it works.
> - also noticed that only for traceroute traffic the DF bit is set.
> ping, telnet, .... traffic never shows the DF bit ??? is this
> normal ???
I'm not quite sure about the peculiarites of your operating
system and your applications.
However, a severe misunderstanding is, that "Path MTU Discovery"
will always work fine, only because it was introduced in some
older RFC, written somewhere by someone, somehow.
O.k., this sounds cynical.
Let's have a look on how PMTU discovery works.
The main idea of PMTU discovery is to send probe packets along the
path, where the probe packets have the DF bit set and thus
must not be fragmented by any router.
If a router is well behaved, i.e. it politefully obeys all the
SHOULDs and MUSTs of the most recent "SHOULDs and MUSTs for
all Internet Systems" RFC, it kindly passes a message to you:
"Respected Sir! I'm so sorry to inform you about me being
unable to fulfill your kind request for some reason beyond
my responsibilty..." blabla ;-)
If a router is some older unit, and I've seen some routers,
where I strongly looked, where the "Interface Message Processor,
Prototype 0.0.1, predeployment release" was hidden from me,
it may occur, that a router does not know of those recent
RFC and that even the maintenance stuff did not replace
or upgrade the unit, because the unit works pretty finde up to now.
In that case, the PMTU discovery will simply not work.
(Although, in some textbooks published by a company in Redmont,
I've seen some so called "Black Hole PMTU discovery" which
deals with this problem by some mixture of timeouts, belief
and religion. And sometimes, even prayers are claimed to work.)
Nevertheless, PMTU discovery is not always guaranteed to work.
It is sufficient for the algorithm to fail, to have one
older, not fully well behaved router on the path.
My personal opinion is, to leave transparent fragmentation alone
on IPv4. In IPv6, it's a different situation, because all nodes
and routers are designed for PTMU discovery from scratch.
In IPv4, it's an additional feature, hence there will always
the possibilty to encounter systems, which do not support
this feature.
DB
--
Mit so einen begrenzten,dass ich gar nicht sage psychisch- retardierten
Individuum,möchte ich mich keinesfalls weiter
rekreieren.
(Hannelore Brigic in d.s.w.c.)
Barry Margolin
Detlef Bosau <Detlef...@tesionmail.de> wrote:
>If a router is some older unit, and I've seen some routers,
>where I strongly looked, where the "Interface Message Processor,
>Prototype 0.0.1, predeployment release" was hidden from me,
>it may occur, that a router does not know of those recent
>RFC and that even the maintenance stuff did not replace
>or upgrade the unit, because the unit works pretty finde up to now.
>
>In that case, the PMTU discovery will simply not work.
The ICMP Message for Fragmentation Required but DF Set has been around
since the beginning of the Internet. I would be extremely surprised if
there are any routers in current use that don't support it.
The only "recent" change was in the Path MTU Discovery RFC, which
recommends that this message also include the MTU that was exceeded. This
allows the sender to drop his Path MTU directly to that value, rather than
guessing what to use. Path MTU Discovery was designed to work without this
(since the designers could hardly expect all routers to be upgraded
overnight), it just makes it more efficient.
If you're not getting the ICMP messages, it's not likely that it's because
of a router that doesn't know how to send it. It's almost certainly
because of a router or firewall in between that's filtering them out.
Dale Talcott
I did not mean the results were strange, only that AIX traceroute was
different from many other traceroutes in attempting to do MTU discovery
at the same time.
Barry Margolin
>
>>> AIX is a little strange with traceroute. For example here is a traceroute
>>> from an AIX 5.1 box on FDDI out to the world. Note the messages about MTU.
>
>>What is strange here? You got a mtu of >4000 bytes on fddi and as soon
>>as your packets reach an ethernet, the corresponding router tells your
>>app (traceroute) to defrag to ethernet-mtu 1500.
>
>I did not mean the results were strange, only that AIX traceroute was
>different from many other traceroutes in attempting to do MTU discovery
>at the same time.
However, it seems like a nice additional feature. In addition to telling
you the route, it also tells you about MTU differences along the way. This
can be helpful in some kinds of troubleshooting.
I'll bet there's an option to turn off this feature.
Detlef Bosau
zum Thema "Re: tcp_mtu_discover causes traceroute problems on aix 4.3.3":
> The ICMP Message for Fragmentation Required but DF Set has been
> around since the beginning of the Internet. I would be extremely
O.k., you're right here. At least, it is defined in RFC 792, that should
be sufficient.
> surprised if there are any routers in current use that don't
> support it.
They should do so, in fact.
Nevertheless, the Microsoft textbook, I refered to, pointed out,
there would be routers, which do not support this feature
correctly. I did not test this myself (I have not that much routers
at home and I do not want to offend customers...), but I am
still quite careful on this one. Do you have any concrete experiences here?
(Nevertheless, a particular problem arises in networks, where
any kind of NAT or IPSec or similar are in effect, because these
techniques may inhibit "ICMP fragmentation needed and DF bit set"
from reaching the original sender.)
> The only "recent" change was in the Path MTU Discovery RFC, which
> recommends that this message also include the MTU that was
O.k., I see.
> If you're not getting the ICMP messages, it's not likely that it's
> because of a router that doesn't know how to send it. It's almost
> certainly because of a router or firewall in between that's
> filtering them out.
Hm. So, we must be sure, that the "evil" bit is not set in those
packets ;-)
(I presume, you know the RFC concerning the "evil bit"? It is one
of the best ones ever :-))
Vernon Schryver
Barry Margolin <barry.m...@level3.com> wrote:
>In article <aeh.105...@quest.cc.purdue.edu>,
>Dale Talcott <a...@quest.cc.purdue.edu> wrote:
> ...
>>I did not mean the results were strange, only that AIX traceroute was
>>different from many other traceroutes in attempting to do MTU discovery
>>at the same time.
>
>However, it seems like a nice additional feature. In addition to telling
>you the route, it also tells you about MTU differences along the way. This
>can be helpful in some kinds of troubleshooting.
> ...
Other versions of traceroute including years old copies
of ftp://ftp.ee.lbl.gov/traceroute.tar.Z
know about '-F' to 'Set the "don't fragment" bit' at least as
(That domain name should sound familiar.)
See also http://www.google.com/search?q=traceroute+man+fragment
Vernon Schryver v...@rhyolite.com