Troubleshooting LAN Switching Environments

Document ID: 12006

This information from the Internetwork Troubleshooting Guide was first posted on CCO here. As a service to our customers, selected chapters have been updated with the most current and accurate information. The complete update to the Internetwork Troubleshooting Guide will soon be available in print and online.

Introduction
Prerequisites
      Requirements
      Conventions
LAN Switching Introduction
      Hubs and Switches
      Bridges and Switches
      VLANs
      Transparent Bridging Algorithm
      Spanning Tree Protocol
      Trunking
      EtherChannel
      MultiLayer Switching (MLS)
      How to Learn About These Features
General Switch Troubleshooting Suggestions
Troubleshooting Port Connectivity Problems
      Hardware Issues
      Configuration Issues
      Traffic Issues
      Switch Hardware Failure
Troubleshooting Ethernet 10/100Mb Half/Full Duplex Auto-Negotiation
      Objectives
      Introduction
      Troubleshooting Ethernet Auto Negotiation Between Network Infrastructure Devices
      Procedures and/or Scenarios
      Example of Configuring and Troubleshooting Ethernet 10/100Mb Auto-Negotiation
      Step-by-Step
      Before You Call the Cisco Systems Technical Support Team
Configuring EtherChannel Switch-to-Switch Connections on Catalyst 4000/5000/6000 Switches
      Tasks for Manual Configuration of EtherChannel
      Step-by-Step
      Verify the Configuration
      Use PAgP to Configure EtherChannel (Preferred Method)
      Trunking and EtherChannel
      Troubleshooting EtherChannel
      Commands Used in this Section
Using Portfast and Other Commands to Fix End-Station Startup Connectivity Problems
      Contents
      Background
      How to Reduce Startup Delay on the Catalyst 4000/5000/6000 Switch
      Timing Tests With and Without DTP, PAgP, and Portfast on a Catalyst 5000
      How to Reduce Startup Delay on the Catalyst 2900XL/3500XL Switch
      Timing Tests on the Catalyst 2900XL
      How to Reduce Startup Delay on the Catalyst 1900/2800 Switch
      Timing Tests on the Catalyst 1900
      An Additional Benefit to Portfast
      Commands to Use for Verifying the Configuration Works
      Commands to Use to Troubleshoot the Configuration
Configure and Troubleshoot IP Multi-Layer Switching (MLS)
      Objectives
      Introduction
      Troubleshooting IP MLS Technology
      Commands or Screen Captures
      Before You Call the Cisco Systems Technical Support Team
NetPro Discussion Forums - Featured Conversations
Related Information

Introduction

The sections in this chapter describe common LAN switch features and solutions to some of the most common LAN switching problems. These items are covered:

LAN Switching Introduction
General switch troubleshooting suggestions
Troubleshooting port connectivity problems
Troubleshooting Ethernet 10/100Mb half/full duplex auto-negotiation
ISL trunking on Catalyst 5000 and 6000 family switches
Configuring and troubleshooting EtherChannel switch to switch
Using Portfast and other commands to fix end-station startup connectivity problems
Configuring and troubleshooting multilayer switching

Prerequisites

Requirements

There are no specific requirements for this document.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

If you are new to LAN switching, these sections take you through some of the main concepts related to switches. One of the prerequisites to troubleshooting any device is to know the rules under which it operates. Switches have become much more complex over the last few years because they have gained in popularity and sophistication. These paragraphs describe some of the key concepts to know about switches.

Hubs and Switches

Because of the great demand placed on local area networks, we have seen a shift from a shared bandwidth network, with hubs and coaxial cable, to a dedicated bandwidth network, with switches. A hub allows multiple devices to be connected to the same network segment. The devices on that segment share the bandwidth with each other. If it is a 10Mb hub, and there are 6 devices connected to 6 different ports on the hub, all six devices share the 10Mb of bandwidth with each other. A 100Mb hub shares 100Mb of bandwidth among the connected devices. In terms of the OSI model, a hub is considered a layer-one (physical layer) device. It hears an electrical signal on the wire and passes it along to the other ports.

A switch can physically replace a hub in your network. A switch allows multiple devices to be connected to the same network, just like a hub does, but this is where the similarity ends. A switch allows each connected device to have dedicated bandwidth instead of shared bandwidth. The bandwidth between the switch and the device is reserved for communication to and from that device alone. Six devices connected to six different ports on a 10Mb switch each have 10Mb of bandwidth to work with, instead of shared bandwidth with the other devices. A switch can greatly increase the available bandwidth in your network, which can lead to improved network performance.

Bridges and Switches

A basic switch is considered a layer-two device. When we use the word layer, we are referring to the 7-layer OSI model. A switch does not just pass electrical signals along, like a hub does; instead, it assembles the signals into a frame (layer two), and then decides what to do with the frame. A switch determines what to do with a frame by borrowing an algorithm from another common networking device: a transparent bridge. Logically, a switch acts just like a transparent bridge would, but it can handle frames much faster than a transparent bridge could (because of special hardware and architecture). Once a switch decides where the frame should be sent, it passes the frame out the appropriate port (or ports). You can think of a switch as a device creating instantaneous connections between various ports, on a frame by frame basis.

VLANs

Since the switch decides on a frame by frame basis which ports exchange data, it is a natural extension to put logic inside the switch to allow it to choose ports for special groupings. This grouping of ports is called a Virtual Local Area Network (VLAN). The switch makes sure that traffic from one group of ports never gets sent to other groups of ports (which would be routing). These port groups (VLANs) can each be considered an individual LAN segment.

VLANs are also described as broadcast domains. This is because of the transparent bridging algorithm, which says that broadcast packets (packets destined for the all devices address) be sent out all ports that are in the same group (that is, in the same VLAN). All ports that are in the same VLAN are also in the same broadcast domain.

Transparent Bridging Algorithm

The transparent bridging algorithm and spanning tree are covered in more detail elsewhere (Chapter 20: Troubleshooting Transparent Bridging Environments). When a switch receives a frame, it must decide what to do with that frame. It could ignore the frame; it could pass the frame out one other port, or it could pass the frame out many other ports.

In order to know what to do with the frame, the switch learns the location of all devices on the segment. This location information is placed in a Content Addressable Memory table (CAM - named for the type of memory used to store these tables). The CAM table shows, for each device, the MAC address of the device, out which port that MAC address can be found, and with which VLAN this port is associated. The switch continually does this learning process as frames are received into the switch. The CAM table of the switch is continually updated.

This information in the CAM table is used to decide how a received frame is handled. In order to decide where to send a frame, the switch looks at the destination MAC address in a received frame and looks up that destination MAC address in the CAM table. The CAM table shows which port the frame must be sent out in order for that frame to reach the specified destination MAC address. Here are the basic rules that a switch uses to carry out the frame forwarding responsibility:

If the destination MAC address is found in the CAM table, the switch sends the frame out the port that is associated with that destination MAC address in the CAM table. This is called forwarding.
If the associated port to send the frame out is the same port that the frame originally came in on, there is no need to send the frame back out that same port, and the frame is ignored. This is called filtering.
If the destination MAC address is not in the CAM table (the address is unknown), the switch sends the frame out all other ports that are in the same VLAN as the received frame. This is called flooding. It does not flood the frame out the same port on which the frame was received.
If the destination MAC address of the received frame is the broadcast address (FFFF.FFFF.FFFF), the frame is sent out all ports that are in the same VLAN as the received frame. This is also called flooding. The frame is not sent out the same port on which the frame was received.

Spanning Tree Protocol

As we have seen, the transparent bridging algorithm floods unknown and broadcast frames out of all the ports that are in the same VLAN as the received frame. This causes a potential problem. If the network devices that run this algorithm are connected together in a physical loop, flooded frames (like broadcasts) are passed from switch to switch, around and around the loop, forever. Dependent upon the physical connections involved, the frames can actually multiply exponentially due to the flooding algorithm, which can cause serious network problems.

There is a benefit to a physical loop in your network: it can provide redundancy. If one link fails, there is still another way for the traffic to reach its destination. In order to allow the benefits derived from redundancy, without breaking the network because of flooding, a protocol called spanning tree was created. Spanning tree was standardized in the IEEE 802.1d specification.

The purpose of the spanning tree protocol (STP) is to identify and temporarily block the loops in a network segment or VLAN. The switches run the STP, which involves electing a root bridge or switch. The other switches measure their distance from the root switch. If there is more than one way to get to the root switch, there is a loop. The switches follow the algorithm to determine which ports must be blocked in order to break the loop. STP is dynamic; if a link in the segment fails, ports that were originally blocking can possibly be changed to forwarding mode.

Trunking

Trunking is a mechanism that is most often used to allow multiple VLANs to function independently across multiple switches. Routers and servers can use trunking, as well, which allows them to live simultaneously on multiple VLANs. If your network only has one VLAN in it, you might never need trunking; but if your network has more than one VLAN, you probably want to take advantage of the benefits of trunking.

A port on a switch normally belongs to only one VLAN; any traffic received or sent on this port is assumed to belong to the configured VLAN. A trunk port, on the other hand, is a port that can be configured to send and receive traffic for many VLANs. It accomplishes this when it attaches VLAN information to each frame, a process called tagging the frame. Also, trunking must be active on both sides of the link; the other side must expect frames that include VLAN information for proper communication to occur.

There are different methods of trunking dependent upon the media that is used. Trunking methods for Fast Ethernet or Gigabit Ethernet are Inter-Switch Link (ISL) or 802.1q. Trunking over ATM uses LANE. Trunking over FDDI uses 802.10.

EtherChannel

EtherChannel is a technique that is used when you have multiple connections to the same device. Rather than each link function independently, EtherChannel groups the ports together to work as one unit. It distributes traffic across all the links and provides redundancy if one or more links fail. EtherChannel settings must be the same on both sides of the links involved in the channel. Normally, spanning tree would block all of these parallel connections between devices because they are loops, but EtherChannel runs underneath spanning tree, so that spanning tree thinks all the ports within a given EtherChannel are only a single port.

MultiLayer Switching (MLS)

MultiLayer switching (MLS) is the ability of a switch to forward frames based on information in the layer-three and sometimes layer-four header. This usually applies to IP packets but now also can occur for IPX packets. The switch learns how to handle these packets when it communicates with one or more routers. With a simplified explanation, the switch watches how the router processes a packet, and then the switch processes future packets in this same flow. Traditionally, switches have been much faster at switching frames than routers, so to have them offload traffic from the router can result in significant speed improvements. If something changes in the network, the router can tell the switch to erase its layer-three cache and build it from scratch again as the situation evolves. The protocol used to communicate with the routers is called MultiLayer Switching Protocol (MLSP).

How to Learn About These Features

These are just some of the basic features that switches support. More are added every day. It is important to understand how your switches work, which features you use, and how those features should work. One of the best places to learn this information about Cisco switches is on the Cisco web site. Go to and under the section Service & Support, choose Technical Documents. From here, choose Documentation Home Page. Documentation sets for all Cisco products can be found here. The Multi-Layer LAN Switches link leads you to documentation for all Cisco LAN switches. In order to learn about the features of a switch, read the Software Configuration Guide for the particular release of software that you use. The software configuration guides give you background information about what the feature does and what commands to use to configure it on your switch. All this information is free on the web. You do not even need an account for this documentation; it is available to anyone. Some of these configuration guides can be read in an afternoon and are well worth the time spent.

Another part of the Cisco web site is populated by the Cisco Technical Support website. It is filled with information designed to help you implement, maintain, and troubleshoot your network. Go to the Technical Support Website at http://www.cisco.com/en/US/support/index.html; from here, you can choose Products Home Page to get detailed support information organized by specific products, or you can go to Technologies Home Page to get support information base on technology (Fast Ethernet, Spanning-Tree, Trunking, etc.). Most of the material on the Technical Support Website is accessible only to users with a Cisco support contract.

General Switch Troubleshooting Suggestions

There are many ways to troubleshoot a switch. As the features of switches grow, the possible things that can break also increase. If you develop an approach or test plan for troubleshooting, you are better off in the long run than if you just try a hit-and-miss approach. Here are some general suggestions to make your troubleshooting more effective:

Take the time to become familiar with normal switch operation. The Cisco web site has a tremendous amount of technical information that describes how their switches work, as mentioned in the previous section. The configuration guides in particular are very helpful. Many cases are opened that are solved with information from the product configuration guides.
For the more complex situations, have an accurate physical and logical map of your network. A physical map shows how the devices and cables are connected. A logical map shows what segments (VLANs) exist in your network and which routers provide routing services to these segments. A spanning tree map is highly useful to troubleshoot complex issues. Because of the ability of a switch to create different segments with the implementation of VLANs, the physical connections alone do not tell the whole story; one has to know how the switches are configured to determine which segments (VLANs) exist and to know how they are logically connected.
Have a plan. Some problems and solutions are obvious; some are not. The symptoms that you see in your network can be the result of problems in another area or layer. Before you jump to conclusions, try to verify in a structured way what works and what does not. Since networks can be complex, it is helpful to isolate possible problem domains. One way to do this is to use the OSI seven-layer model. For example: check the physical connections involved (layer 1); check connectivity issues within the VLAN (layer 2), and check connectivity issues across different VLANs (layer 3), etc. If there is a correct configuration on the switch, many of the problems you encounter are related to physical layer issues (physical ports and cabling). Today, switches are involved in layer-three and four issues, which incorporate intelligence to switch packets based on information derived from routers, or actually have routers that live inside the switch (layer-three or layer-four switching).
Do not assume a component works without checking it first. This can save you a lot of wasted time. For example, if a PC is not able to log in to a server across your network, there are many things that can be wrong. Do not skip the basic things and assume that something works; someone can have changed something and not told you. It only takes a minute to check some of the basic things (for example, that the ports involved are connected to the right place and are active), which could save you many wasted hours.

Troubleshooting Port Connectivity Problems

If the port does not work, nothing works! Ports are the foundation of your switching network. Some ports have special significance because of their location in the network and the amount of traffic they carry. These ports include connections to other switches, routers, and servers. These ports can be more complicated to troubleshoot because they often take advantage of special features like trunking and EtherChannel. The rest of the ports are significant, as well, because they connect the actual users of the network.

Many things can cause a port to be non-functional: hardware issues, configuration issues, and traffic issues. These categories are explored a little deeper.

Hardware Issues

General

Port functionality requires two working ports connected by a working cable (of the correct type). The default of most Cisco switches is to have a port in notconnectstate, which means that it is currently not connected to anything but it wants to connect. If you connect a good cable to two switch ports in the notconnect state, the link light becomes green for both ports, and the port status says connected, which means the port is up as far as layer one is concerned. These paragraphs point out items for which to check if layer one is not up.

Check the port status for both ports involved. Make sure that neither port involved in the link is shutdown. The administrator possibly can have shut down one or both ports. Software inside the switch can have shut the port down because of configuration error conditions (we will expand on this later). If one side is shutdown and the other is not, the status on the enabled side is notconnect (because it does not sense a neighbor on the other side of the wire). The status on the shutdown side says something like disable or errDisable (dependent upon what actually shut the port down). The link does not come up unless both ports are enabled.

When you hook up a good cable (again, if it is of the correct type) between two enabled ports they show a green link light within a few seconds. Also, the port state shows connected in the command line interface (CLI). At this point, if you do not have link, your problem is limited to three things: the port on one side, the port on the other side, or the cable in the middle. In some cases, there are other devices involved: media converters (fiber to copper, etc.), or on Gigabit links you can have gigabit interface connectors (GBICs). Still, this is a reasonably limited area to search.

Media converters can add noise to a connection or weaken the signal if they do not function correctly. They also add extra connectors that can cause problems and are another component to debug.

Check for loose connections. Sometimes a cable appears to be seated in the jack, but it actually is not; unplug the cable and re-insert it. You must also look for dirt or broken or missing pins. Do this for both ports involved in the connection.

The cable can be plugged in to the wrong port, which commonly happens. Make sure both ends of the cable are plugged in to the ports where you really want them.

You can have link on one side and not on the other. Check both sides for link. A single broken wire can cause this type of problem.

A link light does not guarantee that the cable is fully functional. It can have encountered physical stress that causes it to be functional at a marginal level. Usually you notice this by the port that has lots of packet errors.

In order to determine if the cable is the problem, swap it with a known good cable. Do not just swap it with any other cable; make sure that you swap it with a cable that you know is good and is of the correct type.

If this is a very long cable run (underground, across a large campus, for example), it is nice to have a sophisticated cable tester. If you do not have a cable tester, you can consider these:

Try different ports to see if they come up with this long cable.
Connect the port in question to another port in the same switch just to see if the port links up locally.
Temporarily relocate the switches near each other, so you can try out a known good cable.

Copper

Make sure that you have the correct cable for the type of connection that you make. Category 3 cable can be used for 10MB UTP connections, but category 5 must be used for 10/100 connections.

A straight-through RJ-45 cable is used for end-stations, routers, or servers to connect to a switch or hub. An Ethernet crossover cable is used for switch to switch or hub to switch connections. This is the pin-out for an Ethernet crossover cable. Maximum distances for Ethernet or Fast Ethernet copper wires are 100 meters. A good general rule of thumb is that when you cross an OSI layer, as between a switch and a router, use a straight-through cable; when you connect two devices in the same OSI layer, as between two routers or two switches, use a cross over cable. For purposes of this rule only, treat a workstation like a router.

These two graphics show the pin-outs required for a switch-to-switch crossover cable.

Fiber

For fiber, make sure that you have the correct cable for the distances involved and the type of fiber ports that is used (single mode, multi mode). Make sure the ports that are connected together are both single mode or both multimode ports. Single mode fiber generally reaches 10 kilometers, and multimode fiber can usually reach 2 kilometers, but there is the special case of 100BaseFX multimode used in half duplex mode, which can only go 400 meters.

For fiber connections, make sure the transmit lead of one port is connected to the receive lead of the other port, and vice versa; transmit to transmit, receive to receive, does not work.

For gigabit connections, GBICs need to be matched on each side of the connection. There are different types of GBICs dependent upon the cable and distances involved: Short wavelength (SX), long wavelength/long haul (LX/LH), and extended distance (ZX).

An SX GBIC needs to connect with an SX GBIC; an SX GBIC does not link with an LX GBIC. Also, some gigabit connections require conditioning cables dependent upon the lengths involved. Refer to the GBIC installation notes.

If your gigabit link does not come up, check to make sure the flow control and port negotiation settings are consistent on both sides of the link. There can be incompatibilities in the implementation of these features if the switches that are connected are from different vendors. If in doubt, turn these features off on both switches.

Configuration Issues

Another cause of port connectivity issues is incorrect software configuration of the switch. If a port has a solid orange light, that means that software inside the switch shut down the port, either by way of the user interface or by internal processes.

Make sure that the administrator has not shut down the ports involved (as mentioned). The administrator can have manually shut down the port on one side of the link or the other. This link does not come up until you re-enable the port; check the port status.

Some switches, such as the Catalyst 4000/5000/6000, can shut down the port if software processes inside the switch detect an error. When you look at the port status, it reads errDisable. You must fix the configuration problem and then manually take the port out of errDisable state. Some newer software versions (CatOS 5.4(1) and later) have the ability to automatically re-enable a port after a configurable amount of time spent in the errDisable state. These are some of the causes for this errDisable state:

EtherChannel Misconfiguration: If one side is configured for EtherChannel and the other is not, it can cause the spanning tree process to shut down the port on the side configured for EtherChannel. If you try to configure EtherChannel but the ports involved do not have the same settings (speed, duplex, trunking mode, etc.) as their neighbor ports across the link, it could cause the errDisable state. It is best to set each side for the EtherChannel desirable mode if you want to use EtherChannel. Sections later on talk in depth about how to configure the EtherChannel.
Duplex Mismatch: If the switch port receives a lot of late collisions, this usually indicates a duplex mismatch problem. There are other causes for late collisions: a bad NIC, cable segments that are too long, but the most common reason today is a duplex mismatch. The full duplex side thinks it can send whenever it wants to. The half duplex side only expects packets at certain times - not at "any" time.
BPDU Port-guard: Some newer versions of switch software can monitor if portfast is enabled on a port. A port that uses portfast must be connected to an end-station, not to devices that generate spanning tree packets called BPDUs. If the switch notices a BPDU that comes in a port that has portfast enabled, it puts the port in errDisable mode.
UDLD: Unidirectional Link Detection is a protocol on some new versions of software that discovers if communication over a link is one-way only. A broken fiber cable or other cabling/port issues can cause this one-way only communication. These partially functional links can cause problems when the switches involved do not know that link is partially broken. Spanning tree loops can occur with this problem. UDLD can be configured to put a port in errDisable state when it detects a unidirectional link.
Native VLAN mismatch: Before a port has trunking turned on, it belongs to a single VLAN. When trunking is turned on, the port can carry traffic for many VLANs. The port still remembers the VLAN it was in before trunking was turned on, which is called the native VLAN. The native VLAN is central to 802.1q trunking. If the native VLAN on each end of the link does not match, a port goes into the errDisable state.
Other: Any process within the switch that recognizes a problem with the port can place it in the errDisable state.

Another cause of inactive ports is when the VLAN they belong to disappears. Each port in a switch belongs to a VLAN. If that VLAN is deleted, the port becomes inactive. Some switches show a steady orange light on each port where this has happened. If you come in to work one day and see hundreds of orange lights, do not panic; it could be that all the ports belonged to the same VLAN and someone accidentally deleted the VLAN that the ports belonged to. When you add the VLAN back into the VLAN table, the ports become active again. A port remembers its assigned VLAN.

If you have link and the ports show connected, but you cannot communicate with another device, this can be particularly perplexing. It usually indicates a problem above the physical layer: layer 2 or layer 3. Try these things.

Check the trunking mode on each side of the link. Make sure both sides are in the same mode. If you turn the trunking mode to "on" (as opposed to "auto" or "desirable") for one port, and the other port has the trunking mode set to "off", they are not able to communicate. Trunking changes the formatting of the packet; the ports need to be in agreement as to what format they use on the link or they do not understand each other.
Make sure all devices are in the same VLAN. If they are not in the same VLAN, a router must be configured to allow the devices to communicate.
Make sure your layer three addressing is correctly configured.

Traffic Issues

In this section, we describe some of the things you can learn when you look at that traffic information of a port. Most switches have some way to track the packets going in and out of a port. Commands that generate this type of output on the Catalyst 4000/5000/6000 switches are show port and show mac. Output from these commands on the 4000/5000/6000 switches is described in the switch command references.

Some of these port traffic fields show how much data is transmitted and received on the port. Other fields show how many error frames are encountered on the port. If you have a large amount of alignment errors, FCS errors, or late collisions, this can indicate a duplex mismatch on the wire. Other causes for these types of errors can be bad network interface cards or cable problems. If you have a large number of deferred frames, it is a sign that your segment has too much traffic; the switch is not able to send enough traffic on the wire to empty its buffers. Consider the removal of some devices to another segment.

Switch Hardware Failure

If you have tried everything you can think of and the port does not work, there might be faulty hardware.

Sometimes ports are damaged by Electro-Static Discharge (ESD). You can or cannot see any indication of this.

Look at the power-on self-test (POST) results from the switch to see if there were any failures indicated for any part of the switch.

If you see behavior that can only be considered "strange," this could indicate hardware problems, but it could also indicate software problems. It is usually easier to reload the software than it is to get new hardware. Try to work with the switch software first.

The operating system can have a bug. If you load a newer operating system, it could fix this. You can research known bugs if you read the release notes for the version of code you use or use Cisco's Bug Navigator tool (http://www.cisco.com/support/bugtools/).

The operating system could have somehow become corrupted. If you reload the same version of the operating system, you could fix the problem.

If the status light on the switch flashes orange, this usually means there is some kind of hardware problem with the port or the module or the switch. The same thing is true if the port or module status indicates faulty.

Before you exchange the switch hardware, you can try a few things:

Reseat the module in the switch. If you do this with the power on, make sure the module is hot swappable. If in doubt, turn the switch off before you reseat the module or refer to the hardware installation guide. If the port is built in to the switch, ignore this step.
Reboot the switch. Sometimes this causes the problem to disappear; this is a workaround, not a fix.
Check the switch software. If this is a new installation, remember that some components can only work with certain releases of software. Check the release notes or the hardware installation and configuration guide for the component you install.
If you are reasonably certain that you have a hardware problem, replace the faulty component.

Troubleshooting Ethernet 10/100Mb Half/Full Duplex Auto-Negotiation

Objectives

This section presents general troubleshooting information and a discussion of techniques to troubleshoot Ethernet auto-negotiation.

This section shows how to determine the current behavior of a link. It goes on to show how users can control the behavior, as well as explain situations when auto-negotiation fails.
Many different Cisco Catalyst Switches and Cisco Routers support auto-negotiation. This section focuses on auto-negotiation between Catalyst 5000 Switches. The concepts explained here can also be applied to the other types of devices.

Introduction

Auto-negotiation is an optional function of the IEEE 802.3u Fast Ethernet standard that enables devices to automatically exchange information over a link about speed and duplex abilities.

Auto-negotiation is targeted at ports, which are allocated to areas where transient users or devices connect to a network. For example, many companies provide shared offices or cubes for Account Managers and System Engineers to use when they are in the office rather than on the road. Each office or cube has an Ethernet port permanently connected to the network of the office. Because it is not possible to ensure that every user has either a 10Mb, a 100Mb Ethernet, or a 10/100Mb card in their laptop, the switch ports that handle these connections must be able to negotiate their speed and duplex mode. The alternative is able to provide both a 10Mb and a 100Mb port in each office or cube and label them accordingly.

Auto-negotiation must not be used for ports that support network infrastructure devices, such as switches and routers or other non-transient end systems such as servers and printers. Although auto-negotiation for speed and duplex is normally the default behavior on switch ports that are capable of it, ports connected to fixed devices must always be configured for the correct behavior rather than allowed to negotiate it. This eliminates any potential negotiation issues and ensures that you always know exactly how the ports should operate. For example, a 10/100BaseTX Ethernet switch-to-switch link that has been configured for 100Mb Full Duplex only operates at that speed and mode. There is no possibility for the ports to downgrade the link to a slower speed within a port reset or a switch reset. In the event that the ports cannot operate as configured, they must not pass any traffic. On the other hand, a switch-to-switch link that has been allowed to negotiate its behavior can operate at 10Mb Half Duplex. A non-functional link is usually easier to discover than a link, which is operational, but does not operate at the expected speed or mode.

One of the most common causes of performance issues on 10/100Mb Ethernet links is when one port on the link operates at half duplex, while the other port operates at full duplex. This occasionally happens when one or both ports on a link are reset and the auto-negotiation process does not result in both link partners that have the same configuration. It also happens when users reconfigure one side of a link and forget to reconfigure the other side. Many performance-related support calls are avoided if you create a policy that requires ports for all non-transient devices to be configured for their required behavior and enforce the policy with adequate change control measures.

Troubleshooting Ethernet Auto Negotiation Between Network Infrastructure Devices

Procedures and/or Scenarios

Scenario 1. Cat 5K with Fast Ethernet

Table 22-2: Auto-Negotiation Connectivity Issues

Possible Problem	Solution
Was the current behavior of the link auto negotiated?	1. Use the show port mod_num/port_num command to determine the current behavior of the link. If both link partners (interfaces at either end of the link) indicate have an "a-" prefix on their Duplex and Speed status fields, auto-negotiation was probably successful.
Auto negotiation not supported.	2. Issue the show port capabilities mod_num/port_num command to verify that your modules support auto negotiation.
Auto negotiation do not work on Catalyst switches.	3. Use the set port speed mod_num/port_num auto command on a Catalyst to configure auto negotiation. 4. Try different ports or modules. 5. Try resetting the ports. 6. Try different patch cables. 7. Turn the devices off and back on again.
Auto negotiation do not work on Cisco routers.	8. Issue the correct IOS command to enable auto negotiation (if available) 9. Try different interfaces. 10. Try resetting the interfaces. 11. Try different patch cables. 12. Turn the devices off and back on again.

Example of Configuring and Troubleshooting Ethernet 10/100Mb Auto-Negotiation

This section of the document walks you through examining the behavior of an 10/100Mb Ethernet port that supports auto-negotiation. It also shows how to make changes to its default behavior and how to restore it to the default behavior.

Tasks that are Performed

Examine the capabilities of the ports.
Configure auto negotiation for port 1/1 on both switches.
Determine if the speed and duplex mode are set to auto-negotiate.
Change the speed on port 1/1 in Switch A to 10Mb.
Understand the meaning of the "a-" prefix on the duplex and speed status fields.
View the duplex status of port 1/1 on Switch B.
Understand the Duplex mismatch error.
Understand the Spanning Tree error messages.
Change the duplex mode to half on port 1/1 on Switch A.
Set the duplex mode and speed of port 1/1 on Switch B.
Restore the default duplex mode and speed to ports 1/1 on both switches.
View the changes of the port status on both switches.

Step-by-Step

Perform these steps:

The show port capabilities 1/1 command displays the capabilities of a Ethernet 10/100BaseTX 1/1 port on Switch A.

Enter this command for both of the ports you troubleshoot. Both ports must support the speed and duplex capabilities shown if they are supposed to use auto negotiation.
```
Switch-A> (enable) show port capabilities 1/1
Model WS-X5530
Port 1/1
Type 10/100BaseTX
Speed auto,10,100
Duplex half,full
```
Auto negotiation is configured for both speed and duplex mode on port 1/1 of both switches if you enter the set port speed 1/1 auto command (auto is the default for ports that support auto-negotiation).
```
Switch-A> (enable) set port speed 1/1 auto
Port(s) 1/1 speed set to auto detect.
Switch-A (enable)
```
Note: The set port speed {mod_num/port_num} auto command also sets the duplex mode to auto. There is no set port duplex {mod_num/port_num} auto command.
The show port 1/1 command displays the status of ports 1/1 on Switches A and B.
```
Switch-A> (enable) show port 1/1
Port  Name         Status     Vlan       Level  Duplex Speed Type
----- ------------------ ---------- ---------- ------ ------ ----- -----
 1/1               connected  1          normal a-full a-100 10/100BaseTX

Switch-B> (enable) show port 1/1  
Port  Name         Status     Vlan       Level  Duplex Speed Type
----- ------------------ ---------- ---------- ------ ------ ----- -----
 1/1               connected  1          normal a-full a-100 10/100BaseTX 
```
Note that most of the normal output from the show port {mod_num/port_num} command has been omitted.

The "a-" prefixes on the "full" and "100" indicate that this port has not been hard coded (configured) for a specific duplex mode or speed. Therefore it can auto-negotiate its duplex mode and speed if the device it is connected to (its Link Partner) also can auto-negotiate its duplex mode and speed. Also note that the status is "connected" on both ports, which means that a link pulse has been detected from the other port. The status can be "connected" even if duplex has been incorrectly negotiated or misconfigured.
In order to demonstrate what happens when one link partner is auto-negotiating and the other Link Partner is not, the speed on port 1/1 in Switch A is set to 10Mb with the set port speed 1/1 10 command.
```
Switch-A> (enable) set port speed 1/1 10
Port(s) 1/1 speed set to 10Mbps.
Switch-A> (enable)
```
Note: If you hard code the speed on a port, it disables all auto-negotiation functionality on the port for speed and duplex.

When a port has been configured for a speed, its duplex mode is automatically configured for the mode it had previously negotiated; in this case, full duplex. When you enter the set port speed 1/1 10 command caused the duplex mode on port 1/1 to be configured as if the command set port duplex 1/1 full had also been entered. This is explained next.
Understand the meaning of the "a-" prefix in the Duplex and Speed status fields.

The absence of the "a-" prefix in the status fields of the output from the show port 1/1 command on Switch A shows that the duplex mode is now configured for "full," and the speed is now configured for "10."
```
Switch-A> (enable) show port 1/1
Port  Name         Status     Vlan       Level  Duplex Speed Type
----- ------------ ---------- ---------- ------ ------ ----- ------------
 1/1               connected  1          normal  full  10    10/100BaseTX
```
The show port 1/1 command on Switch B indicates that the port now operates at half duplex and 10Mb.
```
Switch-B> (enable) show port 1/1
Port  Name         Status     Vlan       Level  Duplex Speed Type
----- ------------ ---------- ---------- ------ ------ ----- ------------
 1/1               connected  1          normal a-half a-10  10/100BaseTX
```
This step shows that it is possible for a Link Partner to detect the speed at which the other Link Partner operates, even though the other Link Partner is not configured for auto-negotiation. Sensing the type of electrical signal that is arriving to see if it is 10Mb or 100Mb does this. This is how Switch B determined that port 1/1 should operate at 10Mb.

It is not possible to detect the correct duplex mode in the same way that the correct speed can be detected. In this case, where the 1/1 port of Switch B is configured for auto-negotiation and the port of Switch A is not, the 1/1 port of Switch B was forced to select the default duplex mode. On Catalyst Ethernet ports, the default mode is auto-negotiate, and if auto-negotiation fails, then half duplex.

This example also shows that a link can be successfully connected when there is a mismatch in the duplex modes. Port 1/1 on Switch A is configured for full duplex while port 1/1 on Switch B has defaulted to half duplex. In order to avoid this, always configure both Link Partners.

The "a-" prefix on the Duplex and Speed status fields does not always mean the current behavior was negotiated. Sometimes it only means that the port has not been configured for a speed or duplex mode. The previous output from Switch B shows Duplex as "a-half" and Speed as "a-10" which indicates that the port is operating at 10Mb in half duplex mode. In this example, the link partner on this port (port 1/1 on Switch A) is configured for "full" and "10Mb." It was not possible for port 1/1 on Switch B to have auto-negotiated its current behavior. This proves that the "a-" prefix only indicates a willingness to perform auto-negotiation - not that auto-negotiation actually took place.
Understand the Duplex Mismatch error message.

This message about a duplex mode mismatch is displayed on Switch A after the speed on port 1/1 was changed to 10Mb. The mismatch was caused by the 1/1 port of Switch B, which default to half duplex because it sensed its Link Partner could no longer perform auto-negotiation.
```
%CDP-4-DUPLEXMISMATCH:Full/half duplex mismatch detected o1
```
It is important to note that this message is created the Cisco Discovery Protocol (CDP), not the 802.3 auto-negotiation protocol. CDP can report problems it discovers, but it typically does not automatically fix them. A duplex mismatch can or cannot result in an error message. Another indication of a duplex mismatch are rapidly increasing FCS and alignment errors on the half duplex side and "runts" on the full duplex port (as seen in a sh port {mod_num/port_num}).
Understand the Spanning Tree messages.

In addition to the duplex mismatch error message, you can also see these Spanning Tree messages when you change the speed on a link. A discussion of Spanning Tree is beyond the scope of this document; refer the chapter on Spanning Tree for more information on Spanning Tree.
```
%PAGP-5-PORTFROMSTP:Port 1/1 left bridge port 1/1
%PAGP-5-PORTTOSTP:Port 1/1 joined bridge port 1/1
```
In order to demonstrate what happens when the duplex mode has been configured, the mode on port 1/1 in Switch A is set to half with the set port duplex 1/1 half command.
```
Switch-A> (enable) set port duplex 1/1 half
Port(s) 1/1 set to half-duplex.
Switch-A> (enable)
```
The show port 1/1 command shows the change in the Duplex mode on this port.
```
Switch-A> (enable) sh port 1/1
Port  Name         Status     Vlan       Level  Duplex Speed Type
----- ------------ ---------- ---------- ------ ------ ----- ------------
 1/1               connected  1          normal half   10    10/100BaseTX
```
At this point, ports 1/1 on both switches are operating at half duplex. Port 1/1 on Switch B is still configured to auto negotiate, as shown in this output of the show port 1/1 command.
```
Switch-B> (enable) show port 1/1
Port  Name         Status     Vlan       Level  Duplex Speed Type
----- ------------ ---------- ---------- ------ ------ ----- ------------
 1/1               connected  1          normal a-half a-10  10/100BaseTX
```
This step shows how to configure the duplex mode on port 1/1 in Switch B to half. This is consistent with the recommended policy to configure both link partners in the same way.
In order to implement the policy to ways configure both link partners for the same behavior, this step now sets the duplex mode to half and speed to 10 on port 1/1 in Switch B.

Here is the output of entering the set port duplex 1/1 half command on Switch B:
```
Switch-B> (enable) set port duplex 1/1 half
Port 1/1 is in auto-sensing mode.
Switch-B> (enable) 
```
The set port duplex 1/1 half command failed because this command is not valid if auto-negotiation is enabled. This also means that this command does not disable auto-negotiation. Auto-negotiation can only be disabled with the set port speed {mod_num/port_num {10 | 100}} command.

Here is the output of entering the set port speed 1/1 10 command on Switch B:
```
Switch-B> (enable) set port speed 1/1 10
Port(s) 1/1 speed set to 10Mbps.
Switch-B> (enable)
```
Now the set port duplex 1/1 half command on Switch B works:
```
Switch-A> (enable) set port duplex 1/1 half
Port(s) 1/1 set to half-duplex.
Switch-A> (enable)
```
The show port 1/1 command on Switch B shows that the ports is now configured for half duplex and 10Mb.
```
Switch-B> (enable) show port 1/1
Port  Name         Status     Vlan       Level  Duplex Speed Type
----- ------------ ---------- ---------- ------ ------ ----- ------------
 1/1               connected  1          normal half   10    10/100BaseTX
```
Note: The set port duplex {mod_num/port_num {half | full }} command is dependent on the set port speed {mod_num/port_num {10 | 100 }} command. In other words, you must set the speed before you can set the duplex mode.
Configure ports 1/1 on both switches to auto negotiate with the set port speed 1/1 auto command.
```
Switch-A> (enable) set port speed 1/1 auto
Port(s) 1/1 speed set to auto detect.
Switch-A> (enable)
```
Note: Once a duplex mode of a port has been configured to something other than auto, the only way to configure the port to auto sense its duplex mode is to issue the set port speed {mod_num/port_num} auto command. There is no set port duplex {mod_num/port_num} auto command. In other words, if you issue the set port speed {mod_num/port_num} auto command, it resets both port speed sensing and duplex mode sensing to auto.

Examine the status of ports 1/1 on both switches with the show port 1/1 command.

Switch-A> (enable) show port 1/1
Port  Name         Status     Vlan       Level  Duplex Speed Type
----- ------------ ---------- ---------- ------ ------ ----- ------------ 
 1/1               connected  1          normal a-full a-100 10/100BaseTX
Switch-B> (enable) show port 1/1
Port  Name         Status     Vlan       Level  Duplex Speed Type
----- ------------ ---------- ---------- ------ ------ ----- ------------
 1/1               connected  1          normal a-full a-100 10/100BaseTX

Both ports are now set to their default behavior of auto negotiation. Both ports have negotiated full duplex and 100Mb.

Before You Call the Cisco Systems Technical Support Team

Before you call the Cisco Systems Technical Support Website, make sure you have read through this chapter and completed the actions suggested for your system's problem. Additionally, do these and document the results so that we can better assist you:

Capture the output of show version from all of the affected devices.
Capture the output of show port mod_num/port_num from all of the affected ports.
Capture the output of show port mod_num/port_num capabilities from all of the affected ports.

Configuring EtherChannel Switch-to-Switch Connections on Catalyst 4000/5000/6000 Switches

EtherChannel allows multiple physical Fast Ethernet or Gigabit Ethernet links to be combined into one logical channel. This allows traffic among the links to be loadshared in the channel, as well as redundancy in the event that one or more links in the channel fail. EtherChannel can be used to interconnect LAN switches, routers, servers, and clients through unshielded twisted-pair (UTP) wiring or single mode and multimode fiber.

EtherChannel is an easy way to aggregate bandwidth between critical networking devices. On the Catalyst 5000, a channel can be created from two ports that make it a 200Mbps link (400Mbps full-duplex) or four ports that make it a 400Mbps link (800Mbps full-duplex). Some cards and platforms also support Gigabit EtherChannel and have the ability to use from two to eight ports in an EtherChannel. The concept is the same no matter what speeds or number of links are involved. Normally the spanning tree protocol (STP) considers these redundant links between two devices to be loops and causes the redundant links to be in blocking mode, which effectively makes these links inactive (that provide only backup capabilities if the main link fails). When you use IOS 3.1.1 or greater, spanning tree treats the channel as one big link, so all the ports in the channel can be active at the same time.

This section takes you through the steps to configure EtherChannel between two Catalyst 5000 switches and show you the results of the commands as they are executed. Catalyst 4000 and 6000 switches could have been used in the scenarios presented in this document to obtain the same results. For the Catalyst 2900XL and 1900/2820, the command syntax is different, but the EtherChannel concepts are the same.

EtherChannel can be configured manually if you type in the appropriate commands, or it can be configured automatically if the switch negotiates the channel with the other side with the Port Aggregation Protocol (PAgP). It is recommended to use PAgP desirable mode to configure EtherChannel whenever possible since manual configuration of EtherChannel can create some complications. This document gives examples of how to configure EtherChannel manually and examples of how to configure EtherChannel with PAgP. Also included is how to troubleshoot EtherChannel and how to use trunking with EtherChannel. In this document, the terms EtherChannel, Fast EtherChannel, Gigabit EtherChannel or channel all refer to EtherChannel.

Contents

Tasks for Manual Configuration of EtherChannel
Verify the EtherChannel Configuration
Use PAgP to Automatically Configure EtherChannel (preferred method)
Trunking and EtherChannel
Troubleshooting EtherChannel
Commands Used in this Document

This figure illustrates our test environment. The configuration of the switches has been cleared with the clear config all command. Then, the prompt was changed with set system name. An IP address and mask were assigned to the switch for management purposes with set int sc0 172.16.84.6 255.255.255.0 for SwitchA and set int sc0 172.16.84.17 255.255.255.0 for SwitchB. A default gateway was assigned to both switches with set ip route default 172.16.84.1.

The switch configurations were cleared so that we could start from the default conditions. The switches were given names so that we could identify them from the prompt on the command line. The IP addresses were assigned so that we could ping between the switches for testing. The default gateway was not used.

Many of the commands display more output than is needed for our discussion. Extraneous output is deleted in this document.

Tasks for Manual Configuration of EtherChannel

This is a synopsis of directions to manually configure the EtherChannel.

Show the IOS version and modules we use in this document.
Verify that EtherChannel is supported on the ports.
Verify that the ports are connected and operational.
Verify that the ports to be grouped have the same settings.
Identify Valid Port Groups.
Create the channel.

Step-by-Step

These are the steps to manually configure the EtherChannel.

The show version command displays the software version the switch runs. The show module command lists which modules are installed in the switch.

Switch-A show version
WS-C5505 Software, Version McpSW: 4.5(1) NmpSW: 4.5(1)
Copyright (c) 1995-1999 by Cisco Systems
?

Switch-A show module
Mod Module-Name         Ports Module-Type           Model    Serial-Num Status
--- ------------------- ----- --------------------- --------- --------- -------
1                       0     Supervisor III        WS-X5530  006841805 ok
2                       24    10/100BaseTX Ethernet WS-X5225R 012785227 ok
?

Verify that EtherChannel is supported on the ports, show port capabilities appears in versions 4.x and greater. If you have an earlier IOS than 4.x, you must skip this step. Not every Fast Ethernet module supports EtherChannel. Some of the original EtherChannel modules have "Fast EtherChannel" written on the bottom left corner of the module (as you face it in the switch) which tells you that the feature is supported. This convention was abandoned on later modules. The modules in this test do not say "Fast EtherChannel" on them, but they do support the feature.

Switch-A show port capabilities
Model                    WS-X5225R
Port                     2/1
Type                     10/100BaseTX
Speed                    auto,10,100
Duplex                   half,full
Trunk encap type         802.1Q,ISL
Trunk mode               on,off,desirable,auto,nonegotiate
Channel                  2/1-2,2/1-4
Broadcast suppression    percentage(0-100)
Flow control             receive-(off,on),send-(off,on)
Security                 yes
Membership               static,dynamic
Fast start               yes
Rewrite                  yes
Switch-B show port capabilities
Model                    WS-X5234
Port                     2/1
Type                     10/100BaseTX
Speed                    auto,10,100
Duplex                   half,full
Trunk encap type         802.1Q,ISL
Trunk mode               on,off,desirable,auto,nonegotiate
Channel                  2/1-2,2/1-4
Broadcast suppression    percentage(0-100)
Flow control             receive-(off,on),send-(off,on)
Security                 yes
Membership               static,dynamic
Fast start               yes
Rewrite                  no

A port that does not support EtherChannel looks like this.

Switch show port capabilities
Model                    WS-X5213A
Port                     2/1
Type                     10/100BaseTX
Speed                    10,100,auto
Duplex                   half,full
Trunk encap type         ISL
Trunk mode               on,off,desirable,auto,nonegotiate
Channel                  no
Broadcast suppression    pps(0-150000)
Flow control             no
Security                 yes
Membership               static,dynamic
Fast start               yes

Verify that the ports are connected and operational. Before you connect the cables, this is the port status.

Switch-A show port
Port  Name               Status     Vlan       Level  Duplex Speed Type
----- ------------------ ---------- ---------- ------ ------ ----- ------------
 2/1                     notconnect 1          normal   auto  auto 10/100BaseTX
 2/2                     notconnect 1          normal   auto  auto 10/100BaseTX
 2/3                     notconnect 1          normal   auto  auto 10/100BaseTX
 2/4                     notconnect 1          normal   auto  auto 10/100BaseTX

After you connect the cables between the two switches, this is the status.

1999 Dec 14 20:32:44 %PAGP-5-PORTTOSTP:Port 2/1 joined bridge port 2/1
1999 Dec 14 20:32:44 %PAGP-5-PORTTOSTP:Port 2/2 joined bridge port 2/2
1999 Dec 14 20:32:44 %PAGP-5-PORTTOSTP:Port 2/3 joined bridge port 2/3
1999 Dec 14 20:32:44 %PAGP-5-PORTTOSTP:Port 2/4 joined bridge port 2/4

Switch-A show port
Port  Name               Status     Vlan       Level  Duplex Speed Type
----- ------------------ ---------- ---------- ------ ------ ----- ------------
 2/1                     connected  1          normal a-full a-100 10/100BaseTX
 2/2                     connected  1          normal a-full a-100 10/100BaseTX
 2/3                     connected  1          normal a-full a-100 10/100BaseTX
 2/4                     connected  1          normal a-full a-100 10/100BaseTX
Switch-B show port
Port  Name               Status     Vlan       Level  Duplex Speed Type
----- ------------------ ---------- ---------- ------ ------ ----- ------------
 2/1                     connected  1          normal a-full a-100 10/100BaseTX
 2/2                     connected  1          normal a-full a-100 10/100BaseTX
 2/3                     connected  1          normal a-full a-100 10/100BaseTX
 2/4                     connected  1          normal a-full a-100 10/100BaseTX

Since the switch configurations were cleared before this test started, the ports are in their default conditions. They are all in vlan1, and their speed and duplex are set to auto. After the connection of the cables, they negotiate to a speed of 100Mbps and full duplex. The status is connected, so we are able to ping the other switch.

Switch-A ping 172.16.84.17
172.16.84.17 is alive

In your network, you might want to to set the speeds manually to 100Mbps and full duplex instead of reliance on auto-negotiation since you probably want your ports to always run at the fastest speed. For a discussion of auto-negotiation, see the section Troubleshooting Ethernet 10/100Mb Half/Half/Full Duplex Auto-Negotiation.

Verify that the ports to be grouped have the same settings. This is an important point that is covered in more detail in the troubleshooting section. If the command to setup EtherChannel does not work, it is usually because the ports involved in the channel have configurations that differ from each other. This includes the ports on the other side of the link, as well as the local ports. In our case, since the switch configurations were cleared before this test started, the ports are in their default conditions. They are all in vlan1; their speed and duplex are set to auto, and all spanning tree parameters for each port are set the same. We saw from the output that after the cables are connected, the ports negotiate to a speed of 100Mbps and full duplex. Since spanning tree runs for each VLAN, it is easier to just configure the channel and respond to error messages than to try and check every spanning tree field for consistency for each port and VLAN in the channel.
Identify valid port groups. On the Catalyst 5000, only certain ports can be put together into a channel. These restrictive dependencies do not apply to all platforms. The ports in a channel on a Catalyst 5000 must be contiguous. Notice from the show port capabilities command that for port 2/1, these are the possible combinations:
```
Switch-A show port capabilities
Model                    WS-X5225R
Port                     2/1
Channel                  2/1-2,2/1-4
```
Notice that this port can be a part of a group of two (2/1-2) or part of a group of four (2/1-4). There is something called an Ethernet Bundling Controller (EBC) on the module that causes these configuration limitations. Let's look at another port.
```
Switch-A show port capabilities 2/3
Model                    WS-X5225R
Port                     2/3
Channel                  2/3-4,2/1-4
```
This port can be grouped into a group of two ports (2/3-4) or into a group of four (2/1-4).

Note: Dependent upon the hardware, there can be additional restrictions. On certain modules (WS-X5201 and WS-X5203), you cannot form an EtherChannel with the last two ports in a "port group" unless the first two ports in the group already form an EtherChannel. A "port group" is a group of ports that is allowed to form an EtherChannel (2/1-4 is a port group in this example). For example, if you create separate EtherChannels with only two ports in a channel, you cannot assign ports 2/3-4 to a channel until you have first configured ports 2/1-2 to a channel, for the modules that have this restriction! Likewise, before you configure ports 2/6-7, you must configure ports 2/5-6. This restriction does not occur on the modules used for this document (WS-X5225R, WS-X5234).

Since we configure a group of four ports (2/1-4), this is within the approved grouping. We cannot assign a group of four to ports 2/3-6. This is a group of contiguous ports, but they do not start on the approved boundary, as shown by the show port capabilities command (valid groups would be ports 1-4, 5-8, 9-12, 13-16, 17-20, 21-24).

Create the channel. In order to create the channel, use the command set port channel <mod/port on for each switch. We recommend that you turn the ports off on one side of the channel or the other side with the set port disable command before you turn EtherChannel on manually. This avoids possible problems with spanning tree within the configuration process. Spanning tree can shut down some ports (with a port status of "errdisable") if one side is configured as a channel before the other side can be configured as a channel. Because of this possibility, it is much easier to create EtherChannels with PAgP, which is explained later in this document. In order to avoid this situation when you configure EtherChannel manually, we disable the ports on SwitchA, configure the channel on SwitchA, configure the channel on SwitchB, and then re-enable the ports on SwitchA.

First, verify that channeling is off.

Switch-A (enable) show port channel
No ports channelling
Switch-B (enable) show port channel
No ports channelling

Now disable the ports on SwitchA until both switches have been configured for EtherChannel so that spanning tree does not generate errors and shut down the ports.

Switch-A (enable) set port disable 2/1-4
Ports 2/1-4 disabled.
[output from SwitchA upon disabling ports]
1999 Dec 15 00:06:40 %PAGP-5-PORTFROMSTP:Port 2/1 left bridg1
1999 Dec 15 00:06:40 %PAGP-5-PORTFROMSTP:Port 2/2 left bridge port 2/2
1999 Dec 15 00:06:40 %PAGP-5-PORTFROMSTP:Port 2/3 left bridge port 2/3
1999 Dec 15 00:06:40 %PAGP-5-PORTFROMSTP:Port 2/4 left bridge port 2/4

Turn the channel mode to on for SwitchA.

Switch-A (enable) set port channel 2/1-4 on
Port(s) 2/1-4 channel mode set to on.

Check the status of the channel. Notice that the channel mode has been set to on, but the status of the ports is disabled (because we disabled then earlier). The channel is not operational at this point, but it becomes operational when the ports are enabled.

Switch-A (enable) show port channel
Port  Status     Channel   Channel     Neighbor                  Neighbor
                 mode      status      device                    port
----- ---------- --------- ----------- ------------------------- ---------- 
 2/1  disabled   on        channel    
 2/2  disabled   on        channel    
 2/3  disabled   on        channel    
 2/4  disabled   on        channel    
----- ---------- --------- ----------- ------------------------- ----------

Because SwitchA ports were (temporarily) disabled, SwitchB ports no longer have a connection. This message is displayed on the console of SwitchB when the ports of SwitchA were disabled.

Switch-B (enable)
2000 Jan 13 22:30:03 %PAGP-5-PORTFROMSTP:Port 2/1 left bridge port 2/1
2000 Jan 13 22:30:04 %PAGP-5-PORTFROMSTP:Port 2/2 left bridge port 2/2
2000 Jan 13 22:30:04 %PAGP-5-PORTFROMSTP:Port 2/3 left bridge port 2/3
2000 Jan 13 22:30:04 %PAGP-5-PORTFROMSTP:Port 2/4 left bridge port 2/4

Turn on the channel for Switch B.

Switch-B (enable) set port channel 2/1-4 on
Port(s) 2/1-4 channel mode set to on.

Verify that channel mode is on for SwitchB.

Switch-B (enable) show port channel
Port  Status     Channel   Channel     Neighbor                  Neighbor
                 mode      status      device                    port
----- ---------- --------- ----------- ------------------------- ---------- 
 2/1  notconnect on        channel    
 2/2  notconnect on        channel    
 2/3  notconnect on        channel    
 2/4  notconnect on        channel    
----- ---------- --------- ----------- ------------------------- ----------

Notice that the channel mode for SwitchB is on, but the status of the ports is notconnect. That is because SwitchA ports are still disabled.

Finally, the last step is to enable the ports on SwitchA.

Switch-A (enable) set port enable 2/1-4
Ports 2/1-4 enabled.
1999 Dec 15 00:08:40 %PAGP-5-PORTTOSTP:Port 2/1 joined bridge port 2/1-4
1999 Dec 15 00:08:40 %PAGP-5-PORTTOSTP:Port 2/2 joined bridge port 2/1-4
1999 Dec 15 00:08:40 %PAGP-5-PORTTOSTP:Port 2/3 joined bridge port 2/1-4
1999 Dec 15 00:08:40 %PAGP-5-PORTTOSTP:Port 2/4 joined bridge port 2/1-4

Verify the Configuration

In order to verify that the channel is setup properly, do the show port channel command.

Switch-A (enable) show port channel
Port  Status     Channel   Channel     Neighbor                  Neighbor
                 mode      status      device                    port
----- ---------- --------- ----------- ------------------------- ---------- 
 2/1  connected  on        channel     WS-C5505    066509957(Sw  2/1       
 2/2  connected  on        channel     WS-C5505    066509957(Sw  2/2       
 2/3  connected  on        channel     WS-C5505    066509957(Sw  2/3       
 2/4  connected  on        channel     WS-C5505    066509957(Sw  2/4       
----- ---------- --------- ----------- ------------------------- ----------

Switch-B (enable) show port channel
Port  Status     Channel   Channel     Neighbor                  Neighbor
                 mode      status      device                    port
----- ---------- --------- ----------- ------------------------- ---------- 
 2/1  connected  on        channel     WS-C5505    066507453(Sw  2/1       
 2/2  connected  on        channel     WS-C5505    066507453(Sw  2/2       
 2/3  connected  on        channel     WS-C5505    066507453(Sw  2/3       
 2/4  connected  on        channel     WS-C5505    066507453(Sw  2/4       
----- ---------- --------- ----------- ------------------------- ----------

Spanning tree is shown to treat the ports as one logical port in this command. When the port is listed as 2/1-4, spanning tree is treating ports 2/1, 2/2, 2/3 and 2/4 as one port.

Switch-A (enable) show spantree
VLAN 1
Spanning tree enabled
Spanning tree type          ieee

Designated Root             00-10-0d-b2-8c-00
Designated Root Priority    32768
Designated Root Cost        8
Designated Root Port        2/1-4
Root Max Age   20 sec    Hello Time 2  sec   Forward Delay 15 sec

Bridge ID MAC ADDR          00-90-92-b0-84-00
Bridge ID Priority          32768
Bridge Max Age 20 sec    Hello Time 2  sec   Forward Delay 15 sec

Port      Vlan  Port-State     Cost   Priority  Fast-Start  Group-Method
--------- ----  -------------  -----  --------  ----------  ------------
 2/1-4    1     forwarding         8        32   disabled       channel

EtherChannel can be implemented with different ways of traffic distribution across the ports in a channel. The EtherChannel specification does not dictate how the traffic should be distributed across the links in a channel. The Catalyst 5000 uses the last bit or the last two bits (dependent upon how many links are in the channel) of the source and destination mac addresses in the frame to determine which port in the channel to use. You see similar amounts of traffic on each of the ports in the channel if that traffic is generated by a normal distribution of MAC addresses on one side of the channel or the other. In order to verify that traffic goes over all the ports in the channel, you can use the show mac command. If your ports were active before you configured EtherChannel, you can reset the traffic counters to zero by the clear counters command, and then the traffic values represent how EtherChannel has distributed the traffic.

In our test environment, we did not get a real-world distribution because there are no workstations, servers, or routers that generate traffic. The only devices that generate traffic are the switches themselves. We issued some pings from SwitchA to SwitchB, and you can tell that the unicast traffic uses the first port in the channel. The Receive information in this case (Rcv-Unicast) shows how SwitchB distributed the traffic across the channel to SwitchA. A little lower in the output, the Transmit information (Xmit-Unicast) shows how SwitchA distributed the traffic across the channel to SwitchB. We also see that a small amount of switch-generated multicast traffic (Dynamic ISL, CDP) go out all four ports. The broadcast packets are ARP queries (for the default gateway - which does not exist in our lab here). If we had workstations that send packets through the switch to a destination on the other side of the channel, we would expect to see traffic that goes over each of the four links in the channel. You can monitor the packet distribution in your own network with the show mac command.

Switch-A (enable) clear counters
This command will reset all MAC and port counters reported in CLI and SNMP.
Do you want to continue (y/n) [n]? y
MAC and Port counters cleared.
Switch-A (enable) show mac

Port     Rcv-Unicast          Rcv-Multicast        Rcv-Broadcast
-------- -------------------- -------------------- --------------------
 2/1                        9                  320                  183
 2/2                        0                   51                    0
 2/3                        0                   47                    0
 2/4                        0                   47                    0
(...)

Port     Xmit-Unicast         Xmit-Multicast       Xmit-Broadcast
-------- -------------------- -------------------- --------------------
 2/1                        8                   47                  184
 2/2                        0                   47                    0
 2/3                        0                   47                    0
 2/4                        0                   47                    0
(...)

Port     Rcv-Octet            Xmit-Octet
-------- -------------------- --------------------
 2/1                    35176                17443
 2/2                     5304                 4851
 2/3                     5048                 4851
 2/4                     5048                 4851
(...)

Last-Time-Cleared
--------------------------
Wed Dec 15 1999, 01:05:33

Use PAgP to Configure EtherChannel (Preferred Method)

The Port Aggregation Protocol (PAgP) facilitates the automatic creation of EtherChannel links with the exchange of packets between channel-capable ports. The protocol learns the capabilities of port groups dynamically and informs the nearby ports.

Once PAgP identifies correctly paired channel-capable links, it groups the ports into a channel. The channel is then added to the spanning tree as a single bridge port. A given outbound broadcast or multicast packet is transmitted out one port in the channel only, not out every port in the channel. In addition, outbound broadcast and multicast packets transmitted on one port in a channel are blocked from their return on any other port of the channel.

There are four user-configurable channel modes: on, off, auto, and desirable. PAgP packets are exchanged only between ports in auto and desirable mode. Ports configured in on or off mode do not exchange PAgP packets. The recommended settings for switches that you want to form and EtherChannel is to have both switches set to desirable mode. This gives the most robust behavior should one side or the other encounter error situations or be reset. The default mode of the channel is auto.

Both the auto and desirable modes allow ports to negotiate with connected ports to determine if they can form a channel based on criteria such as port speed, trunking state, native VLAN, and so on.

Ports can form an EtherChannel when they are in different channel modes as long as the modes are compatible:

A port in desirable mode can form an EtherChannel successfully with another port that is in desirable or auto mode.
A port in auto mode can form an EtherChannel with another port in desirable mode.
A port in auto mode cannot form an EtherChannel with another port that is also in auto mode since neither port initiates negotiation.
A port in on mode can form a channel only with a port in on mode because ports in on mode do not exchange PAgP packets.
A port in off mode does not form a channel with any port.

When you use EtherChannel, if a "SPANTREE-2: Channel misconfig - x/x-x will be disabled" or similar syslog message is displayed, it indicates a mismatch of EtherChannel modes on the connected ports. We recommend that you correct the configuration and re-enable the ports with the set port enable command. Valid EtherChannel configurations include these:

Table 22-5: Valid EtherChannel Configurations

Port Channel Mode	Valid Neighbor Port Channel Mode(s)
desirable	desirable or auto
auto (default)	desirable or auto¹
on	on
off	off

¹If both the local and neighbor ports are in auto mode, an EtherChannel bundle does not form.

Here is a summary of all the possible channeling mode scenarios. Some of these combinations can cause spanning tree to put the ports on the channeling side into errdisable state (that is, shut them down).

Table 22-6: Channeling Mode Scenarios

Switch-A Channel Mode	Switch-B Channel Mode	Channel State
On	On	Channel
On	Off	Not Channel (errdisable)
On	Auto	Not Channel (errdisable)
On	Desirable	Not Channel (errdisable)
Off	On	Not Channel (errdisable)
Off	Off	Not Channel
Off	Auto	Not Channel
Off	Desirable	Not Channel
Auto	On	Not Channel (errdisable)
Auto	Off	Not Channel
Auto	Auto	Not Channel
Auto	Desirable	Channel
Desirable	On	Not Channel (errdisable)
Desirable	Off	Not Channel
Desirable	Auto	Channel
Desirable	Desirable	Channel

We turned off the channel from the previous example with this command on SwitchA and SwitchB.

Switch-A (enable) set port channel 2/1-4 auto
Port(s) 2/1-4 channel mode set to auto.

The default channel mode for a port that is able to channel is auto. In order to verify this enter this command.

Switch-A (enable) show port channel 2/1
Port  Status     Channel   Channel     Neighbor                  Neighbor
                 mode      status      device                    port
----- ---------- --------- ----------- ------------------------- ---------- 
 2/1  connected  auto      not channel

The previous command also shows that currently the ports do not channel. Another way to verify the channel state is this.

Switch-A (enable) show port channel
No ports channelling
Switch-B (enable) show port channel
No ports channelling

Is really very simple to make the channel work with PAgP. At this point both switches are set to auto mode which means that they channel if a connected port sends a PAgP request to channel. If you setSwitchA to desirable, SwitchA, it causes SwitchA to send PAgP packets to the other switch and asks it to channel.

Switch-A (enable) set port channel 2/1-4 desirable
Port(s) 2/1-4 channel mode set to desirable.
1999 Dec 15 22:03:18 %PAGP-5-PORTFROMSTP:Port 2/1 left bridg1
1999 Dec 15 22:03:18 %PAGP-5-PORTFROMSTP:Port 2/2 left bridge port 2/2
1999 Dec 15 22:03:18 %PAGP-5-PORTFROMSTP:Port 2/3 left bridge port 2/3
1999 Dec 15 22:03:18 %PAGP-5-PORTFROMSTP:Port 2/4 left bridge port 2/4
1999 Dec 15 22:03:19 %PAGP-5-PORTFROMSTP:Port 2/2 left bridge port 2/2
1999 Dec 15 22:03:19 %PAGP-5-PORTFROMSTP:Port 2/3 left bridge port 2/3
1999 Dec 15 22:03:20 %PAGP-5-PORTFROMSTP:Port 2/4 left bridge port 2/4
1999 Dec 15 22:03:23 %PAGP-5-PORTTOSTP:Port 2/1 joined bridge port 2/1-4
1999 Dec 15 22:03:23 %PAGP-5-PORTTOSTP:Port 2/2 joined bridge port 2/1-4
1999 Dec 15 22:03:23 %PAGP-5-PORTTOSTP:Port 2/3 joined bridge port 2/1-4
1999 Dec 15 22:03:24 %PAGP-5-PORTTOSTP:Port 2/4 joined bridge port 2/1-4

In order to view the channel, do this.

Switch-A (enable) show port channel
Port  Status     Channel   Channel     Neighbor                  Neighbor
                 mode      status      device                    port
----- ---------- --------- ----------- ------------------------- ---------- 
 2/1  connected  desirable channel     WS-C5505    066509957(Sw  2/1       
 2/2  connected  desirable channel     WS-C5505    066509957(Sw  2/2       
 2/3  connected  desirable channel     WS-C5505    066509957(Sw  2/3       
 2/4  connected  desirable channel     WS-C5505    066509957(Sw  2/4       
----- ---------- --------- ----------- ------------------------- ----------

Since SwitchB was in auto mode, it responded to the PAgP packets and created a channel with SwitchA.

Switch-B (enable)
2000 Jan 14 20:26:41 %PAGP-5-PORTFROMSTP:Port 2/1 left bridg1
2000 Jan 14 20:26:41 %PAGP-5-PORTFROMSTP:Port 2/2 left bridge port 2/2
2000 Jan 14 20:26:41 %PAGP-5-PORTFROMSTP:Port 2/3 left bridge port 2/3
2000 Jan 14 20:26:41 %PAGP-5-PORTFROMSTP:Port 2/4 left bridge port 2/4
2000 Jan 14 20:26:45 %PAGP-5-PORTFROMSTP:Port 2/2 left bridge port 2/2
2000 Jan 14 20:26:45 %PAGP-5-PORTFROMSTP:Port 2/3 left bridge port 2/3
2000 Jan 14 20:26:45 %PAGP-5-PORTFROMSTP:Port 2/4 left bridge port 2/4
2000 Jan 14 20:26:47 %PAGP-5-PORTTOSTP:Port 2/1 joined bridge port 2/1-4
2000 Jan 14 20:26:47 %PAGP-5-PORTTOSTP:Port 2/2 joined bridge port 2/1-4
2000 Jan 14 20:26:47 %PAGP-5-PORTTOSTP:Port 2/3 joined bridge port 2/1-4
2000 Jan 14 20:26:48 %PAGP-5-PORTTOSTP:Port 2/4 joined bridge port 2/1-4

Switch-B (enable) show port channel
Port  Status     Channel   Channel     Neighbor                  Neighbor
                 mode      status      device                    port
----- ---------- --------- ----------- ------------------------- ---------- 
 2/1  connected  auto      channel     WS-C5505    066507453(Sw  2/1       
 2/2  connected  auto      channel     WS-C5505    066507453(Sw  2/2       
 2/3  connected  auto      channel     WS-C5505    066507453(Sw  2/3       
 2/4  connected  auto      channel     WS-C5505    066507453(Sw  2/4       
----- ---------- --------- ----------- ------------------------- ----------

Note: It is recommended to set both sides of the channel to desirable so that both sides try to initiate the channel if one side drops out. If you set the EtherChannel ports on SwitchB to desirable mode, even though the channel is currently active and in auto mode, it poses no problem. This is the command.

Switch-B (enable) set port channel 2/1-4 desirable
Port(s) 2/1-4 channel mode set to desirable.

Switch-B (enable) show port channel
Port  Status     Channel   Channel     Neighbor                  Neighbor
                 mode      status      device                    port
----- ---------- --------- ----------- ------------------------- ---------- 
 2/1  connected  desirable channel     WS-C5505    066507453(Sw  2/1       
 2/2  connected  desirable channel     WS-C5505    066507453(Sw  2/2       
 2/3  connected  desirable channel     WS-C5505    066507453(Sw  2/3       
 2/4  connected  desirable channel     WS-C5505    066507453(Sw  2/4       
----- ---------- --------- ----------- ------------------------- ----------

Now, if SwitchA drops out for some reason, or if new hardware replaces SwitchA, SwitchB tries to re-establish the channel. If the new equipment cannot channel, SwitchB treats its ports 2/1-4 as normal non-channelling ports. This is one of the benefits of the usage of the desirable mode. If the channel was configured with the PAgP on mode and one side of the connection has an error of some kind or a reset, it can cause an errdisable state (shutdown) on the other side. With PAgP set in desirable mode on each side, the channel stabilizes and renegotiates the EtherChannel connection.

Trunking and EtherChannel

EtherChannel is independent of trunking. You can turn trunking on or you can leave trunking off. You can also turn trunking on for all the ports before you create the channel, or you can turn it on after you create the channel (as we do here). As far as EtherChannel is concerned, it does not matter; trunking and EtherChannel are completely separate features. What does matter is that all the ports involved are in the same mode: either they are all trunking before you configure the channel or they are all not trunking before you configure the channel. All the ports must be in the same trunking state before you create the channel. Once a channel is formed, whatever is changed on one port is also changed for the other ports in the channel. The modules used in this test bed can do ISL or 802.1q trunking. By default, the modules are set to auto trunking and negotiate mode, which means that they trunk if the other side asks them to trunk, and they negotiate whether to use the ISL or 802.1q method for trunking. If not asked to trunk, they work as normal non-trunking ports.

Switch-A (enable) show trunk 2
Port      Mode         Encapsulation  Status        Native vlan
--------  -----------  -------------  ------------  -----------
 2/1      auto         negotiate      not-trunking  1
 2/2      auto         negotiate      not-trunking  1
 2/3      auto         negotiate      not-trunking  1
 2/4      auto         negotiate      not-trunking  1

There are a number of different ways to turn on trunking. For this example, we set SwitchA to desirable. SwitchA is already set to negotiate. The combination desirable/negotiate causes SwitchA to ask SwitchB to trunk and to negotiate the type of trunking to do (ISL or 802.1q). Since SwitchB defaults to autonegotiate, SwitchB responds to the request of SwitchA. These results occur:

Switch-A (enable) set trunk 2/1 desirable
Port(s) 2/1-4 trunk mode set to desirable.
Switch-A (enable)
1999 Dec 18 20:46:25 %DTP-5-TRUNKPORTON:Port 2/1 has become isl trunk
1999 Dec 18 20:46:25 %DTP-5-TRUNKPORTON:Port 2/2 has become isl trunk
1999 Dec 18 20:46:25 %PAGP-5-PORTFROMSTP:Port 2/1 left bridge port 2/1-4
1999 Dec 18 20:46:25 %PAGP-5-PORTFROMSTP:Port 2/2 left bridge port 2/1-4
1999 Dec 18 20:46:25 %DTP-5-TRUNKPORTON:Port 2/3 has become isl trunk
1999 Dec 18 20:46:26 %PAGP-5-PORTFROMSTP:Port 2/3 left bridge port 2/1-4
1999 Dec 18 20:46:26 %DTP-5-TRUNKPORTON:Port 2/4 has become isl trunk
1999 Dec 18 20:46:26 %PAGP-5-PORTFROMSTP:Port 2/4 left bridge port 2/1-4
1999 Dec 18 20:46:28 %PAGP-5-PORTTOSTP:Port 2/1 joined bridge port 2/1-4
1999 Dec 18 20:46:29 %PAGP-5-PORTTOSTP:Port 2/2 joined bridge port 2/1-4
1999 Dec 18 20:46:29 %PAGP-5-PORTTOSTP:Port 2/3 joined bridge port 2/1-4
1999 Dec 18 20:46:29 %PAGP-5-PORTTOSTP:Port 2/4 joined bridge port 2/1-4

Switch-A (enable) show trunk 2
Port      Mode         Encapsulation  Status        Native vlan
--------  -----------  -------------  ------------  -----------
 2/1      desirable    n-isl          trunking      1
 2/2      desirable    n-isl          trunking      1
 2/3      desirable    n-isl          trunking      1
 2/4      desirable    n-isl          trunking      1

The trunk mode was set to desirable. The result was that trunking mode was negotiated with the neighbor switch, and they decided on ISL (n-isl). The current status now is trunking. This is what happened on SwitchB because of the command issued on SwitchA.

Switch-B (enable) 
2000 Jan 17 19:09:52 %DTP-5-TRUNKPORTON:Port 2/1 has become isl trunk
2000 Jan 17 19:09:52 %DTP-5-TRUNKPORTON:Port 2/2 has become isl trunk
2000 Jan 17 19:09:52 %PAGP-5-PORTFROMSTP:Port 2/1 left bridge port 2/1-4
2000 Jan 17 19:09:52 %DTP-5-TRUNKPORTON:Port 2/3 has become isl trunk
2000 Jan 17 19:09:52 %PAGP-5-PORTFROMSTP:Port 2/2 left bridge port 2/1-4
2000 Jan 17 19:09:53 %DTP-5-TRUNKPORTON:Port 2/4 has become isl trunk
2000 Jan 17 19:09:53 %PAGP-5-PORTFROMSTP:Port 2/3 left bridge port 2/1-4
2000 Jan 17 19:09:53 %PAGP-5-PORTFROMSTP:Port 2/4 left bridge port 2/1-4
2000 Jan 17 19:09:55 %PAGP-5-PORTTOSTP:Port 2/1 joined bridge port 2/1-4
2000 Jan 17 19:09:55 %PAGP-5-PORTTOSTP:Port 2/2 joined bridge port 2/1-4
2000 Jan 17 19:09:55 %PAGP-5-PORTTOSTP:Port 2/3 joined bridge port 2/1-4
2000 Jan 17 19:09:55 %PAGP-5-PORTTOSTP:Port 2/4 joined bridge port 2/1-4

Switch-B (enable) show trunk 2
Port      Mode         Encapsulation  Status        Native vlan
--------  -----------  -------------  ------------  -----------
 2/1      auto         n-isl          trunking      1
 2/2      auto         n-isl          trunking      1
 2/3      auto         n-isl          trunking      1
 2/4      auto         n-isl          trunking      1

Notice that all four ports (2/1-4) became trunks, even though we only specifically changed one port (2/1) to desirable. This is an example of how the change of one port in the channel affects all the ports.

Troubleshooting EtherChannel

The challenges for EtherChannel can be divided into two main areas : Troubleshooting within the configuration phase, and troubleshooting within the execution phase. Configuration errors usually occur because of mismatched parameters on the ports involved (different speeds, different duplex, different spanning tree port values, etc.). You can also generate errors within the configuration if you set the channel on one side to on and wait too long before you configure the channel on the other side. This causes spanning tree loops, which generates an error, and shuts down the port.

When an error is encountered while you configure EtherChannel, be sure to check the status of the ports after you correct the EtherChannel error situation. If the port status is errdisable, that means the ports have been shut down by the software and they do not come on again until you enter the set port enable command.

Note: If the port status becomes errdisable, you must specifically enable the ports with the set port enable command for the ports to become active. Currently, you can correct all the EtherChannel issues but the ports do not come up or form a channel until they are enabled again! Future versions of the operating system can periodically check if errdisable ports must be enabled.

For these tests we turn trunking and EtherChannel off: Mismatched Parameters; Wait Too Long Before You Configure the Other Side; Correct Errdisable State; and Show What Happens When a Link Breaks and is Restored.

Mismatched Parameters

Here is an example of mismatched parameters. We set port 2/4 in VLAN 2 while the other ports are still in VLAN 1. In order to create a new VLAN, we must assign a VTP domain for the switch and create the VLAN.

Switch-A (enable) show port channel
No ports channelling

Switch-A (enable) show port
Port  Name               Status     Vlan       Level  Duplex Speed Type
----- ------------------ ---------- ---------- ------ ------ ----- ------------
 2/1                     connected  1          normal a-full a-100 10/100BaseTX
 2/2                     connected  1          normal a-full a-100 10/100BaseTX
 2/3                     connected  1          normal a-full a-100 10/100BaseTX
 2/4                     connected  1          normal a-full a-100 10/100BaseTX

Switch-A (enable) set vlan 2
Cannot add/modify VLANs on a VTP server without a domain name.

Switch-A (enable) set vtp domain testDomain
VTP domain testDomain modified

Switch-A (enable) set vlan 2 name vlan2
Vlan 2 configuration successful

Switch-A (enable) set vlan 2 2/4
VLAN 2 modified.
VLAN 1 modified.
VLAN  Mod/Ports
---- -----------------------
2     2/4
      
Switch-A (enable)
1999 Dec 19 00:19:34 %PAGP-5-PORTFROMSTP:Port 2/4 left bridg4

Switch-A (enable) show port
Port  Name               Status     Vlan       Level  Duplex Speed Type
----- ------------------ ---------- ---------- ------ ------ ----- ------------
 2/1                     connected  1          normal a-full a-100 10/100BaseTX
 2/2                     connected  1          normal a-full a-100 10/100BaseTX
 2/3                     connected  1          normal a-full a-100 10/100BaseTX
 2/4                     connected  2          normal a-full a-100 10/100BaseTX

Switch-A (enable) set port channel 2/1-4 desirable
Port(s) 2/1-4 channel mode set to desirable.

Switch-A (enable)
1999 Dec 19 00:20:19 %PAGP-5-PORTFROMSTP:Port 2/1 left bridge port 2/1
1999 Dec 19 00:20:19 %PAGP-5-PORTFROMSTP:Port 2/2 left bridge port 2/2
1999 Dec 19 00:20:19 %PAGP-5-PORTFROMSTP:Port 2/3 left bridge port 2/3
1999 Dec 19 00:20:20 %PAGP-5-PORTFROMSTP:Port 2/4 left bridge port 2/4
1999 Dec 19 00:20:20 %PAGP-5-PORTFROMSTP:Port 2/2 left bridge port 2/2
1999 Dec 19 00:20:22 %PAGP-5-PORTFROMSTP:Port 2/3 left bridge port 2/3
1999 Dec 19 00:20:22 %PAGP-5-PORTFROMSTP:Port 2/4 left bridge port 2/4
1999 Dec 19 00:20:24 %PAGP-5-PORTTOSTP:Port 2/1 joined bridge port 2/1-2
1999 Dec 19 00:20:25 %PAGP-5-PORTTOSTP:Port 2/2 joined bridge port 2/1-2
1999 Dec 19 00:20:25 %PAGP-5-PORTTOSTP:Port 2/3 joined bridge port 2/3
1999 Dec 19 00:20:25 %PAGP-5-PORTTOSTP:Port 2/4 joined bridge port 2/4

Switch-A (enable) show port channel
Port  Status     Channel   Channel     Neighbor                  Neighbor
                 mode      status      device                    port
----- ---------- --------- ----------- ------------------------- ---------- 
 2/1  connected  desirable channel     WS-C5505    066509957(Sw  2/1       
 2/2  connected  desirable channel     WS-C5505    066509957(Sw  2/2       
----- ---------- --------- ----------- ------------------------- ----------

Notice that the channel only formed between ports 2/1-2. Ports 2/3-4 were left out because port 2/4 was in a different VLAN. There was no error message; PAgP just did what it could to make the channel work. You need to watch the results when you create the channel to make sure it did what you wanted it to do.

Now set the channel manually to on with port 2/4 in a different vlan and see what happens. First we set the channel mode back to auto in order to tear down the current channel, then we set the channel manually to on.

Switch-A (enable) set port channel 2/1-4 auto
Port(s) 2/1-4 channel mode set to auto.
Switch-A (enable)
1999 Dec 19 00:26:08 %PAGP-5-PORTFROMSTP:Port 2/1 left bridge port 2/1-2
1999 Dec 19 00:26:08 %PAGP-5-PORTFROMSTP:Port 2/2 left bridge port 2/1-2
1999 Dec 19 00:26:08 %PAGP-5-PORTFROMSTP:Port 2/3 left bridge port 2/3
1999 Dec 19 00:26:08 %PAGP-5-PORTFROMSTP:Port 2/4 left bridge port 2/4
1999 Dec 19 00:26:18 %PAGP-5-PORTTOSTP:Port 2/1 joined bridge port 2/1
1999 Dec 19 00:26:19 %PAGP-5-PORTTOSTP:Port 2/2 joined bridge port 2/2
1999 Dec 19 00:26:19 %PAGP-5-PORTTOSTP:Port 2/3 joined bridge port 2/3
1999 Dec 19 00:26:19 %PAGP-5-PORTTOSTP:Port 2/4 joined bridge port 2/4

Switch-A (enable) show port channel
No ports channelling

Switch-A (enable) set port channel 2/1-4 on
Mismatch in vlan number.
Failed to set port(s) 2/1-4 channel mode to on.

Switch-A (enable) show port channel
No ports channelling

On SwitchB we can turn the channel on and notice that it says the ports channel fine, but we know that SwitchA is not configured correctly.

Switch-B (enable) show port channel
No ports channelling

Switch-B (enable) show port
Port  Name               Status     Vlan       Level  Duplex Speed Type
----- ------------------ ---------- ---------- ------ ------ ----- ------------
 2/1                     connected  1          normal a-full a-100 10/100BaseTX
 2/2                     connected  1          normal a-full a-100 10/100BaseTX
 2/3                     connected  1          normal a-full a-100 10/100BaseTX
 2/4                     connected  1          normal a-full a-100 10/100BaseTX

Switch-B (enable) set port channel 2/1-4 on
Port(s) 2/1-4 channel mode set to on.

Switch-B (enable)
2000 Jan 17 22:54:59 %PAGP-5-PORTFROMSTP:Port 2/1 left bridge port 2/1
2000 Jan 17 22:54:59 %PAGP-5-PORTFROMSTP:Port 2/2 left bridge port 2/2
2000 Jan 17 22:54:59 %PAGP-5-PORTFROMSTP:Port 2/3 left bridge port 2/3
2000 Jan 17 22:54:59 %PAGP-5-PORTFROMSTP:Port 2/4 left bridge port 2/4
2000 Jan 17 22:55:00 %PAGP-5-PORTTOSTP:Port 2/1 joined bridge port 2/1-4
2000 Jan 17 22:55:00 %PAGP-5-PORTTOSTP:Port 2/2 joined bridge port 2/1-4
2000 Jan 17 22:55:00 %PAGP-5-PORTTOSTP:Port 2/3 joined bridge port 2/1-4
2000 Jan 17 22:55:00 %PAGP-5-PORTTOSTP:Port 2/4 joined bridge port 2/1-4

Switch-B (enable) show port channel
Port  Status     Channel   Channel     Neighbor                  Neighbor
                 mode      status      device                    port
----- ---------- --------- ----------- ------------------------- ---------- 
 2/1  connected  on        channel     WS-C5505    066507453(Sw  2/1       
 2/2  connected  on        channel     WS-C5505    066507453(Sw  2/2       
 2/3  connected  on        channel     WS-C5505    066507453(Sw  2/3       
 2/4  connected  on        channel     WS-C5505    066507453(Sw  2/4       
----- ---------- --------- ----------- ------------------------- ----------

This makes it clear that you must check both sides of the channel when you manually configure the channel to make sure that both sides are up, not just one side. This output shows that SwitchB is set for a channel, but SwitchA does not channel because it has one port that is in the wrong VLAN.

Wait Too Long Before You Configure the Other Side

In our situation, SwitchB has EtherChannel turned on, but SwitchA does not because it has a vlan configuration error (ports 2/1-3 are in vlan1, port 2/4 is in vlan2). Here is what happens wh

Hierarchical Navigation

Ethernet

Troubleshooting LAN Switching Environments

Downloads

Document ID: 12006

Contents