result in entire VLANs being deleted. The first
indication of a VTP problem often occurs when a VLAN is created
on a switch but the VLAN fails to propagate to all other
switches within the domain. When this occurs the first thing to
check is the VTP mode. Each switch can be placed into one of
the following VTP modes: - Server
- Client
- Transparent
Changes to the VLAN
configuration within a VTP domain can only be made on a switch
that is in the VTP server mode. Furthermore, VLAN information
will only be propagated to switches in a VTP mode of Server or
Client that are in the same VTP Domain. The VTP mode and domain
can be verified using the show vtp status
command. This problem occurs when there is a large switched
network where all switches are part of the same VTP domain, and
another switch is added to the network. Assume that this
switch has been previously used, and already has an appropriate
VTP domain name entered. The switch is configured as a VTP
client, and then connected to the rest of the network. The
instant the trunk link is brought up to the rest of the
network, the whole network goes down. What could have happened?
The most likely explanation is that the configuration revision
number of the inserted switch was higher than the configuration
revision of the VTP domain. Therefore, the recently introduced
switch with minimal VLAN information has erased all VLANs
through the VTP domain. This situation will happen whether the
switch is a VTP client or a VTP server. A VTP client can erase
VLAN information on a VTP server. This is evident when many of
the ports in the network go into inactive state and are
assigned to a non-existing VLAN. Quickly reconfigure all of the
VLANs on one of the VTP servers. Always make sure that the
configuration revision of all switches inserted into the VTP
domain is lower than the configuration revision of the switches
already in the VTP domain.
Content 4.3
Troubleshooting Switched Ethernet Networks 4.3.8
Troubleshooting EtherChannel Fast EtherChannel allows
multiple physical Fast Ethernet links to be combined into one
logical channel. This allows load sharing of traffic among the
links in the channel as well as redundancy in the event that
one or more links in the channel should fail. Fast EtherChannel
can be used to interconnect LAN switches, routers, servers, and
clients via unshielded twisted-pair (UTP) wiring or single mode
and multimode fiber. The Fast EtherChannel, Gigabit
EtherChannel, Port Channel, Channel and Port Group will all
refer to EtherChannel, so the information given in this
document applies to all of the above EtherChannels. From the
STP point of view, an EtherChannel is seen as a single port.
This presents a danger of creating forwarding loops if
channeling ports are not consistent on both sides of the
channel. For example, if switch A has two separate links and
switch B considers those same links as part of the channel,
switch B will send a broadcast or unknown unicast packet. That
packet will be forwarded back to switch B, as seen in the
diagram. This causes packet duplication and changes the
forwarding table on switch B to point in the wrong direction.
Symptoms associated with misconfigured EtherChannels include:
- Loss of connectivity due to switching loops.
- Increased backplane utilization may be noticed from the
LEDs on a normally lightly loaded switch.
- Console
messages reporting that ports are rapidly relearning MAC
addresses.
- Interfaces may be automatically placed
into an “ErrDisable” state.
When configuring
EtherChannel, ensure that both sides of the link are configured
correctly. Ports will not form an EtherChannel unless they are
identically configured in terms of speed, duplex, native VLAN
trunk etc. The goal of EtherChannel is to distribute traffic
over several physical links to enhance performance and
availability. One area that is often not considered when
configuring EtherChannel is how EtherChannel determines the
physical link over which the frame will be sent. The following
is a summary of the default behavior for EtherChannel in a
switched and routed environment: - Switches allocate
links based on Layer 2 addresses.
- Routers allocate
links based on Layer 3 addresses.
- Switches allocate
links based on source address.
- Routers allocate links
based on destination address.
Strictly speaking,
this summary is only true of lower end switches and routers
such as 2500, 2600, 2950T and 3550. Higher end routers and
switches may take into account all of the above as well as TCP
port numbers when making a link forwarding decision. Assuming
that the routers and switches in the network are using these
defaults, then load balancing will work well in typical
topologies. In these situations, the switch sees many source
MAC addresses and the router sees many destination IP
addresses. This allows traffic to be effectively spread across
the available links However, consider the situation in Figure .
The top switch is forwarding traffic across the EtherChannel
based on the source MAC address. In this instance there is
only one source MAC address, which is the MAC address on the
router. Consequently, traffic flowing from the router to the
PCs will use only a single Ethernet link. The solution is to
configure the top switch to allocate links based on the
destination MAC address using the port-channel load-balance
{dst-mac | src-mac} global configuration command:
switch(config)#port-channel load-balance dst-mac
Wherever possible and whenever supported by the network device,
use a mechanism for distributing traffic that takes into
account many addresses when determining which link to use. If
the switches or routers support only minimal addresses for
making the distribution decision, take particular care to
consider the Layer 2 data flow destined for, or sourced from,
single nodes such as Routers, Servers and storage- area network
(SAN) devices.
Content 4.4 Troubleshooting
ISDN 4.4.1 T1 framing errors When an
interface receives a frame, the receiving party must be able to
locate several parts. They are the start of a frame, the
components within the frame and the end of the frame. These low
level activities rely on the receiver being able to extract
clocking information from the signal and recognize the
difference between a 1 and a 0. Where these essential elements
break down framing errors will occur. Framing errors are most
likely to occur where different frame and encoding formats are
used and where equipment from different vendors is expected to
work together. This situation is likely to occur where
corporate networks link to those provided by telcos. Although
this topic concentrates on T1 connections such as the ISDN
Primary Rate services, the principles are broadly applicable to
other Layer 2 technologies. In Figure , the show
controllers t1 exec command provides the following
information that can be used to determine whether or not
framing errors are occurring: - Statistics about the T1
link. If a slot and a port number are specified, statistics
for each 15 minute period will be displayed.
- Information to troubleshoot physical layer and data-link
layer problems.
- Local or remote alarm information, if
any, on the T1 line.
Use the show
controllers command to verify if there are alarms or errors
displayed by the controller. To determine if the framing, line
coding, and slip seconds error counters are increasing, use
the show controllers t1 command repeatedly. Note the
values of the counters for the current interval. As a first
step when troubleshooting a suspected framing problem, ask the
telco or service provider to provide details of the required
framing and line coding settings. It is common to use Binary
8-Zero Substitution (B8ZS) line coding with Extended Super
Frame (ESF), and Alternate Mark Inversion (AMI) line coding
with Super Frame (SF). If Slips Secs are present on the T1