Reasons to set speed and duplex on interfaces

[CaptainPistache]

Dear Cisco Community,

We had troubles with the network connections of some of our users (very low bandwidth when accessing internal resources). After investigation, we've found out that the root cause was the speed (100) and duplex (full duplex) settings hard coded on a lot of access switch interfaces (and thus despite the fact that their maximum physical bandwidth is indeed 100 MBps and that their computers were set on auto negotiation).

For those who'd be interested, the symptoms were a lot of input and CRC errors on the interfaces.

I have seen different configuration of switches and I have the impress that hard coded speed and duplex was a thing in the past. However, I cannot found any true reason to do it actually.

When would you set speed and duplex settings on access interfaces ?

Thanks for your help.

Captain

[Mark Malone]

Hi
some older NICs may have required it but i dont think access was ever set that it had to be , definitely towards some ISPs WAN due to there local modems required hard set and still do , config also may have been carried over it happens all the time , recently replaced some daisy chained PCs connected to older phones , phones could only operate at 100mb so they required it , had to update the config when new phones went in that were 1GB capable , usually these days all access is auto and works well , only ever set it if far end has a reason too

[Joseph W. Doherty · Accepted solution]

"When would you set speed and duplex settings on access interfaces ?"

When auto (on both sides of the connection) doesn't work correctly. (Unlikely unless you're working with last century equipment.)

Or, when you truly need the fastest possible down to up connection time.

Otherwise auto is the preferred method. Generally recommended by all hardware vendors and also provides other features such as some additional error diagnostics and possible auto MDI/MDI-X.

BTW, an auto interface connecting to a hard coded full duplex interface will set itself to half duplex, which as you noticed, generally results in very poor performance.

[Giuseppe Larosa]

Hello,

as noted by Joseph the default duplex setting at 100 Mbps is half duplex not full duplex so the issues you have faced. You should have also seen late collisions as the switch side works in full duplex and the PC NIC in half duplex on the PC side.

I have seen in a customer network a better approach:

using in interface mode

speed auto 100

This allows to still negotiate with the other side and puts an upper limit to the usable speed.

I think the switches were a mix of C3650 and older C3560.

Hope to help

Giuseppe

[Joseph W. Doherty]

Just a note, although that's a great info from Giuseppe, "auto" alone will also match speed between different interfaces - so again, you should first try just auto unless you have a reason to do otherwise. I suspect the customer Giuseppe mentions may have wanted to "throttle/limit" hosts to 100 Mbps regardless if the host and network supported gig.

[Leo Laohoo]

---

@CaptainPistache wrote:

I have the impress that hard coded speed and duplex was a thing in the past.

---

Hard coding of the speed and duplex is old school.  The reason is because the early generation of switches, like the 2900/3500XL-EN, did not have auto-negotiated in the codes.  Plus, back then, wired NIC didn't also support that feature. 

In the last 10 years or so, wired NIC now have facilities to auto-negotiate properly.  

There are, however, some exception but these are very, very rare.  And this is due to the reason that there are some vendors who are still utilizing NICs that were manufactured 15 to 20 years ago (cheaper to buy).  I have seen one that will only negotiate to 10/half and doesn't support full duplex.

[CaptainPistache]

Thank you very much to all of you for your helpful and detailed answers, they improve my understanding of the situation.

Bonus question :

We've spent more time than we should have done to investigate the problem because we first tried to do a speedtest (at speedtest[dot]net) and the bandwidth appeared to be totally fine. But the slow-down was still occurring for internal resources. Why did this behavior happened ? Is that because the speedtest protocol just send a lot of dumb data without any transmission control ?

Captain