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 Capability

Enhanced Multilayer Image (EMI) - All Versions YES

Standard Multilayer Image (SMI) - prior to 12.1(11)EA1 NO

Standard Multilayer Image (SMI) - YES

12.1(11)EA1 and later

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 - VTP

Introduction

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

Each mode has been designed to cover specific network setups and needs, as we are about to see, but for now, we need to understand the purpose of each mode and the following network diagram will help us do exactly that.

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:

The diagram shows a 3550 Catalyst switch configured as a VTP Server and 4 Catalyst 2950 switches configured as VTP Clients and cascaded below our 3550. When the VTP Server sends a VTP update, this will travel through all trunk links (ISL, 802.1q, 802.10 and ATM LANE), as shown in the diagram.

The advertised information will firstly reach the two Catalyst 2950 switches directly connected to the 3550 and will then travel to the cascaded switches below and through the trunk links. If the link between the cascaded 2950's was not a trunk link but an access link, then the 2nd set of switches would not receive and VTP updates:

As you can see, the VTP updates will happlily arrive at the first catalyst switches but stop there as there are no trunk links between them and the 2950's below them. It is very important you keep this in mind when designing a network or making changes to the existing one.

VTP Transparent Mode

The VTP Transparent mode is something between a VTP Server and a VTP Client but does not participate in the VTP Domain.

In Transparent mode, you are able to create, modify and delete VLANs on the local switch, without affecting any other switches regardless of the mode they might be in. Most importantly, if the transparently configured switch receives an advertisement containing VLAN information, it will ignore it but at the same time forward it out its trunk ports to any other switches it might be connected to.

NOTE: A Transparent VTP switch will act as a VTP relay (forward all VTP information it receives, out its trunk ports) only when VTP version 2 is used in the network. With VTP version 1, the transparent switch will simply ignore and discard any VTP messages received from the rest of the network.

Lastly, all switches configured to operate in Transparent mode save their configuration in their NVRAM (just like all the previous two modes) but not to advertise any VLAN information of its own, even though it will happily forward any VTP information received from the rest of the network.

This important functionality allows transparently configured switches to be placed anywhere within the network, without any implications to the rest of the network because as mentioned, they act as a repeater for any VLAN information received:

Our 3550 Catalyst here is configured as a VTP Server for the domain called "Firewall". In addition, we have two switches configured in VTP Client mode, obtaining their VLAN information from the 3550 VTP Server, but between these two VTP Clients, we have placed another switch configured to run in VTP Transparent mode.

Our Transparent switch has been configured with the domain called "Lab", and as such, the switch will forward all incoming VTP updates belonging to the "Firewall" domain out its other trunk link, without processing the information. At the same time, it won't advertise its own VLAN information to its neighbouring switches.

Closing, the VTP Transparent mode is not often used in live networks, but is well worth mentioning and learning about.

Summary

This page introduced a few new and very important concepts. The VTP Protocol is considered to be the heart of VLANs in large scale networks as it completely makes the administration point of view easy and transparent for every switch on your network.

We briefly spoke about the three different modes offered by the VTP protocol: Server, Client and Transparent mode. To assist in providing a quick summary, the table below shows the main characteristics for each mode:

VTP Mode Description

VTP Server

The default mode for all switches supporting VTP. You can create, modify, and delete VLANs andspecify other configuration parameters (such as VTP version)for the entire VTP domain. VTP servers advertise their VLAN configurations to other switches in the same VTP domain and synchronize their VLAN configurations with other switches based on advertisements received over trunklinks. VLAN configurations are saved in NVRAM.

VTP Client Behaves like a VTP server, but you cannot create, change, or delete VLANs on a VTP client. VLAN configurations are saved in NVRAM.

VTP Transparent

Does not advertise its VLAN configuration and does not synchronize its VLAN configuration based on received advertisements. However, they will forward VTP advertisements as they are received from other switches. You can create, modify, and delete VLANs on a switch in VTP transparent mode. VLAN configurations are saved in NVRAM, but they are not advertised to other switches.

All switches by default are configured as VTP Servers but without a domain. At this point we need to select the 'Core' switch (usually the most powerful) and configure it as a VTP Server, while reconfiguring all the rest to Client mode. Also, VTP Updates sent by the Server will only propagate through trunk links configured for ISL, IEEE 802.1q, 802.10 or LANE encapsulation.

NOTE: You should be aware that all VTP Messages are sent through what we call the "Management VLAN". This specially created VLAN is usually the first one in the network - VLAN 1 - and by rule is never used by anyone else other than the switches themselves. The creation of a Management VLAN ensures all switches have their own network to communicate between each other without any disruptions.

The next page will analyse the VTP Protocol structure, messages and updates. This will provide a deep understanding on how VTP works and what information it's messages contain. For those out there keen on configuring a switch for VTP, it's covered towards the end of the VLAN topic as shown on the VLAN Introduction page.

  In-Depth Analysis Of VTP

Introduction

The previous page introduced the VTP protocol and we saw how it can be used within a network, to help manage your VLANs and ease the administrative overhead providing a stress-free VLAN environment, automatically updating all the network switches with the latest VLAN information.

This page extends on the above by delving into the VTP protocol itself and analysing it's structure and format in order to gain a better understanding and enhance those troubleshooting skills.

The VTP Protocol Structure

We've mentioned that the VTP protocol runs only over trunk links interconnecting switches in the network. Whether you're using ISL or IEEE 802.1q as your encapsulation protocol, it really doesn't matter as the VTP structure in both cases remains the same.

Following are the fields which consist the VTP protocol:

VTP Protocol Version (1 or 2) VTP Message Type (See Below) Management Domain Length Management Domain Name

What we need to note here is that because there are a variety of "VTP Message Types", the VTP Header changes depending on these messages, but the fields we just mentioned above are always included.

To be more specific, here are the different messages currently supported by the VTP protocol:

Summary Advertisements Subset Advertisement Advertisement Requests VTP Join Messages

It is obvious that all switches use these different messages to request information or advertise the VLANs they are aware of. These messages are extremely important to understand as they are the foundations of the VTP protocol.

We'll take each message and analyse them individually, explaining their purpose and usage, but before we proceed, let's take a quick visual look at the messages and their types to help make all the above clearer:

First up is the 'Summary Advertisements'.

VTP Protocol - Summary Advertisement Message

The 'Summary Advertisement' message is issued by all VTP Domain Servers in 5 minute intervals, or every 300 seconds. These advertisements inform nearby Catalyst switches with a variety of information, including the VTP Domain name, configuration revision number, timestamp, MD5 encryption hash code, and the number of subset advertisements to follow.

The configuration version number is a value each switch stores to help it identify new changes made in the VTP domain. For those experienced with DNS, it's pretty much the same as the DNS serial number. Each time a VTP Server's configuration is changed, the

configuration revision number will automatically increment by one.

When a switch receives a summary advertisement message, it will first compare the VTP domain name (Mgmt Domain Name field) with its own.

If the Domain Name is found to be different, it will discard the message and forward it out its trunk links. However, in the likely case that the domain name is found to be the same, it will then check the configuration revision number (Config Revision No.) and if found to be the same or lower than it's own, it will ignore the advertisement. If, on the other hand, it is found to be greater, an advertisement request is sent out.

The Updater Identity field contains the IP Address of the switch that last incremented the Configuration Revision Number, while the Update Timestamp field gives the time the last update took place.

The MD5 (Message Digest 5) field contains the VTP password in the case where it is configured and used to ensure the validation of the VTP Update.

Lastly, summary advertisements are usually followed by Subset Advertisements, this is indicated by the Followers field and is the next message we'll be closely examining.

VTP Protocol - Subset Advertisement

As mentioned in the previous message, when VLAN changes are made on the Catalyst VTP Server, it will then issue a Summary Advertisement, followed by a Subset Advertisement. Depending on how many VLANs are configured in the domain, there might be more than one Subset Advertisement sent to ensure all VLAN information is updated on the VTP Clients.

Comparing the fields of this message with the previous one, you'll notice most of them are identical, except for the Sequence No. and VLAN Info. Field.

The Code field for a Subset Advertisement of this type is set to 0x02 while the Sequence No. field contains the sequence of the packet in the stream of packets following a summaryadvertisement. The sequence starts with 1 and increments based on the number of packets in the stream.

Apart from these fields, we also have the VLAN Info Field, which happens to be the most important as it contains all the VLAN information the switches are waiting for.

The VLAN Info Field will be presented in segments. Complexity and importance requires us to break it up further and analyse the subfields it contains:

Each VLAN Info Field contains all the information required for one VLAN. This means that if our network is powered with 10 VLANs and a Subset Advertisement is triggered, the VTP Server will send a total of 10 Subset Advertisements since each VLAN Info Field contains data for one VLAN.

The most important subfields in the VLAN Info Field are the VLAN Name Length, ISL VLAN ID, MTU Size and VLAN Name. These subfields contain critical information about the VLAN advertised in the particular Subset Advertisement frame. Some might be suprised to see settings such as MTU's to be configurable in VLAN's, and this confirms that each VLAN is treated as a separate network, where even different MTU sizes are possible amongst your

network's VLANS.

Advertisement Requests

Turning a switch off will result loosing all its VTP information stored in its memory (RAM). When the switch is next turned on, all its database information is reset and therefore requires to be updated with the latest version available from the VTP Server(s).

A switch will also send an Advertisement Request when it hears a VTP summaryadvertisement with a higher revision number than what it currently has. Another scenario where a request would be issued is when the VTP domain membership has changed, even though this is quite uncommon since the VTP domain name is rarely, if ever, changed after its initial configuration.

So what happens when a Advertisement Request hits the streets of your network?

As you would already be aware from the message types we have just covered, the VTP Server will respond with Summary Advertisement, followed by as many Subset Advertisements required to inform the VTP Clients about the currently configured VLANs.

The diagram below shows the structure of an Advertisement Request sent by a VTP Client switch:

Most fields as you can see, are similar to the previous messages we've seen, except two: The Reserved and Starting Advertisement To Request . The Reserved is exactly what it implies - reserved and not used in the Advertisement Request messages, while the Starting Advertisement To Request is the actual request sent by the VTP Client.

VTP Join Messages

VTP Join Messages are similar to the Advertisement Request messages but with a different Message Type field value and a few more parameters. As indicated by the message name, a VTP Join Message is sent when the VTP Client first joins a VTP domain, informing the VTP Server(s) about the new guy in 'town':)

Other VTP Options - VTP Password

The VTP Password is a feature that all security conscious Administrators/Engineers will welcome. With the password feature, you are able to secure your VTP Domain since only switches configured with the correct password are able to properly decrypt the VTP messages

advertised in the management VLAN.

By default the VTP Password option is not turned on and therefore most management VLANs are set to use non-secure advertisements. Once enabled on the VTP Domain Server(s), all switches participating in the domain must be manually configured with the same password, otherwise it will fail to decrypt all incoming VTP messages.

Summary

This page analysed the structure of each message the VTP protocol currently supports to maintain the network's switches in synchronisation with the VTP domain server(s):

Summary Advertisements Subset Advertisement Advertisement Requests VTP Join Messages

We're sure you would agree that VLAN's are in fact a whole study case alone, but surely at the same time it's quite exciting as new concepts and methods of ensuring stability, speed and reliability are revealed.

This completes our in-depth discussion on the VTP Protocol messages. Next up is VTP Prunning, a nice service that ensures our network backbone is not constantly flooded with unnecessary traffic. We are sure you'll enjoy the page, along with the awesome diagrams we have prepared.