RE: Weird networking issue.

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