lkml.org 
[lkml]   [2004]   [Sep]   [2]   [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 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@clubi.ie paul@jakma.org 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@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:05    [W:0.182 / U:0.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site