Ping Reply

[nibble]

guys, we issued a ping to one of our servers and we got this reply:

Reply from 192.169.100.5: Source quench received.
Reply from 192.169.100.5: Source quench received.

may i know whats the meaning of this? any recommendations?

[Michael Tully]

Hi,

If it is on HPUX 11, then you need to set the ip_send_source_quench:
parameter to 0 which is a non default value

# /usr/bin/ndd -set /dev/ip ip_send_source_quench 0

HTH
Michael

[Michael Tully]

One thing I forget to mention, is that you may need to set this permanently in the system config files. Next time your system reboots, the setting will be lost.

Modify the /etc/rc.config.d/nddconf fileas below:

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

Again use zero as the value.
Save the file, do not keep an old copy here, if you must keep a copy place it elsewhere.

[Jeff Schussele]

Hi,

A source-quench request comes from a device mid-stream (usually a router) stating that the sender is saturating it & please stop - the packets are discarded & that message sent back. Pings are ICMP packets & as such are considered "low priority" packets and therefore the first to be asked to cease.

Rgds,
Jeff

[Michael Tully · Accepted solution]

Here is an explantion from the technical knowledge base:

Document #S3100005739 states, in part:

PROBLEM: Upon pinging an 11.0 system, I am seeing a packet loss and Internet Control Message Protocol (ICMP) source quench messages.

RESOLUTION

ICMP source quench messages are generated when an IP packet is received by the 11.0 system that can't be delivered to the socket buffer of the receiving application. The intent is to inform the sender of the full buffer condition so the rate of the transmission
is slowed down until the buffer can be read by the receiving application.

Setting the ndd parameter ip_send_source_quench to 0 can be an effective way to deal with the messages. Programs that use icmp protocol, such as ping, use a type of
socket called SOCK_RAW. The nature of using raw IP sockets is that ALL packets received that match the protocol type of the raw socket are delivered to ALL the sockets using that protocol. It is up to the application to read all the data in it's socket buffer and discard the data it's not interested in. If any of these sockets are full, the icmp source quench message will be generated.

[nibble]

ok thanks. btw, up to what level is this problem can be rated?

high? medium? low? or can be ignored? you see, this server is actually a production.

[Jeff Schussele]

That all depends on just what you're using the pings for.

If you're using pings to determine a remote system's health - this could be high and you'd need to ask the network folks to turn off that device's ability to quench or discard those packets OR find another means to determine health (response to a telnet request?)

If you were just pinging manually, I wouldn't set that very high.

But in any case you need to question the network people as to "health" of the network, i.e. are you nearing saturation? Do we need a fatter pipe? etc. Because nothing is more frustrating than network issues like lost packets or packets rec'd out-of-order. Really slows everything down.

Rgds,
Jeff

[Ron Kinner]

This is not a network issue. It's a well known bug in 11.0. See my original post and the resulting replies:

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

Sanjay's link is now obsolete and as usual the HP's lame search engine can't find it but I pulled it from my email files where I sent it to my HPUX sysadmin. The full text of the article follows:

"PROBLEM
Upon pinging an 11.0 system, I am seeing a packet loss and Internet
Control Message Protocol (ICMP) source quench messages.

Why am I getting these messages?

CONFIGURATION
Operating System - HP-UX
Version - 11.0
Subsystem - Internet Control Message Protocol (ICMP)
RESOLUTION
ICMP source quench messages are generated when an IP packet is
received by the 11.0 system that can't be delivered to the socket
buffer of the receiving application. The intent is to inform the
sender of the full buffer condition so the rate of the transmission
is slowed down until the buffer can be read by the receiving
application.

Setting the ndd parameter ip_send_source_quench to 0 can be an
effective way to deal with the messages.

Programs that use icmp protocol, such as ping, use a type of
socket called SOCK_RAW. The nature of using raw IP sockets is
that ALL packets received that match the protocol type of the raw
socket are delivered to ALL the sockets using that protocol. It is
up to the application to read all the data in it's socket buffer
and discard the data it's not interested in. If any of these
sockets are full, the icmp source quench message will be generated.

One process that uses one of these sockets is part of DCE, and it
is 'rpcd'. This program opens a raw socket in order to listen for
icmp messages, which it uses to monitor the health of other systems
on the network running DCE. 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."

As you can see the quick fix is to just make the ndd change suggested by Michael. This can be done without a reboot and should not cause a disruption of your production system. Make sure you make the changes to nddconf too so that it stays after a reboot.

The long term fix is to install the patch assuming that it still exists. As ours was also a production system we just put in the ndd change and have been working happily ever since.

Ron