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.
Reviewed: https:/ /review. openstack. org/325392 /git.openstack. org/cgit/ openstack/ neutron/ commit/ ?id=09ff5e5ebd2 d608c7ac44ccab1 6d8e108d7181bc
Committed: https:/
Submitter: Jenkins
Branch: master
commit 09ff5e5ebd2d608 c7ac44ccab16d8e 108d7181bc
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]) dump-flows <br>) and leads to a network loop on br-tun when
which adds hidden OpenFlow rules (only visible by issuing ovs-appctl
bridge/
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: I792a89d37b5d53 19cc027835f6a1b fcbe7297ffb
Closes-Bug: #1588393