I have a 3845 router direct cabled to an ASA5400. The router was set for duplex auto and speed auto with the ASA set for duplex full and speed 100. With this, the router was showing the connection at 100/half. When I set the router to duplex full and speed 100 the interface went down and would not come back up.
If I set both devices to duplex auto and speed auto, then the router still only comes up to duplex half and speed 100.
I have the ASA set to duplex auto and speed auto, and the router to duplex full and speed 100. This now shows the router at 100/full as well as the ASA.
I thought you should always hard code both devices and not let them auto negotiate.
Why does the connection not work when both are hard coded?
Why does the connection not work the same when the ASA is hard coded and the router set to auto?
This was also true of the inside port of the ASA also going to another 3845 router.
I have found through hard times that what is taught is not always the best solution. I let the boxes tell me the solution that best fits the problem.
So here is my methodology, I start with auto-auto and watch the interface for errors. If I get errors I start on the device side that feeds into the core switch or router. Set it, watch errors again. If that does not come correct, set it on the core, and on the attaching device, and watch again. etc... 2 devices only 4 possible combos...
Now start port-chaneling and it can become even more fun.
Yes it can be a long task, you can speed it up by generating significant traffic to the device. Then once I think it is clean, I reset the counters on the interface and it run in the real world.
And yes you an spend a lot of time knocking out speed / duplex issues, but my network runs pretty clean. I also don't worry about client PCs unless I am seeing several 1000 errors with in a hour.
And here is the kicker it will change when somebody upgrades a NIC driver, or an IOS. Just part of the fun.
Hey you could have Nortels BPS2000 in which you had to hard code any device that 10mb or else it would not work. I am so glad they fixed that in a latter rev.. I am also glad I have weeded all them out of my network now.
Oh and a last note, if nothing fixes the issue don't forget about the cables and routing. Not routing in the sense of subnets, but physical layer routing.
Negotiation of duplex is dependent on negotiation of speed. If speed is hard coded on one or both sides and can not negotiate then duplex will not negotiate and any device configured with duplex auto will default to half if it can not negotiate duplex. I know some people who routinely will hard code most interfaces. In the early days this was pretty common practice because the negotiation was not so reliable. In today's hardware negotiation is pretty reliable and I believe that most people consider it best practice to have speed and duuplex set to auto, unless there is a particular reason not to or unless for some reason the devices are not negotiating correctly.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...