While troubleshooting an OSPFv3 neighbor stuck in ExStart over a sit tunnel, I came across this post. Correcting the link-local address from /128 to /64 corrected the ospfv3 neighbor problem. This article was posted 2+ years ago and referenced v1.6. I'm running v1.9 and have the same bug. Any news on fixing this long term?? (every reboot I have to reset the link-local address to /64).
From the original post:
Indeed changing the address to a /64 netmask brings the OSPFv3 adjacency up!
# run show ipv6 ospfv3 neighbor
Neighbor ID Pri DeadTime State/IfState Duration I/F[State]
10.97.7.2 1 00:00:33 ExStart/PointToPoint 00:00:02 tun2[PointToPoint]
# delete protocols ospfv3 area 0.0.0.0 interface tun2
# commit
# ip a d fe80::a61:701/128 dev tun2
# ip a a fe80::a61:701/64 dev tun2
# ip a s tun2
8: tun2: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1402 qdisc noqueue state UNKNOWN
link/sit 10.97.7.1 peer 10.97.7.2
inet6 fe80::a61:701/64 scope link
valid_lft forever preferred_lft forever
# set protocols ospfv3 area 0.0.0.0 interface tun2
# commit
# run show ipv6 ospfv3 neighbor
Neighbor ID Pri DeadTime State/IfState Duration I/F[State]
10.97.7.2 1 00:00:33 Full/PointToPoint 00:00:16 tun2[PointToPoint]