On Tue, 2004-02-10 at 20:52, Julian Anastasov wrote:
> > > 2. we lie and send false answers to unicast probes, for long time
> > > after target becomes unreachable
> > This is current behavior; i wouldnt say we lie rather we send educated
> > response back.
> To clear this issue, do you mean this case 2 is for entry in
> STALE state? And because we are not probing it its state in our cache is
> outdated. You prefer in this case to send answer, right? Because I
> do not see a good reason to send answer for FAILED/INCOMPLETE/NONE.
> And because STALE is part of VALID we always will send answer,
> no matter brd/uni. I do not see where we need to send ARP reply
> for !NUD_VALID.
I agree with you. We may be saying the same thing. What i mean is [**]:
> > > I can agree with you (for case 2) only if the requestor is
> > > not going to send unicast probes forever.
> > Thats why i asked if you are trying to catch insane implementation.
> > In my case everything is Linux. Ok, theres some pollution with
> > a CISCO upstream, but that seems to have a sane arp too.
> > Leave #2 with a flag to ask for for neigh_event_send() to be used
> > when needed.
> I only worry if you want to send replies to unicast
> probes in FAILED/INCOMPLETE/NONE state. If we have valid neighbour,
> even STALE one, we can send reply no matter the uni/brd type.
> brd/uni are differently treated only for the delay but we should
> ignore both uni and brd requests if the entry is !VALID.
Thats what i was also trying to say with a small caveat
> I think, it is not enough the flag to control whether
> neigh_event_send is used, if the flag is 0 you want also to
> send replies in !VALID state (as before) because nobody will
> send us IP traffic without receiving answer from us - only
> IP traffic can originate resolution in such case. For now, I
> see that the flag can be only in this way (on output interface?):
Look at that sample code i sent earlier - thats what ive been meaning to
say all along ;-> Gives meaning to code speaks louder ;->
> - 0: (default, as before): send answers in !VALID, do not use
> neigh_event_send. The problem with the old behaviour is that
> we always send answer, even in !VALID.
> - 1: (new): do not send answers in !VALID, use neigh_event_send
> do you mean the same?
I think so.
> > I dont question the validity of this portion of your patch.
> > i.e it is an improvement in certain cases - the cost is only an extra
> > neigh_event_send(). But because it is not needed 100% of the time given
> And I do not see any cost in using neigh_event_send,
> you are always going to fire the resolution process, now with ARP
> probes or later with IP traffic in the default mode. The ARP
> traffic to/from target will be equal in both cases.
Ok, so you agree with what i say in [**] but you are just trying to
ensure it happens all the time i think.
> > the educated assumption being made right now, i think the behavior
> > should be configurable. For me #2 breaks only if the target dissapeares
> > (cable gone or target removed).
> I hope you can clarify your idea with pseudo-C example :)
The previous sample i sent + [**] below.
Note that in the sample code i sent case of proxy_delay being zero even
bcasts are treated the same way.
[**] If a linux machine (which is sane ARP implementation) sent a unicast
probe to us, theres high likelihood that the target is in VALID state.
This is what i refered to as an educated guess.