ndd tcp_mss_max

[pat hayes]

I am being asked by my network guy, who recently implemented a Cisco VPN to one our of remote locations, to use the following command to correct sporadic socket errors:
ndd -set /dev/tcp tcp_mss_max 1460
When the VPN users get socket errors, they lose connection to the HP-UX server, however there session remains there and has to be aborted. The ndd command is in a document he obtained from Cisco for changing the MTU value on HP-UX 11.x. I see that tcp_mss_max is on the UNsupported list of ndd parameters and according to the man page, HP does not recommend modifications to these parameters. The network guy had asked me what the current MTU value was which I obtained with the lanadmin command and is 1500. However, if I do a ndd -get of tcp_mss_max, the value is currently set to 65495, not 1500. I'm concerned about the impact of this change on the frame users of our network and the unix users as well. I appreciate any information anyone has to offer, thanks.

[Jeff Schussele]

Hi,

tcp_mss_max is normally, by default, MTU - 40
So if your MTU is 1500 then I suspect the tcp_mss_max is 1460 already.
I would still probably go ahead (Somebody may have changed it) & do the
ndd -set /dev/tcp tcp_mss_max 1460
and then try a
ndd -get /dev/tcp tcp_mss_max
to see if the get reports the change.
Remember to set this value in /etc/rc.config.d/nddconf so the change survives reboots

But I would also test turning off Path MTU Discovery
ndd -set /dev/ip ip_path_mtu_discovery 0

The problem you're seeing is essentially a net device in the path that's either unable, unwilling or unaware of the need to fragment large packets. The network guy is implying that the device is the NIC in your host, but I doubt that because he asking you to *limit* the max packet size you send. That tells me something else in the path is likely the actual culprit. This change will probably stop the hung connections, but runs the risk of limiting performance in some conditions where large packets would be very advantageous.

BTW - Here's the Cisco page he's probably referencing:

http://www.cisco.com/warp/public/105/38.shtml

HTH,
Jeff

[Ron Kinner]

What Cisco forgets to tell you is that your changes will vanish with the first reboot. You need to edit /etc/rc.config.d/nddconf to make the changes stick after a reboot.

TRANSPORT_NAME[0]=ip
NDD_NAME[0]=ip_pmtu_strategy
NDD_VALUE[0]=0

TRANSPORT_NAME[1]=tcp
NDD_NAME[1]=tcp_mss_max
NDD_VALUE[1]=1460

Use the next higher integers in the brackets if you already have entries.

There is another way to control the MTU. The route command offers the option to set the MTU with -p 1460 and you can also set it in /etc/rc.config.d/netconf with
ROUTE_ARGS[0]="-p 1460"

Ron