Cisco Systems 17053 User Manual

Troubleshooting Cisco Catalyst Switches to NIC Compatibility Issues

Document ID: 17053

Introduction Prerequisites

Requirements Components Used Conventions

Background Information

Purpose Why Do Autonegotiation and Compatibility Issues Exist?

General Troubleshooting for 10/100/1000 Mbps NICs

Autonegotiation Valid Configuration Table EtherChannel and Trunking Between Catalyst Switches and NICs Verifying Physical Connection and Link Verifying Switch Port Configuration Maintaining Link (Link Up/Down Situations) Performance Notes Understanding Data Link Errors Sniffer Trace Teaming of Network Interface Cards

Additional Troubleshooting for 1000BASE−X NICs

Gigabit Autonegotiation (No Link to Connected Device) Verifying GBIC

Cisco Catalyst Switch Compatibility and Operation−Specific Issues

Catalyst 8510 and 8540 CSR Catalyst 6000 and 6500 Switches Catalyst 5000 and 5500 Switches Catalyst 4000, 2948G, and 2980G Switches Catalyst 2950 and 3550 Switches

NIC Compatibility and Operation Issues Appendix A: Information to Gather Before Creating a Service Request Appendix B: Understanding How Autonegotiation Works Networking Professionals Connection  Featured Conversations Related Information

Introduction

The purpose of this document is to cover common issues associated with network interface cards (NICs) that interoperate with Cisco Catalyst switches. Network issues, such as slow performance and connectivity problems, as well as Catalyst switch issues that deal with physical connectivity and data link errors, can be related to NIC issues.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

This document is not restricted to specific software and hardware versions.

Conventions

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

Background Information

Purpose

This document discusses how to troubleshoot these issues:

Autonegotiation• Physical Connectivity• Port Errors (Data Link Errors)• Continuous Link Up/Down Situations• Gigabit Port Configuration• Common Catalyst Switch Software Issues• Common NIC Issues and Resolutions•

When you troubleshoot NIC issues with Catalyst switches, the first step is to verify that the issue is not related to a possible configuration issue with the Catalyst switch. For useful information that pertains to common connectivity issues with the configuration of the Catalyst switch, refer to these documents:

This document addresses initial connectivity delays that occur when workstations connected to

•

Catalyst switches are unable to log in to a network domain (Microsoft Windows NT or Novell), or are unable to obtain a Dynamic Host Configuration Protocol (DHCP) address, due to the Catalyst switch configuration. The first step in order to troubleshoot these scenarios is to confirm that the switch configuration is correct, as shown in Using PortFast and Other Commands to Fix Workstation Startup Connectivity Delays. Excessive data link errors cause ports on some Catalyst switches to go into an errdisabled state.

•

Recovering From errDisable Port State on the CatOS Platforms describes what the errdisable state is, explains how to recover from it, and provides two examples of recovery from this state.

Why Do Autonegotiation and Compatibility Issues Exist?

Autonegotiation issues can result from nonconforming implementation, hardware incapabilities, or software defects. When NICs or vendor switches do not conform exactly to the IEEE specification 802.3u, problems can result. Hardware incompatibility and other issues can also exist as a result of vendor−specific advanced features, such as autopolarity or cable integrity, which are not described in IEEE 802.3u for 10/100 Mbps autonegotiation. Generally, if both the NIC and the switch adhere to IEEE 802.3u autonegotiation specifications and all additional features are disabled, autonegotiation must properly negotiate speed and duplex, and no operational issues exist.

General Troubleshooting for 10/100/1000 Mbps NICs

Autonegotiation Valid Configuration Table

Speed determination issues can result in no connectivity. However, issues with autonegotiation of duplex generally do not result in link establishment issues. Instead, autonegotiation issues mainly result in

performance−related issues. The most common problems with NIC issues deal with speed and duplex configuration. Table 1 summarizes all possible settings of speed and duplex for FastEthernet NICs and switch ports.

Note: This section is only applicable for 10/100/1000 Mbps (1000BASE−T) NICs, and not 1000BASE−X NICs.

Table 1Autonegotiation Valid Configuration

Configuration

NIC

(Speed/Duplex)

AUTO

1000 Mbps, Full−duplex

Configuration

Switch

(Speed/Duplex)

AUTO

Resulting NIC

Speed/Duplex

1000 Mbps, Full−duplex

Resulting

Catalyst

Speed/Duplex

1000 Mbps, Full−duplex

Comments Assuming maximum capability of Catalyst switch, and NIC is 1000 Mbps, full−duplex.

Link is established, but the switch does not see any autonegotiation information from NIC. Since Catalyst switches support only full−duplex operation with 1000 Mbps, they default to full−duplex, and this happens only when operating at 1000 Mbps.

AUTO 1000 Mbps,

Full−duplex

1000 Mbps, Full−duplex 1000 Mbps,

100 Mbps, Full−duplex 1000 Mbps,

Full−duplex

AUTO

1000 Mbps, Full−duplex

No Link No Link

1000 Mbps, Full−duplex

Assuming maximum capability of NIC is 1000 Mbps, full−duplex.

Correct Manual Configuration

Neither side establishes link, due to speed mismatch

100 Mbps, Full−duplex

100 Mbps, Half−duplex

Duplex Mismatch

AUTO 100 Mbps,

Full−duplex

100 Mbps, Full−duplex 100 Mbps,

Full−duplex

100 Mbps, Half−duplex

AUTO

10 Mbps, Half−duplex

AUTO

100 Mbps, Half−duplex

100 Mbps, Full−duplex

100 Mbps, Half−duplex

10 Mbps, Half−duplex

100 Mbps, Full−duplex

100 Mbps, Half−duplex

10 Mbps, Half−duplex

Duplex Mismatch

Correct Manual Configuration

Link is established, but switch does not see any autonegotiation information from NIC and defaults to half−duplex when operating at 10/100 Mbps.

Link is established, but switch does not see Fast Link Pulse (FLP) and defaults to 10 Mbps half−duplex.

10 Mbps, Half−duplex 100 Mbps,

Half−duplex

No Link No Link

Neither side establishes link, due to speed mismatch.

Link is established, but NIC does not

AUTO 100 Mbps,

Half−duplex

100 Mbps, Half−duplex

see any autonegotiation information and defaults to 100 Mbps, half−duplex.

Link is established, but

AUTO 10 Mbps,

Half−duplex

10 Mbps, Half−duplex

NIC does not see FLP and defaults to 10 Mbps, half−duplex.

A duplex mismatch can result in performance issues, intermittent connectivity, and loss of communication.

When you troubleshoot NIC issues, verify that the NIC and switch use a valid configuration.

Some third−party NIC cards can fall back to half−duplex operation mode, even though both the switchport and NIC configuration are manually configured for 100 Mbps, full−duplex. This is because NIC autonegotiation link detection still operates when the NIC is manually configured. This causes duplex inconsistency between the switchport and the NIC. Symptoms include poor port performance and frame check sequence (FCS) errors that increment on the switchport. In order to troubleshoot this issue, try to manually configure the switchport to 100 Mbps, half−duplex. If this action resolves the connectivity problems, this NIC issue is the possible cause. Try to update to the latest drivers for your NIC, or contact your NIC card vendor for additional support.

Why Is It That the Speed and Duplex Cannot Be Hardcoded on Only One Link Partner?

As indicated in Table 1, a manual setup of the speed and duplex for full−duplex on one link partner results in a duplex mismatch. This happens when you disable autonegotiation on one link partner while the other link partner defaults to a half−duplex configuration. A duplex mismatch results in slow performance, intermittent connectivity, data link errors, and other issues. If the intent is not to use autonegotiation, both link partners must be manually configured for speed and duplex for full−duplex settings.

Recommended Port Configuration (Autonegotiation or Manual Configuration)

There are many opinions on the subject of autonegotiation. Previously, many engineers advised customers not to use autonegotiation with any switch−connected device. However, improvements in the interoperation of autonegotiation and the maturity of the technology has recently changed the view of autonegotiation and its use. In addition, performance issues due to duplex mismatches, caused by the manual setting of speed and duplex on only one link partner, are more common. Because of these recent issues, the use of autonegotiation is regarded as a valid practice.

EtherChannel and Trunking Between Catalyst Switches and NICs

EtherChannel can be configured dynamically with Port Aggregation Protocol (PAgP), and trunking can also be configured dynamically with Dynamic Trunking Protocol (DTP). Both PAgP and DTP are Cisco proprietary protocols and supported only on Catalyst switches. If you want to configure EtherChannel or trunking between Catalyst switches and NICs, it is recommended that you configure these features statically, as other vendor NICs can potentially not support PAgP and DTP. On Catalyst switches, configure the EtherChannel mode to on and trunking mode to nonegotiate, which disables the PAgP and DTP protocols. If you configure the switch port with auto or desirable mode, it is possible you can not be able to form the EtherChannel or trunk with NICs.

Verifying Physical Connection and Link

When you troubleshoot NIC issues, the first step is to verify physical connectivity. Visual inspection of the switch must show a LINK light indicator when connected to a link partner. In addition, the NIC can also have a LINK light indicator. The Command Line Interface (CLI) of the switch must be checked in ordre to verify physical connectivity. The port in question must show connected for Catalyst OS software and line protocol up for Cisco IOS® Software on the switch.

Example for CatOS − Catalyst 2948G, 2980G, 4000, 5000, and 6000 that Run CatOS Software

show port modDport

•

Switch> (enable) show port 3/1 Port Name Status VLAN Level Duplex Speed Type

−−−−−−−−−− −−−−−−−− −−−−−−− −−−−−−− −−−−−−− −−−−−− −−−−−−−−−−−−−− 3/1 notconnect 1 normal half 100 100BaseFX MM

Example for Cisco IOS Software on the Switch − Catalyst 2900XL, 3500XL, 2948G−L3, and 6000 that Run Cisco IOS Software

show interfaces type

•

Switch# show interfaces fastethernet 0/1 FastEthernet0/1 is down, line protocol is down

States other than connected and line protocol is up indicate a physical connectivity issue. Complete these steps in order to troubleshoot physical connectivity:

Set speed and duplex of both the NIC and switch at 10 Mbps, full−duplex.

Is there physical connectivity? If desirable, repeat this step with the speed set to 100 Mbps, full−duplex. To set speed and duplex manually is probably not be required in order to establish physical connectivity.

For possible known issues, see the Cisco Catalyst Switch Compatibility and Operation−Specific Issues and NIC Capability and Operation Issues sections of this document. Replace the cable with a known good Category 5, Category 5e or Category 6 10/100/1000 Mbps

2. Ethernet cable. Attempt physical connectivity across multiple switch ports.

Verify that the problem is consistent across multiple switch ports. Also, try multiple switches and hubs if applicable. Replace the NIC in order to determine if the problem is consistent with the same brand and model of

4. NIC.

For possible known issues, see the Cisco Catalyst Switch Compatibility and Operation−Specific Issues and NIC Capability and Operation Issues sections of this document. Create a service request with Cisco Technical Support and the NIC vendor.5.

Verifying Switch Port Configuration

The default configuration of the Catalyst switch ports can cause specific interoperability issues for NICs. The symptoms of problems can include DHCP issues and the inability to perform a network login. When you troubleshoot any NIC or switch port issue, verify that the configuration of port channeling and trunking is off and that spanning tree PortFast is enabled.

Refer to Using PortFast and Other Commands to Fix Workstation Startup Connectivity Delays for more documentation with regard to this configuration change.

Maintaining Link (Link Up/Down Situations)

Under certain circumstances, interoperability issues between Cisco switches and various NICs can result in continuous or intermittent link up/down situations. These link up/down situations are usually a result of power management features or jitter tolerance issues associated with the NIC.

For link up/down situations for CatOS, these messages appear and are normal for link up/down

•

situations:

PAGP−5−PORTTOSPT: Port [dec]/[dec] joined bridge port [dec]/[chars] PAGP−5−PORTFROMSPT: Port [dec]/[dec] left bridge port [dec]/[chars]

This is an example:

%PAGP−5−PORTFROMSTP:Port 3/3 left bridge port 3/3 %PAGP−5−PORTTOSTP:Port 3/3 joined bridge port 3/3

For Cisco IOS Software−based switches, these messages appear for link up/down situations:

•

%LINK−3−UPDOWN: Interface interface, changed state to up %LINK−3−UPDOWN: Interface interface, changed state to down

This is an example:

%LINK−3−UPDOWN: Interface FastEthernet0/1, changed state to up %LINK−3−UPDOWN: Interface FastEthernet0/1, changed state to down

In order to resolve these issues, troubleshoot with these techniques:

Disable Windows 2000 and Windows Millennium Edition (ME) power management functions.

•

Windows 2000 and Windows ME employ a power management capability that can disable the NIC. When the NIC is disabled for power management, it drops the link to the switch. If there is a concern about the link going up/down on NICs with the Windows 2000 or Windows ME operating systems, disable the power management feature as a first step in order to troubleshoot link up/down situations.

Disable the NIC power management functionality. Many NICs support their own power

•

management capability.

When you troubleshoot link up/down issues, disable this feature. For information on how to disable power management, refer to the NIC documentation.

Adjust switch jitter tolerance.

•

Jitter tolerance, based on the IEEE 802.33u−1995, clause 25, must not exceed 1.4 nanoseconds. However, there are situations in which NICs that operat out−of−specification with respect to excessive jitter cause link up/down situations on Catalyst 6000 and 6500 10/100 ports. The workaround for this issue is to increase the jitter tolerance on the Catalyst 6000 and 6500 switches for 10/100 ports to 3.1 seconds. The set option debounce enable command enables the feature. As an ultimate solution, replace the out−of−specification NICs, instead of using the debounce option. This feature is first integrated into software version 5.3(5)CSX.

For the Catalyst 2900XL and 3500XL, the interface command carrier−delay time can be adjusted to four seconds as a possible workaround for this same issue.

Refer to Fast Ethernet Consortium Physical Medium Dependent Test Suite for more information about jitter tolerance.

Performance Notes

Most performance issues are related to switch port configuration, duplex mismatches, link up/down situations, and data link errors. When you troubleshoot performance issues, review all previous sections of this document. After you review these sections, proceed to the next section, Understanding Data Link Errors. The final step in order to resolve any performance issue is to obtain a sniffer trace. A sniffer trace is very conclusive with regard to any specific performance problem because it details packet transfer.

Understanding Data Link Errors

Many performance issues with NICs can be related to data link errors. Excessive errors usually indicate a problem. When operating at a half−duplex setting, some data link errors such as FCS, alignment, runts, and

collisions are normal. Generally, a one percent ratio of errors to total traffic is acceptable for half−duplex connections. If the ratio of errors to input packets is greater than two or three percent, performance degradation can be noticed.

In half−duplex environments, it is possible for both the switch and the connected device to sense the wire and transmit at exactly the same time and result in a collision. Collisions can cause runts, FCS, and alignment errors, caused when the frame is not completely copied to the wire, which results in fragmented frames.

When operating at full−duplex, FCS, cyclic redundancy checks (CRC), alignment errors, and runt counters are probably minimal. If the link operates at full−duplex, the collision counter is not active. If the FCS, CRC, alignment, or runt counters increment, check for a duplex mismatch. Duplex mismatch is a situation in which the switch operates at full−duplex and the connected device operates at half−duplex, or the other way around. The result of a duplex mismatch is extremely slow performance, intermittent connectivity, and loss of connection. Other possible causes of data link errors at full−duplex are bad cables, a faulty switch port, or NIC software or hardware issues.

When you troubleshoot NIC performance issues, view the output of the show port mod/port command and the show mac mod/port command, and note the counter information.

Table 2Explanation of CatOS show port Command Counters

Counter

Alignment Errors

FCS

Xmit−Err This is an indication that the internal transmit

Rcv−Err UnderSize These are frames that are smaller than 64 bytes,

Single Collisions

Multiple Collisions

Late Collisions

Alignment errors are a count of the number of frames received that do not end with an even number of octets and have a bad CRC. FCS error count is the number of frames that were transmitted or received with a bad checksum (CRC value) in the Ethernet frame. These frames are dropped and not propagated onto other ports.

buffer is full.

This is an indication that the receive buffer is full.

which includes FCS, and have a good FCS value.

Single collisions are the number of times the transmitting port had one collision before successfully transmitting the frame to the media.

Multiple collisions are the number of times the transmitting port had more than one collision before successfully transmitting the frame to the media. A late collision occurs when two devices transmit at the same time and neither side of the connection detects a collision. The reason for this occurrence is that the time to propagate the signal from one end of the network to another is longer than the time to put the entire packet on the network. The two devices that cause the late collision never see that the other sends until after it puts the entire packet on the network. Late collisions are detected by the transmitter after the first time slot of the

Description

64−byte transmit time occurs. They are only detected during transmissions of packets longer than 64 bytes. Its detection is exactly the same as it is for a normal collision; it just happens later than it does for a normal collision.

Excessive Collisions

Carrier Sense

Runts These are frames smaller than 64 bytes with a bad

Giants These are frames that are greater than 1518 bytes

Table 3Possible Causes for Incrementing CatOS Counters

Counter

Alignment Errors

FCS

Excessive collisions are the number of frames that are dropped after 16 attempts to send the packet resulted in 16 collisions.

Carrier sense occurs every time an Ethernet controller wants to send data and the counter is incremented when there is an error in the process.

FCS value.

and have a bad FCS value.

Description These are the result of collisions at half−duplex, duplex mismatch, bad hardware (NIC, cable, or port), or a connected device that generates frames that do not end with on an octet and have a bad FCS.

These are the result of collisions at half−duplex, duplex mismatch, bad hardware (NIC, cable, or port), or a connected device that generates frames with bad FCS.

This is an indication of excessive input rates of traffic. This is also an indication that the transmit buffer is full. The counter must only increment in

Xmit−Err

Rcv−Err

UnderSize This is an indication of a bad frame generated by

Single Collisions This is an indication of a half−duplex

situations in which the switch is unable to forward out the port at a desired rate. Situations such as excessive collisions and 10 Mb ports cause the transmit buffer to become full. If you increase speed and move the link partner to full−duplex, it minimizes this occurrence.

This is an indication of excessive output rates of traffic. This is also an indication that the receive buffer is full. This counter must be zero unless there is excessive traffic through the switch. In some switches, the Out−Lost counter has a direct correlation to the Rcv−Err.

the connected device.

configuration.

+ 18 hidden pages