[15:13:03] having ipv6 routing issues for bits.wikimedia.org where's the correct place to report this? It's between tele2.net and wikimedia.org [15:15:13] hi, could you send a traceroute? [15:15:35] sure, to pastebin? [15:15:43] that could work [15:15:57] the answer to your question is probably noc@wikimedia.org, but maybe I can help now [15:17:03] http://pastebin.com/259wsEve [15:18:10] If I drop cogent as peer we see you ok via l3, I can open a ticket with cogent if it's the right end to do it from [15:20:11] it's strange that tele2 is producing the unreachable [15:20:18] we peer with them iirc [15:20:36] so, yeah, better try mailing noc@, I'll make sure to follow up [15:20:49] it is indeed. can you see what route you have for 2a02:3d8::/32 [15:21:01] also, the reason you see only bits as the problem is that we were having some problems on Sunday and redirected just bits to the US [15:21:22] so you hit our cluster in Amsterdam for everything but bits and the US for bits [15:21:37] this is temporary and we're going to revert that, probably tomorrow European morning [15:21:49] ahh, so prehaps soem old routes and broken bgp someplace? I have flushed our ipv6 session with cogent a couple of times to see if that helped [15:21:58] but in any case we should deal with the root of your issue [15:22:28] no, this was probably an issue before and when we switched DNS it became apparent to you [15:25:37] ok mail sent to noc@ from brendan.minish@westnet.ie [15:26:32] we are a memeber of https://ring.nlnog.net/ so I can send you a ring trace if that might be helpful [15:27:18] okay [15:28:24] I am a member of the operations team but I don't normally do network stuff. we have people on the team that specialize on that and they'll know better [15:29:23] sound, appreceate the help, it's hard to deploy ipv6 to customers if it 'breaks stuff' ;-) [15:31:20] I'm looking at the AS path between Tampa (one of our US DCs) and 2a02:3d8::/32 [15:31:37] it goes through one of our transits, then Cogent then you [15:32:35] that would be correct [15:33:23] the rign trace is pretty but not very helpful in this instance ;-) [15:33:51] I've heard of the ring but haven't seen it in action yet [15:34:00] sounds definitely interesting [15:34:04] maybe we should participate too [15:34:44] it's really helpful for us little operators [15:37:20] ringtrace here http://westnet.ie/bits.png [15:44:42] ring-ping says 2620:0:860:ed1a::a - unreachable via: lagis01 digmia01 siminn01 iabg01 claranet02 claranet05 inotel01 westnet01 nessus01 nexellent01 [15:46:48] how interesting [15:47:11] okay, I followed up on your email internally [15:47:52] I'm looking at Cogent's looking glass [15:48:00] we're basically unreachable from Cogent [15:48:02] that's bad [15:58:52] paravoid: bit odd though how it's all fine until the far side of tele2.net [15:59:18] indeed [16:01:51] hmm, I think it's something internal to us [16:15:11] paravoid: well let me know if want us to open a ticket with cogent [16:15:33] no I don't think cogent is at fault here [16:15:36] it's either us or tele2 [16:16:40] ok, well when you think you have a solution I'll be happy to ring-ping again for you to see if the unreacables have gone away [16:36:39] What's happend with the thumbnails ? --->> http://commons.wikimedia.org/wiki/File:Panoramica_de_la_Isla_de_San_Carlos,_Estado_Zulia.jpg [16:41:13] urgh [16:41:21] * Damianz pokes paravoid [16:41:45] Insufficient memory/missing an image filename errors on thumbnail generation [16:42:55] Damianz: are you from Venezuela? [16:43:03] nope [16:43:05] Damian Finnol? [16:43:16] ok, thanks [16:43:26] Some idea for fix this problem? [16:45:39] The image is rather huge so it seems the imagescaler is bailing due to memory requirements on generating the thumbnail, not much I can do about it possibly reedy or such might have an idea that isn't 'make the image smaller' [16:46:31] lol [16:46:58] i wonder how much memory it'd actually need to scale that.. [16:47:09] Damianz: T_T [16:47:14] It's *still* loading the full image for me heh [16:47:14] Else, VIPScaler? [16:51:02] What's VIP Scaler? [16:53:18] wilfredor: https://www.mediawiki.org/wiki/Extension:VipsScaler [18:59:56] wilfredor's image seems a classic interlaced problem [19:18:11] it is: Interlace: JPEG [20:18:16] paravoid: any progress on the ipv6 routing issue ? [20:26:21] bminish: not really, no. we don't have a weekend shift. [20:27:43] that's ok [20:57:13] bminish: I'm suprised, an ISP in the british isles provdig ivp6 in the British Isles? (other than A&A ;)) [20:58:30] Reedy: I'd not consider us as part of the british Isles ;-) [20:58:49] Geographically you are! [20:59:00] Policitically? Meh :p [21:01:44] Reedy: geographically speaking it does depend on who draws the maps ;-) [21:02:37] Anyway IPv6 is important, it's going to get very ugly in the next few years WRT access to ipv4 via nasty carrier grade nat hacks [21:03:14] WRT? [21:03:26] yeah, CGN is going to mean a lot of collateral damage [21:03:27] 'With respect to ' [21:03:37] unless IPv6 is also used [21:04:26] On an interesting note, the wiki with the most IPv6 blocking seems to be frwiki [21:04:45] with about 1 block a day [21:05:18] blocking being done your side for abuse ? [21:05:25] sysops [21:05:52] do you block on /64 or on /128 [21:06:01] generally /128 first [21:06:20] and at the sight of a single hopping of IPs, the /64 [21:06:36] I used to support blocking /64s by default, but now I'm an opponent of it. [21:06:41] (except webhosts) [21:07:03] The reason is that a /64 may still represent many users, such as in a whole office building [21:08:00] yeah, we have been giving /56's out in general but I dont't think we have a single customer yet that has used anything except a single /64 for everything on site [21:08:36] ^ [23:08:26] gn8 folks