Gigabit NIC...Auto Negotiate or Hard Code

[adignan]

Most documentation on CCO leans towards hard coding NIC's for servers, routers, switches, etc. I have done tests in the past with correctly negotiated 100/Full links and hard coded 100/Full links and throughput has always been better on the hard coded side. However, I came across this statement here:

About a page and a half below Ethernet/Fast Ethernet is the Gig section ....

"Gigabit Ethernet

Gigabit Ethernet (GE) has an auto-negotiation procedure (IEEE 802.3z) that is more extensive than that for 10/100 Mbps Ethernet and is used to exchange flow-control parameters, remote fault information, and duplex information (even though Catalyst series Gigabit Ethernet ports only support full-duplex mode). "

Just curious, for Servers and stuff with Gigabit NIC's is it now better to keep it set to Auto for speed and duplex?

[peter.mainwaring]

You will find that you can't hard code speed and duplex on a gig port. I've just looked at what parameters are available on a gig port on one of our 2950's and there is no DUPLEX parameter under the interface and the only sub-parameter to the SPEED parameter is NONNEGOTIATE.

Pete

[lgijssel]

Although this is in fact true, it is only true for gig-ports like the gbic-ports on a 2950/3500/3550 series. With the GBIC, they are only capable of 1000Mb and that is why there are no other parameters.

There are also ports that are 10/100/1000 capable and these can be set to either of these speeds and they can use either half or full duplex.

An example of these ports are the UTP ports on the 3550-12G (port gi0/11 & 12).

Using auto-negotiate for 10/100Mb user ports is good practice, it relieves the administrator from entering a lot of port settings and it works fine in almost all cases. Regarding server-ports etc it is my procedure to use auto if it works without problems. There can be some performance issues that can be prevented by hard coding the speed/duplex settings. It depends a lot on the age of the equipment used. There are little problems with newer equipment. These problems can all be described to sligthly different implentations of the standard (wasn't it 802.3u?) In any case, never omit to check speed & duplex settings for server & router ports running 10/100Mb.

So far, I have never seen auto negotiation go wrong between two 802,3z devices and I tend to rely on it, but only for 1000Mbit. With other speeds, it can still be required to fix the settings. One example from my own experience is a 3550 and a 3640 with an NM-1FE: No link at all until I hard-coded the speed on the 3550.

Regards,

Leo

[peter.mainwaring]

Ah yes - of course, you would have to be able to set speed/duplex on 10/100/1000 ports. We don't have any switches with 10/100/1000 ports yet, only GBIC ports, hence my previous reply.

Pete

[ckhallock]

Leo,

We have had all sorts of issues with 802.3z negotiation on our AS5850's and 6509's. Cisco's reply was to set both devices to not negotiate, and the problems cleared up. We also run Sunfire V480's and have the same issue with the 10/100/1000 ports on those and need to hard code both ends our the multi-path will not work correctly.

Chris

[rhaeppeler]

We have several Catalyst 4506 with Gigabit Ethernet boards WS-X 4548GB-RJ48 (48x10/100/1000).The server with GE-NIC`s were connected as follows:first set port to 100 MB FDX ,than change port speed to 1000.

Otherwise you will have displayed the duplex settings as auto.(show interface status)

[nsysblh]

I believe this to be a bug in the speed/duplex settings. As no Cisco equipment supports 1000/half, duplex in speed 1000 is not supposed to be able to be set. However, if you force to 10/F or 100/F and then change the speed, the duplex full stays in place. I believe it really ought to switch back to auto, or refuse to change the speed to 1000 with a duplex setting in place.

I have been forcing the speed to 1000 on all 10/100/1000 ports that are supposed to run at 1000. Otherwise, I let any machines connected auto detect. It has worked better than 10/100 auto-detection ever did.