Monitor your Internet services or devices to ensure they are always online. Tracks Internet connectivity and speeds with useful proof. For Windows, Linux, ARM (Raspberry, Tinker Board, etc).
Learn more by visiting www.outagesio.com
Agents reports wrong router was down ?
I noticed agent 129005 reports a lot of disconnects.
I started a continuous ping request from command prompt from a PC connected to the network at 9:34am and stopped it at 9:38am (local time) and there was no packet loss :
but agent reports packet losses on that time frame :
Trying to ping 18.104.22.168 from 9:40am to 9:44am shows indeed packet loss :
which are also detected by the agent :
What happens is this computer is connected to a switch, that is connected to a first router (192.168.0.1) that has both a WAN access and 4G backup connection. When I ran the tests, the WAN access had a problem and the router was using the 4G link. The second router for the WAN access is 192.168.1.1 and is connected directly on the WAN port of 192.168.0.1.
Why the agent reports 192.168.0.1 is down ?
I dont see the same thing you say so i need more info
If I check the hops found by the agent I see this:
Can you please explain what the 192.168.1.1 is and why I do see it after the 0.1 before accessing the WAN interface?
Is it the router able to manage the hand-over between the wired and the wireless WAN connections?
Just as an example which not necessary is your case...
...if the router is always on the wireless WAN connection because there is problem on the wired, the ping will maintain the connection up and as soon the ping is stopped then the wireless WAN is unavailable.
If the agent is reporting an outage it means that an IP outage was experienced and I do see some more at the provider level, not only in the local router (0.1)
Any other info you can give us, will be useful to explain the behavior
All the computers are connected on a 192.168.0.0 /24 subnet. The default gateway (192.168.0.1) is the dual WAN router (TP-Link MR200). This router is connected to 192.168.0.1 on it's WAN interface and uses it as a primary access. 192.168.0.1 is the router provider by our ISP (we have an optical fiber connection).
If the WAN access is down, it will use the 4G SIM card as a backup connection. The failover / failback process is automatic. Yesterday the fiber got cut and the primary WAN connection was not working so the router failed back on it's 4G connection.
Sorry for asking again but I need to understand first what is 192.168.1.1 and where is physically connected in the image I decided to build based on your description
...eventually we can schedule a zoom call so I can try to better help you.
In case you agree to a zoom call please dont share any email address here (we protect your privacy!) , just say yes indicating date time and timezone so we can try to arrange a call (we will send you an email to the registered address)
I am not sure why you say the info is incorrect but I am open to see it when I understand what are you are meaning with it.
In the image I shared before you can see that the only path that is recognized for now is the one going from 192.168.0.200 to 192.168.0.1 (your gateway) to 192.168.1.1 (your ISP router) and from there out into the provider's network.
I am assuming that the 192.168.1.2 is the IP associated to the WAN interface connected to the ISP router.
I am also assuming, as per my image, that your router has two different WAN interfaces (one for the wired provider and the other for the 4G provider)
Said so, my first attempt to understand the outages associated to 192.168.0.1 is that your router is going down when is managing the "move" from the wired to the wireless provider meaning it is having a short delay in doing the hand-over
Again it is a very first attempt in trying to explain what the agent sees.
@SBK No matter if it's the primary WAN is up or not, 192.168.0.1 always remains up even during the failover or failback process. I verified this in my first post.
That's why I said the agent reports something incorrect, because it reports that 192.168.0.1 is down when actually 192.168.1.1 is down.