Switching OpenFlow interface to 'native' causes network loop

[Ilya Chukhnakov]

* Description:
After switching openvswitch agent to the 'native' OpenFlow interface (of_interface=native) the public network and the tunnel networks are flooded with ARP packets (see [1] for the tcpdump sample).

* Environment:
 - DevStack stable/mitaka
 - 1 controller/compute and 2 compute nodes
 - configuration from [2]
 - ubuntu 14.04

* How to reproduce:
0. (WARNING) the following steps will flood the network, so it is recommended to use a virtual network as the provider network
1. Deploy DevStack with access to the provider network (see [2]; 1 controller + 2 compute nodes)
2. Set of_interface=native in the [ovs] section of /etc/neutron/plugins/ml2/ml2_conf.ini
3. restart l2 agents on all nodes
4. login to the default gateway and send a broadcast ARP request to the devstack's public network (arping -UD <gateway_ip>)

* Expected result:
normal network operation

* Actual result:
the public network and the tunnel network are flooded with ARP packets

[1] http://paste.openstack.org/show/507292/
[2] http://docs.openstack.org/developer/devstack/guides/neutron.html#devstack-configuration

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/325392

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/325392
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=09ff5e5ebd2d608c7ac44ccab16d8e108d7181bc
Submitter: Jenkins
Branch: master

commit 09ff5e5ebd2d608c7ac44ccab16d8e108d7181bc
Author: Ilya Chukhnakov <email address hidden>
Date: Fri Jun 3 18:57:15 2016 +0300

    Force "out-of-band" controller connection mode

    By default openvswitch uses "in-band" controller connection mode ([1])
    which adds hidden OpenFlow rules (only visible by issuing ovs-appctl
    bridge/dump-flows <br>) and leads to a network loop on br-tun when
    using native OpenFlow interface. As of now the OF controller is hosted
    locally with OVS which fits the "out-of-band" mode. If the remote OF
    controller is ever to be supported by openvswitch agent in the future,
    "In-Band Control" [1] should be taken into consideration for physical
    bridge only, but br-int and br-tun must be configured with the
    "out-of-band" controller connection mode.

    [1] https://github.com/openvswitch/ovs/blob/master/DESIGN.md

    Change-Id: I792a89d37b5d5319cc027835f6a1bfcbe7297ffb
    Closes-Bug: #1588393

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/mitaka
Review: https://review.openstack.org/325766

[IWAMOTO Toshihiro (iwamoto)]

Thanks for fixing the bug.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/325766
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=e5390891ac87ce031794a559acb6597517d63601
Submitter: Jenkins
Branch: stable/mitaka

commit e5390891ac87ce031794a559acb6597517d63601
Author: Ilya Chukhnakov <email address hidden>
Date: Fri Jun 3 18:57:15 2016 +0300

    Force "out-of-band" controller connection mode

    By default openvswitch uses "in-band" controller connection mode ([1])
    which adds hidden OpenFlow rules (only visible by issuing ovs-appctl
    bridge/dump-flows <br>) and leads to a network loop on br-tun when
    using native OpenFlow interface. As of now the OF controller is hosted
    locally with OVS which fits the "out-of-band" mode. If the remote OF
    controller is ever to be supported by openvswitch agent in the future,
    "In-Band Control" [1] should be taken into consideration for physical
    bridge only, but br-int and br-tun must be configured with the
    "out-of-band" controller connection mode.

    [1] https://github.com/openvswitch/ovs/blob/master/DESIGN.md

    Change-Id: I792a89d37b5d5319cc027835f6a1bfcbe7297ffb
    Closes-Bug: #1588393
    (cherry picked from commit 09ff5e5ebd2d608c7ac44ccab16d8e108d7181bc)

[Davanum Srinivas (DIMS) (dims-v)]

This issue was fixed in the openstack/neutron 8.1.2 release.

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/neutron 9.0.0.0b2 development milestone.