Re: Re: ARP relay

Andreas Hofmeister wrote:

> Ok, but in this case one should just handle each network interface on
> its own - each interface would have its own link local address. 
> 
> A linux kernel would answer ARP-Requests for one of its IP addresses on
> any interface, regardless whether the an IP address belongs to that
> interface (afaik, BSD wouldn't). For Linux, an IP address belongs (more
> or less) to the system, not to the interface. Don't be confused by what
> ifconfig suggests, that program has been written for the IP-stack in
> Linux 2.0, wich has been completly replaced in Linux 2.2.

Thanks -- this is interesting. You are right, and I had not considered 
this yet.

<Off-topic>
I think the networking code in Linux is flawed. Even though I often use 
Linux in a research environment, I'm always surprised how little the 
code seems to grasp from the protocols itself. For example, take the 
Window Size of TCP. In short, this is the number of unconfirmed bytes 
(the size of the data along the way, typically the round trip time times 
the bandwidth). This is an important parameter internal the the TCP 
protocol used to control the bandwidth and back-off in case of 
congestion. In Linux (and any TCP implementation), you can set the 
maximum window size. However, if you then ask the same parameter, you 
always get a size twice as large. Apparently, that is the amount of 
memory the implementation allocates. But that is unrelated to the 
maximum window size mentioned in the protocol. A colleague submitted 
that as a bug to kernel developers, but it was ignored. And there are a 
few more examples. I still have the impression that BSD network code is 
superior.
</Off-topic>


> There is a patch for Linux 2.4, that would broadcast ARP requests and
> adjust the route depending on what interface the response has been
> recieved on.

Would it be a good idea to distribute this patch along with zcip? Or at 
least link to it from the Zeroconf.sf.net website?

Interesting patch by the way. Does it also work for non link-local IP 
traffic? If I send traffic to a host, and if it arrives on interface A, 
the return traffic may just as well go out on another interface (eth1 
for example), based on the routing table. If I ignore what I know about 
the route implementation, a more logical approach would be to return the 
traffic of an established connection of that same interface.

I have some experience in applying patches to the kernel (not modifying 
it myself. The one time I tried was a core-dump and computer-crash 
disaster ;) ). For example, the web-100 patches (which allows you to 
tweak more of the TCP parameters), and patches to get a Chelsio driver 
to work (Chelsio sells 10 Gb/s network cards which do full 
TCP-offloading; normal network cards eat 30%-60% of CPU usage just to 
sent out the data, but computers are slow anyway -- the fastest PCI-X is 
the bottleneck: you can't sent more then 8.5 Gb/s). That thought me that 
the kernel code change considerable between linux minor versions, so we 
may just link to patches, because at least I am not capable of keeping 
them up-to-date. (Or at least, I don't have the time to become capable).


Thanks for your explanation of ARP relaying.
I see how the solution you describe can work. However, I personally 
don't think that is a particular good solution. I would probably like a 
solution better which does allow adjacent subnets to use the same IP 
address. All IPv6 API's and most IPv4 API do allow you to specifically 
select the network interface if you open a network socket. That way, an 
application can distinguish between IP 1 on subnet A and the same IP 1 
on subnet B.
If this is combined with a kernel patch like you describe above, I think 
that would be a more elegant solution to the multi-homed problem, since 
the complexity is solved at the computer level, rather then at the 
network level.

Or am I missing something here? (disclaimer: I did not have coffee yet 
this morning).

Regards,
Freek


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20