Re: [libvirt] macvtap - no incoming ipv6 traffic processed on kvm host unless i start tcpdump on interface
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@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