Hi Akisada-san,
Yukiyo Akisada wrote:
> Hi, Karsten.
>
> In Test v6LC.2.3.13,
> your box changed your Neighbor Cache State for TR1 to REACHABLE
> by receiving Redirect from TR1 as you said.
>
> But, now I have doubt about Test v6LC.2.3.14.
> In this test, you got PASS.
> Why your box didn't change to REACHABLE by the Redirect?
>
> I think that the situation for TR1 is similar
> between v6LC.2.3.13 and v6LC.2.3.14.
>
Yes, they are similar but not same. Notable difference is that NUT receives
Redirect when NCE for TR1 is in PROBE state in v6LC.2.3.14.A.
That is an exception case of the linux's behaviour.
I summarized the behaviour as follows;
o Linux considers the Redirect as upper-layer reachability confirmation as described
in rfc4861 appendix C.
o But linux doesn't change NCE state from PROBE to REACHABLE only by upper-layer
reachability confirmation. Linux allows to update it to REACHABLE from DELAY or from
REACHABLE by upper-layer reachability confirmation.
Regarding to the failed cases in v6LC.2.3.13;
o NUT changes NCE for TR1, which is in DELAY state, to REACHABLE by Redirct.
o Cleanup procedure in v6LC.2.3.13 doesn't kill the NCE in NUT.
o Initialization procedure in the next test expects NS for TR1 from NUT,
but NUT doesn't send NS because it's in REACHABLE at that moment.
In my lab, v6LC.2.3.14 also sometimes failed. It's because NCE for TR1 could be alive
after the previous test is finished. But it's triggered also by the cleanup procedure of
v6LC2.3.13, not of 2.3.14.
For example, in the log which I sent to Akisada-san, test #223-#225 of v6LC.2.3.14 failed.
And #222 of v6LC.2.3.13 was passed. In #222, the cleanup procedure is done at 16:44:59.
As I said before, NCE for TR1 was not killed after #222 is completed. So initialization
in #223-#225 failed. In #225, NUT processed 'Neighbour Unreachability Detection' (ie.
send NS to unicast address of TR1). It resulted that the NCE was unreachable at 16:45:28
so the NCE in NUT was killed then. The initialization in next test, #226, succeeded because
there was no NCE for TR1 at that moment.
The duration b/w completion of #222 and failure of #225 was 29 seconds. Since it was within
the range of 'ReachableTime' described in rfc4861, the result makes sense for me.
Could you check #222 of Karsten's log? I'm guessing that NUT processed 'Neighbour Unreachability
Detection' at #222. If so, the NCE was killed in #222. And the later tests were passed
because all Redirects were received in PROBE state.
*My guess* is, linux folks think that a node should wait for the response(ie. NA) once
request it(ie. sending NS). and should not change the state to REACHABLE without receiving
the response.
Thanks,
-toyo
> For the reference,
> I attached expected state machine.
>
> Thanks,
>
>
> On Fri, 13 Jun 2008 07:56:34 +0200
> Karsten Keil <kkeil@suse.de> wrote:
>
>> On Fri, Jun 13, 2008 at 08:36:32AM +0900, Yukiyo Akisada wrote:
>>> Hi, Karsten
>>>
>>>> Hmm, this seems not to be the case, I did run these test with Linux as NUT
>>>> and Test v6LC.2.3.13 Part B-E are skipped because of "initialization fail"
>>>> I can send you logs if you want.
>>> Of course, I want to see the log.
>>>
>> I attach the nd.p2 dir as private mail because of size, feel free to post
>> anything from the logs on the list.
>>
>> --
>> Karsten Keil
>> SuSE Labs
>> ISDN and VOIP development
>> SUSE LINUX Products GmbH, Maxfeldstr.5 90409 Nuernberg, GF: Markus Rex, HRB 16746 (AG Nuernberg)
>>
>
>