OSPF
レイヤー 3 のトラブルシューティング
障害のタイプ
. . . 100
パケットロスのトラブルシューティング
. . . 100
ルーティングループのトラブルシューティング
. . . 104
回線過剰利用のトラブルシューティング
. . . 106
ルート変動のトラブルシューティング
. . . 106
遅延のトラブルシューティング . . . 110
まとめ
. . . .113
本章では、レイヤー
3
のトラブルシューティングについて説明します。IP
ネットワークをトラブルシューティングするための手順と指針を構築 するために、第1
章で示したガイドラインに戻り、繰り返し適用できる プロセスを確立します。遭遇する可能性があるすべての
IP
問題について説明することはほぼ 不可能であるため、本章では、ネットワーク問題の素早い切り分けと 解決を達成できるような、効果的なアプローチの仕方について説明し ます。障害のタイプ
まず、IP障害をタイプ別に分類します。
パケットロス：パケットロスとは、パケットが宛先まで届かない現 象で、さまざまな原因によって起こります。最も一般的な原因とし ては、回線のダウン、（正確な）ルーティング情報の欠如、ルーティ ングループ、回線の過剰利用（Class-of-Service
を伴うまたは伴 わない場合）が挙げられます。多くの場合、セキュリティデバイス も（意図的な）パケットドロップを引き起こす原因となりますが、ファ イアウォールは本書が目的とする範囲外のため言及しません。
遅延：遅延とは、パケットが宛先に届くまでの時間が遅れる現 象で、準最適ルーティングまたはClass-of-Service
キューイン グが原因で起こります。これに関連するジッターも遅延の一種で、IP
ネットワーク上で音声や映像をやり取りする環境では大きな 問題となります。ジッターの主な原因は、Class-of-Service（ま
たはその欠如）です。注
IP
ネットワークをトラブルシューティングする上で最も重要なのは、使 用するプロトコルと、どのようにそれらが相互に作用するのかをしっ かりと理解することです。スペースの制約上、RIP、IS-IS、OSPF、BGP
について詳細に解説することができないため、本章ではネット ワーク上で稼働するプロトコルと、それらがどのように相互に作用す るかについて十分に理解していることを前提としています。パケットロスのトラブルシューティング
パケットロスは、ほぼ常に以下のいずれかの原因によって生じるため、
ネットワーク問題の中でも比較的容易に対処できるものの
1
つです。
回線およびハードウェアの障害（全停止障害）
ルーティングループ（全停止障害）
回線の過剰利用（一部停止障害）
ルート変動（一部停止障害）第7章：レイヤー3のトラブルシューティング 101
これらのタイプの障害をトラブルシューティングするために、関与して いるルーター（1つまたは複数）の特定、根本的原因の特定、さらに 可能な場合には問題の解決をそれぞれ素早く行うためのステップに ついて順に説明していきます。
回線の障害
障害の中でも、全停止障害は、容易に解決できることが多々あります。
全停止障害をトラブルシューティングする上で最も重要なのは切り分 けです。それは、解決には設定の変更、ハードウェアの再起動また は交換、あるいは回線提供通信事業者への連絡が必要となる可能性 があるためです。
このタイプの障害をトラブルシューティングする際に最も役立つツール は、tracerouteです。tracerouteは、TTL（Time-To-Live）値を
1
から1ずつ増分しながら宛先に一連のパケットを送信します。ルーター では、IPパケットを受信したときにTTL
の値を1
だけ小さくすること が求められています。TTL値が0
になると、ルーターはICMP
time-exceeded
メッセージを送信しなければなりません。このICMP
メッセージは、送信ルーターにその特定のホップの
IP
アドレスを知らせる ものです。このプロセスはパス内の各ホップで繰り返されるため、送信ルーター はパス内の各ホップの
IP
アドレスを得ることができます。この情報は、障害の根本的原因を特定しようとするオペレータにとって非常に有用 です。
注
traceroute
の最後の応答ホップが問題の原因であるとの認識は、よくある誤解です。応答するということは、ホストではそのルーターに 対して到達可能性があり、そのルーターもまたホストに対して到達可 能性があることを意味します。
一般に、問題があると疑うべき箇所は、応答した最後のホップと応答 しなかった最初のホップの間、または応答しなかった最初のホップ上 です。この単一コマンドを使用する上で重要なことは、作業を集中的 に行う場所を即座に発見できるということです。
図
7-1
に示すネットワークを例にとります。図7-1 シンプルなネットワークトポロジー
このネットワークは、サイト内に配置した
2
つのルーターで構成され ています。一方のDunkel
（伝統的なビールから命名）は、コーポレー トLAN
のアグリゲーションを行うルーターで、もう一方のPilsener
（人 気の高いビールから命名）はサービスプロバイダに接続するルーター です。Pilsenerには、サービスプロバイダがネクストホップであるデ フォルトのスタティックルートがあり、このルートをサイト内のIGP
で あるOSPF
に配布しています。これにより、Dunkelでは、Pilsener がネクストホップであるデフォルトルートを得ます。LAN
上のサーバー およびホストには、Dunkelがネクストホップであるデフォルトのスタ ティックルートがあります。まず、すべてのシステムが想定どおりに機能しているケースで、イン ターネット上のある宛先に
traceroute
を実行した例を見てみます。server% traceroute 4.2.2.1
traceroute to 4.2.2.1 (4.2.2.1), 30 hops max, 40 byte packets
1 18.32.75.1 (18.32.75.1) 2.617 ms 1.690 ms 2.851 ms ß Dunkel 2 18.32.74.6 (18.32.74.6) 3.386 ms 3.370 ms 5.570 ms ß Pilsener
3 4.10.33.2 (4.10.33.2) 13.513 ms 3.905 ms 5.060 ms ß Service provider hop 1 4 4.1.18.21 (4.1.18.21) 3.778 ms 5.237 ms 5.413 ms ß Service provider hop 2 5 4.2.2.1 (4.2.2.1) 10.876 ms 12.568 ms 5.991 ms ß Destination
図
7-2
に示すように、このネットワークの最も一般的な障害点は、サー ビスプロバイダへのリンクです。次に、この障害をシミュレーションし て、もう一度traceroute
を実行してみます。図7-2 サービスプロバイダリンク障害
図
7-2
に示すシナリオでtraceroute
を実行すると、以下のとおりと なります。ps@dunkel> show route 4.2.2.1 ps@dunkel>
Pilsenerからサービスプロバイダへのデフォルトスタティックルートは、
リンクがダウンすると消え、このルートは
OSPF
には配布されなくなり、結果的に
Dunkel
では4.2.2.1
へのルートがなくなります。Dunkel
は、destination host unreachableエラーメッセージで応答します。これは、
実行した
traceroute
の最終行の文字!Hで示されています。server% traceroute 4.2.2.1
traceroute to 4.2.2.1 (4.2.2.1), 30 hops max, 40 byte packets 1 18.32.75.1 (18.32.75.1) 1.983 ms 2.440 ms 2.414 ms
2 18.32.75.1 (18.32.75.1) 2.883 ms !H 4.136 ms !H 3.799 ms !H
第7章：レイヤー3のトラブルシューティング 103
Dunkel
は18.32.75.1
であるため、ここを調査の開始箇所とすべきです。このケースでは、Dunkelでのルーター操作と、その後で行う
Pilsener
でのルーター操作によって、サービスプロバイダへのリンクがダウンしたことが判明します（おそらく、
Syslogまたは SNMPによっ
て通知済み）。この時点で、接続のローカル側のハードウェアを取り 付け直し、再設定、および/
または交換して、正常に動作することを 確認します。問題が引き続き発生する場合は、サービスプロバイダに 連絡してサポートを要請してください。ポイントツーポイントではないイーサネット接続など、接続のリモー ト側の障害が発生しても回線がダウンしない状況もあります。ここで、
図
7-3
に示すように、サービスプロバイダへの接続を、サービスプ ロバイダにてレイヤー2
スイッチを経由してからルーターに接続する イーサネットリンクに変更します。図7-4
には、サービスプロバイダ ルーターの障害を示します（または、サービスプロバイダスイッチか らサービスプロバイダルーターへの接続の障害）。図7-3および7-4 サービスプロバイダへのイーサネットリンクとその障害
以下に、このタイプの障害が発生している状況で
traceroute
を実行 した場合の出力を示します。server % traceroute 4.2.2.1
traceroute to 4.2.2.1 (4.2.2.1), 30 hops max, 40 byte packets 1 18.32.75.1 (18.32.75.1) 2.891 ms 0.594 ms 1.595 ms 2 18.32.74.6 (18.32.74.6) 2.425 ms 2.544 ms 2.642 ms 3 * * *
trace
はPilsener
まで到達しました。それは、サービスプロバイダへのイーサネット接続の終端装置が（リンクアップしていない）ルー ターではなく、（リンクアップしている）スイッチであるため、接続自 体は確立された状態を維持します。これは、Pilsenerのデフォルト スタティックルートは有効状態を維持し、引き続きデフォルトルートを
OSPF
に配布することを意味します。ps@pilsener> show route 4.2.2.1
inet.0:11 destinations, 12 routes (11 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Static/5] 00:00:33
> to 192.168.14.10 via fe-0/0/1.0
Pilsener
とネクストホップ（サービスプロバイダ）の間でtraceroute
がばらついていることから、調査の開始箇所として適しているのは
Pilsener
です。次のステップとしては、Pilsenerにログインし、上記のshow routeコマンドを実行して、接続のリモート側（192.168.14.10）
に
ping
を試行します。それに失敗した場合は、サービスプロバイダ に連絡してください。この障害はリンクダウンイベントがないため、NMSシステムで検知す る方が難しい可能性があります。このタイプの障害を監視システムで 唯一検知できるのは、性能管理および接続性の保証を行うために何 らかのプローブ機能を併用している場合です。多くの
NMS
システム では、NagiosおよびWhatsUp Gold
のように、こうした目的のた めに複数の異なる宛先へのping
を監視する機能を備えています。ps@router-3> ping 192.168.14.10
PING 192.168.14.10 (192.168.14.10):56 data bytes
^C
192.168.14.10 ping statistics
---5 packets transmitted, 0 packets received, 100% packet loss
ルーティングループのトラブルシューティング
全停止障害は、ルーティングループが原因で発生することがあります。
ルーティングループは、2台のルーター（直接接続されたルーター同 士が多い）が、特定の宛先に対するネクストホップとして互いを選択 した場合に発生します。これは、スタティックルート環境で多く見られ ます。ルーティングループは、ルート変動が生じている場合にも発生 しますが、そうした状況ではループは必ずしも持続的に発生はしませ ん。ルート変動については、本章で後述します。
図