Description of problem: External igmp queries not arriving to the vm. There is no issue with igmp queries generated internally if configured, but if the querier is external, those messages are dropped. In my configuration I have configured a vlan provider network for multicast traffic and configured a igmp querier in the switch. I tried adding igmp and udp to the security group and also disabling port security in the ports, but it didnt work Using ovs-tcpdump i can see those packets in br-int, but they are dropped there. Inside the vm, if I open a tcpdump I do not see those packets. 08:40:15.047132 e4:fc:82:34:4c:43 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 114, p 0, ethertype IPv4, 10.10.114.253 > 224.0.0.1: igmp query v3 [max resp time 4.0s] 08:40:20.049363 e4:fc:82:34:4c:43 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 64: vlan 114, p 0, ethertype IPv4, 10.10.114.253 > 224.0.0.1: igmp query v3 [max resp time 4.0s] I can see that those packets are sent to the controller and then dropped cookie=0x3600428e duration=5030.108s table=0 n_packets=1029 n_bytes=65712 idle_age=1 priority=150 in_port=5 dl_vlan=114 actions=strip_vlan load:0xb->NXM_NX_REG13[] load:0x7->NXM_NX_REG11[] load:0x3->NXM_NX_REG12[] load:0x3->OXM_OF_METADATA[] load:0x1->NXM_NX_REG14[] resubmit( 8) cookie=0xee32c2b5 duration=5030.110s table=8 n_packets=1029 n_bytes=65712 idle_age=1 priority=50 reg14=0x1 metadata=0x3 actions=resubmit( 9) cookie=0x7f6ac8bc duration=5030.127s table=9 n_packets=1131 n_bytes=72006 idle_age=1 priority=0 metadata=0x3 actions=resubmit( 10) cookie=0x4e134d4c duration=5030.164s table=10 n_packets=1131 n_bytes=72006 idle_age=1 priority=0 metadata=0x3 actions=resubmit( 11) cookie=0x7881ca36 duration=5030.128s table=11 n_packets=1131 n_bytes=72006 idle_age=1 priority=0 metadata=0x3 actions=resubmit( 12) cookie=0xb39b18e9 duration=5030.155s table=13 n_packets=1131 n_bytes=72006 idle_age=1 priority=0 metadata=0x3 actions=resubmit( 14) cookie=0x7724a6fa duration=5030.163s table=14 n_packets=1131 n_bytes=72006 idle_age=1 priority=0 metadata=0x3 actions=resubmit( 15) cookie=0x45eb193d duration=5030.128s table=15 n_packets=1131 n_bytes=72006 idle_age=1 priority=0 metadata=0x3 actions=resubmit( 16) cookie=0x2c209b39 duration=5030.111s table=16 n_packets=1131 n_bytes=72006 idle_age=1 priority=0 metadata=0x3 actions=resubmit( 17) cookie=0x5476787c duration=5030.163s table=17 n_packets=1131 n_bytes=72006 idle_age=1 priority=0 metadata=0x3 actions=resubmit( 18) cookie=0x94e2ff29 duration=5030.167s table=18 n_packets=1131 n_bytes=72006 idle_age=1 priority=0 metadata=0x3 actions=resubmit( 19) cookie=0x4065fbb6 duration=5030.124s table=19 n_packets=1131 n_bytes=72006 idle_age=1 priority=0 metadata=0x3 actions=resubmit( 20) cookie=0xae4e8c6c duration=5030.163s table=20 n_packets=1131 n_bytes=72006 idle_age=1 priority=0 metadata=0x3 actions=resubmit( 21) cookie=0x16d398d3 duration=5030.125s table=21 n_packets=1131 n_bytes=72006 idle_age=1 priority=0 metadata=0x3 actions=resubmit( 22) cookie=0x5dbf94c8 duration=5030.166s table=22 n_packets=1131 n_bytes=72006 idle_age=1 priority=0 metadata=0x3 actions=resubmit( 23) cookie=0x6d64646b duration=5030.111s table=23 n_packets=1029 n_bytes=65712 idle_age=1 priority=100 reg14=0x1 metadata=0x3 actions=resubmit( 24) cookie=0xded3080e duration=5030.116s table=24 n_packets=1128 n_bytes=71880 idle_age=1 priority=0 metadata=0x3 actions=resubmit( 25) cookie=0x18a7b75e duration=5030.112s table=25 n_packets=1128 n_bytes=71880 idle_age=1 priority=0 metadata=0x3 actions=resubmit( 26) cookie=0x5875d83c duration=5030.114s table=26 n_packets=1128 n_bytes=71880 idle_age=1 priority=0 metadata=0x3 actions=resubmit( 27) cookie=0xca9b7f19 duration=5030.167s table=27 n_packets=1128 n_bytes=71880 idle_age=1 priority=0 metadata=0x3 actions=resubmit( 28) cookie=0x9b75cdfb duration=5030.113s table=28 n_packets=1128 n_bytes=71880 idle_age=1 priority=0 metadata=0x3 actions=resubmit( 29) cookie=0xe685d82c duration=5030.112s table=29 n_packets=1000 n_bytes=63930 idle_age=1 priority=100 igmp metadata=0x3 actions=clone(load:0x8003->NXM_NX_REG15[] resubmit( 32)) controller(userdata=00.00.00.10.00.00.00.00) cookie=0x75d873ea duration=5030.167s table=33 n_packets=1023 n_bytes=66000 idle_age=1 hard_age=4003 priority=100 reg15=0x8003 metadata=0x3 actions=load:0xb->NXM_NX_REG13[] load:0x1->NXM_NX_REG15[] resubmit( 34) load:0x8003->NXM_NX_REG15[] cookie=0x0 duration=5030.109s table=34 n_packets=1029 n_bytes=65712 idle_age=1 priority=100 reg10=0/0x1 reg14=0x1 reg15=0x1 metadata=0x3 actions=drop Version-Release number of selected component (if applicable): RHOS-16.1-RHEL-8-20210216.n.1 ovn2.13-20.12.0-17.el8fdp.x86_64 How reproducible: 1. Deploy osp 16.1 with igmp snooping enabled: NeutronEnableIgmpSnooping: true 2. Configure a igmp querier in the switch for the vlan being used 3. Create a vlan network 4. Spawn a vm 5. Execute tcpdump in the vm and ovs-tcpdump in br-int 5. Igmp queries are present in br-int but not in the vm Actual results: vms should received igmp queries generated by a external switch or router Expected results: vms do not receive igmp queries generated by a external switch or router Additional info: i will upload sos report
Somehow this bz is related with https://bugzilla.redhat.com/show_bug.cgi?id=1933734 When I enable options:mcast_flood_reports=true for all the ports, I start receiving igmp queries from external querier in vms.
Hi, I've spoke with Dumitru from the core OVN team and according to him this is a known problem in OVN. The problem is that the ovn-controller will consume the IGMP queries and won't send it to the LSP ports. He said it's fixable but as a workaround he suggested (just like you suggested on comment #2) to set the "mcast_flood_reports" to True in the LSP ports; that way ovn-controller will also clone the IGMP queries and send it to the ports. I am moving this bug to core OVN but I will keep https://bugzilla.redhat.com/show_bug.cgi?id=1933734 in OSP so we can work on the workaround (enabling "mcast_flood_reports"). Cheers, Lucas
Bumping priority, this breaks IGMP with external queriers: https://github.com/ovn-org/ovn/issues/126
Posted patches to implement the RFC compliant solution: https://patchwork.ozlabs.org/project/ovn/list/?series=308096&state=* If this series is accepted we won't be needing the mcast_flood_reports=true setting in neutron for VIFs anymore.
V3 posted for review: https://patchwork.ozlabs.org/project/ovn/list/?series=312296&state=*
Will be available once ovn22.09 is released downstream.