[c-nsp] Negotiation problem with Catalyst 2950 and Cisco 2821

[Ted Mittelstaedt]

>-----Original Message-----
>From: Reuben Farrelly [mailto:reuben-cisco-nsp at reub.net]
>Sent: Friday, December 02, 2005 9:41 PM
>To: Wojtek Zlobicki
>Cc: Ted Mittelstaedt; cisco-nsp at puck.nether.net
>Subject: Re: [c-nsp] Negotiation problem with Catalyst 2950 and Cisco
>2821
>
>
>On 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?
>>
>> On 12/3/05, Ted Mittelstaedt <tedm at toybox.placo.com> wrote:
>>>
>>> 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.
>>> IOS 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 OBVIOUS 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 IOS 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 IOS 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:
>
>http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCei41196
>

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