It used to be that your network was small and easily managed. You had only a few servers to maintain, a single Cisco switch, fewer than 100 clients, and everybody was on the same network. Unfortunately, the salad days couldn’t last forever. Your employer just went on an expansion binge, which means that your network landscape is about to become a bit rockier.

If this is starting to sound familiar, then you must be considering what to do first. Sure, you’ve already thought about the basics. You know you’ll need more access ports and probably some network redesign. But, where do you start? In this first Daily Drill Down of my series on VLAN and switching technology, I’ll discuss the reasons for and advantages of implementing VLAN technology through examples showing the development of several network expansion options.

Our IP scheme
First, let’s take a look at the IP addressing scheme. Assume that, with great foresight, you used the reserved Class B address when you originally designed your network. Further, we’ll assume a subnet mask of For those not familiar with subnetting, this means that the entire third octet will be used for subnet numbering and the entire fourth octet will define actual host numbers. That being the case, you have address space for 254 hosts on your existing network. But your host addressing needs just grew beyond that magic number. The information you’ve just received from management is that you’ll soon be supporting about 300 clients. For those familiar with subnetting, it would be easy to modify your subnet mask to allow for more hosts on a single subnet. (For those not subnet-savvy, we’ll keep things basic, as a detailed discussion of subnetting is not our focus here.) Exploring this angle further, we know that we can borrow 1 bit from the third octet, yielding a mask of, which would allow for 510 host addresses. This is a direct and simple solution, as it keeps everyone on the same subnet and alleviates the need to perform any routing. However, this simplicity does come at a price. This option will effectively increase your broadcast domain to three times its current size. This may or may not be a good thing. The problem is that we won’t know if excessive broadcasts will be a problem until after implementing this solution.

Secondly, let’s examine the expansion from a security perspective. Not only must you ramp up your network to support an environment three times the current size, but the company has also mandated departmental traffic isolation. This means you’ll need to secure each department. In other words, accounting, HR, and R&D will all need restricted access as deemed appropriate by management. Unfortunately, the previously mentioned option for expanding your network makes no allowance for isolating traffic by department. By placing everyone on the same subnet, we would be potentially allowing all machines network access to one another. Since this is contrary to management’s directive, this is not an option to pursue any further.

From here, we’ll explore another solution that more closely fits the bill: subnetting. If you create a different subnet for each department as prescribed by management, you can secure traffic departmentally. Since you are placing each department on its own subnet, chances are you’ll need some method for routing appropriate traffic between them. One form of appropriate traffic would be to and from your server farm. Let’s say you’ve decided to place all of your servers on their own subnet. Centralizing your server farm in this manner would be a wise choice for several reasons. Two important reasons would be security and ease of management. In terms of security, you could use access lists on your router to restrict any form of unwanted traffic from reaching the servers. This would give you a greater level of control than if you placed the servers within one of your departmental subnets.

We can apply that same concept to our switches. Cisco switches have a management interface that will need to be assigned a network address. This interface allows you to access and manage your switches across the network. In this case, we’ll place our switches in the same subnet as the servers, thereby consolidating the management subnet. Now that we’ve fleshed out the general parameters for this network expansion option, we’ll get into the details. As previously mentioned, we’ll have three departmental subnets and one management subnet. The network addresses for each are as follows. (Assume a single subnet mask of
Management –
HR –
R&D –
Accounting –

Let’s say, in this simple scenario, that every department is localized in the same physical area of the building. In this case, it becomes easy to implement your new subnets. Each department will be its own subnet and will have its own separate switch. We have 254 host addresses for each subnet, which accommodates our current expansion needs while allowing headroom for future growth. Since we already have one Cisco 4000 series switch, we’ll acquire three more of the same. Additionally, we’ll need a router with at least four Ethernet ports to accommodate each of our subnets. Let’s physically connect each switch to the router. We’ll continue by configuring our subnet interfaces and routing on the router.
Router(config)#ip routing
Router(config)#router rip
Router(config)#interface ethernet 1
Router(config-if)#ip address
Router(config-if)#description Management subnet
Router(config-if)#no shutdown
Router(config)#interface ethernet 2
Router(config-if)#ip address
Router(config-if)#description HR subnet
Router(config-if)#no shutdown
Router(config)#interface ethernet 3
Router(config-if)#ip address
Router(config-if)#description R&D subnet
Router(config-if)#no shutdown
Router(config)#interface ethernet 4
Router(config-if)#ip address
Router(config-if)#description Accounting subnet
Router(config-if)#no shutdown

In this example, we activated routing using the RIP protocol and listed each of the networks to be included in the routing process. Then we configured an interface for each subnet, including a description, and activated the interface.

Now we’ll set up our switches.

Which OS?

These examples assume use of the CatOS utilized in the 4000 series switches.

First, we’ll do the management switch:
Console> (enable) set system name Management
Management> (enable) set interface sc0

Now, the HR switch:
Console> (enable) set system name HR
HR> (enable) set interface sc0

And the R&D switch:
Console> (enable) set system name R&D
R&D> (enable) set interface sc0

Last, but not least, we set up the Accounting switch:
Console> (enable) set system name Accounting
Accounting> (enable) set interface sc0

In this example, we configured each switch with a name reflecting its department and assigned an address for the management interface, SC0, within the management subnet.

Now that we’ve got our new network config implemented, we can sit back and enjoy the fruits of our labor. The users are happy, network performance is great, and the security has never been so good. At this point, the phone rings. It’s the HR manager saying that one of her employees is being moved to another office. As it turns out, the new office location is not within the physical locale of the HR switch. Unfortunately, our subnetting paradigm will not easily tolerate such a move. So, what do we do now?

This is where VLANs come into play. Essentially, you’re creating a virtual subnet for each department.

We could again set up each switch as its own VLAN subnet, but we would run up against the same limitation as in our previous option. Instead, we’ll set it up so that each subnet exists on all switches. This will allow us to move anyone from any department to another location outside the physical realm of their local switch without taking them out of their own departmental subnet. Naturally, this will allow us to isolate the traffic from a routing perspective, as previously described. When you compare the concept of a subnet to a VLAN, you’ll begin to see the advantages of the latter. The VLAN takes up where the subnet left off. One advantage is that we can implement VLANs with far fewer router ports. The other one that we’ll focus on here is location, location, location.

Before we continue with our implementation of VLANs, I need to introduce one of the key concepts that make it all possible: trunking. To illustrate this concept, let’s consider for a moment the previous configuration option. Each switch was connected to its own router network interface. This link carried only traffic to and from that particular subnet. That is why users on that switch had to be members of that department/subnet. But what if that link could carry traffic to and from all subnets? Wouldn’t that allow a person from any department to be connected to any switch? This is where trunking comes in. Basically, we configure each switch to understand all subnets and connect them together on ports that are capable of trunking or handling traffic for all subnets. More specifically, we’ll connect each one of our departmental switches to the management switch, using trunk ports on each interswitch connection. Then we’ll connect the management switch via a trunk port to a single port on the router. Since all switches understand all subnets (or VLANs) and all the links between understand them too, we’ll also need to configure the router to understand them. Keep in mind that not all Cisco routers support trunking. It’s dependent upon the interface, the router model, and the IOS version. The one thing that is certain is that it requires a fast Ethernet interface. Let’s configure our switches to support VLANs and trunking.

First, the management switch:
Switch (enable) set system name Management
Management (enable) set interface sc0
Management (enable) set vlan 10 name Management
Management (enable) set vlan 10 2/5-48
Management (enable) set trunk 2/1-4 on dot1q

Next, the second switch:
Switch (enable) set system name switch2
switch2 (enable) set interface sc0
switch2 (enable) set trunk 2/1 on dot1q
switch2 (enable) set vlan 20 name HR
switch2 (enable) set vlan 20 2/2-48
switch2 (enable) set vlan 30 name R&D
switch2 (enable) set vlan 30 3/1-48
switch2 (enable) set vlan 40 name Accounting
switch2 (enable) set vlan 40 4/1-48

Next, the third:
Switch (enable) set system name switch3
Switch3 (enable) set interface sc0
Switch3 (enable) set trunk 2/1 on dot1q
Switch3 (enable) set vlan 20 name HR
Switch3 (enable) set vlan 20 2/2-48
Switch3 (enable) set vlan 30 name R&D
Switch3 (enable) set vlan 30 3/1-48
Switch3 (enable) set vlan 40 name Accounting
Switch3 (enable) set vlan 40 4/1-48

And then the fourth:
Switch (enable) set system name switch4
Switch4 (enable) set interface sc0
Switch4 (enable) set trunk 2/1 on dot1q
Switch4 (enable) set vlan 20 name HR
Switch4 (enable) set vlan 20 2/2-48
Switch4 (enable) set vlan 30 name R&D
Switch4 (enable) set vlan 30 3/1-48
Switch4 (enable) set vlan 40 name Accounting
Switch4 (enable) set vlan 40 4/1-48

In this example, we defined switch settings for the management switch for four trunk ports to connect to the other three access switches and the router. The other ports on the management switch were all assigned to the Management VLAN, 10, for server access ports. Don’t mistake this for the Cisco default management VLAN 1. This is a different VLAN of our own construction. On the other access switches, we configured all of the departmental VLANs and assigned all ports on the second switch module (except the first port) to the HR departmental VLAN, 20, the third module to the R&D departmental VLAN, 30, and the fourth module to the Accounting departmental VLAN, 40. The first port on the second module of each departmental switch is configured for trunk access back to the management switch.

Now we need to configure the router for routing and the router’s fast Ethernet port for all subnets and trunking:
Router(config)#ip routing
Router(config)#router rip
Router(config)#interface  fastethernet 0.10
Router(config-if)# ip address
Router(config-if)# encapsulation dot1q 10
Router(config-if)# exit
Router(config)#interface  fastethernet 0.20
Router(config-if)# ip address
Router(config-if)# encapsulation dot1q 20
Router(config-if)# exit
Router(config)#interface  fastethernet 0.30
Router(config-if)# ip address
Router(config-if)# encapsulation dot1q 30
Router(config-if)# exit
Router(config)#interface  fastethernet 0.40
Router(config-if)# ip address
Router(config-if)# encapsulation dot1q 40
Router(config-if)# exit

In order to accomplish this, we have defined subinterfaces on fast Ethernet port 0, as described in the previous example. We address each subinterface with an address appropriate for each VLAN/subnet. Then we designate the trunking encapsulation type, dot1q, and assign that subinterface to its respective VLAN. The subinterfaces should now be active. If not, you can easily activate them with the no shutdown command. This concludes our initial configuration of VLANs. At this point, you should be able to communicate between each VLAN and your servers. You can now create access lists to implement security. And finally, let’s revisit the issue of moving users around. With the current configuration, you would simply need to plug the user in to the correct module on any given access switch from switch 2 through 4 to place them in the proper VLAN. Depending upon how dispersed your users are and how often they move, this can be the most important reason for implementing VLANs in your network.

As we’ve explored some of the options for network expansion, I hope it has become clear that the reasons for implementing VLANs are manifold. We found that the VLAN solution can help reduce costs by allowing us to purchase fewer router ports. It also gives us the flexibility of physically placing and moving our clients anywhere in the organization, while still including them virtually within their own subnet. We can also contain broadcasts within the network, thereby freeing up network resources. From a security perspective, it allows us very granular control of the network. Stay tuned for the next Daily Drill Down in this series on VLANs and switching technology, in which I’ll discuss tuning and enhancements to the switched VLAN environment.