On Thu, 2004-07-15 at 19:27, Evgeniy Polyakov wrote:
> On Thu, 2004-07-15 at 18:44, jamal wrote:
> > Evgeniy,
> > Why do you need to put this stuff in the kernel?
> > This should be implemented just the same way as VRRP was - in user
> > space.
> Just because i think it works better being implemented in the kernel? :)
> I don't think it is a good answer thought.
> It is faster, it is more flexible, it has access to kernel space...
Just an addition[from private e-mail]:
> would it be possible to do load balancing at the network level with a
> userland only implementation?
> OpenBSD's CARP does load balancing through Source Hashing (SH), which
> lacks support for.
Userspace can't in principle.
Current kernel implementation can't too, but it can. In principle.
But better implementation should use both carp and ct_sync and some load
balancing code, which should link ct_sync and carp.
OpenBSD has one disadvantage in this regard: it is not modular, so their
carp hooks live in if_ether.c.
In Linux we just need to use connection tracking.
ct_sync makes not exactly it but close to the idea.
> > BTW, is there a spec for this protocol or its one of those things where
> > you have to follow Yodas advice?
> Exactly :)
> Here are all links I found:
> VRRP2 spec.
> I do want this to be in the mainline kernel, but actually I even don't
> think anyone will apply it.
> It is too special stuff for generic kernel, it has reserved 112 vrrp
> protocol number and so on...
> So if developers decide not to include or even not to discuss this cruft
> I will not beat myself by my heels. :)
> It just works as expected, it is reliable and simple.
> And it does it's work, so HA people would like it.
> > cheers,
> > jamal
Evgeniy Polaykov ( s0mbre )
Crash is better than data corruption. -- Art Grabowski
Description: This is a digitally signed message part