[squid-users] heart beet between squid peers

[Alex Rousskov]

On 02/02/2017 04:43 PM, salil GK wrote:

> we provide an interface for the admin to set
> whether forward proxy is enabled or not - and also specify which all
> peers need to be involved in the squid chaining ( parent child ). If I
> have say 4 machines - A,B,C and D. Admin can decide machine A and B are
> the child  and machine C and D as parents. Both A and B can use C and D
> as parents - for load balancing and redundancy. 
> 
> A -> parent -> C
> A -> parent -> D
> B -> parent -> C
> B -> parent -> D
> 
> In the UI interface admin will specify this. When it is done, in the
> back end I will create a tunnel and reconfigure squid config file and
> start squid. Now in the UI I need to specify whether every thing is
> perfect and A and B can talk to C and D seamlessly - or the traffic is
> perfect or not. Only if the traffic between squid A and squid C and
> squid D are perfect, I should mention that it is ACTIVE. For this I
> thought if have some mechanism in both sides to do ping kind of
> functionality, it would be good.

Thank you for detailing your problem!

Others on this list should be able to offer much better solutions, but
if you do not hear any, then I would use curl or wget(**) to send HTTP
requests to each child and have special rules in child squid.confs to
route those requests to the specified-in-the-request parent (probably by
matching a custom HTTP header). Your script can the analyze the Via
headers in each successful response to confirm that the transaction went
to the right parent.

Given your example above, four requests would be sufficient to confirm
connectivity. Please note that those requests cannot confirm whether A
is also _not_ using B as a parent and C is not using D as a parent (for
example). To prove all those "negatives", you will need a few more
requests (and possibly slightly fancier routing rules in squid.conf).

You may be able to send HTTP TRACE requests with Max-Forwards:1 header
if your Squids support that. That way, you will be testing the
connectivity between Squids without being dependent on the outside
connectivity and can analyze forwarded request headers as well, but this
is optional.


Needless to say, you can run a similar script/analysis every T minutes
if you wish to monitor connectivity continuously, after everything has
been configured. However, at runtime, your focus should be on monitoring
for errors, response times, hit ratios, and other measurements that may
reveal Squid problems.


FWIW, "pinging" in the reverse direction (e.g., from C to A) does not
make sense to me and should not be necessary to confirm connectivity
that normal requests will use.


HTH,

Alex.
(**) You may use squidclient as well but I do not recommend that because
it lacks polish and some advanced features that you may eventually find
useful.