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

[Ted Mittelstaedt]

>-----Original Message-----
>From: cisco-nsp-bounces at puck.nether.net
>[mailto:cisco-nsp-bounces at puck.nether.net]On Behalf Of C. Jon Larsen
>Sent: Saturday, December 03, 2005 11:40 AM
>To: cisco-nsp at puck.nether.net
>Subject: RE: [c-nsp] Negotiation problem with Catalyst 2950 and
>Cisco 2821
>
>
>
>> On 12/3/05, Ted Mittelstaedt <tedm at toybox.placo.com> wrote:
>> 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 find it quite odd that as a service provider you would ever
>trust your
>network to autonegotiation.
>

I used to think that way until one day one of our larger customers
complained about packet loss and excessive latency on X-term
connections.  (Why they were doing x-protocol over a DSL line and over
the Internet I'll never know)

When investigating the entire packet path the only thing I could
find was errors on an Intel Etherrexpress Pro 100 plugged into one of our
upstream feeds which was coming in over 100BaseT.  (the intel
card was in a BSD box we were running gated on and running BGP
on)  That had been set to hard-code.  Setting it to auto and having
the feed set their hub port to auto fixed the problem.  (we eventually
changed the BSD box to a 7206VXR because you can't easily support
ATM coming in on a DS3 with a PC.  Other than that it worked fine)

Today the only thing I automatically hard code are the switch ports
plugged into the FE ports on our 7206's because those ports do not auto.
And all our switches are managed these days.  For everything else I
check the stats on the switch port after plugging in the device.
Sometimes
I use hard coding if there's a problem (the Compaq Thunderlan
texas instruments 10/100 interfaces for example are particular
problems) but with everything else, autoneg works better.

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

You can only do this when your plugged into a managed switch.  At
the NOC everything is managed, but it's a different story with most
of our customers.  Even the customers that do have managed switches
(which are few) often don't have management turned on.

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

Most of our customer handoffs are ethernet ports on 1600's, 1700's 1800's
that are at the end of T1's and the router is at the customer site, or
they
are ethernet ports on DSL modems at the customer site.  While most of
the DSL stuff goes right into cheap routers, the Cisco gear usually runs
NAT and goes into anything imaginable.

>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 OS provides.
>Guess I am old fashioned.
>

Ebay 3com managed switches (like the desktop 3300 which is an excellent
and cheap Ebay switch) would be a step up for what 70% of our customers
are using.

Ted