creating and using VLANs

A basic network may have routers and switches, and many users doing many different things; and as a network grows and evolves, it is beneficial to redesign and optimise it to ensure it runs efficiently and securely – as well as allowing for simpler management and a more logical view.

Take this simple network design for example:

If we have lots of different departments, we may need to increase the IP addresses on a network, or improve traffic flow, or implement security features.

One way this can be achieved, is by introducing VLANs into the design:

In this knowledge base article, we are going to create two VLANs and ensure traffic flows between our devices.

To ensure we can route between our networks, we need a layer 3 capable routing device – in this example, we will use a Cisco router to perform this role. The switches need to be VLAN capable managed switches also, we will be using two Cisco switches.

To start, we need to create our new networks (VLANs) on the router (In global configuration mode):

interface Vlan10
description TECHNICAL
ip address

interface Vlan20
description SALES
ip address

The VLANs must still be entered into the VLAN database also, this is done by entering:

Vlan 10
Vlan 20

These commands work because this router has built in switch ports. Dedicated router devices will not, therefore it is required to create sub interfaces and specify the dot1q encapsulation followed by the VLAN tag, like so:

interface faste0/0.1
description TECHNICAL
encapsulation dot1q 10
ip address

interface faste0/0.2
description SALES
encapsulation dot1q 20
ip address

IEEE 802.1Q is the networking standard that supports VLANs, known as dot1q.

Different devices are designed for different purposes, and can differ in commands and terminology, but the networking standards need to be followed.

Remember, VLANs are simply 802.1Q tagged frames. So whether you specify VLANs and VLAN IDs, or whether you specify sub interfaces with encapsulation 802.1Q with a tag ID, you are achieving the same end result.

VLAN Trunking Protocol (VTP) would be beneficial here, to allow created VLANs to be automatically created on other devices in the network, but we will cover the manual configuration per device in this article.

We can see our VLAN configuration like so in our running config:

And we can see our new VLANs in the VLAN database also:

We may wish to change the displayed names here, to do that we can enter the VLAN config and change them:

We can use the router to provide DHCP addresses if required:

ip dhcp pool TECHNICAL POOL

ip dhcp pool SALES POOL

If NAT is required, don’t forget to add ip nat inside to the VLAN configuration and add or edit your NAT overload access list!

Finally, configure the connection to the switch as a trunk – this ensures the link is capable of carrying all specified VLANs:

interface FastEthernet2
switchport mode trunk

Now we can move onto our first switch configuration.

A show cdp neighbors command may help you find the port that is connected to the router:

Here we can see that port 24 is connected to the router. We need to configure this port as a trunk:

interface gi0/24
switchport encapsulation dot1q
switchport mode trunk

Above you can see the need to specify the encapsulation method, IEEE 802.1Q is the networking standard that supports VLANs. This is specified as simply ‘dot1q’. However, this depends on the IOS that the switch is running and may not be required – this standard is the default standard normally.

Next, we need to create the VLANs on the switch, as currently there are only the defaults:

Those of you with a keen eye may notice that port 24 is missing from the entries listed under VLAN 1 (the default VLAN), this is because we changed it to a trunk port.

To create the VLANs, we just enter the new VLAN into global configuration mode like so:

vlan 10
vlan 20
name SALES

The names are optional, but will help our network management.
The new VLANs are created and shown in the VLAN database:

The switch itself operates at layer 2, and therefore it is not required to create a VLAN interface and give it a layer 3 address. Although, as network administrator, you may wish to do that.

Finally, we need to tell the switch which ports need to be in which VLAN. Our earlier diagram indicates we have one technical user and one sales user on this switch.

You can use show mac-address-table to help find this information if you are working on a live production network… or you can assign the ports as you wish.

In this example, we are going to define port 20 as technical, and port 21 as sales:

interface gi0/20
switchport mode access
switchport access vlan 10
interface gi0/21
switchport mode access
switchport access vlan 20

And now the magic happens!
A device connected to port 20 will be tagged as VLAN 10, and frames will only communicate on ports assigned to the same VLAN – or trunks. The device will pass packets to the router, and the router will provide an IP address from its VLAN 10 DHCP pool as it receives the VLAN tag in the frames within the IP packet.
And the same thing happens with VLAN 20 for sales devices.

But let’s not forget our other switch!

Our earlier show cdp neighbours command showed which port it was connected to:

So we need to configure port 1 as a trunk:

interface gi0/1
switchport encapsulation dot1q (if required)
switchport mode trunk

Then we jump onto switch 2, and we repeat the process.

Always verify the config and test!

Here in testing, we can see our DHCP client (Technical_Host (which is connected to Switch 1 port 20)) has received an IP address from the router and has full connectivity across the network, including being able to reach a device on the Sales VLAN:

For the sake of completion, here shown is the same test from the Sales host device (Sales_Host (which is connected to Switch 2 port 21)):

We now have a largely improved network that is easier to manage and more efficient. And we now have the option of implementing security to block access between VLANs.

Let’s say we wanted to stop our technical subnet from accessing our sales subnet altogether.

We can create two access lists for each VLAN that denies traffic like so:

access-list 110 deny ip
access-list 110 permit ip any

access-list 120 deny ip
access-list 120 permit ip any

[format: access-list NUMBER permit/deny protocol source destination]

NB: Remember access lists always have an implicit deny once they are created, which is why we add a permit statement for the subnet to any destination.

These access lists need to be applied correctly and logically to work:

interface vlan 10
ip access-group 110 in

interface vlan 20
ip access-group 120 in

This means traffic flowing inbound to that interface is inspected.

There are other ways to achieve similar results, and you could choose to use standard access lists if deemed suitable. Extended access lists offer more flexibility and scalability though.

In this example, the end result is that hosts on the technical subnet can no longer access the sales subnet and vice versa, but can still access the Internet and their own subnet:

This article has demonstrated how introducing VLANs can segment your network into a more efficient and scalable solution, as well as providing options for implementing security using access lists.