NTP Reach : 0, 377 et tout entre les deux
Décoder le registre reach 8 bits sur chrony et ntpd
1. Reach est un registre à décalage, pas un compteur
Fréquemment mal lue comme un score de 0 à 8, la colonne reach de ntpq -p est en réalité la valeur décimale d'un registre à décalage circulaire 8 bits, affichée en octal. RFC 5905 l'appelle le reachability register.
À chaque poll :
- Le registre est décalé d'un bit vers la gauche.
- Une réponse réussie écrit 1 dans le bit le moins significatif ; un poll manqué écrit 0.
- Le bit sorti de la position la plus significative est jeté — le registre ne retient que les 8 derniers polls.
Comme il est affiché en octal, la valeur maximale est 377 octal = 11111111 binaire = 255 décimal = les 8 polls ont réussi.
2. Table de décodage valeur par valeur
| Reach (oct) | Binaire (MSB→LSB) | Signification |
|---|---|---|
| 0 | 00000000 | 8/8 ratés — peer injoignable |
| 1 | 00000001 | Dernier poll réussi, les 7 précédents ratés — premier contact |
| 3 | 00000011 | 2 derniers polls OK, 6 précédents ratés |
| 7 | 00000111 | 3 derniers polls OK |
| 17 | 00001111 | 4 derniers polls OK — en récupération |
| 37 | 00011111 | 5 derniers polls OK |
| 77 | 00111111 | 6 derniers polls OK |
| 177 | 01111111 | 7 derniers polls OK |
| 200 | 10000000 | Seul le plus ancien poll a réussi — peer en alerte |
| 376 | 11111110 | 7 OK, dernier poll manqué — glitch récent |
| 377 | 11111111 | Les 8 OK — sain |
3. Cycle de vie : 0 → 1 → 17 → 377
Un peer arrive à reach 0. Après le premier poll réussi il passe à 1, puis 3, 7, 17, 37, 77, 177, 377 — si chaque poll suivant réussit. À minpoll 6 par défaut (intervalle 64 s), le chemin du premier contact à reach 377 complet prend 8 polls × 64 s = 512 secondes (8,5 min).
La directive iburst change cela : au premier poll, 8 paquets sont envoyés coup sur coup à ~2 s d'intervalle. Reach 377 est atteint en environ 16 secondes au lieu de 8,5 minutes.
# /etc/chrony/chrony.conf
pool 2.pool.ntp.org iburst
server ntp.rdem-systems.com iburst nts
# /etc/ntp.conf
server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst4. Diagnostiquer une chute de 377 à 0
Un peer stable à 377 qui chute soudainement à 0 sur 8 polls (~8,5 min) a perdu sa joignabilité. Quatre causes typiques :
4.1 Timeout de table d'état du pare-feu
Les pare-feux à état suivent les « connexions » UDP (conntrack sous Linux). Le timeout UDP par défaut est 30 s sur beaucoup de distributions — plus court que l'intervalle de poll NTP par défaut de 64 s. Résultat : un paquet sur deux est droppé.
# Vérifier le timeout actuel (Linux)
$ cat /proc/sys/net/netfilter/nf_conntrack_udp_timeout
30
# Monter à 300 s pour survivre à la cadence NTP
$ sudo sysctl -w net.netfilter.nf_conntrack_udp_timeout=3004.2 Peer amont hors ligne
Vérifiez depuis l'extérieur : dig +short ntp.rdem-systems.com, puis ntpdate -q <ip> depuis un autre ASN. Si les deux échouent, le peer est hors ligne et il vous faut une source alternative.
4.3 Changement BGP / routage
Une nouvelle annonce de préfixe, un RPKI invalide ou un flap de route FAI peuvent rendre un amont spécifique injoignable alors que le reste d'Internet fonctionne. traceroute et mtr révéleront où le chemin casse.
4.4 Problème local NIC ou kernel
Vérifiez les compteurs de l'interface pour les paquets droppés : ip -s link show et ss -s. Sur VM, un vSwitch bruyant-voisin peut dropper des bursts UDP — corrèle habituellement avec des pics d'autres services UDP sur le même hôte.
Les quatre causes ci-dessus ont un point commun : elles sont transitoires et peuvent rejouer à 3h du matin sur un serveur NTP hébergé chez OVH, Scaleway ou un autre opérateur français, sans qu'aucun monitoring local ne les voie passer. Externaliser cette supervision NTP/NTS en astreinte 24/7 — surveillance continue du registre reach, de l'offset et du statut NTS de chaque peer — est typiquement le rôle de l'infogérance serveur RDEM.
5. Confirmer le flux de paquets avec tcpdump
Quand le diagnostic GUI-level atteint sa limite, descendez sur le câble :
# Capture du trafic NTP pendant 3 minutes
$ sudo tcpdump -nn -i any udp port 123 -w /tmp/ntp.pcap &
$ sleep 180 && sudo kill %1
$ tcpdump -nn -r /tmp/ntp.pcap | head -40Attendu : une requête toutes les 64 s (ou selon config) depuis le port éphémère du client vers le 123 du peer, plus une réponse. Si vous ne voyez que des paquets sortants, le chemin retour est cassé. Si vous ne voyez rien du tout, le démon n'émet pas (vérifier qu'il tourne).
6. Équivalent chronyc
chrony n'affiche pas le registre octal, mais chronyc sources -v montre le champ « Reachability register (octal) » quand lancé avec -v :
$ chronyc sources -v
MS Name/IP address Stratum Poll Reach LastRx Last sample
=======================================================================
^+ ntp.rdem-systems.com 1 6 377 18 -0.234ms ...
^* time.cloudflare.com 3 6 377 42 +0.512ms ...
^? ntp1.ptb.de 1 6 037 205 +1.120ms ...Ici, ntp1.ptb.de est à 037 octal = 31 décimal = 5 derniers polls sur 8 OK — en récupération, pas encore de confiance.
Après correction — sites liés :
- Mesurer jitter, offset, latence → ntp-tester.eu
- Preuves d'audit NIS 2 / ISO 27001 → online-ntp-validator.com
- Architecture de référence entreprise → ntp.rdem-systems.com