On Tue, Apr 30, 2013 at 9:16 AM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote: > On 30/04/2013 2:49 a.m., Alex Domoradov wrote: >> >> On Mon, Apr 29, 2013 at 4:57 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> >> wrote: >>> >>> On 26/04/2013 10:57 p.m., Alex Domoradov wrote: >>>> >>>> On Fri, Apr 26, 2013 at 12:31 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> >>>> 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
