A good place to start would be the Advanced Routing HOWTO:
http://www.linuxdoc.org/HOWTO/Adv-Routing-HOWTO.html
The queueing information will be helpful. But mostly you'll need to
learn about fwmark, or firewall marks. This will allow you to tag or
'mark' each packet based on some variable (such as protocol, port,
source or destination address, etc.), then from there you can choose
routes based on that information. Pretty nifty stuff, and all built
right into the kernel and a few relatively simple tools. The
AdvRoutingHOWTO even has some examples for you of doing just the kinds
of things you want to do. Though you may need to recompile your kernel
to get QoS stuff, I don't think most distributions ship with it enabled.
(And, technically, it isn't required for your exact purpose...but with
some cleverness, you can get even more perceived performance from your
network by using it.)
Good luck, Mehran.
Mehran wrote:
> Dear Joe,
>
> Thank you very much for your kind reply.I studied your mail carefully and
> now I have one more question that I ask you:
>
> We have one link for send and two links for receive from
> Internet.So, I think that our Squid must use two different source IP
> address for receiving the requests.Is this right? If so, I think that
> routings must be defined in Linux rather than router.Please inform me is
> such a defenition is possible on Linux?Is there any reference or
> documentation you can introduce to me?
>
> THKS + BST RGDS
> Mehran
>
> ----- Original Message -----
> From: Joe Cooper <joe@swelltech.com>
> To: Mehran <List@sonra.net>
> Cc: <squid-users@ircache.net>
> Sent: Wednesday, January 31, 2001 2:48 AM
> Subject: Re: [SQU] Squid box with two seperate Internet links
>
>
>
>> I don't think I understand what you mean by #1 below...for number 2, the
>> answer is:
>>
>> This is not a Squid question, but a routing question. While it is
>> possible to balance between multiple upstream caches (and there are
>> patches on the SourceForge Squid site regarding this), if you are
>> instead balancing between network links then it is a routing issue, that
>> must be dealt with at the network level.
>>
>> Squid goes out whatever route your OS tells it to go out for
>> requests...so if you set up balancing of some sort (BGP, Multipath,
>> static routing based on the last octet, etc.) at your router, then Squid
>> will be balanced in the same way as all of your other traffic.
>>
>> If I were configuring a network divided as yours is (satellite, and land
>> link) I would use QoS queueing to send latency intensive stuff (like
>> http) over the land link, and get larger, but less interactive stuff
>> (like ftp, streaming media, etc.) from the satellite. Plus I'd overload
>> onto the satellite link for all traffic when the land line is thoroughly
>> saturated.
>>
>> But deeper discussion of all of that is probably more appropriate on a
>> networking and routing list, where networking and routing nerds are more
>> able to provide solid advice, and working examples.
>>
>> Hope this points you in the right direction, anyway.
>>
>> Mehran wrote:
>>
>>
>>> Dear list members,
>>>
>>> We are connected to Internet via two seperate links with different set
>>> of IP addresses: one of them is a one-way connection via a satellite
>>> service and the other is a symmetric leased line connection.We use
>>> Transparent Caching for our clients.Now, the question is: Is there any
>>> way for one Squid box to be used under one of the following conditions?
>>>
>>> 1- Squid can receive requests for each subnet from its individual link .
>>>
>>> 2- Squid acts in someway to Load Balancing. I mean Squid can decide
>>> between two links to get the requests from the Internet via the link
>>> that at the instance has the lower data traffic.
>>>
>>> thank you in advance.
>>>
>>> Mehran
>
--
Joe Cooper <joe@swelltech.com>
Affordable Web Caching Proxy Appliances
http://www.swelltech.com
-- To unsubscribe, see http://www.squid-cache.org/mailing-lists.htmlReceived on Thu Feb 01 2001 - 23:46:54 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:57:51 MST