- NZNOG - lists.nznog.org

Re: [nznog] Win10 downloads causing UFB congestion?
by Regan Murphy 11 Aug '15

11 Aug '15

Chris Keall wrote up this in the NBR yesterday with a "yeah....nah". (paywalled) http://www.nbr.co.nz/opinion/digital-island-windows-10-upgrades-are-congest… -- Regan ________________________________ From: Juha Saarinen<mailto:juha(a)saarinen.org> Sent: ‎8/‎12/‎2015 9:17 AM To: nznog<mailto:NZNOG(a)list.waikato.ac.nz> Subject: [nznog] Win10 downloads causing UFB congestion? Hello NZNOG, I was reading this: http://www.nzherald.co.nz/business/news/article.cfm?c_id=3&objectid=11495508 <http://www.nzherald.co.nz/business/news/article.cfm?c_id=3&objectid=11495508> just now, which says the Windows 10 upgrade is overwhelming capacity on the UFB (which bit of it?). It’s a single source however, and I was wondering if there are other data points for the traffic increase to look at? Not sure if this is operational as such, so please email me off-list if so. Thanks — Juha _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

1 0

Re: [nznog] Win10 downloads causing UFB congestion?
by Scott Weeks 11 Aug '15

11 Aug '15

--- scott(a)scottpettit.nz wrote: From: Scott Pettit <scott(a)scottpettit.nz> puff piece designed to spread FUD for Digital Island's own -------------------------------------- Funny, I worked for another Digital Island that existed in Hawaii from the mid-1990s to ~2002. We had PoPs all over the world including NZ. It was bought by C&W and these guys took up the name 2 years later according to their "about us" page. Until now I never heard of them... scott _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

1 0

Traffic on Akl-IX
by Jesse Archer 09 Aug '15

09 Aug '15

Hey all, A quick heads up about our experience on Akl-IX (community IX based in Auckland, presence in 220 Queen and Vocus Albany). This past week we've seen our traffic coming in via the IX double, in part thanks to Microsoft peering and the Windows 10 updates that are hammering everyone's networks right now :) Also recent growth in peers - I see Compass are on-boarding and a couple of other operators I've spoken with are peering shortly. There are some large content providers on the IX, either directly connected or via "host member ISPs" - so if you've been considering peering and access to content might be a driver for on-boarding and you would like some more info, please speak to Joe Wooller of WAIA on peering(a)akl-ix.nz or you can drop me an email. If you're from: Voyager ICONZ Trade Me Sitehost HD Mediaworks ...I'd love to see you on the IX as we do a bit of traffic each day and the current inbound and outbound paths are not as optimal as they could be. *Jesse Archer* *General Manager*Full Flavour *p. *07 577 0099 *ddi*. 07 281 1391 *s*. Skype "myfullflavour" *e*. jesse(a)fullflavour.nz <jesse(a)fullflavourmedia.co.nz> *w*. fullflavour.nz <http://www.fullflavourmedia.co.nz/> *a. *Basestation, 148 Durham Street, Tauranga *a*. PO Box 16306, Bethlehem 3176, New Zealand

8 9

Some name server changes, SkyTV and Paymark
by paul tinson 09 Aug '15

09 Aug '15

Hi There, I wanted to notify the list that anyone operating recursive resolvers would be wise to flush the following zones from the cache: *.skytv.co.nz *.paymarkclick.co.nz Lastnight the name servers for these where switched to ns1, ns2 and ns3.spark.co.nz. The TTL on the NS record was 24hrs at the time of change so these could still be in cache as the old record. Regards Paul

2 2

Chorus CCIL availability
by Jonathon Exley 05 Aug '15

05 Aug '15

Hi NOGers, The Chorus Co-Innovation Lab (CCIL) is being upgraded to a new software release in preparation for a UFB production upgrade later this year. The Wellington and Auckland nodes will bounce several times today and tomorrow, as we exercise the upgrade and rollback procedures. [cid:image001.jpg(a)01CF4F55.0ABA26E0] Jonathon Exley Network Specialist Layer 2 T +64 4 896 4190 M +64 27 514 8048 E jonathon.exley(a)chorus.co.nz<mailto:jonathon.exley(a)chorus.co.nz> Level 8, State Insurance Tower, 1 Willis Street Wellington www.chorus.co.nz<http://www.chorus.co.nz/> Aon Hewitt Best Employer in Australasia 2012 & 2013 P Please consider the environment before printing this e-mail This communication, including any attachments, is confidential and may be legally privileged. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. No confidentiality or privilege is waived or lost by any mis-transmission or error. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.

2 2

Chorus EUBA + IPV6
by Simon Allard 02 Aug '15

02 Aug '15

Since it seems to be ipv6 month here at NZNog I thought I would bring this up. Some of you have commented that Orcon is in trial mode for IPv6 and are probably wondering why we haven’t progressed. We have had IPV6 enabled for a while and have a good number of ipv6 customers online now. However we found an issue on the Chorus network which stopped us rolling it out further. (UFB ipv6 was another battle which requires beer!) What we found was some Chrous DSLAMS with certain card types would drop IPV6CP packets in one direction when doing the PPPoE->PPPoA conversation. It would seem that these cards don’t support Ipv6. Weirdly enough it would seem it is the newer card types used for Broadband IP. (citation needed). This in itself isn’t a major but we also found our NFV4 modem would reset its entire PPPoE stack if the IPV6CP conversation started but didn’t complete as expected, so customers would constantly be disconnected and cycle around. (The Genius modem works well with ipv6) The NFV4 issue aside (we are resolving with the Vendor). We approached the Chorus tech team and they helped identify the issue but that’s is where its hit a brick wall. The Chorus op team are not keen on fixing the issue nationwide as it involves new code versions, a massive amount of testing and a long rollout program. (I can understand where they are coming from). To summarise: IPV6 doesn’t work on Chorus EUBA on some line card types Only affect PPPoE->PPPoA translation PPPoE end to end is fine. Chorus say IPV6 not supported on EUBA Customer numbers effected are smallish. We will fix the NFV4 issue, but keen to rollout more IPV6 to all customers, not just the lucky ones on card types which work. Has any other ISP’s (the bigger ones especially) noticed this? As it will require some pressure to get some progress. Cheers, Simon Allard Orcon/Callplus [cid:image92256e.PNG(a)016ea4ce.48a80470] Simon Allard // Senior Network Architect D: 09 550 2790 M: 020 100 0790 F: www.callplus.co.nz<http://www.callplus.co.nz> | www.slingshot.co.nz<http://www.slingshot.co.nz> | www.flip.co.nz<http://www.flip.co.nz> | www.orcon.net.nz<http://www.orcon.net.nz> This message and any attachments contain privileged and confidential information. If you are not the intended recipient of this message, you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify the sender immediately via email and then destroy this message and any attachments.

5 5

ARP _request_ with Target Protocol Address = 255.255.255.255
by Ewen McNeill 02 Aug '15

02 Aug '15

On the off chance that someone else has seen this before and knows what causes it, does anyone know of any software that generates ARP _Requests_ with the Target Protocol Address (TPA) of 255.255.255.255 (all ones). Such that results in this sort of log message from picky switches: <188> Jul 29 10:47:13 [SWITCH] ARP[ipMapForwarding]: ipmap_arp_api.c(1147) 1021154 %% Received ARP Request on interface Vl1 with bad target IP address 255.255.255.255. Sender IP is [REALIP], sender MAC is [REALMAC]. As far as I can tell they happen _approximately_ every 5 minutes, but definitely not to the second. I'm told the Sender IP is a relatively old Windows host, but the Windows admins don't know of anything installed which would do that. Searching the Internet doesn't turn up much. I did find UNARP (https://tools.ietf.org/html/rfc1868) but that's supposed to be an unsolicited ARP _Reply_, and this is a Request; and besides this isn't the scenario UNARP was invented for anyway. The only other speculation I can find is maybe it's a gratuitous ARP that doesn't follow RFC5227 (https://tools.ietf.org/html/rfc5227; which says that Target Protocol Address should be set to the address you want to claim), but that also seems implausible (especially since the DHCP leases at this site are longer than 5/10 minutes). Any thoughts as to what might be generating it welcomed. Ewen PS: This is not the ARP being _broadcast_ to the all address 255.255.255.255; that happens all the time on requests. This is asking "who-has 255.255.255.255"!

2 3

gnodal switches
by Rob McDonald 28 Jul '15

28 Jul '15

Hi, Slightly OT maybe. Not an operational issue. But where else would you ask? Has anyone heard of what happened to gnodal? They sprang up, released some fairly impressive switches, went into receivership then were purchased by Cray computing... 18 months later you can buy their hardware on ebay... $5000 kiwi landed for a 72port 10gig SFP+ chassis? Has anyone made use of this kit? Cheers Rob

1 0

Call for Presentations - DNS-OARC Fall Workshop, Oct 2015 -- Deadline Extended
by Sebastian Castro 28 Jul '15

28 Jul '15

The next DNS-OARC Fall Workshop will take place in Montreal on Oct 3rd and 4th, the weekend before NANOG65. DNS-OARC is requesting proposals for presentations, with a preference for DNSSEC work. We are looking for the whole spectrum, from measurement work using passive and active techniques, to applications and potential new uses of DNSSEC. This workshop intends to build from previous strong DNS-OARC workshops, where operational content and research is welcome. Presentations from DNS operators are particularly welcome, as well as from DNS researchers. All DNS-related subjects are accepted, introduction to new tools, visualizations, data analysis, DNSSEC and novel uses of the DNS. If you are an DNS-OARC member, and have a sensitive topic you would like to present for members-only, we will accommodate those talks too. Time will be available for lighting talks to fit short presentations (5 to 10 minutes). Workshop Milestones 17 June 2015, Call for Presentations posted 17 June 2015, Open for submissions 14 August 2015, Deadline for submission (Deadline extended by two weeks) 20 August 2015, Final Program published 1 October 2015, Final deadline for slideset submission Details for abstract submission will be published here: https://indico.dns-oarc.net/event/24/call-for-abstracts/ The workshop will be organized on different tracks, depending on the topics and the timing of each presentation. If you are interested in a lightning talk, let us know at the time of submission. You can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via <submissions(a)dns-oarc.net> if you have questions or concerns. Sebastian Castro, for the DNS-OARC Programme Committee DNS-OARC is also seeking sponsorship for this workshop, please contact <sponsor(a)dns-oarc.net> if your organization is interested in becoming a sponsor. (Please note that DNS-OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) -- Sebastian Castro Technical Research Manager .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 495 2337 mobile: +64 21 400535

1 0

Android "stagefright" bug, aka "The Android End Times"
by Mike Forbes 27 Jul '15

27 Jul '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Seems this is pretty hot right now. Basically every single android device - and it seems very difficult to imagine a scenario where all those devices could be patched. Suggestions for mitigating include disabling the "Auto download / Auto retrieve" portion of your MMS app and/or disabling the MMS APN in your mobile settings. Though, of course the vulnerability is in the media library so assume the malicious code could be sent via other means. In talking to @jduck (he's a Kiwicon regular!) he's openly commented that this exploit could be definitely wormable. Sources: http://arstechnica.com/security/2015/07/950-million-android-phones-can-be-h… http://blog.zimperium.com/experts-found-a-unicorn-in-the-heart-of-android/ -----BEGIN PGP SIGNATURE----- iQQcBAEBCgAGBQJVtrdXAAoJENoDRsDWj78uMxwf/0AmB3LCWaPN7JT+9dlyQfUR YGppVe9ehpLXg0hhZod9//IJ0GXXhO1TeYwXVgO3E5fPKjNCy1DBv4eCrp/HAnBS 13r04j+H7H4tFy+KjPUHj546+U0KxAk8K4R08NGsyhpnSL4vIrm4m8D2MsOzlU/n YuiVHqCsxyO3YQ+FZDh24tLGCnoy+HrhFa+ry/i1KNOPdRFZmtrHwET5BBKX9q0I n/Dfgo1z4Lbfs6D5QmH1A2AhHXQx8fUiW0mNdOfd/SW4Thmwj7xPJVo36PGimYPQ 8qznIlLJLX9BgFZ10uVmCJaQEH2M1ZD1cV8WhnAgznSISTx8oopo5A3Qgk/D3Ltg LXApd09pv8fQbjq15fUmDc1buAYB/On7lkpboWxFSo2UHV3ua5YK0rz9Yag4TaBU Ii3+6a2dwW933qUQlLn7JR0ibv+yKsHeK/zjnd0WC8iaDGb+I33hdf+fL9DU7re/ DF0k0ku7E8Uf7209A+yz+2kW0qrE9guldvn4M3mGC4ptG0QQvRPEiTynxARO9pjW iWTix+zDkD8qlyUw2aiK9yTaXhdYQRUHcoBmVrs+HCQABLgQmpdZ/8FBZGFE3F0F KHRmLaPuhTeeKprHti2JoVU98/5OYGNMzYrRs13jV1I399vJSVP6grUIPIpk7M8i zI8vqsXmBNAK2CYK++WHINccjkFfZf6hJ1V59Ajv1VjeSkmFfuEveO2+AIjOvrBr Bv3ZcflxTZsmqxHrOhrU/VclpT8qprc8GoFYMLSpLmQsLqGG5H9ih5vLhz8H7wXe lDuwjXZbtRmAh4BtfCGZoR20KJExNipgoZlFN0zD46Y91F/CFYvMGOlQlmi978i/ 1CrQ6MAU/7krFGPGUXnf4ChXfDzxH41E90Sb02xHsl6542Cf21z9yjdTqavGln2R z6nnDhIM+FfbGdh/IxdBBQT334Dlaby+HDnHfv9z8NzmA+g6l4rnZn7g04O0r5oq 68odwxL59mUyC1Uhp1NIxcTSxgD+Rj8ZWs98auQkYFOrUoW2QlsmIAvqbZIQY0sT /isSYpsP/pO74mBt62fjz/dcrDwiPypDdT0iZxmgfeD+Jjlo78KxoVCpLxxBtKUw ykxvD3yhqsY4nJf6KkyRMJ3CgkNTNifmdJ/LhJ+0pbO9+zh8gL0kWO/S5WLg2nt4 CtRfOeQ4WwPX7PEmmtSs38L1oA3YUcRBYq2eseg0915WFO6tXjx/9Ej/Fj3lZ0jZ vWzF/PcTxkohBZk2CrnWBXxhbAgGtSNPzHzxDFMcu2kkLrDR0dn7efd5TDbbzRTe Dur1XFAmcGMh8KuW2HxqkOMu/fPLmbgufjxNcy7PG2CWZy7Xn8TwnGAyNnrvcCI= =cyK6 -----END PGP SIGNATURE-----

1 0

Any 2talk NOC lurking?
by Pete Mundy 27 Jul '15

27 Jul '15

Hi 2talk Just on the off-chance any of your guys are lurking on this list? You seem to have dropped a route and all traffic bound to your NS is going nowhere as of shortly after 6am today. I've tried lookups and pings from connections on quite a range of ISPs and they all show the same thing. Some traceroute examples are included below just as a reference. It's not the first time the route to the network hosting your NS has dropped. Have you ever considered having a tertiary NS elsewhere, say maybe on AWS or something? Just a thought. Anyway just a heads up since I can't access your live portal to lodge a ticket ;) (and a warning for others on list in case they are affected by it too). Cheers, Pete [from a Spark link] Host Loss% Snt Last Avg Best Wrst StDev 1. dsl-router.lan 0.0% 3 1.5 1.4 1.3 1.5 0.1 2. 122-56.78-178.n4l.sparkdigital.co.nz 0.0% 3 59.1 24.6 7.2 59.1 29.9 3. 122-56-99-251.n4l.sparkdigital.co.nz 0.0% 3 15.0 30.4 15.0 60.8 26.3 4. 122-56-99-250.n4l.sparkdigital.co.nz 0.0% 3 15.5 17.6 15.5 21.6 3.5 5. 122-56-99-253.n4l.sparkdigital.co.nz 0.0% 3 15.8 15.4 14.9 15.8 0.5 6. ??? 7. ae8-10.akbr6.global-gateway.net.nz 0.0% 2 25.8 25.8 25.8 25.8 0.0 8. ??? [from a Snap link] fpl-rpi17 (0.0.0.0) Tue Jul 28 07:16:35 2015 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. fritz.box 0.0% 6 1.0 1.0 1.0 1.1 0.1 2. 133.7.69.111.static.snap.net.nz 0.0% 6 2.8 5.1 2.8 13.5 4.2 3. ??? [from a Solarix link] vvm2.fiberphone.co.nz (0.0.0.0) Tue Jul 28 07:17:14 2015 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. ge-1-1-1-340.core-0.ive.chc.unleash.net.nz 0.0% 6 1.0 1.0 0.6 2.1 0.6 2. ae1-22.core-0.sho.chc.unleash.net.nz 0.0% 6 1.1 1.5 0.8 3.3 0.9 3. ae0-3221.core-0.que.akl.unleash.net.nz 0.0% 6 17.1 17.3 16.8 18.3 0.5 4. 116.90.129.203 0.0% 5 17.8 17.2 16.7 17.8 0.4 5. ten-0-3-0-500.bdr01.akl05.akl.VOCUS.net.nz 0.0% 5 17.1 17.4 17.1 17.5 0.2 6. ???

3 2

National Broadband Map launched yesterday
by Sebastian Castro 23 Jul '15

23 Jul '15

Hello members of the NZNOG community: NZRS launched the National Broadband Map (https://broadbandmap.nz) yesterday with the participation of Hon. Amy Adams. We had an overwhelming response and our team had to clock some extra hours to scale up everything nicely to cope with the load. We are getting calls and messages noting the accuracy in certain border cases. We are working with our data suppliers to ensure the information we're presenting is as accurate as possible, and new data will be added in the next weeks to improve it. We are open to receiving your comments and feedback, and definitely planning a presentation about the process for the next NZNOG meeting. Kind Regards, -- Sebastian Castro Technical Research Manager NZRS Ltd. desk: +64 4 495 2337 mobile: +64 21 400535

2 1

CallPlus Routes / Akamai Coming via Vocus / AKL-IX??
by Liam Farr 22 Jul '15

22 Jul '15

Hey, Anyone else seeing this, routes to CallPlus are being advertised to AKL-IX by Vocus rather than by CallPlus direct. As an example this is breaking 'www.stuff.co.nz' for me. The path by Vocus seems really 'fucked' (like its aggressively shaped down to nothing) so HTTP takes forever to load. Liams-MacBook-Pro:~ liamfarr$ traceroute www.stuff.co.nz > traceroute: Warning: www.stuff.co.nz has multiple addresses; using > 119.224.143.41 > traceroute to a1784.g.akamai.net (119.224.143.41), 64 hops max, 52 byte > packets > 1 192.168.6.1 (192.168.6.1) 0.710 ms 0.394 ms 0.332 ms > 2 unallocated.maxumdata.net (103.247.154.2) 0.427 ms 0.434 ms 0.397 > ms > 3 vl0901.core2.qs220.maxumdata.net (103.247.154.141) 0.585 ms 0.651 > ms 0.586 ms > 4 vl0233.edge1.qs220.maxumdata.net (103.247.154.38) 0.645 ms 0.672 > ms 0.613 ms > 5 43.243.21.6 (43.243.21.6) 1.580 ms 1.459 ms 1.529 ms > 6 ten-0-1-0-2.cor01.akl05.akl.vocus.net.nz (114.31.202.122) 2.139 ms > 2.088 ms 2.294 ms > 7 bundle-10.bdr02.akl05.akl.vocus.net.nz (114.31.202.101) 2.560 ms > 2.764 ms 2.314 ms > 8 as4610.cust.bdr02.akl05.akl.vocus.net.nz (175.45.102.66) 24.271 ms > 24.166 ms 24.251 ms > 9 pts-n.cpcak4-r1.tranzpeer.net (101.98.5.20) 2.297 ms 2.175 ms > 2.254 ms > 10 p1.akamai.callplus.net.nz (119.224.143.1) 1.488 ms 1.633 ms 2.441 > ms > 11 p41.akamai.callplus.net.nz (119.224.143.41) 1.624 ms 2.116 ms > 2.334 ms liam(a)QS220-EDGE1:~$ show ip bgp 119.224.143.41 > BGP routing table entry for 119.224.142.0/23 > Paths: (4 available, best #3, table Default-IP-Routing-Table) > Advertised to non peer-group peers: > 103.247.154.37 103.247.154.42 103.247.154.186 192.203.154.150 > 2403:4d00:fff:ffff:ffff:ffff:20:2 > 45177 4610 9790 > 103.247.152.241 from 103.247.152.241 (14.1.32.4) > Origin IGP, localpref 50, valid, external > Community: 55785:502 > Extended Community: RT:45177:1117 > Last update: Thu Jul 9 06:37:46 2015 > 45177 4610 9790 > 103.247.152.213 from 103.247.152.213 (14.1.32.4) > Origin IGP, localpref 50, valid, external > Community: 55785:502 > Extended Community: RT:45177:1117 > Last update: Thu Jul 9 06:34:55 2015 > > > > > * 4826 4610 9790 43.243.21.6 from 43.243.21.1 (43.243.21.1) > Origin IGP, localpref 100, valid, external, best Community: 55785:202 > Last update: Wed Jun 24 04:15:20 2015* > 23655 9560 9790 > 111.69.34.225 from 111.69.34.225 (43.225.200.2) > Origin IGP, localpref 90, valid, external > Community: 55785:302 > Last update: Sat Mar 28 03:36:00 2015 As CallPlus peer on AKL-IX I would have expected to see them advertising their own routes, rather than just advertising these to Vocus who are then 'breaking them'. Perhaps someone from CallPlus could fix their advertisements, and someone from Vocus could either fix their 'bottleneck' or stop advertising the routes. -- Kind Regards Liam Farr Maxum Data +64-9-950-5302

8 8

Junos and RPKI validation
by Dave Mill 16 Jul '15

16 Jul '15

Hi all NZNOG, and especially Michael Fincham and Tim Hoffman, had done a big push both at our conferences and on this list to get people using RPKI route validation. We were a test customer using the NZRS service at http://validator.rpki.net.nz/rtr-sessions . Someone with an observant eye may have noticed that we silently stopped using this validator a few weeks ago. We hit a 'minor' issue where Junos would restart _all_ routing daemons and produce a core dump when running a session to a RPKI validator. It affects 12.3R9 12.3X48-D10 13.3R4 14.1R3 14.2R1 15.1R1 and happens on J-series, M-series, T-series, MX-series, EX Series, SRX Series. PR for those with a Juniper login - https://prsearch.juniper.net/InfoCenter/index?page=prcontent&id=PR1010216 Upgrade to a recent release of your choosing to fix. Just figured I'd share for anyone else who is doing RPKI validation on one of these releases. For now we've stopped doing RPKI validation until we can arrange an upgrade of the routers involved. Cheers Dave

2 1

dual sim (3g) routers
by Jodi Thomson 12 Jul '15

12 Jul '15

Hi Folks We're on the hunt for a dual-sim (3g) router. Have done some googling but not sure what may or may not work with our 3/4G networks. Primary objective is to have 2nd 3G link as failover to second network (eg spark -> vodafone), but aggregation would be helpful also if networks support it (eg vodafone-vodafone) Wondering if anyone on the list knows what is available in NZ? Off list replies welcome to prevent clutter Cheers Jodi PS Beer -- Jodi Thomson Systems & Networks Web Connect Ltd Unit 1, 501 Heretaunga Street West Hastings, 4122 Ph: (06) 281 2324 (ext 802) http://www.webconnect.nz

1 1

Whither NzWrt?
by Dave Taht 12 Jul '15

12 Jul '15

I am curious if the NZWrt idea ever got any traction? It certainly seemed saner for me for a set of ISPs to agree on one specific hardware type, get software that met their needs, make it stable as heck, and to maintain it themselves.... -- Dave Täht worldwide bufferbloat report: http://www.dslreports.com/speedtest/results/bufferbloat And: What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast

3 2

NZ TCF very bad SSL FYI
by Tony Wicks 08 Jul '15

08 Jul '15

HI guys, one of my users reported being unable access the IPMS platform this morning and it appears Firefox and Chrome are calling bul### on the really bad SSL on the TCF website and blocking access. IE still works but really shouldn't. Anyone on the TCF on this list, please sort your your technical people, this is just not good enough ! https://www.ssllabs.com/ssltest/analyze.html?d=ipms-prod.tcf.org.nz

1 1

4-wire SHDSL routers in NZ
by Dmitry Konchanin 06 Jul '15

06 Jul '15

Hi all We are suddenly in need of a couple 4-wire SHDSL EFM routers. There is basically no retail market for shdsl devices, ones we found are only 2-wires or have to be ordered with a lead time of couple of weeks (except pricy Cisco 888E option). If somebody has an access to stocked supply of such devices, could you please contact me off the list. -- Kind regards, Dmitry Konchanin

3 2

Intac program
by Dean Pemberton 02 Jul '15

02 Jul '15

Hi all, The Programme for this year's InTAC is now up: http://2015.nethui.nz/programme/day-0-intac This year there is a focus on "The Netflix Effect; Organic Growth or Step Change?" What does the changing face of user demand look like? What happens when people who previously only used their home connections for email and web, start using it for multiple 4-5Mbps streams? What happens when everyone on their street does that? Take a drive down any New Zealand street and look at all the Sky dishes on the roof â€“ what if every one of those houses was trying to pull 20Mbps during primetime instead? What would our network do with all that demand? We take a look at his problem, from the people at one end to the content delivery at the other. Registrations for this and the rest of the NetHui programme are still open here: https://nethui2015.lilregie.com/step1 See you next week! Dean -- -- Dean Pemberton Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean(a)internetnz.net.nz To promote the Internet's benefits and uses, and protect its potential.

2 1

Fwd: [PAG] Fwd: InternetNZ deeply disappointed with Global Mode withdrawal
by Joel Wirāmu Pauling 23 Jun '15

23 Jun '15

FYI; ---------- Forwarded message ---------- From: Jordan Carter <jordan(a)internetnz.net.nz> Date: 23 June 2015 at 16:48 Subject: [PAG] Fwd: InternetNZ deeply disappointed with Global Mode withdrawal To: Policy Advisory Group <pag(a)mailman.internetnz.net.nz> ---------- Forwarded message ---------- From: *Aimee Whitcroft* <news(a)meltwaterpress.com> Date: Tuesday, 23 June 2015 Subject: InternetNZ deeply disappointed with Global Mode withdrawal To: jordan(a)internetnz.net.nz A better world through a better Internet InternetNZ deeply disappointed with Global Mode withdrawal InternetNZ is deeply disappointed at announcements today that the Global Mode service is being withdrawn from New Zealand. "Global Mode was a great example of Internet-based innovation that challenged traditional content distribution models. It was by no means clear that the service was illegal, and we were keen to see the matter go before the courts to provide users and the industry with clarity." said InternetNZ Chief Executive Jordan Carter. The removal of this service means that New Zealanders have fewer options to pay for content. Restricting consumer access to paid content services on the basis of geographic content monopolies seems the wrong answer to resolving copyright concerns. "Withdrawing the service and settling before court seems a worse outcome for all concerned. The media companies have said that they wanted to clarify their own legal rights over content - a settlement doesn't achieve this, and leaves us all none the wiser." "There remains a number of questions that will now go unanswered due to this withdrawal. Internet users and innovation have taken a back seat to entrenched old media interests." "This outcome makes it ever more important that we review New Zealand copyright law, to ensure that the interests of consumers and creators are appropriately balanced." said Carter. *ENDS* For more information, please contact Andrew Cushen, Acting Chief Executive: - 021 346 408 - andrew(a)internetnz.nz www.internetnz.net.nz *Disclaimer: *If you do not wish to receive further news/releases from Internet NZ, please click the following link: [Remove Me] <http://app.meltwaterpress.com/mpress/removeme.html?cId=3507196&sId=171920&c…>. Requests will take a maximum of 2 business days to process. Contact information: Aimee Whitcroft, Internet NZ, Grand Arcade Tower, 16 Willis Street, Wellington, 6011 -- Jordan Carter Chief Executive, InternetNZ +64-21-442-649 | jordan(a)internetnz.net.nz Sent on the run, apologies for brevity _______________________________________________ Pag mailing list Pag(a)mailman.internetnz.net.nz http://mailman.internetnz.net.nz/mailman/listinfo/pag

1 0

Call for Presentations - DNS-OARC Fall Workshop, Oct 2015
by Sebastian Castro 17 Jun '15

17 Jun '15

The next DNS-OARC Fall Workshop will take place in Montreal on Oct 3rd and 4th, the weekend before NANOG65. DNS-OARC is requesting proposals for presentations, with a preference for DNSSEC work. We are looking for the whole spectrum, from measurement work using passive and active techniques, to applications and potential new uses of DNSSEC. This workshop intends to build from previous strong DNS-OARC workshops, where operational content and research is welcome. Presentations from DNS operators are particularly welcome, as well as from DNS researchers. All DNS-related subjects are accepted, introduction to new tools, visualizations, data analysis, DNSSEC and novel uses of the DNS. If you are an DNS-OARC member, and have a sensitive topic you would like to present for members-only, we will accommodate those talks too. Time will be available for lighting talks to fit short presentations (5 to 10 minutes). Workshop Milestones 17 June 2015, Call for Presentations posted 17 June 2015, Open for submissions 30 July 2015, Deadline for submission 20 August 2015, Final Program published 1 October 2015, Final deadline for slideset submission Details for abstract submission will be published here: https://indico.dns-oarc.net/event/24/call-for-abstracts/ The workshop will be organized on different tracks, depending on the topics and the timing of each presentation. If you are interested in a lightning talk, let us know at the time of submission. You can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via <submissions(a)dns-oarc.net> if you have questions or concerns. Sebastian Castro, for the DNS-OARC Programme Committee DNS-OARC is also seeking sponsorship for this workshop, please contact <sponsor(a)dns-oarc.net> if your organization is interested in becoming a sponsor. (Please note that DNS-OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) -- Sebastian Castro Technical Research Manager .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 495 2337 mobile: +64 21 400535

1 0

Onsite Cisco Switch Install - Tomorrow - lunchtime-ish (Auckland)
by Skeeve Stevens 16 Jun '15

16 Jun '15

Hi all, I need a Cisco switch installed in Auckland tomorrow. It is already onsite and will need to be wiped (if anything is on it) and the config provided loaded, then installed into a rack. If you can assist, please let me know off-list with availability (tomorrow obviously) and rates. As usual I get a dozen responses... I will accept the first appropriate one, but sorry if I don't reply to everyone. ...Skeeve *Skeeve Stevens - Founder & Chief Network Architect* eintellego Networks Pty Ltd Email: skeeve(a)eintellegonetworks.nz ; Web: eintellegonetworks.nz Phone: +612 8014 7398 ; Cell +61 (0)414 753 383 ; Skype: skeeve Facebook: eintellegonetworks <http://facebook.com/eintellegonetworks> ; Twitter: eintellego <https://twitter.com/eintellego> LinkedIn: /in/skeeve <http://linkedin.com/in/skeeve> ; Expert360: Profile <https://expert360.com/profile/d54a9> The Experts Who The Experts Call Juniper - Arista - Cisco - Cumulus Linux - Cloud - Consulting - IPv4 Brokering

2 1

IANA AS Numbers registry update
by Selina Harrington 11 Jun '15

11 Jun '15

Hi, The IANA AS Numbers registry has been updated to reflect the allocation of the following block to RIPE NCC in June 2015: 202240-203263 Assigned by RIPE NCC 2015-06-11 203264-204287 Assigned by RIPE NCC 2015-06-11 You can find the IANA AS Numbers registry at: http://www.iana.org/assignments/as-numbers/as-numbers.xml The allocation was made in accordance with the Policy for Allocation of ASN Blocks to Regional Internet Registries: https://www.icann.org/resources/pages/global-policy-asn-blocks-2010-09-21-en Regards, Selina Harrington ******************************************* Internet Assigned Numbers Authority (IANA) Internet Corporation for Assigned Names & Numbers 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094 Phone: +1 310 301 5800 Fax: +1-310-823-8649 *******************************************

1 0

Re: [nznog] racks for beer.
by Stuart Pigneguy 10 Jun '15

10 Jun '15

I also have two 19" server racks (with doors) no longer required and can be exchanged for beer. I believe they are 42U, available for pick up in Auckland on Monday 22nd. Otherwise they'll be scrapped! - please reply off list Cheers, Stuart NZNOG lurker since 2001

1 0

DEI bit on Fortigate D series
by Dan BAJARCA 09 Jun '15

09 Jun '15

Hi All, Just sharing a bit of knowledge around issues we've had with Fortigate firewalls on UFB Accelerate plans. Some of our customers reported slow download speeds (generally close to 2Mbps) when using Fortigate D series firewalls on UFB 200/100 (tested with 30, 60 and 90 models). The issue is caused by the units dropping inbound packets with the DEI bit set and showed up on 5.0 and 5.2 software. After some extensive troubleshooting with Fortinet they've eventually acknowledged the fault and moved it to their bug queue. Hopefully a fix isn't too far away. If you're currently battling this issue, a tested workaround would be to configure the circuit as untagged. Chorus should also be able to disable the DEI bit marking on a per service provider basis but better think twice before requesting it. Cheers, Dan

1 0