８．ネットワ−ク管理技術 '97〜 8-1. ネットワ−クの監視 (1) ネットワ−クの監視ツ−ル * パケットを見るソフト Sniffer パケットの中身を見る ↓ tcpdump, etherfind, snoop どんなパケットが流れているか見る ↓ netstat パケットの流れ具合を見る ・Sniffer は Network General 社販売のプロトコルアナライザである。 ・tcpdump は Van Jacobson らによって開発されたフリ−ソフトである。 ・etherfind は SunOS 4.1.x 用で、Sun ＥＷＳ専用である。 ・snoop は Solaris 2.x 用である。# /usr/sbin/snoop とか # snoop -d le0 等とする。 ・オ−プンソ−スの Ethereal, FreePeek。PacMon １万円、Observer 14.8 万円から等。 [ 使い方 ] Sniffer はこの手のソフトでは非常に有名である。イ−サネット・ケ−ブルに穴を開けて、 全部のフレ−ムを拾いだし、中身を見れるというようなものである。 telnet セッション のパスワ−ドなんかでも容易に見ることができる。 ちなみに Sniffer はくんくん嗅ぎ回 るという意味である。フレ−ムと書いたのは、 ＩＰパケットでも NetBEUI のパケットで もイ−サネットに流れているデ−タは何でも見られるためである。tcpdump では NetBEUI は補捉できない。Sniffer の問題点は市販品で、非常に高価だったことである。 次の tcpdump はフリ−ソフトで、 パケットが飛び交っている状態を目で見ることができ る。１パケットずつトレ−スしていくので、 telnet セッション開始のハンドシェイクの 状態や、named へのＩＰアドレスの問い合わせのやりとりを見ることができる。これは是 非使ってみるべきである。etherfind は SunOS 4.1.x 用で tcpdump と同等な機能である。 Solaris の snoop は、 なんと telnet のロッグイン、パスワ−ドの入力した文字をも表 示する。tcpdump や etherfind はそこまでは、容易に見ることはできない。 netstat は上記の様な細かな情報はとれないが、パケットのコリジョンの測定、ホストの 経路情報、デ−モンの使用ポ−ト、ネットワ−クサ−ビスの状態など、色々なことが分か る。経路情報を見る netstat -rn、ホストのインタ−フェ−スを出入りするパケットの様 子をみる netstat -i ぐらいは覚えておこう。 netstat -i の値をもとにネットワ−クの コリジョンや、エラ−の発生率などを計算で求めることができる。 ただし netstat コマ ンドではネットワ−クの使用率までは求めることはできない。 * とりあえずの監視 tcpdump と Sniffer があれば、 とりあえず当面のネットワ−クはめんどうみることがで きる。SNMP とか RMON とか何かと業界はうるさいが、 別にどうしてもなければならない というものではない。Sniffer はかつて専用の測定装置みたいのしかなく、４００万円ぐ らいしたらしい。 それが９８年７月時点、(株)東陽テクニカが Sniffer Basic-J という のを 248,000 円でキャンペ−ン販売している。Windows 95/NT。10/100 Mbps イ−サネッ ト対応。９８年８月３１日までのお試し版も CD-ROM で無料で配っている。これなら買え ると思うけど。もう少しまけてもらって１９万８千円にならんか。 従来の Sniffer との大きな違いは、エキスパ−ト機能がないこと。 つまりパケットを解 析してこんな障害が起こっていますよと教えてくれる機能が Sniffer Basic-J にはない ことぐらいである。しかしネット−クの障害なんてものは、大方コネクタの接触不良であ る、ちょっと飛躍し過ぎか。RMON はどうだ。RMON2対応プロ−ブというネットワ−ク装置 で、そのセグメントに流れているパケットを捕え、他ホストのネットワ−ク管理ソフトを 使って見るというもの。しかし Sniffer Basic をそのセグメントにもっていけば、RMON2 と同じパケットを見ることができるし、各種グラフも同じように表示ができる。 RMON2 対応プロ−ブや管理ソフトの問題はこれまた高いということ。プロ−ブは８０万円 前後、ソフトも５０万円以上する。こりゃそう簡単に買えない。しかもプロ−ブは基本的 に１セグメントに１個用意する必要がある。それがいやなら１つのプロ−ブを使い回しす るしかない。そんなことするなら Sniffer Basic をノ−トパソコンにでも入れて、 ハブ に繋ぎ変えたって同じである。と、こんな風に RMON2を理解したのだが違うかな？、合っ ている？。RMON はセグメントを流れるパケットを見てトラフィックの状態を計測する。 ネットワ−クの大方の問題は、意図しないパケットが頻繁に出ることにある。Windows パ ソコンはデフォルトで NetBEUI パケットを出しまくっている。これは tcpdump では見れ ないが、Sniffer ならしかっり表示してくれる。ＥＷＳもどこでどうなったか分からない が、マルチキャストを変なＩＰアドレスに向けて出したりしている。 これは tcpdump で 一応分かるが、Sniffer なら絵で示してくれる。非常に有難い。ＩＰアドレスでどこから どこへパケットが飛んでいるかが分かるので、問題の特定も楽である。 それに Sniffer Basic は、 ネットワ−クの状態を知るためのコリジョンやネットワ−ク 使用率なども色々出してくれる。なんと１５秒間隔で１５時間までレコ−ドできるのであ る。RMON2 なんかが出る以前、否現在でもトラフィックを見るのに、 プロは Sniffer を 使っている。色々フリ−のソフトもあって、それぞれ組み合わせれば相応のことができる のだろうが、２０万円ちょっと出して Sniffer Basic を買った方が賢明だと思う。 なん といっても、グラフィカルに表示してくれるのがいい。 日頃、時たま Sniffer を動かし て何気なく眺めているだけでも、ネットワ−クの状態が分かって来るというものである。 * ネットワ−ク接続確認の ping コマンド 相手ホストが稼働しているか調べる時によく使う。パケットが行って戻って来るまでの時 間も分かる、Round Trip Time(RTT) という。 同じセグメント上のホストに ping する場 合、ネットワ−ク装置などに問題がなければ、ほぼ 1 ms を示すだろう。下の実行例でも そうだったが、RTT の値を分かりやすくするため 1,2,4 ms としてみた。 この RTT 値を 見ていればネットワ−クの混雑の度合もある程度は分かる。 % ping mail PING mail (192.168.1.1): 56 data bytes 64 bytes from 192.168.1.1: icmp_seq=0 ttl=255 time=1 ms << 単位:ミリセック。 64 bytes from 192.168.1.1: icmp_seq=1 ttl=255 time=2 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=255 time=4 ms ----mail PING Statistics---- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 1/2/4 ms << 最小、平均、最大 * その他のＵＮＩＸ系ネットワ−ク監視コマンド traceroute: ICMP を使って相手ホストに到達するまでの経路を調べられる。 netuse : ブロ−ドキャストは使わない。ル−タの先も見れる。 ttcp : イ−サネットのパフォ−マンスの測定に使える。INDY にあったもの。 netperf : ttcp より精密に測定できるとのこと。 patchar : traceroute みたいなソフトだが賢いらしい。 MRTG : トラフィックを長期的に見るフリ−ソフト。 これら以外にも netsnoop、spary、rtquery、rup、traffic など色々ある。 Windows のＤＯＳコマンドにも ping がある。netstat -rn コマンドも使える。 [ traceroute コマンド ] NetCache、Cisco 2514、Summit24 などネットワ−ク機器には traceroute、このコマンド 名で入っている。Windows 98 や Windows 2000 には、DOS 窓から tracert というコマン ドで使うことができる、ＩＰアドレスで表示するには > tracert -d 192.168.1.1 という ようにする。ＵＮＩＸ系は # traceroute -n 192.168.1.1 である。 [ ttcp コマンド ] イサ−ネットのパフォ−マンスの測定に使う。２０１０年のこと小型の Linuxアプライア ンスの OpenBlockS を触っていて、 インスト−ルソフトに nttcp( New TCP testing and performance measuring tool ) というのを挙げていた。この前身が ttcp だろうと思う。 受信側 % ttcp -r -s -v ディスクアクセスは関係しない 送信側 % ttcp -t -s hostname * パケットの調査 `22/12 MRTG のグラフで突出したところや定期的に出現するパケットがあった場合、 それがＩＰ アドレスでどこからどこへ行っているのかまでは分からない。傾向として、多いとか通常 ではないパケットが出ていると分かるだけである。Sniffer Basic では、どこからどこへ パケットが行っているかは分かる。どのパケットが多く流れているかも分かる。しかしな がら MRTG のような時系列的なグラフは出すことができない。それゆえ異常パケットがど れか、なかなか特定するのは難しい。そんな場合にちょうどいいのが ASTEC Eyes という 市販ソフトである。MRTG のような時系列グラフを出すことができ、 グラフをピックする とどこからどことＩＰアドレスが出て来る。http://www.asteceyes.com/ でお試し版をダ ウンロ−ドすることができる。ASTEC Eyes は２００１年の "Networld+Interop Tokyo"で 初めて見た。MRTG、Sniffer Basic、ASTEC Eyes の３っつは是非揃えておきたい。 * tcpdump の Windows 版ともいえる windump コマンド `25/03 手元の Windows 2000 Professional に入れてみた。 windump といきなりコマンド入れた が反応なし。 先ずは >windump -D とやって、パソコンがネットワ−クにつながっている イ−サネット・インタ−フェ−スを調べないといけない。ここでは２番だった。 -i 2 と 指定する。INDY の tcpdump ではパケットの取りこぼしはまるで無かったと思う。どうも windump では、パケットが流れているはずが、キャプチャ−し損なっていることがあるみ たいである。 http://wincap.polito.it/install/default.html の WinPcap 3.1 beta 4 download から [ WinPcap auto-installer ( driver +DLLs ) ]をクリック。Windows 2000 に入れてみる。 C:\Program Files\WinPcap\ ディレクトリができて幾つかプログラムが入った。 http://windump.polito.it/install/default.htmlの WinDump 3.8.3 beta download から [ WinDump.exe ] をクリック、これは実行形式のファイルなのでどこか適当な場所に入れ る。C:\Program Files\WinPcap\ に入れた。このディレクトリでコマンド打つ。 C:\Program Files\WinPcap>windump -help windump version 3.8.3 beta, based on tcpdump version 3.8.3 WinPcap version 3.1 beta4 (packet.dll version 3, 1, 0, 24), based on libcap version 0.8.3 Usage: windump [-aAdDeflLnNOpqRStuUvxX] [ -B size ] [ -c count ] [-C file_size] [ -E alogo:secret ] [ -F file ] [ -i interface ] [ -r file ] [ -s snaplen ] [ -T type ] [ -w file ] [-y datalinktype ] [ expression ] >windump -i 2 src 192.168.1.2 ICMP, TCP, UDP 対象。dst もあり。 >windump -i 2 tcp and src 192.168.1.2 TCP のみ対象、ホスト名解決する。 >windump -i 2 -n tcp and src 192.168.1.2 TCP のみ対象、ホスト名解決しない。 * windump コマンドの入れ直し `28/07 久々に使おうとしたらプログラムがなかった。いつだったかディスクが壊れてＯＳを入れ 直したのだった。Windows 2000 に入れ直してみる。Google で windumpを検索して、今ど こにソフトがあるのか調べた。http://www.wincap.org/windump/ にあった。WinPcapをや はり先にインスト−ルしてくれとある。"The latest stable WinPcap version is 4.0.2"、 WinPcap auto-installer(driver +DLLs) をクリックし、C:\Program Files\ 下にwindump ディレクトリを作り WinPcap_4_0_2.exe をダウンロ−ドした。クリックすると、C:\Prog ram Files\WinPcap\ が出来、rpcapd.exe, Uninstall.exeの２つが出来ていた。それから "Windump 3.9.5 Executeable Download" で WinDump.exe を C:\Program Files\windump\ にダウンロ−ドした。これですぐに >windump とコマンドを打って使えた。 (2) イ−サネットの性能とは * パケットの衝突 内部ネットワ−クが、十分なパフォ−マンスが出ているかどうかどうやって調べたらいい だろうか。これが分からなければ 100 Mbps のＬＡＮにするべきかどうかも判断できない。 あるいはル−タを入れた方がいいか、スイッチング・ハブにとりあえずした方がいいのか とか。次の "ブロ−ドキャストによる性能低下" はやや特殊な状況下で起こると思われる。 ここではネットワ−クの定常的な状態で、どうネットワ−クの性能、つまりイ−サネット の性能を判断したらいいか考えてみたい。 -------------------------------------------------------------------------------- ネットワ−クの性能を見るのは、パケットの衝突だけで判断してよいか。基本的によし。 -------------------------------------------------------------------------------- イ−サネットは CSMA/CD( Carrier Sence Mulitiple Access with Colliaion Detection) という伝送方式である。パケットは同一サブネットには、一時に１個しか流すことができ ない。パケットを出すタイミングは早いもの勝ちである。もし他のホストやデ−モンがそ の時にパケットを出さなかったら、めでたしめでたしである。しかしほぼ同時にパケット が出ると、そこで衝突（コリジョン）が起きるわけである。 * 性能指針 ではパケットの衝突はどの程度までならいいのか。あまり明確な指針はないというのが本 音である。コリジョンはできるだけ無いのがいいのは当り前である。では何％以下なら許 容の範囲なのか、どうも一概にこれこれとはいい難いみたいである。雑誌、本によっては １％、いや５％以下だとか書かれている。まあともかく３％を一応の目安としよう。たま に自分のＥＷＳで netstat -i とやってみるが、コリジョンの項目は先ず０である。多分、 そんなに混んでいないネットワ−クでは０％なのだぞ。きっと。 ※コリジョンの発生率が３％以上は要注意である。 コリジョンとともに注意すべきが、ネットワ−クの使用率である。帯域、つまり 10 Mbps イ−サネットなら 10 Mbps の何％以下ならだいじょうぶかという話である。 昔のイ−サ ネットは 10 Mbps と言っても、実際には 3〜4 Mbps のスル−プットしか出なかったらし い。数年前の話しでは 6 Mbps は出るようになっているらしい。何年も前の本で、使用率 １０％ぐらいで要注意、３０％になると、もう危険信号であると書いてあるのを目にした。 昔のスル−プットの値と合致するようだ。Sniffer Basic のデフォルトのしきい値は１０ ％になっていた。 ※ネットワ−クの使用率は、概ね１０％以下が望ましい。 一つテストしてみた。ftp で大きめのファイルを手動でどんどん転送し、そこを Sniffer Basic で見たわけである。５秒に１回ぐらい get file と手入力したのだが、これで使用 率は１０％もいかなかった。６％ぐらいのものか。 しかしへたすると１人が ftp を自動 で連続して使うだけでも、１０％ぐらい行ってしまいそうである。どうりで他のマシンが ftp でバックアップを始めると、何となくネットワ−クの反応が遅くなるはずである。た だ瞬間的に１０％、３０％になろうがあまり問題ではない。それがいつもだと困るわけで ある。 他、性能指針としてはパケットのエラ−や再送率がある。エラ−の発生はネットワ−クを 流れるパケットの問題とはやや異なる。ＥＷＳ自体のトラブル、ネットワ−ク・カ−ドの 故障、ケ−ブルの断線など物理的な要因が大きいと思われる。パケットの再送が起きる場 合は、ホストやル−タ等の機器で CPU 負荷が大きくなり過ぎると、 パケットをとりこぼ したり、なくしたりしてしまう。そうなるともう一度送ってくれ−となるわけである。ち なみに、スイッチング・ハブは原理的にコリジョンは起きないが、パケットの再送は起き るということも覚えておくとよい。 [ ＷＡＮ側は？ ] ※ＷＡＮ側回線（専用線やISDN）の平均使用率は、概ね５０％以下が望ましい。 以前、この５０％という値の根拠を教えてくれとメ−ルが来たことがあった。大手家電メ −カの人で、ユ−ザに回線アップの提案するために数値が欲しい旨、書いてあった。私も どこかしっかり書いたものがあれば教えて欲しいバイ。小生は Apollo のマニュアルのど こかに書いてあったのを見た記憶があるのだ。どのマニュアルだったか、忘れてしまった のだが。今、この何行かを追記しているのは２００１年の１１月なのだが、最近、耳には さんだとこによると、Cisco の資格をとるための本に７０％という数値が出ているそうな。 本屋いくとその Cisco 本がずらっと並んでいるわな。 しかし５０とか７０％とか言って も、どういう状態の値なのかそれが問題である。 時たま、たまげたげにピ−ク値が出る。回線速度が 128 Kbps なら、一日の内、数回一瞬 90 Kbps 以上になる。別にこんなのは問題ではない。目安として、９時から５時の間で少 なくとも５分以上、連続して 90 Kbps 以上の帯域を使っているような状態。 それが日に 何度もあり外部ヘのＷＷＷアクセスの応答が帰って来ないような状態。これは困る。情報 収集のため、外部ＷＷＷを見ようとした時に見れない。がまんできるのは、５分待って再 度アクセスしたら見れた。これぐらいだろうということである。ＥＣによる販売サイトも 設けているなら、５分もお客さんを待たせるわけにはいかない。１分である。回線のトラ フィックは MRTG で計測できる。大学サイトで MRTG グラフを公開している所がある。感 覚を掴むため、見てみるとよい。平均２０とか３０％なんて値が出ていた。 * ブロ−ドキャストによる性能低下 ＩＰアドレスで、ブロ−ドキャスト・アドレスを使うと、同一サブネットに接続している ホスト全てにパケットを送ることになる。これだけならただのネットワ−ク・アプリケ− ションと同じであるが、ブロ−ドキャスト・アドレスの場合は、全てのホストはパケット を一応受けなければならないことが違う。ただのパケットの場合は、自分に関係なければ パケットを受ける必要はない。 ブロ−ドキャストを出している状態でコリジョン、つまりパケットの衝突が起き出すと再 度ブロ−ドキャストを出し、ネットワ−ク全体がブロ−ドキャストで溢れ出すことになる。 これはブロ−ドキャスト・スト−ムと呼ばれている。この状態になると、ファイル転送が 遅くなったり、リモ−ト・ロッグインしても反応がかえって来なくなったりする。さらに 状態がひどくなると、ネットワ−ク全体が全く機能しなくなる。これはイ−サネット・メ ルトダウンと呼ばれる。 引き起こす可能性のあるデ−モンは routed や timed、 コマンドには rwho、ruptime 等。 routed を動かすと３０秒に１回、経路情報をブロ−ドキャストとして吐き出す。 telnet や FTP をかける場合、NIS クライアントが NIS サ−バのホストにアクセスする場合、相 手先のＭＡＣアドレスを知るため、ARP のブロ−ドキャストが発生する。Windows パソコ ンも数十秒に１回吐き出しているのが tcpdumpで観察すると分かる。しかしブロ−ドキャ スト・スト−ムは正常にネットワ−ク接続、設定されていれば滅多に起こるものではない。 機器のＩＰアドレスのサブネット部が、そのネットワ−クと一致していなかったり、とん でもないホスト・アドレスをつけていたり。またはタ−ミネ−タがなかったり、抜けてい たり、UTP ケ−ブルがぐらぐらしていたり、物理的な要因もある。あるいはプログラムの ミスで、ブロ−ドキャストが頻繁に発生するようになっていたりするかも知れない。ブロ −ドキャスト・スト−ムは意外に些細なことで発生する可能性がある。「インタ−ネット 構築入門」P.491〜 "12.5 Ethernet でのブロ−ドキャスト スト−ム" を読むとよい。 * トラフィックの計測 ＥＷＳに標準で入っている netstat コマンドで計測できる。 netstat は自ホストのイン タ−フェ−スを出入りするパケットの数を見るためのツ−ルである。tcpdump のようにイ −サネット・ケ−ブルを流れるパケットを全部捕える訳ではないことに注意。ともかく次 のようにコマンドを入れてみよう。ここでのパケットは正確にはイ−サネット・フレ−ム と呼ぶのが正しい。 $ /usr/ucb/netstat -in Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Collis dr0 1268 192.10.10 192.10.10.1 4340 0 14 0 0 eth0 1500 192.9.200 192.9.200.2 4116 0 6748 0 0 lo0 9216 127 127.0.0.1 2 0 2 0 0 Ipkts : 入ってきたパケットの数。 Ierrs : 入ってきたパケットの内エラ−を起こしていたパケットの数。 Opkts : 出て行ったパケットの数。 Oerrs : 出て行ったパケットの内エラ−を起こしていたパケットの数。 Collis: 衝突（コリジョン）を起こしたパケットの数。 上記の出力ではイ−サネットのインタ−フェ−スが dr0、eth0、lo0 と３つある。lo0 は ロ−カル・ル−プバックである。ロ−カル・ル−プバックはＵＮＩＸマシンに必ず備わっ ている、自分自身向けのイ−サネット・インタ−フェ−スである。dr0、eth0 はこのホス トがゲ−トウェイ構成になっているため２つ出ているのである。 Ipkts ... Collis の数字は、 そのコンピュ−タが起動してから今まで出入りしたパケッ トの数を示す。値をクリアして、これからのパケットを計測するというオプションはない。 クリアするには、ＥＷＳを再起動するしかないみたいである。しかしコンピュ−タをず− と止めずにおくと、どんどん数字が大きくなるのだが、一体どうなるのだろう。 それにコリジョン計測のタイミングや場所も実際には問題となる。誰もコンピュ−タを使 っていない時に調べても無駄という訳である。 それに netstat で見ることができるのは、 そのＥＷＳで起きていることに過ぎない。厳密に調べるには、ネットワ−ク上の主要なホ ストそれぞれで、できれば同時に計測することが必要になるかも知れない。 コリジョンの発生率が３％以上は要注意である。 ( Collis/Opkts ) X 100 Ierrs+Oerrs+Collis エラ−の発生率が１０％以上は要注意である。 ------------------ X 100 Ipkts+Opkts パケット計測に関する netstat コマンドのオプションを幾つか示す。 -I eth0 は特定の インタ−フェ−スのみ対象にする。 次の 5 というのは５秒毎にタッタと状態を表示する。 -in 5 の左部分は eth0 のみの数字であり、右のは dr0 と lo0 を含めた数字である。こ れ以外にも netstat -s というのがあり、もっと詳しい情報を出すことができるみたいだ が、少々勉強しなければならない。 $ /usr/ucb/netstat -in -I eth0 Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Collis eth0 1500 192.9.200 192.9.200.2 4120 0 6748 0 0 $ /usr/ucb/netstat -in 5 input (eth0) output input (Total) output packets errs packets errs colls packets errs packets errs colls 4115 0 6748 0 0 8453 0 6764 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (3) tcpdump コマンドを試す * インスト−ル 適当な ftp サイトから次のファイルをとってくる。archie で調べたら国内でも至るとこ ろにあった。ftp.lab.kdd.co.jp/inet/tcpdump から一番新しいのをとってみた。tcpdump 自体のソ−スは tcpdump-3.2.1 であるが、コンパイルするときに libpcap というのがな いといけない。以下は INDY にインスト−ルした時の話である。 libpcap-0.2.1.tar.Z、tcpdump-3.2.1.tar.Z libpcap-0.2.1 は tcpdump-3.2.1 ディレクトリ下に置いてコンパイルするのが注意点で ある。libpcap-0.2.1 の中の libpcap.a が必要らしい。 ファイルの展開は uncompress と tar でやること。展開したらまず libpcap の方を先に configure,make とコンパイル かけて libpcap.a をつくる。 /usr/local/source/tcpdump-3.2.1/ ... /libpcap-0.2.1/ ... % uncompress tcpdump-3.2.1.tar.Z % tar xvf tcpdump-3.2.1.tar % configure << IRXI 5.3 と認識する。 % make << これで tcpdump の実行モジュ−ルができる。 % make install ./install-sh -c -m 550 -o bin -g sys tcpdump /usr/local/sbin % make install-man ./install-sh -c -m 444 -o bin -g bin tcpdump.1 /usr/local/man/man1 % make install は tcpdump を /usr/local/sbin にコピ−するだけである。install-man の方も、tcpdump.1 ファイルを ../man1 にコピ−するだけである。別に install コマン ドを使う必要もない。それにマニュアルをインスト−ルしても INDY では見ることができ ない。どうも INDY には nroff コマンドが入っていないためらしい。 % man tcpdump と やっても表示されない。仕方ないので Apollo と Sun でマニュアルを見ることにした。 $ /usr/bin/nroff -man tcpdump.1 オンライン・マニュアルと同じ表示をする。 しかしどうもおかしい。変なコントロ−ルコ−ドが入り、化けるところがある。以前のバ −ジョンの tcpdump のものも調べたが同様おかしかった。 しかし、ところどころ頭に三 角と９が入るだけである。エディタで消してやればよい。特に抜けはないみたいである。 % tcpdump -help Version 3.2.1 Usage: tcpdump [-deflnNOpqStvx] [-c count] [ -F file ] [ -i interface ] [ -r file ] [ -s snaplen ] [ -T type ] [ -w file ] [ expression ] * パケットを見る tcpdump ができたら、ともかく % tcpdump とコマンドを打ってみる。 すぐに飛びかって いるパケットが順々にディスプレイに表示されてくる。オプションはなんかすごくたくさ んあるが、どうも気にしなくてもいいみたいである。ともかく全てのパケットを拾うから、 注目しないデ−モンを止めておけば、見やすくなる。 以下の図は hostA のイ−サネットの口 ec0 から、流れているパケットを見ようとしてい る。hostA 自身のデ−モンがネットワ−クに出すパケットと、他のホストが出すパケット を ec0 を通してみることになる。これはちょうど、 ネットワ−ク・ケ−ブルを通るパケ ットを ec0 というガラス越しに見ているようなイメ−ジである。 /etc/resolv.conf named ------- ------- ------- |hostA| |hostB| |hostC| ------- ------- ------- |ec0 | | ----*-------------*---------*------- % tcpdump << root で実行すること。 % ping hostC.nix.co.jj << 先ず hostC.nix.co.jj のＩＰアドレスを調 べるため hostB の named に問い合わせる。 hostA % tcpdump tcpdump: listening on ec0 10:51:20.076200 hostA.1100 > hostB.domain: 1+ (37) hostB の named に尋ねる。 10:51:20.080096 hostB.domain > hostA.1100: 1* 1/0/0 (53) hostB の named から返答。 10:51:20.114082 arp who-has hostC tell hostA 10:51:20.114455 arp reply hostC is-at 8:?:??:?:??:?? ＭＡＣアドレスを得る。 10:51:20.114508 hostA > hostC: icmp: echo request やっと ping をしている。 | hostA % tcpdump -n << ＩＰアドレスで表示する場合。 tcpdump: listening on ec0 10:47:40.169676 192.9.200.6.1099 > 192.9.200.2.53: 1+ (37) 10:47:40.173684 192.9.200.2.53 > 192.9.200.6.1099: 1* 1/0/0 (53) ２回目はもう 10:47:40.195109 192.9.200.6 > 192.9.200.5: icmp: echo request ＭＡＣアドレス 10:47:40.195557 192.9.200.5 > 192.9.200.6: icmp: echo reply を知っている。 | ※/etc/resolv.conf のレゾルバと named デ−モンで、 どの UDP ポ−トを使っているか よく分からなかった。上記の通りレゾルバ側、DNS のクライアントは 1024 からの任意 ポ−トを、named デ−モン、DNS のサ−バ側は 53 番を使っていることが判明した。 * tcpdump コマンドの使い方 % tcpdump -i ec1 << ゲ−トウェイ構成の場合インタ−フェ−スを指定する。 % tcpdump tcp << TCP パケットだけを見る。 % tcpdump tcp port ftp << TCP パケットの ftp アクセスだけを見る。 % tcpdump tcp or icmp << TCP と ping の ICMP を見る。and 指定ではない。 % tcpdump src 192.9.200.1 << 発信元が 192.9.200.1 アドレスだけのパケットを見る。 % tcpdump src 192.9.200.1 and not tcp port telnet << 上記かつ telnet を除く。 % tcpdump -n dst 192.1.1.1 << 宛先が 192.1.1.1 のパケットだけをアドレスで見る。 % tcpdump -x << 流れているパケットの中身を全て１６進で表示する。 [ イ−サネットの口のイメ−ジ ] パケットの中には発信元と宛先のＩＰアドレスが書かれている。実際に流れているのはイ −サネットのフレ−ムである。ＩＰレベルでは、ＭＡＣレベルの包みをはがして、中のデ −タを見る。 ---------------- | ホスト | | | | ○ | ---- ---- | ★ | ホストは ＝ ここで自分宛のパケットか見 ec0| ↑↓| ている。自分宛ならケ−ブルから取り込む。 -------*＝＝＝＝*----------------- ↑↓ 色々なパケットが流れている。ここで ＝ パケッ <-- ★ ○ ● ◎ ◇ --> トの全部の様子を見るのが tcpdumpであり、RMON プロ−ブである。ガラス張り越しに覗くイメ−ジ。 --------------------------------- * おまけ Solaris 2.x の snoop # snoop -d le0 le0 インタ−フェ−スを流れる全てのパケットを見る。 # snoop -d le0 port 80 ともかく往来する 80 番ポ−トのパケットだけを見る。 # snoop -d le0 ! port 80 80 番ポ−ト以外のパケットを見る。 # snoop -d le0 ! port 80 and ! port 53 80(HTTP),53(DNS) 以外のパケットを見る。 # snoop -d le0 udp port 53 UDP の 53 番ポ−トのパケットだけを見る。 # snoop -x 0 src 192.168.1.1 192.168.1.1 からのパケットを１６進で表示する。 # snoop -r ＩＰアドレスをホスト名に変換しないようにする。 * Solaris 9 の snoop コマンド Solaris 9 の V210 でコマンドを叩いた。bge0 は V210のインタ−フェ−スの名前。先ず は telnet をやってみた。TELNET はポ−ト番号 25 ということ。表示は tcpdump よりか なり分かりにくい。おまけに、例えば port 53 を指定して DNS パケットを見ると DNSの 問い合わせの発信元ポ−ト番号がなぜか出て来ない。# snoop -r -V -d bge0 port 53 の ように -V オプションを指定すると細かい表示が出て来る。/usr/sbin/snoop である。 # snoop -d bge0 src 192.168.1.1 Using device /dev/bge0 (promiscuous mode) 192.168.1.1 -> 192.168.1.2 TELNET C port=1092 192.168.1.2 -> 192.168.1.1 TELNET R port=1092 Using device /dev/bg # snoop -r -d bge0 ! port 23 Apollo から Sun に telnet して実行。telnetのパケ Using device /dev/bge0 (promiscuous mode) ットを除いて表示してみた。 192.168.1.1 -> 192.168.1.3 TCP D=2161 S=3305 Push Ack=.. Seq=.. Len=25 Win=16132 192.168.1.3 -> 192.168.1.1 TCP D=3305 S=2161 Ack=.. Seq=.. Len=0 Win=49388 (4) MRTG の概要とコンパイル '02/04 * MRTG( Multi Router Traffic Grapher )の概要 内部ネットやＷＡＮにどれだけパケットが流れているか、つまりトラフィックを長期的に 計測するためのフリ−ソフトである。９７年頃から使われ始めたようである。インタ−ネ ットの検索サイトで MRTG と引くと、大学なんかで MRTG を使ったトラフィックのグラフ がたくさん出て来る。１日、１週間、１ヵ月、１年のグラフが一つのＷＷＷ画面に出てい る。なんとなくインタ−ネットへのアクセスが遅い、じゃＷＡＮの回線速度をアップしよ う。内部ネットもレスポンスが悪い、じゃレイヤ３スイッチを入れよう。そんな単純なこ とでお金が出れば誰も苦労はしない。ネットワ−クのインフラを増強するには、それなり の客観的な資料を上司に提供する必要がある。 MRTG はそんな基礎デ−タに使える。イン スト−ルは少しめんどうだが、利用する価値は十分あると思う。 MRTG 日本語サイト− http://www.ceres.dti.ne.jp/~riocat/webtools/mrtg/ MRTG ソフト − http://ee-staff.ethz.ch/~oetiker/webtools/mrtg/pub/ GD ライブラリ − http://www.boutell.com/gd/ 現時点のバ−ジョンは '02/02/06 リリ−スの 2.8.12 である。 ここでは INDY IRIX 5.3 にインスト−ルしてみた。幾つかソフトを関連してとってきてコンパイルしなければなら なかったが、案外すんなり作業は終わった。MRTG の仕組みは、観測ポイントに SNMPのプ ログラムを置いておきデ−タを収集し、それを MRTG プログラムが回収してグラフ表示す る。観測ポイントの SNMP プログラムは SNMP エ−ジェントといい、収集するデ−タは具 体的には MIB デ−タである。ル−タにはあらかじめ、SNMP エ−ジェント機能が入ってい る。ＥＷＳにもあるようだが、入ってなければフリ−ソフトの UCD-SNMP なんかが使える。 それに MRTG は基本的にはトラフィック計測だが、SNMP ゆえに CPU やディスクの利用率 なんかも、ちょっといじることにより計測できる。 さて実際社内ネットワ−クに MRTG を適用してみた。SNMP のエ−ジェントは、 社内のパ ケットがインタ−ネットに向かう際に通過する、Cisco2514 のロ−カル・ル−タにしてみ た。数十台のパソコンがＷＷＷアクセスしたり、 メ−ルサ−バに定期的に POP アクセス している。ＷＡＮ用ル−タのランプは、結構ピカピカやっているという状態だ。さて、こ れでどれだけのトラフィックになっているのか。グラフは最新のが左側から出てきて、右 へ移動していく。グラフの縦の目盛はＭＡＸに合わせて勝手に変わる。 MRTG デフォルト の設定通り、５分間隔で計測。それが意外や意外、ＭＡＸでもたったの 20 しかない。一 日見ただけなので何ともまだ言えないが。これじゃＷＡＮ回線アップ必要なし。市販のト ラフィック計測ソフトでもやってみる必要があるかも。 * ソフトの入手と展開 << INDY IRIX 5.3 に入れる >> % perl -v << Perl は 5.004_4 以降のこと。 This is perl, version 5.004_04 built for IP22-irix http://ee-staff.ethz.ch/~oetiker/webtools/mrtg/pub/mrtg.tar.gz % zcat mrtg.tar.gz | tar xvf - << mrtg-2.8.12 と展開された。 http://www.boutell.com/gd/http/gd-1.7.3.tar.gz % zcat gd-1.7.3.tar.gz | tar xvf - << なぜか gd-1.8.1 と展開された。 http://www.cdrom.com/pub/infozip/zlib/zlib.tar.gz % zcat zlib.tar.gz | tar xvf - % mv zlib-1.1.3 zlib % ftp ftp.iij.ad.jp << MRTG の READMEによると ftp://swrinde.nde. ftp> site index libpng swri.edu/pub/png/src からとって来るとあっ ftp> cd pub/GNU/ghostscript たが ftp アクセスできなかった。それで IIJ ftp> get libpng-1.0.2.tar.gz を探してみた。 % zcat libpng-1.0.2.tar.gz | tar xvf - % mv libpng-1.0.2 libpng * コンパイル % cd /usr/local/source;ls -F << 関係するソフトだけ示した。 グラフの画像は zlib/ libpng/ gd-1.8.1/ mrtg-2.8.12/ GIF でなく PNG 形式で表示する。GIF は特許 が取られていて少し問題になっている。 特許 % cd zlib をもっているのは確かユニシスだったか。 % ./configure % make % cd libpng % make -f scripts/makefile.std CC=gcc ZLIBLIB=../zlib ZLIBINC=../zlib | ranlib libpng.a << ranlib コマンドがないと警告が出るが、無視してよい。 % cd gd-1.8.1 % make INCLUDEDIRS="-I../zlib -I../libpng" LIBDIRS="-L../zlib -L. -L../libpng" LIBS="-lgd -lpng -lz -m" % cd mrtg-2.8.12 % ./configure --with-gd=../gd-1.8.1 --with-z=../zlib --with-png=../libpng % make [ できた MRTG の内容 ] % cd /usr/local/source/mrtg-2.8.12;ls -F ANNOUNCE Makefile config.log doc/ translate/ CHANGES Makefile.in config.status* images/ ← アイコン COPYING README configure* install-sh* COPYRIGHT UPGRADING configure.in run/ MANIFEST config.cache contrib/ src/ ping の結果を MRTG で表示する mrtg-ping-probe。contrib/ping-probe ディレクト リはあったが中身はなかった。 % ls -F run BER.pm cfgmaker* indexmaker* rateup* SNMP_Session.pm cfgmaker_ip* locales_mrtg.pm SNMP_util.pm cfgmaker_phys mrtg* * MRTG の入れ直し `26/02 INDY に MRTGをインスト−ルしてかなりの年数が経った。数年前に入れた外付けのディス クが壊れてそれきりにしていた。/usr/.. に入れたことにしているが、実は /usr1/.. に 入れていたのだ。MRTG は別なマシン Linux で新しいバ−ジョンでもって動かしてもいる。 これは実際のネットワ−ク監視に稼働させている。今回、テスト用で必要に迫られてトラ フィックを見たいことがでてきた。それで改めてインスト−ルしてみたのだ。残っていた のは perl5.004_04 だけ。他は /usr1/.. で消えてしまっていた。 http://www.mrtg.jp/ MRTG 公式日本語サイト、最終更新日(2002.08.06) を見て最新、２００６年２月９日時点 mrtg-2.13.2 を入れてみることにした。 ほかのは gd-1.8.4.tar.gz, zlib-1.1.4.tar.gz, libpng-1.0.2.tar.gz である。それぞれ展開して以下のようなディレクトリにした。 % ls -F /usr/local/source libpng/ mrtg-2.13.2/ zlib/ gd/ % ./configure --prefix=/usr/local/mrtg --with-gd=../gd-1.8.4 --with-z=../zlib % make --with-png=../libpng % make install << 一応コンパイルはできたのだが。 % cd /usr/local/mrtg; ls -F bin/ lib/ share/ << bin/ に cfgmaker, indexmaker, mrtg, rateup。 % cd bin % ./cfgmaker ns50@192.9.200.2 > local.cfg Perl 5.005 required--this is only version 5.00404, stopped ..MRTG_lib.pm line 18. BEGIN failed--compilation aborted at ./cfgmaker line 49. % ./cfgmaker ns50@192.9.200.2 > local.cfg << perl5.005_04.tar.gz を取ってき SNMP Error: てコンパイルした。96% 成功で残 no response received りエラ−が出たが一応やってみた。 | 結果だめだった。 最初に戻って、うまく行った時の組み合わせに近いものにしてやってみる。 mrtg-2.8.12 を探して取ってきた。 ftp.iij.ad.jp://pub/lang/perl/CPAN/src/5.004_05.tar.gz から 5.004 代の Perl を取ってきた。これで cfgmaker をやっと丸１日掛かりで動かすことが できた。ns50 というのは NetScreen の SNMP の名前である。 * 参考 「UNIX MAGAZINE」 1997/12, P.38〜44 "倉敷芸術科学大学のネットワ−ク構築 20、MRTG"。 > 実際の設定の参考にした。ただし、今は rateup コマンドはやらない。 「日経コミュニケ−ション」 2000/04/17, P.82〜87。 > 無償ネットワ−ク管理ツ−ルの実用度。MRTG を皆使っているよん。 T.J.Tracer ネットワ−ク監視ソフト。2000/03/01。(株)ワイ・ディ・シ−販売。 > http://www.ydc.co.jp/、Windows/NT １５万円。お試しダウンロ−ドあり。 UCD-SNMP フリ−の SNMP エ−ジェント・ソフト。 > http://ucd-snmp.ucdavis.edu/、SNMP は CPU 負荷やディスク使用率も計測できる。 「UNIX MAGAZINE」2002/11,"ＵＮＩＸ便利帖(1)ＭＲＴＧ",P.78〜83。インスト−ルの説明。 > 2002/12,"ＵＮＩＸ便利帖(2) ＭＲＴＧ",P.85〜90。オプションの説明が詳しい。 「UNIX MAGAZINE」2000/10, P.83〜88, "DAEMONS&DRAGONS トラフィックの監視、認定をめ > ぐる議論"。１日のグラフは５分間隔の平均、１ヶ月のグラフは２時間の平均。 本書の "3-6. ネットワ−ク運用の履歴, (4)実際の運用いろいろ, ファイアウォ−ル・ホ ストでのトラフィックの計測" も参照のこと。 (5) MRTG でトラフィックを計る '02/04 * MRTG を設定する Cisco 2514 ル−タに telnet アクセスし、SNMP デ−モンを稼働させる。 ----------------- ｜192.9.201.1 INDY Cisco □ □ mrtg daemon ｜192.9.200.2 ｜ ------------------------------ $ telnet 192.9.200.2 User Access Verification Password: henomo << これらは cisco1>enable Password: kato << 適当です。 cisco1#conf Configuring from terminal, memory, or network [terminal]? t cisco1(config)#snmp-server ? << 設定できるコマンドの一覧を見る。 access-policy Define an SNMPv2 access policy (acl) chassis-id String to uniquely identify this chassis community Enable SNMP; set community string and access privs contact Text for mib object sysContact context Define an SNMPv2 context enable Enable SNMP Traps or Informs host Specify hosts to receive SNMP TRAPs location Text for mib object sysLocation packetsize Largest SNMP packet size party Define an SNMPv2 party queue-length Message queue length for each TRAP host system-shutdown Enable use of the SNMP reload command tftp-server-list Limit TFTP servers used via SNMP trap-authentication Send TRAP messages on receipt of incorrect community string trap-source Assign an interface for the source address of all traps trap-timeout Set timeout for TRAP message retransmissions view Define an SNMPv2 MIB view cisco1(config)#snmp-server community public ro << ro を付けること。その場で 有効になり、SNMP エ−ジェ ントとして働くようになる。 [ INDY での mrtg の設定 ] % cd /usr/local/source/mrtg-2.8.12/run % ./cfgmaker public@192.9.200.2 > local.cfg << このコマンドで MRTGの制御 ファイルを作成する。 % cat local.ok 1:public@192.9.200.2 = Ethernet0 << local.cfg の他にできたファイル。 ル−タな 2:public@192.9.200.2 = Ethernet1 どのアドレスが２つある。local.ok ファイル は % mrtg local.cfg をやるとできるはず。 local.cfg --------------------------------------------- |# Add a WorkDir: /some/path line to this file |WorkDir:/usr/local/source/mrtg-2.8.12/run/data << この一行を追加すること。 |#IconDir: /MRTG/ << MRTG の HTML 表示用アイコンの GIFファイルがある場 | | 所。ここでの設定は指定しなくても問題なかった。 % mkdir data << とりあえず計測デ−タを run/data に作る。 デフォル トでのディレクトリ名は data。 % ./mrtg local.cfg << ル−タでは Rateup WARNING が８個でる。 % ./mrtg local.cfg << ル−タでは Rateup WARNING が２個でる。 % ./mrtg local.cfg << 何もでない。これで設定ＯＫ。 /var/spool/cron/crontabs/root -------------------------------------------------------------------------------- | | |0,5,10,15,20,25,30,35,40,45,50,55 * * * * /usr/local/source/mrtg-2.8.12/run/ | 上からの続き mrtg /usr/local/source/mrtg-2.8.12/run/local.cfg % /etc/init.d/cron stop << 一応念のため cron をリスタ−トする。 やらなくても % /etc/init.d/cron start root ファイルに記述しただけでも動いているようだが。 % crontab -l << これで確認もしておく。root ロッグインしてやること。 ※後に確認したところ root ファイルに記述しただけでは有効にならない。cron stop と cron start をやらないといけない。crontab -l は単に root ファイルの記述を表示す るだけである、クロ−ンのスクリプトが有効になっているかどうかは関係ない。`2a/11 * MRTG の出力をブラウザで見る 時たまグラフの見方で、どっちが IN で OUTだったか分からなくなる。 対象機器に mrtg コマンドをかけた位置によって IN/OUT が決まることになる。その方向性が、ちょっと小 生は直感的でないような気がする。これについては末尾でも再調査した `2f/07。 ：外へ ： -------------------------- IN | OUT --↓---*--↑--- | | mrtg --↓---*--↑--- INDY □ % cd /usr/local/source/mrtg-2.8.12/run/data OUT | IN ｜ % netscape . ------------------------------ data ディレクトリに 192.9.200.2.1.html といったファイルができている。 ここではル −タを対象にしたので、パケットの IN/OUT グラフを反対にした 192.9.200.2.2.html も ある。ともかくそれをクリックするとグラフ表示した画面がでてくる。５分毎にＷＷＷ画 面がべろっとなって、更新されるかに見えるが更新されない。更新するには HTML ファイ ル２つともクリックし直さないけないみたいである。このデ−タをＷＷＷサ−バにおけば、 どこからでもＷＷＷブラウザでグラフを見ることができるわけだ。ＷＷＷサ−バにデ−タ を置くには、mrtg-2.8.12/images/ もコピ−しておくこと。これはＷＷＷ画面のアイコン 用らしい。さてグラフの見方だが。夜中の分も含めて平均を出してもらっても困る。それ に部分的に詳細に見ることもできないようだ。皆がよく使う日中の時間帯でどうかという のを見たいわけなのだ。 あや、だいぶ勘違いしてた。先にＭＡＸでも 20 しか出てないと書いたが、単位を勘違い してたのだ。20 は 20 Kbps だと思い込んでいたが、 グラフの縦軸は Bytes per Second だった。ネットワ−クの速度の単位は bps である。ここしばらくグラフが、16.2 のメモ リのすぐ下で細かくぎざぎざが出ていた。何でこんな所でぎざぎざになる？。ＷＷＷ画面 に出ている Cisco 2514 の Max Speed 1250.0 kBytes/s というのもおかしい。 ロ−カル ル−タは 10 Mbps でないのか。これら８倍して単位を bps に合うようにしたらつじつま が合った。16.2 は 129.6 Kbps、1250 は 1250x8 = 10000 Kbps = 10M bps となる。とい うことは 16.2 でぎざぎざが出ているということは、すでに回線 128 Kbps の帯域一杯を 使っているということになる。 ここで新たな疑問が。ＷＡＮ用ル−タで 128 Kbps なら 128 Kbps 一杯出るものだろうか。 ＷＡＮ用ル−タを詳しく見れば、だいぶパケットのロスが出ているのだろうか。残念なが らこのル−タはプロバイダのレンタルでパスワ−ドを教えてもらってないので、 SNMP の 設定ができないのだ。しかしどうもおかしいと思った。ＷＡＮ用ル−タが一番ピコピコし ている昼からの時間で、ＷＷＷアクセスのレスポンスが返って来ない時がよくある。そん な時でも MRTG のグラフは 10 ぐらいでしかない。そんなことないよな−と思っていたの である。これで納得した。おまけ、ＭＡＸの値につれてグラフのメモリが大きくなるとい う話。local.cfg で Maxbytes という変数で最大値を指定できる。これ以上のトラフィッ クは無視する。AbsMax というのもあって Maxbytes 以上の値も受け付けるというもの。 ※MRTG のグラフには平均やＭＡＸの値が何％とか出ている。 ただし制御ファイルをきち んと設定しないとおかしな値になってしまう。 Max 1.5%、Average 0.2% とか出ていて 変な値だな−とずっと思っていた。皆さん気を付けられたい。 * MRTG の cfgmaker の出力を見る % ./cfgmaker public@192.9.200.2 # Add a WorkDir: /some/path line to this file ###################################################################### # Description: Cisco Internetwork Operating System Software IOS (tm) 2500 # Software (C2500-I-L), Version 11.2(11), RELEASE SOFTWARE (fc1) ... # Contact: # System Name: cisco1 ん？、Cisco のロ−カル・ル−タって 1.25 Mbps しか # Location: 出んのか。違う違う bps の単位でなくて kbytes/sec。 #..................................................................... Target[192.9.200.2.1]: 1:public@192.9.200.2 MaxBytes[192.9.200.2.1]: 1250000 << 最大 160 Kbps だと 20000(20 kBytes/s)。 Title[192.9.200.2.1]: cisco1 (No hostname defined for IP address): Ethernet0 PageTop[192.9.200.2.1]:

Traffic Analysis for Ethernet0

↑ ここ注意
System:cisco1 in
Maintainer:
Interface:Ethernet0 (1)
IP:No hostname defined for IP address (192.9.200.2)
Max Speed:1250.0 kBytes/s (ethernetCsmacd)
#--------------------------------------------------------------- Target[192.9.200.2.2]: 2:public@192.9.200.2 MaxBytes[192.9.200.2.2]: 1250000 Title[192.9.200.2.2]: cisco1 (No hostname defined for IP address): Ethernet1 PageTop[192.9.200.2.2]:

Traffic Analysis for Ethernet1

ここ注意 ↓
System:cisco1 in
Maintainer:
Interface:Ethernet1 (2)
IP:No hostname defined for IP address (192.9.201.1)
Max Speed: 1250.0 kBytes/s (ethernetCsmacd)
↑ (1250.0 x 1000 Bytes/sec) x 8 bit = 10 Mbps * SNMP エ−ジェントが働いてない場合 Cisco のル−タだが、電源を気なしに入れ直してから、 MRTG のデ−タが更新されなくな った。cisco1# write mem をやってなかったので、 SNMP エ−ジェントの設定が消えてし まったのだ。その時、mrtg コマンドかけたらこんなんが出た。 あるいはル−タの電源が 入ってなかったりしてアクセスできなかった時も、このように出る。 [192.9.200.2].161 はル−タのＩＰアドレスが 192.9.200.2 で、 SNMP の標準ポ−ト 161/UDP にアクセスし たことを示している。 % ./mrtg local.cfg SNMP Error: no response received SNMPv1_Session (remote host: "192.9.200.2" [192.9.200.2].161 community: "public" request ID: 860099027 PDU bufsize: 8000 bytes timeout: 2s retries: 5 backoff: 1) SNMPGET Problem for ifInOctets.1 ifOutOctets.1 sysUptime sysName ifDescr.1 on public@192.9.200.2 SNMPGET: Failed to reach target: "1:public@192.9.200.2". I tried multiple times! public@192.9.200.2 [ MRTG の肝心なこと ] MRTGはコンピュ−タやネットワ−ク装置のインタ−フェ−スを出入りするパケットの量を 見ているだけである。ifconfig -a で出て来るイ−サネットの口を出入りするパケットの 数である。MRTG は対象コンピュ−タの SNMPエ−ジェントにリクエストして、その答えを もらう。上の ifInOctets.1 と ifOutOctets.1 がそれである。SNMP の MIB ツリ−のOID で、interfaces グル−プの中に定義されている情報である。下記の数字羅列の最後の .n は、コンピュ−タのイ−サネットのインタ−フェ−スの番号やスイッチングハブのポ−ト 番号ということになる。１つしかインタ−フェ−スがなければ n は 1 である。 1.3.6.1.2.1.2.2.1.10.n 受信したすべてのオクテット数（バイト数） 1.3.6.1.2.1.2.2.1.16.n 転送したすべてのオクテット数（バイト数） 1 3 6 1 2 1 2 2 1 10 インとアウト 16 iso.org.dod.internet.mgmt.mib2.interfaces.ifTable.ifEntry.ifInOctets ifOutOctets * MRTG のイン／アウトについて ｜ ↑OUT MRTGのグラフの見方で IN と OUTがどっちからどっち □ ■MRTG なのか分からなくなる時がある。MRTGの位置で判断す ｜ ↓IN ｜ る。一つおまけ、MRTGのグラフの１つだけ画像キャプ --------------------------- チャするには。パソコンの画面全体は PrintScreenを ｜ ↑IN 押して張り付けで。Windows の画像部分のキャプチャ □ は、一番手前に表示されている画面になるが、これは ｜ ↓OUT Alt+PrintScreen で取ることができる。 * またまた MRTG のイン／アウトについて `2f/07 どうも IN と OUT のこと、また分からなくなってしまった。すぐ上の "MRTG のイン／ア ウトについて" の内容と、これより先に自身で書いた "* MRTG の出力をブラウザで見る" と説明が異なってしまってないか。もう一度 MRTG のこと調べた。 MRTG ソフトの位置は 関係ないのでないか。 MRTG ではなく SNMP ソフトが動いている装置に対して入って来る パケット、出て行くパケットをみるということでないのか。 --------- 先ずは Linux マシンに SNMPソフトを入れて稼働させ | Linux |SNMP てインタ−フェ−ス(a) を出入りするパケットの数を | (a) |ソフト MRTGソフト 計測する。そのデ−タを MRTG ソフトが取りに行って ----*---- ■ Linux グラフを作成する。下図はインタ−ネットヘのアクセ IN↑| ↓OUT ｜マシン スで、社内から外のＷｅｂへのアクセスの応答パケッ ------------------------- ト、入ってくるパケットの方が一般的に多い事を示す。 インタ−ネットへ | ／＼ ／＼OUT (a)を対象にしたMRTGグラフ。 ： b|／ ＼／ ＼ ------------------- p| ＿＿＿／＼＿＿ OUT↑| ↓IN s|／ IN ----*---- ------------------------> time | (b) |SNMP | Router|ソフト | ／＼ ／＼／ IN (b)を対象にしたMRTGグラフ。 | (a) | MRTGソフト b|／ ＼／ ----*---- ■ p| ＿＿＿／＼＿＿ IN↑| ↓OUT ｜ s|／ OUT ------------------------- ------------------------> time