IPv6: No neighbour sollicitation goes unanswered for inet alias

Koen Martens

Koen Martens

Hello forum,

I have a dual-stack FreebsdBSD 9.3 host. I have a main IPv6 address and several aliases on the bridge0 interface (although I have this same problem on another host which has the IPv6 address and aliases on a normal interface, em0). Somehow the aliases won't work for me.

The host is up to date with binary upgrades (freebsd-update):

Code: 
# uname -a
FreeBSD equinox.sonologic.net 9.3-RELEASE-p30 FreeBSD 9.3-RELEASE-p30 #0: Mon Nov  2 10:11:50 UTC 2015  root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

The network interfaces are configured as:

Code: 
# ifconfig
fxp0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500   options=4219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO>
   ether 00:e0:81:4b:d8:44
   nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
   media: Ethernet autoselect (none)
   status: no carrier
bge0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
   options=80099<RXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE>
   ether 00:e0:81:4b:d8:76
   inet6 fe80::2e0:81ff:fe4b:d876%bge0 prefixlen 64 scopeid 0x5
   nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
   media: Ethernet autoselect (100baseTX <half-duplex>)
   status: active
bge1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
  options=8009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE>
   ether 00:e0:81:4b:d8:77
   inet 192.168.0.23 netmask 0xffffff00 broadcast 192.168.0.255
   inet6 fe80::2e0:81ff:fe4b:d877%bge1 prefixlen 64 scopeid 0x6
   inet 192.168.0.100 netmask 0xffffffff broadcast 192.168.0.100
   inet 192.168.0.3 netmask 0xffffffff broadcast 192.168.0.3
   inet 192.168.0.102 netmask 0xffffffff broadcast 192.168.0.102
   inet 192.168.0.101 netmask 0xffffffff broadcast 192.168.0.101
   nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
   media: Ethernet autoselect (1000baseT <full-duplex>)
   status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
   options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
   inet6 ::1 prefixlen 128
   inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7
   inet 127.0.0.1 netmask 0xff000000
   nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
tap0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
   options=80000<LINKSTATE>
   ether 00:bd:96:27:00:00
   inet6 fe80::2bd:96ff:fe27:0%tap0 prefixlen 64 scopeid 0x8
   nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
   media: Ethernet autoselect
   status: active
   Opened by PID 1006
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
   ether 02:81:f4:ec:68:00
   inet 82.94.245.54 netmask 0xffffffc0 broadcast 82.94.245.63
   inet6 fe80::81:f4ff:feec:6800%bridge0 prefixlen 64 scopeid 0x9
   inet6 2001:888:2156::1:1:3000 prefixlen 64
   inet 82.94.245.26 netmask 0xffffffff broadcast 82.94.245.26
   inet6 2001:888:2156::2:2:7 prefixlen 128
   inet 82.94.245.4 netmask 0xffffffff broadcast 82.94.245.4
   inet6 2001:888:2156::2:2:6 prefixlen 128
   inet 82.94.245.23 netmask 0xffffffff broadcast 82.94.245.23
   inet6 2001:888:2156::2:2:14 prefixlen 128
   inet 82.94.190.222 netmask 0xffffffff broadcast 82.94.190.222
   inet6 2001:888:2156::3:42:1 prefixlen 128
   inet 82.94.245.28 netmask 0xffffffff broadcast 82.94.245.28
   inet 82.94.245.55 netmask 0xffffffff broadcast 82.94.245.55
   inet6 2001:888:2156::3:4:3 prefixlen 128
   inet 82.94.245.22 netmask 0xffffffff broadcast 82.94.245.22
   inet6 2001:888:2156::2:2:5 prefixlen 128
   inet 82.94.245.44 netmask 0xffffffff broadcast 82.94.245.44
   inet6 2001:888:2156::3:14:1 prefixlen 128
   inet 82.94.245.21 netmask 0xffffffff broadcast 82.94.245.21
   inet 82.94.245.30 netmask 0xffffffff broadcast 82.94.245.30
   inet6 2001:888:2156::2:1:1 prefixlen 128
   inet6 2001:888:2156::2:1:2 prefixlen 128
   inet 82.94.245.6 netmask 0xffffffff broadcast 82.94.245.6
   inet6 2001:888:2156::2:2:4 prefixlen 128
   inet 82.94.245.5 netmask 0xffffffff broadcast 82.94.245.5
   inet6 2001:888:2156::2:2:11 prefixlen 128
   inet 82.94.245.31 netmask 0xffffffff broadcast 82.94.245.31
   inet6 2001:888:2156::2:2:3 prefixlen 128
   inet6 2001:888:2156::2:2:2 prefixlen 128
   nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
   id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
   maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
   root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
   member: tap0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
    ifmaxaddr 0 port 8 priority 128 path cost 2000000
   member: bge0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
    ifmaxaddr 0 port 5 priority 128 path cost 55
ipfw0: flags=8801<UP,SIMPLEX,MULTICAST> metric 0 mtu 65536
   nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

The relevant interface is bridge0, which has a main address 2001:888:2156::1:1:3000 with prefixlen 64, and a bunch of aliases with prefixlen 128.

Routes for inet6:

Code: 
Internet6:
Destination  Gateway  Flags  Netif Expire
::/96  ::1  UGRS  lo0 =>
default  2001:888:2156::1  UGS  bridge0
::1  link#7  UH  lo0
::ffff:0.0.0.0/96  ::1  UGRS  lo0
2001:888:2156::/64  link#9  U  bridge0
2001:888:2156::1:1:3000  link#9  UHS  lo0
2001:888:2156::2:1:1  link#9  UHS  lo0
2001:888:2156::2:1:2  link#9  UHS  lo0
2001:888:2156::2:2:2  link#9  UHS  lo0
2001:888:2156::2:2:3  link#9  UHS  lo0
2001:888:2156::2:2:4  link#9  UHS  lo0
2001:888:2156::2:2:5  link#9  UHS  lo0
2001:888:2156::2:2:6  link#9  UHS  lo0
2001:888:2156::2:2:7  link#9  UHS  lo0
2001:888:2156::2:2:11  link#9  UHS  lo0
2001:888:2156::2:2:14  link#9  UHS  lo0
2001:888:2156::3:4:3  link#9  UHS  lo0
2001:888:2156::3:14:1  link#9  UHS  lo0
2001:888:2156::3:42:1  link#9  UHS  lo0
fe80::/10  ::1  UGRS  lo0
fe80::%bge0/64  link#5  U  bge0
fe80::2e0:81ff:fe4b:d876%bge0  link#5  UHS  lo0
fe80::%bge1/64  link#6  U  bge1
fe80::2e0:81ff:fe4b:d877%bge1  link#6  UHS  lo0
fe80::%lo0/64  link#7  U  lo0
fe80::1%lo0  link#7  UHS  lo0
fe80::%tap0/64  link#8  U  tap0
fe80::2bd:96ff:fe27:0%tap0  link#8  UHS  lo0
fe80::%bridge0/64  link#9  U  bridge0
fe80::81:f4ff:feec:6800%bridge0  link#9  UHS  lo0
ff01::%bge0/32  fe80::2e0:81ff:fe4b:d876%bge0 U  bge0
ff01::%bge1/32  fe80::2e0:81ff:fe4b:d877%bge1 U  bge1
ff01::%lo0/32  ::1  U  lo0
ff01::%tap0/32  fe80::2bd:96ff:fe27:0%tap0  U  tap0
ff01::%bridge0/32  fe80::81:f4ff:feec:6800%bridge0 U  bridge0
ff02::/16  ::1  UGRS  lo0
ff02::%bge0/32  fe80::2e0:81ff:fe4b:d876%bge0 U  bge0
ff02::%bge1/32  fe80::2e0:81ff:fe4b:d877%bge1 U  bge1
ff02::%lo0/32  ::1  U  lo0
ff02::%tap0/32  fe80::2bd:96ff:fe27:0%tap0  U  tap0
ff02::%bridge0/32  fe80::81:f4ff:feec:6800%bridge0 U  bridge0

When I do ping -S 2001:888:2156::1:1:3000 google.com, I get replies, no worries, everything works as expected.

When I do (for example) ping -S 2001:888:2156::2:2:2 google.com however, I don't get any ping replies.

I checked the interface with tcpdump, to see what icmp6 traffic is happening, and I get this:

Code: 
22:06:56.350356 IP6 2001:888:2156::2:2:3 > 2a00:1450:400c:c01::65: ICMP6, echo request, seq 1, length 16
22:06:56.367091 IP6 fe80:0:0:1013::1 > ff02::1:ff11:1: ICMP6, neighbor solicitation, who has 2001:888:2156::3:11:1, length 32
22:06:56.818808 IP6 fe80:0:0:1013::1 > ff02::1:ff02:3: ICMP6, neighbor solicitation, who has 2001:888:2156::2:2:3, length 32
22:06:57.350347 IP6 2001:888:2156::2:2:3 > 2a00:1450:400c:c01::65: ICMP6, echo request, seq 2, length 16
22:06:57.659640 IP6 fe80:0:0:1013::1 > ff02::1:ff01:1: ICMP6, neighbor solicitation, who has 2001:888:2156::2:1:1, length 32
22:06:57.818826 IP6 fe80:0:0:1013::1 > ff02::1:ff02:3: ICMP6, neighbor solicitation, who has 2001:888:2156::2:2:3, length 32
22:06:58.659958 IP6 fe80:0:0:1013::1 > ff02::1:ff01:1: ICMP6, neighbor solicitation, who has 2001:888:2156::2:1:1, length 32

It looks like the host is not responding to the neighbor sollicitation from the upstream router.

So I enabled neighbour discovery debugging with sysctl -w net.inet6.icmp6.nd6_debug=1 and this gives me a whole lot of:

Code: 
nd6_na_output: source can't be determined: dst=fe80:9:0:1013::1, error=51
nd6_na_output: source can't be determined: dst=fe80:9:0:1013::1, error=51
nd6_na_output: source can't be determined: dst=fe80:9:0:1013::1, error=51
nd6_na_output: source can't be determined: dst=fe80:9:0:1013::1, error=51
nd6_na_output: source can't be determined: dst=fe80:9:0:1013::1, error=51
nd6_na_output: source can't be determined: dst=fe80:9:0:1013::1, error=51
nd6_na_output: source can't be determined: dst=fe80:9:0:1013::1, error=51
nd6_na_output: source can't be determined: dst=fe80:9:0:1013::1, error=51
nd6_na_output: source can't be determined: dst=fe80:9:0:1013::1, error=51
nd6_na_output: source can't be determined: dst=fe80:9:0:1013::1, error=51
nd6_na_output: source can't be determined: dst=fe80:9:0:1013::1, error=51
nd6_na_output: source can't be determined: dst=fe80:9:0:1013::1, error=51

Searching the web for that, I mostly get hits to the sourcecode of nd6_nbr.c, where indeed this error message seems to come from. But I don't know enough of the FreeBSD source code to effectively figure out what is going on.

I'm sure I'm missing something very obvious here, hope to get some help here!

Thanks in advance! And if I've left out any relevant information, let me know.
 
Last edited by a moderator:
Oh, I forgot to add (and i can't edit my post - forum says something about spam-like content), I did check my firewall logs with ipmon (using ipfilter). Nothing relevant is blocked, just a bunch of disallowed ipv4 traffic.
 
I was indeed missing something very obvious: my upstream provider gave me a /48, not a /64. So fixing the prefixlen of the assigned ipv6 address on bridge0 to 48 fixed it.
 
Sadly, it is still wonky. To simplify things, iI've set up a machine without bridging:

Code: 
# uname -a
FreeBSD lmc.sonologic.net 9.3-RELEASE-p30 FreeBSD 9.3-RELEASE-p30 #0: Mon Nov  2 10:11:50 UTC 2015  root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
# ifconfig -a
em0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
   options=4219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO>
   ether 00:e0:81:b7:a6:f1
   inet 82.94.245.43 netmask 0xffffffc0 broadcast 82.94.245.63
   inet6 fe80::2e0:81ff:feb7:a6f1%em0 prefixlen 64 scopeid 0x5
   inet6 2001:888:2156::1:11:1 prefixlen 48
   inet 82.94.245.62 netmask 0xffffffff broadcast 82.94.245.62
   inet6 2001:888:2156::3:11:1 prefixlen 48
   inet 82.94.190.206 netmask 0xffffffff broadcast 82.94.190.206
   inet6 2001:888:2156::3:18:64 prefixlen 48
   nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
   media: Ethernet autoselect (1000baseT <full-duplex>)
   status: active
em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
   options=4219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO>
   ether 00:e0:81:b7:a6:f2
   inet 192.168.0.19 netmask 0xffffff00 broadcast 192.168.0.255
   inet6 fe80::2e0:81ff:feb7:a6f2%em1 prefixlen 64 scopeid 0x6
   nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
   media: Ethernet autoselect (1000baseT <full-duplex>)
   status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
   options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
   inet6 ::1 prefixlen 128
   inet6 fe80::1%lo0 prefixlen 64 scopeid 0xb
   inet 127.0.0.1 netmask 0xff000000
   nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
ipfw0: flags=8801<UP,SIMPLEX,MULTICAST> metric 0 mtu 65536
   nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

Ping from host works fine:
Code: 
# ping6 google.com
PING6(56=40+8+8 bytes) 2001:888:2156::1:11:1 --> 2a00:1450:4013:c01::66
16 bytes from 2a00:1450:4013:c01::66, icmp_seq=0 hlim=56 time=4.636 ms
16 bytes from 2a00:1450:4013:c01::66, icmp_seq=1 hlim=56 time=4.619 ms
16 bytes from 2a00:1450:4013:c01::66, icmp_seq=2 hlim=56 time=4.631 ms
^C

Ping from one alias works fine too:
Code: 
# ping6 -S 2001:888:2156::3:11:1 xs4all.nl
PING6(56=40+8+8 bytes) 2001:888:2156::3:11:1 --> 2001:888:0:18::93
16 bytes from 2001:888:0:18::93, icmp_seq=0 hlim=62 time=0.342 ms
16 bytes from 2001:888:0:18::93, icmp_seq=1 hlim=62 time=0.302 ms
16 bytes from 2001:888:0:18::93, icmp_seq=2 hlim=62 time=0.280 ms
^C

But from another alias, it fails again because there is no reply to the neighbour solicitation, and the kernel console gives me the 'nd6_na_output: source can't be determined' again.

Code: 
ping6 -S 2001:888:2156::3:18:64 xs4all.nl
PING6(56=40+8+8 bytes) 2001:888:2156::3:18:64 --> 2001:888:0:18::93
Dec  6 14:52:02 lmc kernel: nd6_na_output: source can't be determined: dst=fe80:5:0:1013::1, error=51
^C
--- xs4all.nl ping6 statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss

And the tcpdump for that:
Code: 
# tcpdump -n -i em0 icmp6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em0, link-type EN10MB (Ethernet), capture size 65535 bytes
14:52:01.538195 IP6 2001:888:2156::3:18:64 > 2001:888:0:18::93: ICMP6, echo request, seq 0, length 16
14:52:02.304271 IP6 fe80:0:0:1013::1 > ff02::1:ff18:64: ICMP6, neighbor solicitation, who has 2001:888:2156::3:18:64, length 32
14:52:02.539094 IP6 2001:888:2156::3:18:64 > 2001:888:0:18::93: ICMP6, echo request, seq 1, length 16
14:52:03.304136 IP6 fe80:0:0:1013::1 > ff02::1:ff18:64: ICMP6, neighbor solicitation, who has 2001:888:2156::3:18:64, length 32
14:52:03.538101 IP6 2001:888:2156::3:18:64 > 2001:888:0:18::93: ICMP6, echo request, seq 2, length 16
14:52:04.304009 IP6 fe80:0:0:1013::1 > ff02::1:ff18:64: ICMP6, neighbor solicitation, who has 2001:888:2156::3:18:64, length 32
14:52:04.538097 IP6 2001:888:2156::3:18:64 > 2001:888:0:18::93: ICMP6, echo request, seq 3, length 16
14:52:05.538094 IP6 2001:888:2156::3:18:64 > 2001:888:0:18::93: ICMP6, echo request, seq 4, length 16

I don't quite get it. I'm sure it's a configuration error somehow, but apparently I don't understand IPv6+FreeBSD enough to make this work.

It starts to work after a
Code: 
# ifconfig em0 inet6 fe80:5:0:1013:2e0:81ff:feb7:a6f1%em0

after which the config is:

Code: 
# ifconfig -a  
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
  options=4219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO>
  ether 00:e0:81:b7:a6:f1
  inet 82.94.245.43 netmask 0xffffffc0 broadcast 82.94.245.63
  inet6 fe80::2e0:81ff:feb7:a6f1%em0 prefixlen 64 scopeid 0x5
  inet6 2001:888:2156::1:11:1 prefixlen 48
  inet 82.94.245.62 netmask 0xffffffff broadcast 82.94.245.62
  inet6 2001:888:2156::3:11:1 prefixlen 128
  inet 82.94.190.206 netmask 0xffffffff broadcast 82.94.190.206
  inet6 2001:888:2156::3:18:64 prefixlen 128
  inet6 fe80::1013:2e0:81ff:feb7:a6f1%em0 prefixlen 64 scopeid 0x5
  nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
  media: Ethernet autoselect (1000baseT <full-duplex>)
  status: active
em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
  options=4219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO>
  ether 00:e0:81:b7:a6:f2
  inet 192.168.0.19 netmask 0xffffff00 broadcast 192.168.0.255
  inet6 fe80::2e0:81ff:feb7:a6f2%em1 prefixlen 64 scopeid 0x6
  nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
  media: Ethernet autoselect (1000baseT <full-duplex>)
  status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
  options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
  inet6 ::1 prefixlen 128
  inet6 fe80::1%lo0 prefixlen 64 scopeid 0xb
  inet 127.0.0.1 netmask 0xff000000
  nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
ipfw0: flags=8801<UP,SIMPLEX,MULTICAST> metric 0 mtu 65536
  nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

but iI'm not sure why iI'd need to do that.

Thanks for any help!
 
Last edited by a moderator:
Hi,

I had a similar, if not the same issue and was googling for these symptoms. For me it was a manually misconfigured default gateway which had something like fe80:1::1 as its link local address. But link local addresses should be from the fe80::/64 range, although the total reserved range is a /10. I was able to see solicitations from fe80:1::1 in tcpdump, but that's what i'm missing from your packet captures. You're seeing solicitations from fe80:0:0:1013::1, but nd6_na_output is complaining about fe80:5:0:1013::1 and fe80:9:0:1013:1. So, not sure about this.
You could enable net.inet6.icmp6.nd6_onlink_ns_rfc4861, but that imposes a security risk.

BR,
Felix
 
You must log in or register to reply here.
Back
Top