Bug 688307

Description of problem:

With IPv6 RADVD is launched when the network is initially created. That means it picks up the original address of the bridge without any interfaces enslaved to it. With the RADVD config as it is, it sends out this address as the address of the router in the 'source link-address' option of the Router Advertisement.

However when a guest is launched, the MAC address of the bridge changes to the  enslaved interface.

However the guest uses the address in the Router Advertisement as the MAC address for its default route.

The result is that initial communication over IPv6 can take 9 pings to establish while Neighbor Discovery sorts the problem out.

Version-Release number of selected component (if applicable): 0.8.8


How reproducible:


Steps to Reproduce:
1. Create a libvirt network with an IPv6 allocated prefix.
2. Launch a guest on that network and log in via the console or IPv4.
3. Check 'ip neigh show' and note the MAC address. compare to the bridge address.
3. Run ip -6 route and note the link local address.
4. Run ping6 -I eth0 <link local address of bridge>
  
Actual results:

Nine pings are dropped before communication is established. tcpdumps show that neighbor discovery is initially being sent to the wrong mac address.

'ip neigh show' on the guest also shows the wrong mac address for the default route.


Expected results:

pings to the link local address should work straight away.


Additional info:

The solution is to add 'AdvSourceLLAddress off;' to the interface section of the generated radvd configuration. Then neighbor discovery takes the strain.