multicast VPN breaks IPv6 Duplicate Address Detection
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
QEMU |
Won't Fix
|
Undecided
|
Unassigned | ||
Fedora |
Won't Fix
|
High
|
Bug Description
The multicast VPN facility in Qemu uses Multicast Loopback to make sure that other Qemu processes on the Host server receive the transmission. The side effect of this is that the process sending the packet also gets the packet back on its receive channel and currently this is not filtered but passed directly to the Virtual Machine.
You can see this effect by running tcpdump in the virtual machine. Every packet sent appears to be duplicated.
For IPv4 it doesn't appear to cause much of a problem, however with IPv6 the duplicate neighbor solicitation packet is precisely what the system uses to detect duplicate addresses. So IPv6 addresses fail to establish.
If you run 'ip addr' on a virtual Linux machine with IPv6 enabled you will see 'dadfailed' next to the link local address. 'ping6' will then not work.
Checked against 0.12.1.
Changed in fedora: | |
importance: | Unknown → High |
status: | Unknown → Won't Fix |
Description of problem:
Virtual NIC of type "mcast" receives copies of what it sent, resulting in many disastrous behaviors if you add one to a Linux software ethernet bridge.
Version-Release number of selected component (if applicable):
How reproducible:
Always.
Steps to Reproduce:
1. create a kvm/qemu guest with an mcast NIC as eth0
2. create a bridge br0 in the guest, enabling STP
3. add eth0 to br0 as its only slave
Actual results:
Once STP starts sending frames, the host starts reporting:
eth0: received packet with own address as source address
Expected results:
eth0 should not receive copies of what it sends.
Additional info:
This happens as above when the NIC goes into promiscuous mode. I have not bothered to verify whether it happens for multicast or broadcast traffic in non-promiscuous mode.
Things become more obvious and destructive if you add another slave to the bridge. Any incoming broadcast or multicast traffic from the other slave gets bridged into the mcast NIC, reflected back, and creating a kind of psuedo-loop. This confuses the user, upsets everyone on the other LAN, and also confuses the Linux software bridge as it starts falsely discovering all the reflected MACs as if they are reachable behind the mcast NIC.
With a manually created list of the MAC addresses actually behind the mcast LAN, one can create draconian ebtables filters to drop all reflected packets via a command like:
ebtables -t nat -A PREROUTING -i ethX --among-src-file ! /etc/mcast- mac-addrs -j dnat --dnat-target DROP
This will drop the bad frames before they confuse the bridging code, and you end up with a working bridged mcast network. This proves that the problem is reflected packets coming back to the sender via the mcast NIC.