Bug 1057978 - Simple bridge setup fails
Summary: Simple bridge setup fails
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 20
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-26 10:21 UTC by Tim Jones
Modified: 2014-07-24 17:31 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-07-24 17:31:32 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
NetworkManager debug output (28.66 KB, text/plain)
2014-01-26 10:33 UTC, Tim Jones
no flags Details

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.


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