1, タイトル: ネットワークにおける経路の安定性について
2, ロガー  樽井行保 (インターネットマルチフィード)
3, 発表者  永見健一 (インテックネットコア)
4, 時間  2003年7月24日  14:00-14:30

5, 発表の焦点、論点、議題

現在のネットワーク監視は主にSNMPやICMPを用いて到達性を確認することが
多い。これらで確認できる項目は、ルータやリンクのup/downであり、経路に
関する項目をリアルタイムに把握することは難しい。
しかし、経路制御プロトコルの制御パケットを観測することで経路の動きを
知ることができる。今回はOSPF制御パケットの観測結果について報告する。
また、経路の安定性とその監視についてオペレータの方から見た経路監視に
関する要望を議論したい。


6, 発表の流れ

現在のツール紹介
     SNMP、ICMPがあるが、これらは万能ではない。制限(しばり)あり。
     ポーリング間隔の間に発生したことは検知不能。
     MIBであれば、標準、エンタープライズのみに限られる。

OSPF経路制御プロトコルを監視してみた。

まず、OSPFの特徴の復習。
     OSPFはBGPと異なり、ネットワークのトポロジ情報を全て持っている。
     よって、1つのルータを見ていれば、エリア全ての状況を把握できる。
     どんなに遠くても手前のリンクを覗いておけば link down 等、検知可
     能。

測定方法、完了を紹介
     今回は1つのリンクにPCをつないでpassiveに測定。
     実網に影響を与えないよう測定。
     ルータ50台程度のネットワーク。

グラフを見る前に注意点。
     このネットワークが不安定だと言うのではない。
     OSPFのフラップ数を見せるのみ。
     数値には計画工事等、予期されたものも含んでいる。
     計画工事外でカウントできるものが重要である。

OSPFのLSAフラップ数
     5月中より昨日までのデータ。1日毎のサマリデータになっている。
     変化点は経路が落ちたり、トポロジー変化が起きたことを意味する。

緑はEtherリンクの変化、
     ネットワークは生き物なので、それなりにフラップしている。
     area ボーダは30回程度フラップした日もある。
     1回くらいしか落ちない安定した日もある。

フラップの原因。
     具体的な解決策が分かっているもの。

     CiscoとJuniperがマルチベンダで存在するネットワークは、数日に1回
     程度、ルータLSAが消える。ただし、数msというオーダで回復する。
     JuniperのLSRefreshTimeがRFCで書いてあるものと異なる値を使って
     いる。これは、RFC違反ではない。
     一部のIOSでLSAを消してしまう。改修ソフトウェア(IOS)あり。

     原因を突き止め、6月頭に対処した後はフラップしていない。

発表者より逆に質問
     運用、設計、トラブルシュートをしている皆様へ
     現状ツール(SNMP)の他にあるとうれしい情報、また、他に監視できると
     役立つものは無いですか？  無いものは開発することも検討する。


■質疑応答

矢萩 (e-access)
  検証したネットワークのOSPFのneighbor数と、ルート数は？

     A, ルート数は1000程度。neighbor数は10以下。4から5程度。

  ルート数、neighbor数で安定度を計るのも重要では。
  ルート数によっては30分に1回なりDBのフル更新をした時、追いつかなくなる
  ルータがあり、それに起因してフラップするという、ラボでの検証経験あり。

  show ip ospf database に乗っているエントリーをあわせて見ると良い。

     A, database は 1193


水越 (OCN)
  ほしいもの。

  (OSPFに限らないでよいとい前提で)
  運用サイドとしては「タイムマシーン」がほしい。
  例えば、昨日おかしかったという問い合わせの時、過去データをトレース
  できる仕組みが欲しい。

  unreachになっていたとき、経路が消えていたのかノードが悪かったのか、
  参考にできるもの。

  経路の生き死にだけではなく、実際にパケットが届いているかどうか、
  delay, jitter を図る仕組みが必要。最近は real time アプリケーション
  のユーザからの苦情が多い。

  OSPFであれば、1台で全て見えるが、BGPだと、ネットワークのどこで、
  dumping しているのか、というところまでは見れない。


麻野 (富士通)
  LSAデータが消えるというのは routing table から本当に落ちているのか、
  フォワーディングに影響はあるのか？

     A, 実網でルータへのアクセス権限がなく、実際にどうなっているかは
        未確認。
        松崎氏(IIJ)からフォワーディングに影響があったと、あとで報告あ
        り。


河野 (Cisco)
  コンバージェンスをIGP(OSPF)でアグレッシブにやりたいという野望あり。

  先ほどのIOSのバグの話、30分というのは多すぎるという説はあり。
  最近のIOSは stable link ならやめてしまえ、という実装になっている。


中原 (NEC)
  遠くのAS(Europeあたり)に、私(NEC)の経路をアナウンスされた。
  その結果、同AS内でも一部のところは通ったり、通らなかったりした。

  外部の人にメールで経路がどうみえているかバンバン聞きまくった。
  4ヶ月程度、そういう状態だったらしい。

  自ASの外からの監視システムがあまりなかった。
  ルートサーバ、IRRが解決策になるのかなという印象。

     A, このコメントには、2つポイントあり。検知方法と解決策の切り口。
        解決策は難しいかな。
        お客様の申告前にdetectする方法。


近藤 (Intec Netcore)
  経路を投げつけられたという場合、IRRを使い調査するのは基本的にOK。
  IRRを元にフィルタを書くべきなんだが、世の中あんまり広がっていない。
  私はIRR推進派。なかなか難しいかな。という単なるコメント。


松崎 (IIJ)
  LSAのフラップ定義とは具体的には何を示すもの？

     A, OSPFのLSA updateの中身が変わったところ。
        Maxageを受けた、本当に1時間来なかったこととカウントした。
        Juniper/Ciscoの混在環境についてはIIJでも検証したことあり。


山本 (IIJ)
  どんなソフトウェア？  どんなシステムで測定されたのですか？

     A, ツールはフルスクラッチで自作。
        時間軸でOSPFデータを収集し、アナライザかませて可視化。


松嶋 (JT)
  reachablity が本当にあるのかどうか分かればより意義がでるのでは。


7, まとめ

  今回の1例のように必ずしもバグ、不具合を突き止めることはできないかも
しれないが、少なくとも観測しておくことが重要である。これにより今まで
見えていなかったネットワーク状況が把握することできる。また、オペレータ
ならお客様から指摘される前にネットワーク状況を把握しておくべきである。
監視範囲については今後も広げた方がよさそうだ。


8, 所感

ネットワーク管理をしている中、データを収集、視覚化することで得られる
ものは多い。時には今まで気がついていなかった傾向、問題点を突き止め、
大規模な障害を未然に防ぐこともできるかもしれない。
今回は実網の中のOSPFの動きに着目し、Juniper/Ciscoという世の中にずいぶ
ん普及しているであろうネットワーク環境において、IOSのバグ(?)を突き止
めた。
特にマルチベンダ環境において、この類の不具合はまだまだ隠されていると
考えられる。安定したネットワークを継続して運用するため、計測範囲を広
げる等、このような活動は非常に重要だと思う。(樽井)