Re: Multihomed Squid and others...

Stephen Amadei wrote:

> I was wondering if there was some sort of way to make put two interfaces
> on a Linux system, one for each BGP4 announced route, and force Squid to
> divide up the outgoing source address so that half the squid traffic comes
> back on each of my T1's?

Good question. I don't think there is any magic knob to turn for this.

Alternatives I know of are:

a) Rotating default route. Have a deamon which frequently changes the
default route to alternate between the two links.

b) Patch Squid to alternate between two tcp_outgoing_address settings,
combined with source routing in the kernel (or a neighbouring network
device) to make sure the packets go out on the correct link.

c) Set up a second proxy (not cache) which only acts as a request
routing device, forwarding the requests out on the "other" link.

> My next question concerns async-io. I enabled it, but the FAQ states that
> the "squid -k rotate" feature will not work... but it is. Did this
> recently change?

squid -k rotate has worked most time (there was a short time when it did
not work, but it was quickly patched by someone needing it). What does
not work is to manually send signals to Squid as other signals than the
default signals are being used when compiled with async-io on Linux.

> And finally, I'm having two performance problems with Squid. The first
> is that Linux slowdown over a couple of days... enabling async-io seems
> to have solved this...

Fine. But I doubt it actually did cure the cause. async-io is mostly
about peak loads on your cache drives, not long time trends.

> but now, after 4-5 days, the system looses all
> networking. It doesn't crash; but it can't create outgoing network
> connections or accept incoming ones.

Can you ping to/from the box, or is networking completely gone? If you
cannot even ping then it is most likely a driver problem.

What is the output of "netstat --inet -an | awk '/^tcp/ {print $6}'|
sort | uniq -c"?

If you can telnet to the box, but cannot telnet out from it then you
have run out of unbound TCP ports (ip_local_port_range).

If you have problem to telnet to the proxy service but telnet to other
ports works fine and your proxy is processing some requests then you are
most likely bitten by the accept SYN backlog limit. Try increasing the
SYN backlog limit. The default for Linux is 128 which is way to small
for a large scale proxy, especially if there is dialup or long-distance
WAN users involved (the SYN handshake apparently takes place in the SYN
backlog queue on Linux).

There are also other limits on the number of inodes the kernel may
allocate and such. In most cases problems with these are logged to
/var/log/messages.

> I doubt this is a Squid problem, but I'd figure I better ask, as no
> other Linux server has ever done this to me before.

Running a HTTP proxy buts rather specific demands on the networking,
quite unlike any other server use (lots of short lived connections, both
incoming and outgoing, combined with quite a lot of random disk I/O).

> Any thoughts?

Don't know much about running Linux servers on X86 hardware. The
machines I run are Alpha machines with Tulip based network interfaces.
What I do know from experience is that the Linux driver for 3com Vortex
have had a lot of problems, and likevise for the Intel Etherexpress
10/100 driver. The two x86 Linux machines I have used in heavily
networking both had servere problems with these drivers. These problems
usually shoved as a complete network hang, sometimes with messages
logged to /var/log/messages or the console. However, this was 1 to 1 1/2
year ago so things might have improved since then.

--
Henrik Nordstrom
Squid hacker