July 2015 - 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

SDN APE, and IX stats from Citylink
by Tim Hoffman 04 Sep '15

04 Sep '15

Greetings, There was some discussion over the last couple of years with the NZNOG community at conferences and on the mailing list about Citylink doing a SDN based IX. This was to include with it Citylink releasing statistics of the aggregated traffic over their IX - a measure (published by most IXs) that many use to decide if it's worth connecting to an IX. Given the public nature of this discussion so far, and the fact that it's died off, can a representative of Citylink please confirm to the list; 1/ Is there an intention to move to some sort of SDN driven IX still, and if so what the timeframe for this will be? If this project has been abandoned, how will the IXs be developed in place of this project? 2/ Do they have any intention to publish an aggregated traffic on their IXs, and if so what the timeframe for this will be? I am sure many of us in the peering community will be eager to hear the answers to these questions.... Cheers, Hoff

12 21

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

Chorus EUBA + IPV6
by Simon Allard 03 Aug '15

03 Aug '15

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

5 5

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

02 Aug '15

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

2 3

gnodal switches
by Rob McDonald 29 Jul '15

29 Jul '15

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

1 0

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

28 Jul '15

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

1 0

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

27 Jul '15

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

1 0