以下はntpq -pの結果です
remote refid st t when poll reach delay offset jitter
===========================================================================
+xxxxxxxx xxx.xxx.xxx.xxx 8 u 85 128 373 0.159 121.411 3.043
*xxxxxxxx yyy.yyy.yyy.yyy 8 u 59 128 377 0.187 122.618 2.626
通常であれば上記のようにwhenの値がpollよりも小さいのですが
時折，以下のようにwhenの値がpollの値を大きく越えてしまう(104m)
場合があります
remote refid st t when poll reach delay offset jitter
===========================================================================
+xxxxxxxx xxx.xxx.xxx.xxx 8 u 104m 512 300 1.834 236.726 14.426
*xxxxxxxx yyy.yyy.yyy.yyy 8 u 792 1024 377 5.846 348.096 24.042
①通常であれば，いつ最後のバケットを受信したかを示す「when」の値は
ポーリング周期「poll」の値を超えることは無いと考えておりますが
この認識は正しいでしょうか
②上記の現象が発生する原因として，どのようなことが考えられるでしょうか
③また，原因を特定するためにntpログのどういった部分に着目すればよいでしょうか
質問は以上です。
どうぞよろしくお願いいたします。
No.3
21
9
100pt
あー・・・参照先のサーバは同一機体の別I/Fでしたか。
まず念のため、送信と受信が別経路になる状態でのNTP運用は、原則として非推奨です。それぞれの経路の負荷がばらばらに変動する影響を受けるので、遅延の補償がうまくいかず精度が落ちやすくなります。ですので、とりあえずNTPについて言うなら、単にeth1だけ使うのがひとまずの正解だと思います。どうせ戻り経路が同じなのであれば、eth0を参照させておいても耐障害性は得られません。
で、問題のAからB:eth0の見え方については、これはNTP関係なしに本当にネットワーク構成自体の問題ですが・・・まずBの複数I/Fが何を意図していたのかわからないので何とも言い難いです。戻り経路が分離していない時点でロードバランスにはなってないし、管理ネットワークと公開系ネットワークを分けているにしても腑に落ちない。全く自動化していない冗長化もどき?
強いて現状のネットワーク構成が正しいことを前提として言うならば、「そもそもAからB:eth0に到達できていること自体が間違い」という結論しか出てきそうにない気がします。元々の意図がわかればもう少し何か言えることがあるかもしれません。
No.1
668268
50pt
①「通常」がエラーのない状態をいうのであれば普通は超えません。
②whenがpollを超えるのはパケットが帰って来なかったからです。ntpdがパケットを送出できなかったか、行き帰りの途中でパケットが失われたか、が主な原因と思います。
③今回の場合、常時ではなく時折、それも片方だけなので、自ネットワーク以外のどこかでパケットロスしている可能性が高いと思います。ntpログよりICMPパケットが来ていないか確認してはどうでしょうか。
ntpqの出力結果についてですが、reachが前者は「373」後者は「300」となっています。
この数字は8進数で、2進数表記にすることで失敗したポーリングを表します。
「373」の2進数表記は「11111011」、3つ前が失敗しています。
「300」の2進数表記は「11000000」、過去6回連続で失敗しています。
pollの512×6=3072秒=51.2分ですが、それまでのpollが1024なら倍の102.4分、さらに次回までの512秒≒8.5分の途中ということで、7回前から104分と解釈出来ます。
＃pollは2048→1024→512という遷移でも解釈できると思います。
参考：http://www.asahi-net.or.jp/~aa4t-nngk/ntpd2.html#utils_howto
この時以外でも「11111011」と失敗があること、もう一つの方は「377」とその間に全く失敗してないことなどを考えると、どちらかと言えば相手サーバ側の問題だと思います。
運が良ければICMPパケットが来ていて問題のノードはわかるかもしれません
しかし、ICMPパケットすら届かない可能性も高く、また問題のノードが分かったとしても、こちらが打てる手は、たぶんそのサーバを使わないという事しかないかもしれません。
reachについてよくわかっていなかったのでとても参考になりました
No.2
219
50pt
http://doc.ntp.org/4.2.6p5/ntpq.html
http://doc.ntp.org/4.2.6p5/debug.html
pollとwhenの解釈はあっています (ただし状況により数秒超える程度は通常稼働状態でもあります)。これは測定点が欠測あるいは品質不足により棄却になっている状態です。[reach] reach shift register が直近8回の測定状況で、(既に8回以上測定している場合) 値が 377 でない場合は測定が抜けています。
ありがちな原因としては
などですが、一概には言えません。負荷状況やトリップタイムなどを観察してどれと相関があるか割り出していくことになります。
peerstatsファイルについて分からなかったので調べてみました
http://jp.fujitsu.com/platform/server/sparcenterprise/manual/notes/pdf/ntpguide.pdf
のp41~42
時刻サーバとの同期状態の遷移を調べられるという解釈でよいでしょうか
正確に言うなら、実際に同期を行う前の、単にサーバから得ただけの測定値です。
その中から「一番もっともらしいサーバ」を選んで実際の同期に使うわけです。
普通のsyslogに出てくるのは、「一番もっともらしいサーバ」を選んだ後の、同期処理の具合だけなので、各サーバがそれぞれどういう応答をしているか、まではわからないのです。
回答いただきどうもありがとうございます。
返答が遅くなってしまい申し訳ありません
問題の現象が発生した計算機が参照するntpの時刻サーバーは自ネットワーク内に存在しております。
自ネットワークの問題を疑って、いろいろ調べていました。
問題が発生した計算機を、計算機A
計算機AのNTPDが参照する時刻サーバを計算機Bといたします
（計算機Bもほかの時刻サーバを参照している。参照先が自ネットワークか否かは調べておりません）
計算機Aは以下に示す2つの経路で計算機Bへ時刻問い合わせを行っています
（時刻サーバは1つで、問い合わせに用いるルートが2つある）
1.ルートR（応答が返ってこないことが頻発するルート）
計算機Aのeth0を通って、計算機Bのeth0に問い合わせパケットが送られる
Aのeth0→ゲートウェイR(ルータ？)→Bのeth0
計算機Bのeth1を通って、計算機Aのeth0に応答パケットが送られる
Bのeth1→ゲートウェイL2(ルータ？)→Aのeth0
2.ルートL
計算機Aのeth0を通って、計算機Bのeth1に問い合わせパケットが送られる
Aのeth0→ゲートウェイL1→Bのeth1
計算機Bのeth1を通って、計算機Aのeth0に応答パケットが送られる
Bのeth1→ゲートウェイL2→Aのeth0
計算機Bから応答が返ってこない状態のときのパケットの送出状態をtcpdumpを使って調べてみました
以下が結果です
計算機Aのeth0から送られた問い合わせパケットは計算機Bのeth0に届いていました
しかし、計算機Bのeth1に応答のパケットが送られておらず、計算機Aは計算機Bからの応答を
受け取ることが出来ていませんでした
このことから計算機Bのntpdが、計算機Aに応答を送信していないのか
送信はしているが失敗しているのどちらかだと考えています
このときに、計算機Ａから経路Rを通って計算機Bにpingを送出するとなぜか
上記の現象が解消してしまいます
（1度目のpingは時間がかかるか失敗するが2回目のpingはたいてい通る）
ネットワークの問題だと考えていますが
どうして問題でおきているのかわかっていない状態です。
No.3
219
ここでベストアンサー
100pt
あー・・・参照先のサーバは同一機体の別I/Fでしたか。
まず念のため、送信と受信が別経路になる状態でのNTP運用は、原則として非推奨です。それぞれの経路の負荷がばらばらに変動する影響を受けるので、遅延の補償がうまくいかず精度が落ちやすくなります。ですので、とりあえずNTPについて言うなら、単にeth1だけ使うのがひとまずの正解だと思います。どうせ戻り経路が同じなのであれば、eth0を参照させておいても耐障害性は得られません。
で、問題のAからB:eth0の見え方については、これはNTP関係なしに本当にネットワーク構成自体の問題ですが・・・まずBの複数I/Fが何を意図していたのかわからないので何とも言い難いです。戻り経路が分離していない時点でロードバランスにはなってないし、管理ネットワークと公開系ネットワークを分けているにしても腑に落ちない。全く自動化していない冗長化もどき?
強いて現状のネットワーク構成が正しいことを前提として言うならば、「そもそもAからB:eth0に到達できていること自体が間違い」という結論しか出てきそうにない気がします。元々の意図がわかればもう少し何か言えることがあるかもしれません。
AからR経由でB:eth0に送信(だけ)できてしまっているのが最初から間違い（つまりA→RかR→B:eth0のどちらかが意図したものでない）なのかな、と。
逆にもしこれで冗長化のつもりなのだとしたら・・・これを冗長構成として運用するのはかなり面倒くさいような・・・と言いますか、実は冗長化のフリをしているだけで実際には何の役にも立ってないというひどいオチの可能性が。
回答ありがとうございます
ネットワークの問題である可能性が高いと言うことで納得致しました
ghost
2013/05/10 10:09:03
5
5
TransFreeBSD
2
1
1
AからR経由でB:eth0に送信(だけ)できてしまっているのが最初から間違い（つまりA→RかR→B:eth0のどちらかが意図したものでない）なのかな、と。
2013/05/13 23:53:16逆にもしこれで冗長化のつもりなのだとしたら・・・これを冗長構成として運用するのはかなり面倒くさいような・・・と言いますか、実は冗長化のフリをしているだけで実際には何の役にも立ってないというひどいオチの可能性が。
回答ありがとうございます
2013/05/17 00:07:15ネットワークの問題である可能性が高いと言うことで納得致しました