lkml.org 
[lkml]   [2004]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] net/ipv4 for Source VIPA support, kernel BK Head
On Fri, Sep 03, 2004 at 10:07:29AM +0200, Einar Lueck wrote:
> On Donnerstag, 2. September 2004 22:59 Paul Jakma wrote:
> >
> > I dont see why it wouldnt work, it almost undoubtedly will work for
> > NFS over TCP. And any problems to cause it to not work would be best
> > taking up on the linux-nfs list in order to have a "bind to address"
> > option added to knfsd.
>
> I just set up the loopback interface via ZEBRA/OSPF as You described it
> and checked via tcpdump the source IP address of the related NFS packets.
> The kernel chooses the IP address of the NIC he routes the packets over as
> the source IP address and not the Source VIPA configured for loopback.
>
> You are right, it would be one option to have a "bind to address" in KNFSD.
> But our idea was to implement a feature well known from other operating
> systems like AIX to Linux because this feature is quite popular and liked
> especially by large customers. As You have read for sure such a feature
> adding redundant functionality to the kernel is not desired. So maybe we
> should continue our discussion privately. Thanks for Your suggestions!
>
> >
> > Why could it not be solved? And why is the answer not "ask the knfsd
> > people to provide bind-to-ip option"?
> >
>
> We would win a facility allowing for a Source VIPA for all
> kinds of servers not offering an explicit bind option. So: Due to the
> feature port idea mentioned above.

btw, something very similar is implemented and used
by linux-vserver (it's called chbind) to restrict
0.0.0.0 (IADDR_ANY) binds to specified address(es)

if you need more details, just let me know ...

best,
Herbert

> > But on a server, the packets that go out tend to be replies to
> > requests. Or at least, the only packets of interest are replies. It's
> > a rare server that just off its own bat goes and talks to clients
> > which have not communicated first with the server before.
>
> The enterprise customers we care about have for example servers
> that utilize other servers (application servers utilizing a database or
> a NFS server, etc.). So to generate replies these servers need
> replies of other servers .
>
> >
> > Anyway, even if the server for some reason initiated traffic, the
> > correct answer surely is "modify the server to bind to a specific
> > address", no?
>
> As mentioned above ;)
>
> >
> > > Bonding offers a failover facility. For more details, please refer to:
> > > Documentation/networking/bonding.txt in the kernel tree.
> >
> > Right, but what does bonding (layer 2) have to do with virtual IPs
> > and IP source address?
> >
>
> If we focus for a moment just on the NIC-fail-over issue (not caring
> about layers, virtual IPs, etc.) then bonding offers the desired failover with
> some restriction. This is the reason why I mentioned it in this context.
>
> Again, thanks for Your suggestions and maybe we should continue our
> discussion privately.
>
> Regards
>
> Einar.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:06    [W:0.049 / U:1.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site