[AusNOG] Telstra outage?

Tue Jul 14 18:02:30 AEST 2026

On Tue, 14 Jul 2026 at 17:09, Michael Junek <michael at juneks.com.au> wrote:

> If they have only two devices, that's not enough for redundancy. You need
> a minimum of three. With only two upstream sources, and NTP client cannot
> accurately determine which is the correct time - whereas with 3, you'll
> know that 'one' is wrong.
>

And if one of your 3 fail, you now only have two, and similar to if you
have only two watches on your wrist, you can't tell which one is accurate.

Therefore with 3 as minimum you have a single point of failure.

That's why the BCP says a minimum of four, and ideally it's 5 because you
want an odd number under normal circumstances.

In addition to the https://www.ntppool.org/ NTP time servers make
available, I've found plenty of freely available NTP time sources on the
Internet that are run by highly funded and should able to trusted as a time
sources like Microsoft, Apple, Coudflare, Facebook, as well as many others
run by government agencies and universities over both IPv4 and IPv6.
(Google don't use leap seconds, they smear time, and I understand that's
incompatible with other public NTP time sources.)

Somebody might argue you shouldn't trust time you get off the Internet,
which in some cases would be valid. However, if you have a lot of time
sources from diverse organisations around the world, your local NTP
implementation is inherently measuring them all against each other, which
is therefore inherently building more trust in the time accuracy across
them all.

One case however where I wouldn't use "random" publicly available NTP time
servers is if financial transactions were being timestamped with time
derived from those publicly available NTP time sources. I could see a
lawyer in court arguing that financial transaction timestamps can't be
trusted if the timestamp was sourced from the Internet.

You could use the Australian Government's NMI time servers for financial
transactions.

https://www.industry.gov.au/national-measurement-institute/nmi-services/physical-measurement-services/time-and-frequency-services

> That being said if all the Stratum 1 devices rolled back their
> clocks simultaneously, then all downstream clients would have started to
> assume that as correct time; once their polling intervals came around (~17
> min).
>

> Usually the GPS hardware has the GPS "base week" written in as part of the
> firmware, to calculate the real time when they report their time back. It's
> likely that if the devices were all manufactured at the same time, that
> they would have all died relatively simultaneously.
>

That's probably the case. I was thinking of clock source uptime being a
factor, and with likely different uptimes there may be a lucky opportunity
to stop other clocks having an effect.

So this is really an example of the debt collector coming for the technical
debt of not replacing obsolete equipment.

Regards,
Mark.

>
> ------------------------------
> *From:* AusNOG <ausnog-bounces at lists.ausnog.net> on behalf of Mark Smith <
> markzzzsmith at gmail.com>
> *Sent:* Tuesday, 14 July 2026 15:55
> *Cc:* Ausnog; Greg Price
> *Subject:* Re: [AusNOG] Telstra outage?
>
> Going from the news reports they only had two.
>
> Two services ir devices for redundancy is usually enough.
>
> That's what I thought about NTP, until I read the following BCP.
>
> The ideal minimum number of NTP time sources for a client is *5*, due to
> the way time sources are compared to try to identify the best and most
> accurate one to follow, and then to have redundancy, which comes with
> having an odd number of NTP sources.
>
> RFC8633, "Network Time Protocol Best Current Practices"
> https://datatracker.ietf.org/doc/html/rfc8633
>
>
> Also, don't use VMs as NTP time servers. The underlying virtualisation
> layer can cause the VM's virtual timer interrupt to drift about.
>
> You want a hardware timer interrupt to be driving the OS's clock.
>
> If Telstra had had 5 Stratacom NTP servers, even if they were all old and
> had the 20 years ago time fault, it's possible that due to different power
> on times, the first one that failed and turned time back 20 years would
> have been ignored by the others and clients because it became a bad time
> source, and they may have been lucky enough to have time to mitigate the
> remaining ones failing before it had an impact.
>
>
> Regards,
> Mark.
>
> On Tue, 14 July 2026, 15:30 Luke Thompson, <luke.t at tnc.works> wrote:
>
>> "Telstra had a nation-wide network outage last week that affected
>> emergency services.
>>
>> The outage has been pinned on an obsolete Symmetricom SyncServer S300
>> node, which manages time on the network but resets its 10-bit week counter
>> to zero every 1024 weeks (just under 20 years) in a common and well
>> understood GPS rollover bug that caused the device to reset to 2006.
>>
>> The SyncServer S300 was discontinued in 2016."
>>
>> Cheers,
>>
>> Luke Thompson, CTO
>> The Network Crew P/L
>>
>> E: luke.t at tnc.works
>> https://tnc.works
>>
>> On 9 July 2026 7:21:52 am Greg Price <greg at lakemountain.com> wrote:
>>
>>> The stuff I've read and heard is that it was a software update across
>>> multiple systems that provide the reference sources from GNSS that went
>>> wrong causing the the reference date/time to jump back decades, and the
>>> wheels fall off.  This is from the patchwork of sources, but I'd like to
>>> hear it definitively from engineers.
>>>
>>> On 9 Jul 2026, at 7:12 am, Phillip Grasso <phillip.grasso at gmail.com>
>>> wrote:
>>>
>>> Do you think it was related to software patching breaking time services?
>>> (NTP?)
>>>
>>> On Wed, 8 July 2026, 2:48 pm DaZZa, <dazzagibbs at gmail.com> wrote:
>>>
>>>> To paraphrase an oft-repeated meme
>>>>
>>>> It's not NTP
>>>> There's no way it's NTP
>>>> It was NTP
>>>>
>>>> Bets on this just being a speculator to take the heat off until they
>>>> find out what really went wrong?
>>>>
>>>> D
>>>>
>>>> On Wed, 8 Jul 2026 at 14:34, Luke Thompson <luke.t at tnc.works> wrote:
>>>> >
>>>> > Telstra's CFO has pointed to time / NTP:
>>>> >
>>>> >
>>>> https://www.theguardian.com/australia-news/2026/jul/08/telstra-outage-down-network-mobile-outages-today
>>>> >
>>>> > Seems just over 4 hours of impact, and so far they're unsure what
>>>> caused it.
>>>> >
>>>> > Cheers,
>>>> >
>>>> > Luke Thompson, CTO
>>>> > The Network Crew P/L
>>>> >
>>>> > E: luke.t at tnc.works
>>>> > https://tnc.works
>>>> >
>>>> > On 8 July 2026 8:43:01 am Luke Thompson <luke.t at tnc.works> wrote:
>>>> >
>>>> >> & likewise, service restored at the moment.
>>>> >>
>>>> >> Cheers,
>>>> >>
>>>> >> Luke Thompson, CTO
>>>> >> The Network Crew P/L
>>>> >>
>>>> >> luke.t at tnc.works
>>>> >> https://tnc.works
>>>> >>
>>>> >>
>>>> >> On 8/7/2026 8:40 am, lauricat at fastmail.fm wrote:
>>>> >>>
>>>> >>> Good morning
>>>> >>>
>>>> >>> Back here. Regional Vic  Boost and T prepaid mobile data.
>>>> >>>
>>>> >>> ----- Original message -----
>>>> >>> From: lauricat at fastmail.fm
>>>> >>> To: ausnog at lists.ausnog.net
>>>> >>> Subject: [AusNOG] Telstra outage?
>>>> >>> Date: Wednesday, 8 July 2026 7:44 AM
>>>> >>>
>>>> >>> G'day.
>>>> >>>
>>>> >>> How is T where you are?
>>>> >>>
>>>> >>> Regional Vic Boost network no calls other than emergency can be
>>>> made.
>>>> >>>
>>>> >>> Cheers
>>>> >>> Laurie
>>>> >>>
>>>> >> _______________________________________________
>>>> >> AusNOG mailing list
>>>> >> AusNOG at lists.ausnog.net
>>>> >> https://lists.ausnog.net/mailman/listinfo/ausnog
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > AusNOG mailing list
>>>> > AusNOG at lists.ausnog.net
>>>> > https://lists.ausnog.net/mailman/listinfo/ausnog
>>>> _______________________________________________
>>>> AusNOG mailing list
>>>> AusNOG at lists.ausnog.net
>>>> https://lists.ausnog.net/mailman/listinfo/ausnog
>>>>
>>> _______________________________________________
>>> AusNOG mailing list
>>> AusNOG at lists.ausnog.net
>>> https://lists.ausnog.net/mailman/listinfo/ausnog
>>>
>>>
>>>
>> _______________________________________________
>> AusNOG mailing list
>> AusNOG at lists.ausnog.net
>> https://lists.ausnog.net/mailman/listinfo/ausnog
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ausnog.net/pipermail/ausnog/attachments/20260714/db100cdd/attachment.htm>