- NZNOG - lists.nznog.org

nzwrt redux?
by Dave Taht 22 Nov '15

22 Nov '15

this is looking quite good: https://www.indiegogo.com/projects/turris-omnia-hi-performance-open-source-… Dave Täht Let's go make home routers and wifi faster! With better software! https://www.gofundme.com/savewifi

10 14

about NZNOG Conference 2016
by Hiroki Kashiwazaki 21 Nov '15

21 Nov '15

Hi, Although I want to attend NZNOG conference 2016, I cannot find any information on NZNOG web site and ML archives. Are there any information?

2 1

UFB 2M upload issues - DEI markings - Juniper
by Dave Mill 19 Nov '15

19 Nov '15

Hi all We have finally fixed our 2M upload issues on Chorus UFB accelerate plans. Skip to the end of this email if you just want an example fix. Along the way we established a couple of incorrect "facts". Some of which I shared with this list. These were: 1) DEI marked packets were being silently dropped on ingress from the Chorus handover 2) Junos 12.3 fixed this issue Recently I deemed that "fact" 1) was wrong and hence "fact" 2) was a bit irrelevant. Here's a crude diagram of our typical set-up: <Chorus handover> <-> [1] <MX80> [2] <-> MPLS/VPLS over Backhaul fibre <-> [3] <PMR MPLS MX> [4] <-> [5] <PMR BNG> Where the numbers in the square brackets are interfaces where I performed some traffic stats. I deemed that DEI=1 marked packets were still showing up at [1] and [3]. They were not showing up at interfaces [4] and [5]. This deemed my above "facts" incorrect. With Juniper CoS you classify on ingress and rewrite on egress. Once we deemed that DEI marked packets were not being dropped at [1] and instead were being dropped between [3] and [4] we can now rewrite these before interface [4]. As we need to rewrite on egress we'll do this at point [2]. In our test case interface [2] is actually xe-1/2/0.388 . And a simple fix for the issue is under the class-of-service section implement: interfaces { xe-1/2/0 { unit 388 { rewrite-rules { ieee-802.1ad { ieee-802.1ad-dei-rewrite; vlan-tag outer; } } } } } rewrite-rules { ieee-802.1ad ieee-802.1ad-dei-rewrite { forwarding-class best-effort { loss-priority low code-point 0000; loss-priority high code-point 0000; } } } The key is to use a ieee-802.1ad rewrite rule rather than a ieee-802.1 rule. The leftmost bit of the 4 bit code-point is the DEI bit. This is all assuming that all traffic is classified as best-effort at interface [1] - if that is not the case then re-write the DEI bit for your other queues as well. You only need to rewrite the outer vlan DEI bit. This is tested on Junos 12.3R8.7 on a MX80. Thanks to all involved in helping fix this - Steve K, Vance and Ivan especially. Cheers Dave

3 4

Cisco Config for Chorus HSNS SHDSL Service?
by Alan Howard 19 Nov '15

19 Nov '15

Hi I have to configure a Cisco 888EA router for a 10Mb HSNS SHDSL service from Chorus, which is not something I have tackled before. Does anyone have a config example suitable for the Chorus service that they can share? I've been Googling for a config but can't find anything specific to Chorus. Any assistance appreciated. Alan.

2 3

1000BaseT SFP modules
by Gareth Fletcher 19 Nov '15

19 Nov '15

Hi team Sooo would anyone happen to be in Auckland and have a couple of spare GLC-T 1G SFP modules that they'd be willing to part with for a month or so? The $nobrand ones we got coded for our Nexus 9Ks don't work in our 3k :( And now in a bit of a pinch... If you do please reply off-list, and please include your beer of preference. Cheers Gareth

1 0

Re: [nznog] nzwrt redux?
by Ray Taylor 18 Nov '15

18 Nov '15

I imagine once we see ufb unbundling then that could slightly change. The big issue is incompatibilities between pon systems and making an ont in a small sfp form factor. Sent from my Samsung Galaxy smartphone.<div> </div><div> </div><div>-------- Original message --------</div><div>From: Tristram Cheer <t(a)uber.co.nz> </div><div>Date: 19/11/2015 13:04 (GMT+12:00) </div><div>To: Daniel Christie <daniel.christie(a)enlighten.co.nz>, Dave Taht <dave.taht(a)gmail.com>, NZNOG(a)list.waikato.ac.nz </div><div>Subject: Re: [nznog] nzwrt redux? </div><div> </div>Under the current UFB structure there is no scope for RSP supplied or end user supplied pluggable optics TRISTRAM CHEER Network Architect - Most problems are the result of previous solutions... E: t(a)uber.co.nz P: 09 438 5472 Ext 803 | M: 022 412 1985 | W: www.uber.co.nz 53 PORT ROAD | PO BOX 5083 | WHANGAREI | NEW ZEALAND -----Original Message----- From: nznog-bounces(a)list.waikato.ac.nz [mailto:nznog-bounces(a)list.waikato.ac.nz] On Behalf Of Daniel Christie Sent: Thursday, 19 November 2015 1:02 p.m. To: Dave Taht <dave.taht(a)gmail.com>; NZNOG(a)list.waikato.ac.nz Subject: Re: [nznog] nzwrt redux? That actually seems really cool, Would the SFP port work in NZ for removing the need of an ONT? Is it something that the fibre companies would allow consumers to do? ---------------------------------------------------------------------- Daniel Christie SYSTEMS ENGINEER/APPLICATION SPECIALIST PHONE +64 7 8536060 | www.enlighten.co.nz -----Original Message----- From: Dave Taht [mailto:dave.taht(a)gmail.com] Sent: Tuesday, 17 November 2015 1:20 AM To: NZNOG(a)list.waikato.ac.nz Subject: [nznog] nzwrt redux? this is looking quite good: https://www.indiegogo.com/projects/turris-omnia-hi-performance-open-source-… Dave Täht Let's go make home routers and wifi faster! With better software! https://www.gofundme.com/savewifi _______________________________________________ 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 _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

2 1

Dell R610 P/Supply
by Shaun McGuane 16 Nov '15

16 Nov '15

Hi NZNog, Apologies for being off topic - Trying to tap into the local knowledge :) I am over here at our office and shipped over some servers that had a power supply go bang! Wondered if you guys knew of any local places where I could pick up server spares. In particular Dell R610 717W – Model D717P-S0 Thanks in advance Regards Shaun

2 1

Re: [nznog] Dell R610 P/Supply
by Shaun McGuane 16 Nov '15

16 Nov '15

Thanks for the replies everyone. All sorted. Cheers Shaun From: <nznog-bounces(a)list.waikato.ac.nz<mailto:nznog-bounces(a)list.waikato.ac.nz>> on behalf of Shaun McGuane <shaun(a)rackcentral.com<mailto:shaun(a)rackcentral.com>> Date: Tuesday, 17 November 2015 at 10:22 AM To: NZNOG <nznog(a)list.waikato.ac.nz<mailto:nznog(a)list.waikato.ac.nz>> Subject: [nznog] Dell R610 P/Supply Hi NZNog, Apologies for being off topic - Trying to tap into the local knowledge :) I am over here at our office and shipped over some servers that had a power supply go bang! Wondered if you guys knew of any local places where I could pick up server spares. In particular Dell R610 717W – Model D717P-S0 Thanks in advance Regards Shaun

1 0

Does Spark host any actual IPv6-connected resources behind AS4648?
by Mark Foster 15 Nov '15

15 Nov '15

Hiya folks, An honest question... Having been told by a commercial solutions type person at Spark that IPv6 peering is only available for International Transit services - not Domestic - i'm left wondering how much IPv6 actually exists within AS4648? I am not aware of any specific examples of IPv6 connections (either 'content' or 'eyes') in the AS to use as a starting point, but it's quite disappointing to consider that any traffic between my AS and Spark's is being forced to use international transit. (The wording of the correspondence I received on the subject used the word 'currently' suggesting a possible future change on this position, but it also said 'no date for when this will be available' which suggests no great hurry either). Obviously the disappointment would be metered a little if I knew for sure there was essentially no chance of requiring such a peering link, for example if there's no other IPv6 within-or-behind AS4648 that I can't get to via other means. I assume that other NOG'rs who have 'domestic transit' or 'paid peering' with Spark have got similar ipv6 peering problems - I find it incredible that this many years beyond IPv6's initial 'push' [1], that backbone environments - those that don't necessarily have heavy ties to software or systems that may still have compatibility issues[2] - cannot be rigged for IPv6 in relatively short order. Interested in the experiences of others, on-or-offlist as preferred, in terms of Spark and IPv6, or if there's any insight as to Spark's intentions to deploy IPv6 and support it for their wholesale domestic links. Cheers Mark. [1] The oldest post on the NZ IPv6 Task Force website is dated August 2009. We've certainly had a complete technology-refresh-cycle since then, surely?! [2] Notwithstanding [1] I know there are still limitations to IPv6 offerings to customers within my organisation[3], but we are at least committed to working through these and for a large subset of product types, dual-stack is fully available. As such we are seeking to establish IPv6 peering arrangements, initially with all those that we peer with over IPv4 but obviously as openly as possible for the benefit of all parties. [3] When I say 'We' i'm talking about ICONZ, AS4770. If you peer with ICONZ (directly or via a peering exchange[4]) and would like to peer over IPv6, please do drop a note to noc(a)iconz.net and we'll happily set it up. We're already peered with the APE and WIX RR's and with a few domestic peers in addition to our transit provider(s). I should also note that i'm leaving ICONZ in the next week or so, so personal enquiries about ICONZ's position may have finite value. :-) [4] ICONZ is presently on APE and WIX and is hoping to establish a link to AKL-IX in the new year. If they share physical footprint or switch domain they're also happy to bilat or direct-ethernet if it makes sense to do so. Cheers Mark.

2 1

GPON/VDSL/ADSL vendor advice
by Mark Tees 04 Nov '15

04 Nov '15

Hi all, Looking for some advice/recommendations. We’re looking to select a GPON/VDSL/ADSL vendor for a number of new greenfield and brownfield deployments and have been considering the big 3 - ALU, Huawei and Calix. In PON land we would be delivering an “RSP” style service where each port, or a VLAN on a port can be sold to a different RSP to deliver services on. We are also delivering RF and POTS services via these units. So far we’ve found most them to be largely feature comparable and stable in terms of implementation and support. Each vendor has been keen to engage with us and work to make us as comfortable as possible with their product set. The only major differentiator on a hardware level is we’ve noted that the newer ALU chassis do not support xDSL cards, and so we would be stuck on the previous generation of chassis if we wanted to retain xDSL support, where Huawei and Calix don’t have this limitation. We do like Calix’s general view towards software programability and what they are talking about in terms of the future of SDN based networking. That said, there seems to be a number of pro’s/con’s with respect to each vendor in their own ways. Does any one have any strong opinions or recommendations why one vendor is better than another? Equally, does anyone have any brilliant success stories with any of the vendors or horror stay-away stories that we should know? -- Regards, Mark L. Tees

3 2