Kernel Korner - Linux as an Ethernet Bridge
Listing 1. Before configuring the network, check that both Ethernet interfaces are up.
#> ifconfig eth0 Link encap:Ethernet HWaddr 00:CC:D0:99:EB:26 inet6 addr: fe80::2b0:d0ff:fe99:eb26/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:86208855 errors:0 dropped:0 overruns:63 frame:0 TX packets:77098217 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:3871506445 (3692.1 Mb) TX bytes:266311184 (253.9 Mb) Interrupt:5 Base address:0xec00 eth1 Link encap:Ethernet HWaddr 00:CC:03:D8:3A:1A inet6 addr: fe80::201:3ff:fed8:3a1a/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:77087614 errors:0 dropped:0 overruns:0 frame:0 TX packets:85110321 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:264995582 (252.7 Mb) TX bytes:3672580334 (3502.4 Mb) Interrupt:9 Base address:0xec80
In Listing 1, you can see that we have two network cards with no IP addresses bound to them. If you have IP addresses assigned to the interface, remove them for simplicity's sake. On Fedora, edit the file /etc/sysconfig/networking-scripts/ifcfg-X, where X is the card identifier. On my system, the two interfaces are eth0 and eth1. Delete or comment out the lines that relate to the IP address. It is important to make sure the cards are on at boot time. Listing 2 shows a basic configuration that should work. Don't forget to reinitialize networking once you've completed the above, using service network reload.
Listing 2. Two Simple Config Files for Network Cards with No IP Addresses
/etc/sysconfig/networking-scripts/ifcfg-eth0: DEVICE=eth0 ONBOOT=yes BOOTPROTO=static /etc/sysconfig/networking-scripts/ifcfg-eth1: DEVICE=eth1 ONBOOT=yes BOOTPROTO=static
Next, tell the system what devices belong to this group, as shown below. Also, give the command that actually initializes the virtual device, as shown in the last line:
#> brctl addif br0 eth0 #> brctl addif br0 eth1 #> ip link set br0 up
In its most basic form, your Linux box now is acting like a hub. For the keen ones, you can plug in the Ethernet adapters and begin to play. The box itself, however, currently is passing traffic blindly and does not have an IP address assigned to it. I like to be able to connect remotely to my devices after I install them, so I am going to add an IP address and some routing information to the virtual device br0.
To add an IP address to the bridge interface, issue:
#> ip addr add 10.1.1.18/16 brd + dev br0
I had to state both the subnet mask (/16) and which bridge device it should be assigned to. This becomes important if you have more than one virtual device on the machine. I have only the one, but the syntax requires it. If you named your bridge device something else, you need to state that explicitly here.
The last thing to do before you can play with your bridge remotely is to configure the routing:
#> route add default gw 10.1.1.1 dev br0
The usual routing rules and commands apply, and for all intents and purposes you can use the device (br0) as you would any other Linux network interface.
Now that we have everything in place, let's test it out. First, let's confirm that all of our configurations have taken hold:
#> brctl show bridge name bridge id STP enabled interfaces br0 8000.0030843e5aa2 no eth0 eth1
As you can see above, we have a single bridge device called br0 that uses interfaces eth0 and eth1. This confirms that we should be in business.
Now it's time to do the physical setup. Connect one network card to your network switch as you would normally do for any other computer. You should see link lights on both ends of the link. Connect a desktop or laptop to the other interface on your Linux box using a crossover cable. Wait for the link lights to come on, count to ten and ping another node on your network from your desktop or laptop. You should be able to use the network on the other side of the Linux hub as if it was attached directly.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Django Models and Migrations
- Hacking a Safe with Bash
- Secure Server Deployments in Hostile Territory, Part II
- Huge Package Overhaul for Debian and Ubuntu
- Home Automation with Raspberry Pi
- The Controversy Behind Canonical's Intellectual Property Policy
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- diff -u: What's New in Kernel Development
- KDE Reveals Plasma Mobile