***: m0unds has quit IRC (Ping timeout: 250 seconds)
m0unds has joined #arpnetworks
r0ni has quit IRC (Remote host closed the connection)
r0ni has joined #arpnetworks
mhoran has quit IRC (Read error: Connection reset by peer)
m0unds has quit IRC (Quit: derp)
mhoran has joined #arpnetworks
ChanServ sets mode: +o mhoran
m0unds has joined #arpnetworks brycec: 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) ***: qbit is now known as Guest44593
Guest44593 has quit IRC (Quit: leaving)
qbit_ has joined #arpnetworks
qbit_ is now known as qbit m0unds: brycec: those times are UTC, right? brycec: m0unds:looks like it, at least in the CSV log ***: hive-mind has quit IRC (Ping timeout: 245 seconds)
hive-mind has joined #arpnetworks m0unds: 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) mercutio: 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 m0unds: mercutio: my monitoring does come in via he.net
fwiw mercutio: 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 m0unds: yeah, it does cross he, but at the far end mercutio: 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 m0unds: 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) mercutio: 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 dne: https://github.com/catalyst/smokeping-mtr-alert mercutio: 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! dne: yup mercutio: 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