Re: [squid-users] Forwarding loops...

On tor, 2008-07-17 at 08:17 -0700, John Doe wrote:
> So I did put back the tcp_outgoing_address.
> Will I have to use it forever or just for testing?

You should have it for as long as you are running multiple instances on
the same server..

> Does it have to be an IP different than the regular IP?

The main ip per instance is easiest.

> Again, post a bit long...
>
> squid1: 192.168.17.11 / tcp_ougoing 192.168.17.15
> squid2: 192.168.17.12 / tcp_ougoing 192.168.17.16
> squid3: 192.168.17.13 / tcp_ougoing 192.168.17.17
> squid4: 192.168.17.14 / tcp_ougoing 192.168.17.18
>
> digest_rebuild_period 10 minutes
>
> I start the squids after an rm of the cache_dirs.
>
> ### I ask squid1 for object1
>
> squid1:
> 1216303244.157 2 192.168.17.11 TCP_MISS/200 2901 GET http://192.168.16.23/index.html - FIRST_UP_PARENT/apache text/html
> squid2:
> 1216303243.855 0 192.168.17.11 UDP_MISS/000 52 ICP_QUERY http://192.168.16.23/index.html - NONE/- -
> 1216303244.155 0 192.168.17.15 TCP_MEM_HIT/200 477 GET internal://squid2/squid-internal-periodic/store_digest - NONE/- application/cache-digest
> squid3:
> 1216303244.053 0 192.168.17.11 UDP_MISS/000 52 ICP_QUERY http://192.168.16.23/index.html - NONE/- -
> squid4:
> 1216303243.314 0 192.168.17.11 UDP_MISS/000 52 ICP_QUERY http://192.168.16.23/index.html - NONE/- -
> Then, 1mn later, squid3:
> 1216303304.155 0 192.168.17.15 TCP_MEM_HIT/200 477 GET internal://squid3/squid-internal-periodic/store_digest - NONE/- application/cache-digest
> Then, 1mn later, squid4:
> 1216303364.156 0 192.168.17.15 TCP_MEM_HIT/200 477 GET internal://squid4/squid-internal-periodic/store_digest - NONE/- application/cache-digest
>
> ### I ask squid3 for object2
>
> squid1:
> 1216303708.034 0 192.168.17.13 UDP_MISS/000 55 ICP_QUERY http://192.168.16.23/img/spain.gif - NONE/- -
> 1216303708.324 0 192.168.17.17 TCP_MEM_HIT/200 477 GET internal://squid1/squid-internal-periodic/store_digest - NONE/- application/cache-digest
> squid2:
> 1216303707.821 0 192.168.17.13 UDP_MISS/000 55 ICP_QUERY http://192.168.16.23/img/spain.gif - NONE/- -
> squid3:
> 1216303708.330 6 192.168.17.13 TCP_MISS/200 7300 GET http://192.168.16.23/img/spain.gif - FIRST_UP_PARENT/apache image/gif
> squid4:
> 1216303708.242 0 192.168.17.13 UDP_MISS/000 55 ICP_QUERY http://192.168.16.23/img/spain.gif - NONE/- -
> Then, 1mn later, squid2:
> 1216303768.325 0 192.168.17.17 TCP_MEM_HIT/200 477 GET internal://squid2/squid-internal-periodic/store_digest - NONE/- application/cache-digest
> Then, 1mn later, squid4:
> 1216303828.326 0 192.168.17.17 TCP_MEM_HIT/200 477 GET internal://squid4/squid-internal-periodic/store_digest - NONE/- application/cache-digest
>
> ### Etc... Now all objects are randomly spread each on 1 unique squid.
> ### And in the meantime:
>
> squid2:
> 1216303945.412 0 192.168.17.18 TCP_MEM_HIT/200 477 GET internal://squid2/squid-internal-periodic/store_digest - NONE/- application/cache-digest
> squid3:
> 1216303950.276 0 192.168.17.16 TCP_MEM_HIT/200 477 GET internal://squid3/squid-internal-periodic/store_digest - NONE/- application/cache-digest
> Then, squid3:
> 1216304005.426 0 192.168.17.18 TCP_MEM_HIT/200 477 GET internal://squid3/squid-internal-periodic/store_digest - NONE/- application/cache-digest
> squid4:
> 1216304010.277 0 192.168.17.16 TCP_MEM_HIT/200 477 GET internal://squid4/squid-internal-periodic/store_digest - NONE/- application/cache-digest
>
> ### I do another round...
> ### Works well (3 UDP query and 1 HIT, unless the squid has it already) up to object5...
> ### Ask squid2 for object6 (squid1 has it, no UDP traffic in logs):
>
> squid2:
> 1216304170.370 1 192.168.17.12 TCP_MISS/200 9042 GET http://192.168.16.23/img/sweden.gif - FIRST_UP_PARENT/apache image/gif
> squid4:
> 1216304170.369 0 192.168.17.16 TCP_MISS/504 1585 GET http://192.168.16.23/img/sweden.gif - NONE/- text/html
>
> Then works again for a few objects...
> Then not: ask squid2 for object (no UDP traffic in logs).
>
> squid2:
> 1216304475.185 0 192.168.17.12 TCP_MISS/200 8486 GET http://192.168.16.23/img/polska.gif - CD_SIBLING_HIT/squid3 image/gif
> squid3:
> 1216304475.184 147 192.168.17.16 TCP_MEM_HIT/200 8392 GET http://192.168.16.23/img/polska.gif - NONE/- image/gif
>
> ### I do another round...
> ### ask squid2 for object1 (no UDP traffic)...
>
> squid1:
> 1216304762.804 0 192.168.17.16 TCP_MEM_HIT/200 3018 GET http://192.168.16.23/index.html - NONE/- text/html
> squid2:
> 1216304762.804 0 192.168.17.12 TCP_MISS/200 3112 GET http://192.168.16.23/index.html - CD_SIBLING_HIT/squid1 text/html
>
> ### ask squid4 for object2 (no UDP traffic)...
>
> squid2:
> 1216304825.551 0 192.168.17.18 TCP_MISS/504 1583 GET http://192.168.16.23/img/spain.gif - NONE/- text/html
> squid4:
> 1216304825.552 1 192.168.17.14 TCP_MISS/200 7300 GET http://192.168.16.23/img/spain.gif - FIRST_UP_PARENT/apache image/gif
>
> In fact, squid3 had it...

For some reason squid4 thought squid2 had the object, but it didn't (or
it had expired) so Squid4 recovered by going to apache. As there was no
UDP traffic it's most likely a digest false hit.

Regards
Henrik
Received on Fri Jul 18 2008 - 02:03:44 MDT