nanog mailing list archives
RE: Weird networking issue.
From: "Proctor, Chris (EPIK.ORL)" <cproctor () epik net>
Date: Thu, 9 Jan 2003 15:40:21 -0500
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.) -----Original Message----- From: Mikael Abrahamsson [mailto:swmike () swm pp se] Sent: Wednesday, January 08, 2003 2:39 AM To: nanog () merit edu 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
the
human error and I think you'll see forced always works, autoneg sometimes works. (For future reference dont employ incompetent people to run your
networks
folks!)
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
above
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: swmike () swm pp se
Current thread:
- RE: Weird networking issue., (continued)
- RE: Weird networking issue. Mikael Abrahamsson (Jan 07)
- RE: Weird networking issue. MPuras (Jan 07)
- Re: Weird networking issue. Spencer . Wood (Jan 07)
- RE: Weird networking issue. Braun, Mike (Jan 07)
- RE: Weird networking issue. Mikael Abrahamsson (Jan 07)
- RE: Weird networking issue. Daniel Senie (Jan 07)
- RE: Weird networking issue. Stephen J. Wilcox (Jan 07)
- RE: Weird networking issue. Mikael Abrahamsson (Jan 07)
- RE: Weird networking issue. Mikael Abrahamsson (Jan 07)
- RE: Weird networking issue. Jeffrey Wheat (Jan 07)
- RE: Weird networking issue. Braun, Mike (Jan 07)
- RE: Weird networking issue. Proctor, Chris (EPIK.ORL) (Jan 09)