Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Auto or hard coded for 100 Full duplex
- Thread starter iptuser
- Start date
It depends is the answer unfortunately 
(
The general rule is to hard-code infrastrucure ports and anything that is static. Obviously this means all Switch-to-Switch links should be forced at the relevent Speed & Duplex. You would also assume that 'static' devices means Servers etc. Whilst I have seen (and configured) both hard-coded (100/Full) and left them to Auto-Negotiate there are always funny quirks with NIC's. Most Server NIC's (and indeed Cisco MCS Servers) have Intel-based NIC's and these are generally (in my opinion) best left at Auto-Negotiate. I have had odd problems when forcing these NIC's although most people will probably never notice.
We did some performance testing using IPERF a while ago and although IPERF doesn't perform as well under Windows as it does under UNIX/LINUX it is a reasonable tool for soak-testing links etc. We managed to set a 2-way UDP IPERF test between 2 Windows 2000 Workstations; one with an Intel-based 10/100 adapter and one with a 3Com 10/100 PCMCIA card. We got consistent (perfect) results with both cards and switch ports set to Auto Speed and Duplex. When the Intel NIC & Switch port were hard-coded to 100/Full we started to see a small packet loss consistently. We installed the Latest Intel drivers but still saw a small amount of packet loss. With the NIC & switchport reset back to Auto the packet loss stopped.
This was using Cisco Catalyst 6500 series switches in a classic 3-layer design between to access layer switches.
Unless the customer specifically requests Hard-Coding I now leave all Workstation & Server ports set to Auto-Negotiate.
Hope this helps
Andy
(The general rule is to hard-code infrastrucure ports and anything that is static. Obviously this means all Switch-to-Switch links should be forced at the relevent Speed & Duplex. You would also assume that 'static' devices means Servers etc. Whilst I have seen (and configured) both hard-coded (100/Full) and left them to Auto-Negotiate there are always funny quirks with NIC's. Most Server NIC's (and indeed Cisco MCS Servers) have Intel-based NIC's and these are generally (in my opinion) best left at Auto-Negotiate. I have had odd problems when forcing these NIC's although most people will probably never notice.
We did some performance testing using IPERF a while ago and although IPERF doesn't perform as well under Windows as it does under UNIX/LINUX it is a reasonable tool for soak-testing links etc. We managed to set a 2-way UDP IPERF test between 2 Windows 2000 Workstations; one with an Intel-based 10/100 adapter and one with a 3Com 10/100 PCMCIA card. We got consistent (perfect) results with both cards and switch ports set to Auto Speed and Duplex. When the Intel NIC & Switch port were hard-coded to 100/Full we started to see a small packet loss consistently. We installed the Latest Intel drivers but still saw a small amount of packet loss. With the NIC & switchport reset back to Auto the packet loss stopped.
This was using Cisco Catalyst 6500 series switches in a classic 3-layer design between to access layer switches.
Unless the customer specifically requests Hard-Coding I now leave all Workstation & Server ports set to Auto-Negotiate.
Hope this helps
Andy
Auto-negotiate works best for us as well. We even let switch-switch links negotiate because Ciscoworks complains about link speed/duplex miss matches if we don't. Don't know why...just works that way..
We always code older 10baseT devices to 10/half as they were never meant to(and don't)negotiate...
We always code older 10baseT devices to 10/half as they were never meant to(and don't)negotiate...
- Status
Similar threads
- Question