Re: Bizarre LVS oddity - one VIP handled find, another gives ip_rt_bug e

To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: Bizarre LVS oddity - one VIP handled find, another gives ip_rt_bug errors
From: Graeme Fowler <graeme@xxxxxxxxxxx>
Date: Wed, 30 Nov 2005 15:29:49 +0000
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 ( 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] ->, 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):

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.


<Prev in Thread] Current Thread [Next in Thread>