DescriptionMiguel Angel Nieto
2021-03-01 15:20:23 UTC
Description of problem:
When a vm subscribe to a multicast group a igmp report message is generated. This message could be useful for a switch in which igmp snooping is configured to know which ports should be multicast traffic forwarded. Currently this message is not flooded and it can not arrive to the switch. It is possible to enable manually, but it should be enabled automatically if igmp snooping is enabled.
I have the following logical switch in which i have multicast traffic:
()[root@controller-0 /]# ovn-nbctl show 2065900f-4c15-4643-acfa-bd00f13dd50c
switch 2065900f-4c15-4643-acfa-bd00f13dd50c (neutron-b08eab24-9e16-449f-9a05-7816da1b14b8) (aka data)
port c4980121-6c87-4f8a-b19e-6ec6d71bab0a (aka data_port-5)
addresses: ["fa:16:3e:c9:d3:bc 10.10.114.107", "unknown"]
port 49092126-b923-4b92-8b82-98e16ce75eb3
type: localport
addresses: ["fa:16:3e:df:33:ca"]
port 1273eaac-7920-4b2e-98fc-a2a162974c1b (aka data_port-2)
addresses: ["fa:16:3e:f2:61:2e 10.10.114.109", "unknown"]
port 5704ab32-6c40-4db7-8b35-2d5e34693222 (aka data_port-1)
addresses: ["fa:16:3e:6b:48:f2 10.10.114.158", "unknown"]
port 870e889c-12b6-42dd-8b2b-895b3f715bc9 (aka data_port-4)
addresses: ["fa:16:3e:f8:f9:61 10.10.114.192", "unknown"]
port provnet-88f96a0f-6fcf-4c20-aeac-688a2cf91583
type: localnet
tag: 114
addresses: ["unknown"]
port fa2ee875-4024-4575-916b-66de26acd8b5 (aka data_port-3)
addresses: ["fa:16:3e:53:a1:6b 10.10.114.123", "unknown"]
port e0fdcdca-f06e-4e9b-8f3e-b0e852ef7b32
type: router
router-port: lrp-e0fdcdca-f06e-4e9b-8f3e-b0e852ef7b32
port be9e528e-b36b-4c5e-bcc1-e2b865f5ffef (aka data_port-0)
addresses: ["fa:16:3e:a1:d7:c8 10.10.114.125", "unknown"]
In order to have igmp reports flooded to the network, i have had to enable it for each port. This should be enabled by default:
()[root@controller-0 /]# ovn-nbctl set logical_switch_port 1273eaac-7920-4b2e-98fc-a2a162974c1b options:mcast_flood_reports=true
()[root@controller-0 /]# ovn-nbctl set logical_switch_port 49092126-b923-4b92-8b82-98e16ce75eb3 options:mcast_flood_reports=true
()[root@controller-0 /]# ovn-nbctl set logical_switch_port 49092126-b923-4b92-8b82-98e16ce75eb3 options:mcast_flood_reports=true
()[root@controller-0 /]# ovn-nbctl set logical_switch_port 5704ab32-6c40-4db7-8b35-2d5e34693222 options:mcast_flood_reports=true
()[root@controller-0 /]# ovn-nbctl set logical_switch_port 870e889c-12b6-42dd-8b2b-895b3f715bc9 options:mcast_flood_reports=true
()[root@controller-0 /]# ovn-nbctl set logical_switch_port be9e528e-b36b-4c5e-bcc1-e2b865f5ffef options:mcast_flood_reports=true
()[root@controller-0 /]# ovn-nbctl set logical_switch_port c4980121-6c87-4f8a-b19e-6ec6d71bab0a options:mcast_flood_reports=true
()[root@controller-0 /]# ovn-nbctl set logical_switch_port fa2ee875-4024-4575-916b-66de26acd8b5 options:mcast_flood_reports=true
()[root@controller-0 /]# ovn-nbctl set logical_switch_port provnet-88f96a0f-6fcf-4c20-aeac-688a2cf91583 options:mcast_flood_reports=true
Doing this I can see igmp reports in the hypervisor bridges:
root@computeovndpdksriov-1 heat-admin]# /tmp/tcpdump br-dpdk0 dpdkbond1 -nne | grep -v LACP
clear ovs
e7f8b3a9-5f12-4630-a36b-e7758bcf250c
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on snooper0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:10:30.210954 fa:16:3e:6b:48:f2 > 01:00:5e:00:00:16, ethertype 802.1Q (0x8100), length 58: vlan 114, p 0, ethertype IPv4, 10.10.114.158 > 224.0.0.22: igmp v3 report, 1 group record(s)
15:10:30.210956 fa:16:3e:6b:48:f2 > 01:00:5e:00:00:16, ethertype 802.1Q (0x8100), length 58: vlan 114, p 0, ethertype IPv4, 10.10.114.158 > 224.0.0.22: igmp v3 report, 1 group record(s)
15:10:31.099772 fa:16:3e:6b:48:f2 > 01:00:5e:00:00:16, ethertype 802.1Q (0x8100), length 58: vlan 114, p 0, ethertype IPv4, 10.10.114.158 > 224.0.0.22: igmp v3 report, 1 group record(s)
15:10:31.099775 fa:16:3e:6b:48:f2 > 01:00:5e:00:00:16, ethertype 802.1Q (0x8100), length 58: vlan 114, p 0, ethertype IPv4, 10.10.114.158 > 224.0.0.22: igmp v3 report, 1 group record(s)
15:10:33.179767 fa:16:3e:6b:48:f2 > 01:00:5e:00:00:16, ethertype 802.1Q (0x8100), length 58: vlan 114, p 0, ethertype IPv4, 10.10.114.158 > 224.0.0.22: igmp v3 report, 1 group record(s)
15:10:33.179769 fa:16:3e:6b:48:f2 > 01:00:5e:00:00:16, ethertype 802.1Q (0x8100), length 58: vlan 114, p 0, ethertype IPv4, 10.10.114.158 > 224.0.0.22: igmp v3 report, 1 group record(s)
15:10:33.185527 e4:fc:82:34:4c:43 > 01:00:5e:03:02:01, ethertype 802.1Q (0x8100), length 64: vlan 114, p 0, ethertype IPv4, 10.10.114.253 > 235.3.2.1: igmp query v3 [max resp time 1.0s] [gaddr 235.3.2.1]
15:10:34.112764 fa:16:3e:6b:48:f2 > 01:00:5e:00:00:16, ethertype 802.1Q (0x8100), length 58: vlan 114, p 0, ethertype IPv4, 10.10.114.158 > 224.0.0.22: igmp v3 report, 1 group record(s)
15:10:34.112767 fa:16:3e:6b:48:f2 > 01:00:5e:00:00:16, ethertype 802.1Q (0x8100), length 58: vlan 114, p 0, ethertype IPv4, 10.10.114.158 > 224.0.0.22: igmp v3 report, 1 group record(s)
15:10:34.186908 e4:fc:82:34:4c:43 > 01:00:5e:03:02:01, ethertype 802.1Q (0x8100), length 64: vlan 114, p 0, ethertype IPv4, 10.10.114.253 > 235.3.2.1: igmp query v3 [max resp time 1.0s] [gaddr 235.3.2.1]
15:10:34.790755 fa:16:3e:6b:48:f2 > 01:00:5e:00:00:16, ethertype 802.1Q (0x8100), length 58: vlan 114, p 0, ethertype IPv4, 10.10.114.158 > 224.0.0.22: igmp v3 report, 1 group record(s)
15:10:34.790756 fa:16:3e:6b:48:f2 > 01:00:5e:00:00:16, ethertype 802.1Q (0x8100), length 58: vlan 114, p 0, ethertype IPv4, 10.10.114.158 > 224.0.0.22: igmp v3 report, 1 group record(s)
15:10:42.992825 fa:16:3e:6b:48:f2 > 01:00:5e:00:00:16, ethertype 802.1Q (0x8100), length 58: vlan 114, p 0, ethertype IPv4, 10.10.114.158 > 224.0.0.22: igmp v3 report, 1 group record(s)
15:10:42.992827 fa:16:3e:6b:48:f2 > 01:00:5e:00:00:16, ethertype 802.1Q (0x8100), length 58: vlan 114, p 0, ethertype IPv4, 10.10.114.158 > 224.0.0.22: igmp v3 report, 1 group record(s)
I also can see that those packages are arriving to the physical switch:
root@nfv-private-sw04> show igmp snooping statistics vlan vlan114
Vlan: vlan114
IGMP Message type Received Sent Rx errors
Membership Query 200 31094 0
V1 Membership Report 0 0 0
DVMRP 0 0 0
PIM V1 0 0 0
Cisco Trace 0 0 0
V2 Membership Report 0 0 0
Group Leave 0 0 0
Mtrace Response 0 0 0
Mtrace Request 0 0 0
Domain Wide Report 0 0 0
V3 Membership Report 12 0 0
Other Unknown types 0
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. Create a vlan network
3. Spawn a vm
4. Execute tcpdump in the vm and ovs-tcpdump in br-int
5. Start a multicast receiver (it could be iperf or multicast_traffic.py (https://github.com/redhat-openstack/nfv-tempest-plugin/blob/master/nfv_tempest_plugin/tests/scenario/tests_scripts/multicast_traffic.py)
6. igmp reports are reported inside the vm, but not in br-int
7. enable options:mcast_flood_reports=true in all the logical ports of the logical switch
8. start receiver again and in this case we can see that messages are being flooded.
Actual results:
igmp reports messages are blocked
Expected results:
igmp reports messages should be flooded
Additional info:
Description of problem: When a vm subscribe to a multicast group a igmp report message is generated. This message could be useful for a switch in which igmp snooping is configured to know which ports should be multicast traffic forwarded. Currently this message is not flooded and it can not arrive to the switch. It is possible to enable manually, but it should be enabled automatically if igmp snooping is enabled. I have the following logical switch in which i have multicast traffic: ()[root@controller-0 /]# ovn-nbctl show 2065900f-4c15-4643-acfa-bd00f13dd50c switch 2065900f-4c15-4643-acfa-bd00f13dd50c (neutron-b08eab24-9e16-449f-9a05-7816da1b14b8) (aka data) port c4980121-6c87-4f8a-b19e-6ec6d71bab0a (aka data_port-5) addresses: ["fa:16:3e:c9:d3:bc 10.10.114.107", "unknown"] port 49092126-b923-4b92-8b82-98e16ce75eb3 type: localport addresses: ["fa:16:3e:df:33:ca"] port 1273eaac-7920-4b2e-98fc-a2a162974c1b (aka data_port-2) addresses: ["fa:16:3e:f2:61:2e 10.10.114.109", "unknown"] port 5704ab32-6c40-4db7-8b35-2d5e34693222 (aka data_port-1) addresses: ["fa:16:3e:6b:48:f2 10.10.114.158", "unknown"] port 870e889c-12b6-42dd-8b2b-895b3f715bc9 (aka data_port-4) addresses: ["fa:16:3e:f8:f9:61 10.10.114.192", "unknown"] port provnet-88f96a0f-6fcf-4c20-aeac-688a2cf91583 type: localnet tag: 114 addresses: ["unknown"] port fa2ee875-4024-4575-916b-66de26acd8b5 (aka data_port-3) addresses: ["fa:16:3e:53:a1:6b 10.10.114.123", "unknown"] port e0fdcdca-f06e-4e9b-8f3e-b0e852ef7b32 type: router router-port: lrp-e0fdcdca-f06e-4e9b-8f3e-b0e852ef7b32 port be9e528e-b36b-4c5e-bcc1-e2b865f5ffef (aka data_port-0) addresses: ["fa:16:3e:a1:d7:c8 10.10.114.125", "unknown"] In order to have igmp reports flooded to the network, i have had to enable it for each port. This should be enabled by default: ()[root@controller-0 /]# ovn-nbctl set logical_switch_port 1273eaac-7920-4b2e-98fc-a2a162974c1b options:mcast_flood_reports=true ()[root@controller-0 /]# ovn-nbctl set logical_switch_port 49092126-b923-4b92-8b82-98e16ce75eb3 options:mcast_flood_reports=true ()[root@controller-0 /]# ovn-nbctl set logical_switch_port 49092126-b923-4b92-8b82-98e16ce75eb3 options:mcast_flood_reports=true ()[root@controller-0 /]# ovn-nbctl set logical_switch_port 5704ab32-6c40-4db7-8b35-2d5e34693222 options:mcast_flood_reports=true ()[root@controller-0 /]# ovn-nbctl set logical_switch_port 870e889c-12b6-42dd-8b2b-895b3f715bc9 options:mcast_flood_reports=true ()[root@controller-0 /]# ovn-nbctl set logical_switch_port be9e528e-b36b-4c5e-bcc1-e2b865f5ffef options:mcast_flood_reports=true ()[root@controller-0 /]# ovn-nbctl set logical_switch_port c4980121-6c87-4f8a-b19e-6ec6d71bab0a options:mcast_flood_reports=true ()[root@controller-0 /]# ovn-nbctl set logical_switch_port fa2ee875-4024-4575-916b-66de26acd8b5 options:mcast_flood_reports=true ()[root@controller-0 /]# ovn-nbctl set logical_switch_port provnet-88f96a0f-6fcf-4c20-aeac-688a2cf91583 options:mcast_flood_reports=true Doing this I can see igmp reports in the hypervisor bridges: root@computeovndpdksriov-1 heat-admin]# /tmp/tcpdump br-dpdk0 dpdkbond1 -nne | grep -v LACP clear ovs e7f8b3a9-5f12-4630-a36b-e7758bcf250c tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on snooper0, link-type EN10MB (Ethernet), capture size 262144 bytes 15:10:30.210954 fa:16:3e:6b:48:f2 > 01:00:5e:00:00:16, ethertype 802.1Q (0x8100), length 58: vlan 114, p 0, ethertype IPv4, 10.10.114.158 > 224.0.0.22: igmp v3 report, 1 group record(s) 15:10:30.210956 fa:16:3e:6b:48:f2 > 01:00:5e:00:00:16, ethertype 802.1Q (0x8100), length 58: vlan 114, p 0, ethertype IPv4, 10.10.114.158 > 224.0.0.22: igmp v3 report, 1 group record(s) 15:10:31.099772 fa:16:3e:6b:48:f2 > 01:00:5e:00:00:16, ethertype 802.1Q (0x8100), length 58: vlan 114, p 0, ethertype IPv4, 10.10.114.158 > 224.0.0.22: igmp v3 report, 1 group record(s) 15:10:31.099775 fa:16:3e:6b:48:f2 > 01:00:5e:00:00:16, ethertype 802.1Q (0x8100), length 58: vlan 114, p 0, ethertype IPv4, 10.10.114.158 > 224.0.0.22: igmp v3 report, 1 group record(s) 15:10:33.179767 fa:16:3e:6b:48:f2 > 01:00:5e:00:00:16, ethertype 802.1Q (0x8100), length 58: vlan 114, p 0, ethertype IPv4, 10.10.114.158 > 224.0.0.22: igmp v3 report, 1 group record(s) 15:10:33.179769 fa:16:3e:6b:48:f2 > 01:00:5e:00:00:16, ethertype 802.1Q (0x8100), length 58: vlan 114, p 0, ethertype IPv4, 10.10.114.158 > 224.0.0.22: igmp v3 report, 1 group record(s) 15:10:33.185527 e4:fc:82:34:4c:43 > 01:00:5e:03:02:01, ethertype 802.1Q (0x8100), length 64: vlan 114, p 0, ethertype IPv4, 10.10.114.253 > 235.3.2.1: igmp query v3 [max resp time 1.0s] [gaddr 235.3.2.1] 15:10:34.112764 fa:16:3e:6b:48:f2 > 01:00:5e:00:00:16, ethertype 802.1Q (0x8100), length 58: vlan 114, p 0, ethertype IPv4, 10.10.114.158 > 224.0.0.22: igmp v3 report, 1 group record(s) 15:10:34.112767 fa:16:3e:6b:48:f2 > 01:00:5e:00:00:16, ethertype 802.1Q (0x8100), length 58: vlan 114, p 0, ethertype IPv4, 10.10.114.158 > 224.0.0.22: igmp v3 report, 1 group record(s) 15:10:34.186908 e4:fc:82:34:4c:43 > 01:00:5e:03:02:01, ethertype 802.1Q (0x8100), length 64: vlan 114, p 0, ethertype IPv4, 10.10.114.253 > 235.3.2.1: igmp query v3 [max resp time 1.0s] [gaddr 235.3.2.1] 15:10:34.790755 fa:16:3e:6b:48:f2 > 01:00:5e:00:00:16, ethertype 802.1Q (0x8100), length 58: vlan 114, p 0, ethertype IPv4, 10.10.114.158 > 224.0.0.22: igmp v3 report, 1 group record(s) 15:10:34.790756 fa:16:3e:6b:48:f2 > 01:00:5e:00:00:16, ethertype 802.1Q (0x8100), length 58: vlan 114, p 0, ethertype IPv4, 10.10.114.158 > 224.0.0.22: igmp v3 report, 1 group record(s) 15:10:42.992825 fa:16:3e:6b:48:f2 > 01:00:5e:00:00:16, ethertype 802.1Q (0x8100), length 58: vlan 114, p 0, ethertype IPv4, 10.10.114.158 > 224.0.0.22: igmp v3 report, 1 group record(s) 15:10:42.992827 fa:16:3e:6b:48:f2 > 01:00:5e:00:00:16, ethertype 802.1Q (0x8100), length 58: vlan 114, p 0, ethertype IPv4, 10.10.114.158 > 224.0.0.22: igmp v3 report, 1 group record(s) I also can see that those packages are arriving to the physical switch: root@nfv-private-sw04> show igmp snooping statistics vlan vlan114 Vlan: vlan114 IGMP Message type Received Sent Rx errors Membership Query 200 31094 0 V1 Membership Report 0 0 0 DVMRP 0 0 0 PIM V1 0 0 0 Cisco Trace 0 0 0 V2 Membership Report 0 0 0 Group Leave 0 0 0 Mtrace Response 0 0 0 Mtrace Request 0 0 0 Domain Wide Report 0 0 0 V3 Membership Report 12 0 0 Other Unknown types 0 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. Create a vlan network 3. Spawn a vm 4. Execute tcpdump in the vm and ovs-tcpdump in br-int 5. Start a multicast receiver (it could be iperf or multicast_traffic.py (https://github.com/redhat-openstack/nfv-tempest-plugin/blob/master/nfv_tempest_plugin/tests/scenario/tests_scripts/multicast_traffic.py) 6. igmp reports are reported inside the vm, but not in br-int 7. enable options:mcast_flood_reports=true in all the logical ports of the logical switch 8. start receiver again and in this case we can see that messages are being flooded. Actual results: igmp reports messages are blocked Expected results: igmp reports messages should be flooded Additional info: