Bug 1035253
| Summary: | IPv4/IPv6 multicasts are not forwarded via macvtap/macvlan bridge to VM (between VMs) | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Ziegler Karel <ziegleka> | ||||||
| Component: | kernel | Assignee: | Neil Horman <nhorman> | ||||||
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 20 | CC: | alan.christopher.jenkins, dopey, gansalmon, itamar, jbenc, jch, jonathan, kernel-maint, madhu.chinakonda, nhorman, pgampe.au, steved424, ziegleka | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2014-03-17 18:45:47 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Ziegler Karel
2013-11-27 11:42:19 UTC
It will be a few days before I get to reproducing this, but to give me something to think about, would I be correct in presuming that the neigh entries in the remote servers map the macvtap ip addresses on the KVM host to the bare metal mac address of the kvm host rather than the mac of the macvtap interface? I got a little lost in your query, so here I present the configuration of my test environment:
- host server:
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether e0:69:95:35:6a:12 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.251/23 scope global dynamic em1
valid_lft 6541sec preferred_lft 6541sec
inet6 fe80::e269:95ff:fe35:6a12/64 scope link
valid_lft forever preferred_lft forever
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 12:a4:8e:48:00:54 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
4: macvtap0@em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 500
link/ether 52:54:00:80:ac:26 brd ff:ff:ff:ff:ff:ff
inet6 fe80::5054:ff:fe80:ac26/64 scope link
valid_lft forever preferred_lft forever
5: macvtap1@em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 500
link/ether 52:54:00:ce:dc:87 brd ff:ff:ff:ff:ff:ff
inet6 fe80::5054:ff:fece:dc87/64 scope link
valid_lft forever preferred_lft forever
# iptables -n -L -v
Chain INPUT (policy ACCEPT 6 packets, 452 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 4 packets, 512 bytes)
pkts bytes target prot opt in out source destination
- guest server VM1:
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 52:54:00:80:ac:26 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.243/23 scope global dynamic eth0
valid_lft 6043sec preferred_lft 6043sec
inet6 fdee::192:168:1:243/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::5054:ff:fe80:ac26/64 scope link
valid_lft forever preferred_lft forever
# iptables -n -L -v
Chain INPUT (policy ACCEPT 3083 packets, 422K bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 115 packets, 15856 bytes)
pkts bytes target prot opt in out source destination
- guest server VM2:
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 52:54:00:ce:dc:87 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.241/23 scope global dynamic eth0
valid_lft 7004sec preferred_lft 7004sec
inet6 fdee::192:168:1:241/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::5054:ff:fece:dc87/64 scope link
valid_lft forever preferred_lft forever
# iptables -n -L -v
Chain INPUT (policy ACCEPT 2688 packets, 364K bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 114 packets, 17940 bytes)
pkts bytes target prot opt in out source destination
- LAN peer - deskop:
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:1c:c0:92:c0:93 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.111/23 brd 192.168.1.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fdee::192:168:1:111/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::21c:c0ff:fe92:c093/64 scope link
valid_lft forever preferred_lft forever
# iptables -n -L -v
Chain INPUT (policy ACCEPT 18 packets, 1612 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 10 packets, 1312 bytes)
pkts bytes target prot opt in out source destination
Created attachment 829945 [details]
guest VM1 libvirt xml
Created attachment 829946 [details]
guest VM2 libvirt xml
similar problem: http://bugs.centos.org/view.php?id=5860 - Steps to test: 1. ping6 from LAN peer to VM1 or VM2: # ping6 fdee::192:168:1:243 PING fdee::192:168:1:243(fdee::192:168:1:243) 56 data bytes From fdee::192:168:1:111 icmp_seq=1 Destination unreachable: Address unreachable From fdee::192:168:1:111 icmp_seq=2 Destination unreachable: Address unreachable From fdee::192:168:1:111 icmp_seq=3 Destination unreachable: Address unreachable ^C --- fdee::192:168:1:243 ping statistics --- 6 packets transmitted, 0 received, +3 errors, 100% packet loss, time 4999ms 2. ping6 from VM1 to LAN peer: # ping6 fdee::192:168:1:111 PING fdee::192:168:1:111(fdee::192:168:1:111) 56 data bytes 64 bytes from fdee::192:168:1:111: icmp_seq=1 ttl=64 time=1.07 ms 64 bytes from fdee::192:168:1:111: icmp_seq=2 ttl=64 time=0.464 ms 64 bytes from fdee::192:168:1:111: icmp_seq=3 ttl=64 time=0.533 ms 64 bytes from fdee::192:168:1:111: icmp_seq=4 ttl=64 time=0.510 ms ^C --- fdee::192:168:1:111 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3001ms rtt min/avg/max/mdev = 0.464/0.645/1.075/0.250 ms 3. ping6 from LAN peer to VM1: # ping6 fdee::192:168:1:243 PING fdee::192:168:1:243(fdee::192:168:1:243) 56 data bytes 64 bytes from fdee::192:168:1:243: icmp_seq=1 ttl=64 time=0.647 ms 64 bytes from fdee::192:168:1:243: icmp_seq=2 ttl=64 time=0.640 ms 64 bytes from fdee::192:168:1:243: icmp_seq=3 ttl=64 time=0.624 ms ^C --- fdee::192:168:1:243 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1998ms rtt min/avg/max/mdev = 0.624/0.637/0.647/0.009 ms 4. ping6 from VM1 to VM2: # ping6 fdee::192:168:1:241 PING fdee::192:168:1:241(fdee::192:168:1:241) 56 data bytes From fdee::192:168:1:243 icmp_seq=1 Destination unreachable: Address unreachable From fdee::192:168:1:243 icmp_seq=2 Destination unreachable: Address unreachable From fdee::192:168:1:243 icmp_seq=3 Destination unreachable: Address unreachable From fdee::192:168:1:243 icmp_seq=4 Destination unreachable: Address unreachable ^C --- fdee::192:168:1:241 ping statistics --- 5 packets transmitted, 0 received, +4 errors, 100% packet loss, time 4001ms 5. ping6 from VM2 to VM1: # ping6 fdee::192:168:1:243 PING fdee::192:168:1:243(fdee::192:168:1:243) 56 data bytes From fdee::192:168:1:241 icmp_seq=1 Destination unreachable: Address unreachable From fdee::192:168:1:241 icmp_seq=2 Destination unreachable: Address unreachable From fdee::192:168:1:241 icmp_seq=3 Destination unreachable: Address unreachable From fdee::192:168:1:241 icmp_seq=4 Destination unreachable: Address unreachable ^C --- fdee::192:168:1:243 ping statistics --- 4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 2999ms 6. add neighbors in VM1/VM2: [VM1]# ip -6 n replace fdee::192:168:1:241 lladdr 52:54:00:ce:dc:87 dev eth0 [VM2]# ip -6 n replace fdee::192:168:1:243 lladdr 52:54:00:80:ac:26 dev eth0 7. ping6 from VM1 to VM2: # ping6 fdee::192:168:1:241 PING fdee::192:168:1:241(fdee::192:168:1:241) 56 data bytes 64 bytes from fdee::192:168:1:241: icmp_seq=1 ttl=64 time=0.385 ms 64 bytes from fdee::192:168:1:241: icmp_seq=2 ttl=64 time=0.388 ms 64 bytes from fdee::192:168:1:241: icmp_seq=3 ttl=64 time=0.382 ms ^C --- fdee::192:168:1:241 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1999ms rtt min/avg/max/mdev = 0.382/0.385/0.388/0.002 ms 8. ping6 from VM2 to VM1: # ping6 fdee::192:168:1:243 PING fdee::192:168:1:243(fdee::192:168:1:243) 56 data bytes 64 bytes from fdee::192:168:1:243: icmp_seq=1 ttl=64 time=0.314 ms 64 bytes from fdee::192:168:1:243: icmp_seq=2 ttl=64 time=0.398 ms 64 bytes from fdee::192:168:1:243: icmp_seq=3 ttl=64 time=0.400 ms ^C --- fdee::192:168:1:243 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2000ms rtt min/avg/max/mdev = 0.314/0.370/0.400/0.045 ms (In reply to Ziegler Karel from comment #5) > similar problem: http://bugs.centos.org/view.php?id=5860 But I have not noticed this problem on my installation of CentOS 6.4. IPv4 multicasts are not forwarded via macvtap/macvlan bridge too: - host server: # omping 192.168.1.111 192.168.1.241 192.168.1.243 192.168.1.251 ... ^C 192.168.1.111 : unicast, xmt/rcv/%loss = 12/12/0%, min/avg/max/std-dev = 0.210/0.407/0.483/0.067 192.168.1.111 : multicast, xmt/rcv/%loss = 12/12/0%, min/avg/max/std-dev = 0.231/0.426/0.504/0.067 192.168.1.241 : response message never received (it is ok cause macvtap - host to guest communication is denied) 192.168.1.243 : response message never received (it is ok cause macvtap - host to guest communication is denied) - guest server VM1: # omping 192.168.1.111 192.168.1.241 192.168.1.243 192.168.1.251 ... 192.168.1.111 : unicast, xmt/rcv/%loss = 14/14/0%, min/avg/max/std-dev = 0.417/0.499/0.603/0.053 192.168.1.111 : multicast, xmt/rcv/%loss = 14/0/100%, min/avg/max/std-dev = 0.000/0.000/0.000/0.000 192.168.1.241 : unicast, xmt/rcv/%loss = 16/16/0%, min/avg/max/std-dev = 0.348/0.408/0.484/0.040 192.168.1.241 : multicast, xmt/rcv/%loss = 16/0/100%, min/avg/max/std-dev = 0.000/0.000/0.000/0.000 192.168.1.251 : response message never received (it is ok cause macvtap - guest to host communication is denied) - guest server VM2: # omping 192.168.1.111 192.168.1.241 192.168.1.243 192.168.1.251 ... ^C 192.168.1.111 : unicast, xmt/rcv/%loss = 18/18/0%, min/avg/max/std-dev = 0.472/0.531/0.641/0.043 192.168.1.111 : multicast, xmt/rcv/%loss = 18/0/100%, min/avg/max/std-dev = 0.000/0.000/0.000/0.000 192.168.1.243 : unicast, xmt/rcv/%loss = 16/16/0%, min/avg/max/std-dev = 0.361/0.438/0.552/0.044 192.168.1.243 : multicast, xmt/rcv/%loss = 16/0/100%, min/avg/max/std-dev = 0.000/0.000/0.000/0.000 192.168.1.251 : response message never received (it is ok cause macvtap - guest to host communication is denied) - LAN peer - deskop: # omping 192.168.1.111 192.168.1.241 192.168.1.243 192.168.1.251 ... ^C 192.168.1.241 : unicast, xmt/rcv/%loss = 18/18/0%, min/avg/max/std-dev = 0.526/0.574/0.712/0.062 192.168.1.241 : multicast, xmt/rcv/%loss = 18/18/0%, min/avg/max/std-dev = 0.532/0.581/0.721/0.065 192.168.1.243 : unicast, xmt/rcv/%loss = 15/15/0%, min/avg/max/std-dev = 0.508/0.524/0.545/0.011 192.168.1.243 : multicast, xmt/rcv/%loss = 15/15/0%, min/avg/max/std-dev = 0.515/0.616/0.791/0.121 192.168.1.251 : unicast, xmt/rcv/%loss = 13/13/0%, min/avg/max/std-dev = 0.254/0.477/0.511/0.067 192.168.1.251 : multicast, xmt/rcv/%loss = 13/13/0%, min/avg/max/std-dev = 0.260/0.487/0.520/0.069 - guest server VM1: # omping fdee::192:168:1:111 fdee::192:168:1:241 fdee::192:168:1:243 fdee::192:168:1:111 : waiting for response msg fdee::192:168:1:241 : waiting for response msg fdee::192:168:1:241 : joined (S,G) = (*, ff3e::4321:1234), pinging fdee::192:168:1:241 : unicast, seq=1, size=81 bytes, dist=0, time=0.396ms fdee::192:168:1:241 : unicast, seq=2, size=81 bytes, dist=0, time=0.451ms fdee::192:168:1:111 : waiting for response msg fdee::192:168:1:241 : unicast, seq=3, size=81 bytes, dist=0, time=0.364ms fdee::192:168:1:111 : joined (S,G) = (*, ff3e::4321:1234), pinging fdee::192:168:1:111 : unicast, seq=1, size=81 bytes, dist=0, time=0.597ms fdee::192:168:1:241 : unicast, seq=4, size=81 bytes, dist=0, time=0.493ms ... fdee::192:168:1:111 : unicast, seq=10, size=81 bytes, dist=0, time=0.449ms fdee::192:168:1:241 : unicast, seq=13, size=81 bytes, dist=0, time=0.382ms fdee::192:168:1:111 : unicast, seq=11, size=81 bytes, dist=0, time=0.453ms ^C fdee::192:168:1:111 : unicast, xmt/rcv/%loss = 11/11/0%, min/avg/max/std-dev = 0.433/0.510/0.608/0.064 fdee::192:168:1:111 : multicast, xmt/rcv/%loss = 11/0/100%, min/avg/max/std-dev = 0.000/0.000/0.000/0.000 fdee::192:168:1:241 : unicast, xmt/rcv/%loss = 13/13/0%, min/avg/max/std-dev = 0.315/0.396/0.493/0.049 fdee::192:168:1:241 : multicast, xmt/rcv/%loss = 13/0/100%, min/avg/max/std-dev = 0.000/0.000/0.000/0.000 - guest server VM2: # omping fdee::192:168:1:111 fdee::192:168:1:241 fdee::192:168:1:243 fdee::192:168:1:111 : waiting for response msg fdee::192:168:1:243 : waiting for response msg fdee::192:168:1:243 : joined (S,G) = (*, ff3e::4321:1234), pinging fdee::192:168:1:243 : unicast, seq=1, size=81 bytes, dist=0, time=0.298ms fdee::192:168:1:243 : unicast, seq=2, size=81 bytes, dist=0, time=0.449ms fdee::192:168:1:111 : waiting for response msg fdee::192:168:1:111 : joined (S,G) = (*, ff3e::4321:1234), pinging fdee::192:168:1:243 : unicast, seq=3, size=81 bytes, dist=0, time=0.434ms fdee::192:168:1:111 : unicast, seq=1, size=81 bytes, dist=0, time=0.584ms ... fdee::192:168:1:243 : unicast, seq=14, size=81 bytes, dist=0, time=0.416ms fdee::192:168:1:111 : unicast, seq=12, size=81 bytes, dist=0, time=0.484ms ^C fdee::192:168:1:111 : unicast, xmt/rcv/%loss = 14/14/0%, min/avg/max/std-dev = 0.397/0.493/0.593/0.064 fdee::192:168:1:111 : multicast, xmt/rcv/%loss = 14/0/100%, min/avg/max/std-dev = 0.000/0.000/0.000/0.000 fdee::192:168:1:243 : unicast, xmt/rcv/%loss = 14/14/0%, min/avg/max/std-dev = 0.298/0.416/0.511/0.059 fdee::192:168:1:243 : multicast, xmt/rcv/%loss = 14/0/100%, min/avg/max/std-dev = 0.000/0.000/0.000/0.000 - LAN peer - deskop: # omping fdee::192:168:1:111 fdee::192:168:1:241 fdee::192:168:1:243 fdee::192:168:1:241 : waiting for response msg fdee::192:168:1:243 : waiting for response msg fdee::192:168:1:241 : joined (S,G) = (*, ff3e::4321:1234), pinging fdee::192:168:1:243 : joined (S,G) = (*, ff3e::4321:1234), pinging fdee::192:168:1:241 : unicast, seq=1, size=81 bytes, dist=0, time=0.624ms fdee::192:168:1:241 : multicast, seq=1, size=81 bytes, dist=0, time=0.632ms fdee::192:168:1:243 : unicast, seq=1, size=81 bytes, dist=0, time=0.615ms fdee::192:168:1:243 : multicast, seq=1, size=81 bytes, dist=0, time=0.645ms ... fdee::192:168:1:241 : unicast, seq=13, size=81 bytes, dist=0, time=0.663ms fdee::192:168:1:241 : multicast, seq=13, size=81 bytes, dist=0, time=0.670ms fdee::192:168:1:243 : unicast, seq=13, size=81 bytes, dist=0, time=0.660ms fdee::192:168:1:243 : multicast, seq=13, size=81 bytes, dist=0, time=0.665ms ^C fdee::192:168:1:241 : unicast, xmt/rcv/%loss = 15/15/0%, min/avg/max/std-dev = 0.624/0.650/0.670/0.015 fdee::192:168:1:241 : multicast, xmt/rcv/%loss = 15/15/0%, min/avg/max/std-dev = 0.632/0.673/0.908/0.066 fdee::192:168:1:243 : unicast, xmt/rcv/%loss = 13/13/0%, min/avg/max/std-dev = 0.615/0.647/0.663/0.014 fdee::192:168:1:243 : multicast, xmt/rcv/%loss = 13/13/0%, min/avg/max/std-dev = 0.636/0.653/0.669/0.011 - I made the tests on CentOS 6.4 (2.6.32-358.23.2.el6.x86_64) and multicast forwarding works with this kernel version: ~ IPv4: - host server: # omping 192.168.1.111 192.168.1.248 192.168.1.251 192.168.1.254 192.168.1.111 : joined (S,G) = (*, 232.43.211.234), pinging 192.168.1.111 : unicast, seq=1, size=69 bytes, dist=0, time=0.240ms 192.168.1.111 : multicast, seq=1, size=69 bytes, dist=0, time=0.247ms 192.168.1.111 : unicast, seq=2, size=69 bytes, dist=0, time=0.337ms 192.168.1.111 : multicast, seq=2, size=69 bytes, dist=0, time=0.347ms 192.168.1.251 : waiting for response msg 192.168.1.254 : waiting for response msg ... 192.168.1.251 : waiting for response msg 192.168.1.254 : waiting for response msg 192.168.1.111 : unicast, seq=20, size=69 bytes, dist=0, time=0.406ms 192.168.1.111 : multicast, seq=20, size=69 bytes, dist=0, time=0.413ms 192.168.1.111 : unicast, seq=21, size=69 bytes, dist=0, time=0.392ms 192.168.1.111 : multicast, seq=21, size=69 bytes, dist=0, time=0.399ms ^C 192.168.1.111 : unicast, xmt/rcv/%loss = 21/21/0%, min/avg/max/std-dev = 0.240/0.351/0.406/0.039 192.168.1.111 : multicast, xmt/rcv/%loss = 21/21/0%, min/avg/max/std-dev = 0.247/0.359/0.416/0.040 192.168.1.251 : response message never received (it is ok cause macvtap - host to guest communication is denied) 192.168.1.254 : response message never received (it is ok cause macvtap - host to guest communication is denied) - guest server VM1: # omping 192.168.1.111 192.168.1.248 192.168.1.251 192.168.1.254 192.168.1.254 : joined (S,G) = (*, 232.43.211.234), pinging 192.168.1.111 : joined (S,G) = (*, 232.43.211.234), pinging 192.168.1.254 : unicast, seq=1, size=69 bytes, dist=0, time=0.276ms 192.168.1.254 : multicast, seq=1, size=69 bytes, dist=0, time=0.282ms 192.168.1.111 : unicast, seq=1, size=69 bytes, dist=0, time=0.516ms 192.168.1.111 : multicast, seq=1, size=69 bytes, dist=0, time=0.915ms 192.168.1.248 : waiting for response msg ... 192.168.1.248 : waiting for response msg 192.168.1.254 : unicast, seq=23, size=69 bytes, dist=0, time=0.223ms 192.168.1.254 : multicast, seq=23, size=69 bytes, dist=0, time=0.243ms 192.168.1.111 : unicast, seq=23, size=69 bytes, dist=0, time=0.581ms 192.168.1.111 : multicast, seq=23, size=69 bytes, dist=0, time=0.587ms ^C 192.168.1.111 : unicast, xmt/rcv/%loss = 23/23/0%, min/avg/max/std-dev = 0.386/0.565/0.855/0.107 192.168.1.111 : multicast, xmt/rcv/%loss = 23/23/0%, min/avg/max/std-dev = 0.388/0.631/0.953/0.155 192.168.1.248 : response message never received (it is ok cause macvtap - guest to host communication is denied) 192.168.1.254 : unicast, xmt/rcv/%loss = 23/23/0%, min/avg/max/std-dev = 0.205/0.301/0.937/0.148 192.168.1.254 : multicast, xmt/rcv/%loss = 23/23/0%, min/avg/max/std-dev = 0.212/0.371/0.975/0.198 - guest server VM2: # omping 192.168.1.111 192.168.1.248 192.168.1.251 192.168.1.254 192.168.1.251 : joined (S,G) = (*, 232.43.211.234), pinging 192.168.1.111 : joined (S,G) = (*, 232.43.211.234), pinging 192.168.1.251 : unicast, seq=1, size=69 bytes, dist=0, time=0.267ms 192.168.1.251 : multicast, seq=1, size=69 bytes, dist=0, time=0.351ms 192.168.1.248 : waiting for response msg 192.168.1.111 : unicast, seq=1, size=69 bytes, dist=0, time=0.367ms 192.168.1.111 : multicast, seq=1, size=69 bytes, dist=0, time=0.372ms ... 192.168.1.248 : waiting for response msg 192.168.1.251 : unicast, seq=24, size=69 bytes, dist=0, time=0.249ms 192.168.1.251 : multicast, seq=24, size=69 bytes, dist=0, time=0.337ms 192.168.1.111 : unicast, seq=23, size=69 bytes, dist=0, time=0.499ms 192.168.1.111 : multicast, seq=23, size=69 bytes, dist=0, time=0.504ms ^C 192.168.1.111 : unicast, xmt/rcv/%loss = 23/23/0%, min/avg/max/std-dev = 0.324/0.566/0.769/0.113 192.168.1.111 : multicast, xmt/rcv/%loss = 23/23/0%, min/avg/max/std-dev = 0.372/0.605/0.837/0.111 192.168.1.248 : response message never received (it is ok cause macvtap - guest to host communication is denied) 192.168.1.251 : unicast, xmt/rcv/%loss = 24/24/0%, min/avg/max/std-dev = 0.171/0.270/0.605/0.099 192.168.1.251 : multicast, xmt/rcv/%loss = 24/24/0%, min/avg/max/std-dev = 0.236/0.378/0.767/0.155 - LAN peer - deskop: # omping 192.168.1.111 192.168.1.248 192.168.1.251 192.168.1.254 192.168.1.248 : joined (S,G) = (*, 232.43.211.234), pinging 192.168.1.254 : joined (S,G) = (*, 232.43.211.234), pinging 192.168.1.251 : joined (S,G) = (*, 232.43.211.234), pinging 192.168.1.254 : unicast, seq=1, size=69 bytes, dist=0, time=0.543ms 192.168.1.251 : unicast, seq=1, size=69 bytes, dist=0, time=0.535ms 192.168.1.254 : multicast, seq=1, size=69 bytes, dist=0, time=0.548ms 192.168.1.251 : multicast, seq=1, size=69 bytes, dist=0, time=0.537ms 192.168.1.248 : unicast, seq=2, size=69 bytes, dist=0, time=0.464ms 192.168.1.248 : multicast, seq=2, size=69 bytes, dist=0, time=0.474ms ... 192.168.1.248 : unicast, seq=22, size=69 bytes, dist=0, time=0.264ms 192.168.1.248 : multicast, seq=22, size=69 bytes, dist=0, time=0.276ms 192.168.1.251 : unicast, seq=23, size=69 bytes, dist=0, time=0.740ms 192.168.1.251 : multicast, seq=23, size=69 bytes, dist=0, time=0.743ms 192.168.1.254 : unicast, seq=24, size=69 bytes, dist=0, time=0.530ms 192.168.1.254 : multicast, seq=24, size=69 bytes, dist=0, time=0.540ms ^C 192.168.1.248 : unicast, xmt/rcv/%loss = 22/22/0%, min/avg/max/std-dev = 0.212/0.285/0.464/0.085 192.168.1.248 : multicast, xmt/rcv/%loss = 22/22/0%, min/avg/max/std-dev = 0.219/0.294/0.474/0.086 192.168.1.251 : unicast, xmt/rcv/%loss = 23/23/0%, min/avg/max/std-dev = 0.448/0.671/0.928/0.137 192.168.1.251 : multicast, xmt/rcv/%loss = 23/23/0%, min/avg/max/std-dev = 0.450/0.696/0.984/0.144 192.168.1.254 : unicast, xmt/rcv/%loss = 24/24/0%, min/avg/max/std-dev = 0.420/0.565/0.855/0.120 192.168.1.254 : multicast, xmt/rcv/%loss = 24/24/0%, min/avg/max/std-dev = 0.423/0.581/0.864/0.120 ~ IPv6: - host server: # omping fdee::192:168:1:111 fdee::192:168:1:248 fdee::192:168:1:251 fdee::192:168:1:254 fdee::192:168:1:111 : joined (S,G) = (*, ff3e::4321:1234), pinging fdee::192:168:1:111 : unicast, seq=1, size=81 bytes, dist=0, time=0.218ms fdee::192:168:1:111 : multicast, seq=1, size=81 bytes, dist=0, time=0.225ms fdee::192:168:1:251 : waiting for response msg fdee::192:168:1:254 : waiting for response msg ... fdee::192:168:1:251 : waiting for response msg fdee::192:168:1:254 : waiting for response msg fdee::192:168:1:111 : unicast, seq=20, size=81 bytes, dist=0, time=0.402ms fdee::192:168:1:111 : multicast, seq=20, size=81 bytes, dist=0, time=0.410ms ^C fdee::192:168:1:111 : unicast, xmt/rcv/%loss = 20/20/0%, min/avg/max/std-dev = 0.218/0.376/0.407/0.043 fdee::192:168:1:111 : multicast, xmt/rcv/%loss = 20/20/0%, min/avg/max/std-dev = 0.225/0.385/0.419/0.043 fdee::192:168:1:251 : response message never received (it is ok cause macvtap - host to guest communication is denied) fdee::192:168:1:254 : response message never received (it is ok cause macvtap - host to guest communication is denied) - guest server VM1: # omping fdee::192:168:1:111 fdee::192:168:1:248 fdee::192:168:1:251 fdee::192:168:1:254 fdee::192:168:1:111 : joined (S,G) = (*, ff3e::4321:1234), pinging fdee::192:168:1:254 : joined (S,G) = (*, ff3e::4321:1234), pinging fdee::192:168:1:254 : unicast, seq=1, size=81 bytes, dist=0, time=0.194ms fdee::192:168:1:254 : multicast, seq=1, size=81 bytes, dist=0, time=0.202ms fdee::192:168:1:111 : unicast, seq=1, size=81 bytes, dist=0, time=0.782ms fdee::192:168:1:111 : multicast, seq=1, size=81 bytes, dist=0, time=0.787ms fdee::192:168:1:248 : waiting for response msg ... fdee::192:168:1:248 : waiting for response msg fdee::192:168:1:254 : unicast, seq=22, size=81 bytes, dist=0, time=0.249ms fdee::192:168:1:254 : multicast, seq=22, size=81 bytes, dist=0, time=0.257ms fdee::192:168:1:111 : unicast, seq=22, size=81 bytes, dist=0, time=0.506ms fdee::192:168:1:111 : multicast, seq=22, size=81 bytes, dist=0, time=0.512ms ^C fdee::192:168:1:111 : unicast, xmt/rcv/%loss = 22/22/0%, min/avg/max/std-dev = 0.366/0.584/0.878/0.128 fdee::192:168:1:111 : multicast, xmt/rcv/%loss = 22/22/0%, min/avg/max/std-dev = 0.377/0.634/0.975/0.163 fdee::192:168:1:248 : response message never received (it is ok cause macvtap - guest to host communication is denied) fdee::192:168:1:254 : unicast, xmt/rcv/%loss = 22/22/0%, min/avg/max/std-dev = 0.185/0.316/0.960/0.157 fdee::192:168:1:254 : multicast, xmt/rcv/%loss = 22/22/0%, min/avg/max/std-dev = 0.191/0.371/0.995/0.211 - guest server VM2: # omping fdee::192:168:1:111 fdee::192:168:1:248 fdee::192:168:1:251 fdee::192:168:1:254 fdee::192:168:1:111 : joined (S,G) = (*, ff3e::4321:1234), pinging fdee::192:168:1:251 : joined (S,G) = (*, ff3e::4321:1234), pinging fdee::192:168:1:111 : unicast, seq=1, size=81 bytes, dist=0, time=0.473ms fdee::192:168:1:111 : multicast, seq=1, size=81 bytes, dist=0, time=0.579ms fdee::192:168:1:248 : waiting for response msg fdee::192:168:1:251 : unicast, seq=1, size=81 bytes, dist=0, time=0.284ms fdee::192:168:1:251 : multicast, seq=1, size=81 bytes, dist=0, time=0.467ms ... fdee::192:168:1:251 : unicast, seq=21, size=81 bytes, dist=0, time=0.455ms fdee::192:168:1:251 : multicast, seq=21, size=81 bytes, dist=0, time=0.457ms fdee::192:168:1:248 : waiting for response msg fdee::192:168:1:111 : unicast, seq=24, size=81 bytes, dist=0, time=0.578ms fdee::192:168:1:111 : multicast, seq=24, size=81 bytes, dist=0, time=0.592ms ^C fdee::192:168:1:111 : unicast, xmt/rcv/%loss = 24/24/0%, min/avg/max/std-dev = 0.439/0.606/0.880/0.116 fdee::192:168:1:111 : multicast, xmt/rcv/%loss = 24/24/0%, min/avg/max/std-dev = 0.504/0.687/0.902/0.113 fdee::192:168:1:248 : response message never received (it is ok cause macvtap - guest to host communication is denied) fdee::192:168:1:251 : unicast, xmt/rcv/%loss = 21/21/0%, min/avg/max/std-dev = 0.203/0.278/0.455/0.063 fdee::192:168:1:251 : multicast, xmt/rcv/%loss = 21/21/0%, min/avg/max/std-dev = 0.270/0.354/0.630/0.100 - LAN peer - deskop: omping fdee::192:168:1:111 fdee::192:168:1:248 fdee::192:168:1:251 fdee::192:168:1:254 fdee::192:168:1:251 : joined (S,G) = (*, ff3e::4321:1234), pinging fdee::192:168:1:254 : joined (S,G) = (*, ff3e::4321:1234), pinging fdee::192:168:1:248 : joined (S,G) = (*, ff3e::4321:1234), pinging fdee::192:168:1:254 : unicast, seq=1, size=81 bytes, dist=0, time=0.479ms fdee::192:168:1:254 : multicast, seq=1, size=81 bytes, dist=0, time=0.484ms fdee::192:168:1:251 : unicast, seq=1, size=81 bytes, dist=0, time=0.510ms fdee::192:168:1:251 : multicast, seq=1, size=81 bytes, dist=0, time=0.512ms fdee::192:168:1:248 : unicast, seq=1, size=81 bytes, dist=0, time=0.219ms fdee::192:168:1:248 : multicast, seq=1, size=81 bytes, dist=0, time=0.221ms ... fdee::192:168:1:248 : unicast, seq=18, size=81 bytes, dist=0, time=0.253ms fdee::192:168:1:248 : multicast, seq=18, size=81 bytes, dist=0, time=0.259ms fdee::192:168:1:251 : unicast, seq=21, size=81 bytes, dist=0, time=4.628ms fdee::192:168:1:251 : multicast, seq=21, size=81 bytes, dist=0, time=5.414ms fdee::192:168:1:254 : unicast, seq=21, size=81 bytes, dist=0, time=5.972ms fdee::192:168:1:254 : multicast, seq=21, size=81 bytes, dist=0, time=5.977ms ^C fdee::192:168:1:248 : unicast, xmt/rcv/%loss = 18/18/0%, min/avg/max/std-dev = 0.219/0.388/0.499/0.113 fdee::192:168:1:248 : multicast, xmt/rcv/%loss = 18/18/0%, min/avg/max/std-dev = 0.221/0.395/0.506/0.114 fdee::192:168:1:251 : unicast, xmt/rcv/%loss = 21/21/0%, min/avg/max/std-dev = 0.452/0.897/4.628/0.862 fdee::192:168:1:251 : multicast, xmt/rcv/%loss = 21/21/0%, min/avg/max/std-dev = 0.512/0.950/5.414/1.028 fdee::192:168:1:254 : unicast, xmt/rcv/%loss = 23/23/0%, min/avg/max/std-dev = 0.442/0.891/5.972/1.120 fdee::192:168:1:254 : multicast, xmt/rcv/%loss = 23/23/0%, min/avg/max/std-dev = 0.460/0.916/5.977/1.115 I just noticed that your initial description indicates that its multicast addresses that are not getting forwarded, but your reproducer specifically uses unicast addresses to illustrate that nothing is getting forwarded. But later on it appears as though you have unicast ipv6 traffic working. Can you clarify what the problem you're seeing exactly is? I also note in your omping reports that: a) Multicast traffic seems to pass at times (fdee::192:168:1:251 : multicast, seq=21, size=81 bytes, dist=0, time=0.457ms) b) When multicast traffic appears to not get received we see this error (192.168.1.248 : response message never received (it is ok cause macvtap - guest to host communication is denied)) This all amounts in my mind to this being a configuration error rather than a bug, especially since I just set this up here and it all seems to work fine for me. Hi, can we meet on IRC? I agree, I have sent a lot of information and someone could lost in them. I'm on #kernel on LinuxNet, and #fedora-devel on freenode, but I don't really have time for a long drawn out conversation on IRC at the moment. I'm not lost in your description, I'm just pointing out that your summary doesn't match your reproducer, and your reproducer works fine for me, and want some clarification. If you could elaborate on it here please I would appreciate it. *********** MASS BUG UPDATE ************** This bug has been in a needinfo state for several weeks and is being closed with insufficient data due to inactivity. If this is still an issue with Fedora 20, please feel free to reopen the bug and provide the additional information requested. Justin, the reproducer uses IPv6, and IPv6 neigbour discovery relies on multicast (unlike ARP which uses broadcasts). libvirt defaults to trustGuestRxFilters=no. This is documented to ignore the guest "interface mac address and receive filters". This is regrettably obscure; the commit message is slightly clearer: "interface's mac address and unicast/multicast filters". In other words, we should *expect* macvlans on libvirt to break IPv6 by default. Clearly it's a bug that this is not explicitly documented. I think that should be sufficient information to re-open this bug. I can help try and work out a minimal reproduction case too, if you like. When I tried to demonstrate this, I found one exception, and it may be the reason you couldn't see the issue. If you try to ping the default link-local address of a macvtap VM, it *will* work. This is because the macvtap interface on the *host*, automatically configures the same link-local address bsaed on the mac address, and therefore the host joins the necessary multicast group on that interface. However any other IP addresses will use a different multicast group for neighbour discovery, and so it won't work. Other people have observed this issue with libvirt: "I find that host cannot ping6 each VM." "I faced the same issue with macvtap. I found a way to fix it but I don't know how to automate it inside virsh. sudo ip link set dev macvtap0 allmulticast on" http://superuser.com/questions/944678/how-to-configure-macvtap-to-let-it-pass-multicast-packet-correctly IMO the more natural model would be to allow multicast by default. macvlan allows MAC spoofing anyway, as well as sending to multicast addresses. Blocking multicast reception (but not transmission) on a network you think you're directly connected to is an unpleasant surprise. It leads to long painful & confusing debugging sessions like this one :). Thanks for comment 15. That helped me figure out the problem and figured out how to configure the interface with trustGuestRxFilters=yes in the libvirt domain. This is properly evil, but if you don't want to enable all multicast, this seems to work on the host: bridge fdb add 33:33:ff:<lower 24 bits of v6 address> dev <macvtap if> (enables reception of the just the solicited node multicast group for a particular v6 address) This bug was closed with insufficient data, but I can't immediately see what information was needed.
As I understand it, the problem is that IPv6 doesn't work with mcvtap because IPv6 multicast is disabled by default. In the Libvirt xml, if one has
<interface type='direct'>
IPv6 doesn't work unless you set the macvtap device in the host to promiscuous (actually, it works for a little while, a few seconds to perhaps as long as an hour or two), but
if you have:
<interface type='direct' trustGuestRxFilters='yes'>
This, surely, should be the default. What need to be done to reopen this bug to make that happen?
John, I admit I don't remember this bug anymore (I see that I added myself to CC, which means I had to be involved somehow but I don't remember). Quickly scanning through the comments, it appears to be a libvirt issue and not a kernel issue? Or is it the macvtap kernel driver that is broken for IPv6 multicast? In either case, you'll probably have more luck raising the bug upstream (libvirt or kernel netdev, depending on where the bug is). I doubt anyone working on Fedora has capacity to drive this upstream. I remember After this issue, I did some research and this is documented in the libvirt doc: https://libvirt.org/formatdomain.html#elementsNICS It's not clear in the doc what the security reasons are but I found this from IBMs documentation: https://www.ibm.com/support/knowledgecenter/en/linuxonibm/com.ibm.linux.z.ldva/ldva_t_configuringMacVTap.html ```To enable multicasting, you need set the interface trustGuestRxFilters attribute to yes. This has security implications, because it allows the virtual server to change its MAC address and thus to receive all frames delivered to this address.``` So I concur with Jiri, this does appear to be an upstream "issue" and more specifically is disabled by default for a reason. (In reply to Andy Wang from comment #21) > So I concur with Jiri, this does appear to be an upstream "issue" and more > specifically is disabled by default for a reason. On the other hand, a solution that makes IPv6 non-working in the name of security is a wrong solution. Upstream needs to come up with something that is *both* secure and working. |