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).
802.1Q VLAN Implementation for Linux (vlan package): www.candelatech.com/~greear/vlan.html
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.
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?
|Speed Up Your Web Site with Varnish||Jun 19, 2013|
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
- Speed Up Your Web Site with Varnish
- Containers—Not Virtual Machines—Are the Future Cloud
- Linux Systems Administrator
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Non-Linux FOSS: libnotify, OS X Style
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- RSS Feeds
- Reply to comment | Linux Journal
3 hours 41 min ago
- Yeah, user namespaces are
4 hours 58 min ago
- Cari Uang
8 hours 29 min ago
- user namespaces
11 hours 22 min ago
11 hours 48 min ago
- One advantage with VMs
14 hours 17 min ago
- about info
14 hours 50 min ago
14 hours 51 min ago
14 hours 52 min ago
14 hours 54 min ago