VLAN Support in Linux
The typical configuration of a Linux box as a firewall/gateway is to have two physical interfaces, with one connected to the Internet router (public side) and the other connected to the internal LAN switch (private side), as shown in Figure 3.
But, what if the Internet router and switch/patch panel are inside a wiring closet where there is no room to install a Linux box, and every possible location to put it has only a single jack/cable?
VLANs make this no problem. Instead of installing the Linux box physically in between the public and private networks, you can install a small off-the-shelf VLAN switch, configured with two VLANs (VIDs 1 and 2).
Configure one port as a member of both VLANs with Tagging on. You'll plug the Linux box in to this port. This should be the only port configured with Tagging, because it's the only port that will talk to another VLAN device (the Linux box). Every other port will be set to Untagged.
Configure another port of the switch as a member of VLAN 2 only (Untagged, PVID set to 2). You'll plug the Internet router in to this port.
Leave the rest of the ports on VLAN 1 only (Untagged, PVID set to 1). These are the ports for all the hosts on the private network. If there are more hosts than ports, you can plug in another switch or switches (non-VLAN) to any of these VLAN 1 ports to service the rest of the hosts.
The Linux box needs only one physical interface (eth0). Run these commands to configure the VLANs:
ip link set eth0 up vconfig add eth0 1 ip link set eth0.1 up vconfig add eth0 2 ip link set eth0.2 up
Just like in the first example, you now would configure your IP addresses and firewall normally, using eth0.1 as the interface on the private network and eth0.2 as the interface on the public network (Figure 4).
As in the first example, because there is only one physical interface in the Linux box, there is no need to define a bridge.
The VLAN switch ports in this example are acting like interfaces of the Linux box. You easily can extend this concept for other applications and scenarios. Using a 24-port VLAN switch, you could have the equivalent of 23 Ethernet interfaces in a Linux box if you created 23 separate VLANs. The 24th port would be used to connect the Linux box to the switch and would need to Tag all the packets for the 23 VLANs.
You can use tcpdump to see Tagged and Untagged packets on the wire and to make sure traffic is showing up on the expected interfaces. Use the -e option to view the Ethernet header info (which shows 802.1Q Tags) and the -i option to sniff on a specific interface. For example, run this command to show traffic for VLAN 10:
tcpdump -e -i eth0.10
You should see normal traffic without VLAN Tags. If VLAN 10 contains more than a few hosts, you should at least start seeing ARP and other normal broadcast packets (like any switched network, you won't see unicast packets not addressed to your host/bridge).
If the eth0.10 VLAN interface is working correctly above, you should see the Tagged 802.1Q packets if you look at the traffic on the underlying physical interface, eth0:
tcpdump -e -i eth0
If you run this command at the same time as the eth0.10 capture, you should see the Tagged version of the same packets (as well as packets for any other VLAN interfaces set up on eth0).
Resources
802.1Q VLAN Implementation for Linux (vlan package): www.candelatech.com/~greear/vlan.html
bridge-utils: www.linuxfoundation.org/collaborate/workgroups/networking/bridge
ebtables: ebtables.sourceforge.net
IEEE 802.1Q-2005—Virtual Bridged Local Area Networks: standards.ieee.org/getieee802/download/802.1Q-2005.pdf
IEEE 802.1D-2004—Media Access Control (MAC) Bridges: standards.ieee.org/getieee802/download/802.1D-2004.pdf
Henry Van Styn is the founder of IntelliTree Solutions, an IT consulting and software development firm located in Cincinnati, Ohio. Henry has been developing software and solutions for more than ten years, ranging from sophisticated Web applications to low-level network and system utilities. He is the author of Strong Branch Linux, an in-house server distribution based on Gentoo. Henry can be contacted at www.intellitree.com.
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?
| Dynamic DNS—an Object Lesson in Problem Solving | May 21, 2013 |
| Using Salt Stack and Vagrant for Drupal Development | May 20, 2013 |
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
| Non-Linux FOSS: Seashore | May 10, 2013 |
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- The Secret Password Is...
- New Products
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"






4 hours 6 min ago
5 hours 57 min ago
11 hours 10 min ago
14 hours 22 min ago
16 hours 37 min ago
17 hours 5 min ago
18 hours 4 min ago
19 hours 32 min ago
20 hours 41 min ago
21 hours 27 min ago