Track Internet disconnections, provider outages with historical data, and automated speed testing.
For Windows, Linux, ARM64, ARMa7. Learn more by visiting www.outagesio.com
Notice: If you created an account on app.outagesio.com, simply use the same credentials to log in here.
Agent keeps going inactive / disconnecting
-
What's interesting and maybe just a coincidence is restarting the agent service seems to fix the problem temporarily. That implies that whatever is upstream is allowing some ICMP traffic and then blocking it.
FYI, the agent uses standard port 80/443, and ICMP. While ICMP is a small part of actually detecting an outage, it's an important part because it's not only part of the heartbeat to know if it is still communicating but also for the agent to send updated hops changes and other tests.
-
If your office has a managed services arrangement with an outside company, it might be worth asking them if they have any ICMP (and/or other) limiters put in place. If it's not them and you can't find anything in the building, then it could also be the provider.
-
Hi, as an update, 'Back online" email is correct now.
-
Good afternoon.....
I believe I've got everything resolved. So, Cisco disables / blocks ICMP traffic by default to any outside interface. Once I allowed ICMP traffic on my firewall / ASA, my "hops" started showing in the history, and tracert to foxymon.com and tpw.outagesio.com (as well as to any other url) were no longer giving a "time out".
Thank you to everyone for the help!
-
Hi,
That's great to hear and I now see hops coming in which means everything should work now.
It also means your hardware agent should function perfectly once you receive it. -
That's a bit humorous. We were just sending an email to that agent owner about that then noticed it's the same address.
I've asked our dev to look into this one because now I'm stumped and need more input on why it would see a local outage without ICMP.
-
As far as I understand it, that should have created only an Inactive, not an outage. Give us a few minutes to look into this (ID 130432).
-
My bad: the time I gave you was MST not UTC so all fine with the 2:25 (almost 2:30) pm
What I think it is happening is that the agent has a wrong date which is kind of weird!!!!
Pings are coming in and hops came in too but with wrong dates
Let me see what I can do
-
I have been able to change the date and time right now but the NTP is not working so the agent's time is not exact (almost 1 min off)
All agents are in sync with the ntp.org servers so either the port or the URL are somehow blocked
All the confusion in hops and pings is in fact associated to the date and time sent by the agent that remained stuck to Aug 16 when it was prepared and shipped.
Pings are coming in correctly, you should see them and hops too.
I will change the historical data so they can fit the correct timing but the issue of the NTP not working properly on that agent is still unsolved.
