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

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
Received on Tue Apr 30 2013 - 06:16:24 MDT