The outbound unicast traffic of VMS with security group enabled is broadcast

Bug #2067571 reported by weichun ren

This bug report will be marked for expiration in 25 days if no further activity occurs. (find out why)

6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Incomplete
Medium
Unassigned

Bug Description

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 unicast traffic, but it is eventually forwarded to all ports belong to the vlan on the ovs br-int bridge.

  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.

                          patch-int
     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

thank you

Tags: ovs
weichun ren (renwc)
description: updated
Revision history for this message
LIU Yulong (dragon889) wrote :

You may have a try to set explicitly_egress_direct=True for your ovs-agent.

See this for details:
https://docs.openstack.org/neutron/latest/contributor/internals/openvswitch_firewall.html#openflow-rules

And this is the original bug:
https://bugs.launchpad.net/neutron/+bug/1732067

Changed in neutron:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Lajos Katona (lajos-katona) wrote :

@renwc: Do you have any feedback if with explicitly_egress_direct=True your issue is solved?

tags: added: ovs
Changed in neutron:
status: Confirmed → Incomplete
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.