Bug 1057978

Summary: Simple bridge setup fails
Product: [Fedora] Fedora Reporter: Tim Jones <tim>
Component: NetworkManagerAssignee: Dan Williams <dcbw>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: awilliam, chkr, dcbw, jklimes, matthew.hirsch, sven, tim
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-07-24 17:31:32 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
NetworkManager debug output none

Description Tim Jones 2014-01-26 10:21:15 UTC 
Setting up a simple bridge with a single physical interface always fails. This is a common issue at my work too (where we're lucky enough to all use Fedora :), where we must disable NetworkManager to enable us to set up bridges.

Version: NetworkManager-0.9.9.0-26.git20131003.fc20.x86_64

This is always reproducible. I have a single physical interface, em1. I want a bridge, br0, initially bridging em1 only. This use is used for when, sometimes numerous, libvirt/vbox VMs are started they are added as necessary to this same bridge allowing them to be accessed directly via the physical network.

Steps to Reproduce:
1. In nm-connection-editor, add a bridge with DHCP enabled.
2. Add the physical IF to the bridge.
3. Save it.

Actual results:
The bridge is created, but the physical IF is never added to the bridge itself and so DHCP for the bridge can never work.

Expected results:
The bridge IF is created, the physical IF is added to the bridge IF, DHCP configures the bridge IF.

Additional info:

sysctl:
net.ipv4.ip_forward = 1
net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.lo.forwarding = 1
net.ipv4.conf.em1.forwarding = 1
net.ipv4.conf.br0.forwarding = 1

root@dog /etc/sysconfig/network-scripts # cat ifcfg-br0em1 
HWADDR=00:1A:A0:B3:9A:FD
TYPE=Ethernet
NAME=br0em1
UUID=ec58798c-27ed-4321-a92a-257f98ec8c70
ONBOOT=no
USERS=tjones
BRIDGE=c1677c66-542c-45ad-82a4-2723749ac37f

root@dog /etc/sysconfig/network-scripts # cat ifcfg-br0
DEVICE=br0
STP=yes
BRIDGING_OPTS=priority=128
TYPE=Bridge
BOOTPROTO=dhcp
DEFROUTE=yes
PEERDNS=yes
PEERROUTES=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
IPV6_FAILURE_FATAL=no
NAME=br0
UUID=c1677c66-542c-45ad-82a4-2723749ac37f
ONBOOT=yes
Comment 1 Tim Jones 2014-01-26 10:33:30 UTC 
Created attachment 855651 [details]
NetworkManager debug output

I've attached the output from running:

/usr/sbin/NetworkManager --no-daemon -d --log-level=DEBUG > ~/nm.log 2>&1
Comment 2 Jirka Klimes 2014-05-27 16:43:47 UTC 
Did you activate the bridge profiles? You can do it via GUI or nmcli.
It should be sufficient to call:
$ nmcli con up "br0em1"

You have ONBOOT=no in ifcfg-br0em1, so it is not automatically started after boot.
Comment 3 Tim Jones 2014-05-30 15:22:26 UTC 
Hi, yes, they were all activated at the time I entered this report.

But, I've recently retried (after using old style networking scripts) and it's looking like it's working with the current versions of network manager, etc., even over reboots although this wasn't the issue originally.

These are my current config files:

/etc/sysconfig/network-scripts # cat ifcfg-br0
DEVICE=br0
STP=yes
BRIDGING_OPTS=priority=128
TYPE=Bridge
BOOTPROTO=dhcp
DNS1=127.0.0.1
DEFROUTE=yes
PEERDNS=no
PEERROUTES=yes
DHCP_CLIENT_ID=dog.mr-dog.net
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
DNS2=::1
DOMAIN=dog.mr-dog.net
IPV6_DEFROUTE=yes
IPV6_PEERDNS=no
IPV6_PEERROUTES=yes
IPV6_FAILURE_FATAL=no
NAME=br0
UUID=4bec9d65-834b-46e3-a76c-ff4cd49ef5b0
ONBOOT=yes
ZONE=dmz

/etc/sysconfig/network-scripts # cat ifcfg-br0em1 
HWADDR=00:1A:A0:B3:9A:FD
TYPE=Ethernet
NAME=br0em1
UUID=26fa6fa1-d1a9-4af6-9610-9b528813783b
ONBOOT=yes
ZONE=dmz
BRIDGE=4bec9d65-834b-46e3-a76c-ff4cd49ef5b0

I guess this can be considered fix now :)
Comment 4 Adam Williamson 2014-07-24 17:31:32 UTC 
since the OP can't reproduce, let's close this, I don't think it's helping anyone staying open.