Bug 1051593 - "network" script does not correctly bring up ovs bridge devices
Summary: "network" script does not correctly bring up ovs bridge devices
Keywords:
Status: CLOSED DUPLICATE of bug 1072574
Alias: None
Product: Fedora
Classification: Fedora
Component: openvswitch
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Flavio Leitner
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-10 16:33 UTC by Lars Kellogg-Stedman
Modified: 2014-07-22 17:55 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-07-22 17:55:36 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Lars Kellogg-Stedman 2014-01-10 16:33:28 UTC
The "network" service on F20 does not appear to correctly bring up OVS bridge devices.


If I start with the F20 cloud image and install OpenVswitch:

    yum install openvswitch

And enable openvswitch and start:

    systemctl enable openvswitch
    systemctl start openvswitch 

And verify that the "network" service is enabled:

    chkconfig network on

And that NetworkManager is *not* installed:

    rpm -q NetworkManager
    package NetworkManager is not installed

And create a bridge device:

    ovs-vsctl add-br br0

And add an interface configuration file that looks like this:

    DEVICE=br0
    DEVICETYPE=ovs
    TYPE=OVSBridge
    BOOTPROTO=static
    IPADDR=172.24.4.225
    NETMASK=255.255.255.240
    ONBOOT=yes

And reboot, I end up with:

    # ip addr show dev br0
    4: br0: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
        link/ether ce:ac:68:75:a2:4d brd ff:ff:ff:ff:ff:ff
        inet6 fe80::e8ec:8aff:fe03:dd51/64 scope link
           valid_lft forever preferred_lft forever

If I run:

    # ifdown br0
    # ifup br0

I get what I expect:

    # ip addr show dev br0
    5: br0: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
        link/ether 0a:49:24:10:dc:4d brd ff:ff:ff:ff:ff:ff
        inet 172.24.4.225/28 brd 172.24.4.239 scope global br0
           valid_lft forever preferred_lft forever
        inet6 fe80::cc6c:9cff:fef1:d32a/64 scope link
           valid_lft forever preferred_lft forever

This is hitting people trying to run RDO on top of Fedora 20, since the bridge device configured for external connectivity does not get set up correctly when the system boots.

Comment 1 Boris Derzhavets 2014-01-26 05:16:55 UTC
I have two phisical nodes Cluster "Controller + Compute + Neutron GRE + Gluster backend for Cinder on ext4 ( due to known bug not "xfs") "  been setup per:-

http://kashyapc.fedorapeople.org/virt/openstack/neutron-configs-GRE-OVS-two-node.txt && http://kashyapc.fedorapeople.org/virt/openstack/Two-node-Havana-setup.txt

Manual Setup 

- Controller node: Nova, Keystone, Cinder, Glance, Neutron (using Open vSwitch plugin and GRE tunneling )

- Compute node: Nova (nova-compute), Neutron (openvswitch-agent)

dwf02.localdomain   -  Controller (192.168.1.127)
dwf01.localdomain   -  Compute    (192.168.1.137)

On controller :-

$ cat /etc/rc.d/rc.local
#!/bin/sh
ifdown br-ex ;
ifup br-ex ;
service network restart ;
exit 0

To get properly working OVS bridge be-ex & OVS port p37p1 :-

[root@dfw02 ~(keystone_admin)]$ ovs-vsctl show
7d78d536-3612-416e-bce6-24605088212f
    Bridge br-int
        Port br-int
            Interface br-int
                type: internal
        Port patch-tun
            Interface patch-tun
                type: patch
                options: {peer=patch-int}
        Port "tapf933e768-42"
            tag: 1
            Interface "tapf933e768-42"
        Port "tap40dd712c-e4"
            tag: 1
            Interface "tap40dd712c-e4"
    Bridge br-ex
        Port "p37p1"
            Interface "p37p1"
        Port br-ex
            Interface br-ex
                type: internal
        Port "tap54e34740-87"
            Interface "tap54e34740-87"
    Bridge br-tun
        Port br-tun
            Interface br-tun
                type: internal
        Port "gre-2"
            Interface "gre-2"
                type: gre
                options: {in_key=flow, local_ip="192.168.1.127", out_key=flow, remote_ip="192.168.1.137"}
        Port patch-int
            Interface patch-int
                type: patch
                options: {peer=patch-tun}
    ovs_version: "2.0.0"

Comment 2 Flavio Leitner 2014-07-16 21:08:06 UTC
This looks like to be a dup of bz#1072574.
Could you upgrade the openvswitch rpm package accordingly?

fbl

Comment 3 Lars Kellogg-Stedman 2014-07-16 21:29:51 UTC
For the record, I'm including my email to the ovs-discuss mailing list here:

It turns out this was due to the following logic in ifup-ovs:

  if check_device_down "${DEVICE}"; then
          ovs-vsctl -t ${TIMEOUT} -- --may-exist add-br "$DEVICE" $OVS_OPTIO
          ${OVS_EXTRA+-- $OVS_EXTRA} \
          ${STP+-- set bridge "$DEVICE" stp_enable="${STP}"}
  else
          OVSBRIDGECONFIGURED="yes"
  fi

The version of openvswitch currently included in Fedora automatically sets interfaces "up" at boot.  This means that the call to check_device_down was always returning false, setting OVSBRIDGECONFIGURED=yes, so the call to ifup-eth later in the script never happens:

  # When dhcp is not enabled, it is possible that someone may want
  # a standalone bridge (i.e it may not have any ports). Configure it.
  if [ "${OVSBOOTPROTO}" != "dhcp" ] && [ -z "${OVSINTF}" ] && \
          [ "${OVSBRIDGECONFIGURED}" != "yes" ]; then
          ${OTHERSCRIPT} ${CONFIG}
  fi

This is fixed upstream in:

  http://git.openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=commitdiff;h=1839c35676b5c3a2a70e83477a6ce3d3c7d0d245

And appears be addressed by the Fedora package generated in response to:

  https://bugzilla.redhat.com/show_bug.cgi?id=1072574

Comment 4 Lukáš Nykrýn 2014-07-22 13:37:21 UTC
If I did not missed something, this is bug for ifup-ovs which is in openvswitch package.

Comment 5 Flavio Leitner 2014-07-22 17:55:36 UTC

*** This bug has been marked as a duplicate of bug 1072574 ***


Note You need to log in before you can comment on or make changes to this bug.