The great thing about working in a small IT shop is that you get exposed to variety of troubleshooting, installation and support issues. I have worked in many large IT departments where every technology discipline is siloed. Trust me, I totally understand why that is the case, and have no issues with that type of environment.
I do believe though that, even in those environments, there would be a benefit for people to work for a day or two in different silos to get some knowledge transfer, senior staff can mentor and share some of their tribal technical knowledge with staff ad build some internal relationships and collaboration.
On to the point of the article. I have been handed problems lately that have had other technicians stumped – usually due to the fact that these bright technicians are swamped and cant dedicate a lot of time on these issues.
The last three issues all had the same trend – ‘port flapping’.
My definition of ‘port flapping’ is simply a port that goes up/down or connect/disconnect state an ‘excessive’ number of times an hour or day.
It’s important to compare your data with other ports with similar devices to make sense and provide relevant findings. For example, in one case a new printer was installed and that port was flapping over a thousand times a day, where other printers on the same switch had zero.
When a port is flapping here is the methodology I follow:
-Â Â Â Â Â Â Â Â Â Check port statistics and look for errors, lower than expected negotiated speeds or half-duplex
Is there a pattern when it flaps – just during office hours?
What is on the end of it
ensure that spanning tree isnt the root cause
Lately I have been working with Ubiquiti Edgeswtiches and they have a neat cable test feature as well as ‘inspect’ that basically shows you the packets on that port. I have been documenting tips and tricks on using the edgeswitch features, like cable test and the ‘inspect’ packet viewer. I also documented some odd behaviors to look out for like error counters that don’t advance or reset, depending on the specific layer one issue and using the ‘legacy’ screen that has a ton more options.
One ticket the root cause was the internal cabling. The access point was going off line once a minute. We moved the access point into the telecom room and it ran for a day without an issue. Then we moved it back out to 2 different offices, that were close to one another with the same issue. Finally, we tried an office on the opposite side of the building and no issues. During the troubleshooting process I had them try a new patch cable at the AP and the telecom room side, just to be through.
Â
The last 2 tickets I worked one was caused by a printer’s power saving settings and the interesting part is when I accessed the printer’s power settings it looked like this.
Send us your article ideas or short write ups
