Auto Negotiate vs Fixed Speed and Duplex

I am having a disagreement with one of the guys here at work when it comes to setting the ethernet auto negotiate vs fixed speed and duplex. He says he was told by one of the Rockwell Network guys to ALWAYS use fixed settings (100/Full). I think that auto negotiate is a much simpler and helps eliminate mismatched settings.

We run a Cisco 3750 Core Stack with fiber to a mix of Cisco 3560 and Stratix 8000 switches. It is a pretty robust set up but we have issues with I/O failures tied to mismatched settings.

We did have a bunch of unmanaged ntron switches that I have almost completely eliminated. Some of the remaining ntron are set for 100/Full but some of the 1794-AENT modules are old enough that they don't support fixed settings, auto only.

I would just like to get some input and recommendations. Ulimately it's up to me, I just don't want to start a big fight over it.

Thanks

Pat

I was told by rockwell people to use fixed (100/full), and never have had a problem.

bmbsqd said:

I am having a disagreement with one of the guys here at work when it comes to setting the ethernet auto negotiate vs fixed speed and duplex. He says he was told by one of the Rockwell Network guys to ALWAYS use fixed settings (100/Full). I think that auto negotiate is a much simpler and helps eliminate mismatched settings.

We run a Cisco 3750 Core Stack with fiber to a mix of Cisco 3560 and Stratix 8000 switches. It is a pretty robust set up but we have issues with I/O failures tied to mismatched settings.

We did have a bunch of unmanaged ntron switches that I have almost completely eliminated. Some of the remaining ntron are set for 100/Full but some of the 1794-AENT modules are old enough that they don't support fixed settings, auto only.

I would just like to get some input and recommendations. Ulimately it's up to me, I just don't want to start a big fight over it.

Thanks

Pat

Click to expand...

IIRC, when RS first came out with Ethernet it did not work well with most routers in auto mode. I would suspect (hope) that it does now and with the newer hardware/firmware either will be fine. But I'm not a RS guy?

I've gone to multiple customer sites to fix Ethernet systems and been told the same thing: "Rockwell told me to set the ports for fixed 100/Full".

When pressed, not one of the customers could tell me the actual name or job title of the "person at Rockwell" who told them that. Some claim it was Technical Support, but they can't provide a case number. Others vaguely refer to 'Network Services' or 'Rockwell Software'.

I don't work there anymore so I've long since given up on finding out who was giving this advice.

I disagree with that advice for both technical and practical reasons.


Here's why: Autonegotiate is frequently assumed to be some sort of "auto-detection" of speed and duplex. Some vendors even refer to it as "auto-sensing".

But it's not. There's a low-level exchange of information going on between the two sides of the Ethernet link to negotiate the speed and duplex. You can read all about it on Wikipedia; the article is excellent.

When you set a device to "100/Full" and disable Auto-Negotiation, but one of the devices remains configured for Auto-Negotiate, it performs a one-sided "negotiation".

The device that is "auto-negotiating" will probably correctly detect the link speed to be 100 Mb/s.

But when it can't negotiate the duplex setting, the default that the IEEE 802.3 specification requires is that it goes to HALF duplex.

This is analogous to connecting a one-way road to a two-way highway. Collisions are inevitable.

The problem is that at first look, the link works. The Link LED's come on, and data starts flowing. PING works. HTTP works. Browsing with RSLinx is slow but works.

But in the background, error counters are incrementing furiously because the two sides of the link have a duplex mismatch. I/O connections break, then the volume of messages (and errors) is reduced, and the connection establishment messages can get back through.

This wouldn't be a problem if everyone managed their Ethernet switches carefully and knew to disable Auto-Negotiation on both the PLC module side and the Ethernet switch side.

But inevitably, somebody reconfigures the switch. Or they plug in a PC that has Auto-Negotiate configured on its Ethernet port. Or they use an unmanaged switch that can't have Auto-Negotiate disabled.

Ethernet is so fast and so good at re-trying and recovering from errors that it covers this sort of mistake up most of the time, until you really start to press it with data throughput.

[Yoda]

Errors turn to timeouts.

Timeouts turn to faults.

Faults turn to suffering.

[/Yoda]

I just got off the phone with "That Guy" from Rockwell. He admits to suggesting that we set up fixed speed and duplex but he has become more open to using auto negotiate. His claim is that there have been problems specifically with 1756-ENBT cards that have issues re-auto negotiating after powering up. Once they have a mismatch it defaults to half duplex and that is not good for your controlability.

Haveing said that he suggests that if I do go with auto negotiate to just keep an eye on the processor, ethernet cards and the switch settings to make sure everything is working as it should.

Thanks for everyones input.

Pat

I just got off the phone with "That Guy" from Rockwell.

Click to expand...

What the heck is his name?

I don't want to throw him under the bus and won't list his name here but if you want to PM me I will give you his name.

I also had a customer conflict created by "that guy" convincing my customer to not use auto negotiate. This goes back a couple of years.

A few years ago, I got deep into a diagnostic issue with several 1734-AENT modules connected to specific N-Tron switches in which Auto-Negotiate would fail under circumstances we couldn't reliably duplicate.

I imagine something similar has happened with 1756-ENBT modules, as well, at some point in the past.

And it makes sense that if that happens, you can initiate a major engineering effort to figure out exactly what the hardware and firmware and component issues are, both on the Rockwell side and on the switch vendor side, or you could give a standard troubleshooting recommendation.

There are hundreds of switch vendors.

And a bad homemade Ethernet cable presents the exact same symptoms.

So I'm not surprised that one of the stock answers is "set both the switch and the device to 100/Full".

In my experience, the circumstances that lead to duplex mismatches are very common, while the circumstances that lead to auto-negotiation failure are uncommon.

I'm certainly not the authority on the topic, nor do I speak for Rockwell Automation or pretend that I know better than the guys in the bullpen at RA Technical Support.

I just finished a FTTM course from Rockwell and the instructor (who claimed to be a tech guy before the training gig) told me that if you look at the ENBT card properties and find a lot of FTS errors or Frame Check Sequence errors (which are basically checksum errors), and Alignment errors, they can be reduced or eliminated by manually setting the port speed. This being on the ENBT card as well as any switch or device it is connected to.

So when the course was done, I returned to work and did some investigating.

I did a PLC audit that focused on how the communications on our 86 PLC's are set up on the network and the number of errors being generated. Low and behold, the ones that were manually set up to 100/Full were FTS and Alignment error free. These PLC's were connected to managed switches on dedicated ports that were set up to 100/Full as well.

Those set up at 100/Full with the managed switch set to auto were seeing very large numbers of FCS and Alignment errors. And the same went for those set to auto negotiate.

With the help from IT, I'm doing a test on a few that have the errors to see if setting all port speeds used by the test PLC's and the switches they are tied to at 100/Full will reduce or eliminate the number of FCS and Alignment errors.

Just my observation for what it's worth.

Thanks to the OP for starting this topic. It really can be an important one if you are using Produced/Consumed tags between a large number of PLC's over managed switches for control or for data collection.

I took a Rockwell Automation class for Ethernet IP (forget the exact title) just a couple of weeks ago, and they are still teaching people that auto-negotiate should be turned off, that it's meant for the more dynamic office type of networks...

I can get the guy's name to you, Ken, if you'd like.

I always believed that auto-negotiation was a one-time activity at the onset of a communication connection.

I therefore believed that if communication continued uninterrupted, then the settings remained unchanged, i.e. auto-negotiation was never instigated again.

It perturbs me, therefore, that auto-negotiation is being hauled over the coals, when in fact it is most likely other communications issues that are the culprit of FCS and Alignment issues.

I may be mistaken, of course, not having an in-depth knowledge of the technology, but it would be wrong to blame auto-negotiation if comms is dropping for other reasons.

OkiePC said:

I took a Rockwell Automation class for Ethernet IP (forget the exact title) just a couple of weeks ago, and they are still teaching people that auto-negotiate should be turned off, that it's meant for the more dynamic office type of networks...

Click to expand...

Don't you just love technical folklore?

daba said:

It perturbs me, therefore, that auto-negotiation is being hauled over the coals,

Click to expand...

It works fine for everyone else.

It works fine for everyone else.

Click to expand...

Everyone except this member DGillen?

Those set up at 100/Full with the managed switch set to auto were seeing very large numbers of FCS and Alignment errors. And the same went for those set to auto negotiate.

Click to expand...

We have been having issues with ethernet comms localized to a managed rail switch for a bout two days.

Yesterday, the port details in the browser for the switch show a MAC ID belonging to a PV700+ connected at half duplex to a switch port set to auto.