Alan Cox wrote:
One thing I agree with you about is that an ARP resolution for an
address via one path should not block a resolution for it by another
path since to begin with the two paths may be to different routers
one of which is down.
Alan,
I can't believe that you're advocating networking code where:
1) It's not predictable - the route of a packet depends on the ARP reply
generated due to a previous packet.
2) Linux will fail to communicate with the vast majority of routers under
some, fairly basic, conditions.
I'm certain that Cisco (for example) won't change their ways. I
can't blame them, either - no one else does it this way and there's no good
reason for doing it like this either.
I think I'm going to give up at this point because I know I'm not
going to get anywhere. A simple static ARP entry will fix my problems,
although I'd prefer a more generic solution.
Good luck!
Richard
On Tue, 19 Aug 2003 23:12:38 +0100
Richard Underwood [off-list ref] wrote:
I'm certain that Cisco (for example) won't change their ways.
I don't believe this.
In cases where we've been able to show their devices to
be faulty, they've fixed their kit. Go check out what
happened wrt. the ECN issues their firewall products had.
On Tue, 19 Aug 2003 15:11:37 -0700
"David S. Miller" [off-list ref] wrote:
On Tue, 19 Aug 2003 23:12:38 +0100
Richard Underwood [off-list ref] wrote:
quoted
I'm certain that Cisco (for example) won't change their ways.
I don't believe this.
In cases where we've been able to show their devices to
be faulty, they've fixed their kit. Go check out what
happened wrt. the ECN issues their firewall products had.
Yes, but you failed to explain their fault in this discussed issue so far.
Still there is no good explanation for what can be broken if setting the source
ip of an arp request with the interface ip instead of the originating ip (iff
localhost).
According to your own words:
1) the destination host must not care
2) the source ip is no more visible if the request succeeds and a corresponding
entry in the table is made. So originating host has no chance to find out what
it was later on.
Who else should care?
This discussion could btw have ended months ago (it is coming up now and then)
if a _simple_ way was implemented (like proc-setting) to switch between the two
possibilities.
I always thought we are doing a consensus project here.
I guess it would be utmost simple to create a patch that implements something
like:
echo > /proc/sys/net/ethX/idontknowwhat 0 (current default behaviour)
echo > /proc/sys/net/ethX/idontknowwhat 1 (source ip of arp request following
the interface)
echo > /proc/sys/net/ethX/idontknowwhat 2 (don't answer arps on this
interface)
It's _simple_ for the user and contains every piece we talked about so far.
Shoot me for not being member of any religion.
Regards,
Stephan