100/1000 Mbs interface, auto- negotiation

[sarahr202]

Hi every body.

I was reading   about how 1000 -T intererface will default to full duplex.

Let say we have two swithes,sw1 and sw2

sw1

100/1000-T  interface--------------------------------------------------------------------------------------100-T   Sw2

Let say  on sw2,  duplex and speed are manually configured as:

speed 100

duplex full

Now will sw1 default to half duplex?

Thanks a lot.

[Giuseppe Larosa · Accepted solution]

Hello Sarah,

I may be wrong but my current understanding of auto-negotation is that when it is disabled we actually disable only the modulation of the pulse train with the line code capabilities 16 bit word.

However, even if FLP would be turned off completely (as it looks like in http://en.wikipedia.org/wiki/Autonegotiation ), the ethernet frames sent by neighbor would provide its real speed (10 vs 100, as I noted 1000 Mbps can be detected by the fact that there would be activity in all 4 pairs not only on two pairs).

Each ethernet frame has a 64 bits preamble that is used to synchronize to the frame (there is no framing structure with a permanent clock like in a serial interfaces)

so neighbor speed can be sensed in one way or another.

Here we have a theorical answer and an empirical answer from Reza's tests.

We could say that humility comes from experience: many times theory and practice can give different answers, and only doing a specific test the empiric answer can be found.

The test tells us about effective implementation on network devices

Be also aware that CDP is Cisco proprietary and in any case also its standard based conteurpart LLDP it is at an upper layer in the OSI stack: a CDP frame is already an ethernet frame with a specific encapsulation (using 802.2 and SNAP with a well known multicast MAC destination)

Hope to help

Giuseppe

[sarahr202]

Thanks Giuseppe  for the excellent link and answer.

You have a nice weekend.

[sarahr202]

just one thing , i want to confirm.

As the test performed by Reza  indicates  that  a 100/1000 port  defaults to full duplex when  auto negotiation was turned off on the other hand and the speed was found to be 100.  

The question why  empirical  result does not match the theory which is in our case  is IEEE 802.3ab/z. standard.  This  also indicates the cisco switch in question is not fully compliant with IEEE 802.3ab/z standard.  Had the cisco switch been fully compliant with IEEE 802.3ab/z,   it would have defaulted to half duplex .  

i understand sometimes documentation is not very cleared so  implementation of certain feature is open to interpretation by manufactures, and thus manufactures implement it differently.

For example   In  IEEE 802.3u (fast ethernet)  auto-negotiation feature was optional  and was open to interpretion. Different manufactures implemented it differently.  Then came IEEE 802.3  standard  which deals with auto-negotiation process.

In our case  what i find  mind  boggling is  why  manufactures such as Cisco  want to implement  auto-negotiation process, clearly defined in 802.3 ab/z  differently and cause unexpected results such as 10/1000-T  port  being defaulted to full duplex at  100Mbs speed.

Any comments/correction  is greatly appreciated.

Thanks and have a nice weekend.

[Giuseppe Larosa · Accepted solution]

Hello Sarah,

if your objective is to perform interoperability tests it is correct to consider Reza's results the sign of an implementation that differs from accepted standards.

>> s  why  manufactures such as Cisco  want to implement  auto-negotiation process, clearly defined in 802.3 ab/z  differently and cause unexpected results

This can be the result of a software programming error just to make an example or of a broad interpretation of standards.

With a valid service contract you could open a service request to TAC.

Current best practice for 10/100/1000 is to use autonegotiation at both sides.

  We see some times that a link to a server can negotiate at 100 Mbps or even at 10 Mbps. The way we deal with these cases is : we try to shut/unshut the port to make the two endpoints to negotiate again, if this doesn't solve we try to change a patch cable (a damaged cable can be the root cause).

Hope to help

Giuseppe