HP-UX TCP/IP Performance White Paper, March 2008

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. [0,3] Default: 1

Setting the value to one will mean that IP datagrams will always have the DF bit set. This is generally fine,

but there are still some broken setups out there that will filter-out ICMP "Fragmentation Needed" messages.

Trying to send IP datagrams with the DF bit set through such setups will create a "black hole" beyond which

systems are unreachable.

Setting the value to zero will mean that TCP will have to fall-back on other strategies to ensure that its

segments are not fragmented along the path to the destination. This could result in TCP using a Maximum

Segment Size (MSS) smaller than the maximum possible along that path. This can lead to decreased

performance.

Setting the value to 3 will result in the DF bit in the IP header being cleared, but will still have TCP select an

MSS based on the link-local MTU. In effect, it is a way for the network administrator to tell the transport

that all (sub)nets are local or that the network administrator is not at all concerned if traffic from this host

happens to become fragmented along the way.

ip_reass_mem_limit:

Sets an upper bound on the number of bytes IP will use for

packet reassembly. If the limit is reached, reassembly lists

are purged until the space required for the new fragments

becomes available. [-,-] Default: 2000000 bytes

It is rare that this value should need to be changed. Most of the time, the successive fragments of an IP

datagram will arrive fairly close to one another, and will not sit very long in the reassembly queue.

However, if "netstat -p ip" shows a large number of IP datagram fragments being dropped as dup's or for

lack of space, you might consider increasing this value. Before you do, check the frequency of such drops

so you can compare it to after you make the change. If the frequency remains the same after you have

increased the value, it implies that the IP fragment drops were the result of perceived duplicates and not

because there was not enough space.

If you see a large number of IP datagram fragment drops in the output of "netstat -p ip" you might also want

to check the frequency of UDP and TCP checksum failures with netstat -p udp and netstat -p tcp respectively.

There are "limitations" in IP version 4 which can lead to reuse of the IP datagram Identifier before fragments

can timeout in the reassembly area. This can mean that two otherwise unrelated, fragmented IP datagrams

could be reassembled into what one might call a "Frankengram" which will only be detected by the upper-

layer checksum.

The best course of action should this be happening would be to try to eliminate the fragmentation. The next

best course of action would be to try to further restrict the amount of time the system will "hang-on" to an IP

datagram fragment. For more discussion on this topic, read the discussion of the ip_fragment_timeout

tunable.

ip_send_redirects:

Set to 1 to allow IP send ICMP "Redirect" packets; set to 0 to

disable. [0,1] Default: 1 (enable)