[AusNOG] A question for carriers on autoneg

[Stephen Carter (FirstPath)]

Agreeing with the below we find in practice, mainly as we permit BYOD & the inconsistent interpretation of std’s by vendors, sometimes requires situation configuration (which we gladly do or permit pre-configure/order per circuit). We see this as a std future proof requirement from the carrier.

Hope you all had a great weekend.

Kind Regards


Stephen Carter
FirstPath Pty Ltd





From: AusNOG [mailto:ausnog-bounces at lists.ausnog.net] On Behalf Of Colin Stubbs
Sent: Sunday, 11 May 2014 7:52 PM
To: Michael Wheeler
Cc: AusNOG at lists.ausnog.net
Subject: Re: [AusNOG] A question for carriers on autoneg


Agreed.

On GigE or above optimal modulation of signal onto the best available pairs is dependent on auto negotiation.

Anyone insisting on auto neg is ignorant or worse yet stubbornly insistent on remaining so.

--

Sent from a mobile device. Correct spelling and accurate use of grammar is unlikely to have occurred.
On 11/05/2014 7:06 pm, "Michael Wheeler" <michael at michael-wheeler.org<mailto:michael at michael-wheeler.org>> wrote:

I wrote the below a long time ago but generally autoneg in my opinion should be used everywhere. Most of the time when a link won't come up its due to the wrong cable type being used and automdix is fixing it. Changing to hard coded will disable auto mdix.


Two features of modern switches and routes is auto negotiation and auto mdix.

Auto Negotiation provides an easy way for network engineers to configure ports, allow automatic detection of speed and duplex settings. In an ideal world auto negotiation would be used on both ports, but in some cases (eg, when a network engineer only has access to one of the devices), a network engineer cannot tell if the port is statically set, or set to auto negotiation.

If a port is set statically on one device, and not the other, the auto negotiation process will detect the speed, but no the duplex. By the IEEEstandard, if duplex can’t be detected for 10M or 100M then the duplex by default is set to half. Starting at 1G the duplex is set to full.

So what ends up happening is one port set to half duplex, and the other set to full. This causes a duplex mismatch, resulting in a slow link with packet loss. This leaves two simple solutions, set both to a static setting or set both to auto.

This is all well and good, and you end up statically setting the speed and duplex. Duplex is set to full, and 100 on both sides, and suddenly the link won’t come back up. Why is this?

Well on newer switches and devices, a feature called auto mdix allows network engineers to be lazy and use straight through cables where crossover cables are needed and vice versa. Some implementations even allow use of other pairs of wire when cables are damaged.

In Cisco devices when speed and duplex are set, auto mdix is disabled. Therefore if a network engineer has statically set the speed and duplex on one side, and has used the wrong cable, the link will fail.

Long story short…

Use the right cable types when connecting devices
Set duplex and speed the same on each device
If you can’t swap the cable, use auto on both sides
On 11/05/2014 6:51 pm, "Chris Ricks" <chris.ricks at securepay.com.au<mailto:chris.ricks at securepay.com.au>> wrote:
Hi all,

First of all, this question is not one of criticism or anything of the sort - it's simply addressing an observation I've made over the last decade or so. As always, I'm happy to be pointed in the right direction for reading historical posts on this subject

Almost without exception, any time a service is handed off over CAT5e/CAT6, the port parameters are hard set and auto-negotiation disabled. Most recently this was the case on a service handed off from a newly deployed Juniper switch to an EX4200 switch on our end. In another recent experience, a carrier worked with us to get a link up and, in spite of serious attempts to deliver the link through hard-setting of link parameters, we could only get the stability required via auto-negotiation.

I'm curious as to the thinking around auto negotiation being on or off for service handoff from list participants and their reasoning around the choice.

Humble regards,

Chris
_______________________________________________
AusNOG mailing list
AusNOG at lists.ausnog.net<mailto:AusNOG at lists.ausnog.net>
http://lists.ausnog.net/mailman/listinfo/ausnog

_______________________________________________
AusNOG mailing list
AusNOG at lists.ausnog.net<mailto:AusNOG at lists.ausnog.net>
http://lists.ausnog.net/mailman/listinfo/ausnog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20140511/de734efa/attachment.html>