Messages in this thread | | | Date | Tue, 7 Sep 2004 17:34:18 +0200 | From | Herbert Poetzl <> | Subject | Re: [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/
| |