Hi, Dusan, On 02/08/2013 03:12 PM, Mudric, Dusan (Dusan) wrote: > · During the time 173 can’t reach 172 there are ICMPv6 NS > messages from 173 and NA to 173. 173 ndisc_recv_na() is not called. > NAs are silently discarded somewhere. At the same time, 173 neighbor > cache entry does not follow the RFC4861. neigh_update() state changes > from INCOMPLETE to STALE do DELAYED after the first timeout. It > should stay in INCOMPLETE.
If at some point ND had been successful for such address, I think such entry should remain in the "STALE" state rather than move to INCOMPLETE (of the top of my head). > From DELAYED state it goes to PROBE which > is allowed by RFC. It stays in PROBE for 3sec (3 NS retransmissions) > and goes to FAILED state. 2sec later is send NS again and goes into > DELAYED state. > > 3. NDP: > > a. 172 sends only 3 solicitation request for 173 during the > capture period, while 173 sends solicitation to 172 every second > > b. 173 reach 172 only after 172 sends advertisement to 173’ LL > address (not the global one and without the “override” flag) > > Q: Is this a known problem? If yes, is there a patch for it? For this kind of scenario, it's usually helpful if you can provide a packet trace (e.g. tcpdump formated). That said, as noted by others the Linux netdev might be a better place to ask this question... or for instance, you might want to ask it on the ipv6hackers mailing-list: <http://lists.si6networks.com/listinfo/ipv6hackers/> Cheers, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
