Bug 1933990

Summary: [OVN] External igmp queries not arriving to the vms
Product: Red Hat Enterprise Linux Fast Datapath Reporter: Miguel Angel Nieto <mnietoji>
Component: ovn2.13Assignee: Dumitru Ceara <dceara>
Status: CLOSED CURRENTRELEASE QA Contact: ying xu <yinxu>
Severity: medium Docs Contact:
Priority: high    
Version: FDP 21.ACC: apevec, ctrautma, dceara, egarciar, hakhande, jiji, jishi, jlibosva, lhh, majopela, mmichels, oblaut, ralongi, rsafrono, scohen
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-03-13 07:16:49 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:

Description Miguel Angel Nieto 2021-03-02 09:00:41 UTC 
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
Comment 2 Miguel Angel Nieto 2021-03-02 13:23:19 UTC 
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.
Comment 3 Lucas Alvares Gomes 2021-03-02 16:25:14 UTC 
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
Comment 7 Dumitru Ceara 2022-04-08 12:50:28 UTC 
Bumping priority, this breaks IGMP with external queriers:

https://github.com/ovn-org/ovn/issues/126
Comment 8 Dumitru Ceara 2022-07-05 12:20:04 UTC 
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.
Comment 9 Dumitru Ceara 2022-08-02 14:47:14 UTC 
V3 posted for review:
https://patchwork.ozlabs.org/project/ovn/list/?series=312296&state=*
Comment 10 Dumitru Ceara 2022-08-03 09:11:43 UTC 
Will be available once ovn22.09 is released downstream.