[AusNOG] A question for carriers on autoneg

[Colin Stubbs]

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>
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>
> 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
>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>
>
> _______________________________________________
> AusNOG mailing list
> 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/5ee806bf/attachment.html>