Hi Bence,

Sorry for the slow response.

On 2/23/26 6:50 AM, Bence Romsics wrote:
> Hi Neutrinos,
>
> We have a user who discovered that two neutron backends behave
> differently when it comes to handling multicast traffic.
> This user runs servers that need multicast for VRRP coordination (the
> point is multicast, not VRRP).
> They discovered that with the (no longer upstream supported)
> OpenDaylight backend,
> they need to let the multicast traffic through with an allowed address pair.
> On the other hand, the ml2/ovs backend (here always assuming the ovs
> firewall driver) allows the multicast traffic by default.
> If you add the same allowed address pair (for example: {'mac_address':
> '01:00:5e:00:00:64', 'ip_address': '224.0.0.100'}) as with
> OpenDaylight, it actually breaks multicast traffic.
> The traffic breaks even on other servers, affected by the same set of
> flows installed by ovs-agent.
>
> My question is: which backend behaves correctly? And do we need to
> change anything upstream?
>
> Since I found the following upstream history...
>
> https://opendev.org/openstack/neutron/src/branch/master/doc/source/admin/config-ovsfwdriver.rst#differences-between-ovs-and-iptables-firewall-drivers
> https://bugs.launchpad.net/neutron/+bug/1889631
>
> ... I believe that ml2/ovs (with the ovs fw driver) behaves correctly
> when it lets the multicast traffic through by default.
> However I believe it is a bug that the traffic breaks when the user
> adds the allowed address pair.
> But I think it would be pretty pointless to start fixing the traffic itself
> since we would need to make changes for no effect.
> Rather we could reject allowed address pairs with multicast IPs/MAC addresses,
> because that would call the attention of the user that multicast
> traffic is already handled at a different place (that is the default
> behavior of the fw driver).

Yes, based on the docs the OVS FW driver is behaving correctly by
allowing the multicast traffic.

> I also believe that the OpenDaylight driver is buggy when it does not
> let the multicast traffic through just like ml2/ovs does.
> However this is not an upstream problem anymore, since networking-odl
> is long deprecated.
>
> Do you agree in the judgement where the bugs are in this case?
> The possible upstream change: Do you think we should start rejecting
> allowed address pairs with multicast IPs/MAC addresses?
> Plus I guess a doc update for allowed address pairs api-ref is due...
>
> If needed, I'm happy to bring this to the drivers meeting.
> It's 100% that I could attend next Friday (6th of March) and 80% for
> this Friday (27th of February).
It does seem like the intention of allowed address pairs was for unicast
addresses, so I guess rejecting multicast would be Ok. This is the
original spec for history, which only uses unicast addresses in examples
[0].

Let me know if you still want to meet tomorrow at drivers meeting.

[0]
https://github.com/openstack/neutron-specs/blob/master/misc/api/allowed_address_pairs.rst

-Brian