Hi!
I've been using PingPlotter Pro off an on for a few months. Most recently (about a month now) our network monitoring tool has been alerting for down/up events on 2 connections. I have been monitoring and looking at it here and there but it is not a down link only the ability to ping and recieve replys that sometimes works and sometimes does not.

I have 4 total Frontier ADSL links to 4 different locations. I see problems with 2 of the 4. All 4 are located within Wisconsin. I'm collecting data to contact the ISP however I'd like some help analyzing the data to get a little understanding of what might be occurring.

Here are my two shares.
1) https://share.pingplotter.com/Zbn1YMrNTtZ
2) https://share.pingplotter.com/7sckucuxUjj

For both I'm curious why hop 8 shows high packet loss followed by hop 9 of the same IP with no packet loss? This is common and exists this way with one of the other Frontier DSL connections but that connection is pingable and I'm not having problem monitoring the on prem modem.

On the first share (Eden GW), I was getting to the final hop earlier this morning and then it suddenly started failing. Unfortunately, I cleared my workspace by accident so I don't have that showing.

Hey Snewp!

Thanks for getting in touch.

So, from what I can see in your traces, the biggest thing that sticks out to me is that it appears that these targets are not responding to ICMP. This is pretty common for a lot of AWS/Azure servers, and is a pretty common security measure for other devices as well. That being said, it's harder to tell what's *truly* going on with the target since we can't see it.

Usually when this happens, I'll go to the next-to-last hop and gauge the trace based on that - but this also has some complications as the packets sent to intermediate hops are TTL Expired (this is how traceroute in command functions too). It looks like on both traces, there's some packet loss at that second-to-last hop - but it's tough to know if that's real since we can't see it carry through, and the prior hop doesn't have any packet loss. It could be that this hop is just timing out some TTL expired packets (which is very common - that's why some other hops are showing packet loss that doesn't carry through), or it could be that there is real packet loss starting right at that hop that might be carrying through (but we just can't see it since the final hop isn't responding at all).

All this is to say that with these traces, I actually don't see much to be worried about given the circumstances. The latency looks pretty good, and I don't see any packet loss starting "close to home" (which is the most common issue that I've seen in my days of looking at PingPlotter).

However, if you do feel like you have an issue, I can recommend a few different things:

- if you definitely need to trace to this target that you've been tracing to which isn't responding, you can use a different packet type. You could use UDP, or, if you're on Windows, you can install Npcap in winPcap compatibility mode (that's an installer option in the wizard) and use TCP - so you could potentially mimic web traffic. You can read more about how to do this here:

https://www.pingplotter.com/manual/packetoptions.html

- You could also try to just trace another target that responds to ICMP - but I see you have a pretty specific target so you probably have a valid reason and need for that.

Feel free to keep tracing, and send us any share pages you want along the way. You can also reach us directly at support@pingman.com.

Thanks Hayla,
Today one of the two targets is pingable. I suppose that doesn't change much. For whatever reason they stop responding at some point and start again.

Here is the share.
https://share.pingplotter.com/iLg6eKtJgmb

Hey snewp,

Interesting - I went through all the data by pulling the .pp2 into PingPlotter, and everything that I'm seeing that's strictly speaking from a latency/packet loss standpoint is looking pretty good. Any issues such as timeouts seem to be originating right at that final hop, and there was only one instance of a latency spike that I could see that came from another hop (the second to last hop generated that spike) - however there's no pattern or repeat offenses from that hop so I don't see a reason for concern.