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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Tech Tip: Really Simple HTTP Server with Python
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- Rogue Wave Software's Zend Server
- Returning Values from Bash Functions
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide