Thanks for your exhaustive answer.

If I hard code speed 1000 duplex full on a gigabit interface and let a fastethernet interface in auto-negotiation state,

I have understood that auto fails and that auto-negotiation interface set itself at the speed of the hard coded interface.

But in this case, the fastethernet interface can not reach a speed of 1000. What does it happen so? Thanks.

Hello,

First, you have to understand that if you hardcode a port into a speed and duplex combination which the second port does not support then the link will not become active. For example, having a port hardcoded into 1000Mbit/full-duplex and connecting it to a FastEthernet or Ethernet interface will end in the link not even being brought up. The reason is that the FastEthernet or Ethernet use different signalling levels and techniques, even wires in the cable. It would be like speaking to each other with a different language. The FastEthernet or Ethernet will sense the signals sent by the Gigabit Ethernet but they will not understand them so no communication would be possible.

Second, and this might be more confusing: hardcoding both speed and duplex on a port results into autonegotiation being deactivated on some Cisco devices (not all). In other words, when you statically set a port to, say, 1000Mbit/full-duplex, it will stop sending any autonegotiation information. This is very different from sending an autonegotiation information that describes only a single permitted speed/duplex setting. Now, if a port with deactivated autonegotiation is connected to a different port that has active autonegotiation, problems arise: the second port is able to guess the speed by sensing the link coding schemes and signal levels. The duplex setting of the port, however, cannot be sensed or guessed, and so the second port will fall back into half-duplex mode. And what you get in result is a duplex mismatch: both ports run on the same speed because the second port has sensed the speed but the duplex setting of the first port was not advertised in any way so the second port remains in half duplex. This is actually quite common and unpleasant scenario.

Now, essentially by accident, I've discovered that the 3560V2 switches are different: if the ports on these switches are statically set to a particular speed and duplex, they do not deactivate the autonegotiation but they start advertising only the configured speed/duplex setting as the only supported operation mode. The second port can then adapt itself to the advertised speed and duplex.

The bottom line of this is that it can be quite confusing to remember all these facts, and the best practice is either to leave both ports at autonegotiation, or set them both statically to the same speed and duplex. Having one statically configured and the other left to autonegotiation is calling for trouble.

Best regards,

Peter

So, in my example, after fastethernet auto-negotiation interface understands that it can not

adapt the speed to the gigabit hard coded interface, the link is not established and it is not so

important which state fastethernet interface enter in. Ok?

Hello,

Quite correct. As the FastEthernet port cannot adapt itself to the speed used by the port hardcoded to the 1000Mbit/full-duplex, it will not go up and will remain instead in "disconnected" state, as if no cable was connected.

Best regards,

Peter