Comment 2 for bug 1011134

Confirmed here as well.

There can be issues with IPv6 failing to initialize in a VM that is running on a host machine which is bridging the network traffic to the host's physical ethernet port. The issue appears because of two reasons:

1. IPv6 has a duplicate address detection feature, where if it sees packets from the same IPv6 Link-Local (MAC-based) address as itself, it assumes that there is another box on the same network with the same MAC address.
2. With network bridging hairpin'ing turned on, all packets are reflected back to the VMs, so any IPv6 traffic is duplicated and sent back to the VM... which means that the IPv6 duplicate address detection code activates and the IPv6 subsystem skips initialization.

The bug has to do with two separate systems stomping on each other:

1. The bridge is misconfigured. Either it is in promiscuous mode, or the virtual network interface has hairpin'ing turned on. Hairpin'ing reflects all traffic, including IPv6 Neighbor Solicitation messages, back to the sender.
2. The Linux kernel IPv6 code, upon seeing the reflected IPv6 Neighbor Solicitation message, assumes the address is in use (when it really isn't) and doesn't bring the link up all the way as a result.

Detecting the issue
---------------------------

On the VM, run the following command to see if you have an IPv6 Duplicate Address Detection issue:

dmesg | grep duplicate

If you see a line that matches something like the following, you have the IPv6DAD issue:

eth0: IPv6 duplicate address detected!

You can also issue the following command to see if you have any issues with your IPv6 links:

ip addr | grep tentative

If you see a line that matches something like the following, you most likely have the IPv6DAD issue:

inet6 fe80::a816:aeff:be53:d00d/64 scope link tentative

Fixing the Issue
---------------------

There are two potential fixes for the issue:

1. The bridge interface is in promiscuous mode.
2. Hairpin'ing is turned on for the virtual network device and is thus reflecting IPv6 Neighbor Advertisement messages back to the sender.

To solve #1, turn promiscuous mode for the bridge device off by doing the following:

ifconfig br100 -promisc

To solve #2, you have to turn off hairpin'ing mode for the virtual network interface that is associated with the VM that is not able to setup a valid IPv6 link. So, on the OpenStack Compute Node that is hosting the VM, assuming that the bridge device is named 'br100' and the virtual network interface is named 'vnet0', you would perform the following command to turn off hairpin'ing:

echo 0 > /sys/class/net/br100/brif/vnet0/hairpin_mode

If using OpenStack, to make the change more permanent, you can comment out the hairpin code in /usr/share/pyshared/nova/virt/libvirt/connection.py, starting at line 906. Specifically, comment out the "self._enable_hairpin(instance)" line.

Links
-------

* See Section '''14.2.2. Neighbor discovery''': http://tldp.org/HOWTO/html_single/Linux+IPv6-HOWTO/#EXAMPLES-TCPDUMP
* Hairpin'ing feature: http://www.networkworld.com/news/tech/2010/101223techupdate-vepa.html