Autonegotiation vs MDI-X - Ethernet

[Freshman]

Most of these days, the Ethernet PHY/switch devices support Auto-MDIX and Autonegotiation.
So, when a link partner is getting connected to our PHY or a Switch, which of these two phenomenons happens first? Auto-MDIX or Autonegotiation?

My thought is that for Autonegotiation to happens, (which bascially advertises the speed and duplex setting between the partners), the TX and RX connection between the link partners should be aligned and matched first.
So, I believe Auto-MDIX happens first before Autonegotiation. Am I correct?

If the TX and RX between the PHY/Switch and the link partner is not aligned, how will the auto negotiation information be received by the link partner correctly? Because MDIX basically maps TX to RX and vice versa. So, if MDIX doesn't happen first, the auto negotiation info might not get conveyed correctly? Am I correct or missing to understand something?

[ejeffrey]

My understanding is that they way it works is that each link partner randomly starts in either configuration and they try to send link pulses to do auto negotiatiation.  If they doesn't work, each side follows a psuedo-random sequence of polarity flips until it works.

In gigabit and beyond all four pairs are used bidirectionally so there aren't dedicated rx and tx lines.

[Freshman]

Thank you for your answer. Yes, I forgot to add in my question that it was for 100BASE-T Ethernet where Tx and Rx matters.
For 1G, Tx and Rx do not matter as you say.

But, when you say, "starts in either configuration" - you mean to say, they start with MDI-X first before auto-negotiation?

[Berni]

There is no negotiation procedure. The devices just randomly flip between crossed and non crossed mode until the link comes up.

Point is that this should still work even when plugged into a device that does not support this, and it does work. The old device will stubbornly keep using the non cross configuration and so when plugged into a auto MDIX port the port will find that the cross mode works and will start using that.

There are some tricks behind it to solve the problem of two auto MDIX devices getting in sync and flip flopping between the same wrong configuration. So instead of just switching back and forth between cross and non cross, they use a random number generator to make sure that eventually the two devices end up in each in a opposite mode and the link establishes.

[Freshman]

Thank you for the insights! @Berni

Can you clarify what is happening or what does happen when you say, "link comes up"?

What should happen to establish a link?

[Berni]

Most kinds of ethernet transmit a idle signal when they have no data to send. So seeing that idle signal coming in is what tells you that there is someone talking to you on the other end of the wire. A secondary purpose to the idle signal is also to keep the clock recovery on both ends synchronized, so that when there is data to send, the clocks are instantly ready to decode it.

This is usually what network cards look for and signal to the user by turning on a status LED next to the RJ45 connector to tell you the link is up.

[Freshman]

So, the sending and receving of idle signals is what constitutes a link.

In that case, the sending and receiving should happen before the speed is determined (auto-negotiation). And for this sending and receiving to happen correctly, Tx and Rx should be present correctly. Which implies MDIX scenario happens before negotiation. Correct?

[ejeffrey]

Well it happens concurrently.  Each side is sending fast link pulses and idle symbols which contains the autonegotiation and rate information while randomly flipping their rx/tx crossover.  Only when the link is, successfully established is the auto MDI-X process complete and the current setting of the crossover switch is kept.

Its a bit complicated because there are several permissions based on what is supported by each side.  Auto negotiation is optional in 100 base TX but mandatory in 1000Base-T.  And speed auto detection is done even if auto negotiation isn't supported by both sides.

[Berni]

Yeah due to the need for backwards compatibility all of this sort of happens simultaneously.

By default the network card starts off sending out a 10Mbit ethernet idle signal since it has no idea what is on the other end, so it has to go for the lowest common denominator. However next to the idle signal extra pulses are sent to encode the network cards capability, this is how the other end can know what type of speed/standard it can use to talk to you. So once you see the idle signal you know somebody is there to talk to and the extra pulses tell you how fast they can go, at that point you can switch to the highest supported speed, declare the link being up and start sending data.

When the network card is not seeing any idle signal it just keeps constantly trying to reach out to the other side in hopes of getting a response. It could be that the cable is unplugged, the machine on the other end might be powered off, something is wrong on the line etc... One of the reasons there is no idle signal could also be that someone carelessly connected two network cards with a straight RJ45 cable, so the cards are both yelling into the same TX pair while the RX pair is quiet as both are listening there. On a older 100Mbit ethernet card the two cards would keep yelling on the TX lines and never hear back, so the link never goes up. However a smarter auto MDIX network card will occasionally randomly try swapping the TX and RX pairs, eventually the cards will get into a state where the TX pair of one card ends up going into the RX pair of the other card, suddenly they see each others the idle signal and the link goes up as normal.