NTPと同期してくれないときのトラブルシューティング

1月 16, 2021

ラボ環境や検証環境だと、用意したNTPサーバーとESXi/VCSAが同期してくれないことがしばしばあると思います。

多くの場合はちょっとした設定の追加で解決できることが多いので、今回はその方法についてご説明します。

NTPサーバとの疎通確認

何はともあれ、まずはNTP側との疎通と動作確認が必要です。

以下のコマンドを実行してください。

※ESXiにはntpdateコマンドはないのでスキップしてください。

/sbin/ntpdate -b -u <ntp server ip>
/sbin/ntpdate -d <ntp server ip>

上のコマンドはNTPサーバと同期するコマンドです。NTPデーモンは時間がずれすぎている同期してくれないので、まずはこのコマンドで強制的に時間を合わせます。

下のコマンドはntpサーバの正常動作を確認するコマンドです。

このコマンドが失敗するようでは疎通やNTPサーバ側の問題ですのでそちらをご確認ください。

NTPサーバとの同期に時間がかかっている可能性
NTPサーバとの同期は一時間くらいかかることもあります。
その場合はiburstというオプションを付与することで初期同期までの時間を短縮できます。
/etc/ntp.conf内の外部NTPサーバのIPアドレスの後ろにiburstを追加することで設定可能です。
以下のような感じです。

##
48 server <ntp server ip> iburst
49 trustedkey
##

上記の設定があることで何十分も同期を待たずに済みます。

実施後は/etc/init.d/ntpd restart でサービスを再起動してください。

なお、NTPサーバとしてインターネット上の公開NTPサーバを指定している場合はiburstは利用しないか、利用可能かどうかをサーバの管理者にお尋ねください。

社内のNTPサーバの場合はほぼほぼ問題ないとは思いますが、確認しておいた方が無難です。

NTPサーバからの時刻が信頼されていない可能性

iburst設定後や、十分な時間が経過した後でも同期しない場合は、NTPサーバからの情報をNTP Clientが信頼していない場合があります。

VCSAの場合

vcsa の場合は ntpdc コマンドで確認します。

# /usr/sbin/ntpdc -c 'showpeer <ntp ip address>'
remote <ntp ip address>, local <ntp ip address>
hmode client, pmode unspec, stratum 2, precision -6
leap 00, refid [xxx.xxx.xxx.xxx], rootdistance 0.03125, rootdispersion 8.30737
ppoll 6, hpoll 6, keyid 0, version 4, association 57089
reach 001, unreach 1, flash 0x0400, boffset 0.00400, ttl/mode 0
timer 0s, flags config, bclient
reference time: dc0bbd00.3f21a2e7 Tue, Dec 27 2016 1:00:00.246
originate timestamp: dc0c6b35.c3fed202 Tue, Dec 27 2016 13:23:17.765
receive timestamp: dc0c6b35.c3d4dc75 Tue, Dec 27 2016 13:23:17.764
transmit timestamp: dc0c6b35.c3bfd0d1 Tue, Dec 27 2016 13:23:17.764
filter delay: 0.00032 0.00032 0.00000 0.00000
0.00000 0.00000 0.00000 0.00000
filter offset: 0.000801 0.000480 0.000000 0.000000
0.000000 0.000000 0.000000 0.000000
filter order: 0 1 2 3
4 5 6 7
offset 0.000801, delay 0.00032, error bound 1.98726, filter error 0.01791

!!! 注意 !!!

最近の NTP サーバでは ntpdc コマンドが利用する mode 7 がデフォルトで無効になっているため、コマンドが ”timed out, nothing received” となって失敗することがあるそうです。

その場合は、ESXi と同じく ntpq -classoc コマンドと、ntpq -c "rv xxxx" にてご確認ください。

ESXiの場合

ESXi には ntpdc コマンドは無いので ntpq コマンドで確認します。

※ntpq コマンドを利用するためには ntp サービスが稼働している必要があります。

# /usr/sbin/ntpq -classoc
ind assid status conf reach auth condition last_event cnt
===========================================================
1 63674 961a yes yes none sys.peer sys_peer 1

# /usr/sbin/ntpq -c "rv 63674" <<<< rv xxxx のIDは↑のコマンドのassidで確認
associd=63674 status=961a conf, reach, sel_sys.peer, 1 event, sys_peer,
srcadr=ntp-sv1.cpsd.local, srcport=123, dstadr=xxx.xxx.xxx.xxx, dstport=123,
leap=00, stratum=4, precision=-25, rootdelay=350.113, rootdisp=94.040,
refid=10.30.48.37,
reftime=e2b64f76.e5a956e2 Mon, Jul 13 2020 3:11:50.897,
rec=e2b650cc.9a6cec7e Mon, Jul 13 2020 3:17:32.603, reach=377,
unreach=0, hmode=3, pmode=4, hpoll=10, ppoll=10, headway=0, flash=00 ok,
keyid=0, offset=3.212, delay=0.700, dispersion=19.482, jitter=0.630,
xleave=0.039,
filtdelay= 0.74 0.70 0.74 0.68 0.69 0.73 0.76 0.79,
filtoffset= 3.37 3.21 2.94 2.99 2.91 2.83 2.40 1.89,
filtdisp= 0.00 16.02 32.31 48.08 64.13 79.52 95.43 111.65

このコマンド出力中で注目すべきところは太字で強調したflash のところです。
flashの値は簡単にいえばエラーコードみたいなものです。
上の例ではVCSAは0x400 となっており、ESXiでは00 (0x0000)となっています。
flashの値の意味についてはntpのソースコードのヘッダファイルに説明があります。

#### ヘッダファイル引用
+++++ include/ntp.h
/*
* Define flasher bits (tests 1 through 11 in packet procedure)
* These reveal the state at the last grumble from the peer and are
* most handy for diagnosing problems, even if not strictly a state
* variable in the spec. These are recorded in the peer structure.
*
* Packet errors
*/
#define TEST1 0X0001 /* duplicate packet */
#define TEST2 0x0002 /* bogus packet */
#define TEST3 0x0004 /* protocol unsynchronized */
#define TEST4 0x0008 /* access denied */
#define TEST5 0x0010 /* authentication error */
#define TEST6 0x0020 /* bad synch or stratum */
#define TEST7 0x0040 /* bad header data */
#define TEST8 0x0080 /* autokey error */
#define TEST9 0x0100 /* crypto error */
#define PKT_TEST_MASK (TEST1 | TEST2 | TEST3 | TEST4 | TEST5 |\
TEST6 | TEST7 | TEST8 | TEST9)
/*
* Peer errors
*/
#define TEST10 0x0200 /* peer bad synch or stratum */
#define TEST11 0x0400 /* peer distance exceeded */
#define TEST12 0x0800 /* peer synchronization loop */
#define TEST13 0x1000 /* peer unreacable */
#define PEER_TEST_MASK (TEST10 | TEST11 | TEST12 | TEST13)
####

上記のように定められています。

今回の場合は flash 0x400なので、
TEST11のpeer distance exceededに該当することが分かります。
（多くの場合はこれが原因と思います・・・）
これは要するに同期先のNTPサーバまでの距離が遠いということです。
（距離が遠いと信頼性が下がりますからね。違ったら御免なさい）

デフォルトで許容されるホップ数がいくつなのかは不明ですが、
とりあえず増やしてあげれば解決する理屈です。
なのでホップ数を30まで増やすためにtosコマンドを/etc/ntp.confに追記しましょう。
まとめるとこんな感じです。

## /etc/ntp.conf
48 server <ntp ip address > iburst <<<< iburst 追記
49 trustedkey
50
51 tos maxdist 30 <<<< 追記
##

ntp.conf の設定が完了したら、ntp service を再起動しましょう。
この設定をすれば、少なくともflash 0x400の問題は解消できるはずです。

ntp service の再起動方法は以下です。

# VCSA 6.0

service ntp restart

# VCSA 6.5 or later

systemctl restart ntpd

# ESXi

/etc/init.d/ntpd restart

0x400以外の問題については別の対応が必要になると思います。

また、flash codeが正常（0x00）なのに同期してくれない場合は、messagesログなどにntp デーモンのエラーが吐かれているかもしれませんので確認されることをお勧めします。

（補足）NTPサーバがWindwos OSの場合

WindowsサーバをNTPサーバとして構築している場合、デフォルトの設定では同期可能なNTPサーバとしてみなされない場合があります。

おそらく多くの場合はLocalClockDispersion の設定によるものと思われますので、この値が0になっているかを確認されることをお勧めいたします。

レジストリパス

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\

このブログを検索

IT or War