The other day, I was helping someone troubleshoot some performance problems. The first thing I asked was if there were any switch port errors, or as I usually say, Are the ports clean?
In this case, the answer, unfortunately, started with the dreaded 'should' word. When I hear 'should' or 'someone else checked,' I think of ways to have the client check without offending or stepping on toes. Even if they say, "I checked, and everything looks fine." I then ask them to explain what everything means since there are so many things to look at. And, more importantly, how people interpret interface statistics. One of the most important things I start with is to check when the interface counters were last cleared. Hopefully, your device supports that feature.
If you have Cisco equipment, Last clearing of show interface counters never makes troubleshooting trickier since the interface counters were never zeroed out. When this happens, we then need to determine how long the device has been up, which still does not tell us how long the interface was up, but a good start.
In one case, the uptime was over two years, so I have no idea if the interface counters reported covered that entire time period. With Cisco, you can clear the counters using a clear counters interface. If your network management system was monitoring the interface, you can go back to it as well. As you can see, this simple task can quickly spiral out of control and take a tremendous amount of time.
I would suggest that you determine how to check or monitor important ports on your devices since every vendor has their own way of reporting this. The easiest way is to utilize SNMP with a network monitoring system, so you don't need to know the various login credentials and commands. Some monitoring systems will actually interpret the values or create baselines to report on.
An example is on a Cisco 3750, you can type "show interface counter error" command and get a list of all the interfaces and if there are any errors.
Do not forget to check the other side of the link when possible for reported speed and duplex.
The best advice I can give when reviewing port statistics is to use context or basic math to illustrate if there is a legitimate issue.
For example, in the table below, port g7 has 1 Packet received with errors out of 558,733,018 total Packets received without errors, so there is nothing to see here.
If you see a lot of CRC, collisions, alignment errors, you might want to check the cabling and connectors out. Depending on what is connected to the network device, it could create some input/output errors. If this happens, be aware and make notes for future reference and for your colleagues.
After you verify that the ports are error free, you can continue troubleshooting up the OSI stack.
Related articles:
Bob Friday, Chief AI Officer for Juniper Networks, explains how the advanced technology is transforming operations.
Contact center leaders from 8x8, Awaken Intelligence, and 360insight discuss the importance of agent experience.
AI may force enterprises to rewire parts of their data centers so they are fully optimized to run such workloads. The question is do you use Ethernet or InfiniBand?
