We have a 2821 voice gateway connected to a Catalyst 3750G switch. Its port is showing a lot of errors in the web admin interface and drilling down into the detail, we see that there are over a million total collision packets and over 3 million late collision packets. The uptime is 32 weeks.
Is this something to be concerned about? I've not heard about any call quality issues. What may be causing these? How should I collect more info?
Other ports on the switch (or in the network for that matter) seem to have no errors at all.
i feel it's better to statically define speed/duplex for router interfaces, servers, and other mission critical hosts, not necessarily use auto for them. (if there is a issue due to bad NIC, drivers, port, etc. you can then attempt other settings or even auto to see if issues are allieviated just for testing)
user pcs connecting to a switch, yea, auto is fine. (too much admin overhead to statically keep these setup)
as far as a million collisions over 32 weeks, this may not necessarily be pointing to a duplex mismatch although it could be. (if there is a duplex mismatch, the switch & routing logging should show you this; enable logging if it is not or view from the console for awhile)
one basic quick step is to clear the counters of the device and perform 'shows' of the ports & interfaces, if they are readily visible increasing immediately after a clear counters then you can check a few other things.
sounds like to me, the only connection to the router that is performing the routing as a default gateway for most or all of the devices connected to the switch, is this port that has all the collisions. what you should now look for are other errors such as CRC, input/output and deferred packets. if you see a sizeable amount you probably have another problem than duplex-mismatch. you should also check the interface queues. are there any drops? how many etc? deferred packets and queue drops will tell us, in most cases, the interface is overSubscribed. if this is the case, you may need to consider limiting the traffic too it or increasing the capacity of the link between the router & switch.
CRC errors, input/output errors could point to a faulty interface/port.
post a show interface output for our review if you like. also post any config of the ports/interfaces minus sensitive IPs.
The key indicator in the original post is the late collisions. Those are an almost sure sign of a duplex mismatch.
I disagree with you about the use of autonegiation. I don't know if we want to get into the details here but your are statistically more likely to run into problems with modern equipment if you manually set your speed and duplex settings. Some people get lucky and don't have many problems. It all depends on the mix of equipment in your network.
Cisco used to recommend manually setting speed and duplex until I successfully got them to change their documentation. I don't know if this is the proper forum for it but I could go into more detail about this if you'd like. Perhaps we could move the discussion over to the switching forum. (Is there a switching forum?)
I'll give the short answer here so there probably won't be a need to repost the thread elsewhere.
The Fast Ethernet standard, 802.3u, specifies nway autonegotiation as the connection method. It doesn't really specify what to do when one or both sides of a connection are manually set. This is a problem because there are two possible behaviors, and manufacturers don't always agree. In fact, you'll see both behaviors with Cisco equipment depending on the model.
Here are the two possible settings when manually configuring settings:
1. Disable autonegotiation entirely; use only the manually configured settings
2. Use the manually configured settings but still participate in autonegotiation
If you connect a device using behavior #1 to a device using behavior #2, and they're both manually set to 100 Mbps full duplex, you will get a duplex mismatch. Devices using behavior #2 still expect to see an autonegotiating link partner. When they don't see one, they assume (for good reason) that they're connected to a device that is not capable of full duplex. So, they drop back to half duplex.
Most of Cisco's newer equipment exhibits behavior #1, but some of their older stuff (XL switches, for example) use behavior #2.
The only sure way to avoid this problem is to use the only connection method specified in the 802.3u specification, and that is autonegotiation. If a device is not negotiating properly then it has a faulty NIC or NIC driver, or something else is wrong. Trying to fix the problem by manually configuring your settings doesn't actually fix the real problem, it just masks it.
We saw this a lot over the past five years after upgrading from a Catalyst 5500 (behavior #2) to a Catalyst 6500 (behavior #1). We also upgraded a whole bunch of remote locations from 2924XL switches (behavior #2) to Catalyst 2950 switches (behavior #1). Both sets of upgrades brought with them a flood of duplex mismatches where none existed before, but the problem wasn't with the new switches. The problem was that we used to manually configure all of our settings.
Our standard enterprise-wide configuration is auto on everything and we have zero problems. We used to have a couple of issues on some Solaris servers but those have been resolved.
Thanks for the feedback, everyone. I was able to log in to the gateway this morning and I found that the gateway's port is set to FULL duplex whereas the switch's port is set to HALF duplex. Remember, both are manually set to 100Mbps, too. I think these should be set to auto on everything, as suggested.
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...
The below trick might come handy when you have to add a new node to a cluster but you don't have or is unsure of the security password for the publisher. This procedure has been around for ages.
1) Login into the CLI of the Publisher.