I completed a session with an ISA user yesterday that reminded me just how few ISA problems really are problems with ISA Server itself. Network device configuration, name resolution, malware, etc. are all non-ISA considerations that can adversely affect your ISA server perceived performance. Today, we'll discuss a very common non-failure state that degrades ISA performance.
Most modern network devices support the process of auto-negotiation. This process occurs when the network adapter connects to the switch or hub and is analogous to your kids playing rock-paper-scissors to see who gets to choose the family game for the evening, although it’s not nearly as noisy.
Let’s first define some terms.
Speed: This defines the actual data rate for the connection. If a switch port is configured for 100 Mbps and the connected NIC is configured for 10 MbpS (or vice versa), they’ll won’t communicate at all, even though you may have a “connected” light and see “activity blinkies” on the port & adapter indicators.
Duplex: This refers to the directional “rules” that are applied to any electrical signal transmission. They are:
- Full-duplex �� both sides of the connection are able to send traffic at the same time.
- Half-duplex – both sides of the connection can send traffic, but not at the same time.
Historical note: half-duplex configuration was necessary in the bad ol’ network days of networking. The connected devices had to “cooperate” on the wire so as to avoid stepping on each other’s packets. Even on a well-constructed 10MbpS network, the maximum effective data rate rarely even approached 4MbpS because of the mandatory half-duplex network state and the amount of traffic control messages that came and went.
Auto-Negotiation: this is the process defined by the IEEE where the network devices come to agreement on what speed and duplex they use to communicate with the other.
How can auto-negotiation create incompatible NIC / switch configuration of this is so well-defined? Like unto thusly:
1. The Adapter, switch port (or both) are:
b. don’t negotiate properly (happens more often than you may think)
c. have incompatible manual speed/duplex settings (100/full vs. 100/half, for instance)
2. The network cable is faulty
When the traffic begins to flow in earnest (and I don't mean “ping host.domain.tld -t”), incompatibilities in the network configuration come into play that don't exhibit during low-traffic times. The most common scenario is a duplex mismatch between the network endpoints. This situation appears to work just fine for low traffic rates (you know; “ping host.domain.tld”), but slows to a crawl during high traffic rates, such as when your users all want to download the latest music video at the same time.
Auto-negotiation generally works well for machines that move between networks (when they communicate properly), because few mobile users either want or know how to reconfigure their adapter settings. Since your servers get relegated to a data center rack (or a "server closet" with the coats depending on your budget) and rarely if ever get relocated on the network, auto-negotiation represents an unnecessary delay in the network setup process.
In short, Avoid layer-1-induced traffic problems by ensuring the switch and the network adapter for your servers (*especially* for your ISA) are set to the most compatible mode (static settings, where possible). Your users will thank you.
Jim Harrison (ISA SE)
Not quite right.
Hard setting gig-e over copper will break things, badly.
See IEEE standard 802.3z Standard clause 37 for further details.
You're correct that this may not work every time (device "compatablility", more often than not), but my (and quite a few others') experience has demonstrated otherwise.
I run two separate Gig-E copper lab networks and every device that is capable of it operates static G/full. In fact, the connection with the upstream router is also static G/full. All this runs with no problems at L1. Yes; where we have a 100 MbpS device operating, we "dumb down" the switch port, but I've never been forced to use "auto".
I will amend my posting to include "you need to test your configuration", since incompatabilities between devices are the greatest limiting factor.
You mentioned above that "If a switch port is configured for 100 Mbps and the connected NIC is configured for 10 MbpS (or vice versa), they’ll won’t communicate at all, even though you may have a “connected” light and see “activity blinkies” on the port & adapter indicators."
I believe they will still connnected, however the speed will just be slowed down considerably. I know this from experience because I have had many routers and switches that have had ports go bad. When this happens the router generally will still send the data at 10mbps. So I am not sure if that is correct.
Yes; where we have a 100 MbpS device operating