|
On Thu, Jan 06, 2005 at 01:23:19PM +0200, Johan van den Berg wrote:
> Joseph Mack wrote:
>
> >Janno de Wit wrote:
> >
> >
> >>- How can I see if connectiontable is full? `dmesg` gives no output.
> >>
> >>
> >
> >hmm, don't know. probably you can get it with ipvsadm.
> >
> >
> >
> I would really like to find this out too! How do I know if packets or
> connections are being lost or if something malfunctions, or if the
> connection table is full?
The connection table cannot become full. It is a hash table
and you can continue to add entries until you run out of memory,
at which time something very apparent should turn up in dmsg.
> In my scenario I have LVS-NAT for incoming connections into my cluster,
> and IPTABLES SNAT outgoing. Now, if none of my servers need to initiate
> a connection to the outside, then the IPTABLES connection table should
> be clear, and LVS-NAT table contain entries of all incoming connections.
> This it actually does, except every now and again, a client would try to
> establish a connection to the cluster, and IPVS would store the SYN in
> the IPVS connection table, but the SYN/ACK from the server would be
> NATted through IPTABLES, as if the original SYN never existed. This
> would result in the wrong IP on the director being used for the SYN/ACK,
> meaning the client would respond with a RESET, and resend its SYN to the
> original IP, as if connection was never established. This happens about
> once every two days, and then only for a few minutes. One can actually
> see a SYN in the IPVS connection table that just stays like that until
> it times out, and an equivalent SYN/ACK using netstat for the response.
>
> I can only assume that some or other limit was reached in one of the
> connection tables, or that something else went berzerk, but as nothing
> is reported in syslog or klog, and I couldn't figure out how to find out
> exactly what I should otherwise be looking at.
>
> Any further advice would be appreciated.
Sounds like some race condition in netfilter where packates
aren't being passed to the LVS HOOK, ip_vs_in(). Though it might
pay to take a look in ip_vs_in() first.
--
Horms
|
