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

[Paul Jakma]

On Thu, 2 Sep 2004, Einar Lueck wrote:

> Please apologize: I fear I have not specified the setups we address
> precisely enough: I think it helps to imagine the following scenario:
> 1. SERVER1 mounts some NFS stuff exported by SERVER2.
> 2. SERVER1 has two NICs.
> 3. The souce IP address of the related packets is the IP address
> of the NIC the kernel identifies for the outbound route, or the IP
> address specified via a static route (ip route .... src SVIPA)
> 4. In case no static routes are allowed and iptables NAT is no
> option, the relevant packets thus have the IP of a NIC.
> 5. In case the corresponding NIC dies, we have a serious problem.

> This is works of course, too. But it does not solve the problem 
> described above. But, maybe I misunderstood you. Please correct me, 
> if I am wrong.

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.

Why would it not work?

> > hey presto, "virtual IP" which you can redistribute connected in
> > ospfd/ripd whatever and publish in DNS.
>
> I think this is the same as the first point.

But you must describe why it would not work. *Why*?

> NFS works in kernel. Therefore we could not intercept the 
> corresponding "connect" calls. As a result, the problem scenario 
> described above could not be solved.

Why could it not be solved? And why is the answer not "ask the knfsd 
people to provide bind-to-ip option"?

> You are right, but the packets do not come in, they go out, as I 
> tried to illustrate above. Anyway, in the other case you are 
> completely right.

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.

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?

> 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?

> Regards
> Einar

regards,
--
Paul Jakma	paul@xxxxxxxx	paul@xxxxxxxxx	Key ID: 64A2FF6A
Fortune:
People say I live in my own little fantasy world... well, at least they
*know* me there!
		-- D.L. Roth
-
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/