Bug 1072378 - Failure to configure OVS (openvswitch) interfaces at boot / failed network restarts
Summary: Failure to configure OVS (openvswitch) interfaces at boot / failed network re...
Keywords:
Status: CLOSED NOTABUG
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-03-04 13:27 UTC by Florian Otel
Modified: 2023-09-14 02:04 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-03-24 16:58:10 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1072392 0 unspecified CLOSED IP Address is not assigned to an OVS Bridge by if-cfg scripts 2021-02-22 00:41:40 UTC

Internal Links: 1072392

Description Florian Otel 2014-03-04 13:27:54 UTC
Description of problem:

The startup scripts (for network.service and/or openvswitch.service) fail to properly configure an OVS (openvswitch) bridge internal interface at boot time. 

Attempting to restart the network service after the boot results in an error

Version-Release number of selected component (if applicable):

- Fedora 20 (latest updated 2014-03-01)
- openvswitch as per Fedora20 packages (openvswitch-2.0.0-4.fc20)
- SElinux and firewalld.service are disabled

How reproducible:
Consistently

Steps to Reproduce:

Following the instructions at http://git.openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob;f=rhel/README.RHEL;h=cb6ab88d5b44e4c57008c0f590543f19d1d22c3b;hb=HEAD 

1. create "/etc/sysconfig/network-scripts/ifcfg-br99" with the following content:
DEVICE=br99
ONBOOT=yes
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
IPADDR=192.168.254.33
NETMASK=192.168.254.0
HOTPLUG=no

2.Reboot 

Actual results:
- The OVS bridge is NOT created at boot <-> no configured interface.
- Creating that bridge -- "sudo ovs-vsctl add-br br99"  -- and then rebooting _still_ does not configure the bridge internal interface

- "sudo systemctl restart network.service" still fails to configure the interface (even if the OVS bridge is created first) 

Expected results:
- Bridge "br99" created at boot and the bridge internal interface configured accordingly

Additional info:

Comment 1 Flavio Leitner 2014-03-11 18:13:19 UTC
That is happening because network.service is not enabled by default.
Therefore it will fail to configure the OVS bridge at every boot unless you enable it manually.

Can you enable network.service and see if OVS works after that?
The systemd command would be:
# systemctl enable network.service

It will spill some messages out, but this should be ok:
# systemctl is-enabled network.service
network.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig network --level=5
enabled

Or you can use chkconfig:
# chkconfig network on 
# systemctl is-enabled network.service
network.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig network --level=5
enabled
# 
 

Thanks!

Comment 2 Flavio Leitner 2014-03-11 18:14:41 UTC
*** Bug 1072392 has been marked as a duplicate of this bug. ***

Comment 3 Dave Tucker 2014-03-12 00:03:12 UTC
In my case (1072392), it should be noted that network.service was actually enabled and while the bridge was created, no IP address was assigned. 

I used the same configuration in Fedora 19, openvswitch-2.0.0-4.fc19 and everything works as expected.

Comment 4 Flavio Leitner 2014-03-12 03:35:04 UTC
(In reply to Dave Tucker from comment #3)
> In my case (1072392), it should be noted that network.service was actually
> enabled and while the bridge was created, no IP address was assigned. 

Ok, could you do another test? try to ifdown the ovsbr before reboot and see if it works.  The command 'ifdown <bridge>' will delete the bridge from ovsdb which will allow the interface to come up correctly with static IP address at boot time. What I just said is a known bug, see bz#1072574

> I used the same configuration in Fedora 19, openvswitch-2.0.0-4.fc19 and
> everything works as expected.

Maybe Fedora 19 is stopping the network service before stopping openvswitch, so there is no bridge in the ovsdb when the system is booting again.

Thanks!

Comment 5 Dave Tucker 2014-03-12 18:55:38 UTC
(In reply to Flavio Leitner from comment #4)

> Ok, could you do another test? try to ifdown the ovsbr before reboot and see
> if it works.  The command 'ifdown <bridge>' will delete the bridge from
> ovsdb which will allow the interface to come up correctly with static IP
> address at boot time. What I just said is a known bug, see bz#1072574

That fixed it for one reboot. When rebooting a second time, the IP address disappears again.

The fix in bz#1072574 works for me though.

Comment 6 Flavio Leitner 2014-03-12 19:00:31 UTC
(In reply to Dave Tucker from comment #5)
> > Ok, could you do another test? try to ifdown the ovsbr before reboot and see
> > if it works.  The command 'ifdown <bridge>' will delete the bridge from
> > ovsdb which will allow the interface to come up correctly with static IP
> > address at boot time. What I just said is a known bug, see bz#1072574
> 
> That fixed it for one reboot. When rebooting a second time, the IP address
> disappears again.

Yes, because the bridge is back into ovsdb, so you would have to run ifdown every time before rebooting. :-)

> The fix in bz#1072574 works for me though.
That's good. I believe that one is the final fix. So, I will re-open your case again and close as dup of that one instead.  Thanks for testing it!

Comment 7 Flavio Leitner 2014-03-12 19:04:16 UTC
Florian,

Could you tell me if enabling the network.service as described in comment#1 helps?

Comment 8 Flavio Leitner 2014-03-24 16:58:10 UTC
I think comment#2 address the issue, so I am closing this as NotABug.
Feel free to re-open if needed.
Thanks

Comment 9 Red Hat Bugzilla 2023-09-14 02:04:28 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days


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