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

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

The following reply was made to PR kern/54057; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: Havard Eidnes <he%uninett.no@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, kern-bug-people%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/54057: ipv6 neighbor discovery fails to resolve address
Date: Tue, 12 Mar 2019 22:44:29 +0700

     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