Problems with ICP on 2.0-RELEASE

From: David Darville <david@dont-contact.us>
Date: Sun, 11 Oct 1998 14:39:59 +0100

I have a machine configured with 2 instances of squid running. Each
squid has it's outgoing addresses bound to a different interface, and
the caches are configured as each others siblings (with the proxy-only
option enabled), and I have it running with V1.1.22. But now I want to
upgrade to 2.0-RELEASE, and I have been able to get each squid to work
separately, but I have not been able to get the sibling relationship to
work. When I request an URL from one of the squid's, which I know is
cached on the other, it still fetches the URL direct, to try to clear
up the situation, I have run it with some debugging enabled
(debug_options ALL,1 12,9 15,9 44,9 seemed OK), I get the following
log:

1998/10/11 13:40:29| peerSelect: http://www.internic.net/
1998/10/11 13:40:29| peerSelectFoo: 'GET www.internic.net'
1998/10/11 13:40:29| peerSelectFoo: direct = DIRECT_MAYBE
1998/10/11 13:40:29| peerSelectIcpPing: http://www.internic.net/
1998/10/11 13:40:29| neighborsCount: 1
1998/10/11 13:40:29| peerSelectIcpPing: counted 1 neighbors
1998/10/11 13:40:29| peerSelect: Doing ICP pings
1998/10/11 13:40:29| neighborsUdpPing: Peer 130.225.71.227
1998/10/11 13:40:29| neighborsUdpPing: pinging peer 130.225.71.227 for
'http://www.internic.net/'
1998/10/11 13:40:29| neighborsUdpPing: key =
'91BAE14A0EF398EF90B9B47E8F4265B9'
1998/10/11 13:40:29| neighborsUdpPing: reqnum = 1
1998/10/11 13:40:29| icpUdpSend: FD 48 sending ICP_QUERY, 49 bytes to
130.225.71.227:10004
1998/10/11 13:40:29| peerSelectFoo: 0 ICP replies expected, RTT 2000
msec
1998/10/11 13:40:29| peerSelectFoo: After peerSelectIcpPing.
1998/10/11 13:40:29| whichPeer: from 0.0.0.0 port 0
1998/10/11 13:40:29| whichPeer: from 0.0.0.0 port 0
1998/10/11 13:40:29| whichPeer: from 0.0.0.0 port 0
1998/10/11 13:40:29| whichPeer: from 0.0.0.0 port 0
1998/10/11 13:40:29| peerSelect: DIRECT/www.internic.net
1998/10/11 13:40:29| peerSelectCallback: http://www.internic.net/
1998/10/11 13:40:29| icpHandleUdp: FD 48: received 45 bytes from
130.225.71.227.
1998/10/11 13:40:29| icpHandleIcpV2: ICP_HIT from 130.225.71.227 for
'http://www.internic.net/'
1998/10/11 13:40:29| neighborsUdpAck: opcode 2
'91BAE14A0EF398EF90B9B47E8F4265B9'
1998/10/11 13:40:29| whichPeer: from 130.225.71.227 port 10004
1998/10/11 13:40:29| neighborsUdpAck: Unexpected ICP_HIT for
91BAE14A0EF398EF90B9B47E8F4265B9

I have even tried to increase the icp_query_timeout to 60000, without
change - and I can see that it does not wait 60 seconds before timing
out the ICP query, and therefore I conclude that the ICP query mush
time out very quickly - before the other quid has a chance to answer.

- David Darville

PS. The platform is a Linux (Intel, RH5.1), and the Squid-2.0-RELEASE
is build with the --enable-async-io and ---enable-snmp options enabled.
Received on Sun Oct 11 1998 - 05:45:16 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:42:25 MST