Solved: Manually set 100/Full or Auto

laichenkang · ‎07-23-2008

Any good reasons to manually set 100/Full?

Any bad reasons to set auto?

Mark Yeates · ‎07-23-2008

I usually hard code the speed & duplex settings on critical servers, and uplinks to switches/routers or other important services. Sometimes there are times when autonegotiation does not always work, or a desired setting is needed. I always use auto for all the PC's, printers, IP phones... etc. There really aren't any bad reasons to use auto... except for the occasional stubborn NIC that negotiates to 10/half. It reduces the added overhead of configuring the settings on the switches and end devices.

Mark

View solution in original post

Mark Yeates · ‎07-23-2008

I usually hard code the speed & duplex settings on critical servers, and uplinks to switches/routers or other important services. Sometimes there are times when autonegotiation does not always work, or a desired setting is needed. I always use auto for all the PC's, printers, IP phones... etc. There really aren't any bad reasons to use auto... except for the occasional stubborn NIC that negotiates to 10/half. It reduces the added overhead of configuring the settings on the switches and end devices.

Mark

laichenkang · ‎07-23-2008

Thank you for the reply. I always manually set 100/Full but could not find a good reason to.

Mark Yeates · ‎07-23-2008

It usually comes down to personal preference, and the size of the network to go with manual settings. It can be a tedious task if you have hundreds of end user devices.

Thanks for the rating,

Mark

glen.grant · ‎07-23-2008

Either way just remember both ends "must" match , if you hardcode the switchport to 100/full then the server or client nic "must" be hardcoded also cannot be set as auto . This is the major reason to leave as auto . It is not feasible to hardcode all switchports if you have to deal with a large number users . Most nics will auto fine now with the exception of an occasional SUN server.

a.whiting · ‎07-24-2008

Hi,

From experience I've found that "version 1" bundled NIC drivers in new servers sometimes don't negotiate reliably; fixing-up these port-pairs is then needed. It does become a pain when there are lots of them, though! It's worth pointing out to your server team that they should be block-pointing their NIC drivers at least once a year; this usually cures the problems and makes for simple admin going forwards.

Regards,

Andy.

DWAM_2 · ‎07-24-2008

Hello,

Cisco's Position :

http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00800a7af0.shtml#auto_neg_valid

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.

I follow the first reply from Mark

Best regards.

andrew.butterworth · ‎07-24-2008

This old debate.... :o)

Just to add to the already valuable responses. I have had occasions (quite recently as well with recent P4 hardware) where a hard-coded link (100/Full) between a switch and a server has errored. Usually very slightly, however it was noticable in the interface counters. I checked the settings on the switchport and the hosts as well as cleared the switch counters to account for the boot-up of the servers where the NIC will initially be at Auto until the OS has initialised the driver. Still the errors incremented. At the time we also installed the latest available drivers (Intel PRO/100) and still the errors were incrmenting.

We resolved the issue by changing the switchport and the server back to Auto. After checking several days later all the counters were clean. This was on several different HP servers and on a couple of sites, however with the subsequent sites we quickly reverted to Auto without much troubleshooting.

A bit weird and all I could put it down to was either NIC drivers or a bug in the IOS we were using. I never found either though and the resolution of using Auto was good enough for me.

With 10/100/1000 copper NIC's you don't usually get the option of forcing 1Gbps and have to leave them at auto don't you?. Which is likely to be the majority of servers now anyway.

Andy

andrew.prince · ‎07-24-2008

And just to add one little important ditty!!! In the world of switches that now support MDIX on the ports (no need for a x-over cable anymore from switch to switch etc...aahh the joy) the port MUST be set to auto for the MDIX to work - if you manually set the speed and duplex it will not work!