when IPVS into netfilter?

when IPVS into netfilter?

[Xose Vazquez Perez]

hi,

Are there some possibility to IPVS Netfilter
( http://www.linuxvirtualserver.org )
module for it can go into iptable 2.4.xx code?

-thanks-

regards,
-- 
Galiza nin perdoa nin esquence. Governo demision!

Re: when IPVS into netfilter?

[Roberto Nibali]

Hello,

I hope the netfilter people do not mind if I answer this on behalf of 
the LVS project.

> Are there some possibility to IPVS Netfilter
> ( http://www.linuxvirtualserver.org )
> module for it can go into iptable 2.4.xx code?

I think not for 2.4.x because we're changing too much of the 
netfilter/routing code to make it a smooth and acceptable merge. There 
is also some code most people use which is completely not acceptable 
within the scope of routing extensions (like the hidden patch or some 
DGD code).

For 2.5 it is already too late, feature freeze was already called in and 
we haven't talked to the netfilter people anyways ;).

I'm going to talk to Harald about it this coming OLS (once again), 
provided he's got enough time. It's on my BoF list actually; for more 
information please check out the .plan:

http://marc.theaimsgroup.com/?l=linux-virtual-server&m=104756133813089&w=2

Another point is that we (Wensong the most) never felt the urge to 
submit the code to the networking maintainers for approval and 
inclusion. At OLS 2000, Wensong, Horms, Rusty, me and some others talked 
about a possible inclusion of LVS into netfilter. It simply never 
happened because noone felt about doing more than talking of it.

Yet another point is that we never really agreed on having someone being 
the lead developer and responsible for a possible kernel inclusion and 
most of us simply do not have the time to be a maintainer. It's a tough 
and time consuming job even if the code works for 99.999% of the people.

You have to talk to other involved parties, you have to monitor API 
changes and you will need to be responsive to an increasing amount of 
emails addressed directly to you (for example package responsibles for a 
distribution), because you're in the MAINTAINERS list.

Last but not least it is pretty easy to patch your kernel with LVS, 
There are as few as possible changes to the existing code, most of the 
patch is in form of additional code.

 > --
 > Galiza nin perdoa nin esquence. Governo demision!

:) Fair enough.

Best regards,
Roberto Nibali, ratz
-- 
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc

Re: when IPVS into netfilter?

[Xose Vazquez Perez]

Roberto Nibali wrote:

> I think not for 2.4.x because we're changing too much of the
> netfilter/routing code to make it a smooth and acceptable merge. There
> is also some code most people use which is completely not acceptable
> within the scope of routing extensions (like the hidden patch or some
> DGD code).

I can't understand this, the code is not ready for to put into kernel but
it is ready for enterprise use ;-)

> For 2.5 it is already too late, feature freeze was already called in and
> we haven't talked to the netfilter people anyways ;).

well, never is too late for 2.5. A lot of features were included into
latest 2.4.xx. And ,in theory, it is more frozen than a penguin at north pole.

> Another point is that we (Wensong the most) never felt the urge to
> submit the code to the networking maintainers for approval and
> inclusion. At OLS 2000, Wensong, Horms, Rusty, me and some others talked
> about a possible inclusion of LVS into netfilter. It simply never
> happened because noone felt about doing more than talking of it.

if the code is not into the kernel, then it's little useful. Because
not all people are kernel hackers and they need official distribution
support. And custom kernels are not supported.

> Yet another point is that we never really agreed on having someone being
> the lead developer and responsible for a possible kernel inclusion and
> most of us simply do not have the time to be a maintainer. It's a tough
> and time consuming job even if the code works for 99.999% of the people.

It is not necessary to have a leader, bugs must go to mailing-list.

> You have to talk to other involved parties, you have to monitor API
> changes and you will need to be responsive to an increasing amount of
> emails addressed directly to you (for example package responsibles for a
> distribution), because you're in the MAINTAINERS list.

well, ipvs has 5 years of history. Versions are released every XX time.
Red Hat has sold 6.2 and next distributions with ipvs patch.
It works! And how many headaches has you gotten?

> Last but not least it is pretty easy to patch your kernel with LVS,
> There are as few as possible changes to the existing code, most of the
> patch is in form of additional code.

it is easy to patch kernel, for me it's not a problem.
But now LiNUX is not only a hacker OS, there are places where you need
to have distribution support because the boss wants it :-)

-thanks for your time-

regards,
-- 
Galiza nin perdoa nin esquence. Governo demision!

Re: when IPVS into netfilter?

[Roberto Nibali]

Hello Xose,

> I can't understand this, the code is not ready for to put into kernel but
> it is ready for enterprise use ;-)

1. That's your view, yes. Kernel net maintainers were not so nice with
    us when we first proposed the code for inclusion.
2. There is a lot of stable code around on the net that can't be
    included into the mainline kernel because the design doesn't suit the
    rest of the kernel control path. Think about the grsecurity patches.
3. We are now officially working on it :).

> well, never is too late for 2.5. A lot of features were included into
> latest 2.4.xx. And ,in theory, it is more frozen than a penguin at north pole.

We'll see. I've started a discussion in the core dev team about it.

> if the code is not into the kernel, then it's little useful. Because
> not all people are kernel hackers and they need official distribution
> support. And custom kernels are not supported.

There are official distributions which support LVS, RH and SuSE come to 
mind.

> It is not necessary to have a leader, bugs must go to mailing-list.

Yes, that's what they always say. The truth is different, ask Harald 
Welte about some netfilter questions he finds in his Inbox.

> well, ipvs has 5 years of history. Versions are released every XX time.
> Red Hat has sold 6.2 and next distributions with ipvs patch.
> It works! And how many headaches has you gotten?

Yes, I know it works, it was stable starting around June 1999 on 2.0.35 
and ever since. No headaches so far :).

> it is easy to patch kernel, for me it's not a problem.
> But now LiNUX is not only a hacker OS, there are places where you need
> to have distribution support because the boss wants it :-)

Now how exactly does this work? Only because a feature is in the kernel, 
doesn't necessarily mean that a distributor supports it. But as I've 
said, we'll be working on an inclusion comitee for LVS. Most of the core 
  LVS hackers will meet at OLS this year and we'll have a BoF too, so 
stay tuned until about August. A lot of decisions will be made then, 
kernel wise, gcc wise, netfilter wise, ... .

And to go back on being more on-topic, I'd like to ask the netfilter 
team if the ip_fw_compat.c is going to remain in the 2.5.x/2.6.x cycle?
I was under the impression that Rusty once mentioned that he'd wanted to 
get rid of it, but I could be dreaming here.

We have following patch which hooks up LVS to netfilter and sneaks away 
packets and a patch to export a symbol for multicasting.

--- linux-2.5.69/net/ipv4/netfilter/ip_fw_compat.c      Mon May  5 
07:53:13 2003
+++ linux-2.5.69-ipvs-1.1.5/net/ipv4/netfilter/ip_fw_compat.c   Fri May 
  9 11:52:09 200
3
@@ -43,6 +43,10 @@
  extern int __init masq_init(void);
  extern void masq_cleanup(void);

+/* From ip_vs_core.c */
+extern unsigned int
+check_for_ip_vs_out(struct sk_buff **skb_p, int (*okfn)(struct sk_buff *));
+
  /* They call these; we do what they want. */
  int register_firewall(int pf, struct firewall_ops *fw)
  {
@@ -172,8 +176,14 @@
                 return NF_ACCEPT;

         case FW_MASQUERADE:
-               if (hooknum == NF_IP_FORWARD)
+               if (hooknum == NF_IP_FORWARD) {
+#ifdef CONFIG_IP_VS
+                        /* check if it is for ip_vs */
+                        if (check_for_ip_vs_out(pskb, okfn) == NF_STOLEN)
+                                return NF_STOLEN;
+#endif
                         return do_masquerade(pskb, out);
+                }
                 else return NF_ACCEPT;

         case FW_REDIRECT:


I will send in a patch to correct the extern part as it is not ifdef'd. 
The second one is, which makes the whole LVS code as non-intrusive as 
even possible. I think the netfilter community could live with two more 
ifdef-blocks, right? :)

The next one is a symbol export which we need to smuggle into the kernel 
bypassing DaveM :). No, seriously, it should be feasable.

--- linux-2.5.69/net/netsyms.c  Mon May  5 07:53:13 2003
+++ linux-2.5.69-ipvs-1.1.5/net/netsyms.c       Fri May  9 11:52:08 2003
@@ -265,6 +265,7 @@
  EXPORT_SYMBOL(in_aton);
  EXPORT_SYMBOL(ip_mc_inc_group);
  EXPORT_SYMBOL(ip_mc_dec_group);
+EXPORT_SYMBOL(ip_mc_join_group);
  EXPORT_SYMBOL(ip_finish_output);
  EXPORT_SYMBOL(inet_stream_ops);
  EXPORT_SYMBOL(inet_dgram_ops);


Comments, flames?

Best regards,
Roberto Nibali, ratz
-- 
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc

Re: when IPVS into netfilter?

[Xose Vazquez Perez]

Roberto Nibali wrote:

>>Xose wrote:
>>if the code is not into the kernel, then it's little useful. Because
>>not all people are kernel hackers and they need official distribution
>>support. And custom kernels are not supported.

> There are official distributions which support LVS, RH and SuSE come to
> mind.

not now, rhl 7.x, 8 and 9 don't have lvs.
they _only_ put lvs patch in enterpri$e di$tribution$

regards,
-- 
Software is like sex, it's better when it's bug free.

dropping support for ipfwadm/ipchains (Re: when IPVS into netfilter?)

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1965 bytes --]

On Tue, May 20, 2003 at 09:42:17AM +0200, Roberto Nibali wrote:

> And to go back on being more on-topic, I'd like to ask the netfilter 
> team if the ip_fw_compat.c is going to remain in the 2.5.x/2.6.x cycle?
> I was under the impression that Rusty once mentioned that he'd wanted to 
> get rid of it, but I could be dreaming here.

To quote from the packet filtering howto:
---
 There are modules in the netfilter distribution called ipchains.o and
 ipfwadm.o. Insert one of these in your kernel (NOTE: they are
 incompatible with ip_tables.o!). Then you can use ipchains or ipfwadm
 just like the good old days.

 This will be supported for some time yet. I think a reasonable formula
 is 2 * [notice of replacement - initial stable release], beyond the
 date that a stable release of the replacement is available. This means
 that support will probably be dropped in Linux 2.6 or 2.8.
---

So this would make something like 2*(iptables_included-ipchains_included).
But then the question is whether we are talking about stable kernels or
development kernels?

I think ipfwadm can be dropped safely, but ipchains will have to stay.

> The second one is, which makes the whole LVS code as non-intrusive as 
> even possible. I think the netfilter community could live with two more 
> ifdef-blocks, right? :)

We certainly don't mind.  However, having IPVS specific ifdefs in the
mainline kernel while IPVS is outside the mainstream kernel sounds a bit
odd to me.   I think in general this is discouraged...

> Best regards,
> Roberto Nibali, ratz
> -- 

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: dropping support for ipfwadm/ipchains (Re: when IPVS into netfilter?)

[Roberto Nibali]

Hi Harald,

> So this would make something like 2*(iptables_included-ipchains_included).
> But then the question is whether we are talking about stable kernels or
> development kernels?

I'd say development, that's how I interprete that "formula" und the 
wording around it, so it would be 2.7 then. But this is entirely up to 
you guys.

> I think ipfwadm can be dropped safely, but ipchains will have to stay.

Good, I just wanted to establish if the part my previous patch was 
against is going to remain for the 2.6 timeline. This seems to be the 
case then.

>>The second one is, which makes the whole LVS code as non-intrusive as 
>>even possible. I think the netfilter community could live with two more 
>>ifdef-blocks, right? :)
>  
> We certainly don't mind.  However, having IPVS specific ifdefs in the
> mainline kernel while IPVS is outside the mainstream kernel sounds a bit
> odd to me.   I think in general this is discouraged...

:) Of course. The idea is to submit LVS in overviewable chunks to the 
respective kernel lieutnants. The patch I posted is actually the only 
part where we change anything of the existing kernel tree. The rest are 
new files (also thanks to the cool Kconfig).

I only wanted to ask if those two ifdef'd hooks would be acceptable for 
you guys without sending the whole ipvs patch. You can have a look at it 
for yourselves:

http://www.linux-vs.org/software/kernel-2.5/linux-2.5.69-ipvs-1.1.5.patch.gz

Thanks for you time and the positive answer. See you at OLS,
Roberto Nibali, ratz
-- 
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc