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
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
Still not pinging from Frontier, Lumen, AT&T, or Verizon networks
-mel
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 * * *
Seems like these IPs not responding to ping is not unusual, as per https://www.reddit.com/r/sysadmin/comments/11syv2e/google_dns_8888_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
Dan,
Thanks! I had never read that before. But that makes sense.
-mel
Working from ATT route server…
rviews@route-server.ip.att.net> 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
The 4’s have definitely had occasional ICMP allergies over the last 20 years.