[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Multiple DSL lines + iproute + squid ...



Hello all,

I'm working on a problem that seems like it should work and am looking for
some help knocking out any obvious problems.

We currently have several DSL lines that are used for crawling websites.
Bandwidth as it is is pretty cheap via DSL (we have 6 7Mbit lines for much
less than an ~equivalent T-3).  Right now we use a single RedHat machine
that has the DSL lines attached to it and we use iproute to direct the
"networks" of traffic to each DSL line.

The biggest problem with this is that if a DSL line goes down we have no
real way to switch to a new line without going in and changing the rules
by hand.  The machine it currently resides on is a blackbox built by
someone who is no longer with our organization.  It ain't broke, so I
don't touch it.

I came up with the idea of bringing up a new box that has 1 internal
interface and then up to 11 external interfaces (using dual Intel NICs).
The internal interface will have squid running on it and will handle
requests from internal (10.0.0.0/8) addresses.  On each one of the
external interfaces I'll have another copy of squid running (from a
different conf file) that will be a parent to the internal interface.
Each external interface will be attached to a different DSL line.

I'm hoping that by leveraging the cache hierarchy abilities of Squid I can
essentially "load-balance" across all of the lines (for http requests
only).  If a line goes down, Squid should treat it as a dead parent and
not forward requests to it.

I'm currently running a Debian machine with the 2.4.5 kernel under
the testing distro for this.  The machine is setup as a firewall using
iptables (which works wonderfully).  My problem right now is I cannnot
seem to make the ip policy routing work for the external interfaces.  For
example:

cave:/etc/init.d# ip ro show
63.229.140.40/29 dev eth1  proto kernel  scope link  src 63.229.140.41
65.100.40.32/29 dev eth2  proto kernel  scope link  src 65.100.40.33
65.100.62.168/29 dev eth3  proto kernel  scope link  src 65.100.62.169
63.227.221.8/29 dev eth5  proto kernel  scope link  src 63.227.221.9
63.230.174.24/29 dev eth4  proto kernel  scope link  src 63.230.174.25
206.29.168.104/29 dev eth6  proto kernel  scope link  src 206.29.168.106
10.10.0.0/16 dev eth0  proto kernel  scope link  src 10.10.5.57

These are the routes in the main table.  Now, I have Squid bound to
63.229.140.41 and I want all traffic with that source to go out
63.229.140.46 using source routing.  I would think I would do the following:

ip ru add prio 4000 from 63.229.140.41 lookup qwest_7_1
ip ro add table qwest_7_1 via 63.229.140.46
ip ro flush cache

If I do a `ping -I 63.229.140.41 ftp.orst.edu` I get a host unreachable.
Its almost as if the rules aren't taking affect at all.  Same results for
traceroute -i eth1 ... and tcpdump on that interface shows no traffic
moving across it.

Has anyone had any problems with iproute and 2.4.5?  I've tried this with
2.2.19 as well to no avail.  Is there something blindingly obvious wrong
with my rules?!  Someone just please tell me this isn't possible so I can
get some sleep ... :-)

I have the following versions:

Kernel v2.4.5 (with CONFIG_NETLINK and CONFIG_RTNETLINK as well as a few
others enabled)
iproute2 version 20001007-1
Squid v2.4.1-5

Thank you all for you help; couldn't do my job without Debian,

Scott :-)




Reply to: