Dynamic VLANs

Introduction

Dynamic VLANs were introduced to grant the flexibility and complexity(!) that Static VLANs did not provide. Dynamic VLANs are quite rare because of their requirements and initial administrative overhead. As such, most administrators and network engineers tend to prefer Static VLANs.

Dynamic VLANs

Dynamic VLANs, as opposed to Static VLANs, do not require the administrator to individually configure each port, but instead, a central server called the VMPS (VLAN Member Policy Server). The VMPS is used to handle the on-the-spot port configuration of every switch participating on the VLAN network.

The VMPS server contains a database of all workstation MAC addresses, along with the associated VLAN the MAC address belongs to. This way, we essentially have a VLAN-to-MAC address mapping:

The above diagram works as an aim to help us understand the mapping relationship that exists in the VMPS server. As shown, each MAC address, which translates to a host on the network, is mapped to a VLAN, allowing this host to move inside the network, connecting to any switch that is part of the VMPS network and maintain its VLAN configuration.

You can now start to imagine the initial workload involved when configuring a VMPS server for a network of over 300 workstations:)

As one would expect, the above model works very well and also requires the switches to be in constant contact with the VMPS server, requesting configuration information everytime a host connects to a switch participating in the VLAN network. Of course, there is a lot more information we can use to configure the VMPS database, but we won't be covering that just as yet.

Like all network services offered, Cisco has cleverly designed this model to be as flexible as our network might require. For example, you are able to connect more than one host on one dynamically configured port, as long as all hosts are part of the same VLAN:

The diagram above shows us a VLAN capable switch that has been configured to support Dynamic VLANs. On port No.5, we have connected a simple switch (not VLAN aware) from which another 4 workstations are connected.

As mentioned previously, this type of configuration is valid and therefore supported, but it also has its restrictions and limitations.

One of the restrictions, which by the way can also be considered as a semi-security feature, is that all workstations connected to the same port, must be configured in the VMPS server as part of the same VLAN, otherwise the port is

most likely to shut down as a security precaution.

To consider the limitations of this configuration: if the switch detects more than 20 active hosts (20 MAC addresses) on the port, it will once again shut it down, leaving the workstations without any network connection. When this happens, the port that shuts down will return into an isolated state, not belonging to any VLAN.

The fact is that Dynamic VLANs are really not suitable for every network, even though they allow a great deal of flexibility and security. If you consider the advantage one single feature of Dynamic VLANs can provide you with, then it might be all you need to implement them.

Because each host connected to the switch is checked against the VMPS database for its VLAN membership before the port is activated and assigned to a VLAN, this gives the network administrator the ability to ensure no foreign host is able to walk up to a wall socket and simply plug their workstation to access the network, if his MAC address is not stored in the VMPS database. For a large scale network, this could be considered an ACE card under your sleeve.

Choosing Correct Switches

One important factor we haven't yet mentioned is that you cannot run the VMPS server on a Cisco Catalyst 2900 or 3500 series. The Catalyst 4500 and upwards are able to act as a VMPS, and at the time of writing, this switch has reached its end of retail life. For those who have dealt with Cisco Catalyst switches in the past, you would know that a Catalyst 4500 is not the type of switch you would use in a 20 or 50 node network!

The Catalyst 4500, 6500 series, are switches designed for enterprise networks, as such, they are built to be modular, easily expandable depending on your needs, and lastly, fully redundant because you can't have your core backbone switch failing when all other switches and network equipment are directly connected to it.

We've added a few pictures of the Catalyst 6500 series for you to admire :)

You can clearly see the slots available that allow the Catalyst switches to expand and grow with your network. In the likely event you require more ports as your network expands, you simply buy a Fastethernet blade (some people call them 'slices') and insert it into an available slot!

Dynamic VLANs & FallBack VLANs

Another very interesting and smart feature Dynamic VLANs support is the fallback VLAN. This neat feature allows you to automatically configure a port to a VLAN specially created for workstations whose MAC address is not in the VMPS server. Consider company visitors or clients who require specific or restricted access to your network, they can freely connect to the network and have Internet access, alongside with limited rights on public directories.

In the event the fallback VLAN has not been configured and the MAC address connected to the switch's port is unknown, the VMPS server will send an 'access-denied' response, blocking access to the network, but the port will remain active. If the VMPS server is running in 'secure-mode', it will proceed and shutdown the port as an additional security measure.

The above diagram represents a portion of a large scale network using a Cisco 6500 Catalyst as the core switch. The switch has been configured to support Dynamic VLANs, therefore a VMPS server has been configured inside the switch, alongside with a DHCP server for each created VLAN. The administrator has already assigned the 3 workstations MAC addresses to the VLANs shown and also created the fallback VLAN for any MAC address that does not exist in the database.

Now consider this interesting scenario: One morning a visitor arrives in the office and requires Internet connection so he can demonstate a new product to the management. As an administrator, you've already configured a fallback VLAN with a DHCP server activated for the VLAN, pushing the necessary settings to the clients so they may obtain Internet access services.

The visitor finds a free RJ-45 socket on the wall, which connects to a Catalyst 3550 switch nearby, and plugs in his laptop. Before the user is allowed to access the network, the Cisco 3550 switch checks the laptop's MAC address and reads 4B:63:3F:A2:3E:F9. At this point, the port is blocked, not allowing the laptop computer to send or receive data. The Cisco 3550 switch sends the MAC address to the 6500 Catalyst switch which is acting as the VMPS server and it checks for an entry that matches the specified MAC address but is unable to find one.

Naturally, it determines that this a visitor, so it creates an entry for that MAC address to the fallback VLAN and sends the information back to the Cisco 3550 switch. The switch will then enable access to the port our visitor is connected to by configuring the port to the fallback VLAN.

If the visitor's computer is configured to obtain an IP Address automatically, it will do so, once the operating system has booted. When this happens, the visitor's DHCP request will arrive to the 6500 Catalyst switch and its DHCP server will send the requested information, enabling the client (our visitor) to configure itself with all the parameters required to access the VLAN. This will also mean our visitor is now able to access the Internet!

Finishing, if the computer is not configured for DHCP, the client must be advised with the correct network settings or asked to enable automatic IP configuration in their network properties.

Summary

The past pages could be considered as an 'eye-opener' for people who are new to the VLAN concept, and at the same time a 'quick-overview' for those who are well aware of their existence! We hope all your questions to this point have been answered, if not, they are most likely too advanced and will surely be answered in the pages that follow.

Static VLANs

Introduction

VLANs are usually created by the network administrator, assigning each port of every switch to a VLAN. Depending on the network infrastructure and security policies, the assignment of VLANs can be implemented using two different methods: Static or Dynamic memberships - these two methods are also known as VLAN memberships.

Each of these methods have their advantages and disadvantages and we will be analysing them in great depth to help you decide which would best suite your network.

Depending on the method used to assign the VLAN membership, the switch may require further configuration, but in most cases it's a pretty straight forward process. This page deals with Static VLANs while Dynamic VLANs are covered next.

Static VLANs

Static VLAN membership is perhaps the most widely used method because of the relatively small administration overhead and security it provides. With Static VLANs, the administrator will assign each port of the switch to one VLAN. Once this is complete, they can simply connect each device or workstation to the appropriate port.

The picture below depicts an illustration of the above, where 4 ports have been configured for 4 different VLANs:

The screenshot above shows a Cisco switch (well, half of it :>) where ports 1, 2, 7 and 10 have been configured and assigned to VLANs 1, 5, 2 and 3 respectively.

At this point, we should remind you that these 4 VLANs are not able to communicate between each other without the use of a router as they are treated as 4 separate physical networks, regardless of the network addressing scheme used on each of them. However, we won't provide further detail on VLAN routing since it's covered later on.

Static VLANs are certainly more secure than traditional switches while also considerably easy to configure and monitor. As one would expect, all nodes belonging to a VLAN must also be part of the same logical network in order to communicate with one another. For example, on our switch above, if we assigned network 192.168.1.0/24 to VLAN 1, then all nodes connecting to ports assigned to VLAN 1 must use the same network address for them to communicate between each other, just as if this was an ordinary switch.

In addition, Static VLANs have another strong point - you are able to control where your users move within a large network. By assigning specific ports on your switches throughout your network, you are able to control access and limit the network resources to which your users are able to use.

A good example would be a large network with multiple departments where any network administrator would want to control where the users can physically connect their workstation or laptop and which servers they are able to access.

The following diagram shows a VLAN powered network where the switches have been configured with Static VLAN support.

The network diagram might look slightly complicated at first, but if you pay close attention to each switch, you will notice that it's quite simple - six switches with 6 VLANs configured- one VLAN per department, as shown. While each VLAN has one logical network assigned to it, the IT department has, in addition, placed one workstation in the following departments for support purposes: Management, R&D, and HR department.

The network administrator has assigned Port 1 (P1) on each department switch to VLAN 5 for the workstation belonging to the IT department, while the rest of the ports are assigned to the appropriate VLAN as shown in the diagram.

This setup allows the administrator to place any employee in the IT department, anywhere on the network, without worrying if the user will be able to connect and access the IT department's resources.

In addition, if a user in any of the above departments e.g the Management department, decided to get smart by attempting to gain access to the IT department's network and resources by plugging his workstation to Port 1 of his department's switch. He surely wouldn't get far because his workstation would be configured for the 192.168.1.0 network (VLAN 1), while Port 1 requires him to use a 192.168.5.0 network address (VLAN 5). Logically, he would have to change his IP address to match the network he is trying to gain access to, and in this case this would be network 192.168.5.0.

Summary

To sum up, with Static VLANs, we assign each individual switch port to a VLAN. The network addresses are totally up to us to decide. In our example, the switches do not care what network address is used for each VLAN as they totally ignore this information unless routing is performed (this is covered in the InterVLAN routing page). As far as the switches are concerned, if you have two ports assigned to the same VLAN, then these two ports are able to communicate between each other as it would happen on any normal layer 2 switch.

A Comparison With Old Networks

Introduction

Designing and building a network is not a simple job. VLANs are no exception to this rule, in fact they require a more sophisticated approach because of the variety of protocols used to maintain and administer them.

Our aim here is not to tell you how to setup your VLANs and what you should or shouldn't do, this will be covered later on. For now, we would like to show you different physical VLAN layouts to help you recognise the benefits offered when introducing this technology into your network, regardless of its size.

The technology is available and we simply need to figure out how to use it and implement it using the best possible methods, in order to achieve outstanding performance and reliability.

We understand that every network is unique as far as its resources and requirements are concerned, which is another reason why we will take a look at a few different VLAN implementations. However, we will not mention the method used to set them up - this is up to you to decide once you've read the following pages!

Designing your First VLAN

Most common VLAN setups involve grouping departments together regardless of their physical placement through the network. This allows us to centralise the administration for these departments, while also limiting unwanted incidents of unauthorised access to resources of high importance.

As always, we will be using neat examples and diagrams to help you get a visual on what we are talking about.

Let's consider the following company: Packet Industries

Packet Industries is a large scale company with over 40 workstations and 5 servers. The company deals with packet analysis and data recovery and has labs to recover data from different media that require special treatment due to their sensitivity. As with every other company, there are quite a few different departments that deal with different aspects of the business and these are:

• Management/HR Department
• Accounting Department
• Data Recovery & IT Department

These five departments are spread throughout 3 floors in the building the company is situated. Because the IT department takes confidentiality of their own and customer's data seriously, they have decided to redesign their network and also take a look at the VLAN solutions available, to see if they are worth the investment.

We are going to provide two different scenarios here, the first one will not include VLANs, while the second one will. Comparing the two different solutions will help you see the clear advantages of VLANs and also provide an insight to how you can also apply this wonderful technology with other similar networks you might be working with.

Solution 1 - Without VLANs!

The IT department decided that the best way to deal with the security issue would be to divide the existing network by partitioning it. Each department would reside in one broadcast domain and access lists would be placed between each network's boundaries to ensure access to and from them are limited according to the access policies.

Since there are three departments, it is important that three new networks had to be created to accommodate their new design. The budget, as in most cases, had to be controlled so it didn't exceed the amount granted by the Accounting Department.

With all the above in mind, here's the proposal the IT department created:

As you can see, each department has been assigned a specific network. Each level has a dedicated switch for every network available. As a result, this will increase the network security since we have separate physical networks and this solution also seems to be the most logical one. These switches are then grouped together via the network backbone which, in its turn, connects to the network's main router.

The router here undertakes the complex role of controlling access and routing between the networks and servers with the use of access lists as they have been created by the IT Department. If needed, the router can also be configured to allow certain IP's to be routed between the three networks, should there be such a requirement.

The above implementation is quite secure as there are physical and logical restrictions placed at every level. However, it is somewhat restrictive as far as expanding and administering the network since there is no point of central control. Lastly, if you even consider adding full redundancy to the above, essentially doubling the amount of equipment required, the cost would clearly be unreasonable...

So let's now take a look at the second way we could implement the above, without blowing the budget, without compromising our required security level and also at the same time create a flexible and easily expandable network backbone.

Solution 2 - With VLANs!

The solution we are about to present here is surely the most preferred and economical. The reasons should be fairly straight forward: We get the same result as the previous solution, at almost half the cost and as a bonus, we get the flexibility and expandability we need for the future growth of our network, which was very limited in our previous example.

By putting the VLAN concept we covered on the previous page into action, you should be able to visualise the new setup:

As you can see, the results in this example are a lot neater and the most apparent change would be the presence of a single switch per level, connecting directly to the network backbone. These switches of course are VLAN capable, and have been configured to support the three separate logical and physical networks. The router from the previous solution has been replaced by what we call a 'layer 3 switch'.

These type of switches are very intelligent and understand layer 3 (IP Layer) traffic. With such a switch, you are able to apply access-lists to restrict access between the networks, just like you normally would on a router, but more importantly, route packets from one logical network to another! In simple terms, layer 3 switches are a combination of a powerful switch, with a built-in router :)

Summary

If the above example was interesting and provided a insight into the field of VLANs, we can assure you - you haven't seen anything yet. When unleashing the power of VLANs, there are amazing solutions given for any problem or need that your network requires.

It's now time to start looking at the VLAN technology in a bit more detail, that is, how it's configured, the postive and negative areas for each type of VLAN configuration and more much.

The next page analyses Static VLANs which are perhaps the most popular implementation of VLANs around the world. Take a quick break for some fresh air if needed, otherwise, gear up and let's move!

The VLAN Concept - Introduction to VLANs

We hear about them everywhere, vendors around the world are constantly trying to push them into every type of network and as a result, the Local Area Network (LAN) we once knew starts to take a different shape. And yet, for some of us, the concept of what VLANs are and how they work might still be a bit blurry.

To help start clearing things up we will define the VLAN concept not only through words, but through the use of our cool diagrams and at the same time, compare VLANs to our standard flat switched network.

We will start by taking a quick look at a normal switched network, pointing out it's main characteristics and then move on to VLANs.

The Traditional Switched Network

Almost every network today has a switch interconnecting all network nodes, providing a fast and reliable way for the nodes to communicate. Switches today are what hubs were a while back - the most common and necessary equipment in our network, and there is certainly no doubt about that.

While switches might be adequate for most type of networks, they prove inadequate for mid to large sized networks where things are not as simple as plugging a switch into the power outlet and hanging a few Pc's from it!

For those of you who have already read our "switches and bridges" section, you will be well aware that switches are layer 2 devices which create a flat network:

The above network diagram illustrates a switch with 3 workstations connected. These workstations are able to communicate with each other and are part of the same broadcast domain, meaning that if one workstation were to send a broadcast, the rest will receive it.

In a small network multiple broadcast might not be too much of a problem, but as the size of the network increases, so will the broadcasts, up to the point where they start to become a big problem, flooding the network with garbage (most of the times!) and consuming valuable bandwidth.

To visually understand the problem, but also the idea of a large flat network, observe the diagram below:

The problem here starts to become evident as we populate the network with more switches and workstations. Since most workstations tend to be loaded with the Windows operating system, this will result in unavoidable broadcasts being sent occasionaly on the network wire - something we certainly want to avoid.

Another major concern is security. In the above network, all users are able to see all devices. In a much larger network containing critical file servers, databases and other confidential information, this would mean that everyone would have network access to these servers and naturally, they would be more susceptible to an attack.

To effectively protect such systems from your network you would need to restrict access at the network level by segmenting the exisiting network or simply placing a firewall in front of each critical system, but the cost and complexity will surely make most administrators think twice about it. Thankfully there is a solution ..... simply keep reading.

Introducing VLANs

Welcome to the wonderful world of VLANs!

All the above problems, and a lot more, can be forgotten with the creation of VLANs...well, to some extent at least.

As most of you are already aware, in order to create (and work with) VLANs, you need a layer 2 switch that supports them. A lot of people new to the networking field bring the misconception that it's a matter of simply installing additional software on the clients or switch, in order to "enable" VLANs throughout the network - this is totally incorrect!

Because VLANs involve millions of mathematical calculations, they require special hardware which is built into the switch and your switch must therefore support VLANs at the time of purchase, otherwise you will not be able to create VLANs on it!

Each VLAN created on a switch is a separate network. This means that a separate broadcast domain is created for each VLAN that exists. Network broadcasts, by default, are filtered from all ports on a switch that are not members of the same VLAN and this is why VLANs are very common in today's large network as they help isolate network segments between each other.

To help create the visual picture on how VLANs differentiate from switches, consider the following diagram:

What we have here is a small network with 6 workstations attached to a VLAN capable switch. The switch has been programmed with 2 VLANs, VLAN1 and VLAN2 respectfully, and 3 workstations have been assigned to each VLAN.

VLANs = Separate Broadcast Domains

With the creation of our VLANs, we have also created 2 broadcast domains. This mean that if any workstation in either VLAN sends a broadcast, it will propagate out the ports which belong to the same VLAN as the workstation that generated the broadcast:

This is clearly illustrated in the diagram above where Workstation 1, belonging to VLAN1, sends a network broadcast (FF:FF:FF:FF:FF:FF). The switch receives this broadcast and forwards it to Workstation 2 and 3, just as it would happen if these three workstations were connected to a normal switch, while the workstations belonging to VLAN2 are totally unaware of the broadcast sent in VLAN1 as they do not receive any packets flowing in that network.

To help clear any questions or doubts on how the above setup works, the diagram below shows the logical equivalent setup of our example network:

By this stage, you should begin seeing the clear advantages offered by the use of VLANs within your network. Security, cost and network traffic are reduced as more hosts are added to the network and the number of VLANs are increased.

VLANs Help Reduce The Cost

To briefly touch upon the financial side of things, let's take an example to see exactly how we are saving money by using VLANs.

Consider you're the network administrator for a large company and you have been asked to split the existing network infrastructure into 12 seperate networks, but without the possibility of these new networks to communicate between each other. Since the cabling is already in place, we need to simply group the ports of each network we create to one physical switch and for the 12 network, a total of 12 switches will be required.

By using VLANs, the above task would be possible with one or more VLAN capable switches that will cover the number of hosts we need to connect to them, and the cost would surely be a lot less than that compared to 12 switches.

During the implementation of the above task, you would connect all workstations to the switch and then assign the appropriate workstations/nodes to their respectful VLAN, creating a total of 12 VLANs. It is worth noting here that most entry level VLAN switches e.g Cisco 2900 series, are capable of handling up to 64 VLANs, so if we were to use these switches, we would still have plently of room to create more.

Switch Model	Maximum VLANs Supported	VLAN Trunking Supported
Catalyst 2912 XL, Catalyst 2924 XL & Catalyst 2924C XL	64	yes
Catalyst 2900 LRE XL	250	yes
Catalyst 2912M and Catalyst 2924M modular	250	yes
Catalyst 3500 XL & 3550	250	yes

There are a lot more examples one can use to show how these new generation switches are able to solve complex network designs, security issues and at the same time, keep the budget low. Lastly, the best example is one that is able to solve your own requirements, so take a minute to think about it and you will surely agree.

Summary

This page introduced the concept of VLANs and indicated the differences existing between them and normal switched networks. We also briefly examined their efficiency in terms of cost, security and implementation.

The information here serves as an introduction to the VLAN technology and we will now start diving deeper into the topic, analysing it in greater detail. Having said that, our next page deals with the design of VLANs, showing different logical and physical configurations of VLANs within networks. So, make yourself comfortable and let's continue cause there is still so much to cover!

VLAN Security Tips - Best Practices

This article focuses on VLAN Security and its implementation within the business network environment. We provide tips and Cisco CLI commands that will help you upgrade your VLAN network security.

Even though many Administrators and IT Managers are aware of VLAN technologies and concepts, unfortunately, it has been proven that the same does not apply when it comes to VLAN Security. While this section mainly focuses on security implemented on Cisco switches, many of the concepts can be applied on other vendor switches.

The first principle in securing a VLAN network is physical security. If you do not want your devices to be tampered with, physical access to the device must be strictly controlled. Core switches are usually safely located in a datacenter with restricted access, however edge switches are not that lucky and are usually placed in areas where they are left exposed.

Just as physical security guidelines require equipment to be in a controlled space, VLAN-based security requires the usage of special tools and following a few ‘best security practices’ to give the desired result.

Let’s take a look at a few important steps an Administrator or IT Manager can take, to strip their network from the security problems most networks suffer today:

Removal of Console-port Cables, Introduction of Password-Protected Console/Vty Access with Specified Timeouts and Restricted Access.

Console ports on the back side of Cisco switches provide direct access to the system. If no care is taken to secure this access method, then the switch might remain fully exposed to anyone with the popular ‘blue console cable’. Configuration of complex user credentials on the console and telnet/ssh ports will ensure any unwanted visitor will remain in the dark when trying to access the device. Using special commands such as the ‘exec-timeout’ commands, when the Administrator accidently forgets to logout of the session, it will automatically timeout after the programmed timeout value.

Following is a set of commands that will help you accomplish the above measures to help restrict access to the swich:

Switch# configure terminal
Switch(config)# username admin privilege 15 secret *Firewall.cx*
Switch(config)# line console 0
Switch(config-line)# login local
Switch(config-line)# password cisco
Switch(config-line)# exec-timeout 60 0

We also apply the same commands to our VTY (telnet/ssh) section and create an access-list 115 to restrict telnet/ssh access from specific networks & hosts:

Switch (config)# line vty 0 15
Switch (config-line)# password cisco
Switch (config-line)# login local
Switch (config-line)# exec-timeout 60 0
Switch (config-line)# transport preferred ssh
Switch (config-line)# access-class 115 in

Following is the access-list 115 we created:

Switch (config)# access-list 115 remark -=[Restrict VTY Access]=-
Switch (config)# access-list 115 permit ip host 74.200.84.4 any
Switch (config)# access-list 115 permit ip host 69.65.126.42 any
Switch (config)# access-list 115 permit ip 192.168.50.0 0.0.0.255 any
Switch (config)# access-list 115 remark

Always ensure the use of the ‘secret’ parameter rather than the ‘password’ parameter in your username syntax, when defining usernames and their passwords. The classic ‘password’ parameter uses a much weaker encryption algorithm that is easily unencrypted.

To demonstrate this, you can use the 'password' parameter and then copy past the encrypted password into our popular Cisco Type 7 Password decrypt page and see what happens!

Avoid Using VLAN1 (Default VLAN) for your Network Data

VLAN 1 is a special VLAN selected by design to carry specific information such as CDP (Cisco Discovery Protocol), VTP, PAgP and more. VLAN 1 was never intended to be used as standard VLAN to carry network data.

By default configuration, any Access Link on a Cisco switch is set to VLAN 1, causing a major security issue as direct access to the network backbone is given. As a consequence, VLAN 1 can end up unwisely spanning the entire network if not appropriately pruned.

The practice of using a potentially omnipresent VLAN for management purposes puts trusted devices to higher risk of security attacks from untrusted devices that by misconfiguration or pure accident gain access to VLAN 1 and try to exploit this unexpected security hole.

As a general rule of thumb, the network Administrator should prune any VLAN, and in particular VLAN 1 from all ports where that VLAN is not needed.

The following example prunes VLANs 1 to 5 and 7 to 8, allowing access only to VLAN 6 when in trunking mode. Furthermore, we assign the port to VLAN 6 only:

Switch(config)# interface fastethernet0/24
Switch(config-if)# switchport trunk allowed vlan remove ? (help)
WORD VLAN IDs of disallowed VLANS when this port is in trunking mode

Switch(config-if)# switchport trunk allowed vlan remove 1,2,3,4,5,7,8
Switch(config-if)# switchport access vlan 6

Disable High-Risk Protocols on any Port That Doesn’t Require Them

If a port is connected to a ‘foreign’ device, don’t try to speak its language – it could be turned to someone else’s advantage and used against your network. Ensure you disable protocols such as CDP, DTP, PAgP, UDLD (Unidirectional Link Detection Protocol) and always enable spanning-tree portfast & bpduguard on the port.

Here is an example on how to disable the above mentioned protocols and enable spanning-tree portfast bpduguard:

Switch(config)# interface fastethernet0/24
Switch(config-if)# no cdp enable
Switch(config-if)# no udld port
Switch(config-if)# spanning-tree portfast
Switch(config-if)# spanning-tree bpduguard enable
Switch(config-if)# spanning-tree guard root

Finally, if the port is not to be used, issue the ‘shutdown’ command to ensure it won’t be accessed by anyone without the proper authorisation.

VTP Domain, VTP Pruning and Password Protection

Two choices exists here – either configure the VTP domain appropriately or turn off VTP altogether! VTP is a great tool that ensures all VLAN information is carried to your network switches. If necessary security measures are not taken, wiping your network-wide VLAN configuration is as easy as connecting a switch with the ‘proper’ devastating configuration.

A switch configured with the same ‘VTP domain’, a role type of ‘Server’ and a higher ‘VTP revision’ number of the real VTP server (usually the core switch), is all that’s required to cause major disruption and panic across any network size. All other switches will automatically ‘listen’ to the new ‘VTP Server’ and wipe all existing VLAN information. You can then start looking for a new job.

A few simple self-explanatory commands on your core switch will help ensure the above scenario is avoided:

CoreSwitch(config)# vtp domain firewall.cx
CoreSwitch(config)# vtp password fedmag secret
CoreSwitch(config)# vtp mode server
CoreSwitch(config)# vtp version 2
CoreSwitch(config)# vtp pruning

Edge switches will require the ‘vtp mode client’ and ‘vtp password’ command, after which they will automatically receive all necessary VLAN information from your core switch.

You can verify the configuration using the ‘show vtp status’ command:

CoreSwitch # show vtp status
VTP Version capable : 1 to 3

VTP version running : 2

VTP Domain Name : firewall.cx

VTP Pruning Mode : Enabled

VTP Traps Generation : Disabled

Device ID : c062.6b10.5600

Configuration last modified by 192.168.50.1 at 3-16-11 16:53:48

Local updater ID is 192.168.50.1 on interface Vl1 (lowest numbered VLAN interface found)

Feature VLAN:

--------------

VTP Operating Mode : Server

Maximum VLANs supported locally : 1005

Number of existing VLANs : 8

Configuration Revision : 25

MD5 digest : 0xDD 0x9D 0x3B 0xA0 0x80 0xD8 0x7A 0x3A

0x1F 0x2F 0x2A 0xDB 0xCD 0x84 0xCE 0x5F

Control Inter-VLAN Routing Using IP Access Lists

Inter-VLAN routing is a great and necessary feature. Because in many cases there is the need to isolate VLANs or restrict access between them, the usage of IP Access lists is mandatory.

IP Access lists should be created in such a way, that they allow the normal flow of traffic between VLANs, but do not expose the networks that need to be protected. Once the Access Lists are created, they are applied directly on the VLAN interface of the core layer-3 switch. All traffic from the designated VLAN trying to pass to other VLANs will be denied according to the Access Lists, making sure the core network is not exposed.

Let’s take a common example to make this tip more practical.

You’ve created a new guest VLAN (VLAN 6 – Network 192.168.141.0/24) to provide free Internet access to your company visitors. The requirement is to allow full Internet access, but restrict access to other VLANs. In addition, configuration of a DHCP server is also deemed necessary, to make your life easier and less troublesome.

Here’s the configuration used for the DHCP server serving this VLAN:

CoreSwitch(config)# ip dhcp pool vlan6-Guest-Internet
CoreSwitch(dhcp-config)# network 192.168.141.0 255.255.255.0
CoreSwitch(dhcp-config)# dns-server 192.168.130.5
CoreSwitch(dhcp-config)# default-router 192.168.141.1

Note that 192.168.141.1 is our core switch VLAN 6 IP Address, and 192.168.130.5 is our DNS server located on a different VLAN.

Next, we create our necessary Access Lists.

CoreSwitch(config)# access-list 100 remark --[Allow Guest DNS requests to DNS Server]--
CoreSwitch(config)# access-list 100 permit udp 192.168.141.0 0.0.0.255 host 192.168.130.5 eq 53
CoreSwitch(config)# access-list 100 remark [Necessary for DHCP Server to receive Client requests]
CoreSwitch(config)# access-list 100 permit udp any any eq bootps
CoreSwitch(config)# access-list 100 permit udp any any eq bootpc
CoreSwitch(config)# access-list 100 remark --[Deny Guest Access to other VLANs]--
CoreSwitch(config)# access-list 100 deny ip 192.168.141.0 0.0.0.255 192.168.50.0 0.0.0.255 log
CoreSwitch(config)# access-list 100 deny ip 192.168.141.0 0.0.0.255 192.168.130.0 0.0.0.255 log
CoreSwitch(config)# access-list 100 deny ip 192.168.141.0 0.0.0.255 192.168.135.0 0.0.0.255 log
CoreSwitch(config)# access-list 100 deny ip 192.168.141.0 0.0.0.255 192.168.160.0 0.0.0.255 log
CoreSwitch(config)# access-list 100 deny ip 192.168.141.0 0.0.0.255 192.168.131.0 0.0.0.255 log
CoreSwitch(config)# access-list 100 deny ip 192.168.141.0 0.0.0.255 192.168.170.0 0.0.0.255 log
CoreSwitch(config)# access-list 100 deny ip 192.168.141.0 0.0.0.255 192.168.180.0 0.0.0.255 log
CoreSwitch(config)# access-list 100 remark --[Permit Guest Access to everywhere else –Internet ]--
CoreSwitch(config)# access-list 100 permit ip 192.168.141.0 0.0.0.255 any
CoreSwitch(config)# access-list 100 remark

Notice that we permit DNS and DHCP requests initially, and then deny access to all VLANs. Finally we permit access everywhere else. This logical structure of our Access List is built to comply with the Top-Down Access List examination performed by the Core switch.

If we were to place the DNS or Bootp last in the Access List, it would clearly fail as the deny statements would prevail. Finally, the ‘log’ parameter seen on our deny statements would trigger a log entry on our core switch, allowing us to catch any guests trying persistently to access our other VLANs

Last step would be to apply the access-list to the newly created VLAN interface, in the ‘incoming’ direction:

CoreSwitch(config)# interface vlan 6
CoreSwitch (config-if)# ip access-group 100 in

Article Summary

VLAN Technology is wonderful – it offers great enhancements to the network and provides paths to run multiple services in isolated environments without sacrificing speed, quality and network availability. If the necessary basic security guidelines are taken in consideration during its initial implementation and ongoing administration, it can perform wonders and dramatically reduce the administrative overhead from your IT Administrators or Managers. On other hand, if these security guidelines are ignored, the imminent exposure of the whole network is at risk and simply a matter of time.

Perhaps the most serious mistake that an IT Administrator or Manager can make, is to underestimate the importance of the DataLink layer, and of VLANs in particular, in the architecture of switched networks.

It should not be forgotten that any network is only as robust as its weakest link, and that therefore an equal amount of attention should be given to any of its layers, to make sure that its entire structure is sound.

Related Articles

How To Configure Router On A Stick - 802.1q Trunk To Router

Router-on-a-stick is a term frequently used to describe a setup up that consists of a router and switch connected using one Ethernet link configured as an 802.1q trunk link. In this setup, the switch is configured with multiple VLANs and the router performs all routing between the different networks/VLANs.

While some believe the term 'router-on-a-stick' sounds a bit silly, it's a very popular term and commonly used in networks where no layer-3 switch exists. A good example of a router-on-a-stick configuration (which also happens to be the one we are going to cover) would be a Call Manager Express installation where there is the need to split the VoIP network, consisting of your Cisco IP Phone devices, from your data network where all workstations and servers are located.

Example Scenario

Our example is based on a scenario you are most likely to come across when dealing with VoIP networks. Because VoIP implementations require you to separate the data and voice network in order to route packets between them, you need either a layer 3 switch or a router. This configuration ensures availability and stability of the VoIP service, especially during peak traffic hours in your network.

Packets running between VLANs are routed via the CCME router connected to the switch using one physical port configured as a trunk port on both ends (switch and router). If you would like to read more on VLAN routing and VLAN theory, you can visit our popular VLAN Section that covers all related topics and terms found in this article.

This example will show you how to configure a Cisco router and switch in order to create a trunk link between them and have the router route packets between your VLANs.

This diagram shows an illustration of the above configuration.

STEP 1 - Switch Configuration

First step is to create the required two VLANs on our Cisco switch and configure them with an IP address:

SW1# configure terminal
SW1(config)# interface vlan1
SW1(config-if)# description Data Vlan
SW1(config-if)# ip address 192.168.0.2 255.255.255.0
SW1(config-if)# exit
SW1(config)# interface vlan2
SW1(config-if)# description Voice Vlan
SW1(config-if)# ip address 192.168.2.2 255.255.255.0
SW1(config-if)# exit

Next, we need to create the trunk port that will connect to the router. For this purpose, we've selected port GigabitEthernet 0/1 (port 1):

SW1# configure terminal
SW1(config)# interface gigabitethernet 0/1
SW1(config-if)# description Trunk-to-Router
SW1(config-if)# switchport trunk encapsulation dot1q
SW1(config-if)# switchport mode trunk
SW1(config-if)# spanning-tree portfast

To eliminate confusion, these commands are instructing the switch thus:

1) Define the trunk to use the 802.1q protocol

2) Set the specific port to 'trunk mode'

3) Enable the spanning-tree 'portfast' function to ensure the port will forward packets immediately when connected to a device e.g router.

The above steps complete the switch-side configuration.

STEP 2 - Router Configuration

We need to follow a similar configuration for our router to enable communication with our switch and allow all VLAN traffic to pass through and route as necessary.

Creating a trunk link on a router port is not very different from the process used above - while we create the trunk port on one physical interface, we are required to create a sub-interface for each VLAN.

Again, this is a fairly simple process and easy to understand once you've done it at least one time.

R1# configure terminal
R1(config)# interface gigabitethernet0/1
R1(config-if)# no ip address
R1(config-if)# duplex auto
R1(config-if)# speed auto
R1(config-if)# interface gigabitethernet0/1.1
R1(config-subif)# description Data VLAN
R1(config-subif)# encapsulation dot1q 1 native
R1(config-subif)# ip address 192.168.0.1 255.255.255.0
R1(config-subif)# ip nat inside
R1(config-subif)# ip virtual-reassembly
R1(config-subif)# interface gigabitethernet0/1.2
R1(config-subif)# description Voice VLAN
R1(config-subif)# encapsulation dot1q 2
R1(config-subif)# ip address 192.168.2.1 255.255.255.0
R1(config-subif)# ip nat inside
R1(config-subif)# ip virtual-reassembly

In order to form a trunk link with our switch it is necessary to create one sub-interface for every VLAN configured on our switch. After creating the sub-interface, we assign an IP address to it and set the encapsulation type to 802.1q along with the VLAN to which the subinterface belongs.

For example, the encapsulation dot1q 2 command defines 802.1q encapsulation and sets the subinterface to VLAN 2. The native parameter we used for subinterface gigabitethernet0/1.1 tells the router that the native vlan is VLAN 1. This is a default parameter on every Cisco switch and therefore must be matched by the router as well.

The ip virtual-reassembly command is usually automatically thrown in by the Cisco IOS (we've included it to show you the command) and is a security measure to avoid buffer overflow and control memory usage during an attack of fragmented packets which can cough up your router's resources. This command is added automatically when you enable the NAT service using the ip nat inside command. More information on NAT configuration can be obtained by our Cisco Router NAT Configuration articles.

Article Summary

This article explained the use of router-on-a-stick configurations and showed how you can configure an 802.1q trunk link between a Cisco switch and router. Router-on-a-stick configurations are extremely useful in environments where no layer-3 switch exists, providing Inter-VLAN routing services with a single router and one interface - cutting down seriously the costs for internal routing.

It is always preferable to use a router with a Gigabit Ethernet interface to ensure you've got plenty of bandwidth to handle large amounts of data transfers if needed.

If you have found the article useful, we would really appreciate you sharing it with others by using the services provided at the top left corner of this article. Sharing our articles takes only a minute of your time and helps Firewall.cx reach more people through such services.

Configuring Policy-Based Routing (PBR) with IP SLA Tracking - Auto Redirecting Traffic

What is Policy-Based Routing?

Policy-Based Routing (PBR) is a very popular feature in Cisco routers, it allows the creation of policies that can selectively alter the path that packets take within the network. Policy-Based Routing can be used to mark packets so that certain types of traffic are prioritized over the rest, sent to a different destination or exist via a different physical interface on the router.

Classification of interesting traffic is performed using Access-Control Lists (ACLs). These can be standard, extended or named access lists as we know them.

Once the interesting traffic is ‘matched’ with the use of ACLs, the router will perform the configured ‘set’ function which is defined by the Administrator. This ‘set’ function essentially tells the router what to do with the matched traffic and can include sending it to another gateway, dropping it, prioritizing it over other traffic, and much more.

Policy-Based Routing with IP SLA Monitoring for Automatic Fail-over

This article will show how to use Policy-Based Routing to mark a specific type of traffic, for example http, and redirect it to a web proxy (usually Linux Squid) so all network web traffic is automatically filtered through the proxy.

In such setups, network users have no knowledge of the proxy’s existence as they are not required to configure their web browser to use the proxy. All user traffic is forwarded to a single gateway (Cisco ASA Firewall) and from there to router R1. This example can serve as a good solution for how to create a transparent proxy with automatic failover.


Router R1, with the help of Policy-Based Routing, ‘marks’ all http traffic and then performs the appropriate ‘set’ function, which is to redirect the selected traffic to the Linux proxy with IP address 192.168.150.2.

The Linux proxy accepts the traffic, makes the necessary checks defined by the Administrator and forwards it to the Internet via R2 router.

To complement our solution we’ve added IP SLA tracking so that R1 will continuously monitor the Linux proxy to ensure it has not failed or gone offline. If for any reason router R1 loses connectivity with the Linux proxy, the IP SLA & Policy-Based Routing mechanism will stop redirecting http traffic to it and forward it directly to the Internet via R2, effectively bypassing the failed proxy.

The next diagram shows how router R1 will respond to a failure of the Linux proxy as described above:

This solution smartly combines Cisco's Policy-Based Routing with IP SLA tracking and provides a number of benefits, some of which are:

• Automatic redirection of selected (http) traffic to the Linux Proxy.
• Transparent web proxy to all network users, with web filtering according to company policy.
• Automatic failover in case proxy fails. Near-zero downtime.
• Continuous monitoring of proxy after failure – automatic recovery if proxy is back online.

Note: More examples of IP SLA Tracking can be found in our Configuring Static Route Tracking using IP SLA (Basic) article.

How to Configure IP SLA Tracking for a Host

First step is to configure IP SLA tracking for the desired host. This will ensure R1 router will continuously monitor the Linux proxy and stop redirecting http traffic to it in the event it fails:

R1(config)# ip sla 1
R1(config-ip-sla)# icmp-echo 192.168.150.2
R1(config-ip-sla)# frequency 4
R1(config-ip-sla)# timeout 2000
R1(config-ip-sla)# threshold 100
R1(config-ip-sla)# ip sla schedule 1 life forever start-time now

The above configuration defines and starts an IP SLA probe on router R1.

The ICMP Echo probe sends an ICMP Echo (ping) packet to IP 192.168.150.2 every 4 seconds, as defined by the frequency parameter.

Timeout sets the amount of time (in milliseconds) for which the Cisco IOS IP SLAs operation waits for a response from its request packet. This has been set to 2000 milliseconds, or 2 seconds which gives the host ample time to respond.

Threshold sets the rising threshold that generates a reaction event and stores history information for the Cisco IOS IP SLAs operation.

After defining the IP SLA operation, our next step is to define an object that tracks the SLA probe. This can be accomplished by using the IOS Track Object as shown below:

R1(config)# track 1 ip sla 1 reachability

The above command will track the state of the IP SLA operation. If there are no ping responses from the monitored IP address (192.168.150.2), the track will go down and it will come back up when the ip sla operation starts receiving ping responses once again.

To verify the track status, use the “show track” command as shown below:

R1# show track 1
Track 1
IP SLA 1 reachability
Reachability is Up
30 changes, last change 1d08h
Latest operation return code: OK
Latest RTT (millisecs) 1
Tracked by:
ROUTE-MAP 0

The command output verifies that the tracked object is UP and has a response time of 1ms. A closer look shows that for the duration of the tracking, the state has changed 30 times and the last change was 1 day and 8 hours ago. This information is extremely important should it be necessary to troubleshoot intermittent problems that might be reported by the users.

How to Configure Policy-Based Routing to Redirect Selected (http) Traffic

Once we have IP SLA up and running, the next step is to configure PBR so we can redirect http traffic.

First, we need to use Access-Control Lists to select the traffic we want to redirect. Keep in mind that PBR does not limit the type of ACL that can be used. This means you can use IP named ACLs, standard ACLs, extended ACLs, time-based ACLs and others. In our example we are going to use IP named ACLs:

R1(config)# ip access-list extended http-traffic
R1(config)# permit tcp 192.168.5.0 0.0.0.255 any eq www

We've decided to name our IP-named ACL 'http-traffic'. This unique ACL name will be used later on in our route-map. By making the appropriate changes in the ACLs we can define different types of traffic that will be redirected. In our example all http traffic from the 192.168.5.0 network that is destined to the Internet (any) is selected.

Now we must create a route-map that will use the above defined ACLs and instruct the router to redirect the traffic to the Linux proxy:

R1(config)# route-map linux-proxy permit 1
R1(config-route-map)# match ip address http-traffic
R1(config-route-map)# set ip next-hop verify-availability 192.168.150.2 1 track 1

The above command creates a permissive route-map named linux-proxy. The match IP address parameter within the route-map informs the router which set of ACLs defines the traffic we are interested in. Since we've defined our interesting traffic using IP named ACLs, all we need to do is reference the name of our ACL previously created.

The last command configures the route map to verify the reachability of the tracked object (192.168.150.2). If the tracked object is reachable (IP SLA reports it is reachable), then our policy-based route will redirect the defined traffic to it. If the tracked object is not reachable, (IP SLA reports the host is not reachable - down) then our policy-based route will stop redirecting traffic.

Applying the Policy-Based Route

We are almost done. The very last step is to enable and identify the route-map to be use for policy routing. This is performed by selecting the router interface for which the policy routing will be enabled, and applying the policy-route:

R1(config)# interface Vlan1

R1(config-int)# ip policy route-map linux-proxy

In our scenario, R1's VLAN1 interface is connected to the 192.168.150.0/24 network where our ASA and Linux proxy reside so we apply the policy routing to that.

Route-Map & IP SLA Statistics

Keeping a close eye on the router's route-map & IP SLA performance can be achieved with the use of a few simple commands. Monitoring your route-map's performance the first couple of days is a very good idea as it will help verify that traffic is still being redirected to the host.

On the other hand, looking at IP SLA statistics will help identify possible failures or changes of state which were not noticed by anyone.

The show route-mapcommand is a favourite as it combines enough information to help verify everything is working as it should:

R1# show route-map

route-map linux-proxy, permit, sequence 1

Match clauses:

ip address (access-lists): http-traffic

Set clauses:

ip next-hop verify-availability 192.168.150.10 1 track 1 [up]

Policy routing matches: 3864291 packets, 511957007 bytes

The numbers shown here verify immediately that our host is reachable (up) and that R1 has redirected more than 510MB of traffic through the Linux proxy!

The show IP SLA statistics command provides in a similar way useful information that helps verify the object tracking is working correctly and the tracked host is up:
R1# show ip sla statistics
IPSLAs Latest Operation Statistics

IPSLA operation id: 1
Latest RTT: 1 milliseconds
Latest operation start time: *21:36:47.855 UTC Tue Apr 3 2012
Latest operation return code: OK
Number of successes: 16
Number of failures: 0
Operation time to live: Forever