I was notified that a user in #debian-mirrors reported a connectivity issue to our ftp.us.debian.org mirror (2620:0:861:1:208:80:154:15 aka sodium), for "about a week now".
However, the information that we have is already enough to pinpoint at least one issue:
The route for the first hop is 2603:6080::/28 and for the subsequent four, 2606:a000::/32, so both fairly broad and with that customer of theirs is probably in there as well.
Both of those routes have 2001:504:0:2::7843:1, as the next-hop, i.e. Charter's router on the Equinix IXP. The routes are learned through the peering that cr2-eqiad (and only cr2-eqiad) has with that IP. So for cr1-eqiad, the source of the route is cr2-eqiad; the 2001:504:0:2::/64 destination, however, is direct, through its own IXP port, xe-3/0/6.
firstname.lastname@example.org> show ipv6 neighbors |match 2001:504:0:2::7843:1 2001:504:0:2::7843:1 2e:21:31:00:2f:9c reachable 4 yes no xe-3/3/3.0 email@example.com> show ipv6 neighbors |match 2001:504:0:2::7843:1 2001:504:0:2::7843:1 none unreachable 1 no no xe-3/0/6.0
sodium's active VRRP gateway is cr1-eqiad.
The report was IPv6-specific and did not mention IPv4. However:
firstname.lastname@example.org> ping count 2 184.108.40.206 PING 220.127.116.11 (18.104.22.168): 56 data bytes --- 22.214.171.124 ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss email@example.com> ping count 2 126.96.36.199 PING 188.8.131.52 (184.108.40.206): 56 data bytes 64 bytes from 220.127.116.11: icmp_seq=0 ttl=64 time=1.308 ms 64 bytes from 18.104.22.168: icmp_seq=1 ttl=64 time=0.828 ms --- 22.214.171.124 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.828/1.068/1.308/0.240 ms
(126.96.36.199 being 7843's IPv4 on the IXP)
My guess would be that this is Charter filtering traffic on their IXP port to only routers they have peerings with, for security/anti-DDoS reasons.
I'm not sure if this is because we gave them our router's MAC address when we peered, or if they're doing that by means of ARP/NDP with the IP of the router they peer with. More broadly, our setup right now is "cr2-eqiad has the peering but cr1-eqiad can and will send you traffic", which is probably unusual and breaks network ingress assumptions that exist out there.