I'm looking for suggested scripting to monitor the WAN link provided by Spectrum. I used to use ping, but their gateways don't reply to ping anymore. Internet access is working fine, though.
What suggestions do you have for what I could use, and link into a watchcat action script to determine if the ISP gateway is actually working? (and not complain when ISP link works but something elsewhere farther away is broken on the Internet)
The full story:
Spectrum internet in central NY, USA, changed something overnight. IPv4 and IPv6 got renumbered, from which my OpenWrt 25.12.5 router has recovered. However, what's new is that the ISP's gateways no longer respond to ping. I had them monitored by collectd-mod-ping, and they're not responding anymore after the outage overnight.
I have scripting that rewrites /etc/hosts when the upstream gateway changes. I see the correct IP addresses (v4 and v6) listed. But no response to ping. So what else can you suggest I do to monitor if the ISP link is functional?
Pinging farther away makes it harder to tell if it's an interconnect problem beyond my ISP, or a problem with the ISP itself.
I did see some suggestions in other forums (Xfinity and Spectrum customer discussions) to ping the DHCP-announced DNS servers (the theory is that these servers are run by the ISP and within its nearby-network, so any problems reaching them indicates an ISP problem, not a wider problem). I will try that out--the servers are included in the environment when the DHCP user scripts run. My script currently pulls out the upstream gateway from the environment.
You could start with a ping against a remote host, and once that fails switch over to traceroute/mtr, which might reveal some of your ISPs nodes (including the gateway)...
Good point... my ISP's DNS servers used to respond, but some time ago stopped... I do not care that much, as I just use them as endpoint for a routine short mtr run in the middle of the night, and since the intermediate nodes show up, I have what I need (getting the RTT to the server would be nice, but since I run an recursive resolver I am not really using their DNS servers much).
Realistically, I'm bound to keep using a cable Fritz Box my provider provides me with, because there's a couple of VoIP stuff terminated there which would be complicated to move away from, and I don't want any family drama when phone services stop working while and because of me migrating. The WAN port of my OpenWRT router is a Fritz Box Cable in my basement my provider gave me. But I do see this Fritz Box as part of my ISP's infrastructure.
I don't want notifications, I don't want automated handover to an alternative ISP. All I want is monitoring and some graphs.
Yes, I use luci-app-statistics, and that's where I discovered the ping of the upstream gateway had stopped working. I found it useful to know the RTT on the first uplink to my ISP. Alas, no longer available
Thanks for the suggestions. I'll play around with mtr to see if I can get it to expose the upstream first level link.
I did some experiments with traceroute, and it's curious, it show the first hop with a different IP address, not one matching the DHCP-announced router address--neither for IPv4 or IPv6. Could it be some other IP address on the same host (not using the ingress IP address as the source for the ICMP Echo Reply)?
As for monitoring with collectd-mod-ping, I'll use the ISP's DHCP-announced DNS servers (extracted from PROTO_DNS in udhcpc and odhcp6c user scripts). For now, they respond to ping. I figure they're legitimate proxies for functioning ISP service. If they don't answer DNS queries, then the ISP is at fault/having an outage of some sort, so that's as close as I can get to determining that a problem is their reponsibility.
