Re: [libvirt-users] What's the best way to make use of VLAN interfaces with VMs?

Laine I made the change and I can now ping across both bridges: br1 (192.168.0.0/24) and br1600 (192.168.1.0/24): br1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500         inet 192.168.0.110  netmask 255.255.255.0  broadcast 192.168.0.255         inet6 fe80::1e98:ecff:fe1b:276d  prefixlen 64  scopeid 0x20<link>         ether 1c:98:ec:1b:27:6d  txqueuelen 1000  (Ethernet)         RX packets 21608  bytes 10289553 (9.8 MiB)         RX errors 0  dropped 0  overruns 0  frame 0         TX packets 1372  bytes 131012 (127.9 KiB)         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0 br1600: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500         inet 192.168.1.110  netmask 255.255.255.0  broadcast 192.168.1.255         inet6 fe80::1e98:ecff:fe1b:276d  prefixlen 64  scopeid 0x20<link>         ether 1c:98:ec:1b:27:6d  txqueuelen 1000  (Ethernet)         RX packets 3429  bytes 173404 (169.3 KiB)         RX errors 0  dropped 0  overruns 0  frame 0         TX packets 112  bytes 9490 (9.2 KiB)         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0 // ping to another host with the same bridge br1 defined on 192.168.0.120 [root@clusterdev01 ~]# ping 192.168.0.120 PING 192.168.0.120 (192.168.0.120) 56(84) bytes of data. 64 bytes from 192.168.0.120: icmp_seq=1 ttl=64 time=0.481 ms 64 bytes from 192.168.0.120: icmp_seq=2 ttl=64 time=0.244 ms 64 bytes from 192.168.0.120: icmp_seq=3 ttl=64 time=0.242 ms 64 bytes from 192.168.0.120: icmp_seq=4 ttl=64 time=0.244 ms 64 bytes from 192.168.0.120: icmp_seq=5 ttl=64 time=0.237 ms ^C // ping to another host with the same bridge br1600 defined on 192.168.1.120 [root@clusterdev01 ~]# ping 192.168.1.120 PING 192.168.1.120 (192.168.1.120) 56(84) bytes of data. 64 bytes from 192.168.1.120: icmp_seq=1 ttl=64 time=0.316 ms 64 bytes from 192.168.1.120: icmp_seq=2 ttl=64 time=0.245 ms 64 bytes from 192.168.1.120: icmp_seq=3 ttl=64 time=0.176 ms 64 bytes from 192.168.1.120: icmp_seq=4 ttl=64 time=0.213 ms ^C However, for some reason, multicast has stopped working across the bridge interface, when it was working in the previous configuration (with br1 and br1.600). I test multicast using a multicast test app, binding the receiver to br1 on one host (192.168.0.120) and then binding the sender on br1 on another host (192.168.0.110). I also start an instance of tshark on each host to check which packets are being sent across. The multicast packets are seen by tshark to be crossing the bridge but for some reason the receiver app does not receive them. The bridges also have the multicast_querier and multicast_snooping flags enabled (e.g. for br1 on both hosts): [root@clusterdev01 ~]# cat /sys/class/net/br1/bridge/multicast_querier 1 [root@clusterdev01 ~]# cat /sys/class/net/br1/bridge/multicast_snooping 1 [root@clusterdev02 ~]# cat /sys/class/net/br1/bridge/multicast_querier 1 [root@clusterdev02 ~]# cat /sys/class/net/br1/bridge/multicast_snooping 1 // 1. start multicast test app sender and send packet across br1 (the multicast address of 239.11.12.13 is fixed for both apps, as well as multicast port 5555) [root@clusterdev01 bridge-multicast-test]# ./start-ipv4-mcast-sender.sh 192.168.0.110 Socket #1=0.0.0.0/0.0.0.0:5555, ttl=32, bind interface=/192.168.0.110 // 2. tshark on the sending host after sending packet [root@clusterdev01 ~]# tshark -i br1 -f "igmp or host 239.11.12.13" Running as user "root" and group "root". This could be dangerous. Capturing on 'br1'     1 0.000000000 192.168.0.110 → 239.11.12.13 UDP 52 5555 → 5555 Len=10     2 55.389831698      0.0.0.0 → 224.0.0.1    IGMPv2 60 Membership Query, general     3 60.194658894 192.168.0.115 → 224.0.0.251  IGMPv2 46 Membership Report group 224.0.0.251 // 3. tshark on the receiving host across bridge br1 [root@clusterdev02 ~]# tshark -i br1 -f "igmp or host 239.11.12.13" Running as user "root" and group "root". This could be dangerous. Capturing on 'br1'     1 0.000000000 192.168.0.120 → 224.0.0.22   IGMPv3 54 Membership Report / Join group 239.11.12.13 for any sources     2 0.902032534 192.168.0.120 → 224.0.0.22   IGMPv3 54 Membership Report / Join group 239.11.12.13 for any sources     3 41.448921858 192.168.0.110 → 239.11.12.13 UDP 60 5555 → 5555 Len=10 // 4. previously started multicast test app receiver and no packet received [root@clusterdev02 bridge-multicast-test]# ./start-ipv4-mcast-receiver.sh 192.168.0.120 Socket=0.0.0.0/0.0.0.0:5555, bind interface=/192.168.0.120 // NO PACKET APPEARS HERE :-( It's puzzling that the packet is seen to arrive on clusterdev02 but is not received by the test app. It's also odd to see IGMPv3 messages on the receiver and IGMPv2 messages on the sender. Investigating .... Richard On 11/29/19 12:15 PM, Richard Achmatowicz wrote: