Re: Redirector project for FreeBSD

To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: Redirector project for FreeBSD
From: Alexandre Cassen <Alexandre.Cassen@xxxxxxxxxx>
Date: Thu, 28 Mar 2002 22:59:51 +0100
Hi Joe,

I hope that you are well.

> It's called the HighUpTime project.

People ask about LVS for xxxBSD and my reply is a FAQ.

No comments... I agree all the line...

I don't know what loadd is and I can't imagine why it takes
so long for everyone to find out about each other's projects.

Yes I doesn't know HUT too... AFAIK the main site is :

Searching the web for "communication" activity on HUT show that it is a new project (around 27 january 2002). Great a new project ! :)

But when I read : "When I try, one year ago, to search a product like Altheon(tm), Big-IP(tm) etc... I don't find anything except a solution under Linux systems. So, I have decided to write a Load Balancer and a VRRP daemon for participate to the FreeBSD project."

It makes me think : Why not trying to port LVS to FreeBSD or why not participating direclty to LVS ? You will benefit for the LVS maturity code and that way will be able to capitalize on the knowledge embended... As a matter of fact SAVE TIME ! which is the most important OpenSource base and advantage for me :) And even more enhance the LVS code.

I expect the loadd guy knows about us at least. I'd be happy to hear a
"hello, we're doing something similar" from him and to put a note
in the HOWTO.

This is perhaps in its intention but if it is a new project he can be a little overloaded at that time ?

A group in England about a year ago put out a press release for
their commercial software which they loudly proclaimed
as the first and only "Linux Virtual Server". It does different things
to LVS, but I would have thought they'd first do a google search on
the name. I assume they didn't know about us. I sent off a "hello,
we're a Linux Virtual Server project too" letter, but they never replied.

boring & not productive !

It has something called loadd, which
> hooks into FreeBSD's ipfw (like linux's iptables), to provide load
> balancing. There is also an interesting monitoring, ip-takeover daemon
> called vrrp, which I guess would be similar to mon?

When quick read the code, I can see that loadd is a userspace layer7 forwarder tool. Using loadbalancing algo like rr wrr lc wlc over a socket pair. => So the tool have to deal with an heavy overead whhen runing on high bandwidth.... => spending most of the time copying buffers between kernelspace & userspace.

LVS can not be compared to loadd since LVS is fully kernelspace and really optimized, secure, design optimized, connection tracking nicely handled....... (I can write many lines, :) )

But IMHO I do not think loadd want to compete with LVS.

vrrpd is a demon with its own RFC. I think cisco was around in the early
moments of its gestation, and may have initiated the whole thing,
but I don't really know.

Yes CISCO & NOKIA & IBM => impluse by CISCO to replace their HSRP code suffering security limitations.

 A French guy has done
an implementation of vrrpd for Linux and gave a talk about it at OLS last

Yes Jerome Etienne realsed the first vrrp code.

Our own Alexandre Cassen (who has fingers in many pies) is doing another
implementation (or fork of the French guy's code) of vrrpd for LVS.

I don't know why Alexandre has had to redo the code - I believe the French
guy doesn't reply to e-mails.

Yes : Historicaly, I read the first Jerome Etienne code then work on the IPSEC-AH part and create an enhanced release that I send to him. He never reply to my emails even feedback/discuss on new design and the work I done. So I decided to publish my work because he never update/patch with my enhancements... => So I decided to put it on cheetah : a release 0.6 for the community.

Then after many thoughts, code design reading (network design patterns, ...), and always no reply from jerome etienne, I realize that many stuff in vrrpd suffers a design limitation which limite an enhanced use. This is why I take 2 weeks to design a framework for implementing VRRP. And since VRRP can be closely use with LVS (since it is really designed for HA routers) I decided to integrate in my thoughts some LVS specific functions (like sync_instance & sync_daemon activation => currently working on that part) => vrrpd must be considered as a proof of concept tool : nicely coded ! can be used on prod env but is limited to only 1 VRRP instance per NIC => for some users it is enought but still too limited for others.

The design done : So what ... As I used keepalived in a previous devel, I decided to implement VRRP in keepalived that way keepalived will be designly enhanced and more robust. And all maintenance part will be done in keepalived. The design is centralized on an I/O muliplexer used for all parts of keepalived. In fact this I/O multiplexer is a generic scheduling framework since all sheduling task in network code can be directly handled upon I/O activity.

I have spend 1 year of thought to enhance both healthcheck & failover (VRRP). So right now the design is stabilized and I am finishing some VRRP parts to full test it in a production env. The current design of VRRP in keepalived permit the use of multiple VRRP instances per NIC using a packet dispatcher.

The VRRP code will be finish quickly (but still too busy to give a fixed date) after my current fight with NIC MII-registers....

The Sebastien Petit VRRP code (freevrrpd) is nice, but since keepalived framework is based on a generic I/O scheduler (the one from zebra), the port to other UNIX env can be more quicker...

Alexandre's vrrpd together with keepalived etc appears to be the
current front-runner for the all bells and whistles, everything to all men,
software to setup and maintain an HA-LVS. Alexandre is working on it at the moment,
and someday I expect to be deluged with a stack of documentation that will
take a week to read.

If you want docs on VRRP, I will be disponible for writing after my MII hack...

Best regards,

PS: try to free my time for attempting OLS :)... not easy.... too busy :/

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