North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
RE: Weird networking issue.
- From: Proctor, Chris (EPIK.ORL)
- Date: Thu Jan 09 15:43:28 2003
In the real world, auto-negotiation on fiber vs. auto-negotiation on copper
have been two different animals. Most of the compatibility issues result
from 10/100 auto-negotiation on copper as this was the first major
deployment of the technique in Ethernet devices.
Most devices engineered recently should auto-negotiate properly. In the
early to mid 90's this was only true within the product line of a single
vendor. Many of the products Cisco sells were engineered by different
companies and often have problems auto-negotiating to other "Cisco gear"
made by other companies.
Also remember that many of the products that Cisco still sells have roots
back 5 or more years. There is a good chance that any 3600 copper interface
could have the same issues that its cousins did in 1997.
The question of hard-setting speed/duplex on these types of interfaces is
about as murky an issue as spanning-tree. You solve some problems and
create others. I suppose the primary goal is to eliminate support calls and
outages within your own environment.
In my experience, connections which as static (servers, routers, etc...)
should be hard coded on both sides as incorrect negotiations can and do
occur. It is also frustrating to discover that your primary file server has
been running at half duplex for a week.
It may also be interesting to know that IEEE 802.3-2002 says that
auto-negotiation is optional (in section 28.1.2.) It may also be
interesting to know that if a device does support auto negotiation it must
allow manually overriding of the function (IE.. an unconfigurable device is
not allowed to auto-negotiate.)
From: Mikael Abrahamsson [mailto:firstname.lastname@example.org]
Sent: Wednesday, January 08, 2003 2:39 AM
Subject: RE: Weird networking issue.
On Wed, 8 Jan 2003, Stephen J. Wilcox wrote:
> So thats human error not a problem with using forced settings, eliminate
> human error and I think you'll see forced always works, autoneg sometimes
> works. (For future reference dont employ incompetent people to run your
Problem with autoneg is that you always have to have manageble equipment
and you always have to check both ends after changing anything. In an ISP
environment that is generally not a problem luckily, apart from the
equipment you connect to on the customer side, some customers insist on
using cheapo stuff.
Autoneg does add good things, especially on GigE. Autoneg on a GigE yields
the most desireable effect of "link loss return", ie if you lose fiber
link one way the link goes down at both ends.
> Have you looked at what autoneg is.. its horrible, a hack to help out the
> incompetent engineers who dont know how to force duplex.
Hmm, I might draw the same conclusion regarding automatic gear boxes on
cars but I think I should not considering the situation in the US
regarding that perticular issue :)
Personally I think the idea with autoneg is really a good thing, why
shouldnt two units advertise their capabilities and then act accordingly
to what they both can do? We do the same on SMTP (EHLO) and so on.
Mikael Abrahamsson email: email@example.com