HrsTのあれこれ

  ネットワーク機器はログという機能が備わっているけど、意外と再起動すると消えてしまう物が多い。 RAM上に記録するので当然なんだけど、結構これが困った仕様なんだよね。 たとえば再起動を繰り返す不具合が発生したとき、Telnetやコンソールを使ってログにアクセスが難しいくらい短時間で再起動しているとみることはできない。 だけど、もしかしたらログに再起動の原因となっているエラーが記録されているかもしれないよね。 だから、こういう時に備えて、Syslogサーバにログを転送するようにしておくことが重要。 これなら、たとえ短時間で再起動を繰り返していても、Syslogサーバにエラーログが記録されている可能性がある。 再起動を繰り返すNW機器とにらめっこせずに、ゆっくりSyslogサーバのログを読めばいいのだから、とっても楽だよ。 でも、一つ問題があって、Windowsの場合、無償でサービスで動作するSyslogサーバの選択肢がないってこと。

  日頃、上司や一般の方にネットワークの話をするとき気を付けている「できるだけ専門用語を使わない」は無駄な努力では？と思うことがあります。 慣れない言葉で説明するほうが相手を混乱させてしまうことがありました。 こちらがわかりやすいようにと専門用語を避けると、余計にわからなくしてしまうのです。専門用語を使うとその単語が意味わからず名詞として聞き流せるけど、理解できる言葉で説明されると、NWに関する基礎知識がないと言葉は理解できるけど内容はさっぱりという状態になってしまいます。 また、説明する側も慣れていない言葉を使うので、うまく説明できずに墓穴を掘ってしまうのです。 だから、話をするときに気を付けるのは、専門用語をうまく使う。 悪い言い方だと、適度に専門用語を使って煙に巻く。ごまかす。 専門家が素人に専門分野を短時間で理解させるなんて無理なんです。 もし、理解できればその部分において専門家はすでに不要。 相手に理解させる部分は専門分野ではなく、目的と費用と作業概要です。 詳細説明は添付資料にするくらいが丁度よい。 もし、相手が添付資料の説明を求めてきたら、「うまく説明できないかもしれない」といってから、相手が納得するまでとことん付き合いましょう。墓穴を掘る可能性も高いですが・・・熱意は伝わると思います。

  ネットワーク間の接続を行う際に設定するのはルーティングテーブル。これを固定にするかダイナミックにするかは、規模や機能や管理者のポリシーなどです。 この設定を間違えると「繋がらない」や「ループ」といったトラブルにつながります。 でも、ルーティングテーブルはトラブルが起きても修正すればOKだし、設定が間違っていなければ恒久的に安定運用ができるはずなんですよね。（たまに問題が発生するけど・・・） で、タイトルのARPテーブルってやつなんですが、基本的に自動学習です。 一応固定で書けるけど、書くシチュエーションが思いつきません。学習した情報を見ることはよくあるのですが・・・ でね、この自動学習ARPテーブルが曲者なんですよ。 とくに、トラブル時にIPアドレスを持った機器を交換した時に繋がらないってなります。なんでか？それはARPテーブルに新しい機器が登録されないから。で、なんで～～って騒いでいたら自然回復（ARPテーブルが更新された）。 とか、うまく更新されずにず～～～っと接続できないとか・・・ 一番困ったのはNW機器の管理範囲外のARPテーブルを更新してほしい時。こっちは原因がわかっているのでARPテーブルの更新を依頼しても答えは「NO」。絶対にダメなんだって～。まぁ、普通だったら数分待てば更新されるはずなので待ってても一向に学習されない。結局IPアドレスを別のに変更した経験があります。

  ネットワークトラブルが発生したときどうするか？ 復旧を優先し、原因究明手段を捨てる 原因究明を優先し、復旧を遅らす 大きく分けると、この2つになると思います。 ユーザーからすればさっさと復旧してほしいという思いが一番だと思うのですが、ネットワーク管理者としては、再発防止、適切な対応をする必要があり、復旧作業と合わせて状況把握、原因調査を行いたいと思ってしまいます。 おそらく機器の再起動、交換で治ってしまうことがほとんどだと思いますが、再起動するとログが消えてしまったり、カウンタがリセットされるなど、原因調査や報告書作成が困難になることがあります。 そのため、原因究明を行うと必然的に復旧が遅れてしまうのです。 そんな時に役立つコマンドは機器によって違いますが「Show Tech」です。 このコマンドはいくつかのステータス表示コマンドを一つで実行可能な便利なコマンド。 再起動や交換をする前に、このコマンド実行する時間くらいなら用意できると思います。 あとは、Telnetなら操作ログを残しておく。 あとから見直すのは醜いですが、あとからあのタイミングではどうだっただろう？なんて時系列を追いたくなった時は意外と役立ちます。Web設定だと難しいですけどね。 私がおすすめするトラブル時にやることは、操作ログを記録する。Show Techコマンドをとる。そして再起動で治りそうならさっさと再起動してしまう。 ユーザは一秒でも早い復旧を望んでいるのですから・・・ 　それに応えるのが、ネットワーク管理者だと思います。

  NMS(Network Management System)って何？ 　ネットワーク上の機器に対してPingやサービス死活、状態を監視、記録してくれるとっても便利なシステムです。 しらない・・・って人はとりあえず TWSNMP をググれ！！ ExPing とかで死活監視をしている人もいるかもしれないけど、それだったらTWSNMPを導入したほうが良い。 何がいいって、NW図で監視できるって便利じゃない？NW図に表示されたノードに問題が発生したら、そのノードが点滅して教えてくれるから、上司に「ここが問題なんですよ」ほら光ってるでしょっていうと「なるほど～」って納得してくれるので、説明に時間がかからない。 あと、Pingだけでなく、DNSやDHCP、HTTP、FTP、SMTPなどサービスレベルの監視ができるので、ExPingでは見逃していた問題も発見できる。 ただ、NMSってピンきりで無償のTWSNMPから HP Network Management Center など高価なものまで色々。 私のお勧めは、見た目が良くて比較的安価な NetCrunch 。 知らない人にとっては見た目がとっても重要みたいで、TWSNMPで十分だったのに、こんなしょぼい画面だと使い物にならないって決めつけられてしまいました。 HP NNM だってこんな画面ですよ。見た目じゃないし～って紹介したらこれも だめ！！ だって・・・たぶん、導入実績No.1だと思うのですが・・・ TWSNMPの気に入っている機能。それはインタフェースの状態によってノード間を接続している線が点滅してくれるので、ポートより先のエラーが可視化できるため、SNMP対応機器に接続しているSNMP未対応機器まで監視できること。監視対象がちょっと広くなります。 多くのシステムはポートレベルまで監視はできるのですが、いまいち表現力が低いんですよね～