EN FR Accueil

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 :

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
0000000008/8 ratés — peer injoignable
100000001Dernier poll réussi, les 7 précédents ratés — premier contact
3000000112 derniers polls OK, 6 précédents ratés
7000001113 derniers polls OK
17000011114 derniers polls OK — en récupération
37000111115 derniers polls OK
77001111116 derniers polls OK
177011111117 derniers polls OK
20010000000Seul le plus ancien poll a réussi — peer en alerte
376111111107 OK, dernier poll manqué — glitch récent
37711111111Les 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 iburst
Règle de production. Activez iburst sur chaque peer. Le seul inconvénient est 8 paquets au démarrage — négligeable contre le bénéfice d'éviter stratum 16 pendant 8 minutes après boot.

4. 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=300

4.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.

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 -40

Attendu : 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.

Étapes suivantes. Une fois chaque peer stable à 377, votre diagnostic reach est terminé. Si la sélection d'horloge rejette toujours les sources, la page false ticker explique l'algorithme de sélection. Si vous êtes toujours en stratum 16 malgré une bonne reach, le problème est le seuil panic ou un désaccord majoritaire.

Après correction — sites liés :