ip link macvtap interface not processing specific ipv6 multicast traffic without promiscuous mode on

ip link macvtap interface not processing specific ipv6 multicast traffic without promiscuous mode on

[Stefan Bauer]

Hi,

Linux s1 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt7-1 (2015-03-01) x86_64
GNU/Linux
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 10)

The following interface (created by kvm/qemu virtualization)

7: macvtap0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast state UNKNOWN mode DEFAULT group default qlen 500
    link/ether 52:54:00:76:c1:f0 brd ff:ff:ff:ff:ff:ff

is not processing multicast traffic for ipv6 to specific addresses.
My virtual machines get router&prefix correct but can not resolve
addresses - hence are not able to communicate with other machines.

If i put the interface in promiscuous mode the neighbor tables of other
hosts are instantly filled. Without:
2a01:198:200:8350:98ec:1708:c82e:a4fb dev br-lan  INCOMPLETE With:
2a01:198:200:8350:98ec:1708:c82e:a4fb dev br-lan lladdr
52:54:00:8e:b9:eb REACHABLE

Any ideas on this?

Cheers,

Stefan 

Re: ip link macvtap interface not processing specific ipv6 multicast traffic without promiscuous mode on

[Stefan Bauer]

Seems to be a problem with the VM guests.

Works with linux guests out of the box.
Does only not work with win10 guests.

Sorry for the noise :/

Stefan

Re: ip link macvtap interface not processing specific ipv6 multicast traffic without promiscuous mode on

[Stefan Bauer]

I could narrow down the problem. Win7Prof and Windows 10 is having this
issue.

Win Client is member of the multicast group and is listening on
ff02::1:ffdf:fe88

Traffic from router -> client - captured on router:

07:41:23.104567 IP6 fe80::12fe:edff:fee6:cfa > ff02::1:ffdf:fe88: ICMP6,
neighbor solicitation, who has 2a01:198:200:8350:851e:21a7:28df:fe88,
length 32
07:41:24.099764 IP6 fe80::12fe:edff:fee6:cfa > ff02::1:ffdf:fe88: ICMP6,
neighbor solicitation, who has 2a01:198:200:8350:851e:21a7:28df:fe88,
length 32
07:41:25.099772 IP6 fe80::12fe:edff:fee6:cfa > ff02::1:ffdf:fe88: ICMP6,
neighbor solicitation, who has 2a01:198:200:8350:851e:21a7:28df:fe88,
length 32


Traffic from router to client - captured on KVM HOST

09:41:23.106444 IP6 fe80::12fe:edff:fee6:cfa > ff02::1:ffdf:fe88: ICMP6,
neighbor solicitation, who has 2a01:198:200:8350:851e:21a7:28df:fe88,
length 32
09:41:24.101647 IP6 fe80::12fe:edff:fee6:cfa > ff02::1:ffdf:fe88: ICMP6,
neighbor solicitation, who has 2a01:198:200:8350:851e:21a7:28df:fe88,
length 32
09:41:25.101718 IP6 fe80::12fe:edff:fee6:cfa > ff02::1:ffdf:fe88: ICMP6,
neighbor solicitation, who has 2a01:198:200:8350:851e:21a7:28df:fe88,
length 32

No traffic seen on KVM GUEST (win7 or win10) with wireshark

Any ideas to debug this further?

Cheers

Stefan

[SOLVED]Re: ip link macvtap interface not processing specific ipv6 multicast traffic without promiscuous mode on

[Stefan Bauer]

It was the privacy extension enabled on the windows hosts.

So it was sending out from addresses the KVM HOST is not member of the
multicast group.

disabled it with netsh interface ipv6 set privacy state=disabled

Stefan