Nodo secundario de cluster Juniper SRX no conecta con servidor NTP

Me ocurría lo que se comenta en este documento. Al hacer set date ntp, el nodo primario actualizaba correctamente, pero el secundario respondía con «no server suitable for synchronization found». Me logueé en el secundario con request routing-engine login node 1 e intenté hacer ping al servidor NTP configurado, pero no respondía. Probé el router de nuestro ISP y tampoco. Desde el nodo 0 ambas eran visibles. En el documento que he enlazado arriba, aparece una nota:

Note: since the NTP server has to be reachable from the backup RE, you have to use fxp0 interfaces and, in most cases, configure backup-router statement.

En este otro se dice más de lo mismo:

From the node1’s NTP packet path, you can find that the NTP reply packets come to node0’s RE, as node1 uses reth0’s IP as the NTP request’s source address. Node1 will never receive the NTP reply packets. The same result occurs for ICMP and other services. However, for the syslog packet, there is no need to receive reply packets; so It works fine. […] This is by design. When there is no FXP interface, node1 will send packets according to the forwarding-table, which is synced from node0 .So, node1 will use node0’s interface as the source interface to access the server; whether reth or physical interfaces. The solution is to configure node0/node1’s FXP interfaces and backup router.

Por lo visto, desde el nodo secundario parece normal no tener conectividad, y se comenta que para ello hay que configurar la interfaz de mantenimiento fxp0. Sin embargo, hoy me sentía creativo y me acordé de este artículo. En él, se explicaba cómo hacer el failover del grupo de redundancia 1. En uno de los diagramas se veía que el 0 era el correspondiente al plano de control, el Routing Engine (RE). Vi aquí que también era posible hacer el failover con éste, y eso hice:

request chassis cluster failover redundancy-group 0 node 1

Perdí la conexión con SSH. Al reconectar, el prompt mostraba el nodo secundario. Ahora podía hacer ping a cualquier IP, incluída la del servidor NTP. Al hacer set date ntp:

{primary:node1}
admin@ActivaMultimedia_2> set date ntp
node0:
--------------------------------------------------------------------------
25 Sep 15:07:10 ntpdate[8013]: no server suitable for synchronization found

node1:
--------------------------------------------------------------------------
25 Sep 15:07:07 ntpdate[4796]: step time server 81.184.154.182 offset -0.033106 sec

… ocurría justo lo contrario que antes de hacer el failover al nodo 1: ahora el 0 dejaba de funcionar, y el 1 por fin conectaba. Después hice un reset del failover para dejarlo como estaba originalmente:

request chassis cluster failover reset redundancy-group 0 node 0

Si han pasado 5 minutos del período de hold, hay que hacerlo sin el keyword «reset»

request chassis cluster failover redundancy-group 0 node 0

Este procedimiento no es en absoluto el recomendado para conectar con el servidor NTP, porque es un poco peligroso. Además, la sincronización con NTP sólo se efectúa al hacer el failover. Después, el tiempo corre a cargo del reloj del sistema. Como explica la documentación de Juniper, mejor configurar la interfaz fxp0, y hacer periódicamente set date ntp:

In order to keep the time synchronized, periodically run this command automatically, but configure an event-options policy.

Esto era un experimento para aprender. Por otra parte, estaba mirando nuestro servidor FTP y no vi ninguna desconexión, así que también me ha servido para comprobar el correcto funcionamiento de un failover «total», de todos los grupos de redundancia. Me imagino que el corte de la sesión SSH se hizo porque por alguna razón era estrictamente necesario.