VLAN Support in Linux
In the case of a VLAN with only a single switch, no Tagged packets should be sent or received. However, it's still useful to think of the Tagging and Untagging as occurring:
Packet arrives and is Tagged according to the PVID of the ingress port.
Egress port is determined based on the VID in the Tag.
Packet is Untagged and sent.
All packets start out as Untagged when they enter the network, and they also should always end as Untagged when they leave the network and arrive at their destination. Along their journey, if they cross a VLAN network, they will be Tagged with a VID, switched according to this VID by one or more VLAN switches, and then finally Untagged by the last VLAN switch.
If you've been keeping track, you know there are three things you need to configure for each port of each switch:
Member VLANs (list of VIDs).
PVID (must be one of the member VLANs).
Whether packets should be left Tagged or Untagged when sent (egress).
With one or more switches, you can achieve any VLAN topology by selectively configuring the above three settings on each port.
A VLAN switch is really just a normal switch with some extended functionality. Before you can have a VLAN switch, you first need to have a normal switch. Fortunately, Linux already has full support for this—it's just not called “switching”.
The functionality that makes Linux what you would think of as a “switch” is called bridging, a more specific and accurate term, because it's based on the official bridge standard, IEEE 802.1D.
For all practical purposes, switches and bridges are the same thing. Switch is a loose term coined by the industry that means different things for different products (for example, $10 switches usually don't fully support 802.1D, while $500 switches usually at least support 802.1D, plus lots of other features).
An 802.1Q VLAN switch is really a VLAN bridge, because 802.1Q as a standard just extends 802.1D (all devices that support 802.1Q must also support 802.1D). Technically, VLAN bridge is the correct terminology, but very few people would know what that means.
In order to use bridges in Linux, you need a kernel compiled with CONFIG_BRIDGE and the userland package bridge-utils. I suggest you also add the ebtables kernel options and userland tool.
Think of each Ethernet interface in your system as a one-port switch. An Ethernet interface already performs the same basic functions as a switch—forwarding packets, maintaining an ARP cache and so on—but on a single port without the need or capability to decide to which other port(s) a packet should be sent.
Linux's bridging code elegantly plugs in to and extends the existing functionality by letting you define bridges as virtual Ethernet interfaces that bundle one or more regular Ethernet interfaces. Each interface within the bridge is a port. In operation, this is exactly like ports of a switch.
The userland tool for administering bridges is brctl. Here's how you would set up a new bridge comprising eth0 and eth1:
brctl addbr br0 brctl addif eth0 brctl addif eth1 ip link set br0 up
Once you run these commands, you'll have a new Ethernet interface named br0 that is the aggregate of both eth0 and eth1. For typical usage, you wouldn't configure IP addresses on eth0 and eth1 anymore—you would now use br0 instead.
The best way to understand how this works is to imagine br0 as a physical Ethernet interface in your box that's plugged in to a three-port switch on your desk. Because br0 is plugged in to one of the ports, this would leave the switch with two remaining ports—eth0 and eth1 are these two switch ports (Figure 1).
Packets will pass between the interfaces/ports, the bridge will learn and maintain an ARP cache, and like a switch, it will decide to which ports each packet should be forwarded.
But, unlike a normal switch external to your system, you own and control all of the ports. You now can use any and all of the tools available under Linux to create the ultimate managed switch!
Because you still have access to the underlying Ethernet interfaces, you can do things like sniffing with tcpdump or snort on ports individually. Using the ebtables package, you can filter the Ethernet packets that pass through your switch with the same control and precision as iptables for IP packets.
Topics such as ebtables are beyond the scope of this article, but see the ebtables man page and Web site (see Resources).
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
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Rogue Wave Software's Zend Server
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