Simpler Navigation for Servers and Operating Systems - Please Update Your Bookmarks
Completed: a much simpler Servers and Operating Systems section of the Community. We combined many of the older boards, so you won't have to click through so many levels to get at the information you need. Check the consolidated boards here as many sub-forums are now single boards.
If you have bookmarked forums or discussion boards in Servers and Operating Systems, we suggest you check and update them as needed.
General
cancel
Showing results for 
Search instead for 
Did you mean: 

Packets gets dropped, dont defragmnet bit ??

Q4you
Regular Advisor

Packets gets dropped, dont defragmnet bit ??

It looks like on one of the HPUX machine, all the datagrams are coming across with the DF(don't fragment bit) set. So when a large ping comes across from that system it has the DF MF bits set, this is invalid and the packet is dropped from the mainframe side.

Is there any parameter which can change this behaviour ?
1 REPLY
James A. Donovan
Honored Contributor

Re: Packets gets dropped, dont defragmnet bit ??

Sounds like you may need to alter the ip_pmtu_strategy on your server.


> 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
Remember, wherever you go, there you are...