New Vercel IPs 216.198.79.1 & 64.29.17.1 unreachable from AS28668 (Brazil); legacy works

Open Source
1

Since ~June 8, my domains were unreachable (eternal loading). Captured from the
affected network: ISP AS28668 (Desktop Sigmanet), Jaú/SP, Brazil, public IP
187.109.133.157.

Root cause: the “.1” host of each new Vercel anycast block is black-holed from
my ISP, while the “.65” host of the SAME block, and the legacy IPs, work fine.

-– ping (NEW IPs) —
216.198.79.1 → 4 packets transmitted, 0 received, 100.0% packet loss
64.29.17.1 → 4 packets transmitted, 0 received, 100.0% packet loss
216.198.79.65 → 0.0% packet loss (works)
64.29.17.65 → 0.0% packet loss (works)

-– traceroute 216.198.79.1 (dies mid-path) —
4 189.1.144.66 7.131 ms
5 10.100.0.165 7.067 ms
6 *
7 * … (all * up to hop 30)

-– traceroute 64.29.17.1 (dies mid-path) —
4 189.1.144.66 7.840 ms
5 * … (all * to hop 30)

-– TCP 443 —
216.198.79.1 → timeout
64.29.17.1 → timeout
216.198.79.65 → HTTP 307 (ok)
64.29.17.65 → HTTP 307 (ok)

-– legacy IPs (work) —
76.76.21.142 → ping 0% loss, HTTPS 200
66.33.60.66 → ping 0% loss, HTTPS 200

Domains: aglenos.com, www.aglenos.com, app.aglenos.com, aglenos.app,
www.aglenos.app. Apex/CNAMEs that resolved to the “.1” hosts were down; those on
“.65” worked. Temporary fix: repointed all CNAMEs to cname.vercel-dns.com
(legacy), which restored service.

Ask: please check the BGP/route announcement for 216.198.79.1 and 64.29.17.1
toward AS28668 — looks like the .1 hosts of 216.198.79.0/24 and 64.29.17.0/24
aren’t reaching this network.

2

Hi Rodrigo,

This is a strong repro. Since the .65 hosts in the same ranges work, the legacy IPs work, but the .1 hosts fail for both ICMP and TCP/443 from AS28668, I would not treat this as an app/build issue or normal DNS propagation.

It looks more like a route/filtering problem for those specific Vercel anycast endpoints from that ISP path.

If you can, I’d add TCP-based traces too, since ICMP can be filtered differently from HTTPS traffic:

mtr -T -P 443 -rwzc 100 216.198.79.1
mtr -T -P 443 -rwzc 100 64.29.17.1
mtr -T -P 443 -rwzc 100 216.198.79.65
mtr -T -P 443 -rwzc 100 64.29.17.65

And a direct HTTPS comparison:

curl -Iv --connect-timeout 10 --resolve aglenos.com:443:216.198.79.1 https://aglenos.com/
curl -Iv --connect-timeout 10 --resolve aglenos.com:443:216.198.79.65 https://aglenos.com/

The useful summary is:

Affected ISP/ASN: AS28668
Region: Jaú/SP, Brazil
Fails: 216.198.79.1 and 64.29.17.1
Works: 216.198.79.65, 64.29.17.65, and legacy endpoints
Failure type: TCP/443 timeout, not app 4xx/5xx
Temporary workaround: legacy CNAME restored service

I’d also send the same evidence to the ISP if possible. From the community side, this is probably enough to show the domain config itself is not the main problem.