Re: kern/54057: ipv6 neighbor discovery fails to resolve address

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Tue, 12 Mar 2019 14:24:47 +0100 (CET)
    From:        Havard Eidnes <he%uninett.no@localhost>
    Message-ID:  <20190312.142447.676762096099488390.he%uninett.no@localhost>

  | The two connected router interfaces are configured with a shared
  | global address supported by VRRP.  That's probably not what you
  | refer to above as an IPv6 anycast address.

Probably not (and it appears not from the packet trace you appended
in this message) but (given that I know nothing about how VRRP works)
that's the kind of operation where an anycast default router addr
might make sense.   It all depends upon just how seamless the dual
(or more) router config is designed to be - ones where it is essentially
impossible to tell which router is processing the packets would not
normally use anycast (they tend to need to use the same MAC addr for
example) less tightly coupled setups might (and the hosts deal with the
loss of one of the routers, and switch to another, knowing what it is
they are doing ... which usually means a brief (but detectable) period
of network outage, but generally designed to be much less than what would
cause a TCP session to time out - it looks more like a few lost packets.

All this is much quicker than simply having 2 (or more) independent
routers, and relying upon RA timeouts to detect a vanished router,
and pick a new one - that generally takes long enough to reconnect
that TCP (and many UDP applications, like DNS lookups) has given up
before the host picks a new default router and can reach the world again.

  | I saved the pcap file,

That's great - I wish more people would do things that way.   It makes
it much easier to investigate once you have managed to capture the
"interesting event".

  | here it is decoded with -v -v:

I will look at that more carefully tomorrow, but from what I can see
the router(s) is/are configured to require the hosts to use DHCPv6
for address assignment (etc).   That will mean that (I assume) dhcpcd
is configuring the v6 default router - which might be why its link addr
isn't being configured at the same time (which should be happening if
stateless autoconfig were being used.)

I also have a suspicion what might have happened, but unless someone
else analyses this first (in the next dozen hours or so) I need to look
at our ND code to see just how it would process that NS/NA sequence.

  | ...and now when I try to repeat it, of course I can't reproduce
  | it at my desk; an entry is now entered in my neighbor cache:

Of course, that's always the way!   At least that confirms that it
should work (and generally does work)  we just need to work out why
it did not work, which is where having that packet trace is so useful.

kre