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

Its interesting as I have been working in the field longer now and it seems like every time you call in for vendor support they always harping on the firmware version its so very annoying because its used almost like the little boy who cried wolf until nobody listened and then he was eaten by the wolf. However, a few times once specific to a Sonicwall and another time specific to a Nexus 9k switch there was issues and everything was in order and it seemed no way it could be a fault with the devices as it was just outside the realm of what I call the “laws of networking” and you know what it was firmware on the devices and once we upgraded it resolved. So while the vendors call wolf on this stuff way to much when everything else is exhausted it can actually be firmware!!! still annoying as they lay the blame way to fast on it without putting in enough hard work but it is what it is.

Hello Brian

Yes, unfortunately, it happens too often… One of the marks of a good network engineer is that when interacting with the vendor, to provide them with all of the info necessary in such a way as to oblige them to zero in on the problem much faster than they would have if they were to view the problem independently at their own pace… But as you said, it is what it is!

Laz