Network bridging in linux

Network bridge

A bridge is a piece of software used to unite two or more network segments. A bridge behaves like a virtual network switch, working transparently (the other machines do not need to know about its existence). Any real devices (e.g. eth0 ) and virtual devices (e.g. tap0 ) can be connected to it.

This article explains how to create a bridge that contains at least an ethernet device. This is useful for things like the bridge mode of QEMU, setting a software based access point, etc.

Contents

Creating a bridge

There are a number of ways to create a bridge.

With iproute2

This section describes the management of a network bridge using the ip tool from the iproute2 package, which is required by the base meta package.

Create a new bridge and change its state to up:

To add an interface (e.g. eth0) into the bridge, its state must be up:

Adding the interface into the bridge is done by setting its master to bridge_name :

To show the existing bridges and associated interfaces, use the bridge utility (also part of iproute2 ). See bridge(8) for details.

This is how to remove an interface from a bridge:

The interface will still be up, so you may also want to bring it down:

To delete a bridge issue the following command:

This will automatically remove all interfaces from the bridge. The slave interfaces will still be up, though, so you may also want to bring them down after.

With bridge-utils

This section describes the management of a network bridge using the legacy brctl tool from the bridge-utils package, which is available in the official repositories. See brctl(8) for full listing of options.

Create a new bridge:

Add a device to a bridge, for example eth0 :

Show current bridges and what interfaces they are connected to:

Set the bridge device up:

Delete a bridge, you need to first set it to down:

With netctl

With systemd-networkd

With NetworkManager

GNOME’s Network settings can create bridges, but currently will not auto-connect to them or slave/attached interfaces. Open Network Settings, add a new interface of type Bridge, add a new bridged connection, and select the MAC address of the device to attach to the bridge.

KDE’s plasma-nm can create bridges. In order to view, create and modify bridge interfaces open the Connections window either by right clicking the Networks applet in the system tray and selecting Configure Network Connections. or from System Settings > Connections. Click the Configuration button in the lower left corner of the module and enable «Show virtual connections». A session restart will be necessary to use the enabled functionality.

nm-connection-editor can create bridges in the same manner as GNOME’s Network settings.

nmcli from networkmanager can create bridges. Creating a bridge with STP disabled (to avoid the bridge being advertised on the network):

Making interface enp30s0 a slave to the bridge:

Setting the existing connection as down (you can get it with nmcli connection show —active ):

Setting the new bridge as up:

If NetworkManager’s default interface for the device you added to the bridge connects automatically, you may want to disable that by clicking the gear next to it in Network Settings, and unchecking «Connect automatically» under «Identity.»

Assigning an IP address

This article or section needs expansion.

When the bridge is fully set up, it can be assigned an IP address:

With iproute2

With NetworkManager

Give it the desired address:

Set up a DNS server (this will also avoid not being able to load any pages after you apply the changes):

Set the IP address to static:

Apply the changes:

Tips and tricks

Wireless interface on a bridge

To add a wireless interface to a bridge, you first have to assign the wireless interface to an access point or start an access point with hostapd. Otherwise the wireless interface will not be added to the bridge.

Speeding up traffic destinated to the bridge itself

In some situations the bridge not only serves as a bridge box, but also talks to other hosts. Packets that arrive on a bridge port and that are destinated to the bridge box itself will by default enter the iptables INPUT chain with the logical bridge port as input device. These packets will be queued twice by the network code, the first time they are queued after they are received by the network device. The second time after the bridge code examined the destination MAC address and determined it was a locally destinated packet and therefore decided to pass the frame up to the higher protocol stack.[1]

The way to let locally destinated packets be queued only once is by brouting them in the BROUTING chain of the broute table. Suppose br0 has an IP address and that br0’s bridge ports do not have an IP address. Using the following rule should make all locally directed traffic be queued only once:

The replies from the bridge will be sent out through the br0 device (assuming your routing table is correct and sends all traffic through br0), so everything keeps working neatly, without the performance loss caused by the packet being queued twice.

The redirect target is needed because the MAC address of the bridge port is not necessarily equal to the MAC address of the bridge device. The packets destinated to the bridge box will have a destination MAC address equal to that of the bridge br0, so that destination address must be changed to that of the bridge port.

Troubleshooting

No networking after bridge configuration

This article or section needs language, wiki syntax or style improvements. See Help:Style for reference.

It may help to remove all IP addresses and routes from the interface (e.g. eth0 ) that was added to the bridge and configure these parameters for the bridge instead.

First of all, make sure there is no dhcpcd instance running for eth0 , otherwise the deleted addresses may be reassigned.

Remove address and route from the eth0 interface:

Now IP address and route for the earlier configured bridge must be set. This is usually done by starting a DHCP client for this interface. Otherwise, consult Network configuration for manual configuration.

No networking on hosted servers after bridge configuration

This article or section needs language, wiki syntax or style improvements. See Help:Style for reference.

Источник

• BridgeNetworkConnections

Introduction

Bridging your network connection is a handy method for sharing your internet connection between two (or more) computers. It’s useful if you can’t buy a router with more than one ethernet port, or if you’re a college student in a dorm room with limited ethernet jacks and no router.

Basically, bridging is plugging one computer into another computer that already has a connection to a larger network (like the internet) and letting the bridged computer use the networked computer’s connection. To do so though, the networked computer needs to have two ethernet ports, one for the big network, and one for the bridged computer. Make sure before starting that the computer you’re going to bridge through has two ethernet ports, and that the hardware is capable of bridging ethernet connections (it probably should be).

Another example scenario for using bridging is to provide redundant networking capabilities. For example using two network interfaces to connect to two spanning tree enabled switches provides a redundant connection in the event of a cable, interface or switch failure. This requires spanning tree to be enabled on both the bridge interface and the switch.

Installing the software

The program you’re going to need is called brctl and is included in bridge-utils. Find it in Synaptic, or install it using this command:

This software allows you to set up and use the bridge interface. The bridge interface appears as a new interface in ip link, much like eth0 or eth1. It doesn’t physically exist on your computer, but instead it is a virtual interface that just takes the packets from one physical interface, and transparently routes them to the other.

Setting up your Bridge

Manual bridge setup

Note: All these commands are to be issued on the computer with the existing network connection. To set up the computer that’s going to be bridged, just set it up normally, as you would any other computer. You CAN use DHCP, or you can use a static address. It doesn’t matter.

Note: If, after trying to use the bridge interface, you find your network link becomes dead and refuses to work again, it might be that the router/switch upstream is blocking «unauthorized switches» in the network (for example, by detecting BPDU packets). You’ll have to change its configuration to explicitly allow the host machine/network port as a «switch».

First step to creating the bridge network is actually creating it. Issue this command to get the ball rolling and create the new interface.

The name br0 is up to you and can be anything you want. Now you need to add the interfaces that are going to be bridged. You can cross-check the enumeration of your ethernet devices with ( eth0, eth1, etc. is common):

Add both the interface with the second computer, and the interface that leads to the existing network. Use brctl:

This will add the two interfaces eth0 and eth1 to bridge br0. Simple enough. There’s no distinction with how you add the bridges, or what order you do it, or any special commands you have to add to distinguish them. So don’t worry about that.

Well, now we have our bridges, so bring all the interfaces up, and you’ll be set!

Configuring bridging in /etc/network/interfaces

To make your bridge a little more permanent, you will need to edit /etc/network/interfaces. Using our example names, make it look like this and you’re set (if you want to use DHCP):

To bring up your bridge, you just have to issue # ifup br0 and it’ll bring up the other necessary interfaces without anything in your interfaces file about the bridged interfaces.

If you like static IP’s, then you can just add the static IP options under the br0 interface setup. For example:

Notes for Debian Stretch and Buster

If you did as said above, but did not get network after rebooting, though ifup br0 works well, you can try to remove /etc/network/interfaces.d/setup file. This will fix everything. I can’t explain why, but it helps

Useful options for virtualised environments

Some other useful options to use in any stanza in a virtualised environment are:

Setting up bridge-related kernel variables

There are several kernel variables that affect bridge operation. In some cases you may need to tweak these variables. There are two common options:

Add variables to /etc/sysctl.conf directly

Put them to a sysctl configuration file fragment (e.g. /etc/sysctl.d/bridge_local.conf)

In the latter case, the procps init script should take care of loading them during boot. However, on Squeeze it does not, and you need to restart it from /etc/rc.local (or similar):

Libvirt and bridging

Libvirt is a virtualization API that supports KVM (and various other virtualization technologies). It’s often desirable to share a physical network interface with guests by creating a bridge. This usually offers excellent performance and doesn’t require NAT. This operation is composed of two parts:

Setup the bridge interface on host as described in this article, here or here

Configure guest to use the newly-created bridge

The libvirt Networking Handbook provides thorough instructions.

You can verify if bridging is working properly by looking at brctl output:

As can be seen, guest network interfaces vnet0, vnet1 and vnet2 are bound with the physical interface eth0 in the bridge br0. The virbr0 interface is only used by libvirt to give guests NAT connectivity.

Bridging with a wireless NIC

Just like you can bridge two wired ethernet interfaces, you can bridge between an ethernet interface and a wireless interface. However, most Access Points (APs) will reject frames that have a source address that didn’t authenticate with the AP. Since Linux does ethernet bridging transparently (doesn’t modify outgoing or incoming frames), we have to set up some rules to do this with a program called ebtables.

For an alternative Layer 3 approach using proxy ARP and routing, see BridgeNetworkConnectionsProxyArp.

ebtables Overview

ebtables is essentially like iptables, except it operates on the MAC sublayer of the data-link layer of the OSI model, instead of the network layer. In our case, this allows to change the source MAC address of all of our frames. This is handy because we fool our AP into thinking that all of our forwarded frames come from the machine which authenticated to the AP.

bridge-utils Modifications

Before this will work, you need to modify your /etc/network/interfaces file, and add this line to your bridge stanza:

Obviously replacing $MAC_ADDRESS_OF_YOUR_WIRELESS_CARD with the actual MAC address of your wireless card, and $YOUR_ESSID as the ESSID of your wireless network. If you don’t know your MAC address, you can find it by typing

Where wlan0 is your wireless interface. Your MAC address is listed as the HWaddr.

Setting up the rules

First, install ebtables:

Now we can start setting up the rules. The syntax for ebtables is almost identical to that of iptables, so if you have experience with iptables, this will look pretty familiar to you.

The first rule we’re going to set up will set the source MAC address to the MAC address of the bridge for all frames sent to the AP.

The next rules will require you to know the MAC and IP of each of the machines behind your bridge. Replace $MAC and $IP with these.

This is tedious to have to type in everytime you add a new computer to a switch behind your bridge, so I wrote a script to do it for you

Saving your rules

After you have written your ebtables rules, you need to save them in an atomic file. Otherwise, your rules will not be preserved. Saving them is rather simple though.

And then load them like this:

If you want to load your ebtables rules at boot time, a handy place to stick the commit command is in /etc/rc.local. Just pop it in there before the exit 0 line.

Link Aggregation (LACP) with VLANs

Here is an example of the /etc/network/interfaces file for 2 interfaces LACP bonded together with VLANs defined on top of the bond.

Notes: Tested on Debian Jessie 8.0 rc1 on 3/11/2015 (AMD64 arch)

Required debian packages for vlan and bonding:

The /etc/network/interfaces could be:

Источник