Switch / Server - speed / duplex

Hi,

I had a debate with some people at wok on the effects of setting the speed / duplex at the switch, as opposed to auto negotiate. If for example, the switch interface is set to 100Mb/Full Duplex that is the only speed the the node/s connected on that port can connect at? Not

10mb/Half duplex, not 100mb/Half Duplex etc etc. Is this correct?

Also if someone could provide a link to where this is documented it would be appreciated...

Thanks in Advance

R.

Reply to
Russ
Loading thread data ...

Speed settings must match for the link to come up but duplex mismatches will cause collisions. Duplex mismatches can go unnoticed if the link is not under much load but will make it impossible to get much throughput.

I'm a Cisco 'groupie' so I'll direct you to this explanation.

formatting link
BernieM

Reply to
BernieM

My boilerplate on how 100BT autonegotiation is supposed to work:

How 100Base-T Autoneg is supposed to work:

When both sides of the link are set to autoneg, they will "negotiate" the duplex setting and select full-duplex if both sides can do full-duplex.

If one side is hardcoded and not using autoneg, the autoneg process will "fail" and the side trying to autoneg is required by spec to use half-duplex mode.

If one side is using half-duplex, and the other is using full-duplex, sorrow and woe is the usual result.

So, the following table shows what will happen given various settings on each side:

Auto Half Full

Auto Happiness Lucky Sorrow

Half Lucky Happiness Sorrow

Full Sorrow Sorrow Happiness

Happiness means that there is a good shot of everything going well. Lucky means that things will likely go well, but not because you did anything correctly :) Sorrow means that there _will_ be a duplex mis-match.

When there is a duplex mismatch, on the side running half-duplex you will see various errors and probably a number of _LATE_ collisions ("normal" collisions don't count here). On the side running full-duplex you will see things like FCS errors. Note that those errors are not necessarily conclusive, they are simply indicators.

Further, it is important to keep in mind that a "clean" ping (or the like - eg "linkloop" or default netperf TCP_RR) test result is inconclusive here - a duplex mismatch causes lost traffic _only_ when both sides of the link try to speak at the same time. A typical ping test, being synchronous, one at a time request/response, never tries to have both sides talking at the same time.

Finally, when/if you migrate to 1000Base-T, everything has to be set to auto-neg anyway.

Reply to
Rick Jones

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.