Bug 1544892

Can you include a dump of ovs-ofctl dump-flows for br-int and br-ex?

Moshe, can you please capture the requested flows?

[root@overcloud-controller-foo-0 ~]# ovs-ofctl -OOpenFlow13 dump-flows br-ex                                                                                           
 cookie=0x0, duration=10339.559s, table=0, n_packets=210371, n_bytes=182358037, priority=0 actions=NORMAL                                                              
[root@overcloud-controller-foo-0 ~]# ovs-ofctl -OOpenFlow13 dump-flows br-int
 cookie=0x8000000, duration=3481.019s, table=0, n_packets=495, n_bytes=49774, priority=4,in_port="tap64320edb-40",vlan_tci=0x0000/0x1fff actions=write_metadata:0x10000000000/0xffffff0000000001,goto_table:17                                                                                                                                  
 cookie=0x8000000, duration=3480.626s, table=0, n_packets=11120, n_bytes=641544, priority=4,in_port="br-ex-patch",vlan_tci=0x0000/0x1fff actions=write_metadata:0x20000000001/0xffffff0000000001,goto_table:17                                                                                                                                  
 cookie=0x8000000, duration=3480.482s, table=0, n_packets=7544, n_bytes=435478, priority=10,in_port="br-ex-patch",dl_vlan=20 actions=pop_vlan,write_metadata:0x30000000001/0xffffff0000000001,goto_table:17                                                                                                                                     
 cookie=0x8040000, duration=3479.597s, table=17, n_packets=492, n_bytes=49516, priority=10,metadata=0x10000000000/0xffffff0000000000 actions=load:0x1->NXM_NX_REG1[0..19],load:0x138b->NXM_NX_REG7[0..15],write_metadata:0xa00001138b000000/0xfffffffffffffffe,goto_table:43                                                                    
 cookie=0x8040000, duration=3479.470s, table=17, n_packets=7540, n_bytes=435262, priority=10,metadata=0x30000000000/0xffffff0000000000 actions=load:0x3->NXM_NX_REG1[0..19],load:0x138b->NXM_NX_REG7[0..15],write_metadata:0xa00003138b000000/0xfffffffffffffffe,goto_table:43                                                                  
 cookie=0x8000000, duration=8252.671s, table=17, n_packets=0, n_bytes=0, priority=0,metadata=0x8000000000000000/0xf000000000000000 actions=write_metadata:0x9000000000000000/0xf000000000000000,goto_table:80                                                                                                                                   
 cookie=0x6800000, duration=8252.908s, table=18, n_packets=0, n_bytes=0, priority=0 actions=goto_table:38                                                               
 cookie=0x8220015, duration=8252.739s, table=19, n_packets=0, n_bytes=0, priority=100,arp,arp_op=1 actions=resubmit(,17)                                                
 cookie=0x8220016, duration=8252.739s, table=19, n_packets=0, n_bytes=0, priority=100,arp,arp_op=2 actions=resubmit(,17)                                                
 cookie=0x1080000, duration=8252.739s, table=19, n_packets=0, n_bytes=0, priority=0 actions=resubmit(,17)                                                               
 cookie=0x1030000, duration=8252.739s, table=20, n_packets=0, n_bytes=0, priority=0 actions=goto_table:80                                                               
 cookie=0x8000004, duration=8252.739s, table=22, n_packets=0, n_bytes=0, priority=0 actions=CONTROLLER:65535                                                            
 cookie=0x1080000, duration=8252.739s, table=23, n_packets=0, n_bytes=0, priority=0 actions=resubmit(,17)                                                               
 cookie=0x1080000, duration=8252.886s, table=24, n_packets=0, n_bytes=0, priority=0 actions=resubmit(,17)                                                               
 cookie=0x822002d, duration=8252.269s, table=43, n_packets=51, n_bytes=2618, priority=100,arp,arp_op=1 actions=group:5000                                               
 cookie=0x822002e, duration=8252.269s, table=43, n_packets=32, n_bytes=1686, priority=100,arp,arp_op=2 actions=CONTROLLER:65535,resubmit(,48)                           
 cookie=0x8220000, duration=8252.908s, table=43, n_packets=7949, n_bytes=480474, priority=0 actions=goto_table:48                                                       
 cookie=0x4000000, duration=8252.908s, table=45, n_packets=0, n_bytes=0, priority=0 actions=resubmit(,17)                                                               
 cookie=0x8500000, duration=8252.908s, table=48, n_packets=8032, n_bytes=484778, priority=0 actions=resubmit(,49),resubmit(,50)                                         
 cookie=0x805138b, duration=3479.660s, table=50, n_packets=492, n_bytes=49516, priority=20,metadata=0x1138b000000/0xfffffffff000000,dl_src=fa:16:3e:ae:99:79 actions=goto_table:51                                                                                                                                                              
 cookie=0x805138b, duration=3478.439s, table=50, n_packets=6947, n_bytes=375138, idle_timeout=300, send_flow_rem priority=20,metadata=0x3138b000000/0xfffffffff000000,dl_src=8a:8e:00:c8:78:85 actions=goto_table:51                                                                                                                            
 cookie=0x805138b, duration=72.473s, table=50, n_packets=51, n_bytes=5034, idle_timeout=300, send_flow_rem priority=20,metadata=0x3138b000000/0xfffffffff000000,dl_src=fa:16:3e:ae:e6:fc actions=goto_table:51                                                                                                                                  
 cookie=0x8050001, duration=8252.908s, table=50, n_packets=2, n_bytes=148, priority=10,reg4=0x1 actions=goto_table:51                                                   
 cookie=0x8050000, duration=8252.908s, table=50, n_packets=6, n_bytes=1016, priority=0 actions=CONTROLLER:65535,learn(table=49,hard_timeout=10,priority=0,cookie=0x8600000,NXM_OF_ETH_SRC[],NXM_NX_REG1[0..19],load:0x1->NXM_NX_REG4[0..7]),goto_table:51                                                                                       
 cookie=0x803138b, duration=3479.660s, table=51, n_packets=539, n_bytes=53434, priority=20,metadata=0x138b000000/0xffff000000,dl_dst=fa:16:3e:ae:99:79 actions=load:0x100->NXM_NX_REG6[],resubmit(,220)                                                                                                                                         
 cookie=0x803138b, duration=3478.439s, table=51, n_packets=0, n_bytes=0, priority=20,metadata=0x138b000000/0xffff000000,dl_dst=8a:8e:00:c8:78:85 actions=load:0x300->NXM_NX_REG6[],resubmit(,220)                                                                                                                                               
 cookie=0x803138b, duration=72.473s, table=51, n_packets=51, n_bytes=4774, priority=20,metadata=0x138b000000/0xffff000000,dl_dst=fa:16:3e:ae:e6:fc actions=load:0x300->NXM_NX_REG6[],resubmit(,220)                                                                                                                                             
 cookie=0x8030000, duration=8252.886s, table=51, n_packets=0, n_bytes=0, priority=15,dl_dst=01:80:c2:00:00:00/ff:ff:ff:ff:ff:f0 actions=drop
 cookie=0x8030000, duration=8252.908s, table=51, n_packets=7003, n_bytes=382016, priority=0 actions=goto_table:52
 cookie=0x870138b, duration=3479.660s, table=52, n_packets=2, n_bytes=188, priority=5,metadata=0x138b000000/0xffff000001 actions=write_actions(group:210006)
 cookie=0x870138b, duration=3479.660s, table=52, n_packets=7001, n_bytes=381828, priority=5,metadata=0x138b000001/0xffff000001 actions=write_actions(group:210005)
 cookie=0x8800001, duration=3479.660s, table=55, n_packets=2, n_bytes=188, priority=10,tun_id=0x1,metadata=0x10000000000/0xfffff0000000000 actions=drop
 cookie=0x8800003, duration=3479.504s, table=55, n_packets=0, n_bytes=0, priority=10,tun_id=0x3,metadata=0x30000000000/0xfffff0000000000 actions=drop
 cookie=0x8800001, duration=3479.660s, table=55, n_packets=7001, n_bytes=381828, priority=9,tun_id=0x1 actions=load:0x100->NXM_NX_REG6[],resubmit(,220)
 cookie=0x8800003, duration=3479.504s, table=55, n_packets=0, n_bytes=0, priority=9,tun_id=0x3 actions=load:0x300->NXM_NX_REG6[],resubmit(,220)
 cookie=0x1030000, duration=8252.739s, table=80, n_packets=0, n_bytes=0, priority=0 actions=resubmit(,17)
 cookie=0x8220000, duration=8252.908s, table=81, n_packets=51, n_bytes=2618, priority=0 actions=drop
 cookie=0x4000001, duration=8252.886s, table=90, n_packets=0, n_bytes=0, priority=0 actions=resubmit(,17)
 cookie=0x6900000, duration=8252.886s, table=211, n_packets=0, n_bytes=0, priority=63009,arp actions=drop
 cookie=0x6900000, duration=8252.886s, table=211, n_packets=0, n_bytes=0, priority=61009,ip actions=drop
 cookie=0x6900000, duration=8252.855s, table=211, n_packets=0, n_bytes=0, priority=61009,ipv6 actions=drop
 cookie=0x6900000, duration=8252.908s, table=211, n_packets=0, n_bytes=0, priority=0 actions=drop
 cookie=0x6900000, duration=8252.908s, table=212, n_packets=0, n_bytes=0, priority=0 actions=goto_table:213
 cookie=0x6900000, duration=8252.908s, table=213, n_packets=0, n_bytes=0, priority=62020,ct_state=-new+est-rel-inv+trk actions=resubmit(,17)
 cookie=0x6900000, duration=8252.908s, table=213, n_packets=0, n_bytes=0, priority=62020,ct_state=-new-est+rel-inv+trk actions=resubmit(,17)
 cookie=0x6900000, duration=8252.908s, table=213, n_packets=0, n_bytes=0, priority=0 actions=drop
 cookie=0x8000007, duration=3480.436s, table=220, n_packets=0, n_bytes=0, priority=10,reg6=0x300,metadata=0x1/0x1 actions=drop
 cookie=0x8000007, duration=3480.436s, table=220, n_packets=0, n_bytes=0, priority=10,reg6=0x200,metadata=0x1/0x1 actions=drop
 cookie=0x8000007, duration=3480.771s, table=220, n_packets=7540, n_bytes=435262, priority=9,reg6=0x100 actions=output:"tap64320edb-40"
 cookie=0x8000007, duration=3480.436s, table=220, n_packets=492, n_bytes=49516, priority=9,reg6=0x300 actions=push_vlan:0x8100,set_field:4116->vlan_vid,output:"br-ex-patch"
 cookie=0x8000007, duration=3480.436s, table=220, n_packets=0, n_bytes=0, priority=9,reg6=0x200 actions=output:"br-ex-patch"
 cookie=0x6900000, duration=8252.848s, table=239, n_packets=0, n_bytes=0, priority=62020,ct_state=+trk,ip actions=ct(table=241)
 cookie=0x6900000, duration=8252.739s, table=239, n_packets=0, n_bytes=0, priority=62020,ct_state=+trk,ipv6 actions=ct(table=241)
 cookie=0x6900000, duration=8252.739s, table=239, n_packets=0, n_bytes=0, priority=61010 actions=goto_table:241
 cookie=0x6900000, duration=8252.908s, table=241, n_packets=0, n_bytes=0, priority=61010,ip,dl_dst=ff:ff:ff:ff:ff:ff,nw_dst=255.255.255.255 actions=goto_table:242
 cookie=0x6900000, duration=8252.886s, table=241, n_packets=0, n_bytes=0, priority=61005,dl_dst=ff:ff:ff:ff:ff:ff actions=resubmit(,220)
 cookie=0x6900000, duration=8252.886s, table=241, n_packets=0, n_bytes=0, priority=0 actions=drop
 cookie=0x6900000, duration=8252.886s, table=242, n_packets=0, n_bytes=0, priority=0 actions=goto_table:243
 cookie=0x6900000, duration=8252.886s, table=243, n_packets=0, n_bytes=0, priority=62020,ct_state=-new+est-rel-inv+trk actions=resubmit(,220)
 cookie=0x6900000, duration=8252.886s, table=243, n_packets=0, n_bytes=0, priority=62020,ct_state=-new-est+rel-inv+trk actions=resubmit(,220)
 cookie=0x6900000, duration=8252.886s, table=243, n_packets=0, n_bytes=0, priority=0 actions=drop

This is the behavior we see:
1. tripleo 1 controller and 1 compute with opendaylight master and 1 port with vlans:
   1.1 VM get DHCP
   1.2 VM can ping dhcp server

2. tripleo 1 controller 2 compute with opendaylight master and 1 port with vlans:
   1.1 VM didn't get an ip
   1.2 DHCP packet get to the openstack controller node 
   1.3 controller node output the packet to br-ex instead of br-int (see above issue)

3. tripleo 1 controller 2 compute with opendaylight master and 2 ports with vlans
   1.1 VM didn't get an ip
   1.2 DHCP packet are dropped in the compute node
   

ovs-ofctl dump for scenario 3 
[root@overcloud-computesriov-0 ~]# ovs-ofctl -OOpenflow13 dump-flows br-int --name  | grep -v n_packets=0                                                               
 cookie=0x8000000, duration=2087.394s, table=0, n_packets=39, n_bytes=9354, priority=4,in_port=eth3,vlan_tci=0x0000/0x1fff actions=write_metadata:0x20000000000/0xffffff0000000001,goto_table:17                                                                                                                                                
 cookie=0x8040000, duration=2086.774s, table=17, n_packets=39, n_bytes=9354, priority=10,metadata=0x20000000000/0xffffff0000000000 actions=load:0x2->NXM_NX_REG1[0..19],load:0x138a->NXM_NX_REG7[0..15],write_metadata:0xa00002138a000000/0xfffffffffffffffe,goto_table:43
 cookie=0x8220000, duration=59749.894s, table=43, n_packets=39, n_bytes=9354, priority=0 actions=goto_table:48
 cookie=0x8500000, duration=59750.122s, table=48, n_packets=39, n_bytes=9354, priority=0 actions=resubmit(,49),resubmit(,50)
 cookie=0x805138a, duration=2086.774s, table=50, n_packets=39, n_bytes=9354, priority=20,metadata=0x2138a000000/0xfffffffff000000,dl_src=fa:16:3e:31:43:aa actions=goto_table:51
 cookie=0x8030000, duration=59749.894s, table=51, n_packets=39, n_bytes=9354, priority=0 actions=goto_table:52
 cookie=0x870138a, duration=2086.774s, table=52, n_packets=39, n_bytes=9354, priority=5,metadata=0x138a000000/0xffff000001 actions=write_actions(group:210004)
 cookie=0x8800002, duration=2086.775s, table=55, n_packets=39, n_bytes=9354, priority=10,tun_id=0x2,metadata=0x20000000000/0xfffff0000000000 actions=drop
[root@overcloud-computesriov-0 ~]# ovs-ofctl dump-group-stats -OOpenflow13 br-int
OFPST_GROUP reply (OF1.3) (xid=0x4):
 group_id=210004,duration=2439.335s,ref_count=1,packet_count=76,byte_count=22008,bucket0:packet_count=76,byte_count=22008
 group_id=5000,duration=60102.110s,ref_count=1,packet_count=0,byte_count=0,bucket0:packet_count=0,byte_count=0,bucket1:packet_count=0,byte_count=0,bucket2:packet_count=0,byte_count=0
 group_id=210003,duration=2439.634s,ref_count=1,packet_count=76,byte_count=22008,bucket0:packet_count=76,byte_count=22008
[root@overcloud-computesriov-0 ~]# ovs-ofctl dump-groups -OOpenflow13 br-int
OFPST_GROUP_DESC reply (OF1.3) (xid=0x2):
 group_id=210004,type=all,bucket=actions=group:210003
 group_id=5000,type=all,bucket=actions=CONTROLLER:65535,bucket=actions=resubmit(,48),bucket=actions=resubmit(,81)
 group_id=210003,type=all,bucket=actions=set_field:0x2->tun_id,resubmit(,55)


There might be several issue here not sure it is just openvswitch. it maybe related to opendaylight as well.

This is caused by a rule translation issue. Patch ports are internally implemented using the clone() action. However, clone(write_action(..)) has issues regarding the action_set. OVS saves off the action_set before the clone, then restores it afterwards. Unfortunately because of this, it ignores action_sets defined inside the clone.

I'm working on a fix.

Posted upstream:

  https://mail.openvswitch.org/pipermail/ovs-dev/2018-March/344865.html

Applied upstream:

  14ebc6c199a7 ("tests/ofproto-dpif: New test for action_set after traversing patch port")
  118b21d93f55 ("ofproto-dpif-xlate: translate action_set in clone action")

It has also been backported to branch-2.9.

can we get new openvswitch rpm with this fix that we can test it?

(In reply to Moshe Levi from comment #12)
> can we get new openvswitch rpm with this fix that we can test it?

I'm working on it now. When it's ready I'll update this BZ's "fixed in version" field. After which Tim can get the RPM for you.

Hi Tim,

It seems the testing configuration is a little complex. I'm a newbie for testing openvswitch. Can you give me a detail testing method step by step and a topological graph? Or can you help to verify this issue when new version is ready?

Regards,
Liang Li

Hi Liang,
I believe you can just setup a couple switches like this on your system:

eth0   +-----------+          +-----------+
       |  br-ex    |          |  br-int   |
+------+           +----------+           |
       +-----------+          +-------+---+
                                      |
                                      |
                                      |
                                      |
                                  +---+---+
                                  |       |
                                  | VM    |
                                  |       |
                                  +-------+

br-ex can just be a normal flow switch with an interface on it to originate traffic, and a patch port to br-int.  On br-int add a group that sends the packet out interface towards the VM.  Then add a flow to br-int to match on some type of traffic and action is send to the group you created.

Initiate traffic from eth0 that should match the flow you added to br-int.  You should see packets match your flow rule, and then group stats for the group you added show increase.  Finally, packets that hit that group should be sent out the port to your VM, so check the VM to ensure those packets are received.

Hi Tim,

I can't reproduce this issue using below testing steps, are there something wrong in my steps:

1.add ovs bridge:
#ovs-vsctl add-br ovsbr0

2.add vm to ovsbr0
# ovs-vsctl add-port ovsbr0 vnet1

3.create a normal bridge br0, add a physical port to br0
supports-priv-flags: yes
# ip link add name br0 type bridge
# ip link set ens2f0 master br0
# ip link set br0 up

4.add br0 to ovsbr0
# ovs-vsctl add-port ovsbr0 br0
# ovs-vsctl show
6e553058-b6dd-46e4-a97c-c913c265b9e0
    Bridge "ovsbr0"
        Port "vnet1"
            Interface "vnet1"
        Port "ovsbr0"
            Interface "ovsbr0"
                type: internal
        Port "br0"
            Interface "br0"
    ovs_version: "2.9.0"

5.now, ping from a remote system to vm succeeded

6.add flows on ovsbr0:
# ovs-ofctl del-flows ovsbr0
# ovs-ofctl add-group -O OpenFlow11 ovsbr0 
"group_id=3,type=select,bucket=output:3" //3 is vnet1
# ovs-ofctl add-flow ovsbr0 "icmp actions=group:3"
# ovs-ofctl add-flow ovsbr0 "dl_type=0x0806 actions=group:3"

7.I can saw, the arp packets reach the group, and the arp packets reach vm:
# ovs-ofctl dump-flows ovsbr0
 cookie=0x0, duration=1317.404s, table=0, n_packets=100, n_bytes=9800, icmp actions=group:3
 cookie=0x0, duration=1311.263s, table=0, n_packets=27962, n_bytes=1660030, arp actions=group:3
# ovs-ofctl -O OpenFlow13 dump-group-stats ovsbr0
OFPST_GROUP reply (OF1.3) (xid=0x4):
 group_id=3,duration=797.277s,ref_count=2,packet_count=11959,byte_count=710948,bucket0:packet_count=11959,byte_count=710948

So, if this bz occur, the arp packet should not reach the group, right? What's wrong in my testing steps?

#OVS version
[root@hp-dl380pg8-15 topo]# ovs-vsctl -V
ovs-vsctl (Open vSwitch) 2.9.0
DB Schema 7.15.1
[root@hp-dl380pg8-15 topo]# rpm -qa openvswitch
openvswitch-2.9.0-3.el7fdb.x86_64


Thanks,
Liang Li

(In reply to LiLiang from comment #16)
> Hi Tim,
> 
> I can't reproduce this issue using below testing steps, are there something
> wrong in my steps:
> 
> 1.add ovs bridge:
> #ovs-vsctl add-br ovsbr0
> 
> 2.add vm to ovsbr0
> # ovs-vsctl add-port ovsbr0 vnet1
> 
> 3.create a normal bridge br0, add a physical port to br0
> supports-priv-flags: yes
> # ip link add name br0 type bridge
> # ip link set ens2f0 master br0
> # ip link set br0 up

ovsbr0 _and_ br0 must be OVS bridges (not native). Furthermore the bridges must be connected via OVS port type=patch.

I connect the bridges via type=patch, but still can't reproduce this issue:

[root@hp-dl380pg8-15 topo]# ovs-vsctl show
6e553058-b6dd-46e4-a97c-c913c265b9e0
    Bridge "ovsbr0"
        Port "patch1"
            Interface "patch1"
                type: patch
                options: {peer="patch2"}
        Port "vnet1"
            Interface "vnet1"       //vm virtual port
        Port "ovsbr0"
            Interface "ovsbr0"
                type: internal
    Bridge "ovsbr1"
        Port "patch2"
            Interface "patch2"
                type: patch
                options: {peer="patch1"}
        Port "ovsbr1"
            Interface "ovsbr1"
                type: internal
        Port "ens2f0"               //physical port
            Interface "ens2f0"
    ovs_version: "2.9.0"

the arp packet reach the group:
[root@hp-dl380pg8-15 topo]# ovs-ofctl dump-flows ovsbr0
 cookie=0x0, duration=636.849s, table=0, n_packets=1025, n_bytes=52930, arp actions=group:1

[root@hp-dl380pg8-15 topo]# ovs-ofctl -O OpenFlow11 dump-group-stats ovsbr0
OFPST_GROUP reply (OF1.1) (xid=0x4):
 group_id=1,ref_count=1,packet_count=1085,byte_count=56026,bucket0:packet_count=1085,byte_count=56026

Tim/Moshe/others,

Please use build openvswitch-2.9.0-9.el7fdn to verify. I was made aware of a spec file issue that caused some patches to not be applied to the unpacked sources.

(In reply to LiLiang from comment #18)
> I connect the bridges via type=patch, but still can't reproduce this issue:
> 
> [root@hp-dl380pg8-15 topo]# ovs-vsctl show
> 6e553058-b6dd-46e4-a97c-c913c265b9e0
>     Bridge "ovsbr0"
>         Port "patch1"
>             Interface "patch1"
>                 type: patch
>                 options: {peer="patch2"}
>         Port "vnet1"
>             Interface "vnet1"       //vm virtual port
>         Port "ovsbr0"
>             Interface "ovsbr0"
>                 type: internal
>     Bridge "ovsbr1"
>         Port "patch2"
>             Interface "patch2"
>                 type: patch
>                 options: {peer="patch1"}
>         Port "ovsbr1"
>             Interface "ovsbr1"
>                 type: internal
>         Port "ens2f0"               //physical port
>             Interface "ens2f0"
>     ovs_version: "2.9.0"
> 
> the arp packet reach the group:
> [root@hp-dl380pg8-15 topo]# ovs-ofctl dump-flows ovsbr0
>  cookie=0x0, duration=636.849s, table=0, n_packets=1025, n_bytes=52930, arp
> actions=group:1
> 
> [root@hp-dl380pg8-15 topo]# ovs-ofctl -O OpenFlow11 dump-group-stats ovsbr0
> OFPST_GROUP reply (OF1.1) (xid=0x4):
>  group_id=1,ref_count=1,packet_count=1085,byte_count=56026,bucket0:
> packet_count=1085,byte_count=56026

You must use write_actions() in the secondary/internal bridge. The packet must start at the first bridge, traverse the patch port into the secondary bridge, then match a flow that has actions=write_actions(...)

ingress           egress
  |                |
[br1] --patch-- [br2]
                  ^ actions=write_actions(..., output:1)

(In reply to Eric Garver from comment #19)
> Tim/Moshe/others,
> 
> Please use build openvswitch-2.9.0-9.el7fdn to verify. I was made aware of a
> spec file issue that caused some patches to not be applied to the unpacked
> sources.

Tim,
Can you send me the new package?

I added a write_actions(group:3) to flow, but i saw the flow action is drop not write_actions() in output of "ovs-ofctl dump-flows ovsbr0"

[root@hp-dl388g8-22 topo]# ovs-vsctl show
3fa3f89e-a778-4269-81d0-08d734f587f6
    Bridge "ovsbr0"
        Port "patch0"
            Interface "patch0"
                type: patch
                options: {peer="patch1"}
        Port "vnet1"
            Interface "vnet1"
        Port "ovsbr0"
            Interface "ovsbr0"
                type: internal
    Bridge "ovsbr1"
        Port "patch1"
            Interface "patch1"
                type: patch
                options: {peer="patch0"}
        Port "ens5f0"
            Interface "ens5f0"
        Port "ovsbr1"
            Interface "ovsbr1"
                type: internal
    ovs_version: "2.9.0"

[root@hp-dl388g8-22 topo]# ovs-ofctl del-flows ovsbr0
[root@hp-dl388g8-22 topo]# ovs-ofctl add-flow ovsbr0 "dl_src=00:00:00:00:00:00/00:00:00:00:00:00 actions=goto_table(50)"
[root@hp-dl388g8-22 topo]# ovs-ofctl add-flow ovsbr0 "table=50 dl_src=00:00:00:00:00:00/00:00:00:00:00:00 actions=write_actions(group:3)"
[root@hp-dl388g8-22 topo]# ovs-ofctl -O OpenFlow11 add-group ovsbr0 "group_id=3,type=all,bucket=actions=output=3"

[root@hp-dl388g8-22 topo]# ovs-ofctl -O OpenFlow13 dump-groups ovsbr0
OFPST_GROUP_DESC reply (OF1.3) (xid=0x2):
 group_id=3,type=all,bucket=actions=output:vnet1
[root@hp-dl388g8-22 topo]# ovs-ofctl -O OpenFlow13 dump-group-stats ovsbr0
OFPST_GROUP reply (OF1.3) (xid=0x4):
 group_id=3,duration=1188.962s,ref_count=0,packet_count=0,byte_count=0,bucket0:packet_count=0,byte_count=0

[root@hp-dl388g8-22 topo]# ovs-ofctl dump-flows ovsbr0
 cookie=0x0, duration=182.842s, table=0, n_packets=684, n_bytes=113050, actions=resubmit(,50)
 cookie=0x0, duration=133.865s, table=50, n_packets=549, n_bytes=102120, actions=drop  //this should be actions=write_actions(group:3) , why drop???

(In reply to LiLiang from comment #22)
> [root@hp-dl388g8-22 topo]# ovs-ofctl dump-flows ovsbr0
>  cookie=0x0, duration=182.842s, table=0, n_packets=684, n_bytes=113050,
> actions=resubmit(,50)
>  cookie=0x0, duration=133.865s, table=50, n_packets=549, n_bytes=102120,
> actions=drop  //this should be actions=write_actions(group:3) , why drop???

Use ovs-ofctl option "-O OpenFlow11"

(In reply to Moshe Levi from comment #21)
> (In reply to Eric Garver from comment #19)
> > Tim/Moshe/others,
> > 
> > Please use build openvswitch-2.9.0-9.el7fdn to verify. I was made aware of a
> > spec file issue that caused some patches to not be applied to the unpacked
> > sources.
> 
> Tim,
> Can you send me the new package?

Thanks Tim & Eric, the fix seem to be working. we will do more testing next week

reproduced this issue, if any wrong in my testing steps, please tell me.thanks.

[root@dell-per730-16 topo]# ovs-vsctl show
b7940ad7-734e-4855-8f66-3197f3fbb543
    Bridge br-ex
        Port "patch1"
            Interface "patch1"
                type: patch
                options: {peer="patch0"}
        Port br-ex
            Interface br-ex
                type: internal
        Port "p6p1"
            Interface "p6p1"
    Bridge "ovsbr0"
        Port "patch0"
            Interface "patch0"
                type: patch
                options: {peer="patch1"}
        Port "vnet1"
            Interface "vnet1"
        Port "ovsbr0"
            Interface "ovsbr0"
                type: internal
    ovs_version: "2.9.0"


[root@dell-per730-16 topo]# ovs-ofctl del-flows ovsbr0
[root@dell-per730-16 topo]# ovs-ofctl add-flow ovsbr0 "dl_src=00:00:00:00:00:00/00:00:00:00:00:00 actions=goto_table(50)" -O OpenFlow11
[root@dell-per730-16 topo]# ovs-ofctl -O OpenFlow11 add-group ovsbr0 "group_id=3,type=all,bucket=actions=output=3"
[root@dell-per730-16 topo]# ovs-ofctl add-flow ovsbr0 "table=50 dl_src=00:00:00:00:00:00/00:00:00:00:00:00 actions=write_actions(group:3)" -O OpenFlow11

[root@dell-per730-16 topo]#  ovs-ofctl dump-flows ovsbr0 -O OpenFlow11
 cookie=0x0, duration=145.627s, table=0, n_packets=268, n_bytes=27465, actions=goto_table:50
 cookie=0x0, duration=5.424s, table=50, n_packets=7, n_bytes=1031, actions=write_actions(group:3)

[root@dell-per730-16 topo]# ovs-ofctl -O OpenFlow11 dump-group-stats ovsbr0
OFPST_GROUP reply (OF1.1) (xid=0x4):
 group_id=3,ref_count=1,packet_count=0,byte_count=0,bucket0:packet_count=0,byte_count=0

the packet didn't reach group and vm.

(In reply to LiLiang from comment #25)
> reproduced this issue, if any wrong in my testing steps, please tell
> me.thanks.

This looks correct. Now try it again with build openvswitch-2.9.0-9.el7fdn.

(In reply to Eric Garver from comment #26)
> (In reply to LiLiang from comment #25)
> > reproduced this issue, if any wrong in my testing steps, please tell
> > me.thanks.
> 
> This looks correct. Now try it again with build openvswitch-2.9.0-9.el7fdn.

Can't reproduce this with openvswitch-2.9.0-9.el7fdn.

The packet can reach group and vm:

[root@hp-dl380pg8-15 topo]# ovs-ofctl -O OpenFlow11 dump-group-stats ovsbr0
OFPST_GROUP reply (OF1.1) (xid=0x4):
group_id=3,ref_count=1,packet_count=227,byte_count=14480,bucket0:packet_count=227,byte_count=14480

[root@hp-dl380pg8-15 topo]# virsh console g1
Connected to domain g1
Escape character is ^]

[root@localhost ~]# 
[root@localhost ~]# tcpdump -i eth1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
22:05:10.060348 ARP, Request who-has localhost.localdomain tell 200.1.1.2, length 46
22:05:10.060358 ARP, Reply localhost.localdomain is-at 00:de:ad:78:01:02 (oui Unknown), length 28
22:05:10.767385 ARP, Request who-has 20.0.0.25 tell 20.0.0.7, length 38
22:05:10.882381 ARP, Request who-has 20.0.0.25 tell 20.0.0.2, length 38
22:05:10.923058 ARP, Request who-has 20.0.0.26 tell 20.0.0.2, length 38

(In reply to LiLiang from comment #27)
> (In reply to Eric Garver from comment #26)
> > (In reply to LiLiang from comment #25)
> > > reproduced this issue, if any wrong in my testing steps, please tell
> > > me.thanks.
> > 
> > This looks correct. Now try it again with build openvswitch-2.9.0-9.el7fdn.
> 
> Can't reproduce this with openvswitch-2.9.0-9.el7fdn.

Great. So will you mark this VERFIED?

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:1267