Hi,
If I understand correctly Your issue, You may be hitting https://bugs.launchpad.net/neutron/+bug/2051351 for which there is already proposed fix https://review.opendev.org/c/openstack/neutron/+/907382 (but not merged yet).
Dnia czwartek, 30 maja 2024 09:29:07 CEST renwc@chinatelecom.cn pisze:
> hello everyone，
> Here is a description of a bug I encountered using openstack Security Group,If security groups are enabled for virtual nics
> on cloud hosts, The outgoing traffic of the VMS enabled in the security group should be sent in unicast mode,
> but it is eventually forwarded to all ports in the vlan on the ovs br-int bridge.
>
> Does the openstack open source community have a patch to fix this bug? Can you provide patch?
>
> The following is my debugging process in detail.
> The unicast packet sent by the remote virtual machine 172.83.160.63 to the local virtual machine 172.83.160.74 is passed to the br-ex->br-int-> VM,
> Because the security group is enabled on the VM NIC, The br-int cannot learn the entry whose port is patch-ex and mac address is vm2.
> Therefore those packets sent from vm1 to vm2 are broadcast in vlans because they fail to match mac address entries.
>
> 172.83.160.74 patch-int 172.83.160.63
> vm1 --- ovs(br-int) ------ ovs(br-ex)--- tor(physical switch) ......vm2
> patch-ex
>
> The following is the ovs kernel flow table. The mac address of vm1 is fa:16:3e:6c:f3:09,The mac address of vm2 is fa:16:3e:d2:14:b5, the action of the flow table is multiple ports.
>
> recirc_id(0x314123),in_port(8),ct_state(-new+est-rel-rpl),eth(src=fa:16:3e:d2:14:b5,dst=fa:16:3e:6c:f3:09),eth_type(0x0800),ipv4(proto=6,frag=no),tcp(dst=2048/0xf800), packets:60100, bytes:14257193, used:2.035s, flags:P., actions:push_vlan(vid=5,pcp=0),3,pop_vlan,push_vlan(vid=1732,pcp=0),1,pop_vlan,7,9,10,15,5,18
>
> recirc_id(0x314123),in_port(8),ct_state(-new+est-rel+rpl-inv+trk),ct_zone(0x5),ct_mark(0),eth(src=fa:16:3e:d2:14:b5,dst=fa:16:3e:6c:f3:09),eth_type(0x0800),ipv4(frag=no), packets:1, bytes:54, used:2.037s, flags:., actions:push_vlan(vid=5,pcp=0),3,pop_vlan,push_vlan(vid=1732,pcp=0),1,pop_vlan,7,9,10,15,5,18
>
> After careful debugging analysis, the openflow action in the flow table 82 added by neutron is the VM port instead of normal.
> As a result, the ovs br-int bridge cannot learn the mac entry of vm2.
>
> table=82, priority=77,ct_state=+new-est,tcp,reg5=0x9,tp_dst=0x4/0xfffc actions=ct(commit,zone=NXM_NX_REG6[0..15]),output:9
> table=82, priority=77,ct_state=+est-rel-rpl,tcp,reg5=0x9,tp_dst=0x4/0xfffc actions=output:9
>
> Looking forward to reply thanks.
>
> weichun ren
>
--
Slawek Kaplonski
Principal Software Engineer
Red Hat