Seems they fixed it. I did check their route server to see what was going on, here's the before and after: Broken: RP/0/RSP0/CPU0:route-server.newyork.ny.ibone#show bgp 202.12.27.33 Mon Aug 26 19:51:23.615 utc BGP routing table entry for 202.12.27.33/32 Versions: Process bRIB/RIB SendTblVer Speaker 918848884 918848884 Last Modified: Jun 18 02:40:29.577 for 3y10w Paths: (1 available, best #1, not advertised to EBGP peer) Not advertised to any peer Path #1: Received by speaker 0 Not advertised to any peer 64650, (received & used) 66.208.229.9 from 66.208.229.9 (96.109.22.250) Origin IGP, metric 0, localpref 300, valid, internal, best, group-best Received Path ID 0, Local Path ID 0, version 918848884 Community: 7922:403 7922:2900 no-export Fixed: RP/0/RSP0/CPU0:route-server.newyork.ny.ibone#show bgp 202.12.27.33 Mon Aug 26 22:20:06.647 utc BGP routing table entry for 202.12.27.0/24 Versions: Process bRIB/RIB SendTblVer Speaker 1100876456 1100876456 Last Modified: May 6 23:17:19.747 for 3y16w Paths: (1 available, best #1) Not advertised to any peer Path #1: Received by speaker 0 Not advertised to any peer 3257 7500, (aggregated by 7500 202.12.27.167), (received & used) 66.208.229.9 from 66.208.229.9 (96.109.22.227) Origin IGP, metric 0, localpref 250, valid, internal, atomic-aggregate, best, group-best Received Path ID 0, Local Path ID 0, version 1100876456 Community: 7922:403 7922:3000 Originator: 96.109.22.227, Cluster list: 96.109.22.250, 96.109.22.50 For whatever reason they had 202.12.27.33/32 entered into their routing table. I Wonder why they would have done that... On 8/26/24 11:52, Bryan Holloway wrote:
Same here in East Central Illinois. v4 fails; v6 works.
Trace stops in Chicago.
On 8/26/24 03:54, Thomas Wodarek wrote:
I'm getting similar results on residential Comcast up here in Michigan, US (Comcast's Heartland region). Checking from a Google Cloud vm in Iowa, US, I was able to reach m.root-servers.net <http://m.root-servers.net> via both v4 and v6, but it looks like it's routing to the Sao Paulo cluster in both cases (looking at https://m.root-servers.org/ <https://m.root-servers.org/>, I would have assumed it would have routed to SF's cluster)
test-instance-3:~$ ping m.root-servers.net <http://m.root-servers.net> PING m.root-servers.net <http://m.root-servers.net>(M.ROOT-SERVERS.NET <http://M.ROOT-SERVERS.NET> (2001:dc3::35)) 56 data bytes 64 bytes from M.ROOT-SERVERS.NET <http://M.ROOT-SERVERS.NET> (2001:dc3::35): icmp_seq=1 ttl=63 time=141 ms 64 bytes from M.ROOT-SERVERS.NET <http://M.ROOT-SERVERS.NET> (2001:dc3::35): icmp_seq=2 ttl=63 time=141 ms 64 bytes from M.ROOT-SERVERS.NET <http://M.ROOT-SERVERS.NET> (2001:dc3::35): icmp_seq=3 ttl=63 time=141 ms ^C --- m.root-servers.net <http://m.root-servers.net> ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 140.752/140.903/141.091/0.140 ms
test-instance-3:~$ dig +short m.root-servers.net <http://m.root-servers.net> 202.12.27.33
test-instance-3:~$ ping 202.12.27.33 PING 202.12.27.33 (202.12.27.33) 56(84) bytes of data. 64 bytes from *MailScanner warning: numerical links are often malicious:* 202.12.27.33 <http://202.12.27.33>: icmp_seq=1 ttl=254 time=143 ms 64 bytes from *MailScanner warning: numerical links are often malicious:* 202.12.27.33 <http://202.12.27.33>: icmp_seq=2 ttl=254 time=140 ms 64 bytes from *MailScanner warning: numerical links are often malicious:* 202.12.27.33 <http://202.12.27.33>: icmp_seq=3 ttl=254 time=141 ms ^C --- 202.12.27.33 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 140.387/141.368/143.146/1.259 ms
test-instance-3:~$ traceroute -I m.root-servers.net <http://m.root-servers.net> traceroute to m.root-servers.net <http://m.root-servers.net> (202.12.27.33), 64 hops max 1 * * * 2 142.251.64.24 140.646ms 140.640ms 140.749ms 3 187.16.215.148 140.371ms 140.292ms 140.314ms 4 202.12.27.33 139.841ms 140.324ms 139.980ms
test-instance-3:~$ dig -x 187.16.215.148 ... 148.215.16.187.in-addr.arpa. 6423 IN PTR as7500.saopaulo.sp.ix.br <http://as7500.saopaulo.sp.ix.br>. ...
test-instance-3:~$ traceroute6 m.root-servers.net <http://m.root-servers.net> traceroute to m.root-servers.net <http://m.root-servers.net> (2001:dc3::35) from 2600:1900:4000:d977:0:1::, 30 hops max, 24 byte packets 1 * * * 2 2001:4860:0:1::7cd8 (2001:4860:0:1::7cd8) 140.1891 ms 140.0114 ms 140.0064 ms 3 as7500.saopaulo.sp.ix.br <http://as7500.saopaulo.sp.ix.br> (2001:12f8::215:148) 140.7670 ms 140.7445 ms 140.7408 ms 4 M.ROOT-SERVERS.NET <http://M.ROOT-SERVERS.NET> (2001:dc3::35) 140.5523 ms 140.4191 ms 140.4163 ms
On Sun, Aug 25, 2024 at 8:18 PM Crist Clark <cjc+nanog@pumpky.net <mailto:cjc%2Bnanog@pumpky.net>> wrote:
Debated whether to bring this up on the OARC DNS Ops list or NANOG. Seem more of a network-y thing.
I happened to notice that I cannot query or ping m.root-servers.net <http://m.root-servers.net>'s IPv4 address from my home Comcast connection (SF Bay Area). IPv6 works. All of the other root servers are reachable via both IPv4 and IPv6.
Just me or all Comcast users?
Obviously, nothing critical. My DNS servers will work just fine with one root unavailable on one protocol. But curious what's broken. Been this way for at least a couple of weeks.
Compare IPv4 and IPv6 traceroutes,
Mac-Air:~ fred$ traceroute -I m.root-servers.net <http://m.root-servers.net>
traceroute to m.root-servers.net <http://m.root-servers.net> (202.12.27.33), 64 hops max, 72 byte packets
1moat (192.168.64.90)3.004 ms1.409 ms1.155 ms
210.60.234.131 (10.60.234.131)14.354 ms17.153 ms14.451 ms
3po-313-1222-rur202.pleasanton.ca.sfba.comcast.net <http://po-313-1222-rur202.pleasanton.ca.sfba.comcast.net> (96.110.179.157)14.296 ms11.150 ms11.279 ms
4po-200-xar02.pleasanton.ca.sfba.comcast.net <http://po-200-xar02.pleasanton.ca.sfba.comcast.net> (68.85.155.117)11.752 ms10.195 ms11.783 ms
5be-248-rar01.pleasanton.ca.sfba.comcast.net <http://be-248-rar01.pleasanton.ca.sfba.comcast.net> (96.108.99.129)14.261 ms11.228 ms13.187 ms
6be-398-ar01.hayward.ca.sfba.comcast.net <http://be-398-ar01.hayward.ca.sfba.comcast.net> (162.151.87.225)13.577 ms13.552 ms13.725 ms
7* * *
8* * *
9* * *
10* * *
11* * *
12*^C
Mac-Air:~ fred$ traceroute6 -I m.root-servers.net <http://m.root-servers.net>
traceroute6 to m.root-servers.net <http://m.root-servers.net> (2001:dc3::35) from 2601:644:8f01:3b0:c842:51d6:e589:5203, 64 hops max, 16 byte packets
12601:644:8f01:3b0:4262:31ff:fe01:b81.753 ms1.765 ms1.343 ms
22001:558:101e:54::214.526 ms26.113 ms32.365 ms
3po-313-1221-rur201.pleasanton.ca.sfba.comcast.net <http://po-313-1221-rur201.pleasanton.ca.sfba.comcast.net>28.170 ms14.109 ms11.374 ms
4po-200-xar01.pleasanton.ca.sfba.comcast.net <http://po-200-xar01.pleasanton.ca.sfba.comcast.net>11.746 ms20.031 ms42.526 ms
5* * *
6* * *
7* * *
8lo-0-v6.ear2.sanjose1.level3.net <http://lo-0-v6.ear2.sanjose1.level3.net>15.106 ms14.454 ms13.240 ms
9pt.telekomu.edge1.losangeles9.level3.net <http://pt.telekomu.edge1.losangeles9.level3.net>15.921 ms17.188 ms16.294 ms
10m.root-servers.net <http://m.root-servers.net>17.032 ms15.169 ms14.892 ms
-- *Max Goodell * Network Technician 🦆