IP Fragment

[robert sears_1]

I have a 9000 (J210) series server running HP unix 10.2. This server is on a LAN with a class C block of IP's 206.36.246.0. This box has an IP of 206.36.246.98, it runs a web server and DNS for the LAN. On some LAN workstations FTP, TELNET and HTTP requests to this unix box take an incredibly long time, on other host it is an instantaneous return. All host including the HP box are on one single subnet with one default gateway. Out side users trying to get to the web page on the HP box get same results. A probe on our Network returned rusults stating the HP box, 206.36.246.98 was sending out IP fragment overlays. I am not sure what this is. Does this problem lye in the 10.x software or in the NIC/server hardware?

[James R. Ferguson]

Hi:

Have you ruled-out "reverse-name-lookup". Making sure that your device's name is represented in the DNS tables of the DNS server can eliminate timeout delays.

Reverse lookup is the process by which a server receiving a request for service from a remote machine ascertains whether the identity claimed by the machine is in fact its true one. The process goes like this:

1. The request arrives in a packet with an IP address indicating the point of origin.
2. The server queries name service on the net to find out what host name is associated with that IP address.
3. The server then queries name service to find out what IP address is associated with that host-name.
4. If this last request fails to find an IP address, or finds one that doesn't match the original, the request for service is rejected.

For an good description of reverse name lookup, see:

http://www.helpdesk.umd.edu/comm/ethernet/revlook.shtml

...JRF...

[Kofi ARTHIABAH]

Robert, I would suggest that you get a copy of lsof an run it on the hpux box to find out what is going on... there might be a program that is delibrately generating packets with overlaying fragments.

get lsof at
http://hpux.cs.utah.edu/hppd/hpux/Sysadmin/lsof-4.48/

[Anthony deRito]

The kernel tunable parameter you might want to look at is the "netmemmax" parameter. The value of this parameter is the maximum memory size that will be used during IP fragmentation re-assembly. Compare this value with that of yourother boxes.

When you are transmitting IP packets, they are (or can be)broken down into "fragments" based on different MTU sizes over its travel. Memory is reserved for these "fragments" to be re-assembled into the fully assembled packet.

It is very possible, if this parameter is set too high, for so much memory to be used in fragmentation re-assembly that you start having memory pressure on your system which in turn can slow things down. Default is 10% of memory.

Tony

[Alan Riggs]

I posted a reply in the other thread, but that thread seems to have disappeared. At first glance, this seems to be a name resolution issue.

Is the behavior consistent? Do the same workstations show slow connections every time?
If so, try telneting to the IP rather than the hostname, if the connection is fast then you have a name resolution problem on the workstation(s).

[James R. Ferguson]

Robert:

With regard to the kernel's 'netmemmax' as Tony mentioned, see document #S3100006392A.

...JRF...