VLAN Interface Configuration
by Richard Grace <[email protected]>

Introduction

In a not-so-recent network installation, we implemented a large Ethernet using three VLANs. One VLAN was used only for managing the network hardware, while the other two VLANs were used to control the access of clients to particular services. Using the management software in the VLAN switches (3com Superstack 1100 and 3300 switches) it is possible to assign each port to a particular VLAN, and thereby easily manage the access available to each user.

At the time, operating systems did not support VLAN devices or interfaces, so we needed to install three separate Ethernet cards in each server in order to have access to each VLAN. Each server also required three ports on our central VLAN switch (a 3com CoreBuilder 3500) which proved to be quite expensive.

This is now a whole lot easier, with current versions of FreeBSD (and OpenBSD) providing support for IEEE 802.1Q VLAN interfaces. Configuration of OpenBSD is identical to the process outlined in this article.

These interfaces allow the server to be connected to another VLAN capable device (eg, a 3com 3300 switch, or another server) and carry traffic for multiple (some devices only support 16 VLANs, others support more) VLANs over a single cable to one physical interface without breach of network security.

As an example, a single FreeBSD server may act as a server/gateway for many separate networks. In order for the networks to remain separate, a new VLAN would be created on the FreeBSD server and on the VLAN switch, and the port on the switch added to the new VLAN using 802.1Q tagging. Each network sees the FreeBSD server/gateway as though it were a part of the local network, but they are unable to see the joining networks as they are on different VLANs. Services such as DHCP on the server can be bound to the separate vlan interfaces, and by using NAT and proxying services, each VLAN sees only its view of the outside world.

Configuring FreeBSD (and OpenBSD)

1. Building a new kernel

Before you can create and use the VLAN device, you must configure the kernel to use the VLAN device driver. Here is the line required in the kernel, this will add support for 2 vlan interfaces, you can add more if you wish:

pseudo-device  vlan    2       # IEEE 802.1Q VLAN Support

You must re-compile and install the new kernel, and run:

MAKEDEV -all

in the /dev directory before you can configure the VLAN interfaces.

2. Configuring the VLAN interfaces:

Once you have re-compiled the kernel and created the device nodes, here is how you configure the VLAN interface:

ifconfig vlan_device vlan vlan_id vlandev parent_device 

eg,

ifconfig vlan0 vlan 2 vlandev le0

then give it some useful address in the usual way:

ifconfig vlan_device inet address netmask mask 

eg,

ifconfig vlan0 inet 172.16.0.1 netmask 255.255.255.0

An example:

First, let's check the interfaces:

$ ifconfig -a
lo0: flags=8009 mtu 32972
        inet 127.0.0.1 netmask 0xff000000
le0: flags=8863 mtu 1500
        media: Ethernet 10base5
        inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
vlan0: flags=0<> mtu 1500

This shows that our kernel supports one loopback, one ethernet and one vlan.

Second, let's assign a VLAN to our interface:

$ ifconfig vlan0 vlan 2 vlandev le0
$ ifconfig -a
lo0: flags=8009 mtu 32972
        inet 127.0.0.1 netmask 0xff000000
le0: flags=8863 mtu 1500
        media: Ethernet 10base5
        inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
vlan0: flags=8863 mtu 1500
        vlan: 2 parent interface: le0

This shows that interface vlan0 is a member of VLAN ID=2 and will listen for IEEE 802.1Q tagged packets on ethernet device le0.

And finally, we'll give our VLAN interface an address:

$ ifconfig vlan0 inet 172.16.0.1 netmask 255.255.255.0
$ ifconfig -a
lo0: flags=8009 mtu 32972
        inet 127.0.0.1 netmask 0xff000000
le0: flags=8863 mtu 1500
        media: Ethernet 10base5
        inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
vlan0: flags=8863 mtu 1500
        vlan: 2 parent interface: le0
        inet 172.16.0.1 netmask 0xffffff00 broadcast 172.16.0.255

3. Binding Services - DHCP

OK, now suppose you want to run a DHCP service for the client networks, assigning each network a different range of addresses. Here are the config files for the ISC dhcpd and start scripts to bind the service to the vlan interfaces. As you can see, the interfaces may be treated just like a normal ethernet or tunnel device.

In this example, I'm assuming there is a DNS server installed and running on the server/gateway and that the domains have been configured locally.

Here is the /etc/dhcpd.conf for the domain vlan0.test-domain.com.au:

shared-network VLAN0 {
        option  domain-name "vlan0.test-domain.com.au";
        option  domain-name-servers 172.16.0.1;
 
        subnet 172.16.0.0 netmask 255.255.255.0 {
                option routers 172.16.0.1;
                range 172.16.0.129 172.16.0.254;
        }
}

And, here's the startup section from /etc/rc.local for dhcpd:

if [ -f /etc/dhcpd.conf ] ; then
        echo -n ' dhcpd' ; /usr/sbin/dhcpd vlan0
fi

Which binds the DHCP server only to the interface vlan0.

Virtual web servers (for Intranets) and other services are also easily bound to new VLAN interfaces in this manner.

Conclusions

Obviously, with the price of VLAN switches being quite high, and the price of Ethernet cards being low, this solution would not be justifiable for small network installations.

But, larger installations in complex office environments may benefit greatly from the ease of VLAN administration (and it makes patching so much neater!) and the ease with which servers may be pooled among users on different VLANs.

Happy networking,

Richard Grace
ITworks Consulting
[email protected]

�