On Fri, Feb 06, 2004 at 10:07:24AM -0500, John Reuning wrote:
> On Thu, 2004-02-05 at 21:24, Horms wrote:
>
> > I suspect that your web browser (Explorer?) is reopening the connection
> > (RFC 1122, 4.2.2.13), but that it is very short lived so you can't
> > observe what is going on. So basically the port 49598 connection is
> > swiching betweeen active and inactive, which is why you don't see the
> > inactive connection count grow.
>
> I was using Mozilla. However, shouldn't telnetting to VIP port 80 cause
> the connection to relist as ESTABLISHED until the telnet session is
> ended? I tried that, and nothing changed.
>
> And I noticed something else, too. After the connection disappeared
> from the table (after the TIME_WAIT expired), it didn't reappear at all
> when I reloaded pages via a browser or telnetted to port 80. Only the
> persistence SYN_RECV line remained. It wasn't until after the SYN_RECV
> line timed out that a new ESTABLISHED connection line appeared in the
> table.
Are you sure you are connecting to the linux director and not
mistakenly connecting directly to one of the real servers?
Are you using LVS-DR? If you are and you have not hidden
the lo:0 interfaces on the real servers then this
is a very real possibility. Alternatively, perhaps
something strange is going on with ICMP redirects. Have you
traced what is going on with tcpdump?
> > I am not sure if this helps or not, but if a connection is in the
> > connection table (i.e. it shows up in ipvsadm -L -c -n), but is not a
> > persistance template (i.e. the client's port is not zero) then it will
> > be counted in either ActiveConn or InActConn. If the connection is in
> > the ESTABLISHED state then it is counted in ActiveConn, otherwise it is
> > counted in InActConn.
>
> Yep, this makes sense. And it leads me to think that the root cause of
> the newly added real server may be the result of inaccurate ActiveConn
> counting.
I haven't seen anything in what you have reported to indicate
that the connection counts are inaccurate.
--
Horms
|