- Configure, verify, and troubleshoot interVLAN routing
One of the remarkable features about VLAN segmentation with a Layer 2 switch is that the traffic from one VLAN remains separate from all other VLANs. Quite often, however, devices need to communicate or access services with another device that is in another VLAN. Because the VLANs are in separate networks (broadcast domains), you need a device that is capable of
routing in between networks. In other words, you need a router or a Layer 3 switch.
Each broadcast domain that is created in a switch is associated with an IP subnet. Devices in the same VLAN share the same subnet so they can use IP to communicate with each other. Routers and Layer 2 switches route between the logical subnets to allow traffic from one VLAN to reach another VLAN. This is known as interVLAN routing.
Router on a Stick
One method of routing between VLANs is to use a router. Because each VLAN is associated with its own subnet, a router needs to have an interface for each VLAN (IP subnet) so it can route in between them. This can become a costly and unscalable solution if you have a large number of VLANs in your switched network.
The most effective manner of using a router to perform interVLAN routing is something commonly referred to as “router on a stick.” The gist behind this solution is to produce a configuration in which the router can see all the VLAN traffic over a single link. In other words, the router trunks to a switch over a single link, hence the term “router on a stick.” Despite the router being able to see all the VLAN traffic, however, it still requires interfaces with IP subnets assigned to them to route in between these VLANs. The answer for this is something called subinterfaces.
Subinterfaces are virtual interfaces that are created on a single physical interface. When a physical interface is divided into these virtual interfaces, the router still considers them to be directly connected interfaces with subnets assigned to them and can route in between them.
To create the subinterfaces, you navigate in the IOS as you would to a physical interface; however, you add a decimal followed by the logical subinterface number. The IOS prompt changes to reflect Router(config-subif)#, signifying you are in the subinterface configuration mode, as demonstrated here:
Router(config)#interface FastEthernet 0/1.1 Router(config-subif)#
The decimal number you assign to an interface does not have to be in any sequential order. In fact, for good design practices, you should use the same number of the VLAN for which you created the subinterface. In addition, because these are logical interfaces, if one subinterface goes down, it does not affect the rest of the subinterfaces. However, if the physical interface happens to go down, then logic follows that all your subinterfaces go down with the ship, so to speak. Additionally, you do not need to enable no shutdown on each subinterface; this is required only on the physical interface itself.
After you create a subinterface for a VLAN on your Fast Ethernet or Gigabit interface (remember trunks must be at least 100Mbps), you can assign the IP address to the interface for that VLAN’s subnet. This IP address is the default gateway for all the devices in that VLAN because the default gateway is the IP address to which devices send their traffic destined for another network. To assign the VLAN to each subinterface, you must use the encapsulation command and signify which method of VLAN tagging you have configured on the trunk, followed by the VLAN assigned to that subinterface.
To use a router-on-a-stick solution for interVLAN routing, you must trunk between the router and the switch. In addition, the interface must be at least Fast Ethernet and contain subinterfaces for each VLAN.
For instance, given a scenario similar to Figure 15.7, you would create a subinterface in the router for each VLAN. The IP address assigned to these interfaces acts at the default gateway for the PCs. When the computer in VLAN 1 wants to send traffic to the computer in VLAN 3, it sends the traffic over the switch trunks to the router that is to route and re-encapsulate the ethernet frame to have a VLAN ID of VLAN 3. When the switches receive the frame, they forward it out of only access ports that have VLAN 3 assigned to it.
The router configuration for Figure 15.7 would look like the following, assuming you are using 802.1q trunks:
Router(config)#interface FastEthernet 0/1.1 Router(config-subif)#ip address 192.168.1.1 255.255.255.0 Router(config-subif)#encapsulation dot1q 1 Router(config)#interface FastEthernet 0/1.3 Router(config-subif)#ip address 192.168.3.1 255.255.255.0 Router(config-subif)#encapsulation dot1q 3
Switched Virtual Interfaces
An alternative to trunking to an external router is to use a Layer 3 switch to route in between the VLANs. Layer 3 switches combine the logical routing functionality of a router with the hardware speed of a switch because it uses ASICs to do some of the routing operations. So if the Layer 3 switch is faster than a router, why use routers? The answer is that Layer 3 switches do not have all the routing functionality that a router has. Specifically, you cannot purchase the Layer 3 switches with serial interfaces that can connect to a WAN. The Layer 3 switches are designed more to have routing functionality between VLANs in an ethernet LAN.
If you have a Layer 3 switch in your enterprise (certain models of the Catalyst 3550/60, 4500, and 6500 series of switches), you need to trunk to that switch and configure a different set of virtual interfaces to allow interVLAN routing. The result is called switched virtual interfaces (SVI). The interfaces that you configure in the Layer 3 switches are, conveniently enough, VLAN interfaces.
To configure the switched virtual interfaces, you simply navigate to the VLAN interface number that matches your VLAN and assign it an IP address. For example, given the similar interVLAN scenario in Figure 15.8, you are using the Layer 3 switch to route in between the two VLANs. You just need to create the VLAN interfaces and assign the IP addresses, as demonstrated in the following configuration:
Switch(config)#interface Vlan 1 Switch(config-if)#ip address 192.168.1.1 255.255.255.0 Switch(config)#interface Vlan 3 Switch(config-if)#ip address 192.168.3.1 255.255.255.0
We’ve established earlier in this chapter that access ports are ports that only have one VLAN assigned to them. That is typically the case unless you want to assign Voice VLANs, sometimes referred to as auxiliary VLANs, to an interface. In these cases, the access VLAN is actually the VLAN assigned for normal data and the voice VLAN is a separate VLAN for Voice over IP (VoIP) from a Cisco IP Phone.
Cisco IP Phones, such as the 7960, connect to switches and send the IP traffic that contains the voice payloads over the LAN and eventually to the gateway device that connects it to the traditional voice network. In addition to having the responsibility of breaking down speech and sound into data packets, these IP Phones also have an internal LAN switch with a data port on
them that you can use to connect your PC or other end-device to minimize unnecessary cabling and the amount of ports needed on the Catalyst switch.
By configuring the switch port connected to these phones, you have the ability to logically separate the voice traffic from the phone and the data traffic traversing through the phone’s internal switch into separate broadcast domains. This is useful for management purposes because you can essentially configure all IP Phones to be in their own subnet because the phones will
be assigned to the same voice VLAN. But even more important than that, you can configure the Catalyst switch to use QoS and instruct the IP Phone (using CDP no less) to classify the voice traffic differently from the data. By giving the voice traffic higher priority over the data traffic, you are minimizing the possibility that your data traffic will impede the voice packets from reaching their destination (at least from the Catalyst switch) and deteriorate voice quality. To illustrate the process entailed with Cisco IP Phones and voice VLANs, refer to Figure 15.9.
In this illustration, the PC connected to the IP Phone is sending data traffic that is switched through the phone and is assigned to the access data VLAN 100 on the Catalyst switch. Voice traffic coming from the IP Phone is tagged with the voice VLAN ID of 200 and is given a higher QoS priority over the data traffic. If there is contention for sending the voice and data traffic, the switch will choose the voice traffic to ensure optimal voice quality.
To configure a voice VLAN, the syntax is relatively the same as access VLANs except it uses the keyword voice instead of access. For instance, assuming the IP Phone in Figure 15.9 was connected to the Catalyst switch’s Fast Ethernet 0/20 interface, the configuration would look like the following:
Switch(config)#interface FastEthernet 0/20 Switch(config-if)#switchport access vlan 100 Switch(config-if)#switchport voice vlan 200
- Configure, verify, and troubleshoot VLANs
- Configure, verify, and troubleshoot trunking on Cisco switches
- Configure, verify, and troubleshoot interVLAN routing
- Configure, verify, and troubleshoot VTP
I am sure by this point you recognize the usefulness of segmenting your LAN into separate broadcast domains using VLANs. Unfortunately, this valuable Layer 2 technology is not without its share of problems that can (and typically do) arise when implementing VLANs in a switched environment. By logically narrowing down the possible causes based upon the symptoms and using the verification commands learned in this chapter, you should be able to tackle the majority of anomalies that occur in a small-to-medium sized switched network with VLANs.
One of the most common symptoms that may arise when implementing VLANs is the inability to have end-devices able to communicate with each other. The list of possible causes for this can be endless; however, the following questions and solutions will address the most prevalent problems:
- Is this one of the design requirements of implementing VLANs in the first place? Recall that a major benefit of VLANs is to logically separate traffic into separate broadcast domains. If devices are in separate VLANs and do not have a router or Layer 3 switch to route in between the VLANs, then this is the result that is supposed to occur.
- Are the trunks operating correctly between the switches? Assuming that you have multiple switches, verify the configuration and the status of the switch trunks by using the show interfaces trunk command. If the trunk link is not operating correctly, use the OSI model as a guide and begin with the Physical layer by verifying the cable between the switches is a cross-over ethernet cable. Once that is verified, move up to the Data Link layer and check your trunk configuration. Specifically, make sure trunk negotiation was successful, especially if your network is not an all-Cisco switched network. When in doubt, manually configure each side of the link to trunk by using the switchport mode trunk command.
- Are the end-devices assigned to the correct VLANs? If they are designed to be in the same VLAN, verify the VLAN names match and they are assigned to the correct interfaces by using the show vlans command. If they are on separate VLANs, verify your configuration and the status of the interfaces on your router or your Layer 3 switch. In addition, ensure that the end-devices are utilizing the IP address of the subinterface or switched virtual interface as their default gateway.
- If using 802.1q trunks, are both switches sharing the trunk using the same native VLAN? Recall that VLAN leakage can occur if both sides of the trunk are not configured with the same VLAN. Verify the native VLAN on both switches by utilizing the show interfaces trunk command.
The next troubleshooting scenario we will look at revolves around the possibility that output of the show vlan command reveals that your VLANs in your switch are missing or are inconsistent with what you originally configured in the rest of your switches:
- Is your switch in VTP transparent mode? Mismatched VLANs is not only possible in
transparent mode, but it is actually one of the reasons to use transparent mode. In addition, it might also explain why you do not see your VLANs since they will not show up in the VLAN database, but they can be found in your running or startup configuration.
- Are the VTP configuration revision numbers incrementing along with the other switches in the network? It is plausible that the switch has lost a connection to the rest of the switched network. Verify the trunk is configured and operating as mentioned in the first scenario. Secondly, it may be possible that the management VLAN (VLAN 1 by default) is being blocked from propagating between the trunks (we will look into how to change the management VLAN and only allow certain VLANs over trunks in Chapter 16, “Implementing Switch Security.”) Recall that the management IP, CDP,
and VTP advertisements all are advertised using the management VLAN between switches. As a result, if the management VLAN is being blocked, VTP advertisements are consequently being blocked as well. Finally, there may be a switch that was added to your network between you and the VTP server that is configured for a different VTP domain. When the VTP server sends its VTP advertisements to the interjector switch, it will discard the VTP advertisement because it is not in the same VTP domain. The end result is that your switch never receives those VTP advertisements and your VTP configuration revisions will not increase.
- Is there another VTP server in your switched internetwork? It is common to have several VTP servers in a network for redundancy; however, if another administrator is adding, changing, and/or removing VLANs on other VTP server switches, it will increment its configuration revision and all other switches in client and server mode will follow suit. If a VTP server is added and does not have any VLANs configured, that would explain it if all of your configured VLANs have suddenly disappeared as well. You can verify this by issuing the show vtp status command which will show you the IP address of the last VTP updater if known.
- Has there been any configuration changes to the VTP domain or VTP passwords? If your switch does not have matching VTP domain names or VTP passwords, the switch will not accept VTP advertisements. This can be verified using the show vtp status command on each switch. If you suspect the password is not matching, use the show vtp password command from privileged EXEC.