Contents

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
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) interoperating with Cisco Catalyst switches. Network issues, such as slow performance and connectivity problems, as well as Catalyst switch issues dealing with physical connectivity and data link errors, may 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

For more information on document conventions, refer to the Cisco Technical Tips 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 troubleshooting 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 pertaining to common connectivity issues with the configuration of the Catalyst switch, refer to the documents listed below.

• 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 troubleshooting these scenarios is to confirm that the switch configuration is correct, as shown in this document:
  • 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. This document describes what the errdisable state is, explains how to recover from it, and provides two examples of recovery from this state:
  • Recovering From errDisable Port State on the CatOS Platforms

Why Do Autonegotiation and Compatibility Issues Exist?

Autonegotiation issues may 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 may result. Hardware incompatibility and other issues may also exist as a result of vendor-specific advanced features, such as autopolarity or cabling 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 should properly negotiate speed and duplex, and no operational issues should exist.

General Troubleshooting for 10/100/1000 Mbps NICs

Autonegotiation Valid Configuration Table

Speed determination issues may 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 when investigating NIC issues deal with speed and duplex configuration. The table below 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 Table

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

As indicated in the Autonegotiation Valid Configuration Table above, manually setting the speed and duplex for full-duplex on one link partner results in a duplex mismatch. This is the result of disabling 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 using autonegotiation. In addition, performance issues due to duplex mismatches, caused by the manual setting of speed and duplex on only one link partner, have become 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 using Port Aggregation Protocol (PAgP), and trunking can also be configured dynamically using 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 may 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, you may not be able to form the EtherChannel or trunk with NICs.

Verifying Physical Connection and Link

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

Example for CatOS (Catalyst 2948G, 2980G, 4000, 5000, and 6000 Running CatOS Software)

• show port mod⁄port

  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 Running 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. The steps for troubleshooting physical connectivity are:

1. 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 setting speed to 100 Mbps, full-duplex. Setting speed and duplex manually should not be required to establish physical connectivity.

   For possible known issues, refer to the Cisco Catalyst Switch Compatibility and Operation-Specific Issues and NIC Capability and Operation Issues sections of this document.

2. Replace the cable with a known good Category 5, Category 5e or Category 6 10/100/1000 Mbps Ethernet cable.
3. 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.

4. Replace the NIC to determine if the problem is consistent with the same brand and model of NIC.

   For possible known issues, refer to the Cisco Catalyst Switch Compatibility and Operation-Specific Issues and NIC Capability and Operation Issues sections of this document.

5. Create a service request with Cisco Technical Support and the NIC vendor.

Verifying Switch Port Configuration

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

For additional documentation regarding this configuration change, refer to:

• Using PortFast and Other Commands to Fix Workstation Startup Connectivity Delays

Maintaining Link (Link Up/Down Situations)

Under certain circumstances, interoperability issues between Cisco switches and various NICs may 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, the messages displayed are shown below. These messages 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 
  

To resolve these issues, try the following troubleshooting:

• 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 using the operating system Windows 2000 or Windows ME, disable the power management feature as a first means of troubleshooting link up/down situations.

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

  When troubleshooting link up/down issues, disable this feature as another means of troubleshooting. For information on disabling power management, refer to the NIC documentation.

• Adjust switch jitter tolerance.

  Jitter tolerance, according to the IEEE 802.33u-1995, clause 25, should not exceed 1.4 nanoseconds. However, there have been situations in which NICs operating out-of-specification with respect to excessive jitter have caused 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 command to enable the feature is set option debounce enable. The ultimate solution is to replace the out-of-specification NICs, instead of using the debounce option. This feature was 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.

  Additional information regarding jitter tolerance can be found by referring to:

  • Fast Ethernet Consortium Physical Medium Dependent Test Suite

Performance Notes

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

Understanding Data Link Errors

Many performance issues with NICs may be related to data link errors. Excessive errors usually indicate a problem. When operating at 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 may 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 should be minimal. If the link is operating at full-duplex, the collision counter is not active. If the FCS, CRC, alignment, or runt counters are incrementing, check for a duplex mismatch. Duplex mismatch is a situation in which the switch is operating at full-duplex and the connected device is operating 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 troubleshooting 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

Table 3—Possible Causes for Incrementing CatOS Counters

Table 4—Explanation of CatOS show mac Command Counters

² In-Discard and Lrn-Discard do not exist on all Catalyst platforms.

Table 5—Possible Causes for Incrementing CatOS Counters

² In-Discard and Lrn-Discard do not exist on all Catalyst platforms.

Additional counter information can be viewed by issuing the command show counters mod/port . The command must be issued for a single port at a time. Refer to this document for information on the counter displayed:

• show counters Command Documentation

For additional information regarding the Cisco IOS Software show interfaces command counters, refer to:

• show interfaces Command Documentation

Sniffer Trace

Sniffer trace analysis can be very useful in troubleshooting switch and NIC performance or connectivity issues when the issues persist after reviewing all other sections of this document. Sniffer trace analysis reveals every packet on the wire and pinpoints the exact problem. It may be important to obtain several sniffer traces from different ports on different switches. Generally, it is very useful to monitor ("span") ports rather than spanning VLANs when troubleshooting switch and NIC performance and connectivity issues.

For more information on using the Switched Port Analyzer (SPAN) feature required to obtain sniffer traces, refer to:

• Configuring the Catalyst Switched Port Analyzer (SPAN)

Additional Troubleshooting for 1000BASE-X NICs

Gigabit Autonegotiation (No Link to Connected Device)

Gigabit Ethernet has an autonegotiation procedure that is more extensive than what is used for 10/100 Mbps Ethernet (Gigabit autonegotiation specification IEEE 802.3z-1998). The Gigabit autonegotiation negotiates flow control, duplex mode, and remote fault information. You must either enable or disable link negotiation on both ends of the link. Both ends of the link must be set to the same value or the link does not connect.

If either device does not support Gigabit autonegotiation, disabling Gigabit autonegotiation forces the link up. The default configuration of all Cisco switches is autonegotiation-enabled. Disabling autonegotiation hides link drops and other physical layer problems. Only disable autonegotiation to end-devices, such as older Gigabit NICs that do not support Gigabit autonegotiation. Do not disable autonegotiation between switches unless absolutely required, as physical layer problems may go undetected and result in spanning tree loops. The alternative to disabling autonegotiation is contacting the vendor for a software or hardware upgrade for IEEE 802.3z Gigabit autonegotiation support.

Table 6—Gigabit Autonegotiation Configuration Table

Issue these commands for Gigabit autonegotiation configuration:

• CatOS command:

  set port negotiation mod/port enable | disable
  

• Cisco IOS Software command:

  negotiation auto no negotiation auto
  

Verifying GBIC

When troubleshooting link issues on Gigabit Ethernet, it is also important to verify the use of the correct Gigabit Interface Converter (GBIC) adapter with the correct cabling distance. This document references distances and cabling specifications required for different versions of GBIC adapters:

• Gigabit Interface Converter Installation Note

Cisco Catalyst Switch Compatibility and Operation-Specific Issues

The following sections deal with specific Cisco Catalyst switch issues that may affect performance, compatibility, and interoperation of certain NICs.

Catalyst 8510 and 8540 CSR

In the campus switch router (CSR) Cisco IOS Software Release 12.0(5)W5(13), autonegotiation for speed and duplex are enabled by default. In earlier releases, autonegotiation was not supported by default. As a result, each connected interface had to be set to run in full-duplex mode. If you upgrade to Cisco IOS Software Release 12.0(5)W5(13) with the router running in manually full-duplex mode, you experience performance issues. The symptoms include high collision rate, reduced throughput, and more packet drops. This is because the Catalyst 8500 waits to autonegotiate with the connected device. Now that the connected device has been forced to run in full-duplex mode, it does not participate in autonegotiation. According to the specification, this causes the Catalyst 8500 interface to settle in half-duplex mode, causing a mismatch between the device and the Catalyst 8500 at the interface level. Catalyst 8500 interface defaults to half-duplex mode when the peer is incapable of negotiation.

Catalyst 6000 and 6500 Switches

The table below describes Cisco bug IDs found on the Catalyst 6000 and 6500 switches.

Table 7

Cisco Bug ID	Resolved In	Description
CSCdm48887 ( registered customers only)	5.2.3, 5.3.1a	When a port goes into the errdisable state on a Catalyst 6000 or 6500, the switch inadvertently learns the MAC addresses of other devices to be learned from the errdisable port. The errdisable state is caused by excessive late collisions on a port. Since all traffic on that VLAN is forwarded incorrectly out of the incorrect port, there is a loss of connectivity. This errdisable state may appear as a result of a duplex mismatch or faulty NIC.
CSCdm80035 ( registered customers only)	5.2.3, 5.3.1a	When a Gigabit connection is reset on a Catalyst 6000 or 6500, the connection may not reconnect. A symptom of this issue may be that a Gigabit NIC is not connecting after reset or disconnect.
CSCdm88013 ( registered customers only)	5.2.3, 5.3.1a	Occasionally, host NICs connected to WS-X6248-TEL or WS-X6248-RJ-45 modules may incorrectly revert to half-duplex after an autonegotiation failure.

For detailed information on Cisco bug IDs, refer to the Bug Toolkit ( registered customers only) .

Additional Catalyst 6000 and 6500 documented bug fixes can be found by referring to:

• Catalyst 6500 Series Release Notes

Catalyst 5000 and 5500 Switches

The table below lists several known issues found on the Catalyst 5000 and 5500 switches.

Table 8

Cisco Bug ID	Resolved In	Description
CSCdt28585 ( registered customers only)	5.5(6)	Directly connected hosts (PCs, routers, and servers) may indicate a connected state in the output of a show port command, but do not forward Xmit-Broadcast frames. This causes connectivity issues that are only fixed by issuing the set port disable mod/port and the set port enable mod/port commands.
CSCdr50629 ( registered customers only)	5.5(3)	Ports on WS-X5225R, WS-X5234, and WS-X5201R modules stop transmitting unicast frames after a scheduled test of the packet buffers. The workaround is to disable the packet buffer test.
CSCdr03818 ( registered customers only)	4.5(7), 5.4(2)	The WS-X5225R and WS-X5234 modules fail to negotiate the duplex mode correctly after a system reset or power cycle with Sun workstations Ultra 5.
CSCdm51653 ( registered customers only)	4.5(3), 5.1(2a)	Autonegotiation between Sun 10/100 NICs and certain Catalyst 5000 family modules (such as the WS-X5225R) may result in speed or duplex mismatches under certain conditions. The problem typically occurs after resetting the module or disabling and reenabling the switch port. The workaround is to disconnect and reconnect the cable connecting the workstation to the switch port.
CSCdk32984 ( registered customers only)	4.2(2)	The 48-port, 10BASE-T Ethernet module (WS-X5012) incorrectly drops valid frames with dribble bits (extra bits added to frames by some end stations and transceivers).
CSCdj82035 ( registered customers only)	3.2(2), 4.1(3)	Under heavy traffic conditions, ports 1 through 24 (or ports 25 through 48) of the 48-port, 10BASE-T Ethernet module (WS-X5012) may stop transmitting frames.

For detailed information on Cisco bug IDs, refer to the Bug Toolkit ( registered customers only) .

Additional Catalyst 5000 and 5500 documented bug fixes can be found by referring to:

• Catalyst 5000 Family Release Notes

Catalyst 4000, 2948G, and 2980G Switches

The table below lists several known issues found on the Catalyst 4000, 2948G, and 2980G switches.

Table 9

Bug ID	Resolved In	Description
CSCds38973 ( registered customers only)	4.5(8), 5.2(7), 5.5(2)	The Catalyst 2948G and Catalyst 4000 switches may experience issues with total or intermittent loss of connectivity. The frequency of these issues can vary from once a day to once a month. This issue may reoccur even after power cycling the switch. The purpose of this Cisco bug ID is to combine several software reworks, fixes that resolve and reduce the loss of connectivity issues, and additional troubleshooting checks in software.
CSCdr37645 ( registered customers only)	4.5(8), 5.5(2), 6.1(1)	An invalid packet with a length of less than 64 bytes received on a 10/100 port causes both the Runts and FCS-Error counters to increment on the port. To determine the actual number of FCS-Errors on valid length packets received on the port, subtract the value of the port Runts counter from the value of the port FCS-Error counter.
CSCdm38405 ( registered customers only)	5.1(1)	Some Sun Gigabit Ethernet NICs do not reliably autonegotiate flow control with certain ports on the Catalyst 4000 series oversubscribed Gigabit Ethernet modules. The 18-port server switching 1000BASE-X (GBIC) Gigabit Ethernet module (WS-X4418) is affected.
CSCdm51653 ( registered customers only)	4.5(3), 5.1(2a)	In some cases, autonegotiation with some Sun NICs may result in a nonoptimal configuration (such as 10 Mbps, half-duplex instead of 100 Mbps, full-duplex).
CSCdt80707 ( registered customers only)	5.5.7, 6.1.3, 6.2.1	On a Catalyst 4006 with a Supervisor Engine II, switch ports in the same VLAN may lose connectivity with one another. The loss of connectivity results in a VLAN appearing to be partitioned into several isolated segments. A host may be able to ping one set of devices in its VLAN, while it cannot ping another set of devices in the same VLAN. This loss of connectivity is independent of the slot in which a linecard is installed; that is, the same set of ports on a given linecard are affected regardless of the slot in which the linecard is installed. The workaround is to reset the switch.
CSCds89148 ( registered customers only)	5.5.6, 6.2.1	Xmit-Err counter increments on unconnected ports for unexplained reasons. The bug also resolves an issue of high-CPU utilization conditions that can be caused by unconnected ports that are configured as host ports.

For detailed information on Cisco bug IDs, refer to the Bug Toolkit ( registered customers only) .

Additional Catalyst 2948G, 2980G, and 4000 documented bug fixes can be found by referring to:

• Catalyst 4500 Series Release Notes

Catalyst 2950 and 3550 Switches

The table below lists several known issues found on the Catalyst 2950 and 3550 switches.

Table 10

Cisco Bug ID	Resolved In	Description
CSCdz44520 ( registered customers only)	12.1(13)EA1	The Catalyst 3550-24PWR inline power interfaces do not link up to certain 10/100/1000 interfaces configured as auto/auto. Connecting the Catalyst 3550-24PWR inline power interfaces to a 10/100/1000 interface configured as auto/auto on a Catalyst 3550-12G or 3550-12T does not work.
CSCdz32789 ( registered customers only)	12.1(13)EA1	The link to certain NICs fails to come up when the switch port is hardcoded to 100 Mbps, full-duplex or 100 Mbps, half-duplex.
CSCdy72718 ( registered customers only)	12.1(13)EA1	The switch port does not receive packets if the port is hardcoded to a speed of 100, however it transmits properly.
CSCea36322 ( registered customers only)	12.1(14)EA1	If a 10/100 port on the Catalyst 3550-24PWR switch is connected to a Gigabit Ethernet NIC, with the speed/duplex setting set to auto, and the port speed changed from 100 Mbps to 10 Mbps, or from 10 Mbps to 100 Mbps, the link between the port and the NIC may not come up.

For detailed information on Cisco bug IDs, refer to the Bug Toolkit ( registered customers only) .

NIC Compatibility and Operation Issues

Disclaimer: Use this table as a guide to troubleshooting NIC issues. Consult the NIC vendor for verification and proper resolution of the issue.

Table 11

NIC Model/Manufacture	Symptom	Description	Resolution
Apple Macintosh G3	Intermittently loses network services when using the built-in Ethernet interface.	Driver versions earlier than 2.04 may experience this issue. Contact vendor technical support for more information.	Upgrade to driver version 2.04 or later.
Apple Macintosh, Power Macintosh G3, and Powerbook G3	Unable to set speed and duplex of built-in Ethernet interface manually.	Apple Speed/Duplex tool is required to manually set speed/duplex of Ethernet interface.	Download Apple Speed/Duplex tool from Apple support website.
Apple Macintosh OS with Open Transport 2.5.1 and 2.5.2	Unable to obtain DHCP address from DHCP server.	Upon bootup, Macintosh may fail to obtain IP address from DHCP server.	See Apple technical information library article 25049.
Apple Macintosh Built-In Ethernet	Unable to determine hardware MAC address.	In order to troubleshoot network connectivity issues, host MAC address may be required.	Contact vendor technical support.
Apple Macintosh Performance Issues and NuBus	Built-in Ethernet interfaces outperform NuBus Ethernet cards.	Concern of maximum data transfer rate possible with the built-in Ethernet.	See Apple technical information library article 12000.
Apple Powerbook G3/G4 with Internal NIC	Slow performance when performing large file transfers.	Some NICs may operate out-of-specification, as published in IEEE 802.3. Some Catalysts are more tolerant of out-of-spec NICs and do not notice any performance degradation.	Use of external or PC card. Contact Apple technical support.
Various Apple G3/G4 Laptops and Workstations with Internal NICs	Slow performance.	Notable slow performance.	Upgrade to latest NIC driver and load Duplexer utility. Verify autonegotiation settings.
AsantéFast 10/100 PCI Adapter	Slow login or fails to log in to server.	—	See technical document TID1084 at Asanté support website.
AsantéFast 10/100 PCI Adapter	Numerous CRC and FCS errors reported on switch when connected to Power Macintosh 9500.	—	See technical document TID1109 at Asanté support website.
AsantéFast 10/100 PCI Adapter	Slow network throughput after Macintosh OS 8.5 or 8.6 upgrade.	—	See technical document TID1976 at Asanté support website.
Asanté GigaNIC 1064SX PCI Card-Macintosh	Network performance fluctuates.	When the energy saver mode is active under OS 8.6, the network speed becomes quite slow as soon as the monitor goes dim.	Turn off the energy saver mode in the control panel. The network speed remains constant. See technical document TID2095 at Asanté support website.
Asanté GigaNIC 1064SX PCI Card-Macintosh	Slow performance with AppleShare IP servers and PCI Ethernet cards.	Customers report AppleShare IP servers slow down and eventually crash over time. This occurs using both built-in Ethernet and various PCI cards.	See technical document TID2227 at Asanté support website.
3Com 3C574/575 PCMCIA 10/100	Extremely slow performance when operating at 10 MB.	The 3C574/3C575 experiences slow performance when connecting at 10 MB with Catalyst 2948G, 2980G, 4000, 5000, and 6000 switches. This issue is caused by the NIC doing autopolarity upon linkup.	Upgrade to the latest NIC card driver and disable autopolarity.
3Com 3C595	FCS or alignment errors recorded on the switch. Noted slower performance. When using the 3C595 adapter in 100 MB, half-duplex. This problem usually only represents one percent to two percent of the total traffic.	FCS or alignment errors when using the 3C595 adapter in 100 MB, half-duplex. This problem usually represents one percent to two percent of the total traffic.	Upgrade to the latest NIC driver and disable Bus Master. These steps reduce FCS and alignment errors.
3Com 3C905/3C905B	Intermittent DHCP issues.	Despite configuring Catalyst switch ports correctly, workstations still experience some intermittent DHCP issues.	Upgrade to driver version 4.01b or later, which resolves DHCP issues.
3Com 3C905/3C905B	Unable to log in to Novell Internetwork Packet Exchange (IPX) network.	Despite configuring Catalyst switch ports correctly, workstations still experience intermittent Novell IPX login issues.	Upgrade to driver 4.01b or later, which resolves IPX autoframe-type issues. Alternatively, manually configure workstations for IPX frame type.
3Com 3C905B	Slow performance when receiving large files.	Notable slow performance when receiving large files. Problem only occurs with standard Microsoft NT 4.0, regardless of service pack.	Download latest driver from 3Com technical support.
3Com 3C905C	Layer 2 (L2) errors reported on switch port (FCS, alignment, CRC, and runts), and slow performance on high-speed workstations.	Under normal operating conditions, a Catalyst that reports numerous L2 (physical) errors on ports connected to 3C905C NIC adapters.	Load latest driver and diagnostic tools available from 3Com. Test performance back-to-back between two PCs, and note errors on diagnostic tools. Errors reported such as transmit under-run and receive over-run result in physical layers being reported by the switch and minor performance issues. For more details, refer to Cisco bug ID CSCdt68700 ( registered customers only) .
3C905CX-TX-M	The link fails to come up when the switch port is hardcoded to 100 Mbps, full-duplex or 100 Mbps, half-duplex, and the NIC is set to autonegotiate.	Refer to Cisco bug ID CSCdz32789 ( registered customers only) .	Upgrade to driver version 5.4, and in the advanced NIC properties, set LnkChk to enable. The driver can be downloaded from 3Com .
3Com 3C980	Data corruption using Novell.	—	Refer to 3Com technical support reference 1.0.33921641.2241835.
3Com	3C985/3C985B	Novell 5.0 issues	Refer to 3Com technical support reference 1.0.16744826.2027011.
3Com 3C985/3C985B	Clients are unable to log in or browse server, but pings work correctly.	—	Refer to 3Com technical support reference 2.0.4428387.2305072.
3Com 3C985/3C985B	Packets larger than Ethernet MTU (1518 bytes) are generated. These packets are noted as giants on Catalyst switches.	—	Contact 3Com technical support.
3Com 3C905C or 3C920 integrated NIC on Dell Dimension XPS	Network connectivity is dropped every 2–3 minutes or the network card must be reinitialized several times to gain network connectivity.	A 3C905C or 3C920 integrated NIC on Dell Dimension XPS may experience network connectivity issues when running Windows 2000 due to a power management issue.	Disable all power management functions. Contact Dell for details on disabling power management or more details surrounding this issue. For more documentation, refer to 3Com technical support reference 2.0.47464140.2853794.
Compaq Netflex-3 Model NIC Adapters	Slow performance.	Autonegotiation may fail to Catalyst 5000 and 5500 switches.	This problem is resolved in software release 4.5(1) and later for the Catalyst 5000 and 5500 switches. For more details, refer to Cisco bug ID CSCdk87853 ( registered customers only) .
Dell Optiplex GX200	The link flaps when connecting to a Dell Optiplex GX200 PC (Intel Pro 10/100). The NIC works properly when the PC is turned off, but when it is turned back on, the flapping occurs.	For more details, refer to Cisco bug ID CSCdz60677 ( registered customers only) .	Upgrade to the latest drivers from Dell.
Dell Precision 420/530/620	When connecting to the Catalyst 2950 switch with an autonegotiation link, it continuously flaps and the autonegotiation link fails. The motherboards were manufactured with an Intel Chipset that are incompatible with Cisco switches and Netgear hubs.	Manufactured between May 21 and August 1, 2001.	Contact Dell technical support and Cisco Technical Support for more details.
IBM 10/100 EtherJet CardBus Adapter	Extremely slow performance when operating at 10 Mbps.	Certain 10/100 switches implement automatic correction for polarity-reversed cables that are not completely compatible with the same correction provided by the IBM 10/100 EtherJet CardBus Adapter. If the network speed is forced to 10 Mbps, severe throughput problems may be experienced.	To resolve this problem, a new Auto Polarity keyword has been added in the adapter advanced properties. If needed, the default setting of ON (meaning that the card compensates for reversed cables) can be set to OFF to disable polarity correction. This restores normal throughput.
IBM ThinClient Workstations	Link flaps continuously after extended operation.	Workstations earlier than Service Pack 3.0 bounce the link on the switch after continuous use when attached to Catalyst 2948G or 4000 switches on software version 6.x and later.	Upgrade IBM ThinClient to Service Pack 3.0.
Intel Pro/100	Consistent link up/down connections to Catalyst switches.	May be caused by power management. Contact Intel technical support for further information.	Choose Control Panel > System > Hardware > Device Manager. Choose Network Adapters > Intel Pro 100 +. At the Power Management tab, uncheck Allow the computer to turn off this device .
Intel Pro/1000 T Gigabit Copper NIC	When an Intel Pro/1000 T NIC is connected to a Catalyst switch, you may see poor network connections or excessive numbers of dropped packets. The interoperability issue arises when a module with a ten bit interface (TBI) transmits an odd byte packet to a receiver with a Gigabit media-independent interface (GMII).	The interoperability issue arises from the implementation of Carrier Extension. Carrier Extension is detailed in subsection 35.2.3.5 in the IEEE 802.3 specification. Carrier Extension can be used to pad the last byte of a packet, so the packet is aligned on an even-numbered boundary.	Contact Intel technical support for the latest driver.
Sun Microsystems QFE Card	Unable to manually set speed and duplex correctly.	Manually setting speed and duplex only affects the first of four ports.	Contact vendor technical support to obtain the latest driver to resolve the issue.
Sun Microsystems v1.1 Gigabit Cards	Unable to establish link.	V1.1 may not establish link to switch.	Contact vendor technical support or v2.0 Gigabit Card.
Xircom CreditCard Ethernet 10/100 CE3B-100	Not negotiating or operating correctly at 100 Mbps, full-duplex.	Full-duplex operation is only supported at 10 Mbps. Full-duplex is not supported at 100 Mbps. The LineMode keyword has no effect on performance at 100 Mbps. If the LineSpeed keyword is set to 100 Mbps and the LineMode keyword is set to full-duplex, the LineMode keyword is ignored. Full-duplex at 10 Mbps is only available when the adapter is connected to a full-duplex-capable switch or hub.	Do not operate this NIC at 100 Mbps, full-duplex.
Xircom CreditCard Ethernet 10/100 CE3B-100	Not negotiating 10 Mbps full-duplex.	The CE3 and, in some cases, the CE3B are not capable of negotiating to 10 Mbps, full-duplex mode.	On these adapters, in order to operate in full-duplex mode, the LineSpeed keyword must be set to 10 Mbps, and the LineMode keyword must be set to full-duplex. The cable type keyword can be set to Auto Detect or 10BASE-T/100BaseTX. The corresponding port on the attached hub or switch should also be set to 10Mbps, full-duplex.
Xircom RealPort2 CardBus Ethernet 10/100 Adapter (R2BE/RBE/CBE) Models	Extremely slow performance when operating at 10 Mbps.	Certain 10/100 switches implement automatic correction for polarity-reversed cables that are not completely compatible with the same correction provided by the CBE/RBE. If the network speed is forced to 10 Mbps, severe throughput problems may be experienced.	To resolve this problem, a new Auto Polarity keyword has been added in the adapter advanced properties in driver version 3.01. If needed, the default setting of ON (meaning that the card compensates for reversed cables) can be set to OFF to disable polarity correction. This restores normal throughput.
Xircom RealPort2 CardBus Ethernet 10/100 Adapter (R2BE/RBE/CBE) Models	Initial network connections may fail. DHCP may obtain an IP address, and Windows NT login and Novell IPX may fail.	Initialization delay. Certain switches and routers are unable to immediately forward network traffic when a network adapter first establishes link to one of its ports because of initialization delays. This problem is most commonly seen when the network adapter is connected directly to ports on the switch. The adapter, by default, (when used under some operating systems) has almost no delay between link and the initial network request.	A new keyword, Initialization Delay, has been added to the adapter advanced properties that prevents forwarding of network requests for a user-selectable period of time. Delays can be added ranging from 1–60 seconds. In most cases, adding a delay in the 1–3 second range is sufficient to resolve the problem.
Xircom RealPort2 CardBus Ethernet 10/100 Adapter (R2BE/RBE/CBE) Models	Not able to connect to the network or get an IP address from the DHCP server when connected to a port replicator or docking station.	Possible Basic Input/Output System (BIOS) or driver update required. Contact vendor support for more information.	If you are attempting to use a CBE/CBE2/RBE in a port replicator or docking station, using Windows 95, and are having problems, confirm that your laptop has the latest BIOS and that the latest manufacturer patches and utility software have been installed.
Xircom XE2000 PCMCIA NIC	Does not autonegotiate to 100 Mbps, full-duplex.	NIC only autonegotiates to 100 Mbps, half-duplex.	Known limitation of XE2000 NIC. Refer to the XE2000 release notes.

Appendix A: Information to Gather Before Creating a Service Request

If the troubleshooting procedure outlined in this document does not resolve your issue, you need to create a service request with Cisco Technical Support. Before you create a service request, gather this information:

1. Identify the specific problem with NIC-to-switch interoperability.

   For example, is the problem only with DHCP, Novell IPX, login, or performance?

2. Issue the show tech-support command from all affected Cisco devices, if applicable; or, issue the show module, show config, show version, or the show port commands.
3. Know the make and model of the NIC.
4. Know the operating system and the NIC driver version.
5. Verify the consistency of the problem.

   For example, does the problem occur across multiple Catalyst switches?

Appendix B: Understanding How Autonegotiation Works

Autonegotiation uses a modified version of the link integrity test that is used for 10BASE-T devices to negotiate speed and exchange other autonegotiation parameters. The original 10BASE-T link integrity test is referred to as Normal Link Pulse (NLP). The modified version of the link integrity test for 10/100 Mbps autonegotiation is referred to as FLP. The 10BASE-T devices expect a burst pulse every 16 (+/- 8) milliseconds (msec) as part of the link integrity test. FLP for 10/100 Mbps autonegotiation sends these bursts every 16 (+/- 8) msec with the additional pulses every 62.5 (+/- 7) microseconds. The pulses within the burst sequence generate code words that are used for compatibility exchanges between link partners. This process of FLP used in autonegotiation maintains backward compatibility with existing 10BASE-T connections, with the pulse burst every 16 (+/- 8) msec to comply with the link integrity test for normal 10BASE-T hardware. If a device is sending FLP and only receives NLP, the hardware immediately ceases transmission of the FLP and enables the standard 10BASE-T hardware to continue 10BASE-T operation.

The table below describes the possible programmable options of the control register for a FastEthernet interface. These options determine how the FastEthernet interface functions when connected to a link partner. The 0 in the Bits column refers to the programmable register address, and the decimal number following the 0 refers to the bit placement within the 16-bit register.

Table 12—Physical Interface (PHY) Control Register Programmable Options

The register bits relevant to this document include 0.13, 0.12, 0.8, and 0.6. The other register bits are documented in the IEEE 802.3u specification. According to IEEE 802.3u, in order to manually set the rate (speed), the autonegotiation bit, 0.12, must be set to a value of 0. As a result, autonegotiation must be disabled in order to manually set the speed and duplex. If the autonegotiation bit 0.12 is set to a a value of 1, bits 0.13 and 0.8 have no significance, and the link uses autonegotiation to determine the speed and duplex. When autonegotiation is disabled, the default value for duplex is half-duplex, unless the 0.8 is programmed to 1, representing full-duplex.

According to IEEE 802.3u, it is not possible to manually configure one link partner for 100 Mbps, full-duplex and still autonegotiate to full-duplex with the other link partner. Attempting to configure one link partner for 100 Mbps, full-duplex and the other link partner for autonegotiation results in a duplex mismatch. This is a result of one link partner autonegotiating and not seeing any autonegotiation parameters from the other link partner and defaulting to half-duplex.

As described above in Appendix B: Understanding How Autonegotiation Works, pulses within the FLP are used to derive code words that exchange link partner capabilities. The first code word exchanged is referred to as the base page. It informs each link partner of the message type, IEEE 802.3 or IEEE 802.9a, and a technology ability field. This technology ability field is encoded to exchange the maximum operational speed and duplex of each link partner.

Networking Professionals Connection — Featured Conversations

Related Information

• Configuring and Troubleshooting Ethernet 10/100/1000Mb Half/Full Duplex Auto-Negotiation
• LAN Product Support Pages
• LAN Switching Technology Support
• Technical Support - Cisco Systems