Yet Another network command/tool/system


2000/6/16(金)10:15AM-
発表者: 向阪 正彦 ファストネット株式会社


発表内容
1. 概要
2. ping関連のツール
3. traceroute関連のツール
4. webインターフェースのツール
5. まとめ、付録


1. 概要:
ISPとして普段よく使っているコマンド関係 - 経路が違った
コマンドの使い方 - を挙げてみたい。
ISPの運用には障害探知があり、実際には機器の稼動状況をみる
ツールを用いている。機器の構成管理、トラブルチケットに
関する情報、ツールは少ないが、稼動状況監視のツールは、
フリーのもの、小さいコマンドを解説したものがかなりある。


機器の障害には、ping, traceroute, snmpなどを使っている。
システム全体を監視していこうというと、snmp, mrtg, portの
チェックなどがある。その他に自作のものを用いている。
そんなに統合されたものでなくてもよいので、チェックが早く
できるもの、効率のよいものが必要である。


2. 初心に返って...ping
unixの端末からpingを打つとintervalはデフォルトで1秒かかる。
それなりに時間がかかってしまい、遅い。
ciscoのルータから打つ場合と、unixの端末から打つ場合とでは
違って、Ciscoなら5秒ぐらいかかる。


optionを使ってみる。
ping -f(floodオプション): rootでしか使えない。
                        : cisco的にインターバルを短くしたい。
                          (何とか1秒以内)


-i: intervalのオプション
    pingのプログラム自体でintervalを1秒以下に設定できるように改造。
    コンマ1、コンマ05を設定可、効率良くpingが打てる。
    数十台数、数百台監視しなければならない時に有効。
    FreeBSD2.2.8上でpingを改造。
    FreeBSD3.xからは、-i(intervalオプション)は、rootでは1秒以下に
    設定できる。


fping:
ipのリストを指定すればシーケンシャル、順番に打っていく。
icmpを3回ぐらいしか投げないので、dead or aliveの確認にしか使えない。
Replyのsrcアドレスが違うものから帰ってくると、unreachableになってしまう。
(NATの設定がおかしいのか、NATの先のプライベートで返ってくる。)


multiping:
複数箇所に投げられるping。
option等、通常のものとほとんど同じ。
-tをつければ表形式で出てくるなど、出力の結果を指定できる。


router - router間で、障害の時の切り分けなどであちこちに
打ちたいという状況がある。
Ciscoのrsh設定 - リモートシェルをリネイブルするようなものがある。
コマンドラインの引数で、routerのip, targetのip, 引数で
とれるようなものを実装してみた。


好きなターゲットへのping:
5分に1回pingを打つような監視を行っている。
監視をしているサーバの負荷が高い。
mrtgでサーバの負荷をみていると高い。1.1などで高い。
5分で1回なので、自分で自分を監視している分、負荷が高いのか。


spingd&spingread:
常に出し続ける。
一定のリングバッファに書き出す。ただそれだけを行う。
ipアドレスとシーケンシャルをキーに書き出す。
spingreadで読むと過去5分間なりのpingの結果が読める。
dbmを読み出して普通のpingのoutputのかたちにする。
10秒おきに一回のicmpでいいのか、もしかしたら正確な値が
出ないのではないか？


3. traceroute


ASを表示できる版のtraceroute:
-a, -hというオプションをつけることによってずっと、
AS途中の経路にあるIPアドレスからの組織を出していく。
自分のマシンからみたい場合には有効である。


MTR:
tracerouteとpingを同時に実行。
継続的に投げ続けることによって、pingと同じようなことを行う。


visualroute:
ping, traceroute, dnsの情報を表示して、実際の経路を
地図上にvisualに表示する。(javaのアプレット)
ISPの監視にデモとして面白いツール。


4. Webインターフェースのツール
LookingGlass:
WANのトラブルシュートには必須。


mrtg:
input, outputの2値しかとれない。
扱いはらくだが、不満。


shepherd: 
内容的にはmrtgと似たインターフェースをもつ。
デーモンのように立ち上がっていて、複数の宛先まで
非常に効率のよい収集をする。
configを書いて、起動。


トラブルチケットの分野としてRT: 
MySQLとcgiで書かれたツール、比較的わかりやすい。


KeyStone: 
PHP高機能だがわかりにくい。
利用によってはライセンスが必要。


構成管理のtipsとしてcvs:
リヴィジョン管理が非常に楽にできる。
実際にconfigを取ってきて、登録してくれる。
メリットとして、web上でそれまでと変わったところを
カラーで比較できる。


5. まとめ
以上みてきたように、便利なものはいろいろあり、使い方、
カスタマイズの余地はいっぱいある。
今後、さらにいろいろOpenSourceのソフトを評価して、
使い方、使い勝手等をカテゴライズして公開していきたい。


質疑応答&コメント：

コメント：
visualrouteの場所の表示は、DNSの結果を用いているようである。

********************************************************

質問:
pingは、interval - 監視対象に対して何発打つかというところが
ポイントで、5分に30回打つのと、5分間で平均して30回打つので
あれば、平均化された方が負荷として低いのではないかと考えるが...


回答:
平均化された状況をみたいわけで、pingのエージェントを複数の
サーバーに置いて、そこからpingを打つ。もちろん複数箇所から
打つけれども、その中の１台でも、平均化されて打った方が効率が
よいと考える。


*******************************************************************


質問:
ネットワークのルータはunstableで、ping1回だと非常にゆらぎが多く、
出てきた数字があてにならない。
影響を受けない、ゆらぎを少なくするためにどうされているのか。
今後の参考にしてみたい。
[pingをISP内部から使うということでは有効で、監視をネットワーク経由
で行うという場合、どこまで自動化していくとオペレーターにとって
幸せなのかということになるのだが...]


回答:
WANを介してping等で監視する、しきいち等で難しい。
5分で1回のピンポイントだと、全然返ってこない。落ちていたり、とだめ。
時間のスパンをみて、直後でみてみてそちらでokayだったらそちらでみる。
時間で平均化する。multipingだとゆらぎが大きい。
fpingだとそこそこ正しい。そこら辺のチューニングをどうすればよいか、
ということになると思う。