[OVN] IGMP snooping traps IGMP messages
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
Confirmed
|
High
|
Lucas Alvares Gomes |
Bug Description
Hi,
Once we enable IGMP snooping on Neutron, IGMP messages are trapped and cannot leave the virtual switch.
That leads to an non-scalable solution, given that external network cannot know which computes are looking for a given multicast flow and then, are forced to push all multicast to all hosts.
Also, if we resolve the problem above, the provider network interface on the vswitch side becomes an interface that can report into IGMP_Group table on OVN by itself. Therefore, it gets added/removed everytime the external network sends an IGMP message to join/leave a flow. That means multicast traffic entering or leaving hosts will be gated by this erradic behavior of the provnet interface.
The solution I see for this is to (1) always allow all interfaces to flood IGMP; and (2) provnet interfaces should also be allowed to flood multicast traffic.
tags: | added: ovn |
tags: | added: neutron-proactive-backport-potential |
Hi Pedro,
Thanks for reporting this.
Perhaps is something we need to include in the OVN driver itself. We have this bug downstream at https:/ /bugzilla. redhat. com/show_ bug.cgi? id=1933990# c3, and in talks with the Core OVN developers turns out we could enable "mcast_ flood_reports" on the Logical_ Switch_ Ports in the OVN driver to workaround this problem (that would prevent ovn-controller trapping the IGMP pkts).
If you can't wait and want to test it on your environment, it's possible to set this option on the LSP running:
$ ovn-nbctl set logical_switch_port <Neutron port UUID> options: mcast_flood_ reports= true