Re: Squid with two gateways

Henrik,

you've really helped, and by following your example, I'm almost there!! ;-)

(I'm replying your private e-mail to the mailing-list because your reply
might be useful to someone else, ok?)

I could manage my Linux server to route the packets according to the source
address (and using tcp_outgoing_address).

Since I have two little SQUIDs (A and B), I set up my cache_peer's like this:

cache_peer localhost 3132 3133
cache_peer localhost 3134 3135

Big Squid is running with default ports
Little Squid A is running with tcp_port at 3132 and icp_port at 3133
Little Squid B is running with tcp_port at 3134 and icp_port at 3135

I understand that cache_peer_access has this sintax:

cache_peer_access cache-host allow|deny aclname

Now I am facing this problem: since both of my parents run at the same
machine (same "cache-host"), how can I tell cache_peer_access which one I
am trying to apply the rule?

Perhaps the solution is to create another "localhost" with another name,
like "hostlocal" or something.. I don't know if this will work.

Do you know a way around this?

Thanks Henrik once again!!

At 02:03 01/05/99 +0200, you wrote:
>Maybe some ascii drawings will help?
>
>
> ------------ ------------
> | client A | | client B |
> ------------ ------------
> \ /
> \ /
> ----------------
> | Main Squid |---->(large cache)
> ----------------
> /(pA) \(pB)
> ----------- -----------
> | backend | | backend |
>(minimal cache)<-| squid A | | squid B |->(minimal cache)
> ----------- -----------
> /(oA) \(oB)
> ------------- -------------
> | gateway A | | gateway B |
> ------------- -------------
>
>
>pA is a parent peering from the main squid to backend squid A.
>cache_peer_access is used to limit the peering to requests from clients
>of class A.
>
>pB is similar, but for class B.
>
>oA is the output request routing from backend Squid A. This has to be in
>the same network as gateway A. tcp_outgoing_address can be used to tell
>backend Squid A which (virtual or real) interface it should transmit the
>requests on, or you can run the backend Squids on separate machines in
>their respective network.
>
>The main squid can be in any network(s) you'd like. It does not really
>matter. What does matter is the backend Squids wich acts as application
>level routers, and the peerings between the main Squid and the backend
>servers which is similar to routes.
>
>A minimal cache is a few MB for internal objects and no_cache configured
>to match every request.
>
>And one thing more: To be able to correctly route the requests to the
>correct gateway when running all Squids on one maching your OS or an
>external router needs to be capable to route based on sending interface
>(limited form of source routing). Else it may happen that the requests
>travel out by the wrong gateway which some providers does not like to
>much (may even be blocked as a measure to protect the Internet from IP
>spoofing). Now this probably isn't such a big problem as it may sound.
>Even if the packets happens to travel out by the wrong gateway (and
>there is no packet filtering which prevents this), the replies will be
>routed in throught the correct gateway.
>
>--
>Henrik Nordstrom
>Spare time Squid hacker
>
>
>Henrique Pantarotto wrote:
>>
>> Hello Henrik!
>>
>> Thanks for your reply!
>>
>> >The answer would be "Yes, but not really". You will need more than one
>> >Squid process.
>>
>> Good! More then one process is no problem!
>>
>> >What you can do is to set up three Squids. One main Squid which
>> >maintains the cache, and two backend Squids which acts as application
>> >level routers to route the requests to the correct path. All three can
>> >be running on the same machine or on separate machines. Use
>> >cache_peer_access to limit each path to requests from the correct
>> >network, and tcp_outgoing_address to force the backend Squids to use the
>> >correct outgoing interface for their requests.
>>
>> Wow.. too much data for me! I have to read the above a couple of times
>> very slowly.. ;-)

Henrique Pantarotto
Coord. Técnico Operacional
CEPAnet Internet Provider
Web: http://www.cepa.com.br
Tel. suporte: +55 (011) 5506-8477
Sao Paulo - Brasil
Linux Friend
Received on Wed May 05 1999 - 10:31:05 MDT