Re: [lvs-users] localnode question

To: Simon Horman <horms@xxxxxxxxxxxx>
Subject: Re: [lvs-users] localnode question
Cc: "lvs-users@xxxxxxxxxxxxxxxxxxxxxx" <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
From: Dean Scothern <dean.scothern@xxxxxxxxxxxxxx>
Date: Wed, 7 Dec 2011 08:54:20 +0000
On Wed, December 7, at 07:42 Simon Horman wrote:

>Hi Dean,
>I should rummage through the changelog to see what has happened but I
>noticed during recent testing that I can't actually use the Local forwarding
>mechanism at all with recent (e.g. 3.1) kernels.
>I'm unsure if this is a problem in general, but I believe it does allow your 
>case to work if you use the masq forwarding mechaism.
>I just tested the following:
># ipvsadm -C
># ipvsadm -A -t
># ipvsadm -a -t -r -m # ipvsadm -a -t 
> -m # ipvsadm -a -t -r -m # ipvsadm -Ln IP
>Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags
>  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
>TCP wlc
>  ->                  Masq    1      0          0
>  ->                  Masq    1      0          0
>  ->                  Masq    1      0          0
>Note both the 81 and Masq. I believe that these are signifiant to this
>I then ran three daemons (netcat), on on each of, and
> It appears that connections to are load-balanced to
>the three daemons.
>I did find that in the case where -m wasn't specified the Route (not Local)
>forwarding mechanism was used and it seems to be necessary to use the VIP
>as the realserver address in that case. Route (and Local and Tun) don't allow
>port mapping, so port 80 was used in that case.
># ipvsadm -C
># ipvsadm -A -t
># ipvsadm -a -t -r # ipvsadm -Ln IP Virtual Server
>version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags
>  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
>TCP wlc
>  ->                Route   1      0          0
>I would expect to see Local here instead of Route.
>But I don't think that either is particularly useful to you.

Thanks Simon,

 This is certainly interesting that the behaviour has changed though I'm not 
sure if it's a bug somewhere or intended behaviour.
Whilst it is possible that I can get a 3.1 kernel running on my centos6 test 
machines (I'm a bit rusty on this), it would be a difficult call to roll it out 
on our production machines. A later update might also 'fix' the problem, 
reverting the behaviour. I was originally thinking of trying dkms to update 
ipvs but keep the standard kernel (not sure if that is practical). Has the ipvs 
code changed much between the stock centos6 kernels and the 3.1 code or is the 
behaviour change possible due to kernel changes?  I've not looked yet, so 
apologies for sounding lazy. 

I wonder if there is a simple 'reverse fix' to the centos6  2.6.32 kernel that 
I can apply to give the current 3.1 masq behaviour?

Best Regards

Please read the documentation before posting - it's available at: mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to

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