As I have been working in the "networking industry" for the last 10 years, I had always the chance to work with execptional networking engineers. From each one of them I have been taught very simple but important things on how to debug networking problems as they occur on day to day business. There is even a RFC which I like to refer to it is the RFC 1925 - The twelve networking truths.

Apart from that RFC that is fun to read the very most important thing is to mention if debugging productive networks and seraching for a cause of a failure, is to change one thing at a time and to wait at least 24 hours. That is the case if the cause is not known. This once particular and unwritten best practice hint, (please correct me if I am wrong and you find a RFC or a IEEE about this) has helped me numourous times in finding a possible cause for a failure.

The next very important hint while debugging I have been taught in school in a history lecture. Now you will ask yourself what has got a history taught in school with networking. A teacher told us once that if searching for a reason for something, the cause effect is mostly not monocausal.Things do not have only one cause, most times network failures have different reasons and not only one.

I understand that this is a optimised view on a possible problem and the described methods above do not apply always to a particular problem. Still these both are very important methods and I have made good experience with both along the years working in the network industry.