Hi.

This is difficult to speculate on, since we've not heard of people having this problem and we've certainly not heard anyone have an answer.

One possible issue is if the IP Address of local-server has changed. To check this, start a new instance of PingPlotter and try tracing to local-server in that instance. Check and see if the results are different (and in particular, if the IP Address for local-server is any different than it is in your long-running instance of PingPlotter).

I *assume* that this server is responding to other kinds of requests (ie: if you try to access it via your web browser, that it responds that way). If this is the case, a possibly useful exercise would be to see if packets of a different type are getting through. Try switching to TCP or UDP packets and see if the results are different that way.

You'd think that a tier 3 tech would know what's happening with network configurations, but it may be that there was a software upgrade (or similar) done to some peice of hardware near / at local-server that started blocking ICMP echo requests or replies. It's good that the tech saw the same results you did - that way you know it's not a local-to-you problem.

If local-server is accessible via FTP or HTTP client, then you should be able to access the server with PingPlotter using the TCP packet type. That certainly doesn't answer the problem of "What's going on?", but it might work around the issue and still allow you to use PingPlotter to monitor your connection to that server.

- Pete