Bug 214746 - Carp ipv6 duplicate address detection
Summary: Carp ipv6 duplicate address detection
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.3-RELEASE
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-net (Nobody)
Keywords: needs-qa
Depends on:
Reported: 2016-11-22 16:18 UTC by Athanasios Douitsis
Modified: 2016-12-03 09:53 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Athanasios Douitsis 2016-11-22 16:18:49 UTC
Somewhat difficult to ascertain whether this has been previously reported, apologies if this is a duplicate bug.

Trying to use carp and IPv6 on a 10.3-RELEASE. Two machines, each one with its own IPv6 address and one common IPv6. Fairly simple.

When a machine boots (the other one is obviously MASTER and has acquired the common IPv6 address), complaints about duplicate address detection of the common IPv6 are logged by the booting machine's kernel.

kernel: vmx0: DAD detected duplicate IPv6 address <commonipv6address>: NS in/out/loopback=0/1/0, NA in=1
kernel: vmx0: DAD complete for <commonipv6address> - duplicate found

As a result, the machine that has just booted has the duplicated flag for that address in ifconfig and services that want to bind to that common address fail to start. In other words, the BACKUP cannot bind to the common address.

Trying to setup the common address and carp by hand using ifconfig initially fails with:

#ifconfig vmx0 inet6 <commonipv6address>/64 vhid 34 pass <my_pass>
ifconfig: ioctl (SIOCAIFADDR): No such file or directory

What's curious, second time that command is issued, no errors are printed and the address is assigned to the interface.

Using the no_dad ifconfig flag seems to solve the problem, but I suspect that this workaround is not extremely good as it disables DAD.
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2016-12-03 02:42:51 UTC
@Athanasios Could you please attach a file containing the non-working and working configurations (ie: /etc/rc.conf, if specified there). 

Please also include the exact FreeBSD version (uname -a) output.
Comment 2 Athanasios Douitsis 2016-12-03 09:53:00 UTC
(In reply to Kubilay Kocak from comment #1)

Running FreeBSD 10.3-RELEASE-p11 #0: Mon Oct 24 18:49:24 UTC 2016 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64 on both nodes.

This works (dead:beef instead of my real prefix):

ifconfig_vmx0_ipv6="inet6 accept_rtadv dead:beef::60/64"
ifconfig_vmx0_alias1="inet6 dead:beef::95/64 no_dad vhid 34 pass bar”

dead:beef::60 is node0 and dead:beef::61 is node1. Both have dead:beef::95/64 as the common carp IPv6 address. Vhid 34 is randomly chosen. 

For IPv4, I'm using a different vhid and pass, just to be on the safe side.

Removing the no_dad from ifconfig_vmx0_alias1 and rebooting the BACKUP node causes the problem to appear. Backup node will compain about DAD upon reboot, ifconfig will say dead:beef::95/64 duplicated, so it can't really be used. 

Afterwards, trying to manualy issue 

ifconfig inet6 dead:beef::95/64 vhid 34 pass bar

will fail the first time, second time it will go through.