[02:38] *** hazardous has quit IRC (Quit: Lost terminal) [05:30] *** ben2 has joined #arpnetworks [05:30] *** mercutio has quit IRC (Ping timeout: 250 seconds) [09:36] kellytk: Normally what you've described is resolved by set keep-state [09:37] (I tried looking at your pf.conf but it's been removed already) [09:37] *set keep state [09:37] i think [09:38] oh my bad, it's this: [09:38] block return [09:38] pass [09:39] That establishes the "keep state" for connections [09:40] (Overall my point is that the default pf.conf, at least in OpenBSD, has no problems) [10:23] fsck my cc company, gonna have to use bloody paypal mc instead [10:23] they got real assy after i bought things on play [10:58] bummer [12:32] *** hive-mind has quit IRC (Ping timeout: 260 seconds) [12:42] *** ben2 is now known as mercutio [13:15] brycec: http://pastebin.com/6uGA28JM is my ruleset [13:16] FYI, it's for FBSD's port of pf [13:18] *** hive-mind has joined #arpnetworks [13:20] Well assuming it's similar enough to OpenBSD's, then yeah your block by default isn't helping ;P [13:21] (it's blocking everything including the return acks) [13:21] ime it's nearly the same as openbsd's pf [13:21] (same) [13:21] i love pf [13:21] Differs when it comes to specifics like queueing [13:21] yeah [13:21] but its common features are the same [13:21] yup [13:22] like most languages with regional dialects :p [13:23] bryce, which line? [13:23] "block log all"? [13:38] Is the traffic being blocked in http://pastebin.com/kzSv01i5 important? It looks like it's related to DNSSEC resolution but I'm not positive [14:09] You blocked the response from a DNS server. It happens to be a request for a DNSKEY record, but I don't think that's why it was blocked. It was blocked by rule 1, "block log all" [14:10] heh [14:11] (you can confirm which active with "pfctl -sr" of course) [14:11] brycec: What I would like to do is block all, and selectively pass [14:11] udp is nasty [14:11] That's what she said!! [14:11] well at least if you want to send out udp packets and get them back [14:11] Yeah, states and UDP... [14:12] http://pastebin.com/afQv0gj5 is the output of pfctl -sr [14:12] if you allow all responses from port 53, then people can taget any udp ports on your host just by using a source port of 53 [14:12] there's no direction with udp, ... [14:12] there are helpers, but they can have issues too [14:13] and i don't think pf supports any of those fancy helper things. [14:13] (tftp-proxy...) [14:13] (siproxd...) [14:13] tftp-proxy is transparent isn't it? [14:13] *** carvite has quit IRC (Ping timeout: 240 seconds) [14:13] err i mean, you redirect the port to a local host [14:13] rather than inline [14:13] i suppose it makes no diff [14:14] anyway, if you use the same external recursive dns you can allow source/destination ip with all ports for udp [14:16] I'm not finding a way to flush Unbound's cache totally (http://unbound.net/documentation/unbound-control.html) Am I missing something? [14:19] *** carvite has joined #arpnetworks [14:20] reload Reload the server. This flushes the cache and reads the config [14:20] file fresh. [14:20] ^ [14:22] I just found that, thank you :-) [14:24] While running `host update.freebsd.org` the states are http://pastebin.com/bHVa3GDL [14:39] unbound-control flush * [14:40] or that [14:40] hahaha [14:41] staticsafe: Are you sure? [14:41] That gave odd output when I tried it [14:42] root@lasciel:~# unbound-control flush * [14:42] ok [14:43] staticsafe: http://pastebin.com/BKvQCAMc [14:43] thats a shell interpretation problem [14:43] I use tcsh [14:43] try quoting the whole thing [14:44] What do you mean by whole thing? [14:44] "/usr/local/sbin/unbound-control flush *" [14:44] /usr/local/sbin/unbound-control flush "*" worked [14:44] or that [14:44] Thanks for the tip staticsafe [14:45] np [14:45] So I'm back to the firewall not allowing name resolution [14:46] i didn't realise reload flushes the cache on unbound [14:46] that's kind of sub-optimal [14:46] that would not be valid :P staticsafe | "/usr/local/sbin/unbound-control flush *" [14:46] i have found that reload tends to crash out though, so i've been doing restarts... [14:46] (Unless you have an executable named "unbound-control flush *" of course) [14:47] ah true [14:47] which is also sub-optimal [14:47] that's with ubuntu trusty, i haven't checked to see if it's got better since then. [14:51] http://pastebin.com/1kZ66MPk is a summary of the ruleset problem I'm having [14:56] I'm getting the impression /usr/local/sbin/unbound-control flush "*" doesn't actually flush. Results return immediately, whereas after a `service unbound restart` results take a moment [14:57] Something else interesting is `host google.com` returns with the firewall up, however `host update.freebsd.org` does not [15:03] *** carvite has quit IRC (Ping timeout: 246 seconds) [15:06] *** carvite has joined #arpnetworks [15:06] possible you are dropping EDNS queries at the firewall [15:06] i would suggest adjusting your DNS rules [15:07] flush the cache, do queries for google.com and freebsd.org and check firewall log [15:07] staticsafe: Is http://pastebin.com/J3x6PgQA what you mean? [15:08] I recall having to add the last line in the past, but when I've looked for recent info on it I only found mailing lists, no docs [15:09] edns0 (since glibc 2.6) [15:09] sets RES_USE_EDNSO in _res.options. This enables support for the DNS extensions described in RFC 2671. [15:09] that is on linux [15:09] Which man page? [15:09] man resolv.conf [15:11] FreeBSD's resolve.conf man page doesn't include an explanation of the option unfortunately [15:12] its probably not a valid option then [15:13] the difference between google.com and freebsd.org is that freebsd.org is DNSSEC signed which requires EDNS queries to validate [15:14] Ok that's what I suspected. So is it likely that the pf ruleset is blocking DNSSEC, but not regular DNS? [15:15] its breaking EDNS in some way yes [15:15] That's what she said!! [15:16] kellytk: http://lists.freebsd.org/pipermail/freebsd-net/2007-May/014190.html [15:16] BryceBot: no [15:16] Oh, okay... I'm sorry. 'its breaking EDNS in some way yes' [15:16] staticsafe: IPv6 isn't necessary for this, correct? [15:16] no [15:16] pf is dropping the fragments [15:17] pass out quick on $pub_if inet proto udp from $pub_if to any port $out_udp_services keep state > pass out quick on $pub_if inet proto udp from $pub_if to any port $out_udp_services keep state keep frag? [15:21] staticsafe: What are fragments? [15:23] http://www.dnssec-deployment.org/tag/udp-fragments/ [15:30] Unbound has a edns-buffer-size configuration option to help, however is it correct to think that the better solution is to modify the pf ruleset to allow fragments? [15:34] staticsafe: Thoughts on using scrub fragment reassemble? [15:44] This is strange. Two identically configured FreeBSD boxes on my LAN, each having "scrub fragment reassemble" added to pf.conf, one can resolve update.freebsd.org and the other cannot [15:53] i do not know, i don't have experience with pf [15:53] Which firewall do you use? [16:01] Two identically configured boxes on the LAN (except for differing pf.conf), working pf.conf http://pastie.org/private/o6exhdd0wgyofhf0htcq and the broken pf.conf http://pastie.org/private/paf0wnaik0i49l2q0cxyyq [16:03] Ok this is odd, when I drop the firewall on the broken box and rerun `host update.freebsd.org`, it still returns "Host update.freebsd.org not found: 3(NXDOMAIN)" [16:03] up_the_irons brycec mercutio : I emailed softlayer yesterday about the domain they hadn't registered. No response and it is still not registered. [16:04] mnathani_: hahahaha [16:04] Register it and redirect to a lolcats? [16:04] well you've given them fair warning [16:04] * brycec owns too many domains as is, and isn't feeling overly dickish today. [16:04] direct it to ovh [16:04] lolol [16:04] would be embarassing for them [16:04] or worse, GoDaddy [16:05] set the nameserver expiry times insanely long [16:05] and direct to goatse [16:05] i dunno it depends how much you want to stir :) [16:06] I would rather they fix it [16:06] yeah :) [16:06] as one of my clients is about to become a customer of theirs [16:06] That's what she said!! [16:06] BryceBot: nbo [16:06] BryceBot: no [16:06] Oh, okay... I'm sorry. 'as one of my clients is about to become a customer of theirs' [16:06] you could just register it and set the name registration to their name servers [16:07] you could register it, and say that you got no response and go public [16:07] and say you're willing to give it to them at cost [16:07] I wouldnt want to risk a lawsuit [16:07] but going public without registering it first would be irresponsible [16:07] i thought you were in canada for some reaosn [16:07] I am in Canada [16:08] they have a datacenter here also [16:08] oh, i thought that protected you from US lawsuits for the most part. [16:08] at least frivilous ones. [16:12] apparently there's a big el nino thing happening soon [16:12] close to Mexico? [16:12] and july was the hottest recorded month on average around the world. [16:13] across huge areas afaik [16:13] across pacific ocean it seems [16:15] i'm trying to find something more moderate and balanced rather than alarming [16:15] not to much avail [16:16] http://www.thedailybeast.com/articles/2015/09/01/we-re-worse-off-than-ever-for-el-ni-o.html [16:16] this seems better than most [16:17] it's still a bit alarming though. [16:18] kellytk: i use iptables for the most part [16:18] i'd love to see some fear mongering about when we don't have el nino patterns [16:19] there's the non el nino pattern too [16:19] i know [16:19] but no fear mongering [16:19] hmm, apparently el nino may bring rain to california [16:19] SW US enjoys el nino because it means we get rain [16:19] and it means we have fewer forest fires [16:19] heh [16:19] winter here hasn't been neraly as wet or stormy as last year. [16:20] .w [16:20] i wonder what would happen if someone registered that softlayer domain [16:20] hm what was the trigger [16:20] @weather [16:20] mercutio: Fetching weather for your previous query (akl). [16:20] staticsafe: A greater oddity has arisen. With firewalls disabled, one server correctly resolves `host update.freebsd.org` whereas the other server returns ";; connection timed out; no servers could be reached" [16:20] Auckland International, New Zealand: Mostly Cloudy ☁ 57°F (14°C), Humidity: 82%, Wind: From the West at 28 MPH -- For more details including the forecast and almanac, see http://www.wunderground.com/cgi-bin/findweather/getForecast?query=-37.00805664,174.79167175 or re-request this with: @weather -v [16:20] m0unds: i don't want to know enough to risk a lawsuit [16:20] well [16:20] staticsafe: lol [16:20] UDRP process maybe [16:21] maybe brycebot can register it [16:21] be a sport [16:21] eh even if somebody did, Softlayer has certainly enough money and lawyers to file a UDRP [16:21] which would be decided in their favour [16:21] "The selection and placement of stories on this page were determined automatically by a computer programme. " [16:22] does google news spell program as programme for other people too? [16:22] probably localization [16:22] or is it trying to use US vs UK spelling. [16:22] e.g. you're in a place where that might be normal [16:22] here it's normal to call computer programs, programs. [16:22] but if you have an event or something you may have a programme [16:22] would you otherwise say UK english is pretty typical? [16:22] yeah. [16:22] ok [16:22] What's sorta weird is news.google.com shows "program" even though my language is en-UK [16:23] Perhaps because this is the "U.S. edition" [16:23] i don't even remember seeing that statement before. [16:23] it says programme on news.google.co.uk [16:23] it says program on news.google.com w/en_us [16:23] It has said it for a long time [16:24] brycec: maybe it is IP geo-locating you [16:24] :P [16:24] *** kellytk has left "WeeChat 1.0.1" [16:24] i'm on www.google.co.nz with news tab [16:24] it says program on co.nz [16:24] for me [16:24] lol I switched edition to UK and now it's programme https://news.google.com/?edchanged=1&ned=uk&authuser=0 [16:24] google is mysterious [16:24] brycec: probably just didn't notice [16:24] hahaha [16:24] i don't usually scroll down all the way [16:25] And when I switch it to France edition, it's all in french, including programmae [16:25] *programme [16:25] * m0unds waits for google to tell brycec to make up his mind [16:25] we can't profile you if we don't know where you are and what language you want [16:25] how do you switch editions [16:25] i tried appending &ned=us and it's still programme [16:25] "But Google, I care about the world and speak multiple languages!" [16:25] mercutio: there's a drop-down for me [16:26] based on your search history, we can confirm you're a liar [16:26] https://dl.dropboxusercontent.com/u/3167967/screenshot_2015-09-02_16-23-29.png [16:26] redirecting to pig latin edition [16:26] oh that looks totally different [16:27] i don't even have the top stories on the left [16:27] ahh goign to news.google.com is different [16:27] And just for completeness https://dl.dropboxusercontent.com/u/3167967/screenshot_2015-09-02_16-24-39.png [16:27] *** carvite has quit IRC (Ping timeout: 252 seconds) [16:28] the american news is more disturbing [16:30] for some strange reason australia tells me about another china chemical explosion. [16:30] *** carvite has joined #arpnetworks [16:30] i wonder how they decide what's important for different regions. [16:31] Australia? like the whole entire country at once, shouting it across the sea? :D [16:31] australia google news dition [16:31] there's actually no china english edition [16:31] Whatever, I liked my mental image better. [16:31] australia just shouting about a chemical explosion [16:32] what would australia sound like? [16:33] not sure [16:34] @google site:youtube.com Australians shouting [16:34] 2,490 total results returned for 'site:youtube.com Australians shouting', here's 3 [16:34] A century worth shouting about. 100 years of the Royal Australian ... (http://www.youtube.com/redirect?event=stream_redirect&q=http%3A%2F%2Fwww.insidehistory.com.au%2F2013%2F10%2Fa-century-worth-shouting-about%2F&usg=VVFYdiLaFnMweikWVjKABUmaEh4=) Oct 3, 2013 ... Lindsey Shaw, formerly a Senior Curator at the Australian National Maritime Museum, starts a series of four articles on the history of the Royal ... [16:34] Are you God? Crazy guy shouting on Australian Train - YouTube (http://www.youtube.com/watch?v=uq5DzvqJma0) Dec 19, 2013 ... Are you God? Crazy guy shouting on Australian Train. ... Are you God? Crazy guy shouting on Australian Train. MCARDLEPRODUCTIONS. [16:34] Construction Workers Shouting Catcalls Women Can Appreciate ... (http://www.youtube.com/redirect?event=stream_redirect&q=http%3A%2F%2Fwallstreetinsanity.com%2Fconstruction-workers-shouting-catcalls-women-can-appreciate-video%2F&usg=4V43l-ajdmbsmA1yXc9ZQTPShKc=) Mar 27, 2014 ... Snickers has released a new ad in Australia that has good intentions, ... The builders then shouted loud, empowering statements at the women ... [16:34] are you god video sounds like it might be a winner [16:34] * m0unds loads [16:34] well then [16:35] I am suitably amused. [16:35] Especially the part where they try and push him off/down [16:35] yeah [16:35] imagining him screaming about chemical explosions [16:35] Needs more female voices shouting too though [16:36] haha [16:42] Java based IPMIs make me sad [16:56] the ipmi isn't java based [16:56] it's the kvm that is java [16:56] yeah thats what I meant [16:56] you can use ipmitool and serial console to get around it [16:57] and you can reboot etc with ipmitool too [16:57] but yeah java isn't even supported in chrome anymore :( [16:57] and it never really seemed that great. [17:31] *** mnathani_ has quit IRC (Read error: No route to host) [17:31] *** mnathani_ has joined #arpnetworks [17:54] https://www.snellman.net/blog/archive/2015-09-01-the-most-obsolete-infrastructure-money-could-buy/ [18:02] *** kellytk has joined #arpnetworks [18:03] I figured out the Unbound resolution issue. After removing the search domain, all became well. It's an imperfect solution as I made use of the search domain feature however [18:36] Has anyone seen "Could not establish a chain of trust to keys for ntp.org. DNSKEY IN" in unbound.log? In the course of research it seems to be possibly related to pf ruleset + UDP fragmentation, however my pf ruleset should handle frags with its `scrub fragment reassemble` option, so I'm confused [19:15] dnssec is probably going to occur over TCP [19:15] do you handle tcp fragmentation? [19:15] That's what she said!! [19:16] gizmoguy: http://pastie.org/private/imat8lhakzvxkt0fbytmla is my entire pf.conf [19:16] I don't believe I do [19:17] FWIW I'm using the FreeBSD pf port. Can you suggest any improvements to my ruleset? [19:18] you shouldn't really have to handle fragmentation differently [19:18] That's what she said!! [19:18] also I can't say I've used pf before.. [19:19] hold up [19:19] is ntp.org even signed? [19:20] no it's not [19:20] I don't know [19:21] I would suspect that's why DNSSEC to ntp.org fails [19:21] So that failure is normal? [19:22] maybe? [19:22] *** milki has quit IRC (Ping timeout: 256 seconds) [19:23] *** grody has quit IRC (Remote host closed the connection) [19:23] *** milki has joined #arpnetworks [19:23] *** grody has joined #arpnetworks [19:23] BryceBot: no [19:23] Oh, okay... I'm sorry. 'you shouldn't really have to handle fragmentation differently' [19:24] What is the purpose of that bot BTW? [19:24] gross packet loss [19:24] @last m0unds_ [19:24] gizmoguy, I last saw m0unds_ 4 sec ago saying in a channel: gross packet loss. [19:24] can't even stay connected to my VM via ipv6 [19:24] Oh [19:24] ipv6 is for losers [19:25] I've switched to IPv9. [19:25] block log quick inet6 all [19:25] mike-burns: how is v9? do your pakkitz travel at least 15% faster than the speed of light? [19:25] i run chimiak-enhanced-ipv4 [19:25] they arrive before they were transmitted [19:25] Yes but that makes them very loud. [19:25] best ipv4 [19:25] https://tools.ietf.org/html/draft-chimiak-enhanced-ipv4-00 [19:25] hahaha [19:26] basically he removes some cruft from the ipv4 header and lets you use 64bit ipv4 addresses [19:26] for some reason it didn't take off [19:26] funny [19:27] ah yes, NTT return path shittiness [19:28] just saw 50% packet loss at s3, then my session died [19:28] sweet [19:34] gizmoguy: that sounds like a good idea [19:34] mercutio: anything going on w/ipv6? [19:34] m0unds: nothing diff from usual that i know about [19:34] i thought it was ntt being stupid, but i keep seeing packet loss at s3 incrementing, then my ssh session drops when it hits 50% [19:35] wow [19:35] i'm seeing something funky [19:35] with ntt too hah [19:35] wtf [19:35] it's not even all ntt, .. [19:35] hmm and i trace again and it's fine [19:36] yeah, it's fine right now [19:36] yeah i was tracing to www.kame.net [19:36] give it a minute, it'll get weird again [19:36] it's getting worse now [19:36] oh it's going funky again [19:36] yeah [19:36] haha [19:36] and it hits japan ok [19:36] then it hits another router in japan and starts dropping [19:37] me -> arp via ipv6 goes comcast -> he -> arp [19:37] in both directions? [19:37] nah, outbound to arp only [19:37] return is ntt [19:37] outbound to arp is worse [19:37] ntt is just regular old flaky ntt [19:37] i'm not well situated for ipv6 test sites atm [19:38] it seems like it's just v6 that's acting up though, for sure [19:38] vultr in sydney seems fine atm [19:38] because i'm still connected via v4 [19:38] but i'll keep it going [19:38] and that goes level3, not ntt [19:38] bah late hops on vult just screwed up [19:39] and of course there's no reverse lookups and 12 hops... [19:39] hahaha [19:39] *** grody has quit IRC (Remote host closed the connection) [19:39] just hit...75% loss and dropped [19:39] *** grody has joined #arpnetworks [19:40] toggling asn info isn't working [19:40] if you press z does it tell you asn's in mtr? [19:40] negative, it's not doing it [19:40] used to [19:40] damnit [19:41] it's working on my vm [19:41] maybe it only ever worked with ipv4 [19:41] what version of mtr are you? [19:41] 0.86 [19:41] i have .86 on fbsd and .82 on deb [19:41] oh [19:41] on openbsd [19:41] hm [19:41] and 0.85 on linux [19:41] neither are working [19:41] it's working on freebsd but not debian on an rpi [19:41] weird [19:41] hahaha [19:41] it's showing loss from vultr in the same way [19:42] vultr mostly use ntt afaik [19:42] oh, -z isn't a flag on .82 that's why [19:42] 2402:7800 [19:42] i'm pressing inside the app [19:42] hmm 2402:7800 is vocus [19:42] so vultr's screwing up on vocus [19:43] before hitting arp even [19:44] vultr is vocus in both directions [19:44] not ntt [19:44] although i'm not sure what 2001:504:13::210:136 is [19:45] it's probably coresite though [19:45] coresite [19:45] yea [19:45] this is whack though [19:45] i'm mtr'ing in both directions, and one way is showing much more loss than the other [19:47] and my smokeping has been broken for 40 minutes too [19:49] wtf [19:49] 40 minutes ago it got TERM signals [19:50] so i have no ipv4 smokepings to look at [19:51] but if i look at sydney's smokeping stuff to arp there was some loss a couple of hours ago [19:51] so there may be concurrent vocus and ntt issues [19:53] *** mhoran has quit IRC (Ping timeout: 256 seconds) [19:58] *** mhoran has joined #arpnetworks [19:58] *** ChanServ sets mode: +o mhoran [19:59] i'm struggling to determine any consistent patterns [19:59] *** KDE_Perry has quit IRC (Read error: Connection reset by peer) [19:59] *** KDE_Perry has joined #arpnetworks [20:03] it's only www.kame.net i saw the severe loss pattern too [20:09] oh another bind crash vulnerability [20:18] yup [20:20] did coresite die? [20:20] looks like the route changed, outbound from me to arp changed from he to ntt, and return path is still ntt [20:23] lol, he's lg at one wilshire looks awful [20:24] awful to arp or awful in general? [20:24] awful in general [20:24] hmm [20:24] yeah not sure what's happening tbh [20:24] 800ms to me from lax @ coresite [20:24] hahaha [20:24] ouch [20:25] vs 35ms to me from equinix [20:25] pinging arpnetworks.com via coresite lg = 750ms [20:26] it seems a lot of disparate failures at once [20:26] yeah [20:26] so i'm wondering what the connection is [20:26] it may fibre cut [20:26] there was fibre cut in san francisco the other day [20:26] maybe there were more [20:27] i think it's up to like 13 in the last year? [20:27] of reported cuts around there [20:27] yea [20:28] but they seem to cluster a bit [20:28] oh well, weird as hell [20:28] time for planetside [20:28] it does make me think i should setup better ipv6 monitoring though :) [20:29] yea, i have just long interval ping monitoring via uptimerobot [20:34] *** brycec has quit IRC (Ping timeout: 244 seconds) [20:34] *** brycec has joined #arpnetworks [20:40] *** milki has quit IRC (Ping timeout: 256 seconds) [20:41] *** milki has joined #arpnetworks [20:59] Am I the only one getting horribly network activity? [20:59] i worded that badly [21:00] oh a quick skim of the backlog is ffffffasfl;jksadjkladljkasdjkl;sdjkl;asjkl;asjkl;asasdfjkasdfjkasdf[ [21:00] it hung again ^ [21:01] I'll have to get more info, but looks like I haven't been alone [21:07] brycec: i liked your mental image better too [21:08] Thanks. When a country can work together as one voice, it's always great. [21:08] Now, wtf is up with my connection???. I have too much shit to get done to debug this stuff. [21:08] https://smokeping.cobryce.com/?target=ARP shows some nasty IPv6 latency and spikes since 5pm [21:08] (inside ARP) [21:09] And it's really fucking with my SSH session. [21:10] I feel so dirty, connected to my VPS over IPv4 [21:10] but hopefully it's smoother [21:11] (Hm an mtr I've left running for awhile from my VPS to an ipv6 host shows 3% packet loss starting at the second hop 2001:504:13::1a, that would be the first hop beyond ARP. [21:14] Aw I had 30 days connected to this Freenode server too, lost due to the network issues I was seeing. [21:15] aha [21:15] 2001:504:13::1a is an Any2 IX peer [21:16] At this very second, it's dropping packets for me [21:16] Just started flowing [21:17] dropping [21:18] flowing [21:18] (that was 45 seconds dropping) [21:18] dropping [21:19] flowing after 36 seconds [21:20] dropping [21:20] brycec: mine was working via v4 [21:20] v6 was terribad for a long while [21:20] flowing [21:21] (I also dropped 2 packets to ARP's router :O) [21:21] that's what it was doing for me too - it was bad when my v6 route was via he [21:21] (that was another 42 seconds of dropped packets) [21:21] but it seemed to change the last time i tracerouted and it was using ntt instead [21:21] dropping... [21:21] Wow [21:21] the coresite he lg was hosed - 900ms to itself, 900ms to arp, 900ms to other stuff [21:21] This is... [21:21] That's what she said!! [21:22] flowing [21:22] hahaha [21:22] 52 seconds, and again 2 dropped @ ARP [21:22] dropping... [21:24] flowing, 52 seconds agin [21:24] this is cray cray [21:24] looks like it drops every 90 seconds or so for about 52 seconds [21:35] (I should point out that HE is involved in all directions and destinations to which I have access - I can't mtr from a non-HE address besides ARP) [21:38] Well it's not the cleanest way to share two mtr's but it works :P Issue is that he.net->ntt.net handoff it looks like https://dl.dropboxusercontent.com/u/3167967/screenshot_2015-09-02_21-35-05.png [21:38] Dear up_the_irons please to be fixing upstream's issue, kthx [22:31] brycec: there were issues with just ntt in both directions too [22:31] and there were issues with vocus/any2ix [22:36] brycec: did it come right? [22:44] Still craptastic [22:45] Dropped up to a few seconds even [22:45] *a few seconds ago [22:45] And there it goes dropping again [22:46] flowing again [22:46] (but it's not worth flooding the channel, and I have better things to do.) [23:04] got an ip address can trace to to reproduce? [23:05] 2607:f2f8:a650::3 [23:05] from arp i mean :) [23:05] 2001:470:4:2a5::feed:dead [23:05] cool [23:06] that coresite hop having high pings suggests the router is under heavy cpu load [23:06] I'm happy to say in the last 60 seconds, I've only dropped 1 packet in mtr. [23:06] Agreed. [23:06] (I figure it will sort itself out soon enough) [23:06] aka "eventually" [23:07] yeah i was thinking that a couple of hours ago [23:07] even across any2ix direct it does that [23:07] knock on wood but it's looking more stable right now. [23:13] i'm seeing around 0.7% loss [23:14] 11/500 packets dropped [23:14] that's like 2% loss [23:14] i have 3 out of 519 dropped [23:18] (% without context can be a bit hard to grasp. 50% of 2 packets vs 500 can indicate very different things :P) [23:20] yeah [23:20] can be different if they're all dropped in a row etc too [23:27] sounds better [23:35] Running Unbound, is there a reason why a fresh start up is often met with a random number of failures (0-~5) to resolve update.freebsd.org, but not google.com? I suspect the former being signed and the latter not has something to do with it [23:40] *** hive-mind has quit IRC (Ping timeout: 246 seconds)