5

Whenever I start my computer I need to restart my network service (using service network restart) to enable my bridge (br0). How do I get Linux to do this when I start up my computer so I don't have to do it manually?

The network is starting the other 2 ethernet adapters are live when I boot up.

  • How are you "restarting the network service" to enable the bridge? It is likely there is something missing or out-of-order in your startup scripts, if we know what you do to get to working after startup we might be able to tell you the best things to check/change. – David Spillett Dec 4 '09 at 14:42
  • I'm restarting the network by executing "service network restart" the network script some how knows to start the bridge adapter when linux is running, but not on boot. – Peter Turner Dec 4 '09 at 14:52
  • Hey Pete, if you get a second could you accept my answer? I think it's the best option you're gonna find for your problem. Thanks. – slm Aug 16 '12 at 2:44
4

This seems to be an issue with the order that the interfaces are being brought up in. Looking in the /etc/init.d/network init script there is this bit that constructs all the interfaces:

# find all the interfaces besides loopback.
# ignore aliases, alternative configurations, and editor backup files
interfaces=$(ls ifcfg* | \
    LANG=C sed -e "$__sed_discard_ignored_files" \
           -e '/\(ifcfg-lo\|:\|ifcfg-.*-range\)/d' \
           -e '/ifcfg-[A-Za-z0-9\._-]\+$/ { s/^ifcfg-//g;s/[0-9]/ &/}' | \
    LANG=C sort -k 1,1 -k 2n | \
    LANG=C sed 's/ //')

The output of this command produces this list:

br0
eth0

I haven't found a solution to this other than to include a ifup br0 in the /etc/rc.local script to manually force the br0 up AFTER the eth0 device has been brought up.

EDIT

I just created a /etc/sysconfig/network-scripts/ifcfg-br0 like this and upon rebooting had br0 start AFTER eth0!

# ifcfg-br0
DEVICE=br0
TYPE=Bridge
BOOTPROTO=static
ONBOOT=yes
DELAY=0
NM_CONTROLLED=no
STP=off
IPADDR=192.168.1.200
GATEWAY=192.168.1.1
NETMASK=255.255.255.0

Example /etc/sysconfig/network-scripts/ifcfg-eth0

# ifcfg-eth0
DEVICE=eth0
#BOOTPROTO=dhcp
HWADDR=BC:AE:C5:34:C9:E8
ONBOOT=yes
BRIDGE=br0
NM_CONTROLLED=no

With the files like this I now see the network devices coming up like this:

Bringing up interface eth0           [  OK  ]
Bringing up interface br0            [  OK  ]
1

Check to make sure the "network" service is enabled. you can use the GUI Services (system-config-services) or chkconfig if you are familiar with that. This solved the same issue for myself.

1

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:

ifdown enp6s0f0
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
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: on (auto)
        Supports Wake-on: pumbg
        Wake-on: d
        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.

Troubleshooting notes:

I suspect that ommiting the line:

TYPE=Bridge

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:

system_u:object_r:net_conf_t:s0

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.

0

I have the same problem but i find myself wrote the name of bridge interface /etc/sysconfig/network-scripts/br0 instead of /etc/sysconfig/network-scripts/ifcfg-br0

I arrived to it when i open the "/etc/init.d/network" and find the script load only files start with "ifcfg-"

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.