How to Troubleshoot Networks

This topic is to discuss the following lesson:

great blog … thanks

So Good and very helpful for me.Thanks you RENE!!! Your are very good for us.

I wanted to add some details about the “Collect Information” step:

- When did the problem first occur?
- How often does the problem re-occur? (Every 4 hours? Check ARP!)
- Who is it affecting? (One person, a floor, a building)
- Were there any other changes happening around the same time?

Those are some good pointers Tristan, thanks for sharing!

I really enjoyed this lesson so much I memorized the main topics as I like letter groupings so I did CAE HV and TBD FSR don’t ask me why that is easy for me to remember but something about those stick in my memory. Just like
E ACE WNI D for the log messages. I sometimes forget a letters meaning but a quick look puts it back in my memory for weeks if not longer. The grouping is also important for me remember… weird huh lol…

Anyway I really liked this lesson it stood out for me as one of my favorites.

1 Like

Hi Renie,

What is the right approach to start the troubleshooting over network latency & bandwidth related problem. Can I have some live issue with an appropriate troubleshooting & solution approach.

Thank you in advance.
Regards,
Mallik

Hello Vimal

Latency and bandwidth issues can be among the most difficult to troubleshoot. Some things that you can do to try to pinpoint this lantency include:

  1. Verify latency and the path that is being taken by packets experiencing the delay using tools such as traceroute
  2. Examine the interfaces of the network devices through which the particular latency has been identified using the show interface command. Look for queues being overflowed, errors, dropped frames or any other anomaly.
  3. Examine the routers through which packets are being routed and verify that CPU usage is low and that QoS mechanisms are functioning correctly. Verify that no policing or shaping is causing latency.
  4. Use network monitoring tools to examine the flow of traffic through your network in order to identify potential bottlenecks.

This is just a start, but I hope it helps you on your way.

Laz

Hi Laz,

Many thanks for your response, now have some clue to approach.

Can you please also explain how Policing or Shaping can cause latency in network?

Any live scenario or diagram much appreciate for better understanding.

Thank you in advance!

Regards,
Mallik

Hello Vimal

Policing and shaping are QoS techniques that are used to enforce lower bit rates than what the physical interface is capable of. Shaping will buffer traffic that goes beyond the allowed bit rate, while policing will drop packets that exceed the bit rate.

If packets are buffered during shaping, then this means that buffered packets will be delayed in their traversal of the network. This will only occur if the enforced limit is reached. If traffic rates are below the enforced limit, no latency will occur.

The results of policing are even more severe. If packets are dropped, then other error correction mechanisms (such as those used with TCP) will have to kick in at higher layers to have the lost packets resent. This brings about even more delays. If UDP is being used, packets are lost for good resulting not in latency, but packet loss.

You can find out more about shaping and policing at the following lessons:


I hope this has been helpful!

Laz

Many thanks ! once again Laz. Things are getting friendly now. I really enjoyed it :grinning:

1 Like

Hi Rene/Laz,

I am new to CCNP course, and I must say that the way you explain concepts is just commendable.

Though i have been following the course and practicing but I need some suggestions/advice in troubleshooting. I want to learn how to actually read a network. I want to get familiar with my work environment and I need help how to start with that.
What are the things we should do first when starting troubleshooting a DC/network.

I hope this makes sense.

Thanks
Tanya

Hello Tanya

First of all, you can take a look at this lesson that covers this topic:

Some general guidelines you can also keep in mind include knowing your network. The first and most important principle is understand the network that you are working with, learn it, read documentation, assuming it exists and has been kept up to date :stuck_out_tongue:. If it’s not up to date, create the documentation yourself, including a detailed network diagram. Find out what services are running on it. Look at network diagrams, go into devices and check their routing tables, configurations, and setups. It is difficult (more like impossible) to troubleshoot a network you know little or nothing about!

Secondly, when you have a problem, gather as much information as you can, not only from users (that may describe problems very subjectively) but try to experience the problem yourself.

Thirdly, know that troubleshooting only improves with practice. As you expose yourself to more and more problems, and you find their solutions, you intuitively begin to take steps that quickly bring you to the solutions you require.

I hope this has been helpful!

Laz