up_the_irons: Heads-up I've been alerted to some IPv6 issues with ARP's transit/routing over the past day or so, reported as connection timeouts from the NTP pool monitoring; IPv4 connections to the same hosts at the same times were fine. I don't have first-hand data except that my own SSH connection had died at some point. Sorry that's all the details I can give. Here's zeit.arpnetworks.com in IPv6 https://www.ntppool.org/scores/2607:f2f8:0:102::2317 and v4 https://www.ntppool.org/scores/208.79.89.249 (If you click "CSV log" you can see exactly when the "i/o timeouts" occurred) (PS: In case I wasn't clear, I noticed this on my own VPSes too, in addition to zeit.arpnetworks.com - just figured I'd explicitly mention ARP's "stake" in this) brycec: those times are UTC, right? m0unds:looks like it, at least in the CSV log cool, thanks - my monitoring showed some packet loss on ipv6 around the same time as two of the events in the csv (my monitoring is low res since it's just personal stuff) in the past when we saw ipv6 only issues it often used to be more ipv6 goign through he.net i wonder if there's a good system for recording routes at the time of issues mercutio: my monitoring does come in via he.net fwiw does your ipv4 monitoring also? the recording route changes thing has bugged me a for a long time, as at the time you can figure it out ok but in retrospect it's harder yeah, it does cross he, but at the far end but if you want to hack something up to do monitoring and alerting you don't want to get false positives from normal route changes of routers etc, so it would require a few smarts atlanticmetro/any2ix/he yeah, mine's just 5 minute ping/port monitoring; latency isn't a huge deal cuz it's just my personal crap (uptimerobot) yaeh i mostly care about packet loss as a measure these days tbh ike even if latency jumps up by 80 msec if there isn't packet loss it's not going to be severely degrading but if you have 5% packet loss or something even if ping is good it's going to be very very painful https://github.com/catalyst/smokeping-mtr-alert problem is if you measure packet loss every 5 minutes you don't get quick notifications or to see good granaulity dne yeh that'd be good, i suppose you could potentially just recor every so often normal route too hmm actually even if it's not perfect it's still going to be damn useful on it's own! yup my main issue with smokeping is it doesn't scale down to small step sizes well so most people won't monitor with more granuality than a minute i've been iterating over an idea in my head of a better smokeping type system for higher granuality like ping every second or 10 times a second or such depending on where to main issue with that kind of thing is storing in a db synchronously, but if you're ok with losing some data, you don't need to write every time you ping