1 votes

ananTgarg avatar

Le serveur NTP préféré a été rejeté malgré un meilleur décalage et une meilleure gigue.

Demandé el 3 de Avril, 2018
Quand la question a-t-elle été
1042 affichage
Nombre de visites la question a
1 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

Nous avons configuré un client NTP sur l'un de nos systèmes. Le client dispose d'un ensemble de serveurs avec lesquels il peut se synchroniser.

Cependant, le serveur préféré que nous avons choisi est notre serveur maître interne avec l'IP 169.254.1.51.

Le contenu de ntp.conf est le suivant :-

    # --- CLIENT NETWORK -------
    # --- USER SETTINGS BEGIN ---

    server 10.241.34.2 iburst

    server 10.241.34.3 iburst

    server 10.241.34.4 iburst
    restrict 10.241.34.2  mask 255.255.255.255 nomodify notrap noquery
    restrict 10.241.34.3  mask 255.255.255.255 nomodify notrap noquery
    restrict 10.241.34.4  mask 255.255.255.255 nomodify notrap noquery
    # --- USER SETTINGS END ---

    # --- NTP MULTICASTCLIENT ---
    restrict 169.254.0.0 mask 255.255.0.0 nomodify notrap  # internal network
    # --- INTERNAL TIMESERVERS BEGIN-----
    server 169.254.1.51 burst iburst minpoll 4 maxpoll 6 prefer #Internal master Server

    # --- GENERAL CONFIGURATION ---
    server  127.127.1.0 iburst minpoll 4    # local clock
    fudge   127.127.1.0 stratum 10
    tinker step 0

Ce qui précède concerne la partie configuration. Cependant, lorsque nous vérifions le syslog après la configuration et le redémarrage du système, nous constatons que le client se synchronise avec le serveur externe au lieu du serveur préféré, comme le montre la sortie ntpq dans le syslog.

    Mar 22 05:52:48 Node ntpcheck:      remote           refid      st t when poll reach   delay   offset  jitter
    Mar 22 05:52:48 Node ntpcheck: ==============================================================================
    Mar 22 05:52:48 Node ntpcheck: \*10.241.34.2     10.240.33.1      4 u    2   64    1    0.192  -519.50   5.769
    Mar 22 05:52:48 Node ntpcheck:  10.241.34.3     10.241.34.2      5 u    1   64    1    0.172  -523.79   8.912
    Mar 22 05:52:48 Node ntpcheck:  10.241.34.4     10.241.34.2      5 u    2   64    1    0.207  -520.73   8.082
    Mar 22 05:52:48 Node ntpcheck:  169.254.1.51    LOCAL(0)        11 u    1   16    1    0.113   -0.043   2.099
    Mar 22 05:52:48 Node ntpcheck:  127.127.1.0     .LOCL.          10 l   14   16    1    0.000    0.000   0.001}

En outre, le message ci-dessous a été continuellement inondé dans syslog

    Mar 22 06:51:11 Node ntpd\[31292\]: synchronized to LOCAL(0), stratum 10
    Mar 22 06:51:27 Node ntpd\[31292\]: synchronized to 10.241.34.2, stratum 4
    Mar 22 06:51:45 Node ntpd\[31292\]: synchronized to LOCAL(0), stratum 10
    Mar 22 06:52:03 Node ntpd\[31292\]: synchronized to 10.241.34.2, stratum 4
    Mar 22 06:52:20 Node ntpd\[31292\]: synchronized to LOCAL(0), stratum 10
    Mar 22 06:52:35 Node ntpd\[31292\]: synchronized to 10.241.34.2, stratum 4
    Mar 22 06:52:51 Node ntpd\[31292\]: synchronized to LOCAL(0), stratum 10
    Mar 22 06:53:06 Node ntpd\[31292\]: synchronized to 10.241.34.2, stratum 4
    Mar 22 06:53:20 Node ntpd\[31292\]: synchronized to LOCAL(0), stratum 10
    Mar 22 06:53:23 Node ntpd\[31292\]: synchronized to 10.241.34.2, stratum 4
    Mar 22 06:53:38 Node ntpd\[31292\]: synchronized to LOCAL(0), stratum 10
    Mar 22 06:53:53 Node ntpd\[31292\]: synchronized to 10.241.34.2, stratum 4
    Mar 22 06:54:11 Node ntpd\[31292\]: synchronized to LOCAL(0), stratum 10
    Mar 22 06:54:29 Node ntpd\[31292\]: synchronized to 10.241.34.2, stratum 4
    Mar 22 06:54:47 Node ntpd\[31292\]: synchronized to LOCAL(0), stratum 10
    Mar 22 06:55:02 Node ntpd\[31292\]: synchronized to 10.241.34.2, stratum 4
    Mar 22 06:55:20 Node ntpd\[31292\]: synchronized to LOCAL(0), stratum 10
    Mar 22 06:55:21 Node ntpd\[31292\]: synchronized to 10.241.34.2, stratum 4
    Mar 22 06:55:35 Node ntpd\[31292\]: synchronized to LOCAL(0), stratum 10
    Mar 22 06:55:53 Node ntpd\[31292\]: synchronized to 10.241.34.2, stratum 4
    Mar 22 06:56:10 Node ntpd\[31292\]: synchronized to LOCAL(0), stratum 10
    Mar 22 06:56:28 Node ntpd\[31292\]: synchronized to 10.241.34.2, stratum 4
    Mar 22 06:56:46 Node ntpd\[31292\]: synchronized to LOCAL(0), stratum 10
    Mar 22 06:57:03 Node ntpd\[31292\]: synchronized to 10.241.34.2, stratum 4
    Mar 22 06:57:21 Node ntpd\[31292\]: synchronized to LOCAL(0), stratum 10
    Mar 22 06:57:38 Node ntpd\[31292\]: synchronized to 10.241.34.2, stratum 4
    Mar 22 06:57:54 Node ntpd\[31292\]: synchronized to LOCAL(0), stratum 10
    Mar 22 06:58:09 Node ntpd\[31292\]: synchronized to 10.241.34.2, stratum 4
    Mar 22 06:58:24 Node ntpd\[31292\]: synchronized to LOCAL(0), stratum 10
    Mar 22 06:58:42 Node ntpd\[31292\]: synchronized to 10.241.34.2, stratum 4
    Mar 22 06:58:59 Node ntpd\[31292\]: synchronized to LOCAL(0), stratum 10
    Mar 22 06:59:15 Node ntpd\[31292\]: synchronized to 10.241.34.2, stratum 4
    Mar 22 06:59:30 Node ntpd\[31292\]: synchronized to LOCAL(0), stratum 10
    Mar 22 06:59:46 Node ntpd\[31292\]: synchronized to 10.241.34.2, stratum 4
    Mar 22 07:00:02 Node ntpd\[31292\]: synchronized to LOCAL(0), stratum 10
    Mar 22 07:00:17 Node ntpd\[31292\]: synchronized to 10.241.34.2, stratum 4

Nous avons essayé de vérifier sur les forums NTP et avons identifié qu'il utilise le paramètre ci-dessous pour définir le serveur avec lequel il faut préférer se synchroniser (Référence:- https://www.eecis.udel.edu/~mills/ntp/html/warp.html ) :-

  • Le premier niveau de rejet est basé sur le décalage et le retard.
  • Ensuite, après avoir rejeté le pool, les survivants sont passés à l'algorithme de clustering d'horloge.
  • L'algorithme de clustering dépend de la gigue pour décider.
  • Les autres serveurs sont des survivants sélectionnables, n'importe lequel d'entre eux peut être choisi.
  • Maintenant le rôle du mot-clé préférer entre en jeu, et tous les sélectionnables sont cochés et le préférer est choisi.
  • Si le survivant n'est pas présent, alors la règle de migration décide du pair.

Cependant, dans la sortie ntpq, le serveur préféré présente un meilleur décalage et une meilleure gigue, mais il n'est pas choisi.

Est-il possible d'identifier sur quelle base le serveur préféré est rejeté dans ce cas ?

EDIT -1

Nous avons en outre trouvé le syslog pour mentionner le choix de 169.254.1.51 malgré une strate plus élevée comme ci-dessous :-

 `Mar 24 05:01:01 Node ntpq: ==============================================================================
Mar 24 05:01:01 Node ntpq: +10.241.34.2     10.240.33.1      4 u  693 1024  377    0.242  -251.08  10.473
Mar 24 05:01:01 Node ntpq: +10.241.34.3     10.241.34.2      5 u   46   64  377    6.675  -255.20   0.326
Mar 24 05:01:01 Node ntpq: +10.241.34.4     10.241.34.2      5 u  245 1024  377    0.312  -264.63   7.708
Mar 24 05:01:01 Node ntpq: *169.254.1.51          LOCAL(0)        11 u   12   64  377    0.143   80.034   2.248
Mar 24 05:01:01 Node ntpq:  LOCAL(0)        .LOCL.          10 l   10   16  377    0.000    0.000   0.001`
Demandé el 3 de Avril, 2018 par ananTgarg

Réponse

Trop de publicités?

1voto

Att Righ avatar
Att Righ Points 356

Regardez de cette façon : Vous avez quatre serveurs :

  1. 10.241.34.2
  2. 10.241.34.3
  3. 10.241.34.4
  4. 169.254.1.51

Les numéros deux et trois reçoivent leur temps du numéro un. Mais ils sont à peu près dans la strate inférieure, avec les numéros 4 et 5. C'est ce que j'attendais d'un serveur NTP interne. Ils rapportent des temps assez proches, avec des décalages similaires à votre horloge locale, et leurs différences sont dans la limite de la gigue.

En outre, vous avez 169.254.1.51, qui est la strate 11. La strate indique à quel point vous êtes éloigné de la source de temps (strate 0). La strate 1 est connectée à la source de temps, par exemple un GPS ou une horloge atomique. La strate 2 est connectée à la strate 1 et ainsi de suite. Vous avez trois (en réalité un seul, car les n° 2 et 3 font référence au n° 1) serveurs qui disent : "Faites-moi confiance, je suis à quatre pas de la source de temps". Ils sont d'accord sur l'heure.

Puis vous en avez un, qui est à une demi-seconde de ces trois-là, et qui dit que c'est onze pas d'une horloge fiable. Bien entendu, NTP doit faire confiance aux serveurs NTP de strate inférieure.

De plus, vous modifiez l'horloge locale pour la strate 10. En fait, vous dites que vous faites confiance à l'horloge locale más que votre serveur NTP préféré. Cela ne fonctionnera pas. La configuration ici est totalement insensée. En bref. NTP est hiérarchique et doit être traité comme tel.

  1. Synchronisez votre 169.254.1.51 avec un pool externe. Les pools sont généralement de strate 2-3, donc il se retrouvera en strate 3-4. C'est largement suffisant pour la plupart des besoins.
  2. Configurez trois serveurs NTP ou plus, chacun recevant l'heure d'un des pools. Vous pouvez les mettre en relation les uns avec les autres, mais sans que les serveurs 2 et 3 reçoivent l'heure du serveur 1.
  3. Faites en sorte que vos clients utilisent les trois serveurs NTP que vous avez configurés.
  4. Si vous ne pouvez pas avoir trois serveurs NTP, configurez-en un ou utilisez directement les pools. Les pools gèreront la charge à moins que vous n'ayez un très grand nombre (des milliers) de clients.
  5. Ne pas truquer l'horloge locale en strate 10 - si elle n'est pas synchronisée, il ne faut pas lui faire confiance. Si vous souhaitez une synchronisation de l'heure lorsqu'aucune source en amont n'est disponible pendant un certain temps, définissez l'option un de l'horloge locale des serveurs à la strate dix. Cela en fera le maître si aucune remontée n'est disponible.
  6. Deux sources de temps est pire qu'une. Si vous en avez une, vous la suivez. Si vous en avez deux, et qu'elles sont en désaccord, vous ne savez pas laquelle suivre. Si vous en avez trois, et que deux sont d'accord, vous savez laquelle suivre. Une autre alternative consiste à le définir comme truechimer en ajoutant true à la ligne du serveur.

Documentation NTP contient quelques conseils sur la configuration de NTP. Vous devriez probablement le lire.

De plus, en utilisant 169.254.x.x dans un réseau est une pratique étrange . Je vous recommanderais de ré-IPer ce réseau pour utiliser une adresse sane RFC1918-space . 169.254.0.0/16 est conçu comme un réseau local automatique et ne devrait probablement pas être utilisé de cette manière.

Répondu el 3 de Avril, 2018 par Att Righ (356 Points )

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X