Re: udp_outgoing_peer (was: Re: squid.conf (udp_incoming/outgoing_address))

Hi,

> Jan Wedekind wrote:
>
> > To express in other words: a neighbor/peer request from Location A will
> > always have the source address 192.168.1.4. So the response from
> > Location B will go to this address, which itself is configured there.
> > So the response will never go to Location A :-(
>
> I don't understand your problem, or what you are trying to say above.
>
> udp_incoming_address is where Squid listens for queries from other
> peers. Replies to received queries are also sent using this address.
>
> udp_outgoing_address is what Squid uses when sending queries to other
> peers. Replies to those queries are also accepted on this address.
>
> >From your description it sounds like you only have reinvented
> udp_incoming_address. Or have I completely misunderstood what you are
> trying to do?
>
Mmh, let my try to explain our problem in other words or where it comes
from:

By running the proxy with the default (e.g. none) udp_outgoing_address,
we got the following problem:

jk@ciss.de (using squid 2.1.patch2) said:
> - squid's response after a few request:
> 'Detected DEAD Parent: www-proxy.de.uu.net/3128/3130' und
> 'WARNING: Ignored 10 replies from non-peer 192.76.144.30' oder
> 'WARNING: Ignored 10 replies from non-peer 192.76.144.140'

This is, because the official addresses of the proxy servers are
virtual interfaces / addresses on the server machines, but the
ICP-reply will get the hard interface address from the variable
theOutICPAddr in icpCreateMessage(), icp_v2.c line 109.
The reason for this behaviour may be version (at least 2.1.p2)
dependend, but after a brief look into the statistics I don't think
this. (It's also logical to identify the response after the IP-address
of the servers socket.)

So we switched to use 'udp_outgoing_address' at both servers with
happy customers. But the proxy no longer were able to use each other
as siblings for the following reason:

*Both* IP-addresses of www-proxy.de.uu.net are configured as virtual
interfaces at both machines at any time for *backup* reasons, so
that the servers can't use these addresses to ask each other:

An ICP request from location A (192.76.144.30) will leave
the server with an address (192.76.144.113) which is also configured
at location B (192.76.144.140).
Therefore any ICP response from there will be send to the local
configured interface to be dropped by squid itself as an unexpected
ICP-reply.

One solution to this problem is the provided patch, which will cause
to send (and receive) ICP Peer queries over a special
(here: hard) interface with a certain IP-address.

Jan

PS: As I reviewed the source I found a bug in my stuff,
    and I might append a diff to the diff from yesterday.

---
diff squid-2.2.peer-0.7.diff squid-2.2.peer-0.8.diff 
127c127
< --- squid-2.2.peer/src/icp_v2.c       Sun Apr  4 11:30:12 1999
---
> --- squid-2.2.peer/src/icp_v2.c       Mon Apr  5 03:12:12 1999
213c213
< --- 551,558 ----
---
> --- 551,560 ----
217,218c217,220
< +     assert(thePeerIcpConnection > -1);
< +     commSetSelect(thePeerIcpConnection, COMM_SELECT_READ, NULL, NULL, 0);
---
> +     if (thePeerIcpConnection != theOutIcpConnection) {
> +       assert(thePeerIcpConnection > -1);
> +       commSetSelect(thePeerIcpConnection, COMM_SELECT_READ, NULL, NULL, 0);
> +     }
224c226
< --- 562,573 ----
---
> --- 564,575 ----