Re: "Forcing" gigabit link operation

BernieM wrote:
<googlegroups@xxxxxxxxxx> wrote in message
news:1142949283.456613.84140@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
BernieM wrote:

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.

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?

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.

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.

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.

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.

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'.

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.

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.

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:

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.

But it does! Read on below.

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.

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.

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?

Done. Yes. None Presented. Yes. Yes.

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

We're in agreement on this point :-)

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.

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?

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 Jones wrote:
Finally, when/if you migrate to 1000Base-T, everything has to be set
to auto-neg anyway.

from http://www.ethermanage.com/ethernet/autoneg.html
"While Auto-Negotiation can be disabled on 10BASE-T and 100BASE-TX
links, it is required on 1000BASE-T systems"

http://www.sun.com/blueprints/0704/817-7526.pdf
" Technology improvements, and better interoperation of
autonegotiation make it the preferred mode of operation, and is
required on new technologies such as 1000BASE-T"

.

Relevant Pages

  • Re: "Forcing" gigabit link operation
    ... Your Cisco switchport claims to be running full-duplex mode, ... switchport was operating in FD but collisions were ocurring on the ... ports for the last two years. ... It's not so much that we think autonegotiation is totally unreliable ...
    (comp.dcom.lans.ethernet)
  • connection amid neighbouring counter
    ... Why did Nydia boast the operating in touch with the radical ... disciplinary dismissals. ... Tomorrow, activists precede inside cold hemispheres, unless they're ... Many easy large ports best cling as the general instincts raise. ...
    (sci.crypt)
  • Re: USB suddenly died, system started to freeze a lot
    ... second when I plug the last one in and then both are operating just ... USB ports. ... I would never purchase a laptop without at least 4 USB ... when you first plug them in, there is a surge which probably hits it over ...
    (comp.sys.laptops)
  • Re: Industry run by (gasp) Foreigners
    ... questions about what countries are operating which ports. ... TTI Oakland, TTI Seattle, and TTI Long Beach are ...
    (soc.retirement)