netdev
[Top] [All Lists]

Re: [1/2] CARP implementation. HA master's failover.

To: hadi@xxxxxxxxxx
Subject: Re: [1/2] CARP implementation. HA master's failover.
From: Evgeniy Polyakov <johnpol@xxxxxxxxxxx>
Date: Fri, 16 Jul 2004 19:06:41 +0400
Cc: netdev@xxxxxxxxxxx, netfilter-failover@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1089983064.1060.1328.camel@xxxxxxxxxxxxxxxx>
Organization: MIPT
References: <1089898303.6114.859.camel@uganda> <1089898595.6114.866.camel@uganda> <1089902654.1029.23.camel@xxxxxxxxxxxxxxxx> <1089905244.6114.887.camel@uganda> <1089907622.1027.48.camel@xxxxxxxxxxxxxxxx> <1089910760.6114.967.camel@uganda> <1089912285.1028.93.camel@xxxxxxxxxxxxxxxx> <20040715235313.69897131@xxxxxxxxxxxxxxxxxxxx> <1089983064.1060.1328.camel@xxxxxxxxxxxxxxxx>
Reply-to: johnpol@xxxxxxxxxxx
Sender: netdev-bounce@xxxxxxxxxxx
On Fri, 2004-07-16 at 17:04, jamal wrote:

> > Has vrrp some authentification mechanism?
> 
> They (at least used to) claim to be able to do so.

Hm... Quote from draft-ietf-vrrp-spec-v2-08.txt
5.3.6.1 Authentication Type 0
5.3.6.2 Authentication Type 1
5.3.6.3 Authentication Type 2

1. 8bit virtual host ID.
2. Plain password.
3. HMAC.

I think even 3 is not good.
They do strong signed digest, but it does not have any kind of counter
so i do not see replay attack prevention.

> > Can it be used over IPv6? (CARP also can't but it is _very_ easy to
> > add, I just don't have IPv6 network setup to test).
> 
> Theres effort to have it do v6.
> http://www.ietf.org/internet-drafts/draft-ietf-vrrp-ipv6-spec-06.txt
> I agree its lame to have it as an after thought it seems

* VRRP for IPv6 does not currently include any type of authentication. *


> > > Can you explain a little more what you mean by "attching" to
> > > master/slave?
> > 
> > Consider using some abstraction layer which makes some decisions based
> > on knowledge of current HA state.
> 
> sure; make it an API/callback/event to/from the carp daemon to other
> applications.
> 
> > It looks like we do not understand each other :)
> > Here is the explanation of the ct_sync:
> > http://cvs.netfilter.org/netfilter-ha/README?rev=1.2&content-type=text/vnd.viewcvs-markup
> > 
> > Harald Welte will have a talk about ct_sync at OLS.
> 
> 
> Ok, good. Maybe if you too come to OLS we can settle this ;->

:) Unfortunately no...

> Looking at what HArald has, the infrastructure seems to be the correct
> flavor. Seems something gets sent to user space via netlink and gets
> delivered via keepalived.
> I think the CARP loadbalancing feature is an improvement over what is
> being suggested by Harald.
> I have to say as well i am shocked that state is just being transfered
> blindly - but i will deal with Harald when he shows up in Ottawa ;->

Harald, sorry :)

> > > What do you mean realtime traffic?
> > > Is it something that can be achieved by qos prioritization?
> > 
> > Yes it can. But who will control prioritization mechanism?
> > Maybe userspace.
> > But with such approach we need to create each time we need kernel access
> > a kernel agent with it's own kernel<->user protocol, it's own connect
> > to master/slave arbiter...
> > With CARP just create one function in kernelspace and register it in
> > CARP using provided mechanism.
> 
> bah.
> Ok, now you are forcing me to draw diagrams.
>
> I attached to avouid it being mangled.

I will draw one too.

> > > In the end CISCO is going to be the loser in this of because 
> > > something like CARP will take off and it cant talk to them. At the
> > > moment though they do have the market so interoping with them is
> > > valuable.
> > 
> > It is just marketing...
> > The better software the more market it can eat. Theoretically...
> 
> I am afraid even if that sounds logical it doesnt work like that.
> Too many stupid people. If it worked like that MS would be dead and
> buried a few years ago.

For those who cares they are already done.

> > I have great confidence that Theo de Raadt will not include non
> > patent-free code in OpenBSD.
> 
> I hope he is a lawyer or has some good lawyer advising him;->

He is an OpenBSD creator, so he is just a bit more paranoidal than
others :)

> cheers,
> jamal
-- 
        Evgeniy Polaykov ( s0mbre )

Crash is better than data corruption. -- Art Grabowski

Attachment: carp_diagram.1
Description: Text document

Attachment: signature.asc
Description: This is a digitally signed message part

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