Rate this page

Flattr this

Persistently bridge traffic between two or more Ethernet interfaces (Red Hat)

Content

Specific to

Red Hat-based distributions

Tested on

Fedora (12, 13, 14, 15, 16)

Objective

To persistently bridge traffic between two or more Ethernet interfaces on a Red Hat-based system

Background and Scenario

See Bridge traffic between two or more Ethernet interfaces on Linux.

Method

Overview

The method described here has five steps:

  1. Install the bridge utilities package.
  2. Choose a name for the bridge.
  3. Write a configuration script for the bridge.
  4. Write configuration scripts for the Ethernet interfaces.
  5. Start or restart the network service.

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.

Install the bridge utilities package

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 bridge-utils package:

yum install bridge-utils

Choose a name for the bridge

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.

Write a configuration script for the bridge

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

The 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).

The 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 ifup.

A BOOTPROTO of 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.

The 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.

Write configuration scripts for each Ethernet interface

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 ifcfg-eth0:

DEVICE=eth0
HWADDR=02:00:00:00:00:00
ONBOOT=yes
BRIDGE=br0
NM_CONTROLLED=no

and ifcfg-eth1:

DEVICE=eth1
HWADDR=02:00:00:00:00:01
ONBOOT=yes
BRIDGE=br0
NM_CONTROLLED=no

The BRIDGE option specifies the name of the bridge to which the interface should be attached. The interface should not be given an IP address.

Start or restart the network service

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 network service:

service network restart

If the 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).

Variations

Binding an IP address to the bridge

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

Troubleshooting

See: Troubleshooting Ethernet bridging on Linux

Errors

org.freedesktop.NetworkManagerSettings.InvalidConnection

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

See also

Further reading

Tags: bridging | ethernet