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.



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

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

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

May 29, 2007

Frustration II: Cables and Passwords and Redistribution – Oh My!

Filed under: Cabling,Home Lab,IOS — cciepursuit @ 10:38 am

Since Saturday promised to be a very slow workday (beginning of a 3-day holiday weekend in the US) I decided that I would do some hardcore labbing.  In the end I put in 8 hours of lab time, but only completed two (small) labs. 

After a morning of frustration, I got started on some redistribution labs.  I finished two of the labs and was very happy with my results.  I’m finally getting my head around mutual redistribution and am pretty proficient with route-maps.  My configurations matched the answers and my show commands returned the expected results except for one subnet not getting redistributed from BGP into OSPF.  I poured through my configurations expecting to find an error there.  Everything looked good and there was no reason for this subnet not to be redistributed successfully while two other were unless I had mucked up a line in my access-list.  After double and triple-checking the configs I finally noticed that the FastEthernet port to the subnet was “up and down”.

That day I had finally added the last two devices to my lab by connecting two 3560 switches.  I made one of the new 3560s my sw1 to match the Internetwork Expert lab design.  I had assumed that the switches’ configurations were wiped clean.  Wrong.  When I consoled into the devices, I found that these were switches that were reclaimed when we bought out another company.  I tried every known combination of user/pass to get into the boxes.  No dice.  I decided to just go ahead and do a password recovery on the two devices using the following Cisco document:

Cisco 3560 – Recovering a Lost or Forgotten Password

This worked like a charm, except that the documentation states:

Step 4   Press the Mode button, and at the same time, reconnect the power cord to the switch.

You can release the Mode button a second or two after the LED above port 1 turns off. Several lines of information about the software appear with instructions, informing you if the password recovery procedure has been disabled or not.

The LED above port 1 never lit for me.  I discovered that once the System light stopped flashing, I could release the Mode button and be dropped into password recovery mode.

I successfully reset the enable secret password and wiped the two switches clean.  I still could not get the FastEthernet port to come up.  Finally, I swapped Ethernet cables with a known good cable and voila! the connection came up.  A bad cable!?!  Arrgghhhh!!!!

I was disappointed that I only managed to complete two short labs in 8 hours, but I am getting a lot of troubleshooting experience. 🙂

April 5, 2007

Read The Fine Print

Filed under: Cabling,eBay,Home Lab — cciepursuit @ 5:28 pm

So I’ve built my CCIE lab at work (more on that later) and the only thing that I’m missing is an octal cable so that I can use one of the routers as an access server.  I went on eBay and found a number of octal cables for sale.  Most of them ran about $30 including shipping (and most were shipping from Hong Kong).  I ended up using “Buy It Now” to nab one for $25 with free shipping.

Unfortunately I did not read the auction description closely at all.  The picture showed an octal cable with eight RJ45 ends, but the auction stated (in multiple locations) that this was an octal cable with DB25 ends.

The cable arrived today.  After checking the auction and confirming that I am a bonehead, I was left with three options:

1) Order a new octal cable
2) Order 8 DB25 to RJ45 adapters
3) Try to convert the DB25 cables to RJ45s

The downsides to each option are:

1) At least $25 more dollars and a week to receive.
2) Cost comes to about $30.  It would be cheaper to buy an RJ45 octal cable.
3) By hacking apart the DB25 cable, I might end up with need to go with option 1 and not being able to resell the DB25 cable.

The most sensible option is to simply order/bid on another octal cable and to try to resell the DB25 cable.  This would only end up costing me a few extra bucks, some time, and a little bit of pride.

Since option 2 is not financially prudent and would not net me any extra time, which just leaves me pondering option 3.  After last weekend’s cable building party (more on that later) I am pretty confident in my abilities to convert these cables.  I just need to find out if this is possible and if there is a pin out available.  I am currently searching the Internet for any descriptions of how to convert the DB25 connectors to RJ45s.

Blog at