default route via SLAAC not working ?

[Trond Endrestøl]

On Mon, 31 Jul 2017 13:47-0400, Mike Tancsa wrote:

> On 7/31/2017 11:54 AM, Trond Endrestøl wrote:
> >>
> >> Is there a way to manually force a solicitation by the interface ?
> > 
> > rtsol(8), e.g. rtsol ue0 or rtsol -a.
> > 
> 
> Thanks!  A little further. It seems at bootup time, I do get a default
> route installed. But then it goes away
> 
> % netstat -nr6 | head -6
> Routing tables
> 
> Internet6:
> Destination                       Gateway                       Flags
>    Use    Mtu    Netif Expire
> ::/96                             ::1                           UGRS
>      0  16384      lo0
> default                           fe80::a671:74ff:fe2b:c137%ue0 UG
>      3   1460      ue0
> 
> % ping6 -c 2 www.freebsd.org
> PING6(56=40+8+8 bytes) 2605:8d80:6e3:f899:e5b:8fff:fe27:9a64 -->
> 2001:1900:2254:206a::50:0
> 16 bytes from 2001:1900:2254:206a::50:0, icmp_seq=0 hlim=50 time=382.217 ms
> 16 bytes from 2001:1900:2254:206a::50:0, icmp_seq=1 hlim=50 time=149.969 ms
> 
> --- wfe0.ysv.freebsd.org ping6 statistics ---
> 2 packets transmitted, 2 packets received, 0.0% packet loss
> round-trip min/avg/max/std-dev = 149.969/266.093/382.217/116.124 ms
> % ifconfig ue0
> ue0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0
> mtu 1500
>         ether 0c:5b:8f:27:9a:64
>         hwaddr 0c:5b:8f:27:9a:64
>         inet6 fe80::e5b:8fff:fe27:9a64%ue0 prefixlen 64 scopeid 0x10
>         inet6 2605:8d80:6e3:f899:e5b:8fff:fe27:9a64 prefixlen 64 autoconf
>         inet 192.168.8.100 netmask 0xffffff00 broadcast 192.168.8.255
>         nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
> 
> 
> About 6 min after boot up, the kernel (pid 0?) deletes the default route
> for whatever reason (output from route monitor)
> 
> got message of size 312 on Mon Jul 31 13:28:31 2017
> RTM_DELETE: Delete Route: len 312, pid: 0, seq 0, errno 0,
> flags:<GATEWAY,DONE>
> locks:  inits:
> sockaddrs: <DST,GATEWAY,NETMASK,IFP,IFA>
>  default fe80::a671:74ff:fe2b:c137%ue0 default ue0:c.5b.8f.27.9a.64
> fe80::e5b:8fff:fe27:9a64%ue0

That's strange. I've never seen such behaviour before.
Maybe a packet capture can provide more clues.

-- 
Trond.