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