Message
>From: Reuben Farrelly [mailto:reuben-cisco-nsp (AT) reub (DOT) net]
>Sent: Friday, December 02, 2005 9:41 PM
>To: Wojtek Zlobicki
>Cc: Ted Mittelstaedt; cisco-nsp (AT) puck (DOT) nether.net
>Subject: Re: [c-nsp] Negotiation problem with Catalyst 2950 and Cisco
>2821
>
>
3/12/2005 6:28 p.m., Wojtek Zlobicki wrote:
>You have already identified it as a duplex mismatch. Have
>you tried to
>hardcode the duplex and speed on both sides?
>>
>12/3/05, Ted Mittelstaedt <tedm (AT) toybox (DOT) placo.comwrote:
Hi All,
I hae a stock 2821 router with 2 gig E ports on the inside,
and 2 load-balanced t1's going to the Internet, running NAT.
IS version is 12.4.5
>
>Thing is, it's all cisco gear, and current generation at that,
>so he shouldn't
>*need* to force it.
Thanks Reuben, finally someone who isn't a Cisco apologist! I
figured it would be BVIUS to anyone with HALF A BRAIN that
setting autonegotiation on both sides should make it "just work"
out of the box. This IS cisco-to-cisco gear we are talking about
here.

>I mean, it's 2005 and autonegotiation has
>been around for
>years and years so it should be foolproof. Although there are
>problems with
>some kit (not specific to cisco) when one end is hard coded and
>the other isn't,
>that's more a function of the way autonegotiation works and
>isn't relevant in
>this case.
>
I have seen problems hard-coding speed and duplex on both sides,
when the ports are autonegotiation ports. The people advocating
this as a solution have little real-life experience with Ethernet
I think.
We are seeing more and more ethernet-to-ethernet problems than
ever before. The intro of gigabit chipsets has really compounded
the problem as they often don't play well with older chipsets.
And when you have a situation of something like a brand new Dell
using a broadcom chipset plugged into an older 10base T hub,
as I've seen at one of our customers, where it works but ethernet
speed and response is horribly slow, you really have to wonder
what these ethernet chipset manufacturers are smoking when they
design these chips.
I'll tolerate these mismatches with differing vendor equipment.
But there's no excuse for it when the vendor of the 2 items that
aren't playing well together is the same vendor!!!

>I have seen the problem Ted is referring to with 2800x and 2950
>switches, and
>the only way we could get around it was to upgrade IS on the switch to
>something more recent.
>
Thanks, I am glad to hear that someone else has seen the same
thing. That is good to know. An IS update for the switches is
overdue, no question, and I'll admit that. Although, everything
that I've read with respect to autonegotiation says that it's done
at a hardware chipset level.

>This bug might also be worth watching:
>
>
>
I note that bug refers to CSCei85361 which Cisco claims it cannot
find.
The problem with the 2821 and the 2950 should be documented in the
release notes for the 2821. It should not be left latent for customers
to stumble over. This particular problem consumed at least 4 hours
of time to arrive at the site, document it, figure it out, and put in
a replacement. Fortunatelly there was a Goodwill nearby since my last
10base T cheapie hub I didn't have since it was at yet another customers
site that had an ethernet mismatch.
Multiply this failure to document by the number of 2950 and
2821's that Cisco has sold and that are undoubtedly coupled together
and you can see that failing to document this in the 2821 docs wastes
enormous man-years of time for people.
Ted
cisco-nsp mailing list cisco-nsp (AT) puck (DOT) nether.net
archive at

Sat, 3 Dec 2005, Ted Mittelstaedt wrote:

Thanks Reuben, finally someone who isn't a Cisco apologist! I
figured it would be BVIUS to anyone with HALF A BRAIN that
setting autonegotiation on both sides should make it "just work"
out of the box. This IS cisco-to-cisco gear we are talking about
here.

FWIW, I've recently seen autonegotiation fail on FE ports between 3550's
running slightly different IS revisions.

Jon Lewis | I route
Senior Network Engineer | therefore you are
Atlantic Net |
http://www.lewis.org/~jlewis/pgp for PGP public key

cisco-nsp mailing list cisco-nsp (AT) puck (DOT) nether.net

archive at

12/3/05, Ted Mittelstaedt <tedm (AT) toybox (DOT) placo.comwrote:
Thanks Reuben, finally someone who isn't a Cisco apologist! I
figured it would be BVIUS to anyone with HALF A BRAIN that
setting autonegotiation on both sides should make it "just work"
out of the box. This IS cisco-to-cisco gear we are talking about
here.

I find it quite odd that as a service provider you would ever trust your
network to autonegotiation.

Hard code the port - leave nothing to chance. Is just one
extra command, and you should be doing that after you label the port,
with a description and putting it in a vlan, correct ?

With the exception of some cheap nics (and older drivers on windows
servers) I have never seen hardcoding **both** sides to full duplex 10 or
100 fail to produce good results. Failing to set speed and duplex will
(even if it works at first) usually bite you down the road i.e. typically
in a late nite reboot situation when it fails and one side is full and
the other side is in half (the default).

That being said autonegotiate **should** work in most cases, but why leave
it to chance for anything important like a switch to switch or a switch
to router or switch to customer handoff ? Ciscos have always had
autonegotiate problems, dating back to the 5000 and 5500 switches, its
nothing new.

Even with Bay and 3com switches (which do seem to work better with
autonegotiate) I always hardcoded (to full duplex) the server side with
mii-tool and the switch side with whatever tool the switch S provides.
Guess I am old fashioned.
-jon

cisco-nsp mailing list cisco-nsp (AT) puck (DOT) nether.net

archive at

I find it quite odd that as a service provider you would ever trust your
network to autonegotiation.

Hard code the port - leave nothing to chance. Is just one
extra command, and you should be doing that after you label the port,
with a description and putting it in a vlan, correct ?

We have the opposite philosophy. We set everything to auto. We have
*far* more problems with hard-set switch settings. It's been my
experience I have documentation at work to back this up
hard setting your devices to 100/Full is the worst possible choice.

The short story is that there is no standard method of behavior when a
NIC or switch port is hard set. Some devices still participate in Nway
autonegotiation even when hard set, while others completely disable
Nway. You run into problem when you connect devices that behave
differently. Some NICs that still participate in Nway will see that
there is no autonegiating link partner, so they'll try to be "helpful"
and fall back to half duplex under the assumption that they are not
connected to a device capable of full duplex.

I have successfully got Cisco to change their documentation to reflect
this behavior, but I don't have the link to that documentation here at
home. I'd have to go look for it.

John

cisco-nsp mailing list cisco-nsp (AT) puck (DOT) nether.net

archive at

Hard code the port - leave nothing to chance. Is just one
extra command, and you should be doing that after you label the port,
with a description and putting it in a vlan, correct ?

We have the opposite philosophy. We set everything to auto. We have
*far* more problems with hard-set switch settings. It's been my
experience I have documentation at work to back this up
hard setting your devices to 100/Full is the worst possible choice.

Three or four years ago I was of the opinion that hard setting all ports
was the way to go. But things have actually changed - autonegotiation
seems to have improved quite a bit, and nowadays I generally find that
auto works best. YMMV, of course.

Steinar Haug, Nethelp consulting, sthaug (AT) nethelp (DOT) no

cisco-nsp mailing list cisco-nsp (AT) puck (DOT) nether.net

archive at

Fully agree. thing people also fail to recall is that autoneg is
basically *required* (though you can generally disable advertising of
slower link speeds) with 1000BaseTX. It's part of the standard, and the
closer people get to setting all of their links to auto the easier the
transition will be for them later.
-Dave

Sat, 3 Dec 2005, John Neiberger wrote:

I find it quite odd that as a service provider you would ever trust your
network to autonegotiation.

Hard code the port - leave nothing to chance. Is just one
extra command, and you should be doing that after you label the port,
with a description and putting it in a vlan, correct ?

We have the opposite philosophy. We set everything to auto. We have
*far* more problems with hard-set switch settings. It's been my
experience I have documentation at work to back this up
hard setting your devices to 100/Full is the worst possible choice.

The short story is that there is no standard method of behavior when a
NIC or switch port is hard set. Some devices still participate in Nway
autonegotiation even when hard set, while others completely disable
Nway. You run into problem when you connect devices that behave
differently. Some NICs that still participate in Nway will see that
there is no autonegiating link partner, so they'll try to be "helpful"
and fall back to half duplex under the assumption that they are not
connected to a device capable of full duplex.

I have successfully got Cisco to change their documentation to reflect
this behavior, but I don't have the link to that documentation here at
home. I'd have to go look for it.

John

cisco-nsp mailing list cisco-nsp (AT) puck (DOT) nether.net

archive at

cisco-nsp mailing list cisco-nsp (AT) puck (DOT) nether.net

archive at

John Neiberger wrote:

>We have the opposite philosophy. We set everything to auto. We have
>*far* more problems with hard-set switch settings. It's been my
>experience I have documentation at work to back this up
>hard setting your devices to 100/Full is the worst possible choice.
>
>The short story is that there is no standard method of behavior when a
>NIC or switch port is hard set. Some devices still participate in Nway
>autonegotiation even when hard set, while others completely disable
>Nway. You run into problem when you connect devices that behave
>differently. Some NICs that still participate in Nway will see that
>there is no autonegiating link partner, so they'll try to be "helpful"
>and fall back to half duplex under the assumption that they are not
>connected to a device capable of full duplex.

I have never seen problems with Cisco gear setting BTH sides hard-coded.
We always hard-code interfaces between network gear. The switch ports
going through the patch panel to workstation jacks we leave autonegotating.

cisco-nsp mailing list cisco-nsp (AT) puck (DOT) nether.net

archive at