5.90.28.209 recurrently not responding from Spain – only zepto-mad reachable
Hi,
We are experiencing a recurring issue (not just today) where one of our linked-IP resolvers stops responding from our main internet connection in Spain:
- 45.90.28.209 → no response (DNS queries time out, ping 100% loss)
- 45.90.30.209 → works fine
From external services (e.g. ping.eu) 45.90.28.209 responds normally, so the problem seems to be the route/PoP reached from our ISP.
Because of this, our DNS servers frequently fall back to our secondary resolvers, and NextDNS filtering is not applied consistently.
ping.nextdns.io result:
zepto-mad 8 ms (ultralow2)
anycast.dns1.nextdns.io error (anycast1)
anycast.dns2.nextdns.io error (anycast2)
dns1.nextdns.io error (ultralow1)
Traceroute to 45.90.28.209 (stops after 37.19.193.233; first hops inside our ISP omitted):
7 194.30.8.154 7.7 ms
8 213.249.106.141 7.9 ms
9 * * *
10 213.19.221.98 34.4 ms
11 37.19.193.233 34.5 ms
12 * * *
13 * * *
Update – diagnostic results
I managed to run the nextdns.io/diag tool. Public IP and the first hops (local network/ISP edge) have been hidden for privacy.
Summary:
- Anycast primary (45.90.28.0) is unreachable from our ISP: the route dies after 37.19.193.233.
- Anycast secondary (45.90.30.0) works, but routes us to vultr-fra (~36 ms), even though anexia-mad / zepto-mad are reachable at ~8 ms.
Testing IPv6 connectivity
available: false
Fetching https://test.nextdns.io
status: ok
client: [hidden]
protocol: UDP
dest IP: 45.90.30.209
server: vultr-fra-1
Fetching PoP name for ultra low latency primary IPv4 (ipv4.dns1.nextdns.io)
anexia-mad: 7.951ms
Fetching PoP name for ultra low latency secondary IPv4 (ipv4.dns2.nextdns.io)
zepto-mad: 12.78ms
Fetching PoP name for anycast primary IPv4 (45.90.28.0)
Fetch error: Get "https://dns.nextdns.io/info": dial tcp 45.90.28.0:443: connection timed out
Fetching PoP name for anycast secondary IPv4 (45.90.30.0)
vultr-fra: 36.277ms
Pinging PoPs
anexia-mad: 7.791ms
zepto-mad: 8.097ms
zepto-lis: 14.837ms
anexia-lis: 22.11ms
netbarista-par: 23.432ms
zepto-mil: 28.985ms
virtua-par: 34.065ms
anexia-mil: 35.723ms
anexia-zrh: 50.045ms
anexia-par: 24.634ms
Traceroute for ultra low latency primary IPv4 (217.146.1.31)
[hops 1-3 hidden]
4 194.30.8.93 2ms 2ms 2ms
5 194.30.8.58 7ms 7ms *
6 194.30.8.61 12ms 7ms 7ms
7 193.149.1.17 7ms 7ms 7ms
8 87.245.238.163 7ms 7ms 8ms
9 213.227.186.32 8ms 16ms 8ms
10 217.146.1.31 7ms 7ms 7ms
Traceroute for ultra low latency secondary IPv4 (194.156.155.239)
[hops 1-3 hidden]
4 194.30.8.93 2ms 3ms 2ms
5 194.30.9.122 2ms 2ms 2ms
6 194.30.8.166 3ms 3ms 29ms
7 194.30.9.50 2ms 2ms 2ms
8 194.30.8.154 22ms 16ms 8ms
9 213.249.106.141 10ms 8ms 9ms
10 171.75.8.105 9ms 9ms 9ms
11 213.242.105.246 8ms 8ms 9ms
12 84.17.33.97 15ms 24ms 8ms
13 194.156.155.239 8ms 8ms 8ms
Traceroute for anycast primary IPv4 (45.90.28.0)
[hops 1-3 hidden]
4 194.30.8.93 2ms 2ms 2ms
5 194.30.9.122 2ms 2ms 2ms
6 194.30.8.166 2ms 2ms 4ms
7 194.30.9.50 2ms 2ms 2ms
8 194.30.8.154 7ms 7ms 7ms
9 213.249.106.141 8ms 8ms 8ms
10 * * *
11 213.19.221.98 35ms 34ms 34ms
12 37.19.193.233 34ms 34ms 34ms
13-20 * * *
error: context deadline exceeded
Traceroute for anycast secondary IPv4 (45.90.30.0)
[hops 1-3 hidden]
4 194.30.8.93 2ms 2ms 2ms
5 * * *
6 194.30.8.61 8ms 7ms 10ms
7 193.149.1.36 8ms 7ms 7ms
8 129.250.2.204 8ms 8ms 8ms
9 129.250.2.60 23ms 23ms 23ms
10 129.250.5.32 33ms 33ms 33ms
11 129.250.2.9 34ms 34ms 34ms
12 212.119.15.18 33ms 33ms 33ms
13-15 * * *
16 45.90.30.0 35ms 35ms 36ms
Could you please check why anycast primary (45.90.28.0) is unreachable from this route, and why anycast secondary sends us to Frankfurt instead of Madrid? Thanks.
2 replies
-
Update: 45.90.28.209 started responding again at 12:03 CEST (10:03 UTC) without any change on our side. It had been failing since at least 11:39 CEST (monitoring started then; the issue began earlier in the morning). Response time is now ~35 ms, so we still seem to be routed to a distant PoP instead of Madrid (~8 ms). We’ll keep monitoring and report if it fails again.
-
Update: 45.90.28.209 is responding again since 12:03 CEST. ICMP traceroute now reaches it through the exact same path as during the outage (213.19.221.98 → 37.19.193.233 → 45.90.28.209, ~34 ms), so the outage was on the PoP itself, not routing. This has happened to us repeatedly. Could you check the stability of this PoP? We’re also being routed to it (~34 ms) instead of the Madrid PoPs (~8 ms).
Content aside
- 8 hrs agoLast active
- 2Replies
- 25Views
-
1
Following
