David S. Miller wrote:
In the ARP request we are using the source address in the packet we
are building for output.
Well, you shouldn't be! The ARP request represents all FUTURE
packets being sent out that interface, not just the one single packet that
happened to kick of this ARP request.
If ARP doesn't work using that source address, we can only assume IP
communication is not possible either.
That's clearly not a valid assumption. For a start it precludes IP
routeing, but I've also demonstrated it not to be the case with a simple
multi-homed server.
Thanks,
Richard
On Tue, 19 Aug 2003 19:05:13 +0100
Richard Underwood [off-list ref] wrote:
The ARP request represents all FUTURE
packets being sent out that interface, not just the one single packet that
happened to kick of this ARP request.
That's RIGHT! And by your own argument the source address
in the ARP request IS IRRELEVANT and is to be ignored!
Ok, I've lost 3 days of talking about ARP non-stop, I think
I'll take a break from these threads for a while, it's getting
to be a bit much.
David S. Miller wrote:
On Tue, 19 Aug 2003 19:05:13 +0100
Richard Underwood [off-list ref] wrote:
quoted
The ARP request represents all FUTURE
packets being sent out that interface, not just the one single packet that
happened to kick of this ARP request.
That's RIGHT! And by your own argument the source address
in the ARP request IS IRRELEVANT and is to be ignored!
The source address in the ARP request is not irrelevant, because a
broadcast arp request causes all recipients of that broadcast request to
update their arp cache entry (if they have a cache entry for that IP)
for the IP specified in the source with the MAC specified in the request.
So, in an environment where a single address is aliased in multiple
places, such as tunnel endpoints and loopback aliases, and in
multi-homed same-segment configs, it is unpredictable asto which IP will
be bound to which MAC for every machine (or arp cache) on the network.
--Harley