← Back to team overview

yahoo-eng-team team mailing list archive

  1. yahoo-eng-team team
  2. Mailing list archive
  3. Message #94042

[Bug 2067571] [NEW] The outbound unicast traffic of VMS with security group enabled is broadcast

  Thread Previous • Date Previous • • Thread Next 
Public bug reported:

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

** Affects: neutron
     Importance: Undecided
         Status: New

** Description changed:

- 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.
-   
-      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.
- 	 
- 	                         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
+ 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.
  
-      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
+   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

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2067571

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

Status in neutron:
  New

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2067571/+subscriptions
  Thread Previous • Date Previous • • Thread Next