NTPがリモートサーバーではなくローカルに同期するのはなぜですか？

そのため、現在のNTPセットアップをデバッグしようとしていますが、単一の構成済みサーバーからのオフセットが3秒を超えており、調整できないことがわかりました。ntpq出力のLOCAL（0）のアスタリスクは、システムが10.130.33.201サーバー（すべてを同期するシステム上の別のlinuxボックス）ではなく、システム自体とうまく同期していることを示しているようです。

ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.130.33.201   LOCAL(0)         9 u   49   64  377    0.242  -3742.2   1.049
*LOCAL(0)        .LOCL.          10 l    2   64  377    0.000    0.000   0.001

そして、これは私のntp.confファイルです。他の誰かによって書かれたので、私はすべてが正しいと100％確信していません。

server 10.130.33.201 burst iburst minpoll 4 maxpoll 11
driftfile /mnt/active/etc/ntp.drift

restrict -4 default  nomodify nopeer notrap
restrict -6 default  ignore

# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available.
server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10

バーストとiburstおよびminpoll / maxpollについて読んだことがあるので、それらは必要ないかもしれないと気づきましたが、それは現在の問題とは関係ないと思います。

また、どのようにデプロイされるかによって、その構成ファイルを変更するには多くの作業が必要になるため、実際に変更する必要のあるものは何もないことを願っています。これがNTPの仕組みを理解していない私の場合であることを願っています。

編集-

だから、これはこの質問の複製のように見えますが、ポスターが十分な答えを得たとは思わないので、ローカル時間がサーバーよりも好まれている理由を知りたいです。また、以下の回答のいずれかに従ってprefer、構成のサーバー行でキーワードを使用して再起動しようとしましたが、それは効果がなかったようです。

他の質問への回答が示唆するように、構成内のすべての「ローカル」行を削除した場合、サーバーに到達できない場合はどうなりますか？NTPは死にますか、それとも試行を続けますか？

重要な編集-

OK、通常、10.130.33.201（「サーバー」）はインターネットにアクセスできず、使用するGPSタイムソースもありません。重要な部分は、システム上のすべてのデバイスがサーバーと同じ時間を持っているということです。その時間が実際にどれだけ正しいかに関係ありません。

そこで、何が起こるかを確認するために、NTPプールサーバーの1つをサーバーの構成ファイルに追加して、ローカルから時間を取得するのではなく、そこから時間を取得するようにしました。NTPタイムサーバーから時刻を正しく取得できるようになりました。

それを行った後、クライアントはLOCAL（0）を優先するのではなく、サーバーと同期するようになりました

 ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*10.130.33.201   38.229.71.1      3 u   58   64  377    0.216  715621.   1.001
 LOCAL(0)        .LOCL.          10 l   18   64  377    0.000    0.000   0.001

新しい質問-私のサーバーがローカル（与えられた元の例）を使用しているとき、クライアントが「ああ、10.130.33.201はLOCAL（0）を使用しています。うーん、私もLOCAL（0）サーバーがあります- -10.130.33.201で同じ情報を取得するのではなく、直接使用します。

そうですか？間違ったLOCAL（0）である「ソースに直接」アクセスしようとしていますか？LOCAL（0）から時間を取得するにはサーバーが必要であり、サーバーから時間を取得するにはクライアントが必要です。現在、クライアントの設定ファイルから「ローカル」サーバーを削除することが唯一のオプションですが、これが発生する理由を理解したいと思います。可能な場合は、設定の変更を避けてください（設定の変更は、私たちの環境...）。

また、これは良い答えのない別の複製のように見えます。

NTPサーバーが1つしか構成されていない場合、アルゴリズムは誰を信頼すべきか完全にはわかりません。たとえリモートホストの方がストラタムが低い場合でも、アルゴリズムはローカル時間がより信頼できると考えています。

preferキーワードをserverステートメントで使用して、それを優先的なタイムソースとして設定してみてください。

編集-

だから、これはこの質問の複製のように見えますが、ポスターが十分な答えを得たとは思わないので、ローカル時間がサーバーよりも好まれている理由を知りたいです。

本当に十分な答えを得るには、非常に複雑なアルゴリズムの腸を掘り下げることになります。ドキュメントはあまりにも具体的にはなりませんが、ホワイトペーパーまたは仕様がそこにあると確信しています。

他の質問への回答が示唆するように、構成内のすべての「ローカル」行を削除した場合、サーバーに到達できない場合はどうなりますか？NTPは死にますか、それとも試行を続けますか？

NTPデーモンは死ぬことも停止することもありませんが、リモートサーバーへの到達に失敗すると、時刻の同期を終了します。これが、ベストプラクティスが最低3つのリモートサーバーを提案し、ネットワークから切断されていない限り、LCLを使用しないことを推奨する理由です。3台のサーバーが推奨されているのは、2台しかない場合に、どちらが選択されるのでしょうか？3番目のサーバーは、アルゴリズムが偽のサーバーを排除するのに役立ちます。

最後に、私はあなたがを定義していないことに気付きましたdriftfile。これは役立つかもしれませんか？

オフセットの間隔（システム時間とNTPホスト時間の差）は、NTPが適切に設定するには大きすぎるように思えます。

私のおすすめ、

 1. Stop the NTP service
 2. As root ntpdate -bs 10.130.33.201 to reset your time to something close
 3. Start the NTP service

その後は問題ないはずです。

LOCALサーバーとしての10.130.33.201のストラタムは9です。これにより、これから計算されたローカルストラタム（9 + 1 = 10）はストラタム10のローカルLOCALサーバーと競合します。ローカルLOCALストラタムにはネットワーク遅延やジッタがないため、 ntpdには、リモートのものよりも若干良く見えるかもしれません。

この構成を機能させるには、「マスター」ローカルサーバーを9未満のストラタムに設定します。ストラタム1サーバーまで追跡可能な時間を優先する場合は、低すぎません。

私はこれが古いことを知っていますが、あなたは正しいと思います。ntpdの問題をデバッグする方法は誰も示していません。それは実行可能です。

LOCAL（0）のローカルおよび上流サーバーでの使用が問題になる可能性があると疑ったとき、あなたは正しい軌道に乗っていたと思います。

確かに、4台のサーバーのタイムアイランドで、同様の問題が発生していました。これらはすべて互いにピアになるように設定されているため、おそらくあなたとは異なる問題になります。

ただし、最初に、過去数年のntpdバージョンでサポートされているオーファンモードと呼ばれるタイムアイランドを処理するより良い方法があります。

doc.ntp.orgの孤立モード

当初、4台のサーバーはすべて同じ10層であり、ローカルクロックを優先していました。私はそれを修正しましたが、彼らはまだローカル時計を好んでいました（しかし、層は重要であるようです）。

ntpqコマンドpe（peer）as rvを使用して、何が起こっているのかを把握しました。情報をダンプするには、サーバーのアソシエーション番号でrv（readvar）を使用する必要があります。peとasは同じインデックスでソートされているように見えるので、そのようにas番号を取得できます。asに条件と呼ばれるフィールドがあり、サーバーが気に入らない場合に値rejectを表示する場合があります。

rv出力には、flashというフィールドがあります。すべてが順調であれば、これはゼロになります。そうでない場合は、問題のビットマスク（16進数で表示）です。それらはここで調べることができます：

ntpd内部デコード

私が抱えていた問題は0800 peer_loopでした。クロックのrefidが重要であることが判明しました。ローカルクロックとリモートサーバーの両方でLOCAL（0）を見ると、ntpdはループがあると考えていました。David Millsはcomp.protocols.timeの投稿で「NTPのループを回避する方法」を確認しています（2リンクの制限に達しました、ごめんなさい！）

refid引数を使用して一意のrefidを設定することは機能しませんでした-まだ受信者でLOCAL（0）として表示されます。

動作しているように見えたのは、ローカルドライバーに一意のインスタンス番号を使用していたことです。127.127.1。[0-3]。サーバーとファッジラインの両方で同じIDを使用します。これを行うと、サーバーは通常、ローカルクロックを通常使用する最下位のストラタムサーバーに同期しました。ただし、ソースとして使用していた他のサーバーの1つを使用しようとすることがありました。しかし、時代は同期し、そのようにとどまっているようです。

おそらく手遅れになりますが、NTPがロジックとトラブルシューティングに適していることを示すためにそれを提供します。試行錯誤によって答えに達するまでに何時間もかかった後、後でドキュメントを見つけました。

iburstを使用して、1つの要求が失敗した場合でも、サーバーが目的のNTSにNTP要求を送信するように強制します