Re: [PATCH] net/ipv4 for Source VIPA support, kernel BK Head

[Herbert Poetzl <herbert@13thfloor.at>]

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/