O.k. i re checked and from my site there seems to be all in healthy state, except that my server now gets reported as being some bits ahead of time... well, has nothing to do with this IPv6 hickup i think....
anyways: root@heraklon:~# date && dig AAAA ntplax7.ntppool.net Sun May 21 18:20:48 UTC 2017 ; <<>> DiG 9.9.5-9+deb8u11-Debian <<>> AAAA ntplax7.ntppool.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55540 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;ntplax7.ntppool.net. IN AAAA ;; ANSWER SECTION: ntplax7.ntppool.net. 7200 IN AAAA 2607:f238:2::17 ;; Query time: 88 msec ;; SERVER: 91.204.168.2#53(91.204.168.2) ;; WHEN: Sun May 21 18:20:48 UTC 2017 ;; MSG SIZE rcvd: 65 root@heraklon:~# traceroute6 ntplax7.ntppool.net traceroute to ntplax7.ntppool.net (2607:f238:2::17), 30 hops max, 80 byte packets 1 ipv6gw.smart-kvm.com (2a00:1aa0:c001:c0de::4000) 0.350 ms 0.342 ms 0.335 ms 2 2a00:1aa0:c001:c0de::10 (2a00:1aa0:c001:c0de::10) 2.656 ms 2.791 ms 3.344 ms 3 2a01:4a0:1338:68::1 (2a01:4a0:1338:68::1) 0.630 ms 0.592 ms 0.521 ms 4 ae1-2001.fra10.core-backbone.com (2a01:4a0:0:2001::3) 3.644 ms 3.639 ms 3.624 ms 5 2001:1900:5:2:2::651 (2001:1900:5:2:2::651) 3.977 ms 3.967 ms 3.959 ms 6 lo-0-v6.ear1.Frankfurt1.Level3.net <http://lo-0-v6.ear1.frankfurt1.level3.net/> (2001:1900:2::3:10c) 4.164 ms 4.103 ms 4.080 ms 7 GTT-level3-4x10G.Frankfurt.Level3.net <http://gtt-level3-4x10g.frankfurt.level3.net/> (2001:1900:5:3::52) 4.060 ms 4.059 ms 4.041 ms 8 et-8-1-0.cr2-lax2.ip6.gtt.net (2001:668:0:2:ffff:0:5995:8209) 153.419 ms 153.385 ms 153.577 ms 9 te7-2.r02.lax2.phyber.com (2001:668:0:3::8000:2a02) 164.427 ms 164.413 ms 164.633 ms 10 2607:f238:0:8::2 (2607:f238:0:8::2) 164.342 ms 163.953 ms 163.955 ms 11 ntplax7.ntppool.net (2607:f238:2::17) 163.229 ms !X 163.205 ms !X 163.249 ms !X root@heraklon:~# By the way, we have again? or still? some gumtree account on this list. Can the list maintainer please check that? ;) Have a nice weekend anyways, D. hackbtye Mitzlaff ;) 2017-05-22 1:20 GMT+02:00 Arnold Schekkerman <[email protected]>: > Hi, > > A traceroute from the monitor to my server goes over ntt.net from USA, to > NL. > > The route from my system to the monitor goes over cogentco.com from NL to > USA-LAX. > > Tcpdump shows my server gets requests from the monitor and sends replies. > > Last Friday I spoke to a security officer of a large bank. That person is > amongst > others responsible to handle DDoS attacks. He told (and showed) me NTP > monlist is > still used very often in a DDoS. This is no real surprise as a hacker that > gains > root permissions on a Linux box can easily enable monlist. To them NTP is > very > efficient... > > I hope the large network operators will allow the packages with 48 bytes > of UDP > payload whenever the filter udp port 123, instead of filtering it all. > > Kind regards, > Arnold > > > On 21-05-17 21:49, Marco Senft wrote: > > Hi Lucas, > > > >> [...] > >> As far as the claim that the problem inherently resides with the > monitoring > >> node because of RIPE Atlas probes goes, that would be foolish to say the > >> least. Peering issues are a very real thing. Only the windows desktop > had a > >> missed probe on one of the hops (timed out) and the hop before and > after it > >> were with the same network (Comcast, who is my ISP). > > > > Well, as far as I understand from the conversation so far, nobody blamed > the monitoring node for the problems. I completely agree with you that a > peering/routing issue is most probably the root cause of it. However that's > just an educated guess, the only thing we can tell for sure is that the > monitoring incorrectly states many servers as being unreachable. > > > >> I'm really inclined to suspect transatlantic issues at this time. If > someone has > >> a server they can probe over into the UK from somewhere like Ashburn, > >> Virginia: please probe with a traceroute over IPv6. North America > Peering > >> seems solid at the moment. > > > > ntplax7.ntppool.net resolves to 2607:f238:2::17, which belongs to > AS7012. Unfortunately, that AS does not seem to host any (public) Atlas > probes. I created two more measurements pinging and tracerouting the > monitoring system only from probes located within the US: > > https://atlas.ripe.net/measurements/8759687/#!probes > > https://atlas.ripe.net/measurements/8759888/#!probes > > Apparently not only transatlantic connections are affected, but also > peerings within the USA. Whatever the reason is, I hope somebody takes care > of this ASAP. > > > > Cheers, > > marco > > _______________________________________________ > > pool mailing list > > [email protected] > > http://lists.ntp.org/listinfo/pool > > > > > > _______________________________________________ > pool mailing list > [email protected] > http://lists.ntp.org/listinfo/pool > _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
