On Thu, 2004-07-15 at 20:07, jamal wrote:
> > > 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.
> >
> > Hmm...
> > 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...
>
> Yeah, I know ;-> and probably thats what the opnebsd people did.
>
> I still think it should live in user space. This should apply to
> anything thats control related because such things tend to be
> continoulsy enrichned with features. ARP unfortunately is in there; one
> of my pet perpetual projects is to totaly rip it off. Theres already
> hooks to deliver to user space today and Alexey has a daemon for it, not
> sure how widely used it is.
Userspace is too slow.
It can only initiate master's failover, load balancing is a good example
here - userspace _itself_ can not control real time traffic.
> > > 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:
>
> Thank you.
> I think a better idea would be to implement a sync message
> within CARP instead of that pfsync app doing its own thing. Unless i
> misread, pfsync seems to be a separate app.
> This way more than one app can use it via the CARP daemon
> in user space to sync state of their choice (with whatever pfsync does
> being one of many).
ct_sync module does this.
It uses connection tracking and sends firewall state across slaves.
CARP is separate by design - anyone may "attach" to master/slave
failover.
> This is an example of a rich application and further justification for
> it to live in user space.
If it will live in userspace, it just can not control realtime traffic
and even provide some mechanism to achive this.
> > 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.
>
> It is valuable, just doesnt belong to the kernel.
> BTW, i saw some claim that this is patent-free as opposed to VRRP?
> I do hope it takes off. What exactly is the patent issue that was at
> stake? I couldnt tell from the song lyrics ;->
:) Cisco + hsrp == vrrp, but the former is patented.
Here is quote from Ryan McBride, an author of the CARP:
* P.S. If anyone has concerns about the Cisco's patent #5,473,599 and
how their claim that it applies to VRRP has forced us to design our own
incompatible protocol, don't talk to us. Instead, call Cisco's lawyer at
408-525-9706, or email him: rbarr@xxxxxxxxx *
> One valuable thing that could be done is while still avoiding any patent
> issues make it interop with VRRP.
VRRP is not secure, it is protocol dependent, it is not free...
> cheers,
> jamal
--
Evgeniy Polaykov ( s0mbre )
Crash is better than data corruption. -- Art Grabowski
signature.asc
Description: This is a digitally signed message part
|