<p dir="ltr">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.<br>
<br><br></p>
<p dir="ltr">Two features of modern switches and routes is auto negotiation and auto mdix.</p>
<p dir="ltr"><b>Auto Negotiation</b> 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.</p>

<p dir="ltr">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.</p>

<p dir="ltr">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.</p>

<p dir="ltr">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?</p>
<p dir="ltr">Well on newer switches and devices, a feature called <b>auto mdix</b> 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.</p>

<p dir="ltr">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.</p>

<p dir="ltr"><b>Long story short…</b><br></p>
<p dir="ltr">Use the right cable types when connecting devices<br>
Set duplex and speed the same on each device<br>
If you can’t swap the cable, use auto on both sides<br>
</p>
<div class="gmail_quote">On 11/05/2014 6:51 pm, "Chris Ricks" <<a href="mailto:chris.ricks@securepay.com.au">chris.ricks@securepay.com.au</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
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<br>

<br>
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.<br>

<br>
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.<br>
<br>
Humble regards,<br>
<br>
Chris<br>
_______________________________________________<br>
AusNOG mailing list<br>
<a href="mailto:AusNOG@lists.ausnog.net">AusNOG@lists.ausnog.net</a><br>
<a href="http://lists.ausnog.net/mailman/listinfo/ausnog" target="_blank">http://lists.ausnog.net/mailman/listinfo/ausnog</a><br>
</blockquote></div>