CCIE Pursuit Blog

July 8, 2007

Switch Cabling And Auto-MDIX

Filed under: Cabling,Home Lab,IOS,Switching — cciepursuit @ 6:28 am

This thread in GroupStudy about using Auto-MDIX to enable the use of straight-through cables between switches reminded me of a real world issue involving the same technology.  At my previous job, there was a “senior” engineer who supported a large site.  She was having an issue with hard-setting the speed and duplex of an uplink port (I think it was a “stack” of 2950s) on a Cisco switch.  While most of our uplinks were fiber, this one was copper (it was a small office that just needed to connect to the MDF on the floor directly above it).  Our standard was to use a cross-over cable for any switch-to-switch connections and to hard-set the speed and duplex on both sides of the connection.  She was having a problem with setting the speed and duplex.  If she hard-set these settings on both sides of the link, then the link would go down.  If she let one side of the link auto-negotiate, the link would come up, but the connection would not meet our standards.  I eventually got dragged into this issue.

Looking at the switch settings, I noticed something odd: auto-MDIX was enabled (globally) on both switches.  Our standard was to disable this on every switch.  This gave us a little protection from users making unauthorized switch-to-switch connections (accidentally or on purpose) as cross-over cables were not generally available to end users (most wouldn’t know what a cross-over cable was).  I asked the engineer if she was using a cross-over cable on the uplink. 

Her response: “That’s not the problem.  You can use a straight-through cable.” 

“Sure you CAN, but our standard is to use crossover cables because….blah, blah, blah.”

Long story shorter: she refused to adhere to our standards and use a cross-over cable and I refused to waste my time on the issue.  I wasn’t sure that the cabling was the issue, but if disabling auto-MDIX and using the proper cabling did not fix the issue then we could at least take those elements out of the equation. 

She muddled on for a couple more days (she couldn’t be bothered to open a TAC case) and the problem remained.  Finally our top-level LAN guy looked into the issue.  He found the answer after a few minutes on Cisco’s web site (this is specific to the 3560):

Configuring Auto-MDIX on an Interface
When automatic medium-dependent interface crossover (auto-MDIX) is enabled on an interface, the interface automatically detects the required cable connection type (straight through or crossover) and configures the connection appropriately. When connecting switches without the auto-MDIX feature, you must use straight-through cables to connect to devices such as servers, workstations, or routers and crossover cables to connect to other switches or repeaters. With auto-MDIX enabled, you can use either type of cable to connect to other devices, and the interface automatically corrects for any incorrect cabling. For more information about cabling requirements, see the hardware installation guide.

Auto-MDIX is enabled by default. When you enable auto-MDIX, you must also set the interface speed and duplex to auto so that the feature operates correctly. Auto-MDIX is supported on all 10/100 and 10/100/1000-Mbps interfaces and on 10/100/1000BASE-TX small form-factor pluggable (SFP)-module interfaces. It is not supported on 1000BASE-SX or -LX SFP module interfaces.

So you can use a straight through cable to connect two switches, but you then cannot explicitly set the speed and duplex.  The engineer was told that the solution to her problem was to disable auto-MDIX and use a cross-over cable.  Where had I heard that before?  :-)

To be fair, I wasn’t aware of the auto-MDIX needing auto-negotiation issue, BUT whenever you are troubleshooting a problem you want to minimize any deviations from known working configurations to eliminate unnecessary variables.  I think that I remember reading that auto-MDIX uses the same protocol as auto-negotiation and that’s why both need to be enabled.  I’m not positive about that though.

This table is pretty interesting.  I assume that “correct cabling” means a cross-over cable and “incorrect cabling” means a straight-through cable.

Local Side Auto-MDIX Remote Side Auto-MDIX With Correct Cabling With Incorrect Cabling
On On Link up Link up
On Off Link up Link up
Off On Link up Link up
Off Off Link up Link down

You can refer to the table below, but it’s pretty easy to determine if a link will be up or not: at least one side needs to have auto-MDIX enabled along with auto-negotiation of speed and duplex, otherwise the link will be down.

sw1

sw2

MDIX Speed/Duplex MDIX Speed/Duplex Link Status
on auto on auto up
on auto on hard-set up
on auto off auto up
on auto off hard-set up
on hard-set on auto up
on hard-set on hard-set down
on hard-set off auto down
on hard-set off hard-set down
off auto on auto up
off auto on hard-set down
off auto off auto down
off auto off hard-set down
off hard-set on auto up
off hard-set on hard-set down
off hard-set off auto up
off hard-set off hard-set down

This makes sense because you need at least one side to be able to logically switch the pinouts of a straight-through cable to emulate a cross-over cable.  Hard-setting the speed or duplex disables the auto-negotiation protocol (which auto-MDIX must utilize as well) which effectively disables auto-MDIX:

Note: The only command that I know of that will show the auto-MDIX state of an interface (other than looking at the running-configuration of the interface) is the rather verbose “show controllers ethernet-controller fax/x phy | include MDIX” command.

Note: The default setting for switch ports is to have auto-MDIX enabled.  This is a pretty recent change though.  IOS versions prior to 12.2(20)SE will use the default of “no mdix auto”.

“mdix auto” is the default, so it does not show in the running-configuration:
sw2(config)#do sh run int fa0/32
Building configuration…
Current configuration : 34 bytes
!
interface FastEthernet0/32
end

We can verify that auto-MDIX is on for this interface:
sw2(config)#do sh controll eth fa0/32 phy | i MD
 Auto-MDIX                             :  On   [AdminState=1   Flags=0x00052248]

Let’s hard-set the speed and see what happens to auto-MDIX:
sw2(config)#int fa0/32
sw2(config-if)#speed 100
sw2(config-if)#do sh control eth fa0/32 phy | i MD
 Auto-MDIX                             :  Off   [AdminState=1   Flags=0x00010A48]

Notice that our configuration does not state that auto-MDIX has been disabled:
sw2(config-if)#do sh run int fa0/32
Building configuration…

Current configuration : 45 bytes
!
interface FastEthernet0/32 
 speed 100
end

This verifies that hard-setting the speed and/or duplex turns off auto-MDIX for the interface.

Note: I did test to see if DTP was effected by auto-MDIX.  It was not.  As long as the link was up, DTP could work it’s trunking magic.

So the long and the short of it is: you can use straight-through cables to connect two Cisco switches as long as you are willing to sacrifice the ability to hard-set the speed and/or duplex on both sides of the link.


Cisco Documentation:

show controllers ethernet-controllerConfiguring Auto-MDIX on an Interface (3560)

mdix auto

About these ads

10 Comments »

  1. [...] can’t get with “show interface fa0/3 status”, except for the MDIX information.  In a previous post, I wrote: Note: The only command that I know of that will show the auto-MDIX state of an interface [...]

    Pingback by show interfaces transceiver properties « CCIE Pursuit — October 17, 2007 @ 1:10 pm | Reply

  2. Is this MDIX problem not another good reason to leave speed and duplex to auto/auto? Why is it a sacrifice to not be able to hard set ports?

    In some years of network engineering I’ve had at least 5 times as many faults due to ends being mismatched – when in fact if everything was set to auto or reset to auto/auto, it all comes right.

    (The only devices which I have come across in recent times which do not work with auto speed/duplex are APC UPS management cards but apart from that, nothing…)

    Comment by Reuben Farrelly — April 2, 2008 @ 8:28 am | Reply

  3. You’re right about auto-negotiation working most of the time, and that one of the reasons why we leave all of our end user switch ports set to auto/auto. But there are two important reasons for hard-setting server switch ports and requiring that the server owner do the same with their NIC:

    1) Auto negotiation failures. If auto-negotiation of duplex fails, it will default to half-duplex mode. A server connected at 100/half is not a happy box.

    2) Billing. In the companies I have worked for, the network team bills a “port charge”. We require that the server owners fill out business requests to specify the speed and duplex of their devices. We then hard-set the server port to that setting and require the server owners to do the same on their NIC. The port charge increases as the port speed increases. All of our datacenter switches have ports capable of 1000Mbps. We’ll often get trouble tickets about server problems only to find out that server owner has changed their NIC to 1000Mbps without requesting the port change. If we ran auto negotiation, then the port would most likely auto negotiate to 1000Mbps.

    A bit off topic: The server teams figured out a way around this process by calling the NOC and having them either hard set the port to a different speed or to set the port to auto/auto. We eventually wrote a script that runs every Wednesday at midnight that goes though all of the ports and verifies that they are set to the speed that is in the business request. If the speed is different then the script sets the port to the correct speed. This will usually “break” the server resulting in the server owner getting paged out in the wee hours of the morning. The next day we check the logging server to see who changed the speed/duplex on the switch and notify their manager. Needless to say, we’ve had a sharp decrease in NOC port reconfigurations.

    Anyhoo…I agree that there are going to be more issues with mismatches if you are not running auto/auto on every port, but implementing a corporate standard to hard set server ports is useful for the reasons above, PLUS it ends finger-pointing pretty quickly during troubleshooting.

    Comment by cciepursuit — April 2, 2008 @ 9:37 am | Reply

  4. so if auto nego if successful, switch will allow 200 Mbps download and 200 Mbps upload between two pc… am i correct?? if not the switch will only let 100 Mbps upload/download..?

    10Q

    Comment by passerby — July 17, 2008 @ 12:33 pm | Reply

  5. @passerby

    If auto neg works and the ports at either end are 100M Full Duplex, it will allow 100M both ways simultaneously. Half Duplex allows 100M one way. If you hard-code 100M/Full on either end, use a X-Over cable, this is – IMHO – the only way to fly. We have had nothing but issues with MDI-X at auto!

    Comment by Mawdo — July 30, 2008 @ 2:59 am | Reply

  6. 2950 don’t support Auto-MDIX from everything I can find.

    Comment by Kevin — November 12, 2008 @ 10:27 am | Reply

  7. @Kevin – You’re right. It turns out that the 2950s do not support Auto-MDIX. Why do you want to go and ruin a good story? :-)

    We ran 2950, 2960, 3560, and 3750(PoE) in that network. I know that these switches were not 3750s. The 3560 and 2960 switches do have Auto-MDIX support, so it must have been one of those models. They were probably 3560s as we really didn’t deploy many 2960s.

    Comment by cciepursuit — November 12, 2008 @ 10:58 am | Reply

  8. I have just run into toruble with port settings between a Cisco 7606 router and a 3750 switch. Router set to 100/full switch shows 100/half and if we set the swithc to 100/full link goes down. Iam using a gigabitethernet port on my router. I do not know the cabling on the other side. I am puzzled and the client is mad…Any comments

    Comment by don — August 28, 2009 @ 9:42 am | Reply

  9. ante todo buenos días quería pedirle a alguno del foro que si alguien tiene alguna forma sencilla de realizar un cable de red Auto-MDIX me la podría decir porque de verdad no se mucho de redes ni de conexiones gracias y disculpen la molestia

    Comment by renzo — September 5, 2009 @ 7:30 am | Reply

  10. Hi mate,

    Thank you very much for this explanation, I was looking desperatly for Cisco doc to show to an engineer refusing to swap straight cable to crossover.
    Thanks to you he changed his mind.

    Regards
    Younes

    Comment by Younes — October 11, 2009 @ 7:04 pm | Reply


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

The Rubric Theme. Create a free website or blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 109 other followers

%d bloggers like this: