Switch Cabling And Auto-MDIX
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 cannotexplicitly 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
endWe 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 100sw2(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:
No comments:
Post a Comment