cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Bookmark
|
Subscribe
|
3689
Views
5
Helpful
10
Replies

Question about auto-negotiation

Jmorgan1413_2
Level 1
Level 1

Hi all,

Let me preface this by saying that I'm pretty sure this is something that wouldn't stump most people here but, while I am fairly handy with switches, I am by no means an expert.

I have 2 switches that I am connectiong together.

One is an older WS-C2950-24 switch and the other is a newer WS-C2960-24TT-L switch.

I am using the Fa0/1 port on the 2950 and connecting it to the Gi0/2 port on the 2960.

The problem I am running into is that I can not hard set the Gi0/2 interface on the 2960 to 100/Full.  When I do this I lose the connection to the 2950, which is also set to 100/Full.  If I set both the interfaces to AUTO they will negotiate at 100 Full, but setting them both to 100/Full breaks the connection.

I guess what I'd like to know is if this is normal and has to do with the Gigait interface.  Is there a way I can get this to work?  Or should I just give up and let it autonegotiate and call it good?  Any reason not to let it autonegotiate?

Thanks,

John. 

2 Accepted Solutions

Accepted Solutions

Leo Laohoo
Hall of Fame
Hall of Fame

I don't understand why you want to do this since, as you stated, if you set both side to AUTO the ports auto-negotiate themselves correctly to 100/Full. 

View solution in original post

Hi John,

When both speed and duplex are configured statically on an interface, the autocross (auto-MDIX) function is deactivated. Perhaps this is what you are experiencing here: if you are using a straight-through cable to connect the 2950 and 2960, statically configuring both speed and duplex will deactivate the auto-MDIX feature on the 2960 and as a result, the link will not come up. Using crossover cable should probably make the link work correctly.

I typically try to make my switch to switch and switch to server connections  forced.

If you do that, you must make sure that the speed and duplex is configured statically and identically on both ends of the link, and you must use a proper type of cable as the auto-MDIX may be deactivated in these cases.

 I have had people tell me that there is some overhead inherent in autonegotiation that can negatively impact the connection.

Early implementations of autonegotiation were not reliable (none of new technologies are). However, it is not the case anymore, fortunately. Also, waiting for the autonegoiation to take place after a link is connected may add some tens of milliseconds to the link-up transition. If you are hunting for milliseconds, this may be a good point, otherwise, the saved time is negligible.

I've been told that autonegotion is not a one-time only thing - that the  connection keeps on negotiating the whole time it's up.  

Not entirely true. On 10 Mbps Ethernet, the negotiation can be indeed considered to take place continuously, as the transceivers are expecting to see a normal link pulse (NLP) roughly each 16 ms. On faster Ethernets, the autonegotiation takes place only at the link initialization phase. After the link is initialized, the augonegotiation is not performed anymore. Instead, the transceivers keep synchronized by sending so-called IDLE symbols whenever there is no data to send.

If the advice of people who do this much more than I do is to let it autonegotiate, then that's what I'll do.

That would be my personal recommendation. Using autonegotiation should be safe in most cases and should save you quite a lot of trouble figuring out similar issues.

Best regards,

Peter

View solution in original post

10 Replies 10

Leo Laohoo
Hall of Fame
Hall of Fame

I don't understand why you want to do this since, as you stated, if you set both side to AUTO the ports auto-negotiate themselves correctly to 100/Full. 

I actually think it may be more of a "because it's there" type thing.  I can get stubborn about certain things - especially when they don't make sense.

I'm not sure why since it autonegotiates at 100/full, I can't just set it that way.  I typically try to make my switch to switch and switch to server connections  forced.  I have had people tell me that there is some overhead inherent in autonegotiation that can negatively impact the connection.  I have no idea if this is true or not and I don't think I've ever seen any proof of this.

I've been told that autonegotion is not a one-time only thing - that the connection keeps on negotiating the whole time it's up. 

If the advice of people who do this much more than I do is to let it autonegotiate, then that's what I'll do.  Is there any advantage to forcing the connection versus letting it autonegotiate? 

Thanks for taking the time to answer.

  The answer is the 2960 has auto mdix capability , auto mdix will only function with the ports set as auto/auto . If you hardcode the ports  the port will go down and thats normal  .   If you want to hardcode then turn off the auto mdix capabiloity oj that port and it should let you hardcode.

Hi Glen,

How can I see via CLI that mdix has performed its task(when between 2 switches was used straight-through cable instead of cross-over cable)?

--

Dimitry

              If the line comes up on a straight thru then auto mdix did its job , otherwise you need a crossover cable between switches in order to get the line up . 

Another words...

I can't find out the type of cable between 2 switches(speed:auto, mdix: auto) remotely.  I need to ask someone to check it on a site.  Ok. Thank you.

--

Dimitry

Hi John,

When both speed and duplex are configured statically on an interface, the autocross (auto-MDIX) function is deactivated. Perhaps this is what you are experiencing here: if you are using a straight-through cable to connect the 2950 and 2960, statically configuring both speed and duplex will deactivate the auto-MDIX feature on the 2960 and as a result, the link will not come up. Using crossover cable should probably make the link work correctly.

I typically try to make my switch to switch and switch to server connections  forced.

If you do that, you must make sure that the speed and duplex is configured statically and identically on both ends of the link, and you must use a proper type of cable as the auto-MDIX may be deactivated in these cases.

 I have had people tell me that there is some overhead inherent in autonegotiation that can negatively impact the connection.

Early implementations of autonegotiation were not reliable (none of new technologies are). However, it is not the case anymore, fortunately. Also, waiting for the autonegoiation to take place after a link is connected may add some tens of milliseconds to the link-up transition. If you are hunting for milliseconds, this may be a good point, otherwise, the saved time is negligible.

I've been told that autonegotion is not a one-time only thing - that the  connection keeps on negotiating the whole time it's up.  

Not entirely true. On 10 Mbps Ethernet, the negotiation can be indeed considered to take place continuously, as the transceivers are expecting to see a normal link pulse (NLP) roughly each 16 ms. On faster Ethernets, the autonegotiation takes place only at the link initialization phase. After the link is initialized, the augonegotiation is not performed anymore. Instead, the transceivers keep synchronized by sending so-called IDLE symbols whenever there is no data to send.

If the advice of people who do this much more than I do is to let it autonegotiate, then that's what I'll do.

That would be my personal recommendation. Using autonegotiation should be safe in most cases and should save you quite a lot of trouble figuring out similar issues.

Best regards,

Peter

Thank you Peter, Excellent answer.

I just decided to go with it and set the link to autonegotiate.  At least now the link is working and I don't have to look at the yellow exclamation marks in the Network Assistant software any more.

Really great info regarding auto negotation.  Thank you.

Hello John,

Thank you very much. I am honored.

Best regards,

Peter

Oh Boy,

Well now the Cisco Network Assistant tool is showing a duplex mismatch.  I have gone on to both switches and run a "sh int status" command and the connected ports on both switches both show "trunk a-full a-100".  I have looked at the configs of both ports and the only config item for either is the "description" entry.  So I know the ports are not configured for any speed or duplex settings.

The funny thing is that when I look at the port "runtime status" in the Network Assistant software, it also shows each port as operating at full 100.  The only place I am getting any indication of a problem is on the topology view and I'm seeing a big yellow exclamation mark on the link between the two switches.

I did notice that the Auto MDIX is showing as enabled on the 2960 switch.  This is not an option on the 2950 switch.  I assume this means that there is a straight through cable connecting these ports.  Which means I dorked it up when I installed the switches.  Which wouldn't be a problem if the switch was not 300 miles away.