|
On Mon, 20 Feb 2006, Roberto Nibali wrote:
> Mark de Vries wrote:
> > Just testing using fwmark services and noticed that even when no packets
> > are hitting the service ipvsadm -L --rate keeps showing InBPS > 0.
>
> Strange indeed. Which kernel?
2.6.14.3
> > I have a single itables rule marking packets (with '10').
> >
> > iptables -t mangle -xnvL has shown a constant of 103 packets having hit
> > the rule for hours... Yet ipvsadm -L -f 10 --rate shows:
> >
> > Prot LocalAddress:Port CPS InPPS OutPPS InBPS OutBPS
> > -> RemoteAddress:Port
> > FWM 10 0 3 0 182 0
> > -> cns3:domain 0 0 0 30 0
> > -> cns2:domain 0 0 0 0 0
> > -> cns1:domain 0 1 0 53 0
> > -> cns0:domain 0 2 0 98 0
> >
> > If no packets have been marked for hours how can this be?
>
> Could you zero the stats counters and wait again for a while? For now I
> don't know what would cause this.
At the time of my origional post the fwmark based service was not the only
service. There were also udp/tcp services that could matched the same
traffic. (Is it defined which service has precedence in that case?)
After a complete and succesfull test with the fwmark based service I
removed the old services. (Which was the intent of this excersize;
replacing 9vips x 2(tcp/udp) services with 1 fwmark based one.)
And ever since the tcp/udp based services the rate seems to be acurrate
again. Could there be some interferance, things accounted in the wrong
place, or something? I no longer have the setup to reproduce right now but
if someone suspects the might realy be a BUG() I could run some more
test... ? I think, even though it might be undefined if a marked packet
matches a fwmark service or an appropriate tcp/udp based service if also
present, it does seem weird that the rate did not go down to zero when NO
packets where beeing marked....
Regards,
Mark
|
