Auto Negotiating or Static Speed?

Only when it doesn't work... :-)

Autonegotiation is a mandatory part of the 1000base-blah standards so for GigE I wouldn't think of anything else[1]. For 10/100 these days I'd default to auto but check that things worked and stayed working - we still have a few combinations where auto is flakey but mostly it works fine.

Sam

[1] But see comments in several earlier messages about connecting very early GigE kit (e.g. Cisco 12000 series routers) which don't negotiate.

I think we are getting mixed up again. Please see the topic 'turning off auto-negotiation on gigabit interface'. There is 'auto- negotiation' (with the dash) and there is autonegotiation. The latter is required on gigabit, but is not the same as speed/duplex auto- negotiation. It is more for flow control and other parameters, and is part of the gig standard.

Auto-negotiation for speed and duplex is not required, and depends on the vendor and the NIC. I have many boxes that don't even offer 1000/ full as a hard-coded option, therefore we must go auto/auto on both sides to ensure it works correctly. However, for boxes like Sun T2000's for Oracle RAC Clusters, Oracle requires (at least in documentation) hard-coding to gigabit full on both sides. This works great. Regardless of what you do, make sure you match on both sides, and yes auto/auto works a helluva lot better now than it did in the past, and for gig, its even better because gigabit connections do not have 'half-duplex'.

Here is the link to the original post referenced above that has links to explain all of this in depth.

I don't think that hyphen makes a useful distinction. On

10/100/1000base-T[X] capable interfaces there has to be the ability to negotiate speed and duplex (and flow control). On fibre-based 1000base-xX or SFP/GBIC 1000base-T interfaces which only run at a fixed speed there's no need for speed negotiation, and it's difficult to imagine a useful setup which isn't full duplex, but negotiation of flow control and other parameters is still required in the standard.

And that post contains a link to which has a very handy table of what works.

Sam

Yeah, I've never been fully sure either. All I know is that we have some boxes that require 1000/full, and others that only support auto/ auto. Very occasionally I get a problem where one is configured and it should be the other, but not often. And Oracle (at least according to the DB gurus we have) absolutely requires gigabit full. Of course they also require private vlans for RAC and GPFS between DB servers, when crossovers will work the same, and go as far as to say they will not support a cluster if crossovers are used. I completely understand why you need private-vlans for clusters of more than 2 boxes (can't have a 3-way crossover obviously), but never really made sense to me, especially when there is no way for them to tell that a crossover is even being used except perhaps by scrutinizing the macs.

Andy,

• Usually 10 Mbps uses Half Duplex. I'm not aware of any official/standard setup, which uses 10-Full.

• 100 Mbps connection uses the following logic: * If both sides are able to negotiate (both sides set to Auto), and both are capable of 100-Full, the connection will be in Full Duplex. * If one side fails to negotiate (set to fixed), then another side will fallback to 100-Half no matter what another side set. In most cases it will bring a "Duplex Mismatch" state, which will affect a performance. * If both sides set to fixed (for example, both set to 100-Full, the connection will be in Full Duplex.

• 1000 Mbps (Gigabit) is not capable of Half Duplex, so, it either works in Full Duplex, or does not work at all.

Duplex negotiation happens in a first moment, when device is connected to the switch port, and after that has no impact on performance (unless there is a Duplex Mismatch).

Good luck,

Mike CCNP, CCDP, CCSP, Cisco Voice, MCSE W2K, MCSE+I, Security+, etc. CCIE R&S (in progress), CCIE Voice (in progress)

------ Headset Adapters for Cisco IP Phones

Coming back to this after a pause.

The ones that require manual setting are either very old or way out of spec!

Require in the sense of "won't work efficiently without it", "Oracle s/w refuses to work if it detects an out-of-spec interface" or "Oracle Inc won't support a system with an out-of-spec interface"? [1]

Ah, OK. But for the umpteenth time, there is no need for a crossover cable for GigE. Perhaps Oracle know this and are just trying to keep your network sane. :-)

How would could they tell even using the MACs?

Sam

[1] I'm remembering a DEC engineer coming into our machine room and saying "we can't support that system while it's connected to black thin ethernet cable". He eventually explained that official RG58U had a grey sheath. RG58U-type or even RG58U-spec cable could be black but since they weren't going to do measurements on the cable (or accept ours) we had to change the cable for grey. They never asked to see all the rest of our cable runs and we never found out whether we could get grey, non-RG58U cables.

Wh-wh-what?! The shared bus 10Mbps ethernets (10base-5, 10base-2 and

10base-T with repeaters) are inherently half duplex, but as soon as you use 10base-T with switches you get full duplex. Perfectly official and standard!

Not quite. If both sides are set to fixed then they will operate in the state they are set to. If the duplex settings match, then good; if not then there's a duplex mismatch.

That's not true. The standard [1] includes full and half duplex flags in the negotiation, and whilst I don't suppose anyone makes a

1000base-whatever repeater, the standard allows for them and a repeater is inherently half duplex.

It may have an effect if HD is negotiated or assumed and the bandwidth is therefore lower than it would have been in FD.

Sam

[1]

I have not read these in detail however this seems to have everything but is a bit complex.

"Autonegotiation Valid Configuration Table" Looks ok.

And here is a useless one :- )

comp.dcom.lans.ethernet will have had a bit on this.

Search for [Seifert duplex] and you will get some sense. I believe that Mr Seifert wrote a lot of the original 802.3 and many other 802.3s and he writes with a rare clarity.

OK, but it maintains the fiction that you need a crossover cable for

1000base-T. I haven't yet come across any sensible explanation for why people say that.

"Autonegotiation Valid Configuration Table"

Yep, that's been mentioned already.

Succinct... :-)

I'll look out for that.

Sam