ICMP and IP source quenching

[Byron Myers]

Long explanation, but all is relavant.
We have applications (SAP GUI) frequently getting TCP ERRORS. I believe the problem to be in the networking equipment somewhere (So does HP support), but our LAN engineer is adamant that the problem lies on our HP server's internal NIC's. They are L2000's - 100 Mbit full duplex ethernet. All latest patches have been installed, duplex settings confirmed on servers and switch. Our LAN engineer sends 100 pings to each NIC and he get "source quenching" messages, and he concludes that there is a problem with the NIC.

My stance is that pinging (ICMP) uses raw sockets, and that the messages he is seeing is from the server telling him to slow down. When I set the network parameter ip_send_source_quence (via ndd) to off (0), he says everything looks good now - but that is because the server is no longer replying with the source quench messages to slow down.

What are your opinions?
Am I totally off base here?

All responses are greatly appreciated.

[Rita C Workman · Accepted solution]

Did a little research on source_quenching issue and posted a reply...here's the thread:

http://forums.itrc.hp.com/cm/QuestionAnswer/1,1150,0xea6837f45ef7d4118fef0090279cd0f9,00.html

Hope this helps,
/rcw

[Plamen SIMEONOV]

Hi,

Would you try this command:
ndd -get /dev/ip ip_send_source_quench
see and remember the answer. (I think will be 1). After thatL
ndd -set /dev/ip ip_send_source_quench 0

Check again your application.
If the problem isn't exists - edit the file:
/etc/rc.config.d/nddconf like this:

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


Plamen

[Byron Myers]

Thanks.
It looks like the answer is indeed to set ip_source_quench=0. This, apparently, not only disables the source quence messages but also improves performance. At minimum, this will allow us to continue investigating our network problems (if they continue to exist) with our network engineer.

[rick jones]

Methinks your LAN engineer could stand a bit more training. As you suspected, NICs do not send ICMP source-quench messages.

Generally, I thought HP-UX 11 only tended to send source-quench messages when a UDP socket overflowed. You might examine the output of "netstat -p udp" and also perhaps "ndd /dev/ip ip_udp_status" and look for dropps. I would have thought that TCP's windowing would have precluded source quenches for TCP, and I doubt that IP itself could become bottlenecked. Anyhow...

If you are having problems with TCP connections try to get the app to give the actual raw errno value. Also, see what netstat -p tcp reports - especially on the sender. Look for retransmissions, retransmission timeouts, checksum failures, out-of-order packets, and if you establish and tear-down TCP connections with frequency, look for connection drops due to full queue.

If you see retrans and such, start working the stats down the stack and across to the other side - lanadmin for HP-UX NICs, SNMP or switch local for the switches and so on.