Minutes after posting the question I think I have found the solution
with never_direct allow acl.
Regards,
Lucio Jankok
On 12/7/04 9:26 PM, "Lucio Jankok" <lj@2u2.nu> wrote:
>
>
>
> On 12/7/04 9:13 PM, "L. Jankok" <lj@2u2.nu> wrote:
>
>>
>> I wonder if the following is related to bug ID 528.
>>
>> I have a squid configuration with the following configuration;
>>
>> #
>> acl stream dst 81.173.0.0/255.255.224.0
>> acl stream dst 160.68.101.40/255.255.255.255
>> acl stream dst 62.103.164.227/255.255.255.255
>> acl stream dst 62.250.12.50/255.255.255.255
>> acl stream dst 213.133.46.20/255.255.255.255
>> acl stream dst 217.118.160.0/255.255.255.192
>> acl stream dst 145.58.0.0/255.255.0.0
>>
>> ##
>> ## The netcache app
>> ##
>> cache_peer 10.10.10.30 parent 3128 0 no-query proxy-only
>
> This must be 10.11.30.24, which is also the case in the config
>
>> #
>>
>> ##
>> #
>> cache_peer_access 10.11.30.24 allow stream
>> cache_peer_domain 10.11.30.24 .rtl7.nl .vuurwerk.net .vuurwerk.nl
>> .media002.is.nl .omroep.nl .garnierprojects.nl
>> cache_peer_domain 10.11.30.24 .garnierprojects.com .rtl.nl .xs4all.nl
>> .emptydirectoryradio.com .hollandmediagroep.nl
>>
>> What happens is pretty peculair. Although I try to catch the destinations
>> using both their domain as the subnet
>> they fall in, eventually some of those destinations will go to the default
>> route instead of being forwarded to
>> the netcache app.
>>
>> Could somebody shed some lights on this?.
>>
>> Regards,
>>
>> Lucio Jankok
>
>
Received on Tue Dec 07 2004 - 14:09:07 MST
This archive was generated by hypermail pre-2.1.9 : Sat Jan 01 2005 - 12:00:01 MST