lkml.org 
[lkml]   [1999]   [Feb]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: A router bug?
HP-UX 11 has a tunable, ip_pmtu_strategy, that has a workaround for
problems with PMTU. I think this scheme is from Mentat, but I'm not
sure. And I'm not sure how well it works in practice, but it might be
something to consider/think about.

From ``ndd -h ip_pmtu_strategy'':

ip_pmtu_strategy:

Set the Path MTU Discovery strategy: 0 disables Path MTU
Discovery; 1 enables Strategy 1; 2 enables Strategy 2.

Because of problems encountered with some firewalls, hosts,
and low-end routers, IP provides for selection of either
of two discovery strategies, or for completely disabling the
algorithm. The tunable parameter ip_pmtu_strategy controls
the selection.

Strategy 1: All outbound datagrams have the "Don't Fragment"
bit set. This should result in notification from any intervening
gateway that needs to forward a datagram down a path that would
require additional fragmentation. When the ICMP "Fragmentation
Needed" message is received, IP updates its MTU for the remote
host. If the responding gateway implements the recommendations
for gateways in RFC 1191, then the next hop MTU will be included
in the "Fragmentation Needed" message, and IP will use it.
If the gateway does not provide next hop information, then IP
will reduce the MTU to the next lower value taken from a table
of "popular" media MTUs.

Strategy 2: When a new routing table entry is created for a
destination on a locally connected subnet, the "Don't Fragment"
bit is never turned on. When a new routing table entry for a
non-local destination is created, the "Don't Fragment" bit is
not immediately turned on. Instead,

o An ICMP "Echo Request" of full MTU size is generated and
sent out with the "Don't Fragment" bit on.

o The datagram that initiated creation of the routing table
entry is sent out immediately, without the "Don't Fragment"
bit. Traffic is not held up waiting for a response to the
"Echo Request".

o If no response to the "Echo Request" is received, the
"Don't Fragment" bit is never turned on for that route;
IP won't time-out or retry the ping. If an ICMP "Fragmentation
Needed" message is received in response to the "Echo Request",
the Path MTU is reduced accordingly, and a new "Echo Request"
is sent out using the updated Path MTU. This step repeats as
needed.

o If a response to the "Echo Request" is received, the
"Don't Fragment" bit is turned on for all further packets
for the destination, and Path MTU discovery proceeds as for
Strategy 1.

Assuming that all routers properly implement Path MTU Discovery,
Strategy 1 is generally better - there is no extra overhead for the
ICMP "Echo Request" and response. Strategy 2 is available
only because some routers, or firewalls, or end hosts have been
observed simply to drop packets that have the DF bit on without
issuing the "Fragmentation Needed" message. Strategy 2 is more
conservative in that IP will never fail to communicate when using
it. [0,2] Default: Strategy 2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.200 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site