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
--
libvir-list mailing list
libvir-list@redhat.com
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
Further investigation shows that it is working as expected on linux
guests.
Only my win10 guests trigger that problem.
Will dig deeper...
Stefan
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, 2015-04-09 at 10:47 +0200, Michal Privoznik wrote:
Ah, so that's not the bug then. Have you perhaps changed the vNIC MAC
inside the guest after it was started? Even though libvirt will nowadays
adapt to such change, older version of libvirt haven't this implemented
causing guest
On Thu, 2015-04-09 at 10:12 +0200, Michal Privoznik wrote:
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
v4 is using arp to broadcast address (ff:ff:ff:ff:ff:ff) - that works
with macvtap without having card in promiscious mode (ip li is not
showing PROMISC flag).
v6 is using multicast to solicited node-address - that is NOT working
without enabling manually promiscious mode.
Stefan
--
libvir-list
On Thu, 2015-04-09 at 11:03 +0200, Michal Privoznik wrote:
Maybe a firewall problem? Anything interesting in iptables/ebtables output?
I have completely disabled v6 firewall for testing but enabling
promiscious mode should not be able to bypass FW rules.
Stefan
--
libvir-list mailing list
On Thu, 2015-04-09 at 10:12 +0200, Michal Privoznik wrote:
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
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
On Wed, 2015-04-08 at 14:32 +0200, Martin Kletzander wrote:
I'm guessing the promiscuous modes plays its part in this field. You
can try setting the interface to promisc mode manually using 'ip l set
$dev promisc on' and see whether that helps without starting tcpdump.
Also check sysctl -a |
10 matches
Mail list logo
