Section 3 Tasks
• Read today’s lesson notes (below)
• Review yesterday’s lesson notes
• Complete today’s lab
• Read the ICND1 cram guide
You will only encounter networks using one switch in the smallest of offices, whereas you will usually find multiple switches forming part of the network infrastructure. This brings its own set of configuration challenges, which will require a good understading of trunking and associated issues. Cisco consider the ability to install and troubleshoot multiple switch connections a fundamental CCNA-level topic.
Today you will learn about the following:
• Trunking
• Dynamic Trunking Protocol (DTP)
• Inter-VLAN Routing
This module maps to the following ICND1 syllabus requirements:
• Configure and verify trunking on Cisco switches
• DTP
• Auto-negotiation
• Configure and verify inter-VLAN routing (router-on-a-stick)
° Subinterfaces
° Upstream routing
° Encapsulation
• Configure SVI interfaces
Configuring and Verifying Trunk Links
A trunk is a switch port that can carry multiple traffic types, each tagged with a unique VLAN ID. As data is switched across the trunk port or trunk link, it is tagged (or coloured) by the egress switch trunk port, which allows the receiving switch to identify that it belongs to a particular VLAN. On the receiving switch ingress port, the tag is removed and the data is forwarded to the intended destination.
The first configuration task when implementing VLAN trunking in Cisco IOS Catalyst switches is to configure the desired interface as a Layer 2 switch port. This is performed by issuing the switchport interface configuration command.
NOTE: This command is required only on Layer 3-capable or Multilayer switches. It is not applicable to Layer 2-only switches, such as the Catalyst 2960 series. A switch would need to support the command ip routing in order to be considered Layer 3 capable.
The second configuration task is to specify the encapsulation protocol that the trunk link should use. This is performed by issuing the switchport trunk encapsulation [option] command. The options available with this command are as follows:
Switch(config)#interface FastEthernet1/1 Switch (config-if)#switchport trunk encapsulation ? dot1q - Interface uses only 802.1q trunking encapsulation when trunking isl - Interface uses only ISL trunking encapsulation when trunking negotiate - Device will negotiate trunking encapsulation with peer on interface
The [dot1q] keyword forces the switch port to use IEEE 802.1Q encapsulation. The [isl] keyword forces the switch port to use Cisco ISL encapsulation. The [negotiate] keyword is used to specify that if the Dynamic Inter-Switch Link Protocol (DISL) and the Dynamic Trunking Protocol (DTP) negotiation fails to successfully agree on the encapsulation format, then ISL is the selected format. DISL simplifies the creation of an ISL trunk from two interconnected FastEthernet devices. DISL minimises VLAN trunk configuration procedures because only one end of a link needs to be configured as a trunk.
DTP is a Cisco proprietary point-to-protocol that negotiates a common trunking mode between two switches. DTP will be described in detail later. The following output illustrates how to configure a switch port to use IEEE 802.1Q encapsulation when establishing a trunk:
Switch (config)#interface FastEthernet1/1 Switch (config-if)#switchport Switch (config-if)#switchport trunk encapsulation dot1q
This configuration can be validated via the show interfaces [name] switchport command, as illustrated in the following output:
Switch#show interfaces FastEthernet1/1 switchport Name: Fa0/2 Switchport: Enabled Administrative Mode: dynamic desirable Operational Mode: trunk Administrative Trunking Encapsulation: dot1q Operational Trunking Encapsulation: dot1q Negotiation of Trunking: On Access Mode VLAN: 1 (default) Trunking Native Mode VLAN: 1 (default) ... [Truncated Output]
The third trunk port configuration step is to implement configuration to ensure that the port is designated as a trunk port. This can be done in one of two ways:
• Manual (static) trunk configuration
• Dynamic Trunking Protocol (DTP)
Manual (Static) Trunk Configuration
The manual configuration of a trunk is performed by issuing the switchport mode trunk interface configuration command on the desired switch port. This command forces the port into a permanent (static) trunking mode. The following configuration output shows how to configure a port statically as a trunk port:
VTP-Server(config)#interface FastEthernet0/1 VTP-Server(config-if)#switchport VTP-Server(config-if)#switchport trunk encapsulation dot1q VTP-Server(config-if)#switchport mode trunk VTP-Server(config-if)#exit VTP-Server(config)#
Feel free to ignore the switchport command if you are using a lower-end switch (the above output was from a Cat6K switch). This configuration can be validated via the show interfaces [name] switchport command, as illustrated in the following output:
VTP-Server#show interfaces FastEthernet0/1 switchport Name: Fa0/1 Switchport: Enabled Administrative Mode: trunk Operational Mode: trunk Administrative Trunking Encapsulation: dot1q Operational Trunking Encapsulation: dot1q Negotiation of Trunking: On Access Mode VLAN: 1 (default) Trunking Native Mode VLAN: 1 (default) ... [Truncated Output]
Although manual (static) configuration of a trunk link forces the switch to establish a trunk, Dynamic ISL and Dynamic Trunking Protocol (DTP) packets will still be sent out of the interface. This is performed so that a statically configured trunk link can establish a trunk with a neighbouring switch that is using DTP, as will be described in the following section. This can be validated in the output of the show interfaces [name] switchport command illustrated below:
VTP-Server#show interfaces FastEthernet0/1 switchport Name: Fa0/1 Switchport: Enabled Administrative Mode: trunk Operational Mode: trunk Administrative Trunking Encapsulation: dot1q Operational Trunking Encapsulation: dot1q Negotiation of Trunking: On Access Mode VLAN: 1 (default) Trunking Native Mode VLAN: 1 (default) ... [Truncated Output]
In the output above, the text in bold indicates that despite the static configuration of the trunk link, the port is still sending out DTP and DISL packets. In some cases, this is considered undesirable. Therefore, it is considered good practice to disable the sending of DISL and DTP packets on a port statically configured as a trunk link by issuing the switchport nonegotiate interface configuration command, as illustrated in the following output:
VTP-Server(config)#interface FastEthernet0/1 VTP-Server(config-if)#switchport VTP-Server(config-if)#switchport trunk encapsulation dot1q VTP-Server(config-if)#switchport mode trunk VTP-Server(config-if)#switchport nonegotiate VTP-Server(config-if)#exit VTP-Server(config)#
Again, the show interfaces [name] switchport command can be used to validate the configuration, as follows:
VTP-Server#show interfaces FastEthernet0/1 switchport Name: Fa0/1 Switchport: Enabled Administrative Mode: trunk Operational Mode: trunk Administrative Trunking Encapsulation: dot1q Operational Trunking Encapsulation: dot1q Negotiation of Trunking: Off Access Mode VLAN: 1 (default) Trunking Native Mode VLAN: 1 (default) ... [Truncated Output]
Dynamic Trunking Protocol (DTP)
DTP is a Cisco proprietary point-to-protocol that negotiates a common trunking mode between two switches. This dynamic negotiation can also include trunking encapsulation. The two DTP modes that a switch port can use, depending upon the platform, are as follows:
• Dynamic desirable
• Dynamic auto
When using DTP on two neighbouring switches, if the switch port defaults to a dynamic desirable state, the port will actively attempt to become a trunk. If the switch port defaults to a dynamic auto state, the port will revert to being a trunk only if the neighbouring switch is set to dynamic desirable mode.
Figure 3.1 below illustrates the DTP mode combinations that will result in a trunk either being established or not being established (in this case they are all established; see note after Figure 3.2) between two Cisco Catalyst switches:
Figure 3.1 – DTP Mode Combinations
Figure 3.2 below illustrates the valid combinations that will result in the successful establishment of a trunk link between two neighbouring switches – one using DTP and the other statically configured as a trunk port:
Figure 3.2 – DTP Mode Combinations, Part 2
NOTE: It is important to know that if the switches are both set to dynamic auto, they will not be able to establish a trunk between them. This is because, unlike dynamic desirable mode, dynamic auto mode is a passive mode that waits for the other side to initiate trunk establishment. Therefore, if two passive ports are connected, neither will ever initiate trunk establishment and the trunk will never be formed. Similarly, if a statically configured switch port is also configured with the switchport nonegotiate command, it will never form a trunk with a neighbouring switch using DTP because this prevents the sending of DISL and DTP packets out of that port.
When using DTP in a switched LAN, the show dtp [interface <name>] command can be used to display DTP information globally for the switch or for the specified interface. The following output shows the information printed by the show dtp command:
VTP-Server#show dtp
Global DTP information
Sending DTP Hello packets every 30 seconds
Dynamic Trunk timeout is 300 seconds
4 interfaces using DTP
Based on the output above, the switch is sending DTP packets every 30 seconds. The timeout value for DTP is set to 300 seconds (5 minutes), and 4 interfaces are currently using DTP. The show dtp interface [name] command prints DTP information about the specified interface, which includes the type of interface (trunk or access), the current port DTP configuration, the trunk encapsulation, and DTP packet statistics, as illustrated in the following output:
VTP-Server#show dtp interface FastEthernet0/1 DTP information for FastEthernet0/1: TOS/TAS/TNS: TRUNK/ON/TRUNK TOT/TAT/TNT: 802.1Q/802.1Q/802.1Q Neighbor address 1: 000000000000 Neighbor address 2: 000000000000 Hello timer expiration (sec/state): 7/RUNNING Access timer expiration (sec/state): never/STOPPED Negotiation timer expiration (sec/state): never/STOPPED Multidrop timer expiration (sec/state): never/STOPPED FSM state: S6:TRUNK # times multi & trunk 0 Enabled: yes In STP: no Statistics ----------0 packets received (0 good) 0 packets dropped 0 nonegotiate, 0 bad version, 0 domain mismatches, 0 bad TLVs, 0 other 764 packets output (764 good) 764 native, 0 software encap isl, 0 isl hardware native 0 output errors 0 trunk timeouts 2 link ups, last link up on Mon Mar 01 1993, 00:00:22 1 link downs, last link down on Mon Mar 01 1993, 00:00:20
IEEE 802.1Q Native VLAN
In the previous module, you learned that 802.1Q, or VLAN tagging, inserts a tag into all frames, except those in the native VLAN. The IEEE defined the native VLAN to provide for connectivity to old 802.3 ports that did not understand VLAN tags.
By default, an 802.1Q trunk uses VLAN 1 as the native VLAN. The default native VLAN on an 802.1Q trunk link can be verified by issuing the show interfaces [name] switchport or the show interfaces trunk command, as illustrated in the following output:
VTP-Server#show interfaces FastEthernet0/1 switchport Name: Fa0/1 Switchport: Enabled Administrative Mode: trunk Operational Mode: trunk Administrative Trunking Encapsulation: dot1q Operational Trunking Encapsulation: dot1q Negotiation of Trunking: On Access Mode VLAN: 1 (default) Trunking Native Mode VLAN: 1 (default) Voice VLAN: none ... [Truncated Output]
VLAN 1 is used by the switch to carry specific protocol traffic, like Cisco Discovery Protocol (CDP), VLAN Trunking Protocol (VTP), Port Aggregation Protocol (PAgP), and Dynamic Trunking Protocol (DTP) information. CDP and PAgP will be described in detail later in this guide. Although the default native VLAN is always VLAN 1, the native VLAN can be manually changed to any valid VLAN number that is not in the reserved range of VLANs.
However, it is important to remember that the native VLAN must be the same on both sides of the trunk link. If there is a native VLAN mismatch, Spanning Tree Protocol (STP) places the port in a port VLAN ID (PVID) inconsistent state and will not forward the link. Additionally, CDPv2 passes native VLAN information between switches and will print error messages on the switch console if there is a native VLAN mismatch. The default native VLAN can be changed by issuing the switchport trunk native vlan [number] interface configuration command on the desired 802.1Q trunk link, as illustrated in the following output:
VTP-Server(config)#interface FastEthernet0/1 VTP-Server(config-if)#switchport trunk native vlan ? <1-4094> VLAN ID of the native VLAN when this port is in trunking mode
Inter-VLAN Routing
By default, although VLANs can span the entire Layer 2 switched network, hosts in one VLAN cannot communicate directly with hosts in another VLAN. In order to do so, traffic must be routed between the different VLANs. This is referred to as inter-VLAN routing. The three methods of implementing inter-VLAN routing in switched LANs below, including their advantages and disadvantages, will be described in the following sections:
• Inter-VLAN routing using physical router interfaces
• Inter-VLAN routing using router subinterfaces
• Inter-VLAN routing using switched virtual interfaces
Inter-VLAN Routing Using Physical Router Interfaces
The first method of implementing inter-VLAN routing for communication entails using a router with multiple physical interfaces as the default gateway for each individually configured VLAN. The router can then route packets received from one VLAN to another using these physical LAN interfaces. This method is illustrated below in Figure 3.3:
Figure 3.3 – Inter-VLAN Routing Using Multiple Physical Router Interfaces
Figure 3.3 illustrates a single LAN using two different VLANs, each with an assigned IP subnet. Although the network hosts depicted in the figure are connected to the same physical switch, because they reside in different VLANs, packets between hosts in VLAN 10 and those in VLAN 20 must be routed, while packets within the same VLAN are simply switched.
The primary advantage of using this solution is that it is simple and easy to implement. The primary disadvantage, however, is that it is not scalable. For example, if 5, 10, or even 20 additional VLANs were configured on the switch, the same number of physical interfaces as VLANs would also be needed on the router. In most cases, this is technically not feasible.
When using multiple physical router interfaces, each switch link connected to the router is configured as an access link in the desired VLAN. The physical interfaces on the router are then configured with the appropriate IP addresses, and the network hosts are either statically configured with IP addresses in the appropriate VLAN, using the physical router interface as the default gateway, or dynamically configured using DHCP. The configuration of the switch illustrated in Figure 3.3 is illustrated in the following output:
VTP-Server-1(config)#vlan 10 VTP-Server-1(config-vlan)#name Example-VLAN-10 VTP-Server-1(config-vlan)#exit VTP-Server-1(config)#vlan 20 VTP-Server-1(config-vlan)#name Example-VLAN-20 VTP-Server-1(config-vlan)#exit VTP-Server-1(config)#interface range FastEthernet0/1 – 2, 23 VTP-Server-1(config-if-range)#switchport VTP-Server-1(config-if-range)#switchport access vlan 10 VTP-Server-1(config-if-range)#switchport mode access VTP-Server-1(config-if-range)#exit VTP-Server-1(config)#interface range FastEthernet0/3 – 4, 24 VTP-Server-1(config-if-range)#switchport VTP-Server-1(config-if-range)#switchport access vlan 20 VTP-Server-1(config-if-range)#switchport mode access VTP-Server-1(config-if-range)#exit
The switchport command isn’t required on the 2960 switch because the interface is already running in Layer 2 mode.
The router illustrated in Figure 3.3 is configured as shown in the following output:
R1(config)#interface FastEthernet0/0 R1(config-if)#ip add 10.10.10.1 255.255.255.0 R1(config-if)#exit R1(config)#interface FastEthernet0/1 R1(config-if)#ip add 10.20.20.1 255.255.255.0 R1(config-if)#exit
Inter-VLAN Routing Using Router Subinterfaces
Implementing inter-VLAN routing using subinterfaces addresses the scalability issues that are possible when using multiple physical router interfaces. With subinterfaces, only a single physical interface is required on the router and subsequent subinterfaces are configured off that physical interface. This is illustrated below in Figure 3.4:
Figure 3.4 – Inter-VLAN Routing Using Router Subinterfaces
Figure 3.4 depicts the same LAN illustrated in Figure 3.3. In Figure 3.4, however, only a single physical router interface is being used. In order to implement an inter-VLAN routing solution, subinterfaces are configured off the main physical router interface using the interface [name]. [subinterface number] global configuration command. Each subinterface is associated with a particular VLAN using the encapsulation [isl|dot1Q] [vlan] subinterface configuration command. The final step is to configure the desired IP address on the interface.
On the switch, the single link connected to the router must be configured as a trunk link because routers don’t support DTP. If the trunk is configured as an 802.1Q trunk, a native VLAN must be defined if a VLAN other than the default will be used as the native VLAN. This native VLAN must also be configured on the respective router subinterface using the encapsulation dot1Q [vlan] native subinterface configuration command. The following output illustrates the configuration of inter-VLAN routing using a single physical interface (also referred to as “routeron- a-stick”). The two VLANs depicted in Figure 3.4 are shown in the following output, as is an additional VLAN used for Management; this VLAN will be configured as the native VLAN:
VTP-Server-1(config)#vlan 10 VTP-Server-1(config-vlan)#name Example-VLAN-10 VTP-Server-1(config-vlan)#exit VTP-Server-1(config)#vlan 20 VTP-Server-1(config-vlan)#name Example-VLAN-20 VTP-Server-1(config-vlan)#exit VTP-Server-1(config)#vlan 30 VTP-Server-1(config-vlan)#name Management-VLAN VTP-Server-1(config-vlan)#exit VTP-Server-1(config)#interface range FastEthernet0/1 – 2 VTP-Server-1(config-if-range)#switchport VTP-Server-1(config-if-range)#switchport access vlan 10 VTP-Server-1(config-if-range)#switchport mode access VTP-Server-1(config-if-range)#exit VTP-Server-1(config)#interface range FastEthernet0/3 – 4 VTP-Server-1(config-if-range)#switchport VTP-Server-1(config-if-range)#switchport access vlan 20 VTP-Server-1(config-if-range)#switchport mode access VTP-Server-1(config-if-range)#exit VTP-Server-1(config)#interface FastEthernet0/24 VTP-Server-1(config-if)#switchport VTP-Server-1(config-if)#switchport trunk encapsulation dot1q VTP-Server-1(config-if)#switchport mode trunk VTP-Server-1(config-if)#switchport trunk native vlan 30 VTP-Server-1(config-if)#exit VTP-Server-1(config)#interface vlan 30 VTP-Server-1(config-if)#description ‘This is the Management Subnet’ VTP-Server-1(config-if)#ip address 10.30.30.2 255.255.255.0 VTP-Server-1(config-if)#no shutdown VTP-Server-1(config-if)#exit VTP-Server-1(config)#ip default-gateway 10.30.30.1
The router illustrated in Figure 3.4 is configured as shown in the following output:
R1(config)#interface FastEthernet0/0 R1(config-if)#no ip address R1(config-if)#exit R1(config)#interface FastEthernet0/0.10 R1(config-subitf)#description ‘Subinterface For VLAN 10’ R1(config-subif)#encapsulation dot1Q 10 R1(config-subif)#ip add 10.10.10.1 255.255.255.0 R1(config-subif)#exit R1(config)#interface FastEthernet0/0.20 R1(config-subitf)#description ‘Subinterface For VLAN 20’ R1(config-subif)#encapsulation dot1Q 20 R1(config-subif)#ip add 10.20.20.1 255.255.255.0 R1(config-subif)#exit R1(config)#interface FastEthernet0/0.30 R1(config-subitf)#description ‘Subinterface For Management’ R1(config-subif)#encapsulation dot1Q 30 native R1(config-subif)#ip add 10.30.30.1 255.255.255.0 R1(config-subif)#exit
The primary advantage of this solution is that only a single physical interface is required on the router. The primary disadvantage is that the bandwidth of the physical interface is shared between the various configured subinterfaces. Therefore, if there is a lot of inter-VLAN traffic, the router can quickly become a bottleneck in the network.
Inter-VLAN Routing Using Switched Virtual Interfaces
Multilayer switches support the configuration of IP addressing on physical interfaces. These interfaces, however, must be configured with the no switchport interface configuration command to allow administrators to configure IP addressing on them. In addition to using physical interfaces, Multilayer switches also support Switched Virtual Interfaces (SVIs).
SVIs are logical interfaces that represent a VLAN. Although the SVI represents a VLAN, it is not automatically configured when a Layer 2 VLAN is configured on the switch; it must be manually configured by the administrator using the interface vlan [number] global configuration command. The Layer 3 configuration parameters, such as IP addressing, are then configured on the SVI in the same manner as they would be on a physical interface.
The following output illustrates the configuration of SVIs to allow inter-VLAN routing on a single switch. This output references the VLANs used in the previous configuration outputs in this section:
VTP-Server-1(config)#vlan 10 VTP-Server-1(config-vlan)#name Example-VLAN-10 VTP-Server-1(config-vlan)#exit VTP-Server-1(config)#vlan 20 VTP-Server-1(config-vlan)#name Example-VLAN-20 VTP-Server-1(config-vlan)#exit VTP-Server-1(config)#interface range FastEthernet0/1 – 2 VTP-Server-1(config-if-range)#switchport VTP-Server-1(config-if-range)#switchport mode access VTP-Server-1(config-if-range)#switchport access vlan 10 VTP-Server-1(config-if-range)#exit VTP-Server-1(config)#interface range FastEthernet0/3 – 4 VTP-Server-1(config-if-range)#switchport VTP-Server-1(config-if-range)#switchport mode access VTP-Server-1(config-if-range)#switchport access vlan 20 VTP-Server-1(config-if-range)#exit VTP-Server-1(config)#interface vlan 10 VTP-Server-1(config-if)#description “SVI for VLAN 10” VTP-Server-1(config-if)#ip address 10.10.10.1 255.255.255.0 VTP-Server-1(config-if)#no shutdown VTP-Server-1(config-if)#exit VTP-Server-1(config)#interface vlan 20 VTP-Server-1(config-if)#description ‘SVI for VLAN 10’ VTP-Server-1(config-if)#ip address 10.20.20.1 255.255.255.0 VTP-Server-1(config-if)#no shutdown VTP-Server-1(config-if)#exit
When using Multilayer switches, SVIs are the recommended method for configuring and implementing an inter-VLAN routing solution.
You can verify that the SVI is properly configured (IP addressing, etc.) by using the how interface vlan x command. The output is identical to a show interface x command:
Switch#show interfaces vlan 100
Vlan100 is up, line protocol is down
Hardware is EtherSVI, address is c200.06c8.0000 (bia c200.06c8.0000)
Internet address is 10.10.10.1/24
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
ARP type: ARPA, ARP Timeout 04:00:00
If you wish to use a 2960 switch to route IP packets, it will require a configuration change and reload. The reason for this is the 2960 and newer model switches are tuned to allocate resources in a certain way. The resource management is called the Switch Database Management (SDM) template. Your choices include the following:
• Default – balances all functions
• Dual IPv4/IPv6 – for use in dual-stack environments
• Lanbase-routing – supports Unicast routes
• QoS – gives support for QoS features
Here are the options on my 3750 switch. They don’t match the 2960 options exactly, but you get the idea. Also, bear in mind that your switch model and IOS will affect the configuration options, so check the configuration guide for your model:
Switch(config)#sdm prefer ? access Access bias default Default bias dual-ipv4-and-ipv6 Support both IPv4 and IPv6 ipe IPe bias lanbase-routing Unicast bias vlan VLAN bias
Lanbase-routing will need to be enabled if you wish to configure inter-VLAN routing on your 2960 switch. You will also need to reload the switch before the change will take effect. Here is the output of the show sdm prefer command, which tells you the current SDM configuration and resource allocation:
Switch#show sdm prefer The current template is “desktop default” template. The selected template optimizes the resources in the switch to support this level of features for 8 routed interfaces and 1024 VLANs. number of unicast mac addresses: 6K number of IPv4 IGMP groups + multicast routes: 1K number of IPv4 unicast routes: 8K number of directly-connected IPv4 hosts: 6K number of indirect IPv4 routes: 2K number of IPv4 policy based routing aces: 0 number of IPv4/MAC qos aces: 0.5K number of IPv4/MAC security aces: 1K Switch#
VTP
VLAN Trunking Protocol (VTP) is a Cisco proprietary Layer 2 messaging protocol that manages the addition, deletion, and renaming of VLANs on switches in the same VTP domain. VTP allows VLAN information to propagate through the switched network, which reduces administration overhead in a switched network, whilst enabling switches to exchange and maintain consistent VLAN information. This concept is illustrated in Figure 3.5 below:
Figure 3.5 – VTP Updates
Some benefits to using VTP include the following:
• Accurate monitoring and reporting of VLANs
• VLAN consistency across the network
• Ease of adding and removing VLANs
Configuring VTP
All switches must be configured with the same VTP domain name if they are to exchange VLAN information, as illustrated in the output below:
Switch(config)#vtp mode server ← this is on by default Switch(config)#vtp domain in60days Changing VTP domain name from NULL to in60days Switch#show vtp status VTP Version : 2 Configuration Revision : 0 Maximum VLANs Supported Locally : 255 Number of Existing VLANs : 5 VTP Operating Mode : Server VTP Domain Name : in60days
If you want to secure your VTP updates, you can add a password, but it must match on each switch in the VTP domain:
Switch(config)#vtp password Cisco321 Setting device VLAN database password to Cisco321
VTP Modes
VTP runs in the following three modes:
• Server (default)
• Client
• Transparent
You can see the server mode in the configuration and output above.
Server Mode
In Server mode, the switch is authorised to create, modify, and delete VLAN information for the entire VTP domain. Any changes you make to a server are propagated throughout the whole domain. VLAN configuration is stored in the VLAN database file “vlan.dat” located on the flash memory.
Client Mode
In Client mode, the switch will receive VTP information and apply any changes, but it does not allow adding, removing, or changing VLAN information on the switch. The client will also send the VTP packet received out of its trunk ports. Remember that you cannot add a switch port on a VTP client switch to a VLAN that does not exist on the VTP server. VLAN configuration is stored in the VLAN database file “vlan.dat” located on the flash memory.
Transparent Mode
In Transparent mode, the switch will forward the VTP information received out of its trunk ports, but it will not apply the changes. A VTP Transparent-mode switch can create, modify, and delete VLANs, but the changes are not propagated to other switches. VTP Transparent mode also requires configuration of domain information. A VTP transparent switch is needed when a switch separating a VTP server and client needs to have a different VLAN database. Transparent mode is needed to configure the extended VLAN range (1006 to 4096).
VTP Pruning
There will often be situations where you have VLANs 20 to 50, for example, on one side of your network and 60 to 80 on the other. It doesn’t make sense for VLAN information from the switches on one side to be passed to every switch on the other. For this reason, switches can prune unnecessary VLAN information on the switches, thus reducing the Broadcast traffic, as shown in Figure 3.6 below:
Figure 3.6 – VTP Pruning in Operation
The following line of configuration will add VTP pruning to your switch:
Switch(config)#vtp pruning
It is worth noting that if you have a switch set to transparent mode in-between two other switches, then pruning will not work.
Configuration Revision Number
The configuration revision number is a 32-bit number that indicates the level of revision for a VTP packet (see the show vtp status output above). This information is used to determine whether the received information is more recent than the current version. Each time that you make a VLAN change on a switch in VTP Server mode, the configuration revision is incremented by one and change will be propagated to VTP clients (switches in VTP Transparent mode will have a revision number of 0 and will not increase with database changes). In order to reset the configuration revision of a switch, change the VTP domain name, and then change the name back to the original name.
IMPORTANT NOTE: If a switch configured as VTP Server or VTP Client with a matching domain name and a higher revision number connects to the network, its database will be propagated to all other switches, potentially replacing their existing VTP databases. This can bring the whole LAN network down, so be very careful (always check the VTP status) when connecting a new switch to the LAN network!
Basic VLAN Troubleshooting
VLANs are a fairly straightforward feature which rarely requires troubleshooting. A few of the problems that you will see are mostly configuration errors. We will cover Layer 2 troubleshooting in detail on Section 15. Common problems include the following:
- Inter-VLAN routing not working: Check to ensure that the link between the switches and the routers is set up correctly, and the relevant VLANs are allowed and not pruned (see VTP pruning). The show interface trunk command will provide the required information. Also, check to ensure that the router’s subinterfaces are configured with correct encapsulation and VLAN, and the subinterface’s IP address is the default gateway for the hosts.
- VLANs cannot be created: Check whether the VTP mode on the switch is set to “client.” VLANs cannot be created if the VTP mode is client. Another important factor is the number of VLANs allowed on the switch. The show vtp status command will provide the information required (see the Troubleshooting Trunking and VTP section below).
- Hosts within the same VLAN cannot reach each other: It is important that hosts in a VLAN have an IP address that belongs to the same subnet. If the subnet is different, then they will not be able to reach each other. Another factor to consider is whether the hosts are connected to the same switch. If they are not connected to the same switch, then ensure that the trunk link(s) between the switches is/are working correctly and that the VLAN is not excluded/not pruned from the allowed list. The show interface trunk command will show needed information regarding the trunk link.
Troubleshooting Trunking and VTP
The following are examples of problems and possible solutions:
Trunk down?
• Interface must be up/up
• Encapsulation must match both sides
SwitchA#show interface fa1/1 switchport Name: Fa1/1 Switchport: Enabled Administrative Mode: trunk Operational Mode: trunk Administrative Trunking Encapsulation: dot1q Operational Trunking Encapsulation: dot1q Negotiation of Trunking: Disabled Access Mode VLAN: 0 ((Inactive))
VLAN information not passing?
• Is the VLAN blocked on the trunk?
Switch#show interface trunk
VTP information not reaching the client?
• Correct domain and VTP password?
show vtp status / show vtp password
Added a new switch and all VTP information has changed?
• Always add a new switch in Client mode (but check the above note on the configuration
revision number)
• Server mode will propagate new information
VTP pruning not working?
• Is there a transparent switch in the middle?
• Is the VLAN allowed across the trunk?
Troubleshooting Inter-VLAN Routing
Inter-VLAN routing issues can come in many forms, especially considering that multiple devices are involved (switches, routers, etc.) in the process. By following a proper troubleshooting methodology, you should be able to isolate the problem to a particular device and then map it to a specific feature that has been misconfigured.
From a connectivity standpoint, some of the things that need to be checked include:
• Verfiying that the end-stations are connected in the proper switch ports
• Verifying that the proper switch ports are connected in the proper router ports (if a router
is used for inter-VLAN routing)
• Verifying that each of the ports involved in this process carry the correct VLANs
° The ports that connect the end-stations are usually access ports allocated to a
particular VLAN
° The ports connecting the switch to the router are usually trunk ports
After confirming that the connectivity between the devices is correct, the next logical step is investigating Layer 2 configuration, starting with the configured encapsulation method on the trunk ports, which is usually 802.1Q, the preferred method. Next, make sure that the same encapsulation is configured on both ends of the trunk link.
Some of the commands that can be used to verify the encapsulation types are as follows:
• show interface trunk • show interface <number> switchport
Here is an example output:
Cat-3550-1#show interfaces trunk Port Mode Encapsulation Status Native vlan Fa0/1 on 802.1q trunking 1 Fa0/2 on 802.1q trunking 1 Port Vlans allowed on trunk Fa0/1 1,10,20,30,40,50 Fa0/2 1-99,201-4094
Another important detail that is offered by the show interface trunk command is the trunk status. This confirms whether the trunk is formed or not and it has to be checked at both ends of the link. If the interface is not in “trunking” mode, one of the most important things that has to be verified is the mode of operation (on, auto, etc.) to see whether it will allow a trunking state to form with the other end of the link.
The native VLAN is another important element that you should verify on the trunk ports. Misconfigured native VLANs can lead to a lack of functionality or security issues. The native VLAN should match at both ends of the trunk links.
If after verifying the Layer 2 verification tasks the inter-VLAN issue is still not resolved, you can proceed to verifying Layer 3 configuration. Depending upon the Layer 3 device used to ensure the actual inter-VLAN routing, this can be configured/verified on one of the following devices:
• Multilayer switch
• Router – physical interfaces
• Router – subinterfaces
On the Layer 3 device, you should verify that the correct subnet is assigned to each interface (or SVI), and you should also verify the routing protocol, if needed. Usually, a different subnet is assigned to each VLAN so you should make sure that you don’t misconfigure the interfaces. In order to verify this you can use the show interface command for the specific physical interface, subinterface, or SVI.
Section 3 Questions
1. Name four advantages of using VLANs.
2. Hosts in the same VLAN can be in different subnets. True or false?
3. An access link is part of more than one VLAN. True or false?
4. Name the two trunk link encapsulation types.
5. Which commands will configure and name a VLAN?
6. A trunk link on a switch can be in which five possible modes?
7. Which command would put your interface into VLAN 5?
8. Which command will change the native VLAN?
9. VTP Client mode allows you to configure VLANs. True or false?
10. Name three benefits of using VTP.
11. Which command configures VTP pruning on your switch?
Section 3 Answers
1. Containing Broadcasts within a smaller group of devices will make the network faster; saves resources on devices because they process less Broadcasts; added security by keeping devices in a certain group (or function) in a separate Broadcast domain; and flexibility in expanding a network across a geographical location of any size.
2. True, but not recommended.
3. False.
4. 802.1Q and ISL.
5. The vlan x and name y commands.
6. On, off, auto, desirable, and nonegotiate.
7. The switchport access vlan 5 command.
8. The switchport trunk native vlan x command.
9. False.
10. Accurate monitoring and reporting of VLANs; VLAN consistency across the network; and
ease of adding and removing VLANs.
11. The vtp pruning command.
Section 3 Labs
VLAN and Trunking Lab
Topology
Purpose
Learn how to configure VLANs and trunk links.
Walkthrough
1. You will need to add IP addresses on each PC. Feel free to choose your own, as long as they are on the same subnet!
2. On Switch A, set the hostname, create VLAN 2, and put the interface to which your PC is connected into VLAN 2, You can also give the VLAN a name if you wish.
Switch>en
Switch#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Switch(config)#hostname SwitchA
SwitchA(config)#vlan 2
SwitchA(config-vlan)#name 60days
SwitchA(config-vlan)#interface FastEthernet0/1
SwitchA(config-if)#switchport mode access
SwitchA(config-if)#switchport access vlan 2
SwitchA(config-if)#^Z
SwitchA#show vlan brief
VLAN Name Status Ports
---- --------- -------------------------------
1 default active Fa0/2, Fa0/3, Fa0/4, Fa0/5,
Fa0/6, Fa0/7, Fa0/8, Fa0/9,
Fa0/10, Fa0/11, Fa0/12, Fa0/13,
Fa0/14, Fa0/15, Fa0/16, Fa0/17,
Fa0/18, Fa0/19, Fa0/20, Fa0/21,
Fa0/22, Fa0/23, Fa0/24
2 60days active Fa0/1
1002 fddi-default active
1003 token-ring-default active
1004 fddinet-default active
1005 trnet-default active
SwitchA#
3. Set your trunk link to trunk mode.
SwitchA#conf t Enter configuration commands, one per line. End with CNTL/Z. SwitchA(config)#int FastEthernet0/2 SwitchA(config-if)#switchport mode trunk SwitchA#show interface trunk Port Mode Encapsulation Status Native vlan Fa0/2 on 802.1q trunking 1 Port Vlans allowed on trunk Fa0/2 1-1005
4. If you wish, permit only VLAN 2 on the trunk link.
SwitchA(config)#int FastEthernet0/2 SwitchA(config-if)#switchport trunk allowed vlan 2 SwitchA(config-if)#^Z SwitchA# %SYS-5-CONFIG_I: Configured from console by console SwitchA#show int trunk Port Mode Encapsulation Status Native vlan Fa0/2 on 802.1q trunking 1 Port Vlans allowed on trunk Fa0/2 2
5. At this point, if you ping from one PC to another, it should fail. This is because one side is
in VLAN 1 and the other is in VLAN 2.
PC>ping 192.168.1.1
Pinging 192.168.1.1 with 32 bytes of data:
Request timed out.
Ping statistics for 192.168.1.1:
Packets: Sent = 2, Received = 0, Lost = 2 (100% loss)
6. Configure the same commands on Switch B now. For VLAN creation, put the PC port into
VLAN 2, and set the interface to “access” and the trunk link to “trunk.”
7. Now you should be able to ping across the trunk link from PC to PC.
PC>ping 192.168.1.1
Pinging 192.168.1.1 with 32 bytes of data:
Reply from 192.168.1.1: bytes=32 time=188ms TTL=128
Reply from 192.168.1.1: bytes=32 time=78ms TTL=128
Reply from 192.168.1.1: bytes=32 time=94ms TTL=128
Reply from 192.168.1.1: bytes=32 time=79ms TTL=128
Ping statistics for 192.168.1.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 78ms, Maximum = 188ms, Average = 109ms
VTP Lab
Test the VTP configuration commands presented in this module in a topology made up of two
switches:
• Configure one of the switches as a VTP server
• Configure the other switch as a VTP client
• Configure the same VTP domain and password on both switches
• Create a series of VLANs on the server switch and see how they propagate to each other
• Configure VTP pruning on both switches
• Verify (show) the VTP configuration on both switches
• Configure a different VTP domain name and password and repeat the process; see how the results differ