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. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
