Monitor any Internet connection and the associated provider for disruptions and other issues. Tracks reliability with automated speed testing. For Windows, Linux, ARM64, ARMa7.
Learn more by visiting www.outagesio.com
Notice: Community reports replaced by Prestaging dashboard Dec 15, 2023
HW Agent incorrectly reporting outage
My HW Agent (#130432) and SW Agent (#130431) are both reporting outages incorrectly. They are reporting a planned outage, due to my ISP (Comcast) performing repairs to the incoming connection to my building, as a LAN outage. This outage was an ISP outage due to no modem connection coming into my building.
The SW Agent is running on one of my servers, and the HW Agent is plugged into a network port of a Cisco switch. Both are giving the same alert as a LAN related outage.
Again, this was a planned network outage, as my ISP (Comcast) was making repairs to the lines serving my building, and the technician advised our incoming connection would be down for several minutes during the repair.
I was wondering if this is a configuration issue on my end? Any advice or assistance would be appreciated.
The agent will log an outage on the last hop it knew about just before an outage.
In this case, it's possible that when routing halted upstream, that caused the local router to lose the hop so that the agent see the next hop as being down.
In other words, in some networks, when the upstream goes down, it causes the local router/firewall to appear that it is down to the agent. I'm just guessing right now.
We'll take a look at your agents and respond with what we see and we can go from there.
I see different things that I need to be clarified to help troubleshoot...
- The image you sent is of the SW agent which is the only one that has, IMHO, the right hops (please check them in the dashboard menu, option Historical Hops)
- The HW agent strangely is connected in a different way since our app is unable to identify where LAN ends and provider begins
- The public IP belongs to the same network of the first hop of the provider but never appears within the list of the hops which makes me think the same device has both IP addresses set directly to the LAN and the WAN port
- This doesnt explain why the HW agent misses the LAN hop
- If point 3 is correct then I am assuming that the scheduled outage from the provider was interfering with the device configuration since shutting down the WAN interface SHOULD NOT trigger an outage on the LAN port
After looking closely at this, to us at least, as we cannot know for sure since we're not there, it seems as if the agent is connected directly to the providers router or possibly, in a DMZ zone which is bypassing the LAN hop.
That would explain why the agent is behaving as it is.
I am assuming that your firewall is also your default gateway, if not then what follows could be incorrect.
If I take a look at the hops recorded by all 3 SW agents (not only the one you mentioned) and the only HW agent, you will see that only the HW agent is having the first hop pointing to 192.168.1.1, the other ones go directly to an external IP without passing thru the firewall/gateway.
So on one side either the Windows agents or the firewall is masking the direct hops or they are connected in a different way from the HW agent; I also saw that the 130435 was once connected in a different way since it had the same 192.168.1.1 that now doesnt show up again.
In the end, what does it mean?
If the agent cannot determine where the LAN ends and the provider begins there is no way to give you a correct report about where the outage was and IF it was a network outage or a problem related to cabling (provider's end of cabling).
If the firewall is NOT your default gateway then it would be nice to understand a bit more about the LAN topology to help to troubleshoot it but so far I haven't seen a wrong behavior from the agents you have installed.