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:
- Verify latency and the path that is being taken by packets experiencing the delay using tools such as traceroute
- Examine the interfaces of the network devices through which the particular latency has been identified using the
show interfacecommand. Look for queues being overflowed, errors, dropped frames or any other anomaly. - 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.
- 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 
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 
. 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
one of the most useful tools for layer 1 troubleshooting for switches is the commands:
test cable-diagnostics tdr interface interface
show cable-diagnostics tdr interface interface.
Often I have experienced technicians either not wanting to fix a cabling issue, not knowing how, not having the tools, or just lying. A quick fix to layer 1 issues where you have atleast 2 pairs complete(sometimes less) is changing the speed to 100 static its not perfectly ideal, but it will fix all kinds of issues from authentication issues to notconnect issues.
Hello Justin
That’s great, thanks for sharing your experience!
You can take a look at these and some other cable testing commands at the NetworkLessons note on the show cable-diagnostics commands.
Thanks again!
Laz
HI Team,
Users are facing issues with Team like getting disconnected from teams on both wired and wireless office networks. I have collected wires hark logs at the time of disconnection, but unable to find nothing in logs. How can I narrow down this issue. This is happening with lot of users in office.
Regards
Srikar
Hello Sonti
When you say your users are getting disconnected from Teams, do you mean the Microsoft Teams collaboration platform? If you are having problems only with your Teams implementation, then your troubleshooting should focus on the application and the platform. If that is the case, I suggest you ask for assistance from Microsoft support, as they will be able to help you identify specific events in their logs and in the logs of the application on each PC or device.
If however, you are having problems on other systems as well (web traffic, voice, video, pings etc) then you should approach the problem as a general network issue. If that is the case, follow the principles in the following lesson:
Give us some more details so that we can help you further.
I hope this has been helpful!
Laz