4 Tips for
Tackling Network Problems
How do you determine where to begin tracking down the source of network problems? In last month's newsletter, we began at the bottom of the stack by troubleshooting physical-layer issues. This month we're going to examine network-layer problems using tips outlined by NI University instructor Mike Motta.
Trivia Contest
Congrats to last month's winner, Michael Brannon of Charlotte, North Carolina.
Last Month's Answer
Perl was originally named "Pearl," after the Parable of the Pearl from the Gospel of Matthew.
This month's question:
What does the acronym DLCI (related to frame relay data frames) stand for?
Submit your answer and be entered to win a Network Instruments polo shirt.
1. Investigate double-sided captures for delay
Take packet captures from each side of the network conversation and use MultiHop Analysis within Observer® Expert to investigate whether any of the segments are the source of delay. Learn how to set up MultiHop Analysis.
2. Calculate TTL (time-to-live) value to know how many hops
If you're troubleshooting network delay between remote offices, you need to identify where delay is occurring. If you know on average packets take 13 hops when in route from a remote office to headquarters and now it's taking 20 hops, this would point to the source of delay. The number of hops that occurs over a route is determined by calculating the difference between the TTL values from the source to the destination. Having determined the number of hops, we'll see if any hops are causing fragmentation.
3. Configure filters to look for fragmentation fields in the header with More Fragments or Don't Fragment bits set
Fragmentation issues cause packets to be unnecessarily chopped into multiple packets thus increasing workload and delay. Packets with the More Fragment bit set may indicate that a router along the path is fragmenting frames. While packets having the Don't Fragment bit set most likely indicate an application problem.
4. Build filters to search ICMP messages
If a router throws a packet away with the Don't Fragment bit set, it will notify the sender via ICMP (Internet Control Message Protocol). The message can determine the exact nature and source of the problem. ICMP messages other than pings indicate issues with the subnet, mask, routing, default gateway, or QoS.
| ICMP Message | Likely Issue |
| Redirect for Network | Default gateway incorrectly configured |
| Redirect for Host | Subnet mask incorrectly configured |
| Port Unreachable | Application port not started or responding |
| Host Unreachable | Have route but box not answering ARP request |
| Protocol Unreachable | ARP request answered but box not answering specific protocol request |
| Network Unreachable | Router does not have route to reach network |
If the network layer is determined to be error free, the next step will be to analyze application delivery and performance. To review MultiHop Analysis and advanced application analysis experts, read through the Network Application Performance white paper. You can also sharpen your network and application troubleshooting skills by signing up for one of our Network Instruments University classes.
Filtering For ICMP Messages
One critical step in troubleshooting network-layer issues is being able to quickly identify the source of delay along a network route. ICMP messages provide an easy way to identify the network problem and source. Create a filter to identify Redirects and Unreachable errors in Observer using the following steps:
1. In the main Observer console screen, from the menu at the top of the screen select Actions and Filter Setup for Selected Probe
2. Click New Filter from the menu in the Active Filters window and title the filter ICMP. Click OK.
3. In the Edit Filter window, select Edit Filter > Edit Rule As > Protocol

4. Within the Protocol Filter window, scroll and select ICMP and then highlight the desired protocol filter. For this example, select Destination Unreachable.
5. To add other ICMP messages to the filter, right-click on the protocol filter and select <OR> then Protocol > ICMP > Redirect.

Successfully creating an ICMP filter automates the error-finding process, and will make it easier for you to assess whether the problem is occurring on the network or elsewhere.
Reduce Troubleshooting Time by 20%
What if you could free up one day each week where you didn't have to troubleshoot? Learn how a new client automated and improved their troubleshooting process, while achieving a complete return on their investment in 24 months. Read the case study.
© 2010 Network Instruments, LLC. All rights reserved.
Network Instruments, Observer, GigaStor, Link Analyst, and all associated logos are trademarks
or registered trademarks of Network Instruments, LLC.
All other trademarks, registered or unregistered, are sole property of their respective owners.




