Re: Redirector project for FreeBSD

To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: Redirector project for FreeBSD
From: Roberto Nibali <ratz@xxxxxxxxxxxx>
Date: Fri, 29 Mar 2002 09:42:11 +0100
No comments... I agree all the line...

Well, I've already gotten several requests of porting LVS to other *BSD variants :)

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."

Exactly what I thought was a little strange.

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 recently got a request by a group of students of a german university to help porting LVS to NetBSD. The problem with porting LVS to another Unix (BSD related in our case) is actually that there is about 10% really Linux kernel specific stuff there which is either not portable (framework doesn't exist) or must be completely rewritten. While going through the TCP stack implementation of OpenBSD I just recall the structure for hooking up a receiver for packets [Q: how do you mark packets in OpenBSD :)]. You have quite a different way of accessing TCP state transitions from kernel space. Following parts could pose a serious porting trouble:

o export of statistics to proc-fs and tcp_defense strategy tunables
o hook a ipvs_service to the ip_fw struct in the masquerading code
o Julian's special HW_CHECKSUM workaround :)
o the (re-)routing and packet rewriting calls

What I would consider quite easy to port:

o the ipvs_service and load balancing modules (well not as loadable
  kernel modules though)
o the user space tool :)

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.

Don't worry, at least Alteon Websystems knows about us :)

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

I'm still not so sure if he wants to do load balancing in regard of the load generated on the clients. If you check out his software, you see that you need a client and a server. LVS provides the (network) load balancing only, the notification/service takeout a third party modules like keepalived, piranha and such.

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 !


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.

In FreeBSD (CURRENT) kernelspace/userspace msg passing is actually a lot more effective then under Linux (<2.5.x)

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.


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

With what do you want to replace such an established standard and teach your customers to use it?

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

:) and

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...

Seems to be the french people's most liked RFC. I wonder if this is already translated to french (couldn't resist)

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

What part is still missing?

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

You'll better show up or I'll drag you up there. Seriously now, you really need to sign up or you won't get a place anymore.

Best regards,
Roberto Nibali, ratz

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