Re: [PATCH] net/ipv4 for Source VIPA support, kernel BK Head
From: Herbert Poetzl
Date: Tue Sep 07 2004 - 11:17:03 EST
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 ...
> > 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.
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/