|
Hello,
On Wed, 7 Dec 2011, Simon Horman wrote:
> > 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.
What is changed with this patch from 2010-OCT-17 is
that LOCALNODE mode (whether RIP is local IP or not) is
determined for every packet, not when real server is updated.
It helps to survive master-backup role change without
modifying the real servers and avoids packet loops on the
LVS box as found here:
http://marc.info/?t=128428786100001&r=1&w=2
It also allows Masq mode to use local RIP:RPORT
Now the rules are almost same:
- DR (Route) means: do not change packets, just route to RIP.
While RIP is local IP use LOCALNODE mode.
- NAT (Masq) means: change packets, route to RIP. If RIP is
local IP it looks like LOCALNODE but NAT happens.
Before this patch LOCALNODE worked by not
modifying packets - local servers must listen on VIP.
- TUN means: do not change packets, just tunnel them to RIP
by prepending IPIP header if RIP is remote IP or work
as LOCALNODE mode if RIP is local.
So, LOCALNODE is not a forced mode but overrides
the actual mode while RIP is local IP.
If Masq mode is used, the box where this RIP is
configured must listen on RIP.
If Route/Tun mode is used, the box where this RIP is
configured must listen on VIP to accept the traffic.
I also want to note that I remember for possible
Netfilter conntrack collisions if NAT was used in master-slave
setup and when roles are changed. But I may be wrong about
this. There should be no problems if conntrack is not used.
So, now, even for boxes that change roles and use
NAT, the applications must listen on RIP, not on VIP.
> My opinion is that the Masq behaviour is a desirable new feature
> and I will be reticent to remove it in the future.
>
> > 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?
>
> I believe that I also observed the behaviour above using a backport of
> IPVS (~2.6.36 code) to the 2.6.35.4[*] kernel, though the reason for the
> backport was to test an unrelated feature (SNAT). The reason for the
> backport being that I was not able to upgrade the entire kernel.
>
> So I suspect that you could build an updated IPVS module for centos6,
> either backporting IPVS in its entirety or just the changes that you are
> interested in. But doing so is a somewhat involved process, by which I
> mean, if you haven't done something like that before then be prepared
> for it to take a bit of time.
>
>
> [*] For reference, the backport is available in the
> v2.6.35.4-ipvs-backport branch of my IPVS tree on Kernel.Org
>
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/ipvs.git
>
> I just uploaded it there as I only recently had my access to kernel.org
> restored after the break-in they experienced. The same tree is also
> available on github, which I was using as a temporary home
> until my account was restored.
>
> git://github.com/horms/ipvs.git
>
> Looking over the backport it seems that the following patch is relevant
> https://github.com/horms/ipvs/commit/c123e9ff994388b21b507d4f0377a425b76bcc02
>
> I'm unsure if that is all that is necessary,
> though I do recall some subsequent fixes for corner cases.
>
> In any case, that patch explains why we see Route instead of Local.
> It is intentional and Local can be explicitly set from user-space
> (by enhancing ipvsadm) if needed.
Regards
--
Julian Anastasov <ja@xxxxxx>
_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users
|
