|
Hi there
On Wed 30 Nov 2005 15:04:19 GMT , John Line <jml4@xxxxxxxxxxxxxx> wrote:
The problem is that while access to the web cache (131.111.8.1)
through the new director "just worked", the WPAD requests almost all
got stuck - shown as SYN_RECV in /proc/net/ip_vs_conn and reported in
/var/log/messages as
... ip_rt_bug: [clientIPhere] -> 131.111.8.68, eth1
and corresponding packets do not get forwarded to a real-server.
...the only time I've ever triggered anything like this was whilst
running a very early 2.6.x kernel on a gateway box at home which did
both SNAT and DNAT depending on direction of traffic. I managed to get
myself into some weird condition at one point whereby the packets
entering the external interface which were destined for the local
machine fell through the netfilter tables and ended up trying to go out
via a DNAT rule. At this point the kernel spat the dummy, logged an
ip_rt_bug message and stopped forwarding those packets.
A kernel update later and it all went away. I never did find out what
caused it, either.
This thread might be of interest (although it's likely to be academic,
if at all):
http://www.ussg.iu.edu/hypermail/linux/kernel/0504.3/index.html#0239
Do you see *any* traffic hitting the realservers at all when these
messages are being logged? Also, is anything being sent back to the
clients? Understandably debugging this is going to be fairly hard, but
if it were me I'd park a whole heap'o'debug -j LOG statements into
whatever netfilter ruleset you have on the director, and run tcpdump
writing files on the interfaces involved (client, director in, director
out, realserver in, realserver out) and see what shows up.
Other than that, flummoxed.
Graeme
|
