A virtual approach to networks

Most managed switches support virtual local area networks (Vlans), although there is still a lot of confusion in the market as to what VLans do and how to implement them. Here we will take a look at the technology and how to use it correctly.

First, it is important to talk about the 802.1q standard. When VLans were introduced, each switch manufacturer came up with their own implementation, but 802.1q introduced a standard. As long as your switches comply with it, you can set up VLans across the network.

What is a VLan?

A VLan is a group of network devices that act as if they are on the same physical network even though they may be spread around a building.

For example, your sales team might be on several different floors, while their servers sit in the server room. Creating a VLan for the sales department would allow all its resources and bandwidth to be shared as though they were on the same network segment. Other departments' resources would remain hidden from sales.

The traditional approach

Segmenting the network using traditional equipment would involve placing sales and marketing, say, on separate switches and IP segments. That way, marketing would not get any of the sales department's broadcasts, and vice versa. For communication to take place between the two departments, a router would have to be installed between the two switches.

This is fine in theory, but what if somebody in sales moves floors? The network would then have to be physically redesigned and you might even have to buy new equipment to retain the level of service installed.

The VLan approach

A VLan solves the problem by implementing the functionality in software. Each switch port is given a VLan ID. Any device connected to a port is on that port's VLan.

If a member of sales moves, it is just a matter of changing the VLan port membership, and there is no need to physically rearrange the networks.

Advantages

VLans have the benefit of letting you organise a network beyond the physical design and infrastructure. Logically it makes more sense to divide the network by job function as it can help with troubleshooting. If there's a problem with sales, for example, then it must be located on the sales VLan.

Next, VLans help you manage traffic. In a standard switched environment, broadcasts are sent to every switch port. It is only when a broadcast hits a router that it is stopped.

Security is also improved, as VLans allow parts of the network to be hidden from other parts. For some applications you may want to restrict anyone from viewing a particular VLan.

However, the benefits will be realised only if the VLan is implemented correctly. This requires initial planning that can at first introduce an extra level of complexity into the network.

Stop and think

Before you start implementing a VLan the first step is to stop and think what you are about to do. The benefits VLans can offer will be enjoyed only in large networks. Do not implement a VLan if there is no clear benefit.

Next, plan how many VLans you will need based on the logical organisation of the company. Work out which devices will belong to each VLan and remember to include servers and printers, not just computers.

Switch configuration

To start with, let's take a look at setting up a single switch to support two departments: marketing and sales. The first task is to map which switch ports belong to each department. Next, you need to get into the management interface on the switch and access the VLan section.

Switches can support two kinds of VLan membership: port and MAC address. MAC address membership has the advantage that if a user moves you do not have to reconfigure the VLan settings. However, it does involve a significant management overhead.

Most VLans are based on port membership. In this case each port is given a VLan ID, which is just a number. Switches ship with a default VLan, of which all ports are members. All ports with the same ID are in the same VLan. When a packet comes into the switch, the switch will only pass that packet onto a port with the same VLan tag.

The job here is to assign one ID to all the ports belonging to sales and a different ID to all the ports belonging to marketing. Once you have done this, marketing will not be able to see any traffic that belongs to sales, and vice versa.

Routing

So far, so good, but what if the sales department needs to access a service that marketing offers? Since the VLan implementation prevents the switch from forwarding packets in this manner, you need to use a router instead.

A packet destined for a foreign VLan comes into the switch, is forwarded to the right router and passed onto the correct VLan port. This gives several advantages in implementation. First, routers offer access control.

The router will pass on packets to a destination only if it has a rule that says it can. It is often useful to be able to restrict access to services, such as payroll servers, to authorised personnel only.

Second, routers stop broadcasts. As the network has been logically separated on the basis of function, there is no reason for sales to get any of marketing's broadcasts. Restricting broadcasts in this way helps to improve network efficiency.

Finally, routers introduce Layer-3 address structure into the network. This lets you place each department on a separate subnet, which makes management and troubleshooting easier, as you can identify exactly where traffic is coming from.

Bringing a router into the equation is not difficult. All we have to do, is add an extra port into the sales VLan and another into the marketing VLan. Both of these ports are then connected to a router. When a packet has to go from one VLan to another, it can now be properly routed.

Now we have the basics sorted out, we can start to look at how to implement larger systems.

Multi-switched environments

Large networks are made up of lots of switches. Implementing these is also conceptually easy. In our example, let us imagine that sales and marketing staff are on switch A and the servers they use are on switch B.

First, on switch A we set up two VLans. Next, on switch B we use the same VLan IDs given to A to segment the servers into the sales and marketing departments. Now we just need to link the switches. An extra port for each VLan would be no good here, as this would require four ports. In large networks this practice would soon get out of hand.

Instead, we use an ordinary Ethernet connection but mark the port as a VLan 'trunk' (that is, a port that carries connections for multiple VLans).

VLan tags

The only problem with this is that the switch at the other end needs to know which VLan an incoming packet belongs to. This is where VLan tags come in.

Unfortunately, when Ethernet was developed VLans had not been thought of. As Ethernet adheres to a strict policy where frames have a minimum size of 64 bytes and a maximum size of 1,518 bytes there is nowhere for the tag to go.

The frame specification cannot be changed either, as too many devices expect the formatting to remain the same. The workaround was to take the four-byte VLan field and insert it after the source and destination fields.

This means the tag is protocol-independent. However, it also changes the minimum size of a frame to 68 bytes and maximum size to 1,522 bytes.

To compensate, the receiving switch has to strip this additional information out of the packet before forwarding it to its destination. This information has to be understood if you plan to monitor activity on a trunk link.

Routing in a multi-switched environment

Fortunately, the introduction of more switches into the environment does not make life any more difficult from the routing perspective. As we have a way to traverse the network at Layer-2 all we have to do for our example network is pick any two ports on the network, one from each VLan, and plug them into a router. This will enable routing across the network.

An alternative to a dedicated router is a Layer-3 switch. This introduces routing capabilities, and more, to a standard switch. However, a Layer-3 switch can route at high speed.

For VLans it makes sense to put a Layer-3 switch at the core of the network. As packets come in, the switch can take the decision on whether to route or switch a packet.

Dynamic Host Configuration Protocol

We have got the routing set up, but we still have the problem of how to hand out IP addresses to clients. Typically we want each VLan to run on a separate IP subnet.

This can be done by placing a DHCP (server) on each subnet. Alternatively, a single DHCP server can be used if zones are set up correctly and routers are set up to forward DHCP requests.

Shared servers

In any network there will be servers, such as for email and the intranet, that have to be accessed by multiple departments. These can be installed on their own VLan, but the point of our configuration is to organise the network on the basis of business function, which this does not do.

The way around this is to plug VLan trunks directly into these servers, which makes them capable of receiving all traffic from any VLan.

For this to work you need to make sure the network card in the server supports the VLan tag because, as mentioned earlier, these frames are not standard Ethernet.

BIG MISTAKES

Unless implemented properly, VLans can make management of the network harder and reduce its efficiency. Here are some common mistakes:

One VLan per device

Putting each device type - laptops, PCs, printers, servers, and so on - in their own VLans might seem like a logical way to divide the network. However, it negates the point of implementing the technology in the first place.

All users will need access to the server VLan. But assigning each device to one VLan makes it difficult to stop, say, a member of sales accessing the marketing department's server. Ultimately all traffic will have to leave the switch and be routed.

To make things easier, broadcast control can be turned off at the router level. Unfortunately, this increases network load. It is better in this case to turn off VLans and return to a switched environment.

One VLan per floor

Dividing an office on the basis of floor is another poor strategy. Again, it is loaded with problems, as the network division is based on physical location rather than business function, such as sales and marketing.

The problems encountered are similar to those in implementing a VLan per device. As servers are generally kept together, traffic destined for them will have to be routed out of one floor's VLan to the servers. Again, this makes it difficult to restrict the sales department's access to marketing's servers.

Hundreds of VLans

Just because a switch has a maximum VLan limit there is no need to use them all. This is an inefficient method of implementation. It makes management a lot more complex, and means there are routing issues to sort out.

Conclusion

As long as the network is planned properly before you start configuring anything, you will find that VLans are an intelligent way to run a network.

However, as the physical view of the network does not accurately depict the logical view, it is very important to maintain detailed network documentation. It might be a pain, but it is the only way to ensure that the network runs smoothly.

VLans make it easy to change your network layout through software, while introducing security and broadcast control, and are definitely worth the effort.