#arpnetworks/ 2019-08-29,Thu

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)

WhoWhatWhen
***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)
brycecup_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)
[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)
m0undsbrycec: those times are UTC, right? [11:13]
................. (idle for 1h20mn)
brycecm0unds: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)
m0undscool, 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]
mercutioin 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]
m0undsmercutio: my monitoring does come in via he.net
fwiw
[13:45]
mercutiodoes 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]
m0undsyeah, it does cross he, but at the far end [13:47]
mercutiobut 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]
m0undsatlanticmetro/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]
mercutioyaeh 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]
dnehttps://github.com/catalyst/smokeping-mtr-alert [13:49]
mercutioproblem 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]
dneyup [13:52]
mercutiomy 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)