- NZNOG - lists.nznog.org

Re: [nznog] Network for Learning APE Peering
by Peter Lambrechtsen 28 Nov '14

28 Nov '14

Let's not forget that N4L is run by Spark Digital aka Gen-I and is completely separate infrastructure from the Retail broadband stack. For all intensive purposes they are separate companies. > -------- Original message -------- > From: Tony Wicks <tony(a)wicks.co.nz> > Date: 29/11/2014 8:59 AM (GMT+12:00) > To: "'nznog(a)list.waikato.ac.nz'" <NZNOG(a)list.waikato.ac.nz> > Subject: Re: [nznog] Network for Learning APE Peering > > > Yes, and it also goes to highlight that there is no reason whatsoever why the rest could not be peered ! > > > >Subject: Re: [nznog] Network for Learning APE Peering > > > > > > >That'll be a royal truck-load of daytime traffic moving from domestic transit links to peering links! > > > > >I think much kudos should go to the N4L team for bringing some 5000+(*) addresses of Spark's IP space into being openly peered at APE. This is a fantastic move! > > > > >Well done guys :)

1 0

Network for Learning APE Peering
by Clayton Hubbard 28 Nov '14

28 Nov '14

Hi Noggers.. Network for Learning has just completed peering with APE. If you provide services to schools in NZ and have any suboptimal routing, please contact me off-list to investigate. Thanks, *Clayton Hubbard* Senior Engineer, The Network for Learning Ltd D: 09 972 2906 | M: 022 043 0155 | W: http://www.n4l.co.nz A: Suite 306, Geyser Building, 100 Parnell Road, Parnell, Auckland 1052 P: PO Box 37118, Parnell, Auckland 1151 <http://www.n4l.co.nz> <https://twitter.com/@N4LNZ/> <https://www.facebook.com/NetworkForLearning> <https://plus.google.com/104649004276520409744/about> <http://www.linkedin.com/company/the-network-for-learning-ltd-n4l->

3 2

Re: [nznog] FW: Letter to Network Operators 24 Nov 2014
by Revel N 25 Nov '14

25 Nov '14

Completely agree. My interpretation of the guidance is the same (i.e. "continuing to use the exact same systems as were decided on and deployed prior to 11 May would not require a notice and replacing dead hardware with the same thing doesn't require this notice either"). As such, I'd be surprised if there had been a large number of submissions from every operator within 6 months. On 26 November 2014 at 12:00, <nznog-request(a)list.waikato.ac.nz> wrote: > Send NZNOG mailing list submissions to > nznog(a)list.waikato.ac.nz > > To subscribe or unsubscribe via the World Wide Web, visit > http://list.waikato.ac.nz/mailman/listinfo/nznog > or, via email, send a message with subject or body 'help' to > nznog-request(a)list.waikato.ac.nz > > You can reach the person managing the list at > nznog-owner(a)list.waikato.ac.nz > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NZNOG digest..." > > > Today's Topics: > > 1. Re: FW: Letter to Network Operators 24 Nov 2014 > (Alexander Neilson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 25 Nov 2014 12:12:41 +1300 > From: Alexander Neilson <alexander(a)neilson.net.nz> > To: Dave Mill <dave(a)mill.net.nz> > Cc: "nznog(a)list.waikato.ac.nz" <nznog(a)list.waikato.ac.nz> > Subject: Re: [nznog] FW: Letter to Network Operators 24 Nov 2014 > Message-ID: <3B4DF5F6-1C93-4023-AE3E-D5D483D7CC0A(a)neilson.net.nz> > Content-Type: text/plain; charset="utf-8" > > What I think is missing here is where providers have a standard system > they have used with the same hardware before May 11th. > > These were decisions made beforehand, no change to deployment, or not > covered by an area of specified security interest. > > How many people on this list would have changed the manufacturer / type of > equipment used in the NOC / core network that meets the threshold in 6 > months? > > IANAL > > However from my lay reading of the guidance and exemptions continuing to > use the exact same systems as were decided on and deployed prior to 11 May > would not require a notice and replacing dead hardware with the same thing > doesn?t require this notice either. > > So I am not sure that a low number of notifications is an odd thing unless > people had major changes to their core and a short run time to make these > changes. > > Others may want to chime in with their experiences. > > Regards > Alexander > > Alexander Neilson > Neilson Productions Limited > > alexander(a)neilson.net.nz > 021 329 681 > 022 456 2326 > > > On 25/11/2014, at 11:51 am, Dave Mill <dave(a)mill.net.nz> wrote: > > > > I'm actually surprised that our GCSB overlords haven't done something > like this sooner. To me it seems pretty obvious that not all network > providers are using/following the new guidelines. And much better an email > like this one than a proper slap by the NCSC/GCSB. > > > > To explain my logic without giving too much away. > > > > We are a small ISP. We have submitted proposals under this new law. Lets > call our number of proposals X. > > > > At a technical conference recently the GCSB were able to share with us > their rough total number of proposals. That number was also reasonably > obvious from the proposal numbering system the NCSC use. Lets call this > number Y. > > > > Y wasn't that much bigger than X. I'm talking 5 or 6 times bigger from > memory. > > > > We have spent a lot of time and effort in following this new > legislation. I think its only fair that others do also (lets not debate > whether we needed the legislation here). And with the numbers talked about > so far I think its pretty clear that some organisations out there aren't > following this new legislation. > > > > At the very least (based on Ray's comments) most network operators > should be submitting at least 5 - 10 standard builds each IMHO. > > > > Cheers > > Dave > > > > > > On Mon, Nov 24, 2014 at 8:30 PM, Ray Taylor <ray(a)ruralkiwi.com <mailto: > ray(a)ruralkiwi.com>> wrote: > > I am assuming this refers to notifications about equipment changes, > vendor suppliers etc? > > > > It may come as a surprise to these people but most network operators > create standards and stick to them! > > > > > > > > > > > > > > > > Ray Taylor > > > > Taylor Communications > > > > ray(a)ruralkiwi.com <mailto:ray(a)ruralkiwi.com> > > > > > > Ph 021-483-280 > > > > Network status 06-929-9082 > > > > > > > > <image001.png> > > > > > > > > From: TICSA [mailto:TICSA(a)ncsc.govt.nz <mailto:TICSA(a)ncsc.govt.nz>] > > Sent: Monday, 24 November 2014 3:21 p.m. > > To: TICSA > > Subject: Letter to Network Operators 24 Nov 2014 > > > > > > > > Dear Network Operator > > > > > > > > Please find attached a letter to all network operators. This letter > shares our surprise at the low number of notifications received from > registered network operators to date. We want to reinforce that we are here > to support you in meeting your obligations under the TICSA. > > > > > > > > We thank those network operators who have actively engaged with us under > the TICSA since May. > > > > > > > > > > > > Kind regards > > > > From the TICSA Team > > > > > > > > > > > > This electronic message, together with any attachments, contains > information that is provided in confidence and may be subject to legal > privilege. Any classification markings must be adhered to. If you are not > the intended recipient, you must not peruse, disclose, disseminate, copy or > use the message in any way. If you have received this message in error, > please notify us immediately by return email and then destroy the original > message. > > The Government Communications Security Bureau (GCSB) accepts no > responsibility for changes to this e-mail, or to any attachments, after its > transmission from GCSB. Thank you. > > > > This email has been filtered by SMX. For more information visit > smxemail.com <http://smxemail.com/> > > _______________________________________________ > > NZNOG mailing list > > NZNOG(a)list.waikato.ac.nz <mailto:NZNOG(a)list.waikato.ac.nz> > > http://list.waikato.ac.nz/mailman/listinfo/nznog < > http://list.waikato.ac.nz/mailman/listinfo/nznog> > > > > > > _______________________________________________ > > NZNOG mailing list > > NZNOG(a)list.waikato.ac.nz > > http://list.waikato.ac.nz/mailman/listinfo/nznog > >

1 0

ntp.net.nz Update
by Josh Simpson 24 Nov '14

24 Nov '14

Hi NZNOG, Time for an update with regards to ntp.net.nz servers. On the morning of Saturday Nov 22, ntp3.ntp.net.nz failed with a similar issue to that of ntp2.ntp.net.nz, this happened just a few weeks short of the new ntp2 go live. Due to this event we have pushed the new ntp2 appliance into service as well as reconfiguring another new appliance that was to be ntp4 as a ntp3 replacement. Both of these went live on Nov 22 at 18:06 hours, along with reverting the DNS ntp2 -> ntp3 redirection changes that were made in the July 14th email. As part of this the IP addresses for ntp2 and ntp3 have changed to the following ntp2.ntp.net.nz: 202.46.178.18 ntp3.ntp.net.nz: 202.46.179.18 ntp2 was unavailable via IPv6 prior to the failure, we have plans to resolve this in the near future. ntp3 is now unavailable via IPv6 due to the short time span of the work on Saturday, we hope to have this resolved in the coming weeks. We will update the list when IPv6 is back up and running. If you had previously used the IP addresses in your configs be sure to update them. We do recommend using the DNS names specified at https://ntp.net.nz to avoid this issue in the future. If you need any further information, please contact us at support(a)nzrs.net.nz Cheers Josh -- Josh Simpson Systems Administrator .nz Registry Services M: +64 21 783 399 P: +64 4 555 0124 GPG: 6516 B4EA 413B CAED 57B5 0956 124C 8AC3 A362 8080 www.nzrs.net.nz

2 1

Network Monitoring VPS in exchange for VPS from us in return.
by daniel＠glovine.com.au 23 Nov '14

23 Nov '14

Hi Noggers, I was wondering if a couple of providers whom wouldn't mind swapping a small VPS for a small VPS from us, in order for us to run a couple of external network monitoring tools from, Looking for providers whom are on MegaPort Sydney IX Looking for providers whom are on NSW IX Looking for providers whom are not on Vocus transit These requirements above are not all necessary to meet, a mix would be handy and dandy :D, Would even consider providers in QLD, Perth, Melbourne Pritty much Australia wide even NZ is a consideration If you wouldn't mind and you are interested please shoot me an off-list reply for further details and discussions TIA Daniel

1 0

FW: FW: Letter to Network Operators 24 Nov 2014
by Ray Taylor 23 Nov '14

23 Nov '14

Unclassified Have forwarded to you Ray Taylor Taylor Communications <mailto:ray(a)ruralkiwi.com> ray(a)ruralkiwi.com Ph 021-483-280 Network status 06-929-9082 Description: header_logo From: Rob McDonald [mailto:r(a)l2.co.nz] Sent: Monday, 24 November 2014 8:38 p.m. To: Ray Taylor Subject: Re: [nznog] FW: Letter to Network Operators 24 Nov 2014 Hey Ray, Is the text of the actual letter under any confidentiality? If not would you forward it to me? Im quite interested. Could be a gem considering the terse nature of the email. Cheers R On 24/11/2014 8:31 PM, "Ray Taylor" <ray(a)ruralkiwi.com> wrote: I am assuming this refers to notifications about equipment changes, vendor suppliers etc? It may come as a surprise to these people but most network operators create standards and stick to them! Ray Taylor Taylor Communications ray(a)ruralkiwi.com Ph 021-483-280 Network status 06-929-9082 Description: header_logo From: TICSA [mailto:TICSA(a)ncsc.govt.nz] Sent: Monday, 24 November 2014 3:21 p.m. To: TICSA Subject: Letter to Network Operators 24 Nov 2014 Dear Network Operator Please find attached a letter to all network operators. This letter shares our surprise at the low number of notifications received from registered network operators to date. We want to reinforce that we are here to support you in meeting your obligations under the TICSA. We thank those network operators who have actively engaged with us under the TICSA since May. Kind regards >From the TICSA Team _____ This electronic message, together with any attachments, contains information that is provided in confidence and may be subject to legal privilege. Any classification markings must be adhered to. If you are not the intended recipient, you must not peruse, disclose, disseminate, copy or use the message in any way. If you have received this message in error, please notify us immediately by return email and then destroy the original message. The Government Communications Security Bureau (GCSB) accepts no responsibility for changes to this e-mail, or to any attachments, after its transmission from GCSB. Thank you. _____ This email has been filtered by SMX. For more information visit smxemail.com <http://smxemail.com/> _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

1 0

Generating a default route
by Dylan Hall 20 Nov '14

20 Nov '14

Hi all, I'm curious what other people are doing to generate a default route. The config I'm familiar with lists a set of networks, and if any of them are present then the default route is created. Is that how everyone does it? How are people choosing the set of networks? Do you just use Google and Facebook, after all, if they're present that's pretty much the whole internet? Do you use networks that your transit supplier originates? How many networks do you rely on? If I've lost 50% of my full route table in a fault, am I better off not generating default and letting my multi-homed customers use their backup supplier? Comments welcome on and off list :) Thanks, Dylan

1 0

Outdoor Plant Cabinet
by Alexander Neilson 20 Nov '14

20 Nov '14

Hey All We have been caught a little short on availability of our normal outside plant cabinet and I thought I might pop a call out to the list to see if anyone had advice or a spare lying around We are looking for a cabinet with front and back doors, 13RU internal 19” usable rack space (or an 18/19 RU one door rack) We need 600mm depth for the design. Does anyone have a cabinet sitting spare meeting these requirements or a company they have worked with for external cabinets who may have one in their showroom that could be mobilised or has space on a production line. We are looking for availability in 2-3 weeks so quite a tight timeframe. I can offer beer as a finders fee for successful outcome (plus we can buy a cabinet if someone has it spare at their place) *note not asking for loaner cabinets as the plan is to set in a concrete pad where the mounting pole is* Regards Alexander Alexander Neilson Neilson Productions Limited alexander(a)neilson.net.nz 021 329 681 022 456 2326

1 0

Netflix launch in NZ (and Australia) March 2015
by Jesse Archer 18 Nov '14

18 Nov '14

https://pr.netflix.com/WebClient/getNewsSummary.do?newsId=1751 Will be interesting to see if they turn up on Megaport IX Auckland, Auckland IX or APE. *Jesse Archer* *General Manager*Full Flavour *p. *07 929 7111 *ddi*. 07 281 1391 *s*. Skype username "myfullflavour" *e*. jesse(a)fullflavour.co.nz <jesse(a)fullflavourmedia.co.nz> *w*. fullflavour.co.nz <http://t.sigopn02.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XZs2zqjsKN…> *a. *Tauranga Business Centre, 50 Devonport Road, Tauranga *a*. PO Box 16306, Bethlehem 3176, New Zealand

6 6

Re: [nznog] Netflix launch in NZ (and Australia) March 2015
by Jesse Archer 18 Nov '14

18 Nov '14

Netflix will supply the appliances. http://oc.nflxvideo.net/docs/OpenConnect-Deployment-Guide.pdf Expect to have 1-2Gbps between Sydney & NZ tied up each night for 10 hours filling the caches with content. *Jesse Archer* *General Manager*Full Flavour *p. *07 929 7111 *ddi*. 07 281 1391 *s*. Skype username "myfullflavour" *e*. jesse(a)fullflavour.co.nz <jesse(a)fullflavourmedia.co.nz> *w*. fullflavour.co.nz <http://t.sigopn02.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XZs2zqjsKN…> *a. *Tauranga Business Centre, 50 Devonport Road, Tauranga *a*. PO Box 16306, Bethlehem 3176, New Zealand On Wed, Nov 19, 2014 at 2:47 PM, Simon Allard <Simon.Allard(a)callplus.co.nz> wrote: > Netflix does have its own CDN which they deploy in ISP networks. Looks > like the ISP supplies the hardware and they supply the software. > > > > https://openconnect.itp.netflix.com/ > > > > In the past they have never let anyone outside of the regions they service > use these. So will be interesting to see what they expect of NZ/AU ISP’s > now. > > > > Do we need to deploy CDN nodes? or will they come in with their own CDN > and peer? How will they handle non-peering ISP’s? > > > > March isn’t that far away with a big nice brownout/blackout period in the > middle. > > > > > > > > *From:* nznog-bounces(a)list.waikato.ac.nz [mailto: > nznog-bounces(a)list.waikato.ac.nz] *On Behalf Of *Jesse Archer > *Sent:* Wednesday, 19 November 2014 11:56 a.m. > *To:* nznog(a)list.waikato.ac.nz > *Subject:* [nznog] Netflix launch in NZ (and Australia) March 2015 > > > > https://pr.netflix.com/WebClient/getNewsSummary.do?newsId=1751 > > Will be interesting to see if they turn up on Megaport IX Auckland, > Auckland IX or APE. > > > > > > > *Jesse Archer * > *General Manager *Full Flavour > > *p. *07 929 7111 *ddi*. 07 281 1391 > *s*. Skype username "myfullflavour" > *e*. jesse(a)fullflavour.co.nz <jesse(a)fullflavourmedia.co.nz> > *w*. fullflavour.co.nz > <http://t.sigopn02.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XZs2zqjsKN…> > *a. *Tauranga Business Centre, 50 Devonport Road, Tauranga > *a*. PO Box 16306, Bethlehem 3176, New Zealand > > > > Simon Allard // > Senior Network Architect > > *D:* 09 550 2790* M:* 020 100 0790* F:* > > > > www.callplus.co.nz | www.slingshot.co.nz | www.flip.co.nz | > 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. > >

1 0

New IXs in NZ - discussion
by Bevan Slattery 17 Nov '14

17 Nov '14

Hi Joe, [snip] IX Australia are the only independent Internet Exchange operator in Australasia, with 16 years experience running exchanges throughout the region. Unlike all other Internet Exchanges in the region, we are not for profit, and seek to serve our members, not our shareholders. We're already very far down the path of bringing some very interesting content providers and large NSPs online. [/snip] Interesting to see IX-Australia following Megaport lead again and it¹s great to see competition. However, a few points regarding your statement above: 1. It is a misrepresentation to say that WAIA/IX-Australia is the only independent provider of IX Services in Australasia 2. Its generally known that IX-Australia provides services to organisations that aren¹t members of WAIA/IX-Australia. which apart from a contravention of its constitution means the statement above isn¹t quite factually correct. Can you confirm WAIA only provide services to registered members under its constitution? I can think of a handful that aren¹t. 3. The constitution of WAIA only provides for WAIA/IX Australia to service Australia, so I¹m not sure whether the announcement is simply a reaction to Megaports announcement, not approved by members/amended in the constitution or part of a plan to expand (not foreshadowed at the recent AGM which would have been the time to amend the constitution?) 4. WAIA is Incorporated in WA which actually only really provides for the delivery of services in Western Australia (there is a pathway to delivering nationally through Incorporation under ASIC), but certainly is not able to provide services outside of Australia. Operation outside of Australia may lead to issues regarding WAIA¹s incorporated status. Despite some persistent rumours that IX-Australia is perhaps being taken advantage of by a particular commercial carrier to hinder Megaports success, I would like to think otherwise, but this reaction to step outside the legal operational jurisdiction makes me think there is merit to same. So ultimately, from a Network Operations perspective it would be helpful to understand whether WAIA as an Incorporated Association in Western Australia is legally able to operate outside of Australia in the first instance though (even if the Constitution allowed it which I don¹t think it does). Your clarification to the list would be helpful. Cheers [b] WAIA 2013 Constitution https://www.waia.asn.au/node/83

3 4

Megaport Auckland
by Denver Maddux 17 Nov '14

17 Nov '14

Hi NZNOGers, First off, I’m new to the NZNOG list, but far from new to NOGs in general. I’ve recently stepped into the CEO role at Megaport and expect to be more actively engaging the community regionally as we expand the business into New Zealand, but I’ve been a long-time active member of NANOG, GPF, EPF, and APF groups. I’ve been trying to catch-up on the NZNOG list via the archives over the past couple of weeks to get some context for the community and I’m really happy to see how active the list has been as of late. Second, I wanted to just drop a note that Megaport is now live in 220 Queen St. As many of you have seen, we are partnered with Vibe in NZ, but users can also sign up directly with Megaport now in The Data Centre. This is for the full index of Megaport services, including IX, as has been heavily discussed on this list recently. We will also be expanding into Datacom Orbit Dr in the next month or so. http://www.megaport.com Feel free to email me direct if you have questions, or flames. :) Denver Maddux CEO Megaport denver.maddux(a)megaport.com<mailto:denver.maddux(a)megaport.com>

2 1

Reminder of NZNOG list AUP
by Simon Lyall 12 Nov '14

12 Nov '14

Just a reminder to everyone that the list AUP includes: 6. Blatant product or service marketing is unacceptable. so please try not to overdo it. The full AUP is here: http://www.nznog.org/mailing-list Simon. NZNOG list co-moderator. -- Simon Lyall | Very Busy | Web: http://www.simonlyall.com/ "To stay awake all night adds a day to your life" - Stilgar

12 13

New IXs in NZ - discussion
by Tim Hoffman 12 Nov '14

12 Nov '14

All, We’ve had some interesting announcements of Megaport and IX Australia building internet exchanges into NZ over the last week or so. I’ve been a bit surprised at how little chatter there has been around this on the list. I thought I’d put some thoughts down (as someone who has worked for a bunch of networks in NZ and is now overseas working for big content) with hope of kicking off a discussion. At a 10,000 foot view, New Zealand has had a reasonably successful operation of IXs over the last 10-15 years. All of y’all except for the two big operators openly peer. This is awesome! However, as has been discussed in other posts recently; 1/ More and more of the internet is becoming about connectivity from CDNs to users. 2/ More and more CDNs are coming to New Zealand and Australia 3/ Trans-tasman capacity isn’t hugely expensive Addressing points (1) and (2), as content comes into New Zealand, we have to remember that on a global scale, New Zealand is absolutely tiny. It’s a hard business case to get a POP there as a content provider. Content providers that do come are likely just going to put in a single location - Auckland. So while WIX may make sense for ISPs in NZ peering with each other, for the bulk of the *interesting* content on the internet that you can get through peering, you’re going to have to get it in Auckland. Networks have outages, planned works, etc. So assuming that most of NZ’s interesting content is in Auckland (with a bit more over the Tasman, which isn’t too expensive to get to these days), it makes sense to have multiple (redundantly built and managed) ways of getting at this content. It’s interesting looking at the differences between the 3 IXs we’re about to have. Citylink, who have the critical mass of all the peers, are in the most locations, and are the most expensive. They’ve also got a product set around metro ethernet, dark fibre, and have a CDN running. And they’re doing some interesting things around a “SDN driven IX”. Megaport, who have placed huge focus on their “Virtual Cross Connect” product and being able to configure this on the fly, but also have run a pretty successful IX. IX Australia, who are very IX focused, and have gone to great pains to ensure that that’s their only product, making them the most “independent”. IX Australia also have public graphs of traffic levels through their IX (i.e. for NSW-iX http://monitor.nsw.ix.asn.au/cacti/graph_image.php?action=view&local_graph_… <http://monitor.nsw.ix.asn.au/cacti/graph_image.php?action=view&local_graph_…>) - which is commendable (it would be nice to see Megaport and Citylink follow suit on this one) I suspect you’re going to find that most of the content will try to get to all 3. It’s my hope that most of the bigger ISPs try to get to all three, then the smaller ones can go to a couple, get most NZ routes reliantly over peering, and then transit the rest if it has to happen. It would be disappointing if we didn’t see the top 5-6 IXs + all the content providers on all of them. Also it’ll be important to ensure that the result isn’t just that we have 3 split IX communities, all with different content/users on them without crossover, as this would cause a huge barrier to entry to smaller players if they have to connect to all 3. For the community, having this competition is going to be a win. It won’t kill APE, which has huge critical mass, and has done a great job in it’s long history, but will ensure that all 3 IXs keep each other honest. What will be interesting to see is who turns up at which IX and how they all grow together. What’s everyone else’s thoughts? It would be interesting particularly if there is anyone from Citylink, or any of the big ISPs, who could comment on their take on these developments in the market and where they will be peering? Cheers, Hoff

16 19

Non Commercial request for Hardware (learning kit)
by Alexander Neilson 11 Nov '14

11 Nov '14

Hey All Sorry if this is rude of me to ask and I apologise if so. Does anyone have old routers / switches / firewalls / spare parts or modules for same lying around that are still function (or slightly broken) that they are looking at flicking on or long term loaning? I am looking for any gear that would help me get greater exposure to other hardware / configurations and that can be used in my home lab. I currently have a single Cisco 2821 that was pulled from production, and a Cisco Catalyse 2900XL plus on long term loan I have two Juniper J2320’s. The 2821 has a very loud dying fan that I would like to replace (flatmates aren’t so understanding about my learning noises) and I would like to get some more experience with Cisco and other manufacturers. I do also have a copy of GNS3 that I will be trying to use more but I have always preferred to grab actual physical hardware and wire it up and play around with configs etc. I am wellington based so hardware locally would be a bonus but if its something exciting to learn I would probably try save up shipping. Also I don’t have massive space so while some hardware would be awesome to experience I will likely decline for space reasons. Thank you all in advance. Apologies for any noise on the list. Off list replies are probably best. Please note for future people seeing this in the archive, if you want to take a look / have a play any of the hardware I receive would be available for learning loan to others. Regards Alexander Alexander Neilson Neilson Productions Limited alexander(a)neilson.net.nz 021 329 681 022 456 2326

2 1

Load balance appliances
by Jodi Thomson 11 Nov '14

11 Nov '14

Hi All Just wondering what people are using these days for dedicated load balance appliances. Last ones I had anything to do with were the Alteon Ace Directors going back 7-8 yrs so am a little out of touch with whats in use today. Cheers Jodi -- Jodi Thomson Systems & Networks Big Noise Group Ltd 501 Heretaunga Street West, Hastings 4122 Cell (021) 903712 Ph: (06) 876 9661 Fax: (06) 876 9668 Skype: jodit1 Web : http://www.bignoisegroup.com

6 8

Filming a server room
by Ross Ozarka 11 Nov '14

11 Nov '14

Hello members of NZNOG, My name is Ross Ozarka. I'm a filmmaker who is making a documentary about wire. I'm collecting shots of wires put to different uses, and I'd love to show off the wiring of a server room. The shoot will take about ten minutes, and whoever lets me film their server room will receive an Associate Producer credit. Takers, please get in touch with me at ross.ozarka(a)gmail.com so we can set up a day that works best for you. Warm Regards, Ross Ozarka

1 0

UFB 1 gig plans for retail and impact they have
by Barry Murphy 08 Nov '14

08 Nov '14

Hey guys, I just wondered what people thought of the implications around 1gbps residential / business plans now becoming more and more common. I¹m seeing requests from wholesalers and retail asking about this gigatown thing and how they can get a 1Gbps service, especially unlimited. While I know 1gbps is not too common yet, the 200mbps plan is becoming more and more common and it won¹t be long before there is pressure to do 1gbps I know the unlimited part is easy to justify to the client around Œinternational & domestic¹ transit pricing, but some ask why can we not do user to user or peering traffic at 1gbps. I¹m not sure if it¹s still true, but I recall from the Chorus documentation that you could LAG a maximum of 8x10g circuits in a handover region and that was the max, so theoretically 80gbps handover. For the sake of ease and because 10Gbps holes are not cheap in high end routers like ALU 7750 SR-7¹s which we run, we will consider the average provider has a single 10g or maybe 2 per region right now. If you had say 10 or 20 users on the 1Gbps plan or even 100-200 users on the 200mbps plan and they had misconfigured routers (consider they could do 200mbps upload) opening them up to the likes of DNS amplifications etc. Now those users are maxing out the upload capacity of the handover, you have no ability to QoS the malicious users as the QoS would need to come before hitting the handover, I.e. On the CPE. Suddenly everyone on the handover is impacted from a handful of users that wanted the faster speed just because it was available and affordable. The only way to stop the attack affecting everyone would be to isolate and disconnect the end users causing the damage, be it IPOE or PPPoE, if the user was on a direct /30 IP then things are even harder to manage. The DNS amplifications that hurt Spark for a whole weekend, I can only assume was caused by such a large amount of affected devices filling up the handovers and also because it was targeted at their DNS. Imagine an attack of that magnitude, 10s of thousands of end users on 200 or even 100mbps circuits filling up a 10gig or even at this point a 80gbps handover LAG. When you talk about regional handovers up and down the country then the problem gets worse as you then obviously need to backhaul that capacity to Auckland before getting out to the internet, so this also has to be considered too. Any thoughts on the matter. Many thanks Kind regards, Barry Murphy / Chief Operating Officer +64 27 490 9712 / barry(a)vibecommunications.co.nz <http://www.vibecommunications.co.nz/> <https://www.facebook.com/VibeCom> <https://twitter.com/vibecomnz> <https://www.linkedin.com/company/1941512> Office: +64 9 222 0000 / Fax: 0800 842 326 Unit A7, 1 Beresford Square, Auckland, New Zealand Web: www.vibecommunications.co.nz <http://www.vibecommunications.co.nz/> / Peering: AS45177 <http://www.peeringdb.com/view.php?asn=45177> This communication, including any attachments, is confidential. 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. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.

19 36

Network Operators Around the World Demonstrate Their Commitment to a Secure and Resilient Internet
by Dean Pemberton 06 Nov '14

06 Nov '14

This Interesting release via ISOC kinda fits in with the recent conversation around how to protect the Internet from edge originating ause. Any comment from New Zealand Network Operators (thats all of you!) as to whether you see a benefit in this initiative? Anyone want to publically add their name to the list of operators who "have taken one or several of the expected actions defined by the MANRS framework." Interested in peoples thoughts on this. ---------- Mutually Agreed Norms for Routing Security (MANRS) recommendations provide a coordinated approach to improve global routing system [Washington, D.C., USA and Geneva, Switzerland] - 6 November 2014 - Leading network operators around the world today announced that they have implemented a package of recommended measures that help improve the security and resilience of the global Internet. Working together, network operators have developed a tightly defined set of concrete actions to improve the global Internet routing system. The recommendations, called Mutually Agreed Norms for Routing Security (MANRS), recognize the interdependent nature of the global routing system and integrate best current practices related to routing security and resilience. More network operators from across the globe are encouraged to sign onto the movement and participate by visiting the website at www.manrs.org <http://www.manrs.org> and completing the signup form. Organized by the Internet Society, and building on the demonstrated success of coordinated industry activities such as World IPv6 Day and World IPv6 Launch, MANRS represents a significant step forward towards building a more resilient and secure Internet infrastructure. "The security of the Internet as a network of networks often relies on specific collaborative action. This initiative increases the security of the Internet by improving resiliency and stability of the underlying routing infrastructure," commented Olaf Kolkman, the Internet Society's Chief Internet Technology Officer. "Participating network operators committed to the MANRS initiative are taking actions that address problems with incorrect routing information and spoofed traffic, demonstrating their collective responsibility to a healthy and secure Internet ecosystem. We encourage and look forward to other network operators around the world publicly taking these steps." Participating network operators have taken one or several of the expected actions defined by the MANRS framework. These include preventing propagation of incorrect routing information, preventing traffic with spoofed IP addresses, and facilitating global operational communication and coordination between network operators. Committed network operators are: ● CERNET ● Claranet ● Comcast ● KPN ● Level 3 ● NTT ● RUNNet ● SpaceNet ● SURFnet Several of the participating network operators commented on their actions and today's announcement: "Adherence to MANRS is an important commitment that operators make back to the Internet community. Together we aim to remove the havens from which miscreants maintain the freedom and anonymity to attack our network and our customers." - David Freedman, Claranet Group "Comcast is committed to helping drive improvements to the reliability of the Internet ecosystem. We are thrilled to be engaged with other infrastructure participants across the spectrum and around the globe in pursuit of these goals." - Jason Livingood, Vice President, Internet Services, Comcast "Good network routing practice is the fundamental requirement for trust between providers, and ultimately creates a safer and stronger Internet for customers. KPN is committed to providing secure and trustworthy communications, and by joining partners in MANRS, we continue to improve security and resiliency for all." - Jaya Baloo, Chief Information Security Officer, KPN "As one of the most connected Internet providers in the world, security of the Internet is top-of-mind at Level 3 Communications. We are dedicated to supporting and protecting the Internet ecosystem and work each day to safeguard customers' critical communications. The Internet is a shared responsibility, and only through these important collaborative efforts can we continue to ensure the protection of this collective infrastructure." - Dale Drew, Senior Vice President, Chief Security Officer at Level 3 Communications "SURFnet is a big supporter of these initiatives to make the Internet more secure. Committing to the actions as outlined in the MANRS document will make routing on the Internet safer. This impacts every day usage of the Internet and helps with a free, open, and more secure Internet for all users." - Erik Huizer, CTO, SURFnet For more information about MANRS and the Routing Resilience Manifesto visit: http://www.manrs.org <http://www.manrs.org>

3 2

AKL-IX Launching Soon
by Joe Wooller 06 Nov '14

06 Nov '14

Hey All, It looks like NZ is the place to be! I am proud to announce that we have launched a new Internet Exchange in Auckland NZ, AKL-IX! We have just put a place holder page up with some information at http://www.akl-ix.nz <http://www.akl-ix.nz/> IX Australia are the only independent Internet Exchange operator in Australasia, with 16 years experience running exchanges throughout the region. Unlike all other Internet Exchanges in the region, we are not for profit, and seek to serve our members, not our shareholders. We're already very far down the path of bringing some very interesting content providers and large NSPs online. We seek further participants who wish to take part during our start-up phase of operation. During the start-up phase no charges will apply to participants. We are in the process of connecting a number of peers currently. Peers will need to be present at 220 Queen St as this is our first live site. Interested parties can contact peering(a)akl-ix.nz to learn how to take part. For a list of participants will be available on the above website and on PeeringDB (http://bit.ly/1vRAvgZ <http://bit.ly/1vRAvgZ>) If you have any questions please feel free to contact me. Regards Joe

2 2

Who's looking at peering on the new Intellipath / Megaport IX service?
by Jesse Archer 06 Nov '14

06 Nov '14

I see www.Intellipath.co.nz just launched. Anyone else looking at coming on-board? http://www.reseller.co.nz/article/558524/megaport-partners-vibe-break-down-… We've ordered a port at MDR and will VxC to a couple of other networks we do a lot of traffic to. The Megaport IX service in Auckland looks like a credible alternative to Citylink's APE - depends on who comes on-board. I'd be happy if Callplus & Mediaworks on-boarded. *Jesse Archer* *General Manager*Full Flavour *p. *07 929 7111 *ddi*. 07 281 1391 *s*. Skype username "myfullflavour" *e*. jesse(a)fullflavour.co.nz <jesse(a)fullflavourmedia.co.nz> *w*. fullflavour.co.nz <http://t.signauxsept.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XZs2zqj…> *a. *Tauranga Business Centre, 50 Devonport Road, Tauranga *a*. PO Box 16306, Bethlehem 3176, New Zealand

4 3

Chorus UBA price changes for 1st December 2014
by Barry Murphy 05 Nov '14

05 Nov '14

Hey guys, What are other telcos opinions on the proposed chorus price changes that are to take effect on 1st December 2014? Reduction of naked services and increased of clothed services on UBA, yet none of the pricing is 'confirmed' and nor is the POTS reduction pricing. How can the commerce commission or Telecommunications minister allow for something so big to happen so close to a brown out date and with such short notice. It's now the 6th of November and with the proposed changes happening in about 24 days surely it's against their T&C's to give such short notice. We have been provided with 'draft' but that is just not good enough to give to downstream customers and wholesalers, questions we ask go unanswered meaning we can't advise customers of pricing before its out of draft. We had a meeting booked in with Chorus 'Billing resource' to explain the changes, yet this has just been cancelled because things are not yet confirmed internally. My account manager just called me while I was typing this email and said "they still haven't confirmed things internally as they don't know how they are to implement things into their systems". He also advises we are the first customer in the queue to have a billing resource meting to discuss the changes. I then proceeded to ask about the pricing of ADSL install +-$270 vs VDSL install +-$170 and he is even unsure. Just wondering how well or badly other Telcos in the same position are taking this. Cheers Kind regards, Barry Murphy / Chief Operating Officer +64 27 490 9712 / barry(a)vibecommunications.co.nz<mailto:barry(a)vibecommunications.co.nz> [3sparks llc]<http://www.vibecommunications.co.nz/> [Vibe Communications] <https://www.facebook.com/VibeCom> [Vibe Communications] <https://twitter.com/vibecomnz> [Vibe Communications] <https://www.linkedin.com/company/1941512> Office: +64 9 222 0000 / Fax: 0800 842 326 Unit A7, 1 Beresford Square, Auckland, New Zealand Web: www.vibecommunications.co.nz<http://www.vibecommunications.co.nz/> / Peering: AS45177<http://www.peeringdb.com/view.php?asn=45177> This communication, including any attachments, is confidential. 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. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.

3 3

Re: [nznog] UFB 1 gig plans for retail and impact they have
by Mark Foster 04 Nov '14

04 Nov '14

Blocking outbound port 25 blocks the vast majority of non authenticated smtp. The remainder being authenticated (or channelled via the same service provider, who can trace you by your IP, dynamic or not), provides some accountability and makes spam much easier to trace... acknowledging that much spam comes from compromised machines on residential grade connectivity (on port 25). Blocking port 25 outbound (with an opt out option) makes sense if you can't quickly deal with offenders on your network (as often seems to be the case with big players). This doesnt the provide those players with an excuse to under-resource abuse@ (as the remaining spam is finding another way out) but this does seem to happen regardless... so its not even close to a silver bullet but it does helo more than hinder. Mark. Sent from a mobile device. -------- Original message -------- From: Steve Holdoway <steve(a)greengecko.co.nz> Date:05/11/2014 14:56 (GMT+12:00) To: Peter Lambrechtsen <Peter.Lambrechtsen(a)spark.co.nz> Cc: nznog <nznog(a)list.waikato.ac.nz> Subject: Re: [nznog] UFB 1 gig plans for retail and impact they have On Wed, 2014-11-05 at 14:14 +1300, Peter Lambrechtsen wrote: > Have to say that blocking inbound port 25 and 53 is highly recommended > for all RSPs. Plus blocking outbound port 25 to only SMTP servers you > run if you wanted a sense of if customers are using their connections > for mass spamming. With an opt out of course. Given that mail servers also listen on 587 ( thanks billg ) and 465, isn't blocking just 25/tcp just a bit pointless? Steve -- Steve Holdoway BSc(Hons) MIITP http://www.greengecko.co.nz Linkedin: http://www.linkedin.com/in/steveholdoway Skype: sholdowa _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

3 2

Re: [nznog] An 'end to end' Internet (was Re: UFB 1 gig plans for retail and impact they have)
by Scott Weeks 03 Nov '14

03 Nov '14

--- mcdonald.richards(a)gmail.com wrote: From: McDonald Richards <mcdonald.richards(a)gmail.com> I should point out that I mean it purely as an "any service to any service from any host to any host" type of scenario :) Maybe I should have phrased it as the days of unfiltered and unfettered provision of default residential services is coming to an end. ------------------------------------------ I hope not. That'd be the beginning of the slow death of the internet innovation we have seen over the past couple of decades. We will be the new dinosaur. Maybe the homenet WG in IETF will come up with something. <crossing fingers> scott > _______________________________________________ > NZNOG mailing list > NZNOG(a)list.waikato.ac.nz > http://list.waikato.ac.nz/mailman/listinfo/nznog > > _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

1 0

Re: [nznog] UFB 1 gig plans for retail and impact they have
by Scott Weeks 03 Nov '14

03 Nov '14

--- ben(a)meh.net.nz wrote: From: Ben <ben(a)meh.net.nz> My biggest concern ATM over DDOS, is when IPV6 starts becoming widely used - a lot of people use NAT as a firewall, and when they implement IPV6 don't protect their hosts properly. --------------------------------------------- Homenet in the IETF is attempting to address that among other things in the home networks: https://datatracker.ietf.org/wg/homenet/charter <quote> End-to-end communication is both an opportunity and a concern as it enables new applications but also exposes nodes in the internal networks to receipt of unwanted traffic from the Internet. Firewalls that restrict incoming connections may be used to prevent exposure, however, this reduces the efficacy of end-to-end connectivity that IPv6 has the potential to restore. Home networks need to provide the tools to handle these situations in a manner accessible to all users of home networks. Manual configuration is rarely, if at all, possible, as the necessary skills and in some cases even suitable management interfaces are missing. The purpose of this working group is to focus on this evolution, in particular as it addresses the introduction of IPv6, by developing an architecture addressing this full scope of requirements: o prefix configuration for routers o managing routing o name resolution o service discovery o network security </quote> scott _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

2 1

Re: [nznog] CloudFlare Peering Blog
by McDonald Richards 02 Nov '14

02 Nov '14

Mobile in Australia is an oligarchy. Since the collapse of ISPone there seems to be an active effort being put in by the 3 mobile carriers (Telstra, Optus, VHA) to protect their margins and make it as difficult as possible for MVNOs to start up. Prepaid plans should not be that expensive - I have had worse experiences in Germany. Your home Internet is a different story. The caps exist to support the limited resource. Unlimited has been tried and is always abused. The wholesale access charges within Australia require ISP's set limits or it's the same as everyone leaving their taps running and lights on. Cloudflare's experience with Australian bandwidth pricing will be related to the costs charged by the tier 1 carriers (Optus, Telstra and AAPT [note: AAPT may have started peering; I am a little out of the game there now]). They will be seeking direct access to eyeballs and being charged for the privilege, much the same as the issues Netflix is facing with eyeball carriers in the USA. On the cost front, the underlying delivery cost for some of these networks is higher, as they try to keep consistent pricing across all regions of Australia. People in small towns pay the same prices as people in the largest cities. The country is big and the population density is low. Contrast that to Europe, and carriers there have a much easier time making money. Despite all of this, negotiating peering (paid or otherwise) in Europe with their incumbent carriers is just as difficult and costly as in Australia :) - unless you are Cloudflare-size and have hit that critical mass of outbound content that makes you attractive to these incumbents. Macca On Mon, Nov 3, 2014 at 8:04 PM, Petri Ojala <petri.ojala(a)gmail.com> wrote: > > We spend our winter in Sydney. While not directly related to the carrier > bandwidth costs, my mobile charges will triple and broadband internet cost > will be seven fold. > > In addition to the increased costs the services will be slower and I’m > getting data caps, which I don’t have in Europe. The offerings are > crippled by mandatory landlines, 24-month contracts and various other > requirements and fees. While one can get Telstra Cable without a minimum > contract, it comes with a mandatory landline that has penalties if > terminated too early. I won’t even go into details about the customer > experience getting the broadband.. > > I think it tells a story if CloudFare pays the same amount for Australia > as they do for all of Europe. I was actually thinking about buying Telstra > stock simply because it’s de-facto monopoly in the country and not much > light at the other end of the tunnel. > > Petri > > On 3 November 2014 at 10:14:21, McDonald Richards ( > mcdonald.richards(a)gmail.com) wrote: > > Keep in mind that this refers to "Benchmark pricing" with $10 being the > benchmark for the USA. > > Do your own math and draw conclusions from that extrapolation :) > > Macca > > On Mon, Nov 3, 2014 at 7:47 AM, Dean Pemberton <nznog(a)deanpemberton.com> > wrote: > >> Interesting article from CloudFlare... >> >> >> http://blog.cloudflare.com/the-relative-cost-of-bandwidth-around-the-world/ >> >> While NZ isn't mentioned I'm picking we get lumped in with Australia >> for which they have this to say... >> >> "Australia >> >> Australia is the most expensive region in which we operate, but for an >> interesting reason. We peer with virtually every ISP in the region >> except one: Telstra. Telstra, which controls approximately 50% of the >> market, and was traditionally the monopoly telecom provider, charges >> some of the highest transit pricing in the world — 20x the benchmark >> ($200/Mbps). Given that we are able to peer approximately half of our >> traffic, the effective bandwidth benchmark price is $100/Mbps. >> >> To give you some sense of how out-of-whack Australia is, at CloudFlare >> we pay about as much every month for bandwidth to serve all of Europe >> as we do to for Australia. That’s in spite of the fact that >> approximately 33x the number of people live in Europe (750 million) >> versus Australia (22 million). >> >> If Australians wonder why Internet and many other services are more >> expensive in their country than anywhere else in the world they need >> only look to Telstra. What's interesting is that Telstra maintains >> their high pricing even if only delivering traffic inside the country. >> Given that Australia is one large land mass with relatively >> concentrated population centers, it's difficult to justify the pricing >> based on anything other than Telstra's market power. In regions like >> North America where there is increasing consolidation of networks, >> Australia's experience with Telstra provides a cautionary tale." >> _______________________________________________ >> NZNOG mailing list >> NZNOG(a)list.waikato.ac.nz >> http://list.waikato.ac.nz/mailman/listinfo/nznog >> > > _______________________________________________ > NZNOG mailing list > NZNOG(a)list.waikato.ac.nz > http://list.waikato.ac.nz/mailman/listinfo/nznog > >

2 2

CloudFlare Peering Blog
by Dean Pemberton 02 Nov '14

02 Nov '14

Interesting article from CloudFlare... http://blog.cloudflare.com/the-relative-cost-of-bandwidth-around-the-world/ While NZ isn't mentioned I'm picking we get lumped in with Australia for which they have this to say... "Australia Australia is the most expensive region in which we operate, but for an interesting reason. We peer with virtually every ISP in the region except one: Telstra. Telstra, which controls approximately 50% of the market, and was traditionally the monopoly telecom provider, charges some of the highest transit pricing in the world — 20x the benchmark ($200/Mbps). Given that we are able to peer approximately half of our traffic, the effective bandwidth benchmark price is $100/Mbps. To give you some sense of how out-of-whack Australia is, at CloudFlare we pay about as much every month for bandwidth to serve all of Europe as we do to for Australia. That’s in spite of the fact that approximately 33x the number of people live in Europe (750 million) versus Australia (22 million). If Australians wonder why Internet and many other services are more expensive in their country than anywhere else in the world they need only look to Telstra. What's interesting is that Telstra maintains their high pricing even if only delivering traffic inside the country. Given that Australia is one large land mass with relatively concentrated population centers, it's difficult to justify the pricing based on anything other than Telstra's market power. In regions like North America where there is increasing consolidation of networks, Australia's experience with Telstra provides a cautionary tale."

3 2

Call for Papers - APRICOT 2015
by Dean Pemberton 02 Nov '14

02 Nov '14

Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT) 24th February - 6th March 2015, Fukuoka, Japan https://2015.apricot.net CALL FOR PAPERS =============== The APRICOT 2015 Programme Committee is now seeking contributions for Presentations and Tutorials for APRICOT 2015. We are looking for presenters who would: - Offer a technical tutorial on an appropriate topic; - Participate in the technical conference sessions as a speaker; - Convene and chair panel sessions of relevant topics. Please submit on-line at: http://papers.apricot.net/user/login.php?event=19 CONFERENCE MILESTONES --------------------- Call for Papers Opens: 1 November 2014 First Draft Program Published: 6 December 2014 Final Deadline for Submissions: 7 February 2015 Final Program Published: 14 February 2015 Final Slides Received: 21 February 2015 PROGRAMME MATERIAL ------------------ The APRICOT Programme is organised in three parts, including workshops, tutorials and the conference. Topics for tutorials and the conference must be relevant to Internet Operations and Technologies: - IPv4 / IPv6 Routing and operations - IPv6 deployment and transition technologies - Internet backbone operations - ISP and Carrier services - IXPs and Peering - Research on Internet Operations and Deployment - Japan Internet - Software Defined Networking / Network Function Virtualisaton - Network security issues (NSP-SEC, DDoS, Anti-Spam, Anti-Malware) - DNS / DNSSEC - Internet policy (Security, Regulation, Content Management, Addressing, etc) - Access and Transport Technologies, including Cable/DSL, 3G/LTE, wireless, metro ethernet, fibre, MPLS - Content & Service Delivery (Multicast, Voice, Video, "telepresence", Gaming) and Cloud Computing CfP SUBMISSION -------------- Draft slides for both tutorials and conference sessions MUST be provided with CfP submissions otherwise the Programme Committee will be unable to review the submission. For work in progress, the most current information available at time of submission is acceptable. All draft and complete slides must be submitted in PDF format only. Final slides are to be provided by the specified deadline for publication on the APRICOT website. Prospective presenters should note that the majority of speaking slots will be filled well before the final submission deadline. The PC will retain a limited number of slots up to the final submission deadline for presentations that are exceptionally timely, important, or of critical operational importance. Please submit on-line at: http://papers.apricot.net/user/login.php?event=19 Any questions or concerns should be addressed to the Programme Committee by e-mail at: pc-chairs at apricot.net We look forward to receiving your presentation proposals. Mark Tinka, Raphael Ho & Dean Pemberton Co-Chairs, APRICOT Programme Committee

1 0

Cableways rack - offer me beer and it's yours (Auckland)
by David Robb 28 Oct '14

28 Oct '14

I have a surplus-to-requirements cableways rack available to a good home. It’s in Auckland (Blockhouse Bay), and you have to come and pick it up. https://paradise.gen.nz/stuff/rack.jpg If you want to give me money for it, that’d be great, if the best offer is someone who’ll just take it away, that’ll do. Thanks, David

1 0

Moving Phone Lines
by Skeeve Stevens 28 Oct '14

28 Oct '14

Hey all, I have a site in Albany NZ that is merging with a site in the city. They have multiple indials - could be ISDN, I am not sure... they also have multiple 0800's and another 0508 number. We aren't really sure how these are delivered and by who. Does anyone know how I could find this out? ...Skeeve *Skeeve Stevens - *eintellego Networks Pty Ltd skeeve(a)eintellegonetworks.co.nz ; www.eintellegonetworks.co.nz Phone: +612 8014 7398; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; <http://twitter.com/networkceoau> linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com The Experts Who The Experts Call Juniper - Cisco - Cloud - Consulting - IPv4 Brokering

2 1

NZNOG Power Leads and Multiboards
by Mark Foster 28 Oct '14

28 Oct '14

Hi Folks I'm trying to track down the NZNOG pool of power leads and multiboards; i'm hoping to borrow these if possible. Queries to the NZNOG conference team don't seem to be going anywhere and i'm not sure who the organisers for this year are, to ping them personally. Does anyone know the wherabouts of these? Offlist responses perhaps most appropriate. Thanks Mark.

1 1

openvz vm's
by Tony Wicks 24 Oct '14

24 Oct '14

I've noticed openvz VM's on several different international hosing providers have all dropped out at once (currently down), anyone else seeing this ? cheers

3 3

Vodafone VSI / Spark SecureME
by Tom Henderson 22 Oct '14

22 Oct '14

Hi All I'm interested in some feedback (off list) from anyone using either Vodafone VSI or Spark's SecureME offerings. We're currently looking into both of these for a group of hospitality outlets. Cheers Tom Henderson IT Manager | Pack & Company | 027 461 4403 | 09 929 2750 | tom(a)pack.co.nz -- ---------------------------------------------------------------------------If you are not the intended recipient of this email, you must not disclose, copy, or distribute any information contained in or attached to it, or take any action/inaction based on it. Please contact us immediately, and delete this email from your system. Any views or opinions presented in this email are solely those of the author and not of Pack & Company (NZ) Limited (the "Company"), however any intellectual property contained in or attached to this email is the property of the Company. Thank you.

1 0

Unwanted Traffic Removal Service (UTRS)
by Dean Pemberton 15 Oct '14

15 Oct '14

The latest useful community service from Team Cymru ---------- Forwarded message ---------- From: John Kristoff <jtk(a)cymru.com> [ Apologies if you have seen this elsewhere already - jtk ] Friends and colleagues, Last week I briefly discussed a new project we've recently launched and for which invited participation from the NANOG 62 attendees. This is a not so subtle wider request for consideration. UTRS is essentially a community RTBH that people have suggested to us would be a good service to provide, so we're giving it a go. The lightning talk page has the slide deck I presented: <https://www.nanog.org/meetings/abstract?id=2436> I've also put some additional technical detail here: <http://www.cymru.com/jtk/misc/utrs.html> There was a brief discussion, mostly criticism and that is fine, that took place on the NANOG list you may wish to review. If you have an assigned ASN and this sounds like something you or your network would like to take advantage of, drop me a line, I'd sure like to hear about it. If you think this is a terrible idea and want to express all that is wrong with it, tell me that too, I can take it. Even if you're unsure if you would ultimately deploy it in production, but are interested in testing it, do contact me. We won't expend energy on this project and will drop it if we there isn't sufficient interest from the community, but enough trial users would be encouraging. Kindly, John

1 0

Facebook NOC
by Stan Rivett 14 Oct '14

14 Oct '14

Hi guys Has anyone had any luck communicating with Facebook network operations in the past? They appear to be filtering our shiny new /22 and it is making clients somewhat grumpy. Cheers Stan Rivett ------------------ Netspeed Data Ltd PO Box 5691 Dunedin P: +64 3 481 7245 C: +64 21 323 841 ------------------

1 0

Is there anyone on the list using mikrotik hardware to receive UFB Handovers from Chorus?
by Alexander Neilson 10 Oct '14

10 Oct '14

Hey Everyone We have just stood up our first Chorus UFB Handovers in Auckland and Wellington and while the Mikrotik’s are showing the interfaces as running Chorus are telling me their end is “operationally down”. I have tried changing all the settings I have on my end and they are still reporting the same result. I have tried alternative optics, checked light levels with a meter, and even had a Chorus tech out to take a look. Chorus originally pointed to the SFP+ being the issue, now they are saying the config is wrong on my device and that they aren’t “seeing layer two”. I have asked them for any errors on the port or similar and they haven’t reported any to me. I am a little stumped here and would appreciate the advice of anyone doing either 1G or 10G HO Links for UFB with Chorus who could provide any input or any idea of issues they have seen with the configs that would help me diagnose this issue and resolve it. Thank you for your time. Regards Alexander Alexander Neilson Neilson Productions Limited alexander(a)neilson.net.nz 021 329 681 022 456 2326

5 7

Re: [nznog] UFB Upload Issues
by Peter Ensor 09 Oct '14

09 Oct '14

The change in the CFI to DEI occurred between the 802.1q 2005 and the 2011 versions. In 802.1q 2005 section 9.6 Octet 1 bit 5 was defined for use as CFI (Canonical Format Indicator) whereas in the 2011 version of the standard (also shown in section 9.6), this bit has been redefined as the DEI (Discard Eligible Indicator) bit. The diagram is for a single .Q tag but I assume it also applies to additional tags. Cheers, Peter. > From: Nathan Ward [mailto:nznog(a)daork.net] > Sent: Thursday, 9 October 2014 1:26 p.m. > To: Brent Marquis; Dave Mill; Don Stokes > Cc: nznog(a)list.waikato.ac.nz > Subject: Re: [nznog] UFB Upload Issues > > > On 9 October 2014 at 1:09:42 pm, Brent Marquis > (brent.marquis(a)chorus.co.nz(mailto:brent.marquis(a)chorus.co > .nz))<mailto:brent.marquis(a)chorus.co.nz(mailto:brent.marqu > is(a)chorus.co.nz))> wrote: > > > Sorry for the quick reply to myself! > > > > It actually seems like Don might not be 100% correct. > > > > I don?t have IEEE access to get the .1q standard? But > Wikipedia suggests it has been updated in 2005 for CFI to > be DEI: > > > http://en.wikipedia.org/wiki/IEEE_802.1ad > > > > Drop eligible indicator (DEI): a 1-bit field. (formerly > CFI[note > 1](http://en.wikipedia.org/wiki/IEEE_802.1Q#cite_note-2)[2 > ](http://en.wikipedia.org/wiki/IEEE_802.1Q#cite_note-3)) > May be used separately or in conjunction with PCP to > indicate frames eligible to be dropped in the presence of > congestion.[3](http://en.wikipedia.org/wiki/IEEE_802.1Q#ci > te_note-4) > > > With the note suggesting ? ?IEEE 802.1Q-2005 clause 9.6? > > > > If it?s on Wikipedia, it must be true?. Right? J > > The quote above is from the 802.1q page. If you read the > page you link to, the 802.1ad page, you get: > > In IEEE 802.1ad the CFI is replaced by a Drop Eligibility > Indicator (DEI), increasing the functionality of the PCP > field. > > Key bit is ?802.1ad?, not 802.1q. Using 0x88a8 vs > 0x8100/0x9100 is signalling that you?re using 802.1ad vs. > stacked 802.1q, so should set this bit appropriate to the > tag type. I?m with Don on this one - the frame type bits > signal how to interpret the following bits, you can?t just > swap them around. > > People should really just use 0x88a8 - those who aren?t, > can I ask why not? Is it because you?re trying to tunnel > it over a switch that doesn?t support 802.1ad or > something? I?m not saying it?s wrong, I?m interested in > understanding the situations in which you might do this. > > -- > Nathan Ward > 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. > >

3 2

Taking down `rpki-validator.lab.hotplate.co.nz' for a bit
by Michael Fincham 08 Oct '14

08 Oct '14

Hi all, I've noticed a few NZNOGish looking addresses hitting this service periodically, even though an automated upgrade to the rpki-ca package broke the database updates some months ago :) Thanks for checking it out, folks who did, and I hope you found it useful! Just a quick note to let everyone know I'm taking the validator app down for a bit until I have time to fix it and find it a new home (I'm currently paying for a whole VM for it to live on which seems a little unnecessary given it's partially broken). In the mean time, BGPmon has a (much more comprehensive) service you can query via WHOIS: <http://www.bgpmon.net/securing-bgp-routing-with-rpki-and-roas/> -- Michael

2 1

Re: [nznog] UFB Upload Issues (Ewen McNeill)
by Peter Ensor 08 Oct '14

08 Oct '14

Just for clarification, a 802.1ad (TPID = 88a8) does not need to have both a SVLAN and CVLAN. It is allowed to only be a single VLAN tag. This will occur when a an untagged packet ingresses a BS3/3a/4 type service at the UNI (Upstream frame). This frame will be wrapped with a SVLAN but because it did not contain any original CVLAN tag, there will not be any CVLAN tag in the packet that egresses the UFB Handover connection. My reading is that on a 802.1ad interface. the TPID = 88a8 indicates that it is a SVLAN whereas a TPID = 8100 would indicate that it is CVLAN or QinQ. Since both TPID's now use the DEI bit (since the 2011 standard) I'm not sure how else the two frames would be different. Cheers, Peter. Hi Brent, On 9/10/14 16:03, Brent Marquis wrote: > It just gets slightly more confusing. [...] > Which would mean your interpretation is that CFI on 802.1q only applies > if there is also an 88a8 802.1ad tag preceding it. Based on looking at the 802.1Q-2005 specification and 802.1ad-2005 specification that Nathan linked to, it seems to me that the intent of both 802.1Q-2005 and 802.1ad-2005 was that ethertype=0x8100 would mean "interpret the header as a 802.1Q VLAN Tag/802.1ad CVLAN Tag", both of which have the same bit pattern, and semantics -- including a CFI bit rather than a DEI bit. This is section 9.6 in both specifications (which makes sense since 802.1ad was based on 802.1Q). By contrast, in 802.1ad there is a SVLAN tag, with a separate ethertype (0x88a8), which is the same except that it has a DEI bit in the same bit position that 802.1Q/802.1ad has the CFI bit. This is section 9.7 in the 802.1ad specification. It seems to me that the intent was: if ethertype=0x8100 then bit is interpreted as CFI, else if ethertype=0x88a8 then bit is interpreted as DEI. Which gives an unambiguous interpretation, without needing any context (much easier for an ASCI implementation). So I'm pleased IEEE seem to have thought of this problem in advance and tried to avoid ambiguity. However, setting DEI on an 802.1ad frame with ethertype 0x88a8, then changing the ethertype of the outer tag to 0x8100 ("for compatibility" :-) ) seems to either (a) require force-clearing that bit to avoid confusion, or (b) lead to a potential for misinterpretation that causes traffic to be discarded. > IMO, our interface is .1ad and we dont believe being nice and tweaking > the ethertype at RSP request changes that :) but let me see what I can > find out from our Vendor. FWIW, it appears to me that sending two 0x8100 tags stacked is not 802.1ad, but some "pre-standard" double tagging. Even if the frames started out 802.1ad compliant. 802.1ad seems to require a SVLAN tag (0x88a8) around a CVLAN tag (0x8100). Although it appears the difference mostly only matters for the interpretation of this one bit (DEI or CFI). If Chorus is going to offer 0x8100-double-tagging (ie, two 0x8100 tags stacked, pre-802.1ad Q-in-Q) it seems like it'd maximise compatibility if you were able to clear bit 5 (CFI on 0x8100/DEI on 0x88a8) of the tag in that specific case (ie, two stacked 0x8100 tags). Ewen PS: For reference, Nathan's links: http://www.stephan-robert.ch/attachments/File/TIN08/802-1Q-2005.pdf https://github.com/yhaz/homeenv/blob/master/specs/802.1ad-2005.pdf beware the 802.1ad one is a revision 4 draft (they went to revision 6 before the release AFAICT: http://www.ieee802.org/1/pages/802.1ad.html) if you want to argue with vendors it might pay to get the official standard from IEEE directly.

2 1

APRICOT 2015 Programme Committee - call for volunteers
by Dean Pemberton 08 Oct '14

08 Oct '14

Hi everyone, The APRICOT 2015 Programme Committee is responsible for the solicitation and selection of suitable presentation and tutorial content for the APRICOT 2015 conference (http://2015.apricot.net/) The APIA Board selects a new Programme Committee each year and is now seeking nominations from the community. As part of APIA's partnership with APNIC, the PC will be responsible for building the technical & operational content for both APRICOT in Fukuoka, Japan in February/March 2015 and the APNIC 40 Conference in September 2015. Eligible PC candidates are those who have attended APRICOT & APNIC conferences in the recent past, have broad technical knowledge of Internet operations, and have reasonable familiarity with the format of APRICOT & APNIC conferences. Having constructive opinions and ideas about how the programme content might be improved is of high value too. PC members are expected to work actively to solicit content for the two events and review submissions for technical merit. The PC meets by conference call, weekly in frequency during the three months prior to each event. If you are interested in joining the PC and meet the above eligibility criteria, please send a brief note to "apia-sec at apia.org". The note should include affiliation (if any) and contact details (including e-mail address), and a brief description of why you would make a good addition to the PC. PC members receive complimentary registration for the event they helped assemble the programme for. The APIA Board will accept nominations received by the end of Friday 24 October, 2014, and will announce the new PC shortly thereafter. Many thanks! Mark Tinka, Raphael Ho & Dean Pemberton (APRICOT 2015 PC Chairs)

1 0

Re: [nznog] UFB Upload Issues
by Brent Marquis 08 Oct '14

08 Oct '14

Hi Craig, Yes, I spotted that this morning, hence we need some document updates - my understanding (it's not my document) is that specific wording hung around from an old version of the document and it was intended to point out that we will not utilise DEI/colour marking from RSPs into our network. Thanks, Brent BrentMarquis Layer 2 Network Specialist T +6448964169 M +64272290923 E Brent.Marquis(a)chorus.co.nz -----Original Message----- From: Craig Whitmore [mailto:lennon(a)orcon.net.nz] Sent: Thursday, 9 October 2014 10:44 a.m. To: Brent Marquis; nznog(a)list.waikato.ac.nz Subject: RE: [nznog] UFB Upload Issues Maybe I'm a little confused but reading the TUG it says DEI is not used /aware? Page 48 of the Chorus NGA TUG it states... Canonical Format Indicator (CFI) or Discard Eligible Indicator (DEI) is set to 0. DEI applies to the 802.1ad outer tag and is not used, i.e. NGA is not colour-aware. ???? -----Original Message----- From: nznog-bounces(a)list.waikato.ac.nz [mailto:nznog-bounces(a)list.waikato.ac.nz] On Behalf Of Brent Marquis Sent: Thursday, 9 October 2014 9:44 a.m. To: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] UFB Upload Issues Thanks for pushing all that info back into the list. I know of 1 RSP which has Juniper equipment that seems to be discarding CFI/DEI=1. I guess some switches need a bit of config to recognise CFI as DEI or to re-write it entirely (luckily there haven't been any hardware issues yet) 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.

1 0

Call for Papers NZNOG 2015
by Richard Nelson 05 Oct '14

05 Oct '14

It turns out that June is much too early to issue the CFP for NZNOG next January. So here it is again. We are negotiating with some interesting international speakers but we rely on submissions from the local community to make the programme interesting. Remember there is a prize of a trip to Japan. Richard. -------- The NZNOG organising committee invites papers for its 13th annual conference, to be hosted at the Distinction Hotel, Rotorua, New Zealand from 26 - 30th January 2015. There will the three day Workshops 26 – 28 January, a day of tutorials on 28 January with the main conference on 29 – 30 January. The best local conference paper as judged by the trustees in association with the programme committee will win a trip to APRICOT 2015, to be held jointly with APAN 39 in Fukuoka, Japan, from February 24th to March 6th 2015. Umm that’s right, an all[1] expenses paid trip to JAPAN!!!! It's a real thing. Two people have won this in previous years and to be honest they seemed pretty happy with the prize. Conference objective: The NZNOG conference, workshops and tutorials are a once-a-year opportunity for individuals and organisations involved in Internet operations to meet and share the latest in Internet operations, technologies practices and receive high quality training. The event is unique in New Zealand and attracts technical, skilled individuals with a genuine interest in Internet operations and Internetworking technologies. Submit a paper: Presenters are invited to submit abstracts of their paper for consideration by Monday 20th October. Abstracts should be no more than one page long and provide a summary of your networking-related subject matter. Please note that full slide decks will be required by late November. To submit your paper please e-mail: talks(a)nznog.org When considering a presentation, remember that the NZNOG audience is mainly comprised of technical network operators and engineers with a wide range of experience levels from beginners to multi-year experience. There is a strong orientation to offer core skills and basic knowledge in SIGs and to address issues relevant to the day-to-day operations of ISPs and network operators in the conference sessions. Note: The inclusion of a title, bio, topic, abstract, and slides with proposals is not compulsory but will help us determine the quality of your proposal and increase the likelihood it will be accepted. The organising committee will evaluate proposals based on fit with the conference’s objective and its ability to stimulate lively discussions around the current state of New Zealand networking. The best local paper will be judged by a selection of the trustees and the programme committee. It will be expected the best paper is submitted by the winner for presentation at APRICOT. More details on paper submission can be found at http://www.nznog.org/call-for-papers For more information about the conference visit www.nznog.org or contact: talks(a)nznog.org [1] where 'all' means Return Flights, Accommodation and Conference Fees. You still need to pay for things like food and entertainment. Most of what you need to eat/drink is covered in the conference though. We're also open to cases of special needs should you win. --------

1 0

Shell Shock - Bash vulnerability - CVE-2014-6271
by Dean Pemberton 28 Sep '14

28 Sep '14

Hi all, This isn't normally a security vuln release list but this one looks pretty bad A newly discovered vulnerability (CVE-2014-6271) in the Bash command-line interpreter poses a critical security risk to Unix and Linux systems. It allows remote code execution. NZITF is responding to this remote execution exploit, with a News page that we will be keeping up to date - http://www.nzitf.org.nz/news.html . We are also reaching out to technical and security community points of contact to raise awareness to the issue and ensure necessary action is taken (hence this email to you). Please note, no patch is yet available for Mac OSX. However, many other patches are available. So Patch, Patch, Patch. Regards, Dea

21 35

2degrees
by Matthew Harrison - PrimoWireless Ltd 24 Sep '14

24 Sep '14

Can someone from 2degrees please contact me off list. Regards, Matthew Harrison The Top Dog Please excuse the shortness of my email as it was sent from my phone.

2 1

Whole of Domain Web Harvest 2014 - Robots.txt
by Jay Gattuso 23 Sep '14

23 Sep '14

Hi Noggers, We are looking at undertaking another Whole of Domain (WOD) web harvest during this financial year. (I will be in touch with you with the specifics once we have some of the timings formalised with the crawl contractor, the Internet Archive. I wanted to ask for your views on adherence to robots.txt. We have three options that are hypothetically available to us, each with various merits. 1) Strictly adhere - will miss some artefacts required to replay a site correctly 2) Adhere but follow embeds - (allows us to get linked images, css, some json etc) 3) Ignore - most fulsome crawl. On the last WOD (in 2013) we used option (2), and I wanted to test if this was still the right option to choose. We aim to capture the most complete snapshot of the NZ web possible so it is available to future generations. This Robots issues directly affects the completeness of the crawl we can undertake. If we choose the wrong option, there is a risk of a, reduced crawl coverage, and frustrated web content operators. I'm really keen to make sure we are able to capture the most complete WOD we can, and seek your opinions on the above, on or off list. Many thanks, Jay Jay Gattuso | Digital Preservation Analyst | Preservation, Research and Consultancy National Library of New Zealand | Te Puna Mātauranga o Aotearoa PO Box 1467 Wellington 6140 New Zealand | +64 (0)4 474 3064 jay.gattuso(a)dia.govt.nz<mailto:jay.gattuso(a)natlib.govt.nz>

6 5

Did DNS replies for outlook.office365.com increase in size on Friday?
by Michael Fincham 23 Sep '14

23 Sep '14

Hi all, Out of curiosity - did anyone else see the DNS replies for outlook.office365.com scoot over 512 bytes on Friday? An ANY query from here currently returns a 740 byte answer. Trying to determine if Microsoft changed something on their end or my customer's router unexpectedly lost the ability to deal with large DNS replies 8^) -- Michael

3 4

2U swap for DR
by Rob McDonald 22 Sep '14

22 Sep '14

Hello all, I'm canvassing (soliciting??) for people interested to swap a few U and a few Mbps for a DR / monitoring server. People who just want to sell me rack space and data in a one way arrangement need not apply, I can research that myself. We are based in Auckland, but realise that all the sites we have available to put our monitoring and DR server are also in Auckland, with very similar network paths. To keep it on topic, to the winning referral goes the beer! Cheers Rob *Rob McDonald | *Director Level 2 Systems Ltd *M:* +64 21 902 929 *eFax:* +64 9 974 4734 *W:* http://www.L2.co.nz <http://www.l2.co.nz/>

1 0

Spark Lightbox question
by Tony Wicks 20 Sep '14

20 Sep '14

Hi guys, does anyone know the traffic path (or source IP's) for the Spark Lightbox service ? Interested to know if they are handing the traffic over APE or not. I really hope someone has not done something very stupid and put the streaming servers in Sydney and expect all the ISP's to pay to haul the traffic in internationally. [root(a)dalek ~]# traceroute lightbox.co.nz traceroute to lightbox.co.nz (54.252.86.48), 30 hops max, 60 byte packets 1 103-9-40-81.flip.co.nz (103.9.40.81) 1.355 ms 1.415 ms 1.408 ms 2 v503-ae1.icore1-e.flip.co.nz (103.9.41.35) 0.278 ms 0.280 ms 0.277 ms 3 v503-ae1.icore1-w.flip.co.nz (103.9.41.34) 0.290 ms 0.290 ms 0.284 ms 4 ten-1-0-0-250.bdr01.akl05.akl.VOCUS.net.nz (175.45.102.9) 0.254 ms 0.250 ms 0.245 ms 5 ten-0-2-0-3.cor01.alb01.akl.VOCUS.net.nz (114.31.202.88) 24.333 ms 24.328 ms 24.316 ms 6 ten-0-0-0-2.cor03.syd03.nsw.VOCUS.net.au (114.31.199.116) 23.842 ms 23.783 ms ten-0-3-0-2.cor03.syd03.nsw.VOCUS.net.au (114.31.202.85) 24.037 ms 7 ten-1-1-0.bdr03.syd03.nsw.VOCUS.net.au (175.45.72.116) 23.760 ms ten-2-1-0.bdr03.syd03.nsw.VOCUS.net.au (114.31.192.43) 23.733 ms 23.730 ms 8 16509.syd.equinix.com (202.167.228.131) 23.716 ms 23.986 ms 23.991 ms 9 54.240.192.77 (54.240.192.77) 24.736 ms 25.515 ms 24.739 ms 10 54.240.192.107 (54.240.192.107) 24.727 ms 24.841 ms 24.755 ms 11 ec2-54-252-0-1.ap-southeast-2.compute.amazonaws.com (54.252.0.1) 25.549 ms ec2-54-252-0-5.ap-southeast-2.compute.amazonaws.com (54.252.0.5) 25.781 ms ec2-54-252-0-1.ap-southeast-2.compute.amazonaws.com (54.252.0.1) 26.035 ms 12 * * * 13 * * * cheers

4 3

Call for NZ Provider
by Daniel Watson 20 Sep '14

20 Sep '14

Gday Noggers, I am currently seeking any NZ providers whom would meet the following requirements, Being able to rent dedicated servers at reasonable market pricing, Being able to provide us a BGP session on IPv4 & IPv6 to advertise our own IP's Being able to set up a VyOS VM to act as our router via a direct BGP session to said provider If you can meet these requirements, I am eger to meet you :D Please respond off-list if you can meet this requirement Regards, Daniel Watson Network Administrator / Network Operations Manager E Daniel(a)GloVine.com.au<mailto:Daniel(a)GloVine.com.au> W www.GloVine.com.au<http://www.GloVine.com.au> "No trees were harmed in the making of this email, however a large number of electrons were terribly inconvenienced."

1 0

[OT] APC Suppliers / Reps
by Alexander Neilson 18 Sep '14

18 Sep '14

Hey Noggers. Beer for the OT Taking a look at the APC Website and their Distributors I can only see acquire listed for NZ. I have no experience with them as a supplier, can others provide me with experiences offline? Also is there anyone else in NZ who supplies APC gear / is an APC Rep / Expert who would be able to help with planning some purchases? I have a couple of small DC’s to fit out (starting small but planning to improve management features on it as well). Any contact details would be much appreciated. Regards Alexander Alexander Neilson Neilson Productions Limited alexander(a)neilson.net.nz 021 329 681 022 456 2326

2 1