Auto-MDIX, Automatic-Medium Dependent Interface crossover(X), is a feature that eliminates the need for a crossover cable when connecting two similar (OSI Layer) ports together. It is enabled by default on most switches. This works great for infrastructure links where you interconnect two switches, but it's not typically needed on edge/user ports. If you disable Auto-MDIX on user ports, when those two ports are accidentally connected together, they won't get link. It is disabled with the interface command:
interface FastEthernet0/1
no mdix auto
You can verify its status by looking at the controller:
3560-1#show controllers ethernet-controller FastEthernet 0/1 phy | inc MDIX
Auto-MDIX : Off [AdminState=0 Flags=0x00002248]
Very Creative
ReplyDeleteGreat idea James. I've primarily relied on BPDU guard in the past.
ReplyDeleteI did some tests in my lab and played with MDIX a bit. At first I have connected two switches with a straight-through cable and then a computer with a crossover cable.
But it seems like it isn't possible to find out in software, if the switch port is performing MDIX or not. Neither "sh controllers ethernet-controller" nor "sh int fa0/1 transceiver properties" tells you the real operational status of MDIX. You only see that MDIX is off, when you have turned it off manually and in that case one should know that it's off ;-)
Did you perform some tests on that?
It would be at least useful to know if MDIX is used on a switch port, where a workstation/server was somehow connected with a crossover cable, before you turn it off on all ports. But that's just a very rare use case. And you should have a serious conversation with the server admins, when they are using crossover cables to connect a server to a switch :D
Best regards,
Jochen
>where a workstation/server was
ReplyDelete>somehow connected with a crossover
>cable, before you turn it off on all ports.
Most (newer) end device NICs also support Auto-MDIX. If a server is connected with a crossover when you disable it, the server port may bounce but come back online because it's Auto-MDIX kicked in.
>Did you perform some tests on that?
I will test it out tomorrow and report back.
Also keep in mind that Auto-MDIX is tied to autonegotiation. If you hard code the speed and duplex, you're disabling Auto-MDIX.
>I will test it out tomorrow and report back.
ReplyDeleteI was unable to find a command that shows if it's currently being used.
>Most (newer) end device NICs also support Auto-MDIX. If a server
ReplyDelete>is connected with a crossover when you disable it, the server
>port may bounce but come back online because it's Auto-MDIX kicked in.
You are right. My laptop has a Intel Pro 1000 pl (82573L) nic, which supports MDIX. That's why the link always came up in my tests, no matter which cables I have used :D
>...
> I was unable to find a command that shows if it's currently being used.
Me too
I had to fix a very issue concerning this yesterday. One of our engineers configured a 3560-8 as a CPE device.
ReplyDeleteThe particular carrier requires a hard coding of 10-full. It also requires a cross-over cable if connecting a router, and a straight cable if connecting a switch.
It seems to me that all they tried was the cross-over cable. When they hard-coded the port to 10-full, link stayed down. When sticking it on auto the port came up, but only at half-duplex.
They then ran off to the carrier to log the fault.
Of course what happened here is they had the wrong cable. As soon as they hard-coded the link, auto-mdix turns off causing the link to stay down. When it was on auto, auto-mdix was on and the link came up but at half-duplex.
So, changed the cable to straight and hard-coded. Link is now 10-full.