Re: [Ntp] Antw: Re: Antw: [EXT] NTPv5 Loop Detection without Stratum

[David Venhoek <[e-mail]>]

On Tue, Aug 30, 2022 at 3:22 PM Ulrich Windl
<[e-mail]> wrote:
>
> >>> Danny Mayer <[e-mail]> schrieb am 30.08.2022 um 00:37 in
> Nachricht <[e-mail]>:
>
> > On 8/24/22 1:54 AM, Ulrich Windl wrote:
> >>>>> Heiko Gerstung <[e-mail]> schrieb am 23.08.2022 um 12:21
> >> in
> >> Nachricht <[e-mail]>:
> >>> One way of avoiding/detecting loops:
> >>> - upon startup, an NTPv5 instance creates a random 64bit ID
> >>> - we add a loop detection EF that can include n IDs (or we use n EFs)
> >>> - a stratum one server, when ask for his "sync trace", responds with only
> >>> his ID
> >> Considering that a stratum-1 server may have more than one reference clock
> >> (say m) to pick, I think a stratum-1 server should actually prepare one ID
> > per
> >> reference clock. It's a design issue whether to return one ID that is
> > different
> >> for each clock (see below), or two IDs (server's + clock's).
> >
> > No need. When it's a stratum-1 server the referenceID in the packet
> > indicates the clock being used. See RFC5905 Figure 12.
>
> But if the Reference ID for all GPS clocks would be "GPS ", wouldn't he new "loop avoidance" algorithm consider all those to be the same source, thus a loop? So we could not have redundant GPS sources any more???
>
> Regards,
> Ulrich
> ...

No, the loop avoidance algorithm only rejects a source if that source
depends on the node itself. So, when having 4 servers A B C and D, if
server A is a stratum 1 server, and servers B and C sync to server A,
server D can still use all of A,B and C to synchronize. However,
suppose it uses all 3, then at that point, it will no longer be
accepted as a potential time source by node B or C, because these then
see they were part of the source of D, and therefore reject.

Kind regards,
David Venhoek


>
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp