I had this same issue on a physical box running Centos 7.3 x86_64 and was able to resolve it by first moving the physical adapter to a different PCI-X slot on the motherboard, and then doing all of the following:
Remove the bridge interface config file:
rm -f /etc/sysconfig/network-scripts/ifcfg-br0
Remove the slave interface config file:
rm -f /etc/sysconfig/network-scripts/ifcfg-enp6s0f0
Where enp6s0f0 was the original slave interface name, and was the only slave interface assigned to bridge br0
Make sure to completely remove the original bridge, ensuring that all traces of it are gone (brctl show) should not list the br0 bridge interface.
Shutdown the bridge:
ifconfig br0 down
Shutdown the slave:
ifconfig enp6s0f0 down
Stop the network service:
systemctl stop network.service
Manually remove the bridge if necessary: (In my case, it was.)
Before the bridge can be removed all slave interfaces must be removed from it. You can use the bridge control utility to remove them
brctl delif br0 enp6s0f0
Once all the slave interfaces have been removed, the bridge itself can be removed.
brctl delbr br0
Confirm that no remaining configuration files reference br0:
grep -i br0 /etc/sysconfig/network-scripts/ifcfg-*
Should return no results
In my case the new interface name based on moving the card up one slot is now enp5s0f0.
Start the interface, and then confirm with ethtool, or 'ip link' which should report that link is detected for the interface.
[root@phaser ~]# ifconfig enp5s0f0 up
[root@phaser ~]# ethtool enp5s0f0
Settings for enp5s0f0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Port: Twisted Pair
MDI-X: on (auto)
Supports Wake-on: pumbg
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
Use nmcli to create a new bridge.
nmcli will write the necessary interface configuration files in /etc/sysconfig/network-scripts/
Create the bridge interface:
nmcli conn add type bridge ifname br0 ip4 10.0.0.16/24 gw4 10.0.0.1
Add the slave interface to the bridge:
nmcli conn add type bridge-slave ifname enp5s0f0 master bridge-br0
Disable spanning tree protocol if the network already has a spanning tree master:
nmcli con modify bridge-br0 bridge.stp no
Ensure that the bridge is configured to start on boot with nmcli:
nmcli con mod br0 connection.autoconnect yes
At this point I can start, and stop the network service successfully, and on reboot, the bridge interface starts properly.
I suspect that ommiting the line:
from my original config file for br0 may have led to this issue.
I also suspect that not using nmcli and manually creating the bridge interface files also caused issues. This may be because NetworkManager is still attempting to manage the interface. This can be confirmed with:
nmcli dev status
This command will display a table that lists all network interfaces along with their STATE. If Network Manager is not controlling an interface, its STATE will be listed as unmanaged. Any other value indicates the interface is under Network Manager control.
If you do end up manually modifying an ifcfg file under /etc/sysconfig/network-scripts, make sure to inform network manager of the changes with a reload.
nmcli con reload
This will tell network manager to re-read all of the ifcfg files and recognize any changes.
I found the following post:
How do I prevent Network Manager from controlling an interface?
For those who don't want to use NetworkManager in RHEL / CENTOS 7.x
One other minor thing that i noticed during testing was that the selinux context on the original interface configuration files that I had manually created was not identical to the automatically generated configuration files.
ls -lZ showed that the automatically generated ifcfg- files had the following context:
Whereas the files I created had unconfined_u as the user.
I used chcon to set the user to system_u
chcon system_u:object_r:net_conf_t:s0 ifcfg-<filename>
Another observation is that when bringing the new bridge interface up, or down, systemd now properly reports that the interface is connected and disconnected. Before making these changes, when using my own self written configuration files, systemd seemed to have no awareness of the interface. It would show that the interface was configured but not connected. Despite ethtool reporting link detection.