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

48
There are two most common ways to identify the overflowing UDP socket:
• ndd –get /dev/ip ip_udp_status lists the UDP fanout table and one of the columns is
“overflows”. If the UDP port is long-lived, this will tell which UDP socket is experiencing the
overflows.
• Collect a network trace during one of the overflows and look for an ICMP SOURCE QUENCH
packet. If the SOURCE QUENCH was generated because of a UDP socket overflow, the SOURCE
QUENCH packet will tell you which UDP socket is overflowing.
IPv4:
36340838 total packets received
The total number of IP datagrams received by this host.
13 bad IP headers
Bad headers could include IP header checksum failures, or unrecognized options and the like.
11 fragments received
The total number of IP datagram fragments received. This is not enough data to tell how many fragmented
IP datagrams were received however - as there is no data on the distribution of fragments per datagram.
0 fragments dropped (dup or out of space)
An increment in this statistic could mean possible Frankengram situation when the fragments are reported
duped, or simply that the fragments are indeed being duplicated by the network. The "out of space" can
arise from packet loss rates and settings on the limits of memory consumed by IP fragment reassembly.
(ip_reass_mem_limit – see Appendix B for guidelines on setting the ip_reass_mem_limit in some
conditions.)
0 fragments dropped after timeout
The only time there should be fragments dropped after timeout is when there is packet loss in the network.
In those cases, it is possible that a high-enough rate of IP datagram fragments from a remote system could
wrap the 16-bit IP Datagram ID field and result in "Frankengrams" coming-out of IP fragment reassembly.
This is a fundamental problem with IPv4 and not necessarily a bug in any specific implementation.
"Frankengrams" are when the fragments of two otherwise unrelated IP datagrams which happened to have
the same IP Datagram ID are joined into one datagram - some fragments from one datagram, some
fragments from the other.
The only thing that will detect this in the Transport would be the ULP (Upper Layer Protocol - eg UDP or TCP)
Internet Checksum. So, one should _NEVER_ disable UDP checksums. Otherwise, it is up to the application
to detect lest there be silent data corruption.
TCP does much to avoid IP fragmentation, and so using TCP instead of UDP would be a decent workaround
from that standpoint, but the workaround is not complete - especially if PathMTU discovery is disabled
(ip_pmtu_strategy), or TCP is told to not adjust its send sizes based on the ICMP Fragmentation
Needed messages generated by PathMTU Discovery (tcp_ignore_path_mtu).