Re: Dodgy AS327933 ...?

2023-08-14 Thread Chris Cappuccio
Mark Tinka [mark@tinka.africa] wrote: > > It is not terribly clever of Mikrotik to have two commands that do different > things be that close in syntax. > It should be a huge embarrasment to the designers. They survive on low price and unique features. It would be quite amazing to have a CLI

Re: NTP Sync Issue Across Tata (Europe)

2023-08-14 Thread Forrest Christian (List Account)
I've responded in bits and pieces to this thread and haven't done an excellent job expressing my overall opinion. This is probably because my initial goal was to point out that GPS-transmitted time is no less subject to being attacked than your garden variety NTP-transmitted time. Since this

Re: NTP Sync Issue Across Tata (Europe)

2023-08-14 Thread Masataka Ohta
Mike Hammett wrote: " As such, the ultimate (a little expensive) solution is to have your own Rb clocks locally." Yeah, that's a reasonable course of action for most networks. For most data centers with time sensitive transactions, at least. *sigh*

Re: NTP Sync Issue Across Tata (Europe)

2023-08-14 Thread Mel Beckman
Forrest, I think you’re gilding the lilly. My original recommendation was to use GPS as primary, for its superior accuracy and resistance to attack, and have anti-GPS back up. If you want automatic fail over, do that in an intermediate server on your site that makes a conscious test and

Re: NTP Sync Issue Across Tata (Europe)

2023-08-14 Thread goemon--- via NANOG
On Mon, 14 Aug 2023, Masataka Ohta wrote: Mike Hammett wrote: " As such, the ultimate (a little expensive) solution is to have your own Rb clocks locally." Yeah, that's a reasonable course of action for most networks. For most data centers with time sensitive transactions, at

Re: NTP Sync Issue Across Tata (Europe)

2023-08-14 Thread Forrest Christian (List Account)
We're going to have to somewhat disagree here... I may not have been 100% clear about what I see as the most common risks for GPS. The reason I suggest that NTP risks and GPS risks are similar is not primarily due to intentional time injection hacks (although that is a risk). Instead, it's

Re: NTP Sync Issue Across Tata (Europe)

2023-08-14 Thread Forrest Christian (List Account)
Replying to two posts at once... One can definitely get inexpensive and high-quality rubidiums for dirt cheap on the second-hand market. I've specifically ignored those when discussing price as options as one can never be sure about their accuracy or long-term reliability, and I try to filter

Frontier technical contacts

2023-08-14 Thread Tudisca, Bradley
Hi group! Not sure if this is even allowed but worth a shot; Does anyone/is anyone an engineer with Frontier in Connecticut? I have some questions regarding their FTTH/FTTB products, and their wonderful tier 1 support is useless and has been for the last month of me paying for this service.

Re: NTP Sync Issue Across Tata (Europe)

2023-08-14 Thread James R Cutler
> On Aug 14, 2023, at 3:07 AM, Forrest Christian (List Account) > wrote: > > I've responded in bits and pieces to this thread and haven't done an > excellent job expressing my overall opinion. This is probably because my > initial goal was to point out that GPS-transmitted time is no less

Re: NTP Sync Issue Across Tata (Europe)

2023-08-14 Thread Masataka Ohta
Forrest Christian (List Account) wrote: There are lots of ways to improve a GPS-based NTP server. Better antenna positioning. Better GPS chipset. Paying attention to antenna patterns. Adding notch filters to the GPS feed. And so on. They are not a very meaningful improvement. But, in

Re: NTP Sync Issue Across Tata (Europe)

2023-08-14 Thread Mike Hammett
Forrest seems to have posted a good general overview and perspectives about "good enough for the use case" while others continue to be pedantic about nuances that don't seem to be relevant to most use cases. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com