Don't fragment bit in ip header set in 11.00

[Dale Barnes]

It appears the the behaviour of HP-UX has changed from 10.20 to 11.00 in that the
"don't fragment bit" in the ip header is now set under 11.00. This is causing a problem
at one of our sites which has their mtu set to 1480 (for reasons I don't really understand). None of my 11.00 machines can send packets greater that 1480 via
a ping while all of my 10.20 machines can. Does anyone know how to change
this behaviour? I.e., I would like to turn this "don't fragment" bit off.

[John Palmer · Accepted solution]

Excerpt from knowledge document id 275KBRC00002111 :-

The variable ip_pmtu_strategy controls the setting of the DF bit. When enabled
(1), all TCP datagrams will be transmitted with the DF bit set and this will
start the PMTU Discovery process. When disabled(0), the DF bit is not set. The
default is enabled(1).

On 11.0 the parameter is

ip_pmtu_strategy :

For Details regarding the parameter enter the following ndd command:

ndd -h ip_pmtu_strategy

To view the current setting or ip_pmtu_strategy:

ndd -get /dev/ip ip_pmtu_strategy

Default is 2


To disable the use of the DF flag and thus disable the path MTU
discovery, set ip_pmtu_strategy to 0.

ndd -set /dev/ip ip_pmtu_strategy 0



ndd settings will not survive a reboot, you will need to include
the parameters in the /etc/rc.config.d/nddconf file.

See man 1m ndd and the /etc/rc.config.d/nddconf file for more
information.

[Stefan Farrelly]

To set if off in HP-UX 11 you can either modify /etc/rc.config.d/nddconf or use the ndd command to set ip_pmu_strategy to 0 (no Path MTU discovery)

[Dale Barnes]

Thanks a bunch. This appears to have solved our problem!

[Dale Barnes]

The ip_pmtu_strategy setting to 0 has worked on a couple of my 11.00 machines,
but it doesn't appear to work on a couple of others! Anybody have a clue as to
why this works on some but not others?

[John Palmer]

Have you compared the Pmtu values from 'netstat -rn' obtained from one that works to one that doesn't?

Having set ip_pmu_strategy to 0, I wonder whether you need to reconfigure the LAN card?

Try 'ifconfig lan? 0.0.0.0'
then 'ifconfig lan? etc.

Or amend nddconf and reboot.

[Neal R. Fildes]

this thread has not run to 'completion' as I see it. I am in a similiar circumstance - customer does not want to move from k-class (10.20) to n-class because some dialup users evidently have a path with some element not supporting pmtu negotiation.

the ndd settings have 'stuck' so far (I would have preferred option '2' instead of zero but evidently that is not allowed anymore).

any more suggestions here? want to get on the new hardware we paid for!

would adjusting mtu on client end help? it is a character-oriented ap over a telnet type session.

also, if these particular users connect to the 'k/1020' box and then telnet over to the N-class their performance is good!

any help appreciated.

ip_pmtu_strategy was changed from 1 to zero with no help.

nrf