0

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

null
    • Iker_R
    • 12 hrs ago
    • Reported - view

    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.

    • Iker_R
    • 12 hrs ago
    • Reported - view

    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