Description of problem:
This bug is reproduced running the following test (test_igmp_snooping_ext_network_and_unsubscribe) on an Openstack BGP setup:
https://code.engineering.redhat.com/gerrit/plugins/gitiles/rhos-qe-tests/tempest_neutron_plugin/+/master/neutron_plugin/tests/scenario/test_multicast.py#606

The test creates a sender and a receiver VM on different compute nodes.
The receiver VM subscribes to a multicast group.
The sender VM sends a message to that multicast group.
The test checks the receiver VM received the message.

This test passes on non-BGP OSP17.1 CI jobs, but it fails on BGP jobs.

On a non-BGP environment, the sender VM sends a packet with destination IP 225.0.0.120 and destination MAC 01:00:5e:00:00:78. That packet goes from the VM, through its tap interface, br-ex and output port from the compute (e.g.: enp3s0) and it is flooded to all the overcloud nodes. The packet can be captured on any overcloud node, with the same dest IP and MAC addresses. The compute where the receiver IP runs receives that packet and replies.

On a BGP environment, the sender VM sends a packet with destination IP 225.0.0.120 and destination MAC 01:00:5e:00:00:78. The dest MAC changes in the br-ex from the compute where the sender VM runs because of the flows installed when BGP is configured.

Packet captured on tapc3cd612b-65:
10:44:26.216301 fa:16:3e:e1:d0:a4 > 01:00:5e:00:00:78, ethertype IPv4 (0x0800), length 59: (tos 0x0, ttl 1, id 47094, offset 0, flags [DF], proto UDP (17), length 45)
172.24.100.93.41784 > 225.0.0.120.wsm-server-ssl: UDP, length 17

Packet captured on br-ex:
10:44:26.216515 fa:16:3e:e1:d0:a4 > 42:a5:1f:62:db:4f, ethertype IPv4 (0x0800), length 59: (tos 0x0, ttl 1, id 47094, offset 0, flags [DF], proto UDP (17), length 45)
172.24.100.93.41784 > 225.0.0.120.wsm-server-ssl: UDP, length 17

br-ex flows:
[root@cmp-2-0 ~]# ovs-ofctl dump-flows br-ex
cookie=0x3e7, duration=85.036s, table=0, n_packets=8, n_bytes=720, priority=900,ip,in_port="patch-provnet-1" actions=mod_dl_dst:42:a5:1f:62:db:4f,NORMAL
cookie=0x3e7, duration=85.015s, table=0, n_packets=0, n_bytes=0, priority=900,ipv6,in_port="patch-provnet-1" actions=mod_dl_dst:42:a5:1f:62:db:4f,NORMAL

The packet is not flooded and it can't be routed at L3 level too.
In case of BGP environments, since the overcloud nodes are not on the same L2 network, and the routing depends on the FRR configuration, multicast BGP routing support should be added to the frr.conf file generated by tripleo and applied to the overcloud nodes.
The FRR configuration from the routers (spines and leafs) that are part of this setup will also have to be adapted.

This is probably a tripleo bug, but I'm setting component to ovn-bgp-agent for triaging purposes. The component can be modified later, if needed.

Version-Release number of selected component (if applicable):
RHOS-17.1-RHEL-9-20221130.n.1
ovn-bgp-agent-0.3.1-1.20221117171123.5388639.el9ost.noarch
openstack-tripleo-common-15.4.1-1.20221120001853.868af68.el9ost.noarch

How reproducible:
100%

Steps to Reproduce:
1. run test test_igmp_snooping_ext_network_and_unsubscribe on a BGP setup
2.
3.

Actual results:
The compute can't route the packet sent to a multicast dest IP

Expected results:
The VMs subscribed to a multicast group successfully received the multicast packets sent to it