[libvirt] macvtap - no incoming ipv6 traffic processed on kvm host unless i start tcpdump on interface

[Michal Privoznik]

On 08.04.2015 14:13, Stefan Bauer wrote:
> Dear folks,
> 
> I'm using for the first time macvtap interface for my virtual machines in bridged mode.
> 
> VM -> HOST -> Router -> INTERNET
> 
> This works fine for ipv4 connectivity.
> 
> For ipv6 my virtual machines receive appropriate v6 address from radvd but are not able to receive answer packages from outside (ping -t -6 google.de was started inside VM).
> 
> I see the ping request/response on my router:
> 
> 14:10:52.147834 IP6 2a01:198:200:8350:dc8b:cd82:144e:14eb > 2a00:1450:4001:806::1018: ICMP6, echo request, seq 108, length 40
> 14:10:52.182073 IP6 2a00:1450:4001:806::1018 > 2a01:198:200:8350:dc8b:cd82:144e:14eb: ICMP6, echo reply, seq 108, length 40
> 14:10:55.179874 IP6 2a01:198:200:350::2 > 2a00:1450:4001:806::1018: ICMP6, destination unreachable, unreachable address 2a01:198:200:8350:dc8b:cd82:144e:14eb, length 88
> 
> 
> But i do not receive the reply on the VM.
> 
> However on the KVM host - when i start a tcpdump on the macvtap interface with
> 
> root at s1:~# tcpdump -ni macvtap0 ip6
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on macvtap0, link-type EN10MB (Ethernet), capture size 262144 bytes
> 14:12:37.134516 IP6 2a01:198:200:8350:dc8b:cd82:144e:14eb > 2a00:1450:4001:806::1018: ICMP6, echo request, seq 129, length 40
> 14:12:37.188529 IP6 fe80::12fe:edff:fee6:cfa > ff02::1:ff4e:14eb: ICMP6, neighbor solicitation, who has 2a01:198:200:8350:dc8b:cd82:144e:14eb, length 32
> 14:12:37.189040 IP6 2a01:198:200:8350:dc8b:cd82:144e:14eb > fe80::12fe:edff:fee6:cfa: ICMP6, neighbor advertisement, tgt is 2a01:198:200:8350:dc8b:cd82:144e:14eb, length 32
> 14:12:37.189202 IP6 2a00:1450:4001:806::1018 > 2a01:198:200:8350:dc8b:cd82:144e:14eb: ICMP6, echo reply, seq 129, length 40
> 
> 
> packages starting to get processed and VM receives replies.
> Any idea what is happening here?
> 

I mildly recalls seeing a bug like this. The problem was in intel's
kernel driver. A NIC by defaul checks incoming packets whether they
match NIC's MAC. So if a TAP device was created over a NIC, it had to be
put into promisc mode (automatically done by the driver) to allow
different MACs and the check was done in kernel then. But since this
generates too much interrupts, NICs HW was extended and it can be
programmed with multiple MACs to let through. However, there was a bug
which I recall of, that intel driver was not always putting the TAP MAC
into the NIC HW correctly. Obviously, the bug was not visible if the NIC
was put into promisc mode. And this may be what you are seeing. Let me
see if I can find the bug.

Michal