Sending Source Quench

[KHuysmans]

Dear,
I am a network administrator and users complain about problems using applications/services hosted on our HP-UX machine.
We are running this version:
HP-UX goliath B.11.11 U 9000/800 589716547 unlimited-user license

When I test from the switch where the Unix Cluster is connected to, the HP-UX replies with a lot of ICMP Source Quench messages.
Example (I am sending 5000 ICMP packets with a 500 bytes payload):
Success rate is 9 percent (489/5000), round-trip min/avg/max = 1/1/4 ms

Please note that there is no loss due to timeout, only source quenche messages.

In our cluster we have 2 machines, each with 2 NIC's (1 being a redundant one). All 4 network cards are configured with 100Mb Full Duplex and the switch ports accordingly.

I am trying to further troubleshoot this on the HP-UX to find out what is causing it to send the ICMP SQ messages.

Any and all suggestions are appreciated.

With kind regards,
Kevin Huysmans
---
Network Administrator
Arvato Services Belgium

[Steven E. Protter · Accepted solution]

Shalom Kevin,

It is probably the default behavior of the OS or the system was configured to work this way.

It can be changed.

If it is a patching issue:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=689778

Another possible cause:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=123369

A ndd command line fix.
http://forums1.itrc.hp.com/service/forums/bizsupport/questionanswer.do?threadId=793089

Please let me know if this is helpful.

SEP

[Alan Casey]

A source quench received message usually comes from a router in the path the ping was headed.
They do this when they start to become saturated with traffic. They deal with the saturation by starting to discard "low-priority" traffic of which ICMP traffic is one of the first. Ping uses ICMP traffic.

[James R. Ferguson]

Hi Kevin:

Source quench messages expose flow-control problems. Have a look at Technical Knowledge Base document #4000105473 for more information.

Regards!

...JRF...

[KHuysmans]

Steven,
Thanks for your tips. What interests me a lot would be to read about the "other possible cause" you mention, but the link you offer points to a thread which points to another thread which is no longer available.

Alan,
Thanks. There is no router in this path, I am testing this from the LAN switch (Cisco Catalyst 6509) where the HP-UX is attached to.

James,
More information on how to trouble-shoot flow-control problems sounds like something I very much would like to have. Unfortunately the HP Openview technical knowledge base does not recognize a document with ID 4000105473.

Kind regards,
Kevin

[Steven E. Protter]

There is more material available.

In the search box above type:

Source Quench

You'll get more.

I can validate the links I post are okay, but not the links inside the links.

SEP

[James R. Ferguson]

Hi (again) Kevin:

The document ID #4000105473 works for the ITRC Technical Knowledge Base. Make sure that you choose "Select by Doc ID".

Regards!

...JRF...

[Tom Ward_1]

Some security folks advise turning off source quench. Take a look at the HP security bulletin HPSBUX01164
http://www2.itrc.hp.com/service/cki/docDisplay.do?docId=HPSBUX01164

from
http://www.gont.com.ar/drafts/draft-gont-tcpm-icmp-attacks-05.txt

6.1. Description

The Host requirements RFC [RFC1122] states that hosts MUST react to
ICMP Source Quench messages by slowing transmission on the
connection. Thus, an attacker could send ICMP Source Quench (type 4,
code 0) messages to a TCP endpoint to make it reduce the rate at
which it sends data to the other end-point of the connection.
[RFC1122] further adds that the RECOMMENDED procedure is to put the
corresponding connection in the slow-start phase of TCP's congestion
control algorithm [RFC2581]. In the case of those implementations
that use an initial congestion window of one segment, a sustained
attack would reduce the throughput of the attacked connection to
about SMSS (Sender Maximum Segment Size) [RFC2581] bytes per RTT
(round-trip time). The throughput achieved during attack might be a
little higher if a larger initial congestion window is in use
[RFC3390].

6.2. Attack-specific counter-measures

The Host Requirements RFC [RFC1122] states that hosts MUST react to
ICMP Source Quench messages by slowing transmission on the
connection. However, as discussed in the Requirements for IP Version
4 Routers RFC [RFC1812], research seems to suggest ICMP Source Quench
is an ineffective (and unfair) antidote for congestion. [RFC1812]
further states that routers SHOULD NOT send ICMP Source Quench
messages in response to congestion. On the other hand, TCP
implements its own congestion control mechanisms [RFC2581] [RFC3168],
that do not depend on ICMP Source Quench messages. Thus, hosts
SHOULD completely ignore ICMP Source Quench messages meant for TCP
connections.

This behavior has been implemented in Linux [Linux] since 2004, and
in FreeBSD [FreeBSD], NetBSD [NetBSD], and OpenBSD [OpenBSD] since
2005.

HTH,
Tom