Quando o broadcast / broadcastclient do NTPd deve ser usado em vez dos modos cliente / servidor ou peer?

Question

O NTP deamon, se usado frequentemente em seu modo mais simples, que é cliente / servidor: você especifica uma ou mais diretivas server em seu ntp.conf e seus clientes usarão esses servidores.

Além disso, quando você executa seus próprios servidores NTP, é uma boa prática juntá-los, então, se um deles perder conectividade com seus servidores upstream, ele terá tempo de seus colegas.

Mas o NTPd também pode trabalhar com distribuição de difusão e / ou multicast de dados de tempo, com a documentação informando:

broadcast and multicast modes are intended for configurations involving one or a few servers and a possibly very large client population

A documentação também diz outro lugar :

It is possible and frequently useful to configure a host as both broadcast client and broadcast server. A number of hosts configured this way and sharing a common broadcast address will automatically organize themselves in an optimum configuration based on stratum and synchronization distance.

Eu posso ver um óbvio benefício administrativo: você não precisa especificar e atualizar manualmente sua lista de servidores NTP nos clientes peer , então para mim parece tentador usar o modo broadcast mesmo para uma pequena população de clientes ( digamos 5+ clientes com 3 ~ 4 servidores). Espero que o tráfego de rede seja um pouco maior com transmissões em vez de associações cliente / servidor, mas, dada a LAN ethernet gigabit usual, o impacto deve ser insignificante, a menos que você tenha um número muito grande de hosts no mesmo domínio de transmissão.

No final do dia, quando o modo de transmissão deve ser usado ou evitado? Existem prós e contras que eu não vi?

    

Answer 1

Não, o modo de cliente de transmissão não é suportado na maioria dos sistemas operacionais. Os modos broadcast e multicast são inerentemente menos precisos e menos seguros (mesmo com autenticação) do que o modo servidor / cliente comum e não são tão úteis quanto costumavam ser.

Se você é inflexível sobre isso, você pode soldado em ...

Linux OS suporta broadcast / manycast / multicast, mas impõe uma sobrecarga de CPU pela virtude de colocar a Ethernet NIC mais antiga e sua interface em modo promíscuo (lendo em todos os pacotes incluindo pacotes destinados a outros hosts).

MacOSX (agora macos ) pode suportar NTP multicast, mas nenhum suporte é dado a ele. Você pode usar o seguinte comando para ativá-lo:

sudo route -nv add -net 228.0.0.4 -interface en0

O serviço de tempo do Microsoft Windows não oferece suporte a multicast / broadcast no Windows 2000 Server, no Windows Server 2016, no Windows Server 2012 R2 e no Windows Server 2012, muito menos em qualquer uma das variantes da área de trabalho do Windows. Usado para oferecer suporte a multicast NTP (K9 de www.mingham-smith.com/k9.htm fornece multicast NTP para Windows 3.1, 95, 98, ME, NT, 2000, XP, 2003, Windows Mobile 2003).

    

Answer 2

Na minha opinião, o broadcast / broadcastclient deve ser sempre evitado.

Eu mesmo examinei essa opção e não encontrei nenhuma maneira adequada de configurar o cliente apenas para aceitar essas transmissões apenas de servidores "oficiais".

E o próximo ponto é: Qual a compatibilidade dessa transmissão com computadores que executam o Windows / MacOS?