On 05.09.2017 18:25, Greg Rivers wrote: > dtrace saw nothing, yet tcpdump recorded what one would expect. Apparently > the inbound RAs and NSs are not making it through to the IPv6 stack. At this > point I suspect a bug in the Emulex oce(4) driver, or a bad interaction > between oce(4) and lagg(4). I have not seen this issue on hosts with lagg and > other NICs. As soon as I can, I'm going to eliminate lagg and repeat the > experiment while running on just one oce interface. I'll report back with > results. > >>> $ ping6 fe80:XXXX:XXXX:4013:23::2%lagg0 >>> ping6: UDP connect: Network is unreachable >> >> Hmm. Can you show the second word of address in this example? >> Is it not zero? I.e. fe80:XXXX: is correct or you missed '::' part? >> > Correct, neither of the XXXX parts are zero; the :: part is at the end of the > address: ...::2%lagg0. Sorry for the obfuscation, but policy at $WORK about > company information on public lists is very strict.
I think the problem is not with oce(4) driver. Unfortunately, your router uses IPv6 LLA that is not compatible with KAME based IPv6 stack that is used by all BSDs. The FreeBSD kernel internally uses special form of IPv6 addresses, that have IPv6 scope zone id embedded into second word of address. This problem was recently discussed here: https://mailarchive.ietf.org/arch/msg/ipv6/fuzpfBXJHeBfsEddMBtgIpGjKvk Some time ago I have patched the kernel to avoid use of this hack, but this was done for 9.3 kernel and currently I have no time to port patches to recent CURRENT. -- WBR, Andrey V. Elsukov
signature.asc
Description: OpenPGP digital signature
