"Forcing" gigabit link operation

Finally, when/if you migrate to 1000Base-T, everything has to be set

> to auto-neg anyway.

I know Rick's words to be the truth, and yet I regularly see NIC setup interfaces that purport thier ability to "force" gigabit operation. Like this one:

formatting link
What's the deal with these control panels?

My guess is that the NICs are still autonegotiating, but restrict the bits advertised in the TAF to just the gigabit modes.

Is that correct?

Secondarily, can anyone offer perspective on why-oh-why systems/network people everywhere seem to think autonegotiation is totally unreliable?

I can count the number of times I've seen a genuine negotation failure with my fingers, and those invariably involved pre-802.3u transceivers.

OTOH, the number of links I've seen screwed up due to force-happy administrative error are myriad.

/chris

Reply to
googlegroups
Loading thread data ...

IIRC strictly speaking, autoneg is simply about duplex settings, and the speed stuff was part of the "autosensing" part of the specs, but then I don't really do Ethernet to pay my mortgage, so I'm sure I have some parts wrong.

Long ago, and far away, when autoneg was "optional" there were:

a) some devices that supported FD, but didn't do autoneg

and perhaps more to the point

b) combinations of switches and NICs that would not autoneg with one another. And either an inability or unwillingness among either the switch vendor, NIC vendor or end-user to fix or replace the kit that didn't quite work right.

and

c) people (network administrators among them) who didn't fully understand how autoneg was supposed to work and ass-u-me-d that they could leave one side at auto and hardcode the other to "force" the mode they wanted. That it happened to "work" when the "forced" side was half-duplex was most unfortunate, but required as part of the spec since autoneg was indeed optional.

Those have left a nearly indelible mark on many network administrators who at the time decided that life was implest if they hardcoded everything. And that gets repeated all the time. One of the finest examples of "You never get a second chance to make a first impression" I've come across in a while.

I've no idea if it might have been helpful or even possible for the spec to say something like "If an autoneg capable device is administratively forced to a non-autoneg setting and sees an autoneg request from the link-peer, that device is required to report an error condition and not enter an operational state.

rick jones

Reply to
Rick Jones

I've seen a few devices even "autosense" the speed incorrectly.

Unfortunately, this is still the case today with some vendors. It's getting rarer, but it's still common enough to drive admins nuts. And some vendors are _still_ making equipment that doesn't do auto at all.

Also, most of that older equipment still doesn't work right, even with the latest software, so every datacenter will have switch/NIC combos that just won't autoneg right no matter how hard you try. Forcing a few ports here and there while leaving the rest at auto is difficult to maintain; it's easier to force everything.

Very true. I think there's also a bit of:

d) people don't like leaving performance to chance when their job is on the line; why leave something as "auto" and pray that it works when you can force a setting and be sure it works?

I'd prefer the standard require that if a device is forced to a particular setting, it responded to auto-neg requests with the forced setting only instead of being silent. That'd clean up 99% of the issues I've seen.

I'd like it even better if auto-neg hadn't been optional, which would have forced the issue earlier and made it more likely the kinks would have been worked out long before products hit mass deployment.

I'd have been happiest if half-duplex had simply been disallowed starting with FastE, but I know the economic reality of switching at the time wouldn't have made that possible. Still, it'd have removed the need for auto-neg entirely: 10 meg is HDX, 100+ meg is FDX, end of story.

I just got back from a customer site where they have 80,000 switch ports all forced to 100/full; my product (which will be attached to roughly half of those ports, randomly distributed) does auto only. They went nuts when they realized the implications...

S
Reply to
Stephen Sprunk

I've seen many a case of NetWare reporting a 'negotiating' NIC as operating in FD mode and we see the Cisco switchport having negotiated FD but still showing collisions. As a general rule we've now hard coded all core switch ports (200 servers connected) for the last two years. Once the 'general rule of thumb' becomes policy it's easy to manage.

It's followed over to our migration to Gbit and we've never looked back. It's not so much that we think autonegotiation is totally unreliable but hard coding both ends significantly reduces the possibility of problems.

Having the option to hard code Gbit switchports (which generally means you can also hard code them down) allowed us to replace all 10/100 cards with

10/100/1000 and progressively migrate non-Gbit devices to Gbit.

BernieM

Reply to
BernieM

Your Cisco switchport claims to be running full-duplex mode, but is also logging colisions?

This is very surprising behavior. Did you log a bug with Cisco? What did they say?

Okay, but you might be introducing a problem. It's very easy to force all of your switch ports, especially since they're likely all under the conrol of one group, and the ports live on a small subset of equipment (the switches)... You didn't say that you positively know the operating mode of every last host transceiver in your environment.

Perhaps in your experience it reduces the possibility of problems. I explained in the OP that in my experience it greatly increases the possibility of problems. I'm guessing from Rick's post that he's seen the same thing:

rj> c) people (network administrators among them) who didn't fully rj> understand how autoneg was supposed to work and ass-u-me-d that rj> they could leave one side at auto and hardcode the other to rj> "force" the mode they wanted.

In my work, I regularly deploy equipment in other people's datacenters. I can't tell you how many times I've setup systems where the customer's switchports were running auto (often the switch had just come out of the carton), only to be called back a few months later to discover that some admin had blindly forced all port operating modes without knowing/caring what was on the other end of each cable.

When I deployed the equipment, I checked the switchports and setup a good match. When the admin changed the port settings without coordination he broke things. He was likely applying a similar "rule of thumb".

I don't understand what you're trying to say. You can plug 10/100 cards into 10/100/1000 ports (and vice versa) regardless of your ability to administratively restrict operating modes. It seems like you're just creating work for yourself. "Having the option to hard code" certainly did not "allow you to replace".

And you missed the point of my original post: Autonegotiation is mandatory with gigabit. The silent force mode Cisco employs on its FastEthernet switchports cannot work in a gigabit environment.

The option you describe doesn't exist. You're still autonegotating, just perhaps with a limited subset of operational modes. This is very different from the FastEthernet model where autonegotiation can be truly eliminated.

/chris

Reply to
googlegroups

That's completely normal behaviour when there is a duplex mismatch. The switchport was operating in FD but collisions were ocurring on the Ethernet ... hence we discovered the other end was not operating in FD although the OS said it was.

We only hard code 'server' switchports. Interesting how people take things out of context. I specifically mentioned 'core' switch ports and never stated 'every single host'.

Yes, and I'm presenting my experience which indicates migrating to Gbit doesn't mean 'everything has to be set to autonegotiation' and you can the hard coding of speed and duplex settings can be managed. It's horses for courses as they say.

Communication during the initial setup? Wouldn't you discuss the state of switchports with the sites support person/s? Were you made aware of the rules? Did you ask? Were the details of your installation documented?

I'm not having a go at you I'm just conveying the fact that mismatches can be avoided when all parties 'communicate'.

Sorry for missing the 'point' of your post but I was making comments related to my experience with Gbit and 'negotiation'.

I don't understand what you saying. our server ports do not autosense. They are hard coded at both ends. How can autonegotiation be 'mandatory' when you can still hard code the NIC/switchport. What am I not understanding?

BernieM

Reply to
BernieM

If your switch is operating in full-duplex mode, how can it possibly detect collisions? A collision (on twisted pair or fiber media) in half-duplex mode is defined as frame-reception-while-transmitting. However, in full-duplex mode, frame reception while transmitting is perfectly normal and expected. The question is, what "event" is being counted by the collision counter for a switch port in full-duplex mode?

Now, the collision counter on the *half-duplex* end of a mismatched pair may very well see collisions; in fact, it may see more than usual, since its full-duplex link partner considers it perfectly acceptable to transmit while receiving frames.

[snip]

You cannot disable Auto-Negotiation for 1000BASE-T. What you *can* do is limit the Auto-Negotiation advertisements to reflect a desire to operate as "gigabit or nothing," but the device will still execute the Auto-Negotiation algorithm. At minimum, it needs to select a clock master for the link, and place the other device in slave status.

Reply to
Rich Seifert

Agree that errors are normal in the case of a duplex mismatch. You'd said that both ends claimed they were running FD. If your administrative interface indicates the transceiver is operating in FD mode, but it's acutally running HD, then the interface is broken.

Ahh. I'd missed the significance of 'server' in your post. If keeping track of which ports should be locked 100/FD (the 'server' ports) and which ports should be auto (presumably all others?) is a convenient solution for you, then great!

This topic is interesting to me because of the *huge* number of my clients who attempt a similar strategy, but fail to get it right. If they had left things alone, they'd be better off. I've found that I'm much more likely to encounter an administrative screwup than a genuine negotiation failure.

But it does! Read on below.

Done. Yes. None Presented. Yes. Yes.

We're in agreement on this point :-)

You're bringing me back to my original question, which begins with the premise that autonegotiation is mandatory for gigabit links. The question was: Given that autonegotiation is mandatory, what are these interfaces which appear to hard code the settings actually accomplishing?

It is mandatory:

Rick J> Finally, when/if you migrate to 1000Base-T, everything has to be set

from

formatting link
"While Auto-Negotiation can be disabled on 10BASE-T and 100BASE-TX links, it is required on 1000BASE-T systems"

formatting link
" Technology improvements, and better interoperation of autonegotiation make it the preferred mode of operation, and is required on new technologies such as 1000BASE-T"

Reply to
googlegroups

When one side (in this case, the NetWare box's NIC) detects a collision, it transmits a short jamming signal out to make the other end aware of the collision so that both sides can back off and retry. Most switches will detect these collision signals and count them, even if they're not sending any themselves.

That's what you're seeing in the counters on the Cisco. The _far_ end is colliding even though the _near_ end isn't.

S
Reply to
Stephen Sprunk

Thanks, Rich.

It's a little disheartening to consider that administrative interfaces set to 1000BASE-T truly are negotiating (where they might not be for

100-BASE modes) and that they make no distinction on this point.

I'm very curious if you've got opinions to share on the state of mistrust of the algorithm.

/chris

Reply to
googlegroups

Bernie told us that *both*ends* were running full duplex.

In that case, neither end should be detecting collisions. Shouldn't even be looking for them.

And, in the case of a duplex mismatch, the jam signal sent by the HD guy won't make any sense to the FD guy. It will be recorded as "bits that didn't add up to a valid frame" rather than "collision jam signal".

/chris

Reply to
googlegroups

He later clarified that both ends were configured for FDX, but one end was silently operating as HDX. This is equivalent to the case where one side is forced to FDX and the other side is trying to auto-neg.

If you ever see collisions on an FDX port, you have a duplex mismatch. The cause is only interesting after you recognize the symptoms.

The hardware is there either way, so there's no harm in watching for something even if it's not supposed to happen, and it's a useful diagnostic considering duplex mismatches are common. It's probably cheaper to leave it on than to turn it off in FDX mode, so why bother?

That depends on the hardware implementation. All of the switch PHYs I'm familiar with recognize a collision jam signal even when configured for FDX operation. I don't recall what the jamming signal looks like electrically, but I'm pretty sure it couldn't be misinterpreted as normal (or even corrupted) bits.

I'm not familiar with NIC PHYs to say if the same applies; I'm a network guy so all my troubleshooting is done from the switch end.

S
Reply to
Stephen Sprunk

Ah I see what the original point/question was. I should read 'better' ... speaking of which I'll read those articles on negotiation now and will leave an open mind toward migrating 'back' to an autonegotiated environment.. Thanks very much for contributing to the topic its an interesting subject..

BernieM

Reply to
BernieM

Hrm. This isn't/wasn't clear to me.

In that case, one end should clearly be operating in FD mode and the other clearly operating in HD mode. "silent" HD mode operation where the interface claims FD mode sounds like a different scenario to me. Namely, that of a broken interface.

No. Rich told us earlier that you should never see collisions on an FD port:

RS> If your switch is operating in full-duplex mode, how can it possibly RS> detect collisions?

The hardware is there, but the meaning is not. The "jam signal" is not a meaningful signal. It's just noise on the wire to trigger the receiving-while-transmitting exception.

Because receiving-while-transmitting is not an exception in FD mode, the FD recipient of a jam signal sees only a nasty-string-o-bits. Cisco will (i think) log these as crc or framing errors. Certainly not collisions.

Couldn't it? It's just bits with no valid trailer.

You've really seen a port in FD mode logging collisions?

I can't make any sense of that.

Rich, is there more to the jam signal than just noise to trigger the (now evolved) over-voltage exception?

/chris

Reply to
googlegroups

Except that the "jam" signal is nothing more than 32 additional bits of data; it is indistinguishable from ordinary frame data. The full-duplex end cannot tell that it is a "collision," it looks like a truncated frame (which may increment a CRC error counter, but not a collision counter). The one thing that *might* increment a collision counter on a full-duplex interface would be reception of a frame shorter than 512 bits in length (what would be a collision fragment on a half-duplex interface), but these should properly be discarded without a counter increment.

Reply to
Rich Seifert

The jam signal is no different from data bits; it is simply a continuation of the normal frame transmission for an additional 32 bit times.

We should *never* have called it a "jam" signal; it has resulted in this common misconception. The name came from the original Xerox prototype Ethernet, where they really did send a unique signal--they held the coaxial cable to a logic "high" state for an extended period to indicate collision. We eliminated this special signal in 10 Mb/s Ethernet, and implemented the function using data extension; we should have changed the name. Come to think of it, we should have changed the name "collision" to "arbitration cycle" and avoided two decades of arguments about how to avoid collisions!

Reply to
Rich Seifert

While I have heard numerous anecdotal accounts of Auto-Negotiation failures (in this newsgroup, and similar fora), I have never personally seen or experienced a single instance of such on any production (non-prototype) equipment.

Reply to
Rich Seifert

If you're dying to see it for yourself, find a switch with a late-90s-era Broadcom PHY (e.g. Cisco 5000) and a PC with a 3com NIC using _original_ Windows drivers. It'll fail every time.

Those of us who dealt with these things in the wild saw it all the time back when it first came out. Particularly problematic is that folks tend to buy the same server/PC models in bulk, so if one fails, odds are you're looking at several hundred/thousand simultaneous failures. Or you might luck out and never see any, depending on what IT was buying.

It's definitely not as bad now as it was then, but the problem isn't gone yet. However, I'd agree that the rate is likely much lower than admins believe it is.

S
Reply to
Stephen Sprunk

I must have been remembering the coax signal and figured it applied to UTP.

This explanation leaves me at a loss for explaining how Cisco switches can detect remote collisions during FDX operation, but somehow they do, and it's a reliable indicator of duplex mismatches.

Rich, any ideas how they do it?

Arbitration was a bad word back then. For some reason, collision wasn't, except among the very, very new to the field. I suppose with a different name, we wouldn't have had to train that fear out of them...

S
Reply to
Stephen Sprunk

Do you count 10baseT devices that don't interact properly with devices trying to auto-negotiate with them?

I had this happen with some Asante boards likely designed (or using chips designed) before auto-negotiation.

I have never known anything faster than 10 megabits to fail negotiation.

-- glen

Reply to
glen herrmannsfeldt

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.