Re: [squid-users] How to use tcp_outgoing_address with cache_peer

On Tue, Apr 30, 2013 at 9:16 AM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
> On 30/04/2013 2:49 a.m., Alex Domoradov wrote:
>>
>> On Mon, Apr 29, 2013 at 4:57 PM, Amos Jeffries <squid3_at_treenet.co.nz>
>> wrote:
>>>
>>> On 26/04/2013 10:57 p.m., Alex Domoradov wrote:
>>>>
>>>> On Fri, Apr 26, 2013 at 12:31 PM, Amos Jeffries <squid3_at_treenet.co.nz>
>>>> wrote:
>>>>>
>>>>> On 26/04/2013 8:37 p.m., Alex Domoradov wrote:
>>>>>>
>>>>>> First of all - thanks for your help.
>>>>>>
>>>>>>> Problem #1: Please upgrade your Squid.
>>>>>>>
>>>>>>> Squid-2.6 has been 3 years since the last security update, nearly
>>>>>>> 5
>>>>>>> years
>>>>>>> since your particular version was superceded.
>>>>>>
>>>>>> ok, I will update to the latest version
>>>>>>
>>>>>>> On 24/04/2013 12:15 a.m., Alex Domoradov wrote:
>>>>>>>>
>>>>>>>> Hello all, I encountered the problem with configuration 2 squids. I
>>>>>>>> have the following scheme -
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> http://i.piccy.info/i7/0ecd5cb8276b78975a791c0e5f55ae60/4-57-1543/57409208/squids_schema.jpg
>>>>>>
>>>>>>
>>>>>>> Problem #2: Please read the section on how RAID0 interacts with Squid
>>>>>>> ...
>>>>>>> http://wiki.squid-cache.org/SquidFaq/RAID
>>>>>>>
>>>>>>> Also, since youa re using SSD, see #1. The older Squid like 2.6 push
>>>>>>> *everything* through disk which reduces your SSD lifetime a lot.
>>>>>>> Please
>>>>>>> upgrade to a current release (3.2 or 3.3 today) which try to avoid
>>>>>>> disk
>>>>>>> a
>>>>>>> lot more in general and offer cache types like rock for even better
>>>>>>> I/O
>>>>>>> savings on small responses.
>>>>>>
>>>>>> ok. The main reason why I choose raid0 is to get necessary disk space
>>>>>> ~400
>>>>>> Gb.
>>>>>
>>>>>
>>>>> It does not work the way you seem to think. 2x 200GB cache_dir entries
>>>>> have
>>>>> just as much space as 1x 400GB. Using two cache_dir allows Squid to
>>>>> balance
>>>>> teh I/O loading on teh disks while simultaenously removing all
>>>>> processing
>>>>> overheads from RAID.
>>>>
>>>> If I understood you correctly in my environment will be more
>>>> preferable to use something like
>>>>
>>>> SSD1 /dev/sda
>>>> SSD2 /dev/sdb
>>>>
>>>> # mount /dev/sda /var/spool/squid/ssd1
>>>> # mount /dev/sdb /var/spool/squid/ssd2
>>>>
>>>> and point squid to use 2 separate disk space
>>>> cache_dir aufs /var/spool/squid/ssd1 200000 16 256
>>>> cache_dir aufs /var/spool/squid/ssd2 200000 16 256
>>>
>>>
>>> Yes that is the idea.
>>
>> I see, and on which disks in that case would be place files? It would
>> be something like round robin?
>
>
> The default is for each transaction response to be stored on the currently
> least loaded directory:
> http://www.squid-cache.org/Doc/config/store_dir_select_algorithm/
>
>
>>
>>> So you see the packets "exiting" machine A and never arriving on machine
>>> "B". With only a wire between them that is unlikely.
>>> As I said before the firewall has to be getting in the way somewhere.
>>> There
>>> are several layers of components involved with the firewall these days
>>> and
>>> each end of the link has its own version of the same layers of
>>> components.
>>>
>>> I'm afraid it is going to be up to you to track down exactly which one is
>>> getting in the way. The best I can do is point you at a few things which
>>> are
>>> commonly causing trouble to other Squid users with this type of setup:
>>> * rules in the Squid box capturing the Squid outbound packets and
>>> sending
>>> them back to Squid.
>>> * rules on the sending box preventing delivery (DROP/REJECT on
>>> outbound)
>>> * rules on receiving box preventing arrivals (DROP/REJECT on inbound).
>>>
>>> You focused earlier on the routing rules as evidence that the looping
>>> back
>>> to Squid was not happening, but it is both routing rules, and NAT rules
>>> involved can do it. The NAT ones have the nasty property of changing the
>>> packets which can make the NATed packet be missed by monitoring tools
>>> (tcpdump etc). So take extra care there. These are most often the problem
>>> as
>>> the slight mistake of omitting or adding a NIC interface or IP range to
>>> the
>>> NAT rules can have major effects on what they are capturing.
>>>
>>> The DROP rules at both sides could be hidden anywhere in the firewall
>>> complexity. So a full audit is sometimes required to find things hidden
>>> away. Alternatively there are things like rp_filter or SELinux which are
>>> automatic components doing the same things as a DROP rule for certain
>>> things
>>> - often without reporting what they are dropping. If something like that
>>> is
>>> happening it can be *very* difficult to identify. Good luck if its one of
>>> these.
>>>
>>> The one thing you have demonstrated is that the problem is something in
>>> the
>>> operating system *outside* of Squid. So this is not really an appropriate
>>> place for detailed tracking any more. The best place if you still need
>>> further help would be the help groups for the developers of the
>>> networking
>>> stack on your machine(s). From the tools you've mentioned already I guess
>>> that would be netfilter.
>>>
>>> Amos
>>
>> I see, all I want to know is that is there exist any settings in squid
>> to avoid such problems without modification routing tables. Something
>> like parent_tcp_outgoing_address ;)
>
>
> There is just tcp_outgoing_address. It can use an ACL of type "peername" to
> match (or not) the cache_peer traffic.
>
> Amos
Interesting. So I can use something like?

cache_peer 192.168.220.2 parent 3128 3130 name=PEER1
acl peer1 peername PEER1

tcp_outgoing_address 192.168.220.1 peer1
tcp_outgoing_address xxx.xxx.xxx.239 local_net
Received on Tue Apr 30 2013 - 06:37:46 MDT