| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When | |
|---|---|---|---|
| *** | lfam has quit IRC (Quit: Leaving) | [00:10] | |
| m0unds has quit IRC (Ping timeout: 250 seconds)
m0unds has joined #arpnetworks | [00:20] | ||
| .................................................................... (idle for 5h38mn) | |||
| r0ni has quit IRC (Remote host closed the connection) | [05:58] | ||
| ........ (idle for 36mn) | |||
| r0ni has joined #arpnetworks | [06:34] | ||
| ..... (idle for 23mn) | |||
| 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 | [06:57] | ||
| ..................... (idle for 1h40mn) | |||
| 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
(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) | [08:38] | |
| ......................... (idle for 2h3mn) | |||
| *** | qbit is now known as Guest44593
Guest44593 has quit IRC (Quit: leaving) qbit_ has joined #arpnetworks qbit_ is now known as qbit | [10:43] | |
| ...... (idle for 27mn) | |||
| m0unds | brycec: those times are UTC, right? | [11:13] | |
| ................. (idle for 1h20mn) | |||
| brycec | m0unds:looks like it, at least in the CSV log | [12:33] | |
| ...... (idle for 28mn) | |||
| *** | hive-mind has quit IRC (Ping timeout: 245 seconds)
hive-mind has joined #arpnetworks | [13:01] | |
| ....... (idle for 33mn) | |||
| 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) | [13:34] | |
| 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 | [13:41] | |
| m0unds | mercutio: my monitoring does come in via he.net
fwiw | [13:45] | |
| 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 | [13:45] | |
| m0unds | yeah, it does cross he, but at the far end | [13:47] | |
| 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 | [13:47] | |
| 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) | [13:47] | |
| 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 | [13:49] | |
| dne | https://github.com/catalyst/smokeping-mtr-alert | [13:49] | |
| 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! | [13:50] | |
| dne | yup | [13:52] | |
| 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 | [13:52] | |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |