April 2015 - NZNOG - lists.nznog.org

list.waikato.ac.nz Has Moved
by Donald Neal 11 Dec '24

11 Dec '24

NZNOG-People, I have just finished migrating all of the mailing lists held at The University of Waikato from one server to another. I don't have any reason to believe that anything's gone wrong, but please bear with me for today if it turns out that something has. - Donald Neal -- Donald Neal | Q: How many Aucklanders does it take to change Systems Programmer/Analyst | a light bulb? The University of Waikato | A: Pass me that candle and I'll tell you. Hamilton, New Zealand | --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

4 3

RE: Sort of OT: are there any "Internet enabled" temperature sens ors/servers for Auckland?
by Greg Clare 18 Aug '21

18 Aug '21

May not be exactly what you are after? However DSE have an Internet weather station at the Albany HQ. http://www.dse.gen.nz/public/webdata/weather.htm Regards Greg > -----Original Message----- > From: Juha Saarinen [mailto:juha(a)saarinen.org] > Sent: Wednesday, 2 January 2002 2:47 pm > To: NZNOG > Subject: Sort of OT: are there any "Internet enabled" temperature > sensors/servers for Auckland? > > > Measuring the outside temperature, with geographic location given. > > -- > Juha > Take off every sig! > > - > To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz > where the body of your message reads: > unsubscribe nznog > - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

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

UFB Upload Issues
by Dave Mill 20 Aug '15

20 Aug '15

Hi all If any RSPs currently have any reports of 100/20 UFB Right Performing customers having only 2M upload could you contact me offlist? If you do contact me I'm really interested in where your BNG is and where your customers are with the issue. If any end users are on 100/20 with only 2M upload also feel free to contact me. I'm more interested in your location and your ISP in this case. Cheers Dave (representing Inspire Net in this post)

17 34

Chorus EUBA + IPV6
by Simon Allard 02 Aug '15

02 Aug '15

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

5 5

APNIC 40 Conference - Call for Papers
by Elly Tawhai 29 Apr '15

29 Apr '15

________________________________________________________________________ APNIC 40 Conference - Call for Papers ________________________________________________________________________ Hi NZNOG Community, The APNIC 40 Program Committee is now seeking presentations for the APNIC 40 Conference in Jakarta, Indonesia. We are looking for content that would suit the APOPS Plenary, technical conference sessions, lightning talks and Birds of Feather (BoF) sessions. Key Dates --------- The timeline for submissions is: Call for Papers Opens Now First Round Paper Acceptance 17 July 2015 Final Deadline for Submissions 14 August 2015 Final Round Paper Acceptance 21 August 2015 Final Slides Received 4 September 2015 Submitting Proposals -------------------- http://submission.apnic.net/user/login.php?event=28 Program Material ---------------- The technical sessions at APNIC 40 will include presentations relevant to Internet operations and technologies. The following topics are examples of possible areas of interest. - ISP and Carrier Services - IXPs and Peering - Network and infrastructure security - Access and Transport Technologies - Content and Service Delivery - Software Defined Networking and Network Function Virtualization If you have any other ideas or proposals for panel or BoF sessions, please feel free to submit your ideas via the submission system. If you have any questions, please email the Programme Committee: pc-chairs(a)apricot.net For more information about APNIC 40, please visit: https://conference.apnic.net/40 On behalf of: ________________________________________________________________________ Dean Pemberton & Mike Jager APNIC 40 Program Committee Co-chairs ________________________________________________________________________

1 0

IANA AS Numbers registry update
by Selina Harrington 29 Apr '15

29 Apr '15

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

1 0

Re: [nznog] Looking for data on how much Netflix/SVOD data NZ ISPs are seeing
by Richard Naylor 28 Apr '15

28 Apr '15

At 09:23 a.m. 29/04/2015, Barry Murphy wrote: >Obviously the cache fill that happens between >midnight and mid-day consumes some bandwidth, we >find the fill capacity (after the initial fill) >is about 1.2gbps for on average 2-4 hours per day. >We currently share our cache on Megaport IX >Auckland, in doing so we find weâre filling a >few other providers caches so they donât have >to fetch it from AU, so this may be helping some providers. Thanks Barry - Thats REALLY useful. I'm involved in downstream activity in 2 areas. First - Uploading We have a current project moving some older videos from a server in NZ to Vimeo. Theres a weekly 20GB limit on uploads and an ugly web uploader (no restarts and a break means a complete re work). Using ADSL its pretty ugly. It takes 3.5 days to get 20-30GB up and ADSL 'breaks' make life a real pain. So I pay a local church to use their UFB. We find that uploading during the day conflicts with US based uploaders, so only get 10Mbps upload. If I wait until 5pm, we get a pretty good 100Mbps and the 20GB is up in about an hour. The first time we did it a 2.5G file that took 12 hours ( and failed) on ADSL went up in 4 minutes. Looking at the graph, it seems we have a nice window between 5pm and 8 or 9pm to do our uploads. Thats great to know. The second issue - Live feeds. We're doing quite a bit of live TV feeding using the net now. We have RX points with both TVNZ and TV3 - and also Sky Sport UK. The local TV companies are OK - its local (bounces out of SYD) and only SD and they don't really trust this IP stuff. Sky UK is different. We send them HD at 4Mbps and after some small adjustments for latency, can do live crosses with 3 sec delay (4 sec total allowing for return audio for the talent earpiece). NZ to UK is pretty solid. The other night we tried UK to NZ. NZ RX was via ADSL. We found we could only get a 1Mbps feed going. (vs 4Mbps going the other way) We need to do more testing as there are feed aggregation points and they are different depending on direction, but we have been wondering if there was congestion along the way causing the issue. If so we need to avoid doing crosses during the 'flix' peak. We are also going to test where we do the feed aggregation to see if that helps. Currently NZ to UK has aggregation in London, while UK to NZ has aggregation in LAX. We think its the LAX to NZ leg that suffers. More testing required. Richard

1 0

Looking for data on how much Netflix/SVOD data NZ ISPs are seeing
by Dean Pemberton 28 Apr '15

28 Apr '15

Hi Everyone. Following recent media articles making mention of "the Netflix effect" and broadband slowdowns at peak times, we've had a number of requests to see if we could pull together some facts from NZ ISPs detailing what they are actually seeing. So the question is... How much Netflix/SVOD traffic are you seeing, either as a direct measurement or percentage of total traffic. Does this percentage change at all during the day/week. I realise that this may be considered commercially sensitive but I'm sure we can find a way to make it work. If you're happy to give number on the list that would be great. Good on you for sharing. If you're not comfortable with that then drop me a line and we can discuss how you might feel more comfortable about sharing the facts. I'm happy to agree to only give an aggregated number from people who contact me privately for eg "ISPs are seeing between X and Y % SVOD traffic" Or you could just tell me and I'll keep it to myself (not quite as helpful but I can use it for context). You could also tell me "we have no way of knowing" and I guess that's a data point too :). Thanks -- Dean Pemberton Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean(a)internetnz.net.nz To promote the Internet's benefits and uses, and protect its potential.

2 1

Need assistance troubleshooting a DNS issue
by Glen Eustace 26 Apr '15

26 Apr '15

>From about October/November last year we have been getting the odd call from some of our customers to report that our servers are ‘not found’. So far, each report has been from an Xtra broadband user. When investigating these reports we have found that the servers were fine and DNS lookups from various sources (except Xtra) were as well. Last night the issue happened to a member of the family so I was able to jump onto their computer using Teamviewer and do some more thorough diagnostics. My results were; Name servers in use: ns1.xtra.co.nz <http://ns1.xtra.co.nz/> and ns2.xtra.co.nz <http://ns2.xtra.co.nz/> Name servers pingable from PC: Yes Does smtp.godzone.net.nz <http://smtp.godzone.net.nz/> resolve: No, times out Do other resources in our DNS resolve: No, time out Do resources in other DNS servers resolve: Yes Are all 4 of our name servers pingable from PC: Yes, 2 in NZ and 2 offshore Use nslookup to query our name servers directly, does smtp.godzone.net.nz <http://smtp.godzone.net.nz/> resolve: Yes Use nslookup to query our name servers using 8.8.8.8, does smtp.godzone.net.nz <http://smtp.godzone.net.nz/> resolve: Yes To fix the issue on the PC, I manually set the name servers to 8.8.8.8 and 8.8.4.4, all our services were then resolvable and useable. So, whats going on ? How are our servers different ? Well, we are one of the few ISPs that are using DNSSec to sign zones. Is DNSSec broken ? Not according to dnsviz.net <http://dnsviz.net/> The problem is also intermittent, I have heard that the two Xtra servers are actually LB VIPs in front of a farm of name servers. With the intermittent nature of the issue I wonder whether one server in the farm might be broken/misconfigured, just a thought. I have tried, without success to contact appropriate people at Xtra to either comment or assist and have failed to get past the level one helpdesk people. Their only response being “Sorry we can’t help you”. I am not saying this is an issue with Xtra’s internal recursive DNS servers but so far I have been unable to replicate the issue and have had no reports from any of our other customers using alternative broadband suppliers. I have run out of ideas now on how to continue to investigate this and just changing to Google’s DNS servers might work but isn’t a great solution. If anyone has any suggestions I’d appreciate hearing from you. Glen. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Glen and Rosanne Eustace, GodZone Internet Services, a division of AGRE Enterprises Ltd., P.O. Box 8020, Palmerston North, New Zealand 4446 Ph: +64 6 357 8168 <tel:%2B64%206%20357%208168>, Fax: +64 6 357 8165 <tel:%2B64%206%20357%208165>, Mob: +64 27 542 4015 <tel:%2B64%2027%20542%204015> "Specialising in providing low-cost professional Internet Services since 1997"

8 12