[c-nsp] Cisco 2924XL Questions

John Neiberger John.Neiberger at efirstbank.com
Wed May 11 10:58:17 EDT 2005


>Actually, interestingly enough, I've recently run into a lot of
problems
>with hard-coding speed/duplex on some devices and had to revert them
to
>auto-negotiation. Specifically, I had an issue with a Cisco 2970 and
a
>SonicWall firewall, which we had a lot of problems with and ended up
having
>to revert from hard-coded 100/Full on both sides to Auto-Neg to get a
duplex
>match. Auto-mdix didn't seem to work at all, either.
>
>Has anyone else had similar to this?

I have had a gazillion issues like this. If you're really interested in
reading my semi-annual rants on the subject, go to www.groupstudy.com
and look up my name and autonegotiation in the archives. I've explained
our story many times. I've successfully got Cisco to alter their
documentation regarding this topic. They used to say that hard-coding
these settings was a good way to go, but that's actually not true any
longer.

Because of the way Nway autonegotiation works, manually setting newer
devices to 100/Full is absolutely the worst thing you can do. It may
work, but it has the highest chance of failing of any setting. If you
must hard-code, use 100/half.

Here's the problem in a nutshell: the Fast Ethernet standard only
discusses autonegotiation; it does not specify how a device should
behave if the speed and/or duplex are manually configured. This is a
problem because there are two different possible behaviors and all the
NIC vendors can't decide which behavior they want to use.

Behavior #1: Accept the manual settings and do not participate in Nway
autonegotiation 

Behavior #2: Accept the manual settings and still participate in Nway,
but only mention the manual settings during negotiation

Cisco's older switches, like the 2924XL, used behavior #2 but their
newer switches all use behavior #1. Imagine the following scenario...

You have a server connected to a 2924XL and both sides are hard-coded
to 100/Full. All is well, life is good. The 2924XL dies and needs to be
replaced so you swap in a 2950 with a config identical to the
2924XL--both sides are hard-coded. All is not well, life is not good.
The 2950 reports that it is running at 100/full but you're seeing a
whole bunch of input errors and the server is responding very poorly.
You access the statistics from the server NIC and you see a huge number
of late collisions. You then bang your head against your desk for a few
hours trying to figure out why this is happening.

Well, I'll tell you why. :)  Your server NIC uses behavior #2 and even
though you have hard-coded the speed and duplex, the server expects to
see an Nway-capable link partner. The 2924XL still participates in Nway
even when you hard-code the settings. The server sees an Nway-capable
partner and it is happy.

The 2950 will not participate in Nway if you hard-code the settings.
Your server will not detect an Nway-capable link partner and it will
assume that it is connected to a device that is not capable of running
at full duplex. So, unbeknownst to you, it will drop back to half duplex
even though you have it manually set to full duplex! Whoo hoo!

The solution is to either hard-code to 100/half on both sides or, more
preferably, use auto on both sides. As I mentioned, I successfully got
Cisco to alter their documentation to reflect that autonegotiation is
the preferred setting and that manual settings of 100/full can result in
some very bad things happening.

Regards,
John
--


More information about the cisco-nsp mailing list