Netstat -p udp shows socket overflows errors

[Enrico Farneti]

I work in a HPUX11 L1000 environment with a LAN that receives from external devices a big UDP traffic.
I suspect that part of this traffic is lost and I am investigating about this issue.
With the command 'netstat -p udp' I see a very big number associated to the 'socket overflows' item; this increases about 300 unit/sec.
Is this a problem? Can this be related to a not well sized UDP receive buffer?
In this last case what is the HPUX parameter to increase to solve the problem?
Thank you for the help,
Enrico.

[Uday_S_Ankolekar]

To isolate the connection the overflows were created on use the ndd command

# ndd -get /dev/udp ip_udp_status

In the output
The third field from the left, lport, is the UDP applications listener
port. This value is in hex, convert this to decimal to see which UDP port
the application is running on.

Then using lsof the process i.d. and program name can be found.
./opt/lsof -i | grep 49241

Lsof can be found in hp porting site.
http://hpux.cs.utah.edu/hppd/

Goodluck
-USA..

[Jeff Schussele]

Believe you have to set the following:

udp_xmit_hiwat
udp_recv_hiwat

using ndd to increase UDP buffers.

Rgds,
Jeff

[Ron Kinner]

You may just be seeing the cause of my source quench problem. You might want to install PHSS_17810:

In this case 'rpcd' used a 32K buffer,
and processed the messages received every 5 minutes, which led to
the buffer full condition.

PHSS_17810 addresses the problem by increasing
the buffer size to 128K and processing the messages every 2 minutes.

What sort of NICs are you using? I had some that were known to be sensitive to EMF and which would sometimes make packets vanish with no trace.

What does:
lanadmin
lan
display
show for the NIC in question? (Especially the second pagte of the display.

Switches often have a limit on the number of broadcasts that are allowed. Are your udp packets being broadcast are sent to a particular address?

Have you put a sniffer on the LAN? You can get demo, shareware and freeware sniffers if you don't own a dedicated one. They run on most window boxes or you can get tcpdump for UNIX. It's amazing how much junk traffic gets on there. It's not just Microsoft either. Compaq's have about 6 different management services which run by default and they clutter up the LAN quite a bit.

Ron

[Peter Eisentraeger]

I had a few times the same problem on a L1000. The socket overflows came from a hanging nfs process. Sometime we needed to restart the nfs-services but somtime nothing helped than a reboot.

[Enrico Farneti]

Hello folks,
thank you for your answers. It will follows some other details and questions about the problem reported:

1) To Uday: I already know in other ways the udp port and the application that cause the overflow. The problem is how to solve this behaviour.

2) To Jeff: using ndd on L1000 and HP-UX11, the ndd command doesn't recognize the parameters udp_xmit_hiwat and udp_recv_hiwat; they aren't valid parameters!

Valid parameters are only the following:
# ndd -h|grep udp
ip_udp_status - Reports IP level UDP fanout table
udp_def_ttl - Default TTL inserted into IP header
udp_largest_anon_port - Largest anonymous port number to use
udp_status - Get UDP instances information.
udp_do_checksum - Compute UDP datagram checksum
udp_pass_up_icmp - Controls the delivery of ICMP messages to
udp_pass_up_options - Controls the delivery of options to user
udp_smallest_anon_port - Smallest anonymous port number to use
udp_smallest_nonpriv_port - Smallest port number non-privileged processes
udp_wroff_extra - Header space for link layer header


Where did you find the suggested parameters to increase the size of the UDP buffers?
Are there other valid parameters for HP-UX11?

3) To Ron: now I have not the possibility to test the patch.
With reference to NIC information, here is the lanadmin output:

Description = lan0 Hewlett-Packard 10/100 TX Full-Duplex TT = 1500
Type (value) = ethernet-csmacd(6)
MTU Size = 1500
Speed = 100000000
Station Address = 0x306e0664d9
Administration Status (value) = up(1)
Operation Status (value) = up(1)
....
Index = 1
Alignment Errors = 0
FCS Errors = 0
Single Collision Frames = 0
Multiple Collision Frames = 0
Deferred Transmissions = 0
Late Collisions = 0
Excessive Collisions = 0
Internal MAC Transmit Errors = 0
Carrier Sense Errors = 0
Frames Too Long = 0
Internal MAC Receive Errors = 0

The udp packets are sent to a particular address.
I think I will use also a sniffer to continue the analysis of the problem.

4) To Peter: we don't use nfs.


If you have other suggestions to solve the problem, you are welcome!

Thank you to everyone.
Regards,
Enrico.

[Jeff Schussele]

Hi (again)

I have to admit that I didn't check on an HP before I answered - did not have access at that time. These parms ARE spelled out in the RFC & are implemented by both SUN & Micr$oft. BUT...are NOT implemented by HP.
So it appears to me that there is no, at least apparent, way to adjust UDP buffers in HP-UX...unless I'm missing something here.
Any UDP experts out there know different?

Sorry,
Jeff

[T G Manikandan]

If you are using the server as NFS server then increase NUM_NFSD and NUM_NFSIOD in the /etc/rc.config.d/nfsconf file.
By default the value is 4,increase them to 16.

Then
/sbin/init.d/nfs.server stop
/sbin/init.d/nfs.server start

Thanks

[T G Manikandan]

check this document

http://us-support2.external.hp.com/cki/bin/doc.pl/sid=8bd97ad401d51bd988/screen=ckiDisplayDocument?docId=200000042773864

Also check for the latest NFS patch
PHNE_25234

Thanks