Hello again,
a few days ago I described the following situation and problem,
where I am now able to provide a solution for:
> At least I would like a configurable option for the outgoing address
> in dependence of the destination sibling, to suite the following
> scenario:
>
> At two locations are running two (or even more) proxies with the
> following (sample) configuration:
>
> Interface Location A Location B
>
> le0 192.168.1.2 192.168.1.130
> le0:1 192.168.1.4 (192.168.1.4)
> le0:2 (192.168.1.132) 192.168.1.132
>
> The official proxy addresses are .4 and .132 and they are load balanced
> by DNS Round Robin.
> In the normal case the load is also balanced over the two machines. But
> in case of a failure of one machine (or location) the other location
> will become active and responsible for the failed IP-address.
>
> Because we don't want to announce the hard adresses to our customers,
> the proxies have to be configured with udp_outgoing_address
> .4 for location A and .132 for location B to be usefull two other
> proxies as parents or siblings. (Otherwise the siblings running with
> older squid versions will not receive or ignore the response, coming
> from an unexpected ip-address).
>
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 :-(
To fix this problem I created a new option: udp_outgoing_peer
If you're using this option, every neighbor requests are routed over this
IP-address instead of the default one (udp_outgoing_address).
For this I created a new fd 'thePeerIcpConnection' within the source,
and changed all relevant calls to use this fd.
(The fd is copied from 'theOutIcpConnection' if you're not using the
new option and would then cause no behavioral changes.)
The patch is included below; It should be usefull for others with an
equal redundant setup as we have and maybe so for similar ones.
If so, it may/should go into the distribution.
Enjoy,
Jan
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:45:42 MST