December 2014 - NZNOG - lists.nznog.org

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

12 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 21 Aug '15

21 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

BCP / Guidance on IPv6 prefix size to provide to customers
by Alexander Neilson 03 Jan '15

03 Jan '15

I wondered if anyone on here had any guidance on any current BCP (or BCOP) or some general guidance on IPv6 allocations to customers (I am speaking here only for casual day to day allocations to customers) Looking through email archives and discussions that have seen around there was fairly vigorous discussions but no real resolutions. I have seen suggestions of /48, /50, /56. I am inclined to allocate /56’s to each customer (providing 256 /64’s). I don’t want to prevent customers from having the flexibility to do what they need / want to do nor stymie future use cases. If there is some good guidance on a need for /48’s then I will look at it and will use those if needed. Also, is current operating practice amongst others for all links to be /64’s even for p2p links? It seems a lot of documentation / reference texts are a few years old now and some providers have told me that this advice is no longer current but I haven’t yet seen this codified. My /32 allocation is provisionally as follows: 16 bits of /56 allocations - 65,535 customer allocations 8 bits for internal (leaves me 255 /64’s for p2p links between routers) Currently using PPPoE for IPv4 authentication for bulk customers and bespoke routed configurations for the rest. I intend to continue the PPPoE at this stage and just provide dual stack to every customer when connecting. I am still open to any input people have or feedback about what contributed to their deployments. I have looked into archives but was unable to find clear guidance that wasn’t discussed at length to be out of date / disputed so I am primarily looking for what the current best practice is so I can take advantage of the best advise for rolling out the deployment (I know we are late to this party but better late than never) Regards Alexander Alexander Neilson Neilson Productions Limited alexander(a)neilson.net.nz 021 329 681 022 456 2326

7 13

Re: [nznog] Whole of Domain Web Harvest 2015
by emma h 24 Dec '14

24 Dec '14

for those wishing to block, the apache rewrite rule is; RewriteEngine on RewriteRule ^(.*)$ http:/your.domain.co.nz [R=301,L] RewriteCond %{HTTP_USER_AGENT} ^(.*)NLNZ_IAHarvester2015(.*)$ RewriteRule ^(.*)$ http://tinyurl.com/NLNZ-IAHarvester2015 merry festivus. -- em

2 1

AUI 10BaseT transceiver
by Gareth Fletcher 24 Dec '14

24 Dec '14

Hi team Is anyone near Auckland CBD/Ponsonby and have one of these they'd be willing to part with this afternoon/next week? We seem to have trashed all ours years ago... Please reply off-list, with beer of choice of course :) Cheers! Gareth

1 0

Whole of Domain Web Harvest 2015
by Jay Gattuso 23 Dec '14

23 Dec '14

Hi NZNoggers, I write to let you know of our intent to commence the next NZ Whole of Domain web harvest on the 12th of Jan 2015. The crawl will take approximately 3 weeks to complete. We will be following the same model as previous years, with the Internet Archive acting on our behalf to undertake the crawl. We will be adhering to robots.txt in the main, however when content blocked by robots.txt is embedded in a page that’s not blocked by robots.txt we will attempt to capture that content. The metadata the crawler will be using is:- metadata.userAgentTemplate=Mozilla/5.0 (compatible; NLNZ_IAHarvester2015 +(a)OPERATOR_CONTACT_URL@) metadata.operatorContactUrl=https://natlib.govt.nz/publishers-and-authors/web-harvesting/domain-harvest The contact URL gives some information that describes why we are doing this, and what we’re doing. If you have any questions or concerns, please drop me a line – I’ll be monitoring this email address over the Xmas period. 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>

1 0

Fwd: Estonian IPv6 deployment report
by Brian E Carpenter 23 Dec '14

23 Dec '14

An example from far away... -------- Original Message -------- Subject: Estonian IPv6 deployment report Date: Mon, 22 Dec 2014 17:27:23 +0200 From: Tarko Tikan <tarko(a)lanparty.ee> To: IPv6 Ops list <ipv6-ops(a)lists.cluenet.de> hey, Some time ago, many people noticed rapid IPv6 deployment growth in Estonia (from 0% to 5% in 4 weeks). We at 3249/Elion/Estonian Telecom were behind this, other operators don't have any serious IPv6 deployments at the moment. We rolled out v6 to everyone (both business and residential customers) with last-gen CPE, there was no hop-in our hop-out program - aim was to do it perfectly and without customers even noticing. I'm happy to say that we achieved this goal :) To satisfy general interest, I promised small (somehow it turned out longer than I expected) technical writeup how we enabled v6 for our subscribers. If you have any other questions, feel free to ask and I do my best to answer them. You can also skip the technical content and there are some statistics below. Our access network is mix of DSL/GPON/wimax/p2p-ETH and broadband service is deployed in shared service vlans. IPv6 traffic shares vlan with IPv4. Service vlans are transported over MPLS metro network using pseudowires and terminated in geo-clustered Alcatel 7750 BNG routers. Each subscriber is allocated up to 4 mixed v4 and v6 IP hosts. For v4 we are using the usual DHCP, for IPv6 we are using DHCPv6 with IA_PD only, no IA_NA is provided. Unfortunately DHCPv6 provides no way to signal IPv6 default-route thus we have to fall back to RA for default-route. RA does not include any on-link prefixes or DNS information. RAs are L2 unicasted to CPE MAC so no other CPE in service vlan picks up those RAs. To ensure rapid switchover between BNG routers, we are signalling virtual link-local address as default-route. We are using ALU internal DHCP/DHCPv6 servers to allocate leases but we also signal IP information from radius (in such case BNG "fakes" DHCP server) for static IP customers. Provided IPv6 prefix is always /56 and we keep the old lease for 24h even if the CPE is turned off (actual lease time is 30min). Unfortunately, IPv6 LDRA is not available on most of our access platforms so we have to rely on IPv4 session information for authentication. This linking is done in the radius server during subscriber authentication (excellent radiator + quite awful SQL queries :) - if subscriber has IPv4 session (that has been authenticated using DHCP opt82), same MAC address is allowed to have IPv6 session on exactly the same virtual BNG port. IPv4 and v6 session are both tied to same subscriber and share shapers, QOS etc. We were able to enable IPv6 only on our last-gen Inteno CPEs. They run modified OpenWrt and because it's linux - everything is possible :) In CPE, /56 is divided up to /64s, first one is currently reserved but we will configure it on loopback interface and use it for CPE management. Second /64 is configured on LAN and third is configured on public wifi SSID (if you choose to enable this option). In the LAN, IPv6 config is provided by RAs, we also support RDNSS and stateless DHCPv6 for DNS. There is also ingress IPv6 firewall in the CPE and configuration is modifiable by user. To make deployment as smooth as possible, we rolled out IPv6 capable CPE software first. Then, during the BNG platform refresh, we deployed L2 ACLs that dropped all IPv6 traffic based on 0x86dd ethertype. We then deployed IPv6 config to all BNGs and could verify everything before single v6 lease was handed out to the subscribers. Then, interface by interface, we replaced L2 ACL with one that only allowed 0x86dd for certain, supported, OUIs. This is the current situation and we are investigating ways to support 3rd party CPEs - main problem is unreliable IPv6 config in CPEs. Many don't enable DHCPv6 (or enable NA but no PD) but still pick up default-route from RA and happily signal it to LAN. Some others hammer our BNGs with NA request every 0.1 seconds etc. As statistics go, there are 30000+ active IPv6 subscribers (almost 15% of our customer base, based on our public numbers), 81% of them have have at least one IPv6 enabled device in the LAN, 70% have more than one. Most IPv6 traffic is generated by Google+Youtube, Facebook and Akamai. Not bad for a country with 1.3M people. Next up: mobile network :) -- tarko

2 1

Primary access method
by Brian E Carpenter 21 Dec '14

21 Dec '14

Hi, In answer to a ticket entitled "Not getting an IPv6 prefix today", here is what the help desk told me: > Currently XXX have IPv6 services turned off due to some ongoing investigations > with this service. > > Once this is turned back on you will be able to get an IPv6 address again. and in response to my follow-up bleat > As IPv6 is not the Primary access method we offer on our connections this does > not need to be updated on the network status page. > > IPv6 is not a fully released product therefore it is still going through testing > and this is why we are currently unable to apply static IPv6 address (I didn't ask about a static address and don't want one.) This morning, I still have no IPv6 service and the XXX status page still says "OK - No Known Network Problems". Now, since I've had stable IPv6 service for a long time and it often gives me better response times than IPv4, I was a bit annoyed by this. Isn't it time that people consider IPv6 to be the primary access method, and IPv4 to be a legacy solution? Grumble. I need to fire up SixXs again, then. Brian

9 14