Floating IP, ping and source quench - wrong IP?

[Michael Burbury]

Hi all, OK I'm confused and would appreciate any insight.

I have two lan adaptors on the same subnet as follows:

Lan0: 192.168.136.145
Lan1: 192.168.136.146

I setup MC S/G to have the floating IP as 192.168.136.147 on Lan0:1

Then I ping the floating IP and see:

C:\> ping 192.168.136.147
Reply from 192.168.136.146: Source quench received.

If 192.168.136.147 is on Lan0:1 why would I get a source quench when pinging Lan0:1 from Lan1??

(Admittedly I was doing a Veritas netbackup of the system which uses Lan1 to perform the backup and hence lan1 was busy, but I was sending pings to lan0:1, not lan1??)

Any help or insight appreciated.

[Michael Tully]

Use ndd to disable the source quench message:
Have a look at this posting.

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

[Michael Burbury]

Thanks for the initial help on how to turn off the messages, but my question is really:

I am sending pings to LAN0:1, why is LAN1 responding with the source quench message to these pings?

I would have expected LAN1 to not be sending anything in reply to packets sent to LAN0:1 or LAN0??

Appreciate any insight. Cheers.

[melvyn burnard]

Well basically you cannot have two lan adaptors on the same subnet.
This gives many and varied issues, of which I believe this is one.

[Ron Kinner]

Contrary to what you would expect, routing algorithms do not care how the packet arrived or what its original destination address was. They only look at the routing table to see how to send the reply back to the original source which now becomes the destination. They then tack on a source address to match the interface they plan to use to send the packet out on.

Look at
netstat -rnv
to see the routing table but don't put a lot of trust in the number of uses per entry. I think netstat has a few bugs when used with multiple interfaces.

Ron

[Michael Burbury]

Ron,

10 points, I believe you hit the nail on the head.

Even if I'm pinging to the LAN0 adaptor, the system appears to use the default route to generate the packet replies and my default route goes out LAN1.

Well done, I didn't know it would do that until I ran my packet sniffer on the weekend and found that is actually what it really does, in fact all generated replies for all protocols seem to do this. Not a bad thing as all the inbound packets come in on LAN0 and the generated replies go out LAN1, so I call this my pseudo load balancing :)

[rick jones]

Support for multiple _physical_ NICs (physical from the standpoint of ifconfig/IP) is "interesting" as you have already seen. Traffic will be received on any interface, only one will be used for outbound.

There is a way to have source IP address included in the route lookup - it is by setting ip_strong_es_model to a value of 1. This causes the source IP address to be used in addition to the destination IP address when looking for the best match in the routing table.

As often as not, it will mean that a reply to a packet will be sent-out the interface with the matching source IP address.

The downside is that packets will only be accepted on interfaces with matching IP addresses - no more accepting a packet destined for the IPs on lan0 on the lan1 interface.

ftp://ftp.cup.hp.com/dist/networking/briefs/annotated_ndd.txt

[MANOJ SRIVASTAVA]

Hi Michel

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


here it goes :
This problem has been identified and is addressed in SR 5003435396.
This problem will be fixed in the 11.01 version of the HP-UX operating
system. These messages can be safely ignored as they have absolutely no
impact on the operating system (performance or otherwise). Alternatively
these messages can be prevented by disabling source quench. For more
information see the sections below.

What is causing these messages?

At 11.0 the Streams Xport layer now passes the ICMP echo request to any
other process that has a socket open and bound to raw IP. The rpcd
rpcd/dced deamon opens a raw socket to listen to ICMP messages. This raw
socket is open by icmp_monitor routine of rpcd. The main function of
this routine is to check for error messages from DCE servers registered
in endpoint database of the host and it checks the socket every 5
minutes. It does not respond to or use the ICMP echo requests; however,
the socket queue becomes filled during the 5-minute delay causing the
source quench message. The fix being implemented in 11.01 will be to
increase the buffer size to 128 K and shorten the wait interval from 5
minutes to 2 minutes, thereby flushing the queue of these unwanted
messages before the queue becomes filled.

Why is it safe to ignore these messages or to turn them off?

A good disscussion of this is in TCPIP Illustrated Volume 1,
by Richard Stevens, pages 160-162.Here is an excerpt from page 161:

Although RFC 1009 [Braden and Postal 1987] requires a
router to generate source quenches when it runs out of
buffers, the new router requirements RFC [Almquist 1993]
changes this and says that a router must not originate
source quench errors. The current feeling is to deprecate
the source quench error, since it consumes network bandwidth
and is an ineffective and unfair fix for congestion.

Also, see RFC 1812, section 4.3.3.3 Source Quench for a good
discussion of the issues.

Also RFC 2001 has discussion on Congestion and why TCP should handle
this not ICMP:

Congestion avoidance and slow start are independent
algorithms with different objectives. But when congestion
occurs, TCP must slow down its transmission rate of packets
into the network and then invoke slow start to get things
going again. In practice, they are implemented together.

Exactly how do I disable source quench?

You can disable source quench in HP-UX 11.0 by executing this command:

ndd -set /dev/ip ip_send_source_quench 0

To disable Source Quench so that it can survive a reboot,

modify the /etc/rc.config.d/nddconf file as follows :
TRANSPORT_NAME[X]=ip
NDD_NAME[X]=ip_send_source_quench
NDD_VALUE[X]=0

Where X is the next logical numerical sequence in a table
of values, with X starting at 0.
--------------------------------------------------

DCE patch and dependencies:

3 PHCO_23651 fsck_vxfs(1M) cumulative patch
2 PHCO_23876 cumulative SAM/ObAM patch
1 PHCO_25883 cumulative 10.20 libc compatibility support
3 PHKL_18543 PM/VM/UFS/async/scsi/io/DMAPI/JFS/perf patch
3 PHKL_20016 2nd CPU not recognized in G70/H70/I70
3 PHKL_23956 Profile, virtual timers and disabling fix
3 PHKL_24027 VxFS 3.1 cumulative patch
1 PHKL_25906 Probe,IDDS,PM,VM,PA-8700,asyncio,T600,FS
1 PHKL_25999 syscall, msem_lock, umask cumulative patch
2 PHSS_21614 HP DCE/9000 1.7 Runtime cumulative patch


You may like to do like this
ndd -set /dev/ip ip_send_source_quench 0


this is solve the issue.


Manoj Srivastava