Persistently bridge traffic between two or more Ethernet interfaces (Red Hat)
|Red Hat-based distributions|
|Fedora (12, 13, 14, 15, 16)|
To persistently bridge traffic between two or more Ethernet interfaces on a Red Hat-based system
The method described here has five steps:
- Install the bridge utilities package.
- Choose a name for the bridge.
- Write a configuration script for the bridge.
- Write configuration scripts for the Ethernet interfaces.
- Start or restart the
Be warned that once an interface has been attached to a bridge it cannot be used for other purposes, and in particular, cannot be used as an endpoint for Internet Protocol traffic. A common mistake when administering a machine remotely via SSH is to incapacitate the network interface that the SSH connection is using. Before acting on these instructions you should ensure that you will still be able to control the machine after the bridge has been created.
Note that this method is not applicable to SUSE-based distributions. (Its configuration files have a similar format, but the procedure for defining bridges is entirely different.) Fedora 13 requires additional action to disable NetworkManager, as described below.
Bridging is performed by a kernel module, but a userspace package is needed to configure it. On Red Hat-based systems this can be found in the
yum install bridge-utils
Each bridge must be given a name. In this case the name
br0 will be used, however it is not necessary to follow any particular naming convention provided it does not clash with another network device.
A configuration script should now be written for the bridge and placed in the directory
/etc/sysconfig/network-scripts. If the bridge is named
br0 then the file containing the script should be named
ifcfg-br0. The format is an extension of that used for configuring ordinary network interfaces:
DEVICE=br0 TYPE=Bridge STP=on ONBOOT=yes BOOTPROTO=none NM_CONTROLLED=no
STP option specifies whether or not the Spanning Tree Protocol should be enabled. This is essential if there is any possibility of the bridge creating a loop in the network. It is safe in other cases, but it will increase the delay between a new link being added and it being able to pass traffic. For this reason you may want to leave STP disabled in simple cases (such as when bridging a set of virtual machines to a single physical interface).
ONBOOT option specifies whether or not the interface should be brought up automatically at boot time. Without this the bridge must be brought up manually using
none specifies that the bridge should not attempt to obtain an IP address using BOOTP or DHCP. Since it has not been given a static address either, it will not be bound to one. See below if an address is wanted.
NM_CONTROLLED option indicates that this network device should not be managed by NetworkManager. This is potentially needed for two reasons: to prevent NetworkManager from interfering with scripts that have been created manually, and because (at the time of writing) NetworkManager does not support bridging. If NetworkManager is not enabled then this option may be safely omitted, however there is no harm in including it as a precaution.
A configuration script is similarly needed for each of the Ethernet interfaces that is to be attached to the bridge. As above the scripts should be placed in the directory
/etc/sysconfig/network-scripts. For this example they should be named
DEVICE=eth0 HWADDR=02:00:00:00:00:00 ONBOOT=yes BRIDGE=br0 NM_CONTROLLED=no
DEVICE=eth1 HWADDR=02:00:00:00:00:01 ONBOOT=yes BRIDGE=br0 NM_CONTROLLED=no
BRIDGE option specifies the name of the bridge to which the interface should be attached. The interface should not be given an IP address.
Like the Ethernet interfaces, the bridge will not become operational until it is brought into the ‘up’ state.
This can be done by starting or restarting the
service network restart
network service does not start automatically at boot time then you should arrange for that to happen:
chkconfig network on
On systems that use NetworkManager the
network service is typically not enabled by default. If it is already enabled then enabling it again is harmless.
The bridge should now be ready for use, however there may be a delay before traffic starts to flow (typically about 30 seconds if STP is enabled or half that if not).
As noted above, an Ethernet interface cannot usefully have an IP address if it is also attached to a bridge. However it is possible to achieve the same effect by binding an address to the bridge itself. The IP address can be set statically:
DEVICE=br0 TYPE=Bridge STP=on ONBOOT=yes BOOTPROTO=none IPADDR=192.168.0.1 NM_CONTROLLED=no
or obtained using DHCP:
DEVICE=br0 TYPE=Bridge STP=on ONBOOT=yes BOOTPROTO=dhcp NM_CONTROLLED=no
|See:||Troubleshooting Ethernet bridging on Linux|
On Fedora 13 you may see errors from NetworkManager when the networking service is restarted despite using the
NM_CONTROLLED option to request that the devices are not managed. A typical example would be:
Error org.freedesktop.NetworkManagerSettings.InvalidConnection: ifcfg file '/etc/sysconfig/networkscripts/ifcfg-br0' unknown
It is unclear whether this causes any actual harm, as it does not appear to prevent the bridge from being created and properly configured, however errors like this are certainly not desirable. They can be avoided by permanently deactivating the NetworkManager service:
service NetworkManager stop chkconfig NetworkManager off
- Bridge traffic between two or more Ethernet interfaces on Linux
- Persistently bridge traffic between two or more Ethernet interfaces (Debian)
- Persistently bridge traffic between two or more Ethernet interfaces (SUSE)