Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
Another important aspect of troubleshooting is the ability to identify and resolve VTP
issues, assuming port connectivity and VLAN problems have been identified and resolved.
Figure 2-40 shows the flow used for troubleshooting VTP issues.
Figure 2-40 VTP Troubleshooting
Unable to See VLAN Details in the show run Command Output
VTP client and server systems require VTP updates from other VTP servers to be
immediately saved without user intervention. A VLAN database was introduced into Cisco
IOS Software as a method to immediately save VTP updates for VTP clients and servers.
In some versions of software, this VLAN database is in the form of a separate file in Flash,
called the vlan.dat file. You can view VTP and VLAN information that is stored in the
vlan.dat file for the VTP client or VTP server if you issue the show vtp status command.
VTP server and client mode switches do not save the entire VTP and VLAN configuration
to the startup-config file in NVRAM when you issue the copy running-config startupconfig
command on these systems. VTP saves the configuration in the vlan.dat file. This
behavior does not apply to systems that run in VTP transparent mode. VTP transparent
Troubleshoot
Physical Layer
Port Connectivity
Issues
Troubleshoot
VLAN/Trunking
Issues
Troubleshoot
VTP
Issues
Troubleshoot
Spanning-Tree
Issues
Can you
see VLAN
details in the
show run
command
output?
Do switches
exchange VTP
information?
Does an
inserted switch
cause network
problems?
Are all
ports inactive
after power
cycle?
Troubleshooting Switched Networks 83
switches save the entire VTP and VLAN configuration to the startup-config file in NVRAM
when you issue the copy running-config startup-config command. For example, if you
delete the vlan.dat file on a VTP server or client mode switch after you have configured
VLANS, and then you reload the switch, VTP is reset to the default settings. (All userconfigured
VLANs are deleted.) But if you delete the vlan.dat file on a VTP transparent
mode switch and then reload the switch, it retains the VTP configuration. This is an example
of default VTP configuration.
You can configure normal-range VLANs (2 through 1000) when the switch is in either VTP
server or transparent mode. But on the Cisco Catalyst 2960 switch, you can configure
extended-range VLANs (1025 through 4094) only on VTP-transparent switches.
Cisco Catalyst Switches Do Not Exchange VTP Information
When Cisco switches do not exchange VTP information, you need to be able to determine
why they are not functioning properly. Use the following guidelines to troubleshoot this
problem:
■ There are several reasons why VTP fails to exchange the VLAN information. Verify
these items if switches that run VTP fail to exchange VLAN information.
■ VTP information passes only through a trunk port. Ensure that all ports that
interconnect switches are configured as trunks and are actually trunking.
■ Ensure that the VLANs are active on all the VTP server switches.
■ One of the switches must be a VTP server in the VTP domain. All VLAN changes must
be done on this switch to have them propagated to the VTP clients.
■ The VTP domain name must match, and it is case sensitive. For example, CISCO and
cisco are two different domain names.
■ Ensure that no password is set between the server and client. If any password is set,
ensure that it is the same on both sides. The password is also case sensitive.
■ Every switch in the VTP domain must use the same VTP version. VTP version 1
(VTPv1) and VTP version 2 (VTPv2) are not compatible on switches in the same VTP
domain. Do not enable VTPv2 unless every switch in the VTP domain supports
version 2.
NOTE VTPv2 is disabled by default on VTPv2-capable switches. When you
enable VTPv2 on a switch, every VTPv2-capable switch in the VTP domain enables
version 2. You can only configure the version on switches in VTP server or
transparent mode.
84 Chapter 2: Medium-Sized Switched Network Construction
■ A switch that is in VTP transparent mode and uses VTPv2 propagates all VTP
messages, regardless of the VTP domain that is listed. However, a switch running
VTPv1 propagates only VTP messages that have the same VTP domain as the domain
that is configured on the local switch. VTP transparent mode switches that are using
VTPv1 drop VTP advertisements if they are not in the same VTP domain.
■ The extended-range VLANs are not propagated. So you must configure extendedrange
VLANs manually on each network device.
■ The updates from a VTP server are not updated on a client if the client already has a
higher VTP revision number. In addition, the client does not propagate the VTP
updates to its downstream VTP neighbors if the client has a higher revision number
than that which the VTP server sends.
Recently Installed Switch Causes Network Problems
A newly installed switch can cause problems in the network when all the switches in your
network are in the same VTP domain, and you add a switch into the network that does not
have the default VTP and VLAN configuration.
If the configuration revision number of the switch that you insert into the VTP domain is
higher than the configuration revision number on the existing switches of the VTP domain,
your recently introduced switch overwrites the VLAN database of the domain with its own
VLAN database. This happens whether the switch is a VTP client or a VTP server. A VTP
client can erase VLAN information on a VTP server. A typical indication that this has
happened is when many of the ports in your network go into an inactive state but continue
to be assigned to a nonexistent VLAN.
To prevent this problem from occurring, always ensure that the configuration revision
number of all switches that you insert into the VTP domain is lower than the configuration
revision number of the switches that are already in the VTP domain. You can accomplish
this by changing the VTP mode to transparent and then back to server or client. You can
also accomplish it by changing the VTP domain name and then changing it back.
All Ports Inactive After Power Cycle
Switch ports move to the inactive state when they are members of VLANs that do not exist
in the VLAN database. A common issue is all the ports moving to this inactive state after a
power cycle. Generally, you see this issue when the switch is configured as a VTP client
with the uplink trunk port on a VLAN other than VLAN1. Because the switch is in VTP
client mode, when the switch resets, it loses its VLAN database and causes the uplink port
and any other ports that were not members of VLAN1 to become inactive.
Troubleshooting Switched Networks 85
Complete these steps to solve this problem:
Step 1 Temporarily change the VTP mode to transparent.
Step 2 Add the VLAN to which the uplink port is assigned to the VLAN
database.
Step 3 Change the VTP mode back to client after the uplink port begins
forwarding.
Troubleshooting Spanning Tree
It is also important to know how to identify and resolve spanning-tree issues, assuming port
connectivity, VLAN, and VTP problems have been identified and resolved. Figure 2-41
shows the flow for troubleshooting STP.
Figure 2-41 Troubleshooting STP
Use the Diagram of the Network
Before you troubleshoot a bridging loop, you must at least be aware of the following:
■ The topology of the bridge network
■ The location of the root bridge
■ The location of the blocked ports and the redundant links
Troubleshoot
Physical Layer
Port Connectivity
Issues
Troubleshoot
VLAN
Issues
Troubleshoot
VTP/Trunking
Issues
Troubleshoot
Spanning-Tree
Issues
Use
Network Diagram
to ID Root and
Blocked Ports
Identify
Bridging Loop
and Restore
Connectivity
Quickly
Check STP
Log Events
Verify Root
Bridge Selection
and That RSTP
Is Enabled
86 Chapter 2: Medium-Sized Switched Network Construction
This knowledge is essential for the following reasons:
■ Before you can determine what to fix in the network, you must know how the network
looks when it is functioning correctly.
■ Most of the troubleshooting steps simply use show commands to identify error
conditions. Knowledge of the network helps you focus on the critical ports on the key
devices.
Identify a Bridging Loop
It used to be that a broadcast storm could have a disastrous effect on the network. Today,
with high-speed links and devices that provide switching at the hardware level, it is not
likely that a single host, such as a server, will bring down a network through broadcasts.
The best way to identify a bridging loop is to capture the traffic on a saturated link and
verify that you see similar packets multiple times. Realistically, however, if all users in a
certain bridge domain have connectivity issues at the same time, you can already suspect a
bridging loop. Check the port utilization on your devices to determine whether abnormal
values are present.
Restore Connectivity Quickly
Bridging loops have extremely severe consequences on a switched network. Administrators
generally do not have time to look for the cause of the loop, and they prefer to restore
connectivity as soon as possible. The easy way out in this case is to manually disable every
port that provides redundancy in the network.
Disable Ports to Break the Loop
If you can identify the part of the network that is affected most, begin to disable ports in
this area. Or, if possible, initially disable ports that should be blocking. Each time you
disable a port, check to see if you have restored connectivity in the network. By identifying
which disabled port stops the loop, you also identify the redundant path of this port. If this
port should have been blocking, you have probably found the link on which the failure
appeared.
Log STP Events
If you cannot precisely identify the source of the problem, or if the problem is transient,
enable the logging of STP events on the switches of the network that experiences the
failure. If you want to limit the number of devices to configure, at least enable this logging
on devices that host blocked ports; the transition of a blocked port is what creates a loop.
Issue the privileged EXEC command debug spanning-tree events to enable STP debug
information. Issue the global configuration mode command logging buffered to capture
Troubleshooting Switched Networks 87
this debug information in the device buffers. You can also try to send the debug output to a
syslog device. Unfortunately, when a bridging loop occurs, you seldom maintain
connectivity to a syslog server.
Temporarily Disable Unnecessary Features
Disable as many features as possible to help simplify the network structure and ease the
identification of the problem. For example, EtherChannel is a feature that requires STP to
logically bundle several different links into a single link, so disabling this feature during
troubleshooting makes sense. As a rule, make the configuration as simple as possible to ease
troubleshooting.
Designate the Root Bridge
Often, information about the location of the spanning-tree root bridge is not available at
troubleshooting time. Do not let STP decide which switch becomes the root bridge. For
each VLAN, you can usually identify which switch can best serve as the root bridge. Which
switch would make the best root bridge depends on the design of the network. Generally,
choose a powerful switch in the middle of the network. If you put the root bridge in the
center of the network with direct connection to the servers and routers, you generally reduce
the average distance from the clients to the servers and routers. For each VLAN, hard code
which switches will serve as the root bridge and which will serve as the backup (secondary)
root bridge.
Verify the Configuration of RSTP
The 802.1d and PVST+ spanning-tree protocols have convergence times between 30 and
50 seconds. The RSTP and PVRST+ spanning-tree protocols have convergence times
within one or two seconds. A slow convergence time may indicate that not all of the
switches in your network have been configured with RSTP, which can slow the convergence
times globally in your network. Use the show spanning-tree command to verify the
spanning tree mode.
Summary of Troubleshooting Switched Networks
The list that follows summarizes the key points that were discussed in this section.
■ Effective switched-network troubleshooting begins by understanding what makes a
network function correctly.
■ Hardware issues and port configuration errors can cause port connectivity issues.
■ Native VLAN mismatches and trunk mode mismatches can prevent a trunk link from
being established.
88 Chapter 2: Medium-Sized Switched Network Construction
■ Understanding how VTP works is the best defense when troubleshooting VTP
problems.
■ One of the primary objectives when dealing with an STP failure is to break the loop
and restore connectivity as soon as possible.
No comments:
Post a Comment