InterVLAN Routing
Introduction
Surely most of you network gurus would agree without a doubt that the invention of VLANs for networks are as good, if not better, as the invention of the mouse for computers!
Being able to create new network segments using the existing backbone and without rewiring is, for most administrators, a dream come true! Add the ability to move users or deparments between these networks with a just few keystrokes and you're in paradise.
VLANs have certainly become popular and are very welcomed in every administrator's or engineer's network. However, they also raised several issues which troubled many of us. One major issue concerns routing between existing and newly created VLANs.
The Need For Routing
Each network has it's own needs, though whether it's a large or small network, internal routing, in most cases, is essential - if not critical. The ability to segment your network by creating VLANs, thus reducing network broadcasts and increasing your security, is a tactic used by most engineers. Popular setups include a separate broadcast domain for critical services such as File Servers, Print servers, Domain Controllers e.t.c, serving your users non-stop.
The issue here is how can users from one VLAN (broadcast domain), use services offered by another VLAN?
Thankfully there's an answer to every problem and in this case, its VLAN routing:
The above diagram is a very simple but effective example to help you get the idea. Two VLANs consisting of two servers and workstations of which one workstation has been placed along with the servers in VLAN 1, while the second workstation is placed in VLAN 2.
In this scenario, both workstations require access to the File and Print servers, making it a very simple task for the workstation residing in VLAN 1, but obviously not for our workstation in VLAN 2.
As you might have already guessed, we need to somehow route packets between the two VLANs and the good news is that there is more than one way to achieve this and that's what we'll be covering on this page.
VLAN Routing Solutions
While the two 2924 Catalyst switches are connected via a trunk link, they are unable to route packets from one VLAN to another. If we wanted the switch to support routing, we would require it to be a layer 3 switch with routing capabilities, a service offered by the popular Catalyst 3550 series and above.
Since there are quite a few ways to enable the communcation between VLANs (InterVLAN Routing being the most popular) there is a good chance that we are able to view all possible solutions. This follows our standard method of presenting all possible solutions, giving you an in-depth view on how VLAN routing can be setup, even if you do not have a layer 3 switch.
Note: The term 'InterVLAN Routing' refers to a specific routing method which we will cover as a last scenario, however it is advised that you read through all given solutions to ensure you have a solid understanding on the VLAN routing topic.
VLAN Routing Solution No.1: Using A Router With 2 Ethernet Interfaces
A few years ago, this was one of the preferred and fastest methods to route packets between VLANs. The setup is quite simple and involves a Cisco router e.g 2500 series with two Ethernet interfaces as shown in the diagram, connecting to both VLANs with an appropriate IP Address assigned to each interface. IP Routing is of course enabled on the router and we also have the option of applying access lists in the case where we need to restrict network access between our VLANs.
In addition, each host (servers and workstations) must either use the router's interface connected to their network as a 'default gateway' or a route entry must be created to ensure they use the router as a gateway to the other VLAN/Network. This scenario is however expensive to implement because we require a dedicated router to router packets between our VLANs, and is also limited from an expandability prospective.
In the case where there are more than two VLANs, additional Ethernet interfaces will be required, so basically, the idea here is that you need one Ethernet interface on your router that will connect to each VLAN.
To finish this scenario, as the network gets bigger and more VLANs are created, it will very quickly get messy and expensive, so this solution will prove inadequate to cover our future growth.
VLAN Routing Solution No.2: Using A Router With One Ethernet (Trunk) Interface
This solution is certainly fancier but requires, as you would have already guessed, a router that supports trunk links. With this kind of setup, the trunk link is created, using of course the same type of encapsulation the switches use (ISL or 802.1q), and enabling IP routing on the router side.
The downside here is that not many engineers will sacrifice a router just for routing between VLANs when there are many cheaper alternatives, as you will soon find out. Nevertheless, despite the high cost and dedicated hardware, it's still a valid and workable solution and depending on your needs and available equipment, it might be just what you're looking for!
Closing this scenario, the router will need to be configured with two virtual interfaces, one for each VLAN, with the appropriate IP Address assigned to each one so routing can be performed.
VLAN Routing Solution No.3: Using A Server With Two Network Cards
We would call this option a "Classic Solution". What we basically do, is configure one of the servers to perform the routing between the two VLANs, reducing the overal cost as no dedicated equipment is required.
In order for the server to perform the routing, it requires two network cards - one for each VLAN and the appropriate IP Addresses assigned, therefore we have configured one with IP Addresses 192.168.1.1 and the other with 192.168.2.1. Once this phase is complete, all we need to do is enable IP routing on the server and we're done.
Lastly, each workstation must use the server as either a gateway, or a route entry should be created so they know how to get to the other network. As you see, there's nothing special about this configuration, it's simple, cheap and it gets the job done.
VLAN Routing Solution No.4: InterVLAN Routing
And at last.... InterVLAN routing! This is without a doubt the best VLAN routing solution out of all of the above. InterVLAN routing makes use of the latest in technology switches ensuring a super fast, reliable, and acceptable cost routing solution.
The Cisco Catalyst 3550 series switches used here are layer 3 switches with built-in routing capabilities, making them the preferred choice at a reasonable cost. Of course, the proposed solution shown here is only a small part of a large scale network where switches such as the Catalyst 3550 are usually placed as core switches, connecting all branch switches together (2924's in this case) via superfast fiber Gigabit or Fast Ethernet links, ensuring a fast and reliable network backbone.
We should also note that InterVLAN routing on the Catalyst 3550 has certain software requirements regarding the IOS image loaded on the switch as outlined on the table below:
Image Type & Version / InterVLAN Routing CapabilityEnhanced Multilayer Image (EMI) - All Versions / YES
Standard Multilayer Image (SMI) - prior to 12.1(11)EA1 / NO
Standard Multilayer Image (SMI) - 12.1(11)EA1 and later / YES
If you happen to have a 3550 Catalyst in hand, you can issue the 'Show version' to reveal your IOS version and find out if it supports IP routing.
In returning to our example, our 3550 Catalyst will be configured with two virtual interfaces, one for each VLAN, and of course the appropriate IP Address assigned to them to ensure there is a logical interface connected to both networks. Lastly, as you might have guessed, we need to issue the 'IP Routing' command to enable the InterVLAN Routing service!
The diagram above was designed to help you 'visualise' how switches and their interfaces are configured to specific VLAN, making the InterVLAN routing service possible. The switch above has been configured with two VLANs, VLAN 1 and 2. The Ethernet interfaces are then assigned to each VLAN, allowing them to communicate directly with all other interfaces assigned to the same VLAN and the other VLAN, when the internal routing process is present and enabled.
Access Lists & InterVLAN Routing
Another common addition to the InterVLAN routing service is the application of Access Lists (packet filtering) on the routing switch,to restrict access to services or hosts as required.
In modern implementations, central file servers and services are usually placed in their own isolated VLAN, securing them from possible network attacks while controlling access to them. When you take into consideration that most trojans and viruses perform an initial scan of the network before attacking, an administrator can smartly disable ICMP echoes and other protocols used to detect a live host, avoiding possible detection by an attacker host located on a different VLAN.
Summary
InterVLAN is a terrific service and one that you simply can't live without in a large network. The topic is a fairly easy one once you get the idea, and this is our aim here, to help you get that idea, and extend it further by giving you other alternative methods.
The key element to the InterVLAN routing service is that you must have at least one VLAN interface configured with an IP Address on the InterVLAN capable switch, which will also dictate the IP network for that VLAN. All hosts participating in that VLAN must also use the same IP addressing scheme to ensure communication between them. When the above requirements are met, it's then as simple as enabling the IP Routing service on the switch and you have the InterVLAN service activated.
Next in line is the Virtual Trunk Protocol (VTP), a protocol that ensures every administrator's and engineer's life remains nice and easy .... how can this be possible?
Introduction To The Virtual Trunk Protocol - VTPIntroduction
The invention of VLANs was very much welcomed by all engineers and administrators, allowing them to extend, redesign and segment their existing network with minimal costs, while at the same time making it more secure, faster and reliable!
If you're responsible for a network of up to 4-6 switches that include a few VLANs, then you'll surely agree that it's usually a low overhead to administer them and periodically make changes - most engineers can live with that:)
Ask now an engineer who's in charge of a medium to a large scale network and you will definately not receive the same answer, simply because these small changes can quickly become a nightmare and if you add the possibility of human error, then the result could be network outages and possibly downtime.
Welcome To Virtual Trunk Protocol (VTP)
VTP, a Cisco proprietary protocol, was designed by Cisco with the network engineer and administrator in mind, reducing the administration overhead and the possibility of error as described above in any switched network environment.
When a new VLAN is created and configured on a switch without the VTP protocol enabled, this must be manually replicated to all switches on the network so they are all aware of the newly created VLAN. This means that the administrator must configure each switch separately, a task that requires a lot of time and adds a considerable amount of overhead depending on the size of the network.
The configuration of a VLAN includes the VLAN number, name and a few more parameters which will be analysed further on. This information is then stored on each switch's NVRAM and any VLAN changes made to any switch must again be replicated manually on all switches.
If the idea of manually updating all switches within your network doesn't scare you because your network is small, then imagine updating more than 15-20 switches a few times per week, so your network can respond to your organisation's needs....have we got you thinking now? :)
With the VTP protocol configured and operating, you can forget about running around making sure you have updated all switches as you only need to make the changes on the nominated VTP server switch(es) on your network. This will also ensure these changes are magically propagated to all other switches regardless of where they are.
Introducing The VTP Modes
The VTP protocol is a fairly complex protocol, but easy to understand and implement once you get to know it. Currently, 3 different versions of the protocol exist, that is, version 1, 2 (adds support for Token Ring networks) and 3, with the first version being used in most networks.
Despite the variety of versions, it also operates in 3 different modes: Server, client and transparent mode, giving us maximum flexibility on how changes in the network effect the rest of our switches. To help keep things simple and in order to avoid confusion, we will work with the first version of the VTP protocol - VTP v1, covering more than 90% of networks.
Below you'll find the 3 modes the VTP protocol can operate on any switch throughout the network:
- VTP Server mode
- VTP Client mode
- VTP Transparent mode
A typical setup involves at least one switch configured as a VTP Server, and multiple switches configured as VTP Clients. The logic behind this setup is that all information regarding VLANs is stored only on the VTP Server switch from which all clients are updated. Any change in the VLAN database will trigger an update from the VTP Server towards all VTP clients so they can update their database.
Lastly, be informed that these VTP updates will only traverse Trunk links. This means that you must ensure that all switches connect to the network backbone via Trunk links, otherwise no VTP updates will get to your switches.
Let's now take a closer look at what each VTP mode does and where it can be used.
VTP Server Mode
By default all switches are configured as VTP Servers when first powered on. All VLAN information such as VLAN number and VLAN name is stored locally, on a separate NVRAM from where the 'startup-config' is stored. This happens only when the switch is in VTP Server mode.
For small networks with a limited number of switches and VLANs, storing all VLAN information on every switch is usually not a problem, but as the network expands and VLANs increase in number, it becomes a problem and a decision must be made to select a few powerful switches as the VTP Servers while configuring all other switches to VTP Client mode.
The diagram above shows a Cisco Catalyst 3550 selected to take the role of the network's VTP Server since it is the most powerful switch. All other Catalyst switches have been configured as VTP Clients, obtaining all VLAN information and updates from the 3550 VTP Server.
The method and frequency by which these updates occur is covered in much detail on the pages that follow, so we won't get into any more detail at this point. However, for those who noticed, there is a new concept introduced in the above diagram that we haven't spoken about: The VTP Domain.
The VTP Domain - VLAN Management Domain
The VTP Domain, also known as the VLAN Management Domain, is a VTP parameter configured on every switch connected to the network and used to define the switches that will participate in any changes or updates made in the specified VTP domain.
Naturally, the core switch (VTP Server) and all other switches participate in the same domain, e.g firewall, so when the VTP Server advertises new VLAN information for the VTP firewall domain, only clients (switches) configured with the same VTP Domain parameter will accept and process these changes, the rest will simply ignore them.
Lastly, some people tend to relate the VTP Domain with the Internet Domain name space, however, this is completely incorrect. Even though the acronym 'DNS' contains the word 'Domain', it is not related in any way with the VTP Domain. Here (in VTP land), the word 'Domain' is simply used to describe a logical area in which certain hosts (switches) belong to or participate in, and are affected by any changes made within it.
We should also note that all Cisco switches default to VTP Server mode but will not transmit any VLAN information to the network until a VTP Domain is set on the switch.
At this point we are only referencing the VTP Domain concept as this is also analysed in greater depth further on, so let's continue with the VTP modes!
VTP Client Mode
In Client Mode, a switch will accept and store in its RAM all VLAN information received from the VTP Server, however, this information is also saved in NVRAM, so if the switch is powered off, it won't loose its VLAN information.
The VTP Client behaves like a VTP Server, but you are unable to create, modify or delete VLAN's on it.
In most networks, the clients connect directly to the VTP Server as shown in our previous diagram. If, for any reason, two clients are cascaded together, then the information will propagate downwards via the available Trunk links, ensuring it reaches all switches: