Some of you may not have noticed this in the post-Christmas doze ...
What will happen is that on 30th June [UTC time] the clock will go 23:59:59 > 23:59:60 > 00:00:00, instead of 23:59:59 > 00:00:00, i.e. an extra 'leap' second is inserted.
It will cause the odd issue or two, depending on your environment and operating system..
For example, if you should happen to use RHEL you could start here https://access.redhat.com/articles/15145
There were certainly issues in other Linux distributions (including Oracle Linux and SLES) last time this happened on 30th June / 1st July 2012.
This year will be slightly longer after the Paris Observatory announced that it was adding a "leap second" at midnight [UTC] on June 30
Note: Midnight [UTC] on June 30 2015 is Noon, Wednesday, 1 July 2015 NZ Standard Time
INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS)
SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE ET DES SYSTEMES DE REFERENCE SERVICE DE LA ROTATION TERRESTRE DE L'IERS OBSERVATOIRE DE PARIS
61, Av. de l'Observatoire 75014 PARIS (France)
Tel. : 33 (0) 1 40 51 22 26
FAX : 33 (0) 1 40 51 22 91
e-mail : services.iers(a)obspm.fr<mailto:email@example.com>
Paris, 5 January 2015 Bulletin C 49
To authorities responsible for the measurement and distribution of time UTC
TIME STEP on the 1st of July 2015
A positive leap second will be introduced at the end of June 2015. The sequence of dates of the UTC second markers will be: 2015 June 30, 23h 59m 59s 2015 June 30, 23h 59m 60s 2015 July 1, 0h 0m 0s
The difference between UTC and the International Atomic Time TAI is: from 2012 July 1, 0h UTC, to 2015 July 1 0h UTC : UTC-TAI = - 35s from 2015 July 1, 0h UTC, until further notice : UTC-TAI = - 36s
Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI.
Bulletin C is mailed every six months, either to announce a time step in UTC or to confirm that there will be no time step at the next possible date.
Earth Orientation Center of IERS Observatoire de Paris, France
The information contained in this Internet Email message is intended
for the addressee only and may contain privileged information, but not
necessarily the official views or opinions of the New Zealand Defence Force.
If you are not the intended recipient you must not use, disclose, copy or
distribute this message or the information in it.
If you have received this message in error, please Email or telephone
the sender immediately.
APNIC is offering free, individual Hostmaster consultation sessions at
the NZNOG Conference. These will be available on Wednesday Jan 28.
At these sessions you can ask about:
- How to request IPv4, IPv6, and AS numbers from APNIC
- How to transfer IPv4 addresses and AS numbers
- Current policies for IP and AS number management in the APNIC
- How to maintain and update your resource registration record
in the APNIC Whois Database
- Any individual issues you might have
To register for the Hostmaster consultations, please email:
Heads up that ~700 new prefixes just appeared then vanished from WIX route
reflector 2. This momentarily pushed the route totals up over 2000 which
may have reset a few BGP sessions for anyone limiting their received
prefixes to 2000 on that session.
I'm giving a tutorial on "analysing network traces with python" at
NZNOG 2015. The tutorial will cover how to use my python-libtrace
module, with lots of example python programs.
However, the examples I can think up easily are mostly trivial.
It would help me a lot to know what kinds of trace analysis ISPs
would actually find useful! If/when you collect packet traces,
what kinds of information or analysis would you like to get from them?
Any suggestions would be much appreciated - please email me off-list,
Nevil Brownlee Computer Science Department
Phone: +64 9 373 7599 x88941 The University of Auckland
FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand
(Apologies if you've seen this notification from the mailop list already. )
See the post below re: the AHBL RBL wildcarding certain zones today.
There are NZ ASs in the latest CSV lists in the link below (Vodafone NZ,
ICONZ, HD & NZ Wireless), this change may affect mail flows.
-------- Original Message --------
Subject: Re: [mailop] Wildcarding of AHBL public DNSbl lists on Jan 1st
Date: Fri, 26 Dec 2014 16:26:34 -0700
From: Brielle Bruns <bruns(a)2mbit.com>
On 12/26/14 4:00 PM, Frank Bulk (iname.com) wrote:
> Thanks, that's helpful.
> I'm not sure how many IPs you have, but Cymru's service might be an option:
> I found some other options:
>http://dev.maxmind.com/geoip/legacy/geolite/ (usage described here:
Thanks. I threw together a shell script that handles the conversion for
me based on the geoiplookup tool and the output is going here:
I have to generate the lists manually for now, but it should help those
looking to figure out who on their network is doing queries.
The Summit Open Source Development Group
mailop mailing list
This email has been filtered by SMX. For more info visit http://smxemail.com
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)
Neilson Productions Limited
021 329 681
022 456 2326