Re: Level3 4.2.2.1 and 4.2.2.2 not responding to pings, DNS queries work
On Mon, Jan 13, 2025 at 10:48 AM, Mel Beckman wrote:
>
> Dan,
>
>
>
> That dig tip for identifying the NS phy loc is very nice! That's something
> I can put in our support procedures for DNS troubleshooting.
>
Yup. Note that many authoritative DNS servers also support RFC5001 - "DNS
Name Server Identifier (NSID) Option"
<https://datatracker.ietf.org/doc/rfc5001/> (NSID). This can be really
valuable for figuring out which instance of an Anycast server you are
hitting.
E.g:
$ dig +nsid +edns NS . @b.root-servers.net
[[SNIP]]
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; NSID: 62 31 2d 69 61 64 ("b1-iad")
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
. 518400 IN NS a.root-servers.net.
. 518400 IN NS b.root-servers.net.
. 518400 IN NS c.root-servers.net.
[[SNIP]]
W
>
>
>
>-mel
>
> --
>
> *From:* [email protected]
> *Sent:* Monday, January 13, 2025 7:19 AM
> *To:* Mel Beckman ; [email protected] [email protected]>
> *Cc:* North American Network Operators' Group
> *Subject:* Re: Level3 4.2.2.1 and 4.2.2.2 not responding to pings, DNS
> queries work
>
>
>
> I’m seeing some of the resolver IPs being filtering from various locations
> while responding from others, no doubt due to their use of anycast. I
> rarely ping test 4.2.2.2 anymore, having switched to 8.8.8.8 some time ago
> which I have a window up running 24x7 as a quick way to detect if my laptop
> is having connectivity issues from wherever it currently resides. It’s
> usually reliable, but I understand such traffic is the first to get
> filtered/dropped when needed so it’s just an initial indicator for me from
> which further testing can be performed when needed.
>
>
> I will also mention it’s possible to detect which NS server/pool/location
> you are reaching on Level3’s network via the below dig query. This has been
> an invaluable tool over the years as IME they tend to break DNS
> sub-delegation at least once or twice a year and the more data you can
> provide to them about where the breakage is the faster you can get them to
> engage the DNS team to actually fix it vs. arguing with you that it’s not
> broken because it "works for them” (facepalm). And at least once I found
> they broke resolution on their authoritative name servers (ns1.l3.net or
> ns2.l3.net) and again they first told me it wasn’t a problem because DNS
> again the broken one(s) would timeout and then get the answer from another,
> working server (double-facepalm).
>
>
>
>
> dig +short @4.2.2.2 hostname.bind CH TXT
>
>
>
>
> I’ve also been provided this query to derive the same for Cloudflare’s NS
> servers:
>
>
>
>
> dig CHAOS TXT id.server @1.1.1.1 +nsid
>
>
>
> And the following for Cleanbrowsing NS servers (these power content
> filtering on Unifi networks):
>
>
>
> nslookup -type=txt iptest.whois.dnscontest.cleanbrowsing.org
>
>
>
>
>
>
> Below are the results I got for Level3 from various locations (pardon the
> wall of text). It looks like they’re making some changes to serve DNS
> queries off their NTP servers
>
>
>
> From Level3 WDC1/McLean:
>
>
>
>
>
> PING 4.2.2.1 (4.2.2.1) 56(84) bytes of data.
>
>
>
> --- 4.2.2.1 ping statistics ---
>
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
>
> rtt min/avg/max/mdev = 0.987/0.987/0.987/0.000 ms
>
> "pubntp1.wdc12"
>
> PING 4.2.2.2 (4.2.2.2) 56(84) bytes of data.
>
>
>
> --- 4.2.2.2 ping statistics ---
>
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
>
> rtt min/avg/max/mdev = 0.926/0.926/0.926/0.000 ms
>
> "cns4.sjo1"
>
> PING 4.2.2.3 (4.2.2.3) 56(84) bytes of data.
>
>
>
> --- 4.2.2.3 ping statistics ---
>
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
>
> rtt min/avg/max/mdev = 0.799/0.799/0.799/0.000 ms
>
> "pubntp1.wdc12"
>
> PING 4.2.2.4 (4.2.2.4) 56(84) bytes of data.
>
>
>
> --- 4.2.2.4 ping statistics ---
>
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
>
> rtt min/avg/max/mdev = 0.855/0.855/0.855/0.000 ms
>
> "pubntp2.wdc12"
>
> PING 4.2.2.5 (4.2.2.5) 56(84) bytes of data.
>
>
>
> --- 4.2.2.5 ping statistics ---
>
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
>
> rtt min/avg/max/mdev = 0.897/0.897/0.897/0.000 ms
>
> "cns4.sjo1"
>
> PING 4.2.2.6 (4.2.2.6) 56(84) bytes of data.
>
>
>
> --- 4.2.2.6 ping statistics ---
>
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
>
> rtt min/avg/max/mdev = 0.973/0.973/0.973
Re: Level3 4.2.2.1 and 4.2.2.2 not responding to pings, DNS queries work
A tangent came to mind while reading over this thread: Google has a similar feature to aid in troubleshooting. https://redirector.googlevideo.com/report_mapping It will indicate which YouTube node/cluster your current IP prefix is currently served by; I have found this to be helpful in the past. -Original Message- From: nanog--- via NANOG mailto:nanog---%20via%20nanog%20%[email protected]%3e>> Reply-To: [email protected]<mailto:[email protected]> To: Mel Beckman mailto:mel%20beckman%20%[email protected]%3e>> Cc: North American Network Operators' Group mailto:North%20American%20Network%20Operators'%20group%20%[email protected]%3e>> Subject: Re: Level3 4.2.2.1 and 4.2.2.2 not responding to pings, DNS queries work Date: Mon, 13 Jan 2025 14:59:27 -0500 Dan’s not here, man! But I’m glad to spread the word so it can help more people in their troubleshoot efforts. -T On Jan 13, 2025, at 10:48, Mel Beckman wrote: Dan, That dig tip for identifying the NS phy loc is very nice! That's something I can put in our support procedures for DNS troubleshooting. -mel
Re: Level3 4.2.2.1 and 4.2.2.2 not responding to pings, DNS queries work
Dan’s not here, man! But I’m glad to spread the word so it can help more people in their troubleshoot efforts. -T > On Jan 13, 2025, at 10:48, Mel Beckman wrote: > > Dan, > > That dig tip for identifying the NS phy loc is very nice! That's something I > can put in our support procedures for DNS troubleshooting. > >-mel
Re: Level3 4.2.2.1 and 4.2.2.2 not responding to pings, DNS queries work
The 4's have definitely had occasional ICMP allergies over the last 20 years. On Sun, Jan 12, 2025 at 11:27 PM Mel Beckman wrote: > Dan, > > Thanks! I had never read that before. But that makes sense. > > -mel > > On Jan 12, 2025, at 8:22 PM, Daniel Sterling > wrote: > > > Seems like these IPs not responding to ping is not unusual, as per > https://www.reddit.com/r/sysadmin/comments/11syv2e/google_dns__dropping_pings_like_crazy_today/ > > "Google has stated multiple times before as has Level3/CenturyLink/Lumen > that 4.2.2.1 and 8.8.8.8 should not be used for ping checks and they will > drop packets when under load or if they notice too much activity from a > single IP" > > -- Dan > > On Sun, Jan 12, 2025 at 11:03 PM Mel Beckman wrote: > >> Still not pinging from Frontier, Lumen, AT&T, or Verizon networks >> >> >> -mel >> >> On Jan 12, 2025, at 4:13 PM, Jerry Cloe wrote: >> >> >> O:\>ping 4.2.2.1 >> >> Pinging 4.2.2.1 with 32 bytes of data: >> Reply from 4.2.2.1: bytes=32 time=36ms TTL=56 >> Reply from 4.2.2.1: bytes=32 time=44ms TTL=56 >> Reply from 4.2.2.1: bytes=32 time=36ms TTL=56 >> Reply from 4.2.2.1: bytes=32 time=38ms TTL=56 >> >> Ping statistics for 4.2.2.1: >> Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), >> Approximate round trip times in milli-seconds: >> Minimum = 36ms, Maximum = 44ms, Average = 38ms >> >> Same for 4.2.2.2 >> >> >> >> >> -Original message- >> *From:* Mel Beckman >> *Sent:* Sun 01-12-2025 06:07 pm >> *Subject:* Level3 4.2.2.1 and 4.2.2.2 not responding to pings, DNS >> queries work >> *To:* [email protected]; >> I noticed that Level3 open DNS 4.2.2.1 and 4.2.2.2 stopped responding to >> ping today. They are responding to DNS queries however. >> >> Does anyone know if this filtering is going to be permanent? >> >> -mel beckman >> >>
Re: Level3 4.2.2.1 and 4.2.2.2 not responding to pings, DNS queries work
Dan, That dig tip for identifying the NS phy loc is very nice! That's something I can put in our support procedures for DNS troubleshooting. -mel From: [email protected] Sent: Monday, January 13, 2025 7:19 AM To: Mel Beckman ; [email protected] Cc: North American Network Operators' Group Subject: Re: Level3 4.2.2.1 and 4.2.2.2 not responding to pings, DNS queries work I’m seeing some of the resolver IPs being filtering from various locations while responding from others, no doubt due to their use of anycast. I rarely ping test 4.2.2.2 anymore, having switched to 8.8.8.8 some time ago which I have a window up running 24x7 as a quick way to detect if my laptop is having connectivity issues from wherever it currently resides. It’s usually reliable, but I understand such traffic is the first to get filtered/dropped when needed so it’s just an initial indicator for me from which further testing can be performed when needed. I will also mention it’s possible to detect which NS server/pool/location you are reaching on Level3’s network via the below dig query. This has been an invaluable tool over the years as IME they tend to break DNS sub-delegation at least once or twice a year and the more data you can provide to them about where the breakage is the faster you can get them to engage the DNS team to actually fix it vs. arguing with you that it’s not broken because it "works for them” (facepalm). And at least once I found they broke resolution on their authoritative name servers (ns1.l3.net<http://ns1.l3.net> or ns2.l3.net<http://ns2.l3.net>) and again they first told me it wasn’t a problem because DNS again the broken one(s) would timeout and then get the answer from another, working server (double-facepalm). dig +short @4.2.2.2 hostname.bind CH TXT I’ve also been provided this query to derive the same for Cloudflare’s NS servers: dig CHAOS TXT id.server @1.1.1.1 +nsid And the following for Cleanbrowsing NS servers (these power content filtering on Unifi networks): nslookup -type=txt iptest.whois.dnscontest.cleanbrowsing.org<http://iptest.whois.dnscontest.cleanbrowsing.org> Below are the results I got for Level3 from various locations (pardon the wall of text). It looks like they’re making some changes to serve DNS queries off their NTP servers >From Level3 WDC1/McLean: PING 4.2.2.1 (4.2.2.1) 56(84) bytes of data. --- 4.2.2.1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.987/0.987/0.987/0.000 ms "pubntp1.wdc12" PING 4.2.2.2 (4.2.2.2) 56(84) bytes of data. --- 4.2.2.2 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.926/0.926/0.926/0.000 ms "cns4.sjo1" PING 4.2.2.3 (4.2.2.3) 56(84) bytes of data. --- 4.2.2.3 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.799/0.799/0.799/0.000 ms "pubntp1.wdc12" PING 4.2.2.4 (4.2.2.4) 56(84) bytes of data. --- 4.2.2.4 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.855/0.855/0.855/0.000 ms "pubntp2.wdc12" PING 4.2.2.5 (4.2.2.5) 56(84) bytes of data. --- 4.2.2.5 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.897/0.897/0.897/0.000 ms "cns4.sjo1" PING 4.2.2.6 (4.2.2.6) 56(84) bytes of data. --- 4.2.2.6 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.973/0.973/0.973/0.000 ms "pubntp1.wdc12” >From Level3 SFO1/Sunnyvale: PING 4.2.2.1 (4.2.2.1) 56(84) bytes of data. --- 4.2.2.1 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 999ms "cns3.sjo1" PING 4.2.2.2 (4.2.2.2) 56(84) bytes of data. --- 4.2.2.2 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms "cns2.sjo1" PING 4.2.2.3 (4.2.2.3) 56(84) bytes of data. --- 4.2.2.3 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms "cns1.sjo1" PING 4.2.2.4 (4.2.2.4) 56(84) bytes of data. --- 4.2.2.4 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms "cns2.sjo1" PING 4.2.2.5 (4.2.2.5) 56(84) bytes of data. --- 4.2.2.5 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.275/0.275/0.275/0.000 ms "cns3.sjo1" PING 4.2.2.6 (4.2.2.6) 56(84) bytes of data. --- 4.2.2.6 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms "cns3.sjo1” >From Comcast Atlanta: PING 4.2.2.1 (4.2.2.1) 56(84) bytes of data. --- 4.2.2.1 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms "cns2.atl2" PING 4.2.2.2 (4.2.2.2) 56(84) bytes of data. --- 4.2
Re: Level3 4.2.2.1 and 4.2.2.2 not responding to pings, DNS queries work
: PING 4.2.2.1 (4.2.2.1) 56(84) bytes of data. --- 4.2.2.1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 2.062/2.062/2.062/0.000 ms "cns2.nyc6" PING 4.2.2.2 (4.2.2.2) 56(84) bytes of data. --- 4.2.2.2 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 2.012/2.012/2.012/0.000 ms "cns2.nyc6" PING 4.2.2.3 (4.2.2.3) 56(84) bytes of data. --- 4.2.2.3 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.651/1.651/1.651/0.000 ms "cns3.nyc6" PING 4.2.2.4 (4.2.2.4) 56(84) bytes of data. --- 4.2.2.4 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 2.055/2.055/2.055/0.000 ms "cns2.nyc6" PING 4.2.2.5 (4.2.2.5) 56(84) bytes of data. --- 4.2.2.5 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 2.102/2.102/2.102/0.000 ms "cns3.nyc6" PING 4.2.2.6 (4.2.2.6) 56(84) bytes of data. --- 4.2.2.6 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.626/1.626/1.626/0.000 ms "cns3.nyc6” From Verizon FIOS New York (oddly from here I get no response to the hostname.bind dig queries): PING 4.2.2.1 (4.2.2.1) 56(84) bytes of data. --- 4.2.2.1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 4.355/4.355/4.355/0.000 ms PING 4.2.2.2 (4.2.2.2) 56(84) bytes of data. --- 4.2.2.2 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 3.764/3.764/3.764/0.000 ms PING 4.2.2.3 (4.2.2.3) 56(84) bytes of data. --- 4.2.2.3 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 4.053/4.053/4.053/0.000 ms PING 4.2.2.4 (4.2.2.4) 56(84) bytes of data. --- 4.2.2.4 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 3.394/3.394/3.394/0.000 ms PING 4.2.2.5 (4.2.2.5) 56(84) bytes of data. --- 4.2.2.5 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 3.442/3.442/3.442/0.000 ms PING 4.2.2.6 (4.2.2.6) 56(84) bytes of data. --- 4.2.2.6 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 4.944/4.944/4.944/0.000 ms From Allied Telecom in Washington DC: PING 4.2.2.1 (4.2.2.1) 56(84) bytes of data. --- 4.2.2.1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.683/1.683/1.683/0.000 ms "pubntp1.wdc12" PING 4.2.2.2 (4.2.2.2) 56(84) bytes of data. --- 4.2.2.2 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.592/1.592/1.592/0.000 ms "pubntp2.wdc12" PING 4.2.2.3 (4.2.2.3) 56(84) bytes of data. --- 4.2.2.3 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.776/1.776/1.776/0.000 ms "cns1.wdc12" PING 4.2.2.4 (4.2.2.4) 56(84) bytes of data. --- 4.2.2.4 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.810/1.810/1.810/0.000 ms "pubntp2.wdc12" PING 4.2.2.5 (4.2.2.5) 56(84) bytes of data. --- 4.2.2.5 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.729/1.729/1.729/0.000 ms "cns1.wdc12" PING 4.2.2.6 (4.2.2.6) 56(84) bytes of data. --- 4.2.2.6 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.432/1.432/1.432/0.000 ms "cns4.sjo1” -T > On Jan 13, 2025, at 07:00, [email protected] wrote: > > Message: 6 > Date: Mon, 13 Jan 2025 04:24:50 + > From: Mel Beckman mailto:[email protected]>> > To: Daniel Sterling <mailto:[email protected]>> > Cc: Jerry Cloe mailto:[email protected]>>, "[email protected] > <mailto:[email protected]>" mailto:[email protected]>> > Subject: Re: Level3 4.2.2.1 and 4.2.2.2 not responding to pings, DNS > queries work > Message-ID: <[email protected] > <mailto:[email protected]>> > Content-Type: text/plain; charset="utf-8" > > Dan, > > Thanks! I had never read that before. But that makes sense. > > -mel > > On Jan 12, 2025, at 8:22?PM, Daniel Sterling <mailto:[email protected]>> wrote: > > ? > Seems like these IPs not responding to ping is not unusual, as per > https://www.reddit.com/r/sysadmin/comments/11syv2e/google_dns__dropping_pings_like_crazy_today/ > > "Google has stated multiple times before as has Level3/CenturyLink/Lumen that &
Re: Level3 4.2.2.1 and 4.2.2.2 not responding to pings, DNS queries work
Working from ATT route server [email protected]> ping 4.2.2.1 PING 4.2.2.1 (4.2.2.1): 56 data bytes 64 bytes from 4.2.2.1: icmp_seq=0 ttl=54 time=8.661 ms 64 bytes from 4.2.2.1: icmp_seq=1 ttl=54 time=9.291 ms 64 bytes from 4.2.2.1: icmp_seq=2 ttl=54 time=9.401 ms ^C --- 4.2.2.1 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 8.661/9.118/9.401/0.326 ms [email protected]> From: NANOG on behalf of Mel Beckman Sent: Sunday, January 12, 2025 7:24 PM To: Jerry Cloe Cc: [email protected] Subject: Re: Level3 4.2.2.1 and 4.2.2.2 not responding to pings, DNS queries work Still not pinging from Frontier, Lumen, AT&T, or Verizon networks -mel On Jan 12, 2025, at 4:13 PM, Jerry Cloe wrote: O:\>ping 4.2.2.1 Pinging 4.2.2.1 with 32 bytes of data: Reply from 4.2.2.1: bytes=32 time=36ms TTL=56 Reply from 4.2.2.1: bytes=32 time=44ms TTL=56 Reply from 4.2.2.1: bytes=32 time=36ms TTL=56 Reply from 4.2.2.1: bytes=32 time=38ms TTL=56 Ping statistics for 4.2.2.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 36ms, Maximum = 44ms, Average = 38ms Same for 4.2.2.2 -Original message- From: Mel Beckman Sent: Sun 01-12-2025 06:07 pm Subject: Level3 4.2.2.1 and 4.2.2.2 not responding to pings, DNS queries work To: [email protected]; I noticed that Level3 open DNS 4.2.2.1 and 4.2.2.2 stopped responding to ping today. They are responding to DNS queries however. Does anyone know if this filtering is going to be permanent? -mel beckman
Re: Level3 4.2.2.1 and 4.2.2.2 not responding to pings, DNS queries work
Dan, Thanks! I had never read that before. But that makes sense. -mel On Jan 12, 2025, at 8:22 PM, Daniel Sterling wrote: Seems like these IPs not responding to ping is not unusual, as per https://www.reddit.com/r/sysadmin/comments/11syv2e/google_dns__dropping_pings_like_crazy_today/ "Google has stated multiple times before as has Level3/CenturyLink/Lumen that 4.2.2.1 and 8.8.8.8 should not be used for ping checks and they will drop packets when under load or if they notice too much activity from a single IP" -- Dan On Sun, Jan 12, 2025 at 11:03 PM Mel Beckman mailto:[email protected]>> wrote: Still not pinging from Frontier, Lumen, AT&T, or Verizon networks -mel On Jan 12, 2025, at 4:13 PM, Jerry Cloe mailto:[email protected]>> wrote: O:\>ping 4.2.2.1 Pinging 4.2.2.1 with 32 bytes of data: Reply from 4.2.2.1<http://4.2.2.1>: bytes=32 time=36ms TTL=56 Reply from 4.2.2.1<http://4.2.2.1>: bytes=32 time=44ms TTL=56 Reply from 4.2.2.1<http://4.2.2.1>: bytes=32 time=36ms TTL=56 Reply from 4.2.2.1<http://4.2.2.1>: bytes=32 time=38ms TTL=56 Ping statistics for 4.2.2.1<http://4.2.2.1>: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 36ms, Maximum = 44ms, Average = 38ms Same for 4.2.2.2 -Original message- From: Mel Beckman mailto:[email protected]>> Sent: Sun 01-12-2025 06:07 pm Subject: Level3 4.2.2.1 and 4.2.2.2 not responding to pings, DNS queries work To: [email protected]<mailto:[email protected]>; I noticed that Level3 open DNS 4.2.2.1 and 4.2.2.2 stopped responding to ping today. They are responding to DNS queries however. Does anyone know if this filtering is going to be permanent? -mel beckman
Re: Level3 4.2.2.1 and 4.2.2.2 not responding to pings, DNS queries work
Seems like these IPs not responding to ping is not unusual, as per https://www.reddit.com/r/sysadmin/comments/11syv2e/google_dns__dropping_pings_like_crazy_today/ "Google has stated multiple times before as has Level3/CenturyLink/Lumen that 4.2.2.1 and 8.8.8.8 should not be used for ping checks and they will drop packets when under load or if they notice too much activity from a single IP" -- Dan On Sun, Jan 12, 2025 at 11:03 PM Mel Beckman wrote: > Still not pinging from Frontier, Lumen, AT&T, or Verizon networks > > > -mel > > On Jan 12, 2025, at 4:13 PM, Jerry Cloe wrote: > > > O:\>ping 4.2.2.1 > > Pinging 4.2.2.1 with 32 bytes of data: > Reply from 4.2.2.1: bytes=32 time=36ms TTL=56 > Reply from 4.2.2.1: bytes=32 time=44ms TTL=56 > Reply from 4.2.2.1: bytes=32 time=36ms TTL=56 > Reply from 4.2.2.1: bytes=32 time=38ms TTL=56 > > Ping statistics for 4.2.2.1: > Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), > Approximate round trip times in milli-seconds: > Minimum = 36ms, Maximum = 44ms, Average = 38ms > > Same for 4.2.2.2 > > > > > -Original message- > *From:* Mel Beckman > *Sent:* Sun 01-12-2025 06:07 pm > *Subject:* Level3 4.2.2.1 and 4.2.2.2 not responding to pings, DNS > queries work > *To:* [email protected]; > I noticed that Level3 open DNS 4.2.2.1 and 4.2.2.2 stopped responding to > ping today. They are responding to DNS queries however. > > Does anyone know if this filtering is going to be permanent? > > -mel beckman > >
Re: Level3 4.2.2.1 and 4.2.2.2 not responding to pings, DNS queries work
no issues here in Houston on gpon from 397412. 3356 has been doing an insane amount of icmp and traceroute filtering on their routers as of late, but the resolver IPs continue to respond with no issues. Based on RTT I assume I am going up to Dallas... may be an issue with the resolvers that are local to you. tim@tb-m3mbp ~ $ ping -c3 4.2.2.1 PING 4.2.2.1 (4.2.2.1) 56(84) bytes of data. 64 bytes from 4.2.2.1: icmp_seq=1 ttl=57 time=6.71 ms 64 bytes from 4.2.2.1: icmp_seq=2 ttl=57 time=6.76 ms 64 bytes from 4.2.2.1: icmp_seq=3 ttl=57 time=6.77 ms --- 4.2.2.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 6.713/6.746/6.772/0.024 ms tim@tb-m3mbp ~ $ ping -c3 4.2.2.2 PING 4.2.2.2 (4.2.2.2) 56(84) bytes of data. 64 bytes from 4.2.2.2: icmp_seq=1 ttl=57 time=9.01 ms 64 bytes from 4.2.2.2: icmp_seq=2 ttl=57 time=6.82 ms 64 bytes from 4.2.2.2: icmp_seq=3 ttl=57 time=6.78 ms --- 4.2.2.2 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 6.778/7.536/9.008/1.040 ms tim@tb-m3mbp ~ $ traceroute 4.2.2.1 traceroute to 4.2.2.1 (4.2.2.1), 30 hops max, 60 byte packets 1 172.29.0.126 (172.29.0.126) [*] 0.127 ms 0.109 ms 0.096 ms 2 136-244-3-1.static.tachusfiber.net (136.244.3.1) [AS397412] 3.401 ms 3.394 ms 3.284 ms 3 hu0-0-0-23.r02.conroe.tx.tachusfiber.net (136.244.1.178) [AS397412] 3.259 ms 3.263 ms 3.285 ms 4 * * * 5 fh0-0-2-0.er01.houston.tx.tachusfiber.net (136.244.1.26) [AS397412] 4.662 ms * * 6 64.154.27.21 (64.154.27.21) [AS3356] 8.422 ms 5.449 ms 8-2-4.bear2.houston1.level3.net (4.2.239.93) [AS3356] 4.997 ms 7 * * * 8 * * * From: NANOG on behalf of Mel Beckman Sent: Sunday, January 12, 2025 6:24 PM To: Jerry Cloe Cc: [email protected] Subject: Re: Level3 4.2.2.1 and 4.2.2.2 not responding to pings, DNS queries work Still not pinging from Frontier, Lumen, AT&T, or Verizon networks -mel On Jan 12, 2025, at 4:13 PM, Jerry Cloe wrote: O:\>ping 4.2.2.1 Pinging 4.2.2.1 with 32 bytes of data: Reply from 4.2.2.1: bytes=32 time=36ms TTL=56 Reply from 4.2.2.1: bytes=32 time=44ms TTL=56 Reply from 4.2.2.1: bytes=32 time=36ms TTL=56 Reply from 4.2.2.1: bytes=32 time=38ms TTL=56 Ping statistics for 4.2.2.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 36ms, Maximum = 44ms, Average = 38ms Same for 4.2.2.2 -Original message- From: Mel Beckman Sent: Sun 01-12-2025 06:07 pm Subject: Level3 4.2.2.1 and 4.2.2.2 not responding to pings, DNS queries work To: [email protected]; I noticed that Level3 open DNS 4.2.2.1 and 4.2.2.2 stopped responding to ping today. They are responding to DNS queries however. Does anyone know if this filtering is going to be permanent? -mel beckman
Re: Level3 4.2.2.1 and 4.2.2.2 not responding to pings, DNS queries work
Still not pinging from Frontier, Lumen, AT&T, or Verizon networks -mel On Jan 12, 2025, at 4:13 PM, Jerry Cloe wrote: O:\>ping 4.2.2.1 Pinging 4.2.2.1 with 32 bytes of data: Reply from 4.2.2.1: bytes=32 time=36ms TTL=56 Reply from 4.2.2.1: bytes=32 time=44ms TTL=56 Reply from 4.2.2.1: bytes=32 time=36ms TTL=56 Reply from 4.2.2.1: bytes=32 time=38ms TTL=56 Ping statistics for 4.2.2.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 36ms, Maximum = 44ms, Average = 38ms Same for 4.2.2.2 -Original message- From: Mel Beckman Sent: Sun 01-12-2025 06:07 pm Subject: Level3 4.2.2.1 and 4.2.2.2 not responding to pings, DNS queries work To: [email protected]; I noticed that Level3 open DNS 4.2.2.1 and 4.2.2.2 stopped responding to ping today. They are responding to DNS queries however. Does anyone know if this filtering is going to be permanent? -mel beckman
RE: Level3 4.2.2.1 and 4.2.2.2 not responding to pings, DNS queries work
O:\>ping 4.2.2.1 Pinging 4.2.2.1 with 32 bytes of data: Reply from 4.2.2.1: bytes=32 time=36ms TTL=56 Reply from 4.2.2.1: bytes=32 time=44ms TTL=56 Reply from 4.2.2.1: bytes=32 time=36ms TTL=56 Reply from 4.2.2.1: bytes=32 time=38ms TTL=56 Ping statistics for 4.2.2.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 36ms, Maximum = 44ms, Average = 38ms Same for 4.2.2.2 -Original message- From:Mel Beckman Sent:Sun 01-12-2025 06:07 pm Subject:Level3 4.2.2.1 and 4.2.2.2 not responding to pings, DNS queries work To:[email protected]; I noticed that Level3 open DNS 4.2.2.1 and 4.2.2.2 stopped responding to ping today. They are responding to DNS queries however. Does anyone know if this filtering is going to be permanent? -mel beckman
Level3 4.2.2.1 and 4.2.2.2 not responding to pings, DNS queries work
I noticed that Level3 open DNS 4.2.2.1 and 4.2.2.2 stopped responding to ping today. They are responding to DNS queries however. Does anyone know if this filtering is going to be permanent? -mel beckman
