• Status: Solved
  • Priority: High
  • Security: Private
  • Views: 75
  • Last Modified:

Why it is losing 3% ping?

Topology is like this: N7K1 ----- N5K1 -----Opengear1(OG1). HSRP ip: in N7K1, which is connected(through N5K1) to OG1, N5K1 is layer2 there. N7K1 can ping OG1 with 97% successful rate. What can cause ping loss?  We also have N7K2---- N5K2 -----OG2. but it can work well without any issue. Thank you
2 Solutions
Mal OsborneAlpha GeekCommented:
Not sure of your exact topology there, however 3% packet loss is probably not going to cause any huge issues, unless a heap are happening consecutively. TCP can easily cope with that. There may be the odd glitch during VOIP calls, but nothing unmanageable.

Sometimes ICMP is prioritised lower than other traffic as well, so you may have less loss in "real" traffic.
eemoonAuthor Commented:
Thanks for your reply. yes, it is not big issue, but it is there for a few days. it is always 2-4% loss there.
3% packet loss is way too much (although TCP will recover it will cause a lot of retransmissions), but it may be just 3% ping loss not traffic loss.
Control plane can limit ping amount, so it can be OK if there are no errors  under interfaces and some pings are lost (ping can be configured as low priority traffic or control plane is limiting icmp rate).

Could be bad cables, or saturated interfaces.

"show interface ethernet x/y" can be issued on involved interfaces and check for errors.
atlas_shudderedSr. Network EngineerCommented:
Before you get spun up over Pedrags comment, try running your ping with TCPing rather than a standard ping.  Yes, 3% loss could be problematic.  No, 3% doesn't mean you will be on your knees.  It depends on what the traffic loss is on.  The reason for using TCPing is that ICMP is the lowest priority across the network and for that reason, will be dropped before any other protocol.  Translation, if your 3% loss is limited to just ICMP, then you really don't have a problem and panic would be completely unwarranted.  If the 3% loss carries over to TCPing, then you will want to start evaluating intermediate devices for errors, buffer overruns, contention, saturation, etc.

eemoonAuthor Commented:
Thank you engineer. i got it. it is end device interface issue
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: SQL Server Core 2016

This course will introduce you to SQL Server Core 2016, as well as teach you about SSMS, data tools, installation, server configuration, using Management Studio, and writing and executing queries.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now