Junos の基本 - Juniper Networks...Junos について Junos® は、ルーティング、スイッチング、セキュリティをカバーする高信頼性かつ高性能なネットワークOSです。新サービス導入に伴う所要期

Junos®の基本

Day One：Junosの監視および

トラブルシューティング

著者：ジェイミー・パナゴス、アルバート・スタッティ

第1章：根本的原因の特定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

第2章：フィックステストの適用. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

第3章：CLIの操作 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

第4章：システムの監視およびトラブルシューティング . . . . . . . . . . . . . . . . . . . . . 39

第5章：レイヤー1およびレイヤー2の監視およびトラブルシューティング . . . . 55

第6章：レイヤー3の監視 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

第7章：レイヤー3のトラブルシューティング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99

© 2011 by Juniper Networks, Inc. All rights reserved.

Juniper Networks、Juniper Networksのロゴ、Junos、NetScreen、ScreenOSは、Juniper Networks, Inc.（以下、ジュニパーネットワークス）の米国およびその他の国における登録商標です。Junoseは、ジュニパーネットワークスの商標です。その他の商標、サービスマーク、登録商標、登録サービスマークは、それぞれの所有者に帰属します。

ジュニパーネットワークスは、本書に誤りが含まれていることがあっても責任を負いません。ジュニパーネットワークスは予告なく本書を変更、修正、転載、別の形態に改訂する権利を留保します。ジュニパーネットワークスが製造、販売する製品、あるいはその部品は、ジュニパーネットワークスが保有する、あるいはライセンスを受けた以下の米国特許のうち 1件または複数により保護されている場合があります。米国特許第 5,473,599号、第 5,905,725号、第 5,909,440号、第 6,192,051号、第 6,333,650号、第 6,359,479号、第 6,406,312号、第 6,429,706号、第 6,459,579号、第 6,493,347号、第 6,538,518号、第 6,538,899号、第 6,552,918号、第 6,567,902号、第 6,578,186号、第 6,590,785号。

発行元：Juniper Networks Books著者：ジェイミー・パナゴス、アルバート・スタッティ編集責任者：パトリック・エイムズ原稿整理・校正編集者：ナンシー・ケルベルJunosプログラムマネージャ：キャシー・ガデッキ

ISBN：978-1-936779-04-8（印刷版）印刷：Vervante Corporation（米国）ISBN：978-1-936779-05-5（電子書籍版）

改訂：第 3版、2011年 1月 4 5 6 7 8 9 10 #7100124

著者の紹介ジェイミー・パナゴスは、ジュニパーネットワークスのシニアネットワークコンサルタントで、データセンター、企業環境、およびサービスプロバイダ向けのネットワークの設計、実装、運用を専門としています。世界有数の大規模なネットワークに 10年以上携わってきた経験があり、影響力の大きい NANOG、ARIN、RIPEをはじめとするいくつかの業界コミュニティにも参加しています。また、JNCIE-MT #445および JNCIE-ER #50の有資格者でもあります。

アルバート・スタッティは、ジュニパーネットワークスのシニアテクニカルライターで、過去 9年にわたりJunos OSに関するマニュアルや文書の制作に携わってきました。これまで制作した文書類は、MPLS、VPN、VPLS、マルチキャストなどのネットワーク機能やプロトコルに関するもので多岐にわたります。

著者の謝辞この場をお借りして、本書の制作にご協力いただいた方々に感謝を申し上げます。パトリック・エイムズ氏のご助力やご指導なしには、本書は実現できませんでした。ネイサン・アルジャー氏、ライオネル・ルジェリ氏、およびザック・ギブズ氏には、このブックレットの制作過程で幾たびも貴重なテクニカルフィードバックをいただいたことを感謝いたします。キャシー・ガデッキには、制作のさまざまな工程で助言やフィードバックをいただき、この構想をブックレットという形に実現させたことに大きく貢献していただいたことを感謝します。末筆ながら、さまざまな形でご助言およびご協力いただいた多くのみなさまに対し感謝の意を表します。

本書はさまざまな形式でwww.juniper.net/dayoneから入手できます。ご提案、ご意見、ご批評は、[email protected]まで電子メールでお送りください。 TwitterでもDay Oneシリーズに関する情報を発信しています。@Day1Junos

ii

本書を読む前に知っておくべきこと

対象ネットワークで採用しているトポロジー、トラフィックフロー、およびプロトコルをしっかりと理解していること

Junos CLIに精通していること

Syslogや SNMPなどのネットワーク監視プロトコルを扱った経験があること

ネットワーク管理システムで何を行い、どのように行うかなど、理解していること

OSIモデルと、それがネットワークプロトコルやネットワーク構成要素にどのように適用されるのかを把握していること

本書の学習目標

デバイスにログインしなくても、ネットワークで発生している問題の原因と場所を予測すること

技術者および監視システムがネットワークを運用する上で必要となるすべての情報をまとめた監視およびトラブルシューティングの標準テンプレートを作成すること

異なるプロトコルや技術にわたり、迅速かつ効果的なトラブルシューティングを行えるようOSIモデルを活用すること

Junosが備える機能を用いて、デバイスおよびネットワークの正常性を監視し、ネットワークダウンタイムを短縮すること

ネットワークに対する処置の適確性を確認するための独自テストを開発すること

注お客様のご意見やご批評をお聞かせください。ご提案は、[email protected]まで電子メールでお送りください。

iii

JunosについてJunos®は、ルーティング、スイッチング、セキュリティをカバーする高信頼性かつ高性能なネットワークOSです。新サービス導入に伴う所要期間を短縮し、ネットワーク運用コストを最大 41%も削減します。Junosは、アプリケーション開発用に高信頼のプログラミングインタフェースとJunos SDKを備え、ネットワークの価値を最大限に引き出します。Junosは設計に当たって、ネットワークのあり方を 1から見直して統一システムを実現しています。

統一されたOS：ネットワークインフラストラクチャの計画、導入、運用に伴う時間を短縮し、手間を軽減します。

統一されたリリース体系：豊富な実績に裏打ちされた一定の間隔で新機能を安定的に提供します。

統一されたモジュラー型ソフトウェアアーキテクチャ：高可用性と優れた拡張性のソフトウェアであるため、ニーズの変化に柔軟に対応します。

ネットワークで Junosを運用すると、既存アプリケーションの信頼性、性能、セキュリティが向上します。無駄のない効率的なシステム上でネットワーク運用が自動化されるため、余った時間を新しいアプリケーションやサービスの導入に振り向けることができます。拡張や縮小も自由に実行でき、開発者やオペレータにとっては一貫性、信頼性、安定性に優れたシステムが実現します。この結果、ビジネスを支える、より経済性に優れたソリューションとなります。

Junos基本シリーズについてこの Day Oneシリーズは、Junos OSを初めて導入するユーザーを対象に、1日の作業で必要となる情報をまとめたものです。まずは、Junosが動作するデバイスをセットアップして運用するための実践的なステップと必要な知識から順に説明していきます。詳細およびその他の Day Oneブックレットについては、www.juniper.net/dayoneを参照してください。

『Junos High Availability』の特別価格でのご提供『Junos High Availability』を読むことで、数台の機器で支える小規模な企業環境ネットワークから、複雑な構成のキャリア向けネットワークまで規模を問わず、ジュニパーネットワークスのデバイスを導入した信頼性と障害許容力の高いネットワークを構築できるようになります。この本で紹介するソフトウェアアップグレード、拡張性、リモートネットワーク監視および管理、VRRPをはじめとする高可用性プロトコルなどに関する有益なアドバイスに従えば、ネットワークのアップタイムを最大限まで、場合によっては 99.99999%まで向上させることができます。www.oreilly.com。プロモーションコード JHAVTをお使いいただくと35%の割引が適用されます。

iv

第1章

根本的原因の特定

フィックステスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

本書で使用するネットワーク . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

6 Day One：Junosの監視およびトラブルシューティング

問題のトラブルシューティングで達成すべき第一の目標とは、その根本的原因の特定です。本セクションでは、ネットワーク問題の根本的原因を素早く特定するために、手がかりやツールを使用するアプローチについて説明します。このアプローチを使用することで、経験の浅いネットワークエンジニアから経験を積んだシニアネットワークエンジニアまで、調査に要する時間を短縮してダウンタイムを短縮し、最終的にはコストまで削減できるようになります。デバイスやネットワーク管理システムにログインしなくても、問題の性質、調査すべき箇所や事柄を予測することは可能です。問題の特性を理解するための基本的な質問セットに答えることで、これが可能になります。

注この時点では、まだ問題の解決策は見つからないかもしれません。しかし、ほとんどの状況に対応する不変の質問セットに従うことで、選択肢を絞り込むことがきるようになります。これらの質問で得られる答えの内容も重要ですが、ネットワークの監視とトラブルシューティングで一貫性が保たれることも同じくらい重要です。

ヒントコンピュータネットワークの複雑性により、原因ではないかと疑った機器が実際には正常に動作しており、真の根本的原因がネットワークの別のレイヤー内にある機器であると判明することがあります。ルーターが、レイヤー 4での問題を引き起こすことがあります。あるいは、スイッチが、通常はレイヤー 3での問題と思われる問題を引き起こすことがあります。要するに、間違った場所で原因を探そうとしている可能性があります。そのため、最初に導き出した予測や疑いを完全に却下せずに、3次元で立体的に当てはめてみてください。

図 1-1a、1-1b、1-1c、および 1-1dに、ジュニパーネットワークスの各種デバイスおよびネットワークに対する監視およびトラブルシューティングのアプローチ方法を示します。各図は、問題の範囲の提示から開始します。例えば、図 1-1aは、単一ユーザーが単一接続先に接続できないネットワーク問題に対するアプローチ方法を示しています。その後で、影響を受けるトラフィックのタイプ、問題の発生が継続的または散発的か、さらにはトラブルシューティング作業を集中的に行う場所を絞り込むことができます。

第1章：根本的原因の特定 7

図 1-1a 単一ユーザーが単一接続先に接続できない

単一ユーザー単一接続先

一部のプロトコルで一貫していない

一部のプロトコルで一貫している

すべて

継続的

散発的

継続的

散発的

接続元ユーザー

接続先

サービスプロバイダ

回線またはルート変動

ファイアウォール

継続的または散発的

トラフィックタイプ問題の一貫性トラブルシューティング集中箇所

問題の範囲

単一ユーザーすべての接続先



すべて

継続的

散発的

継続的

散発的

接続元ユーザー



問題の範囲

継続的

散発的

図 1-1b 単一ユーザーがすべての接続先に接続できない



すべてのユーザー単一接続先



すべて

継続的

散発的

継続的

散発的

接続先



問題の範囲

継続的

散発的


図 1-1c すべてのユーザーが単一接続先に接続できない


すべてのユーザーすべての接続先



すべて

継続的

散発的

継続的

散発的

アグリゲーションポイントの問題


回線ダウン



問題の範囲

継続的

散発的

ネットワーク全体の障害

図 1-1d すべてのユーザーがすべての接続先に接続できない


ヒントこれらの図は、ネットワーク障害の範囲および考えられる原因を特定する上で役立ちます。この情報を次に示すフィックステストとともに使用することで、より素早く問題を切り分け、顧客へのサービス提供を復旧できるようになります。

フィックステスト本書を通して、フィックステストと呼ばれる共通の質問セットを作業者と作業自体に適用します。この質問セットの一例を以下に示します（これを例として、独自のフィックステストを作成することを推奨する）。

問題の範囲は ?

障害の範囲や規模が何を意味するのかは、人によって異なります。例えば、主要アカウントで 1つのWebサイトをダウンロードするのに時折時間がかかっただけでも、それを大災害として捉える人もいれば、ネットワーク全体がダウンしたときに初めて重大事であると捉える人もいます。この質問については、感情や主観を排除した客観的な目で問題を調べることが求められます。これは、障害を把握する第一歩として最も重要なことです。

影響を受ける接続元ネットワークはいくつあるか ?

問題が生じている接続先はどこか ?

これに答えることで、問題が接続元、接続先、あるいはより大規模な領域で発生しているのかを把握できます。単一ユーザー（またはネットワーク）が、すべての接続先に対して問題が発生していると報告している場合は、接続元に近いネットワーク構成要素に作業対象を絞るべきです。多くのユーザーが、単一の接続先（またはネットワーク）に対して問題が発生していると報告している場合は、接続先に近い箇所で発生しているか、ピアリングポイントなどのネットワーク相互接続箇所で生じている問題に起因している可能性があります。問題の発生場所を接続元または接続先のどちらかに切り分けできない場合、その事象はおそらくネットワーク全体で発生しているため、緊急事態として捉えるべきです。

問題を最初に報告したのは誰か ?

この質問は、問題が最初に発生した場所（ネットワークに関連するため、地理的な場所）を特定する上で役立ちます。問題が接続元に関連したもの、接続先に関連したもの、またはネットワーク全体にわたる障害のいずれであっても、この質問に答えることで集中的に最初に調べるべき箇所を絞り込むことができます。


影響を受けるトラフィックのタイプは（複数の場合あり）?

この質問の答えは、問題が発生しているのが OSIモデルのどのネットワークレイヤーであるかを把握する上で役立ちます。接続性が完全に失われた状況は、通常、レイヤー 3で問題が発生しているか回線がダウンしていることを示します。レイヤー 2での問題は、一般に、プロトコルに限定されるものでありませんが、全停止障害を引き起こす可能性は極めて低いといえます。上位レイヤー（レイヤー 4、5、6、7）での問題は、多くの場合、ファイアウォールに関連する問題が原因です。この質問に答えることで、集中的に調査すべきエリアだけでなく、問題を引き起こしている機器を特定できるようになります。レイヤー 2での問題は、一般に、イーサネットスイッチか、またはルーターおよびエンドホストポート上のレイヤー 2エラーに焦点を当てるべきであることを示します。レイヤー 3での問題は、エンドホスト上のルーターおよび IPスタックを確認すべきであることを示します。

問題の発生は継続的であるか、散発的か ?

継続的に発生する問題は、一般に、設定の誤りやハードウェア障害などの持続的な問題が原因です。散発的に発生する問題は、一般に、ルートや回線のフラッピングなど繰り返し発生する問題、あるいはトラフィックの一時的な増加によるトラフィックスパイクによる影響を示しています。ここでも、これらの質問に答えることで、最初に調べるべき箇所を特定できるようになります。継続的に発生する問題については、最近、ネットワークに対して何らかの変更が加えられたかを確認するためにログを調べます。また、障害が発生し始めたときに、何らかの管理作業が予定されていたかをオペレーションセンターに問い合わせます。こうしたケースに該当しない場合は、次に、ハードウェアが問題の原因となっているかの特定を試みます。前述の質問に対する答えは、調査開始場所の特定に役立つはずです。散発的に発生する問題は、特定が若干難しくなります。トラフィックスパイクは、特に、インタフェースでの送受信レートをポーリングするためのネットワーク管理システムが導入されている場合には、比較的容易に特定できます。問題の範囲や規模に基づいて、さらに調査が必要な疑わしいインタフェースを特定します。

この時点で問題が明白にならない場合は、繰り返し発生する、あるいは何らかの変動に関する問題である可能性があります。Syslogやその他の NMSユーティリティを利用することは、フラッピングしているリンクを特定する上で役立ちます。また、前述の質問に対する答えに基づいて、調査箇所をある程度絞り込めるようになるはずです。ルート変動の問題の場合は、調査対象のネットワークごとに、できる限り徹底的に接続元から接続先まで、さらには接続先から接続元の双方向のパスをたどりながら、ルーティング変更があるかどうか各ホップを監視する必要があります。


本書で使用するネットワーク本書では、コアネットワークとして、図 1-2に示すトポロジーを使用します。これは、キャリアやサービスプロバイダなどが採用する大規模なネットワークを表すために、2つの企業環境ネットワークによる構成が示されています。ネットワーク規模にかかわらず、適用する監視およびトラブルシューティングのスキルは共通ですが、当然ながら大規模なネットワークでは、そのスキルの適用範囲が広くなり、作業も多くなります。

図 1-2 本書で使用するネットワークトポロジー

物理的な設計このトポロジーで示す物理的な設計は、2つの主要サイト（シカゴおよびボストン）、遠隔地にある 2つのサイト（イリノイ州ピオリアおよびアイスランドのレイキャビク）、およびシカゴサイト内にある小さなデータセンターをサポートする比較的シンプルな企業環境ネットワークを表しています。この物理的な設計の最大の目的は、できる限りの


冗長性をもたらしながら、拡張性も与えることです。ネットワークのコアには、2台のM10iルーター、4台のM7iルーター、さらには 4台のMX240イーサネットアグリゲーションルーターが配置されています。M10iルーターは、さまざまな技術を使い、2つの主要サイト間の接続性を提供しながら、遠隔地にある拠点へのWAN接続の終点となります。各サイトの一方のM7iルーターは、インターネットへの接続性を提供しており、後で 2つの SRXファイアウォールによって保護される予定です（現在、SRXはフィルタリングを行っていない）。もう一方のM7iルーターは、もう一方の主要サイトへの冗長接続性を提供します。MX240ルーターは、各主要サイト内のクローゼットEXシリーズイーサネットスイッチのアグリゲーションを行い、データセンターとネットワークのその他の箇所の間のレイヤー 3境界としての役割を果たします。遠隔地にあるサイト内の Jシリーズルーターは、ゲートウェイルーターおよび EXシリーズスイッチのアグリゲーションポイントとしての役割を果たします。さらに、遠隔地にある拠点で採用されたのと似た方法で、コアのM7iルーターに買収により合併した企業が接続されています。ただし、このサイトのアーキテクチャは他とは若干異なります。この設計は、シャーシレベルで冗長性をもたらしながら、モジュラー型の設計とシャーシの選択肢によって、コストがかかるコア内でのハードウェア交換なしに、帯域幅の増加とエッジアグリゲーションデバイスの追加を実現できる拡張性も与えます。

論理的な設計

論理的な設計は、物理的な設計と同様に、冗長性をもたらしながら、将来的にMPLS、マルチキャスト、および IPv6などを容易に導入でき、高速な収束を実現することを目的としています。

サテライトサイト

遠隔地にある拠点は、従来のWAN回線技術だけでなく、IPSecおよびレイヤー 2 VPN技術を用いた擬似有線による論理接続によっても接続されています。これらの接続は、ネットワークの他の場所からは他の物理媒体と同じように機能しているように見えますが、論理接続であるため、監視およびトラブルシューティングの面では異なります。


IGP

この設計で用いられる主要 IGPは、OSPFです。OSPFは、MXシリーズおよびMシリーズルーター上の単一エリア（エリア0）内で動作します。遠隔地にある拠点の Jシリーズルーター上でもOSPFが動作しますが、これら2つのOSPFドメインは別個であり、買収した企業ではこれまで RIPが採用されてきました。OSPFは、設定が比較的容易である点や、その収束特性、MPLSのサポート、運用チームが扱いに慣れているなどの理由から採用されています。IS-ISでも、同じように問題なく運用できます。OSPFと IS-ISのどちらを採用するかは、そのプロトコル導入の経験度と快適度によって決定することになります。その他の要素や条件が同じであるならば、プロトコルを選択する上で扱いに慣れている方を採用することは、正当かつ有効な選択方法です。

BGP

BGPは、このネットワークのさまざまな機能をサポートします。このネットワークは、マルチホームでインターネットに接続するため、サービスプロバイダ間では外部 BGP（eBGP）が動作しています。このケースでは、シカゴのインターネット接続がボストンの接続よりも優先されるよう、ASパスのプリペンドおよびローカルプリファレンスを適用してルーティング決定プロセスを制御します。すべてのMシリーズ、MXシリーズ、および Jシリーズルーターでは内部的に、フルメッシュにて内部 BGP（iBGP）が動作します。遠隔地の拠点と買収により合併した企業では、ローカル IGPルートを BGPに、BGPをローカル IGPに、それぞれ再配布します。eBGPは、3つ目のサービスプロバイダでも用いられ、アイスランドサイトへの冗長接続性をもたらすMPLS IP VPNサービスを提供します。

まとめ監視およびトラブルシューティングプロセスを構築する目的は、show

コマンドを実行しなくても、何を調査すべきか大まかに把握できるようにすることです。調査すべき場所だけでなく、調査すべき対象の目安が示されます。さらに、トリアージや通知手順を開始するための追加人員や、必要であればイベント管理グループを確保するために先制的に通知することができます。人員を追加できれば、問題の早期解決にもつながります。


ヒント前線のサポート要員は、実際に問い合わせを受ける前に問題を認識していることで、より最適なサポートを提供できるようになります。また、サポート要員から運用部門およびエンジニアリング部門へのフィードバックは、問題の切り分けと解決に役立ちます。

本書では、どのような問題の根本的原因を特定するときにも、共通のアプローチを使用します。本書では、前述の質問に答えて問題を切り分けるアプローチ方法について説明するとともに、根本的原因の特定に役立つ機能や操作も示します。

最後に、顧客に影響を及ぼさないよう先を見越して問題を探し出せるように、管理および監視手法を見直し、障害発生時にそれらの手法をどのように適用するかについて説明します。

本書で示すすべての監視およびトラブルシューティング手法は、Junos OSリリース 10.1に基づきます。

第2章

フィックステストの適用

トラフィック制御および過負荷のトラブルシューティング . . . . . . . . . . . . . . . . . . . 18

フィックステスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28


問題の根本的原因を特定できたら（第 1章）、次のステップでは、それを解決します。本章では、短期的フィックスおよび長期的フィックスの 2つのタイプのフィックスについて説明します。

意図的に汎用的な呼び方をしていますが、短期的フィックスや極端なケースではハッキングも、本書で定義する以下のフィックステスト基準を満たせば容認できる解決方法となることを示します。

� フィックスが他の問題を引き起こさないこと � フィックスが再起動後も有効であること � フィックスが明確に伝達されること � フィックスの運用方法がわかりやすいこと � フィックスが、ある程度の期間内に長期的フィックスで置き換えられること

これらの要件が満たされた場合、その短期的フィックスは完全に容認できるものです。どの（短期的または長期的）フィックスも、必ず迅速なサービス提供の復旧を最大の目標とするべきです。

トラフィック制御および過負荷のトラブルシューティングこのフィックステストアプローチの優れた例として、短期的にはトラフィック制御、長期的には容量アップグレードが挙げられます。図 1-2に示すネットワークを例にとります。両サービスプロバイダからBGPを介してフルインターネットルーティングテーブルを受け取ります。また、ローカルプリファレンスを使用して、シカゴをプライマリ出口ポイントとして選択し、ボストンのピアリングポイントをバックアップとして設定します。ASパスプリペンドを使用して、戻りトラフィックが必ずシカゴの接続を経由するようにしていますが、複数のユーザーから、ピーク時間帯のインターネットアクセスが遅いとの苦情を受けています。

この問題は、すべてのユーザーおよびすべての外部接続先で発生していることから、単一ユーザーに限定的な問題ではなく、任意のアグリゲーションポイント（出口ポイントなど）で発生している可能性があることが推測できます。さらに、問題が散発的に発生することから、トラフィックレベルに関連していることも推測できます。

ネットワーク管理システムを使用するか（図 2-1）、CLIでトラフィックレベルを確認することで（図 2-1の後）、このネットワークでは、シカゴのプライマリサービスプロバイダへのアウトバウンドのギガビットイーサネットリンクが過剰利用されていることがわかります。ネットワークオペレータには、図 2-1のようなグラフが示されます。

第2章：フィックステストの適用 19

図 2-1 Chicago-edge-1-as-44利用状況グラフ

ネットワークオペレータが、Junos CLIを使用してインタフェース統計を確認した場合には、具体的に入力レートと出力レートが表示されることで問題が示されます。

ps@chicago-edge-1> show interfaces ge-0/0/9 Physical interface: ge-0/0/9, Enabled, Physical link is Up Interface index:137, SNMP ifIndex:118 Description:Connection to isp-1 Link-level type:Ethernet, MTU:1514, Speed:1000mbps, MAC-REWRITE Error:None, Loopback:Disabled, Source filtering:Disabled, Flow control:Enabled, Auto-negotiation:Enabled, Remote fault:Online Device flags :Present Running Interface flags:SNMP-Traps Internal:0x4000 Link flags :None CoS queues :8 supported, 8 maximum usable queues Current address:00:19:e2:25:b0:09, Hardware address:00:19:e2:25:b0:09 Last flapped :2009-10-13 13:51:19 PDT (2d 20:44 ago) Input rate :3217455289 bps (13928377 pps) Output rate :9843638222 bps (37520944 pps) Active alarms :None Active defects :None

上記出力の太字で示した箇所で、プロバイダへのアウトバウンドの接続がラインレートに近いことがわかります。CLI出力はスナップショットであるため、真のトラフィック状況を深く理解するためには、このコマンドを何回か実行することを推奨します。また、ネットワーク管理システムを使用してボストンを確認した場合には、図 2-2のようなグラフが示されます。

図 2-2 Boston-edge-1-as-107利用状況グラフ

Junos CLIを使用して show interfacesコマンドを実行すると、ボストンの接続の入力レートおよび出力レートが表示されます。ネットワークを能動的に監視してエラー発生を警告するのに適しているのはネットワーク管理システムですが、具体的な情報を即座に収集するにはCLIが最適です。これら2つのツールセットを組み合わせることで、ネットワーク問題の迅速な切り分けと修理が可能になります。

ps@boston-edge-1> show interfaces so-3/3/2 Physical interface: so-3/3/2, Enabled, Physical link is Up Interface index:167, SNMP ifIndex:151 Description:Connection to isp-2 Link-level type:PPP, MTU:4474, Clocking:Internal, SONET mode, Speed:OC12, Loopback:None, FCS:16, Payload scrambler:Enabled Device flags :Present Running Interface flags:Point-To-Point SNMP-Traps Internal:0x4000 Link flags :Keepalives Keepalive settings:Interval 10 seconds, Up-count 1, Down-count 3 Keepalive:Input:0 (never), Output:0 (never) LCP state:Down NCP state: inet:Not-configured, inet6:Not-configured, iso:Not-configured, mpls: Not-configured CHAP state:Closed PAP state:Closed CoS queues :8 supported, 4 maximum usable queues Last flapped :2009-10-14 07:03:58 PDT (2d 03:37 ago) Input rate :1207 bps (6 pps) Output rate :2943 bps (17 pps) SONET alarms :None SONET defects :None

ボストンのプロバイダ回線のインバウンドおよびアウトバウンドの同じビットレートを見ると（上記の太字箇所）、ほぼ空であることがわかります。

プライマリプロバイダとのピアリング容量のアップグレードを要求することもでき、要求すべきですが、実現まで数週間かかります。この過剰利用の問題には、短期的な解決策が必要です。ボストンには、セカンダリプロバイダに対する別の送信ポイントがあるため、アウトバウンドトラフィックの一部がバックアップリンクを利用するよう強制し、シカゴの回線の過剰利用を緩和するよう、ルーティングポリシーを変更できます。ボストンのエッジルーターに対して show bgp summaryコマンドを実行して、ボストンのサービスプロバイダからのルートを現在選択していないことを確認します。

ps@boston-edge-1> show bgp summary Groups:2 Peers:3 Down peers:0Table Tot Paths Act Paths Suppressed History Damp State Pendinginet.0 13986 6993 0 0 0 0Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Damped...



10.25.30.1 10 7013 7112 0 0 13:07 6993/6993/0 0/0/010.25.30.3 10 28 7111 0 0 12:41 0/0/0 0/0/018.32.16.102 107 7006 6277 0 0 8:10 0/6993/0 0/0/0

show bgp summary の出力を見ると、AS 107は 6993のルートを送信していますが、そのどのルートもboston-edge-1ではアクティブではありません。これは、現在「0/6993/0」と表示しているフィールドに示されています。最初の値はアクティブなルート数、2番目の値は受け取ったルート数、最後の値は減衰ルート数を示します。この BGPセッションに適用したポリシーを見直すには、以下のように show configuration

protocols bgp group [group-name]コマンドを使用します。ps@boston-edge-1> show configuration protocols bgp group ebgp-as-107 type external;import as-107-in-secondary;export aggregate-out;peer-as 107;neighbor 18.32.16.102;ps@boston-edge-1> show configuration policy-options policy-statement as-107-in-secondary term localpref-50 { then { local-preference 50; }}

ピアリング設定と適用したインポートポリシーを見直すと、なぜ問題が生じているのかがわかります。ボストンのサービスプロバイダからの全ルートのローカルプリファレンスは 50に設定されているため、シカゴのサービスプロバイダは、インターネットを接続先とする全トラフィックの優先送信ポイントとして機能しています。ローカルプリファレンスは、BGPルート選択プロセスにおいて最も重要な基準です。この値が高いほど、そのルートの優先度は高くなります。デフォルト値は 100です。そのため、50を設定すると、この BGPピアから通知されたルートは、デフォルトのローカルプリファレンスが適用されたルートを取得しているプライマリプロバイダから通知された同一ルートよりも優先度が低くなります。

実際にそうであるか、確認します。ボストンのインターネット接続先に対して show routeコマンドを実行します。

ps@boston-edge-1> show route 8.32.80.0/23 inet.0:7013 destinations, 14007 routes (7013 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both8.32.80.0/23 *[BGP/170] 00:10:13, localpref 100, from 10.25.30.1 AS path:44 107 46355 8081 52274 22469 5890 9532 8078 I > to 192.168.14.1 via ge-1/0/0.0


[BGP/170] 00:05:03, localpref 50 AS path:107 44 46355 8081 52274 22469 5890 9532 8078 I > to 18.32.16.102 via so-3/3/2.0

この出力によって、仮説が裏付けられました。出力のアスタリスクは選択されたルートを示します。また、ASパス 44の最初のホップはシカゴのサービスプロバイダであるため、選択されたルートは、シカゴのピアリングポイントを介して通知されたルートであることがすぐに判別できます。これは、ローカルプリファレンスに対して設定された値に基づいて選択されています。トラフィックの一部でボストンの送信ポイントを優先的に選択するようにするには、一部のルートでポリシーが一致するよう更新し、シカゴよりも高いローカルプリファレンスに設定する必要があります。プレフィックス単位でのトラフィック統計はないため、ポリシーを変更し、インタフェース統計を確認して、このサイクルを繰り返し、満足のいくトラフィックレベルが達成されるまで微調整を行います。

シカゴの送信側利用率を 70%まで低減させます。これは、300～400メガビット /秒の低減を意味します。最も簡単なのは、ボストンのサービスプロバイダの ASまたはその顧客が接続元となるルートに対して、ローカルプリファレンスを設定する方法です。

まず、プロバイダがすべての顧客ルートに対して BGPコミュニティとして 107:100を設定していることをWebサイトに掲載しているピアリングポリシーを確認して把握しています。これはネットワークオペレータが情報を配布するときに用いる一般的な方法であり、この情報に基づいてポリシーを構築します。次に、このコミュニティに一致する項を追加して、ローカルプリファレンスを 120に設定します。これにより、ボストンのピアリングポイントがそれらのルートに対して優先されるようになります。変更を加えたことで目的の効果が得られたかを確認するため、例として 8.32.80.0/23を使用します。

ps@boston-edge-1> show route 8.32.80.0/23 detail inet.0:7013 destinations, 14004 routes (7013 active, 0 holddown, 0 hidden)8.32.80.0/23 (2 entries, 1 announced) *BGP Preference:170/-101 Next hop type:Indirect Next-hop reference count:20970 Source:10.25.30.1 Next hop type:Router, Next hop index:488 Next hop:192.168.14.1 via ge-0/01.0, selected Protocol next hop:10.25.30.1 Indirect next hop:8e04000 131070 State:<Active Int Ext> Local AS: 10 Peer AS: 10 Age:1 Metric2:1 Task:BGP_10.10.25.30.1+179 Announcement bits (2):0-KRT 4-Resolve tree 1


AS path:44 107 I Communities:107:100 Localpref:100 Router ID:10.25.30.1 BGP Preference:170/-51 Next hop type:Router, Next hop index:486 Next-hop reference count:6999 Source:18.32.16.102 Next hop:18.32.16.102 via so-3/3/2.0, selected State:<Ext> Inactive reason:Local Preference Local AS: 10 Peer AS: 107 Age:3:57 Task:BGP_107.18.32.16.102+59002 AS path:107 I Communities:107:100 Localpref:50 Router ID:172.17.0.3

変更前は、ローカルプリファレンスの設定により、シカゴの出口ポイントが優先されていました。変更を加えるには、as-107-customersという名前のコミュニティを作成し、値 107:100を設定して、そのコミュニティを新たに挿入した項で使用します。最終的な設定は、以下のようになります。

ps@boston-edge-1> show configuration policy-options policy-statement as-107-in-secondary { term localpref-50 { then { local-preference 50; } } term localpref-120 { from community as-107-customers; then { local-preference 120; } }}community as-107-customers members 107:100;

加えた変更によって目的の効果が得られているかを確認するには、プレフィックス例 8.32.80.0/23に対して、もう一度 show routeコマンドを実行します。

ps@boston-edge-1> show route 8.32.80.0/23 detail inet.0:7013 destinations, 13008 routes (7013 active, 0 holddown, 0 hidden)8.32.80.0/23 (1 entry, 1 announced) *BGP Preference:170/-121 Next hop type:Router, Next hop index:486 Next-hop reference count:8991


Source:18.32.16.102 Next hop:18.32.16.102 via so-3/3/2.0, selected State:<Active Ext> Local AS: 10 Peer AS: 107 Age:35:27 Task:BGP_107.18.32.16.102+59002 Announcement bits (3):0-KRT 3-BGP RT Background 4-Resolve tree 1 AS path:107 I Communities:107:100 Localpref:120 Router ID:172.17.0.3

さらに、show bgp summaryコマンドを実行して、ボストンのルーターで、一部のプレフィックスに対して現在は AS 107を選択していることを確認できます。以前は、このコマンドの実行によって「0/6993/0」と示されましたが、現在このピアからは 1256のルートがアクティブであることがわかります（シカゴのピアからのアクティブルート数が 1256減っている）。

ps@boston-edge-1> show bgp summary Groups:2 Peers:3 Down peers:0Table Tot Paths Act Paths Suppressed History Damp State Pendinginet.0 13986 6993 0 0 0 0Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Damped...10.25.30.1 10 7013 7112 0 0 13:07 5737/6993/0 0/0/010.25.30.3 10 28 7111 0 0 12:41 0/0/0 0/0/018.32.16.102 107 7006 6277 0 0 8:10 1256/6993/0 0/0/0

目的通りにパスの選択を最適化できていることが確認できます。この時点で、コミュニティに 107:100を設定したルートは、ボストンのSONETリンクを経由しています（上記の太字の行を参照）。また、ボストンのルーターのルートでは、このコミュニティに一致しないルートは引き続きシカゴのリンクを優先して選択しており、ISP-1のアグリゲーションルート 178.0.0.0/8を優先して使用することが確認できます。

ps@boston-edge-1> show route 178.63.18.22 detail inet.0:7013 destinations, 13008 routes (7013 active, 0 holddown, 0 hidden)178.0.0.0/8 (2 entries, 1 announced) *BGP Preference:170/-101 Next hop type:Indirect Next-hop reference count:17982 Source:10.25.30.1 Next hop type:Router, Next hop index:488 Next hop:192.168.14.1 via ge-0/0/0.0, selected Protocol next hop:10.25.30.1 Indirect next hop:8e04000 131070 State:<Active Int Ext> Local AS: 10 Peer AS: 10


Age:1:23:37 Metric2:1 Task:BGP_10.10.25.30.1+179 Announcement bits (2):0-KRT 4-Resolve tree 1 AS path:44 I Localpref:100 Router ID:10.25.30.1 BGP Preference:170/-51 Next hop type:Router, Next hop index:486 Next-hop reference count:8991 Source:18.32.16.102 Next hop:18.32.16.102 via so-3/3/2.0, selected State:<Ext> Inactive reason:Local Preference Local AS: 10 Peer AS: 107 Age:1:20:22 Task:BGP_107.18.32.16.102+59002 AS path:107 44 I Localpref:50 Router ID:172.17.0.3

想定どおりに設定が機能しています。ボストンでは、この接続先へのルートとして、シカゴサイトへのギガビットイーサネット接続を優先しています。実際のテストでは、この時点でトラフィックレベルを確認する必要があります。インタフェース上のビットレートを確認して、どのくらいのトラフィックが代替ルートに移動したかを確認します。

ps@boston-edge-1> show interfaces so-3/3/2 Physical interface: so-3/3/2, Enabled, Physical link is Up Interface index:167, SNMP ifIndex:151 Description:Connection to isp-2 Link-level type:PPP, MTU:4474, Clocking:Internal, SONET mode, Speed:OC12, Loopback:None, FCS:16, Payload scrambler:Enabled Device flags :Present Running Interface flags:Point-To-Point SNMP-Traps Internal:0x4000 Link flags :Keepalives Keepalive settings:Interval 10 seconds, Up-count 1, Down-count 3 Keepalive:Input:0 (never), Output:0 (never) LCP state:Down NCP state: inet:Not-configured, inet6:Not-configured, iso:Not-configured, mpls: Not-configured CHAP state:Closed PAP state:Closed CoS queues :8 supported, 4 maximum usable queues Last flapped :2009-10-14 07:03:58 PDT (2d 03:37 ago) Input rate :1724 bps (9 pps) Output rate :3063137642 bps (10599092 pps) SONET alarms :None SONET defects :None


ルーターへの 2つ目の CLIセッションを開いた場合、monitor

interface so-3/2/2コマンドを使用して boston-edge-1上のリアルタイムトラフィックを監視できます。

ps@boston-edge-1> monitor interface so-3/3/2 boston-edge-1 Seconds:18 Time:16:11:23 Delay:0/0/17Interface: so-3/2/2, Enabled, Link is UpEncapsulation:PPP, Keepalives, Speed:OC12Traffic statistics: Current delta Input bytes: 35514 (1973 bps) [184] Output bytes: 55136476428 (3063137579 bps) [30631491127] Input packets: 162 (9 pps) [10] Output packets: 190782746 (10599092 pps) [10435138]Error statistics: Input errors: 0 [0] Input drops: 0 [0] Input framing errors: 0 [0] Input runts: 0 [0] Input giants: 0 [0] Policed discards: 0 [0] L3 incompletes: 0 [0] L2 channel errors: 0 [0] L2 mismatch timeouts: 0 [0] Carrier transitions: 1 [0] Output errors: 0 [0] Output drops: 0 [0] Aged packets: 0 [0]Next=’n’, Quit=’q’ or ESC, Freeze=’f’, Thaw=’t’, Clear=’c’, Interface=’i’

これらのコマンドを実行したことで、ボストンのエッジルーターでは、現在 SONETリンクを介して約 300メガビットをサービスプロバイダに向けて送信していることがわかります。シカゴのエッジルーターに対して類似コマンドを実行すると、トラフィックの低減を確認できます。最後にもう一度、ギガビットイーサネットを確認します。

ps@chicago-edge-1> show interfaces ge-0/0/9 Physical interface: ge-0/0/9, Enabled, Physical link is Up Interface index:137, SNMP ifIndex:118 Description:Connection to isp-1 Link-level type:Ethernet, MTU:1514, Speed:1000mbps, MAC-REWRITE Error:None, Loopback:Disabled, Source filtering:Disabled, Flow control:Enabled, Auto-negotiation:Enabled, Remote fault:Online Device flags :Present Running Interface flags:SNMP-Traps Internal:0x4000 Link flags :None CoS queues :8 supported, 8 maximum usable queues Current address:00:19:e2:25:b0:09, Hardware address:00:19:e2:25:b0:09 Last flapped :2009-10-13 13:51:19 PDT (2d 20:44 ago) Input rate :3172844311 bps (10682977 pps)


Output rate :6739379368 bps (23159379 pps Active alarms :None Active defects :None

太字で表示された行には、シカゴのプロバイダの接続上の出力トラフィックレベルが約 670メガビットまで低減したことがわかります。これは、アウトバウンドトラフィック利用率を 70%まで低減させるという当初の目標を達成しています。

フィックステストユーザーが遭遇していた接続に関する問題を解決するよう、ネットワークトラフィックを正しく制御できました。これは短期的なフィックスであるため、短期的フィックステストを実行して、内容が容認できるものかを確認する必要があります。

フィックスが他の問題を引き起こしていないか ?

明らかな問題は生じていません。NMSシステムを使用して、ボストンの回線を毎日監視し、トラフィックピーク時に回線の過剰利用が発生していないことを確認します。

フィックスが再起動後も有効であるか ?

はい。

フィックスが明確に伝達されているか ?

これは、あなた次第です。通常の状況では、この問題をトラッキングするチケットを更新し、フィックスの詳細、監視対象、関連する問題のエスカレーションのタイミングを説明した電子メールを運用担当者に送信します。

フィックスの運用方法はわかりやすいか ?

はい、フィックスはわかりやすいものです。ここでは、サービスプロバイダから提供されたコミュニティを使用して、ボストンのピアリングポイントを優先するよう一部のトラフィックを制御しています。


フィックスがある程度の期間内に長期的フィックスで置き換えられるか ?

残念ながら、さまざまな要素に依存します。サービスプロバイダ側でアップグレードに取り組む必要があります。また、ローカルループプロバイダ側では、新しい回線を設置しなければならない可能性があります。これが許容できる期間内に完成するかはわからないにしても、障害が発生したシナリオにおいて、トラフィック制御が最も適した短期的フィックスであったのは事実です。

第3章

CLIの操作

環境コマンド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

シャーシコマンド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Request Support Informationコマンド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38


ネットワークの安定性と常に高いアップタイムを維持するためには、問題が発生すると同時にトラブルシューティングを行えることが不可欠です。Junosデバイスのトラブルシューティングに最も必要なスキルは、Junos CLIを理解して操作できることです。

まず、システムが正常に稼働していることを確認でき、何らかの問題が生じたときにトラブルシューティングを開始する上で役立つシステム操作コマンドについて、いくつか説明します。

環境コマンド大半の環境操作コマンドは、シャーシ（chassis）階層レベルにあります。

ps@dunkel-re0> show chassis ? Possible completions: alarms Show alarm status craft-interface Show craft interface status environment Show component status and temperature, cooling system speeds ethernet-switch Show Ethernet switch information fabric Show internal fabric management state firmware Show firmware and operating system version for components fpc Show Flexible PIC Concentrator status hardware Show installed hardware components location Show physical location of chassis mac-addresses Show media access control addresses pic Show Physical Interface Card state, type, and uptime routing-engine Show Routing Engine status sibs Show Switch Interface Board status synchronization Show clock synchronization information temperature-thresholds Show chassis temperature threshold settings

シャーシの状態を素早く評価するには、show chassis alarmsコマンドを実行します。

ps@dunkel-re0> show chassis alarms 1 alarms currently activeAlarm time Class Description2010-01-19 11:47:35 PST Major PEM 3 Not OK

シャーシで、PEM（Power Entry Module）3に関する問題が生じているようです。通常、これは電源に関する問題を指し示します。ケーブルが外れているか、サーキットブレーカに問題があります。問題の詳細を把握するには、show chassis environment pemコマンドを実行します。

第3章：CLIの操作 31

ps@dunkel-re0> show chassis environment pem PEM 0 status: State Online Temperature OK DC Output: OKPEM 1 status: State Online Temperature OK DC Output: OKPEM 2 status: State Online Temperature OK DC Output: OKPEM 3 status: State Present

PEM 3は Presentとして表示されていることから、問題の原因は電源入力にあると推測できます。また、ここでは図 1-1の意思決定ツリーを利用します。例えば、現場の技術者に、ケーブルとサーキットブレーカが正常に機能していることを確認してもらうことから開始します。show chassis environmentコマンドを実行して、デバイスの現在の環境データをすべて表示します。

ps@dunkel-re0> show chassis environment Class Item Status MeasurementTemp PEM 0 OK PEM 1 OK PEM 2 OK PEM 3 Check Routing Engine 0 OK 45 degrees C / 113 degrees F Routing Engine 1 OK 43 degrees C / 109 degrees F CB 0 OK 41 degrees C / 105 degrees F CB 1 OK 39 degrees C / 102 degrees F SIB 0 OK 41 degrees C / 105 degrees F SIB 1 OK 41 degrees C / 105 degrees F SIB 2 OK 41 degrees C / 105 degrees F SIB 3 OK 44 degrees C / 111 degrees F FPC 0 Intake OK 31 degrees C / 87 degrees F FPC 0 Exhaust OK 42 degrees C / 107 degrees F FPC 1 Intake OK 31 degrees C / 87 degrees F FPC 1 Exhaust OK 41 degrees C / 105 degrees F FPC 2 Intake OK 30 degrees C / 86 degrees F FPC 2 Exhaust OK 41 degrees C / 105 degrees F FPC 3 Intake OK 32 degrees C / 89 degrees F FPC 3 Exhaust OK 43 degrees C / 109 degrees F FPC 4 Intake OK 31 degrees C / 87 degrees F FPC 4 Exhaust OK 42 degrees C / 107 degrees F FPM GBUS OK 33 degrees C / 91 degrees F

Fans Top Left Front fan OK Spinning at normal speed Top Right Rear fan OK Spinning at normal speed Top Right Front fan OK Spinning at normal speed Top Left Rear fan OK Spinning at normal speed Bottom Left Front fan OK Spinning at normal speed Bottom Right Rear fan OK Spinning at normal speed Bottom Right Front fan OK Spinning at normal speed Bottom Left Rear fan OK Spinning at normal speed Rear Fan 1 (TOP) OK Spinning at normal speed Rear Fan 2 OK Spinning at normal speed Rear Fan 3 OK Spinning at normal speed Rear Fan 4 OK Spinning at normal speed Rear Fan 5 OK Spinning at normal speed Rear Fan 6 OK Spinning at normal speed Rear Fan 7 (Bottom) OK Spinning at normal speedMisc CIP OK

show chassis environmentコマンドの実行によって、PEM、温度、およびファン動作の状態に関する情報が提供されることがわかります。ここには温度アラームも表示されます（show chassis alarmsコマンドで表示される）。これらは多くの場合、冷却システムの障害、ラックやシステムの誤配置、ファンの障害（show chassis environmentコマンドおよび show chassis alarmsコマンドの出力で表示される）などのサイトで発生した問題によって発せられます。

ヒントファンの障害や、ケーブルおよびサーキットブレーカの問題が原因ではない PEM障害については、一般的に、ジュニパーネットワークスの RMA（Return Material Authorization）が必要となり、JTAC（Juniper Technical Assistance Center）でチケットを発行してもらう必要があります。

シャーシコマンドメインシャーシレベルにおける他の懸念事項には、ルーティングエンジンの状態、FPC（Flexible PIC Concentrator）、およびPIC（Physical Inter-face Card）があります。show chassis routing-engineコマンド、show chassis fpcコマンド、および show chassis fpc pic-statusコマンドを実行することで、これらの情報を表示できます。以下に、単一のルーティングエンジンを備えるルーターに対して show

chassis routing-engineコマンドを実行したときの出力サンプルを示します。

ps@doppelbock> show chassis routing-engine Routing Engine status: Temperature 32 degrees C / 89 degrees F CPU temperature 32 degrees C / 89 degrees F



DRAM 512 MB Memory utilization 36 percent CPU utilization: User 2 percent Background 0 percent Kernel 4 percent Interrupt 0 percent Idle 94 percent Model RE-2.0 Serial ID c40000078cf97701 Start time 2010-01-12 05:56:58 EST Uptime 7 days, 21 hours, 4 seconds Load averages: 1 minute 5 minute 15 minute 0.08 0.02 0.01

この出力に、重要な情報が示されます。動作温度、CPU利用率、およびアップタイムは、どれも重要です。ネットワーク管理システムやルーター自体でも、一部の値（温度など）や関連するイベントでのしきい値違反を警告しますが、トラブルシューティングやデバイス全体の正常性診断を行う際には、CLIでのこうした出力を理解することも重要になります。

以下に、デュアルルーティングエンジンを備えるルーターに対して実行する show chassis routing-engineコマンド例を示します。スロット0の現在の状態は「Master」、slot 1は「Backup」であり、これらはデフォルトのマスター優先度であることに注意してください。

ps@dunkel-re0> show chassis routing-engine Routing Engine status: Slot 0: Current state Master Election priority Master Temperature 45 degrees C / 113 degrees F CPU temperature 51 degrees C / 123 degrees F DRAM 3584 MB Memory utilization 9 percent CPU utilization: User 0 percent Background 0 percent Kernel 3 percent Interrupt 0 percent Idle 97 percent Model RE-A-2000 Serial ID 1000702757 Start time 2010-01-19 11:42:50 PST Uptime 23 hours, 26 minutes, 46 seconds Load averages: 1 minute 5 minute 15 minute 0.00 0.04 0.05


Routing Engine status: Slot 1: Current state Backup Election priority Backup Temperature 43 degrees C / 109 degrees F CPU temperature 47 degrees C / 116 degrees F DRAM 3584 MB Memory utilization 8 percent CPU utilization: User 0 percent Background 0 percent Kernel 0 percent Interrupt 0 percent Idle 100 percent Model RE-A-2000 Serial ID 1000699981 Start time 2010-01-19 11:28:08 PST Uptime 23 hours, 41 minutes, 28 seconds

デュアルルーティングエンジンを備えたルーターに対する出力は、正常動作時に想定されるものです。ルーティングエンジンの Current

stateとして（以下のように）Presentが表示される場合は、さらに詳細な調査が必要です。

ps@dunkel-re0> show chassis routing-engine Routing Engine status: Slot 0: Current state Master Election priority Master Temperature 45 degrees C / 113 degrees F CPU temperature 52 degrees C / 125 degrees F DRAM 3584 MB Memory utilization 9 percent CPU utilization: User 0 percent Background 0 percent Kernel 3 percent Interrupt 1 percent Idle 97 percent Model RE-A-2000 Serial ID 1000702757 Start time 2010-01-19 11:42:50 PST Uptime 1 day, 39 minutes, 22 seconds Load averages: 1 minute 5 minute 15 minute 0.01 0.01 0.02Routing Engine status: Slot 1: Current state Present


Present状態にあるルーティングエンジンは、それがルーターに取り付けられているものの、正しく機能していないことを示します。他のルーティングエンジンが通常起動を実行していることが原因である可能性があります。しかし、この状態が継続する場合、またはルーティングエンジンがまったく表示されない場合は、高い確率でトラブルシューティングが必要となります。

可能であれば、デバイスをコンソールポートに接続してみます。コンソールポートが応答しない場合は、現場の技術者にルーティングエンジンの取り外しと取り付け直しを依頼し、その作業中にコンソールポートを監視してください。それでも画面上に出力されない場合、または出力されるがルーティングエンジンが起動しない場合は、さらに詳細なトラブルシューティングを行うために JTACにケースとして申請するか、RMAを依頼してください。show chassis fpcコマンドおよび show chassis fpc pic-statusコマンドを実行することで、取り付けてある FPCおよび PICの現在の状態に関する情報が提供されます。

ps@dunkel-re0> show chassis fpc Temp CPU Utilization (%) Memory Utilization (%)Slot State (C) Total Interrupt DRAM (MB) Heap Buffer 0 Online 42 2 0 1024 2 49 1 Online 40 1 0 1024 2 49 2 Online 41 1 0 1024 2 49 3 Online 43 1 0 1024 2 50 4 Online 42 1 0 1024 2 49 5 Empty 6 Empty 7 Empty ps@dunkel-re0> show chassis fpc pic-status Slot 0 Online M320 E2-FPC Type 3 PIC 0 Online 10x 1GE(LAN), 1000 BASE PIC 1 Online 10x 1GE(LAN), 1000 BASESlot 1 Online M320 E2-FPC Type 3 PIC 0 Online 4x OC-48 SONET PIC 1 Online 8x 1GE(TYPE3), IQ2Slot 2 Online M320 E2-FPC Type 2 PIC 0 Online 4x OC-12 SONET, SMIR PIC 1 Online 2x OC-12 ATM-II IQ, MMSlot 3 Online M320 E2-FPC Type 1 PIC 0 Online 1x OC-12 SONET, SMIR PIC 1 Online 1x OC-12 ATM-II IQ, MM PIC 2 Online 4x OC-3 SONET, SMIR PIC 3 Online 4x OC-3 SONET, MMSlot 4 Online M320 E2-FPC Type 1 PIC 0 Online 4x CHDS3 IQ PIC 2 Online 1x CHOC12 IQ SONET, SMIR PIC 3 Online 4x OC-3 SONET, SMIR


通常の FPCおよび PICについては、すべてのコンポーネントがOnlineであるとして表示される必要があります。他の状態である場合は、詳細な調査が必要となる可能性があります。FPCや PICは、ルーティングエンジンと同様、起動までに若干の時間を要します。そのため、ルーター、FPC、または PICを再起動した直後は Online以外の状態であっても問題はありません。

ただし、通常ではない状態が継続する場合は、最初のトラブルシューティングステップとしてPICまたは FPCの再起動を試みます。FPCを再起動するには、request chassis fpc slot [slot-number] restart

コマンドを実行します。ps@dunkel-re0> request chassis fpc slot 4 restart Restart initiated, use “show chassis fpc” to verify

show chassis fpcコマンドを繰り返し実行することで、FPCの再起動の進捗状況を追うことができます。

ps@dunkel-re0> show chassis fpc Temp CPU Utilization (%) Memory Utilization (%)Slot State (C) Total Interrupt DRAM (MB) Heap Buffer 0 Online 42 4 0 1024 2 49 1 Online 40 1 0 1024 2 49 2 Online 41 1 0 1024 2 49 3 Online 43 1 0 1024 2 50 4 Offline ---Restarted by cli command--- 5 Empty 6 Empty 7 Empty ps@dunkel-re0> show chassis fpc Temp CPU Utilization (%) Memory Utilization (%)Slot State (C) Total Interrupt DRAM (MB) Heap Buffer 0 Online 42 4 0 1024 2 49 1 Online 40 1 0 1024 2 49 2 Online 41 1 0 1024 2 49 3 Online 43 1 0 1024 2 50 4 Present 42 5 Empty 6 Empty 7 Empty ps@dunkel-re0> show chassis fpc Temp CPU Utilization (%) Memory Utilization (%)Slot State (C) Total Interrupt DRAM (MB) Heap Buffer 0 Online 42 4 0 1024 2 49 1 Online 40 1 0 1024 2 49 2 Online 41 1 0 1024 2 49 3 Online 43 1 0 1024 2 50 4 Online 40 1 0 1024 2 49 5 Empty 6 Empty 7 Empty


PICを再起動するには、まず request chassis pic fpc-slot [slot-

number] pic-slot [pic-slot number] offlineコマンドを実行します。show chassis pic fpc-slot [slot-number] pic-slot [pic-slot number]

コマンドを実行して、PICがオフライン状態にあることを確認します。次に、request chassis pic fpc-slot [slot-number] pic-slot [pic-slot

number] onlineコマンドを実行して、PICを再度オンライン状態にします。ps@dunkel-re0> request chassis pic fpc-slot 4 pic-slot 0 offline fpc 4 pic 0 offline initiated, use “show chassis fpc pic-status 4” to verifyps@dunkel-re0> show chassis pic fpc-slot 4 pic-slot 0 FPC slot 4, PIC slot 0 information: State Offline ps@dunkel-re0> request chassis pic fpc-slot 4 pic-slot 0 online fpc 4 pic 0 online initiated, use “show chassis fpc pic-status 4” to verifyps@dunkel-re0> show chassis pic fpc-slot 4 pic-slot 0 FPC slot 4, PIC slot 0 information: Type 4x CHDS3 IQ State Online PIC version 2.7 Uptime 1 second

問題が引き続き発生する場合は、ルーティングエンジンのトラブルシューティングセクションで説明したように、FPCまたは PICの取り付け直しを試みてください。それでも問題が解決できない場合は、JTACにケースとして申請してください。

ルーティングエンジン、FPC、または PICでの問題をケースとして申請するときには、request support informationコマンドの実行による出力と、messagesおよび chassisdログファイル（/var/logディレクトリ内に保存される）のコピーを JTACの新規ケースに添えて提出してください。

Request Support Informationコマンドrequest support informationコマンドは、多数の異なるCLIコマンドを自動的に実行するバッチコマンドです。これらのコマンドは、どのような問題のトラブルシューティングにおいても、ジュニパーネットワークスのサポート組織にとって非常に役立ちます。このコマンドの出力は、telnetまたは SSHクライアント内のバッファに保存するか、ルーターにローカルで保存してからFTP、SCP、または SFTPを用いて転送できます。

以下に SFTPを使用して request support informationコマンドの出力を保存および収集する方法の例を示します。request support informationコマンドを実行して、出力をファイルに保存します。

ps@dunkel-re0> request support information | save rsi-dunkel-01202010.log Wrote 7679 lines of output to ‘rsi-dunkel-01202010.log’


SFTPを使用して保存したファイルをダウンロードします。server-1>sftp ps@dunkelConnecting to dunkel...ps@dunkel’s password: sftp> get rsi-dunkel-01202010.logFetching /var/home/ps/rsi-dunkel-01202010.log to rsi-dunkel-01202010.log/var/home/ps/rsi-dunkel-01202010.log 100% 381KB 381.2KB/s 00:00

ログファイル

さらに、ルーター上の /var/logディレクトリ内に保存される messages

および chassisdログファイルのコピーは、JTACにとって非常に有益な情報となります。ルーターで SFTPセッションが開いている状態で、これらのファイルをコピーできます。

sftp> cd /var/logsftp> get messagesFetching /var/log/messages to messages/var/log/messages 100% 32KB 31.7KB/s 00:00 sftp> get chassisdFetching /var/log/chassisd to chassisd/var/log/chassisd 100% 1967KB 1.9MB/s 00:01

これで、JTACにケースを申請するために必要な情報がすべて揃いました。ジュニパーネットワークスのサポートチームが、以降のトラブルシューティングを支援し、必要に応じて交換ハードウェアを発注します。

まとめネットワーク管理システムは、ネットワークを能動的に監視し、具体的な値をポーリングして、ある程度まで問題を切り分けるための優れた方法ではあるものの、効率的にナビゲートできるCLIの機能にとって代わるものはありません。大半のリアルタイムトラブルシューティング、診断、および解決ステップでは CLIの使用が必要となるため、CLIをしっかりと理解することは不可欠です。Junos CLIおよびそれを用いて具体的な問題を監視およびトラブルシューティングする方法について書かれた書籍も数多く出版されています。本章では、いくつかの主要コマンドを紹介しました。以降の章では、デバイスの内部動作を調べるための CLIの操作方法について説明します。

さらに詳しくは Junosに関する詳細情報が必要ですか ?この Day Oneシリーズ『Junosの基本』の他のブックレットについては、http://www.

juniper.net/dayoneから入手可能です。

第4章

システムの監視および

トラブルシューティング

Syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40

SNMPポーリング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

SNMPトラップ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54


接続性やプロトコルを調べ始める前に、システムが正常に稼働していることを確認する必要があります。本章では、基本的な Syslog、SNMPポーリング、SNMPトラップ、およびCLIの操作について説明し、システムの運用状況を評価できるようにします。また、本章は、後述の監視およびトラブルシューティングに関する考察の基盤となります。

Syslog

システム管理者は、システムログ、変更ログ、およびインタラクティブコマンドを収集することで、そうした Syslogファイルを用いてトラブルシューティングと監視を行えるようになります。同時に、設定変更に合わせてネットワークイベントが発生しているかを確認する上でも役立ちます。Syslogファイルは、可能な状況で、問題の根本的原因を適切に警告、通知、および特定するために十分な情報を Syslogサーバーに提供することができます。ジュニパーネットワークスは、プラットフォームに応じて、ハードディスクドライブまたはコンパクトフラッシュディスクの /var/logディレクトリ内のファイルにメッセージを書き込むローカルロギングと、Syslogメッセージが遠隔地にある Syslogサーバーに送信されるリモートロギングの両方を提供します。

ベストプラクティスローカルのハードドライブまたはコンパクトフラッシュディスクに書き込まれるデータ量を制限するために、ローカルシステムロギングを少なめに設定することを推奨します。ロギングレベルは後から増加でき、トラブルシューティングが必要となったときに追加でトレーシングを有効にできます。

リモートシステムロギングの設定は、より自由度が高いものの、収集する情報の有用性に基づいて判断すべきです。習慣的に繰り返されるログメッセージの量が多くなると、実際の障害に関連するSyslogメッセージを探し出すのが難しくなり、問題の早期解決が行えないどころか、障害が長引くことになります。

また、ログ監視を行うのがシステムなのか人間なのかに応じて、収集対象となる Syslogメッセージを決定します。人間がログの監視を担当する場合、各メッセージは短く、重要なメッセージのみ記録すべきです。必要な状況下では、技術者に通知して、より詳細な調査を依頼します。ネットワーク監視システムで Syslogメッセージをトラッキングする場合、きめ細かな影響特定と根本的原因の正確な切り分けを行えるよう、より詳細なメッセージを収集することが役立ちます。

第4章：システムの監視およびトラブルシューティング 41

Syslogメッセージには、重要度 Syslogのタグが付けられます。重要度を低い方から高い方に並べると、以下のようになります。

Debug Info Notice Warning Error Critical Alert Emergency

注 Junosでは、Debugを除くすべての Syslog重要度をサポートします。

ここでは、以下の 3つの機能を実行するデフォルトの設定を示します。1. emergencyレベル以上のメッセージのユーザーへのログ記録が有効になります（メッセージはコンソールまたはターミナルに表示される）。

2. infoレベル以上の authorizationタイプのメッセージまたは noticeタイプ以上のメッセージは、/var/logに保存されるmessagesという名前のファイルに送信されます。

3. ユーザーが実行するインタラクティブコマンドは、interactive-commandsという名前のファイルに送信されます。このファイルも /var/logに保存されます。

ps@dunkel-re0> show configuration system syslog user * { any emergency;}file messages { any notice; authorization info;}file interactive-commands { interactive-commands any;}

デフォルト設定は、出発点としては良いですが、個別のニーズに合わせて調整する必要があります。技術者とNMSシステムのどちらも、この Syslogサーバーを使用するため、ログを大量に記録することなく必要な情報が十分に得られるようにします。

このサーバーに送信されるメッセージのファシリティーを設定します。ファシリティー（facility）も、システムログに付けられるタグの 1つで、Syslogサーバーで特定のメッセージをフィルタリングできるようにす

るものです。Syslogサーバー管理者は、このファシリティーを使用して、ファイルに送られるメッセージをフィルタリングします。以下のルーターは、追加のローカルロギングと、172.19.110.10にあるSyslogサーバーにシステムログを送信するよう設定されています。

ps@dunkel-re0> configure Entering configuration mode[edit]ps@dunkel-re0# set system syslog host 172.19.110.10 any notice [edit]ps@dunkel-re0# set system syslog host 172.19.110.10 interactive-commands any [edit]ps@dunkel-re0# set system syslog host 172.19.110.10 change-log any [edit]ps@dunkel-re0# set system syslog host 172.19.110.10 facility-override local3 [edit]ps@dunkel-re0# show system syslog user * { any emergency;}host 172.19.110.10 { any notice; change-log any; interactive-commands any; facility-override local3;}file messages { any notice; authorization info;}file interactive-commands { interactive-commands any;}[edit]ps@dunkel-re0# show | compare [edit system syslog]+ host 172.19.110.10 {+ any notice;+ change-log any;+ interactive-commands any;+ facility-override local3;+ }[edit]ps@dunkel-re0# commit commit complete

これにより、Syslogサーバーでは noticeレベルのログ、変更ログ、インタラクティブコマンドを受け取り、それらは local3のファシリティーオーバーライドで送信されます。



Syslogサーバーでは、レイヤー 1での問題を含め、大半の問題のトラブルシューティングを行うために必要なすべての情報を受信するようになります。しかし、前述のように、すべてのトラブルシューティングステップは、ネットワークの別のソースから裏付けされる必要があります。そこで、リンク遷移をトリガーするフィックステストを実行して、Syslogサーバーで通知を受け取るかどうかを監視します。so-3/3/2の SONETリンクを無効化します。

ps@dunkel-re0> configure Entering configuration mode[edit]ps@dunkel-re0# set interfaces so-3/3/2 disable [edit]ps@dunkel-re0# commit commit completeResulting syslog message:Jan 19 15:48:41 172.19.110.171 mib2d[4549]:SNMP_TRAP_LINK_DOWN: ifIndex 151, ifAdminStatus down(2), ifOperStatus down(2), ifName so-3/3/2

Syslogメッセージは太字で表示されています。正しく機能していることがわかります。

正しく機能するデフォルトの Syslogモデルが完成しました。短期的なトラブルシューティング向けに、後でこれを修正できますが、ここでは他の状況にも使用できるようSyslogテンプレートとして保存します。

SNMPポーリングSyslogが設定できたので、次に SNMP（Simple Network Management Protocol）について説明します。SNMPを使用することで、クエリーに受動的に応答するか、あるいはトラップと呼ばれるSNMPメッセージを能動的に送信できます。

注ジュニパーネットワークスのルーターでは、SNMPはデフォルトで無効化されています。

まず、特定のアドレスからの SNMPポーリングを実行できるようルーターを設定し、SNMPコミュニティとして tr4pp15tを設定します（SNMPコミュニティとは、クエリーを実行するエンティティーを認証するためのシンプルなパスワードである）。

ps@dunkel-re0> configure Entering configuration mode[edit]ps@dunkel-re0# set snmp community tr4pp15t authorization read-only [edit]ps@dunkel-re0# set snmp community tr4pp15t clients 172.19.110.10/32 [edit]ps@dunkel-re0# show snmp


community tr4pp15t { authorization read-only; clients { 172.19.110.10/32; }}[edit]ps@dunkel-re0# show | compare [edit snmp]+ community tr4pp15t {+ authorization read-only;+ clients {+ 172.19.110.10/32;+ }+ }[edit]ps@dunkel-re0# commit commit complete

この設定により、172.19.110.10にある SNMPサーバーからの読み込み専用 SNMPアクセスが許可されます。

SNMPサーバーでは、ルーターの SNMPポーリングを実行するために、tr4pp15tコミュニティを使用しなければなりません。これをテストするために、172.19.110.10（nms-1）からルーターに、SNMPクエリーsystem.sysDescr.0を送信します。

注 system.sysDescr.0文字列は、どの値に応答すべきかをルーターに指示するオブジェクト識別子（OID：Object Identifier）です。

この例では、Junosデバイスからシステム情報が提供される system.

sysDescr.0 OIDをクエリーします。この文字列でクエリーすると、Junosからベンダー、プラットフォーム、カーネル、およびビルド情報が提供されます。

nms-1> snmpget -v2c -c tr4pp15t dunkel system.sysDescr.0SNMPv2-MIB::sysDescr.0 = STRING:Juniper Networks, Inc. m320 internet router, kernel Junos 10.1R1.8 #0:2010-02-12 17:15:05 UTC [email protected]:/volume/build/Junos/10.1/release/10.1R1.8/obj-i386/bsd/sys/compile/JUNIPER Build date:2010-02-12 16:37:34 UTC Copyright (c) 1996

設定内容を裏付けるために、別のサーバーからルーターの SNMPポーリングを試します。

server-1> snmpget -v2c -c tr4pp15t dunkel system.sysDescr.0Timeout:No Response from dunkel.

クエリーがタイムアウトしたため、172.19.110.10からの SNMPクエリーのみをルーターでリッスンしていることがわかります。


情報をクエリーできる SNMPオブジェクトは多数あります。これらオブジェクトの多くは、有効化されているサービス、プロトコル、および設定に依存します。

ベストプラクティスジュニパーネットワークスでは、以下のベースオブジェクトを設定してシステム運用状況を監視することを推奨します。

� ハードウェア一覧 � ルーティングエンジン CPU利用率 � ルーティングエンジンメモリ利用率 � ルーティングエンジン温度

以降のセクションで、これらの SNMPオブジェクトについて詳しく説明します。

ハードウェア一覧

デバイスのハードウェア一覧をポーリングするには、snmpwalkユーティリティを使用して、指定した値からSNMPツリーを順次たどり、情報を取得します。ハードウェア一覧のOIDは、.1.3.6.1.4.1.2636.3.1.13.1.5です。

nms-1> snmpwalk -v2c -c tr4pp15t dunkel .1.3.6.1.4.1.2636.3.1.13.1.5SNMPv2-SMI::enterprises.2636.3.1.13.1.5.1.1.0.0 = STRING:“midplane”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.2.1.0.0 = STRING:“PEM 0”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.2.2.0.0 = STRING:“PEM 1”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.2.3.0.0 = STRING:“PEM 2”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.2.4.0.0 = STRING:“PEM 3”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.4.1.1.0 = STRING:“Top Left Front fan”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.4.1.2.0 = STRING:“Top Right Rear fan”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.4.1.3.0 = STRING:“Top Right Front fan”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.4.1.4.0 = STRING:“Top Left Rear fan”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.4.2.1.0 = STRING:“Bottom Left Front fan”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.4.2.2.0 = STRING:“Bottom Right Rear fan”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.4.2.3.0 = STRING:“Bottom Right Front fan”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.4.2.4.0 = STRING:“Bottom Left Rear fan”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.4.3.1.0 = STRING:“Rear Fan 1 (TOP)”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.4.3.2.0 = STRING:“Rear Fan 2”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.4.3.3.0 = STRING:“Rear Fan 3”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.4.3.4.0 = STRING:“Rear Fan 4”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.4.3.5.0 = STRING:“Rear Fan 5”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.4.3.6.0 = STRING:“Rear Fan 6”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.4.3.7.0 = STRING:“Rear Fan 7 (Bottom)”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.7.1.0.0 = STRING:“FPC:M320 E2-FPC Type 3 @ 0/*/*”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.7.2.0.0 = STRING:“FPC:M320 E2-FPC Type 3 @ 1/*/*”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.7.3.0.0 = STRING:“FPC:M320 E2-FPC Type 2 @


2/*/*”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.7.4.0.0 = STRING:“FPC:M320 E2-FPC Type 1 @ 3/*/*”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.7.5.0.0 = STRING:“FPC:M320 E2-FPC Type 1 @ 4/*/*”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.8.1.1.0 = STRING:“PIC:10x 1GE(LAN), 1000 BASE @ 0/0/*”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.8.1.2.0 = STRING:“PIC:10x 1GE(LAN), 1000 BASE @ 0/1/*”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.8.2.1.0 = STRING:“PIC:4x OC-48 SONET @ 1/0/*”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.8.2.2.0 = STRING:“PIC:8x 1GE(TYPE3), IQ2 @ 1/1/*”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.8.3.1.0 = STRING:“PIC:4x OC-12 SONET, SMIR @ 2/0/*”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.8.3.2.0 = STRING:“PIC:2x OC-12 ATM-II IQ, MM @ 2/1/*”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.8.4.1.0 = STRING:“PIC:1x OC-12 SONET, SMIR @ 3/0/*”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.8.4.2.0 = STRING:“PIC:1x OC-12 ATM-II IQ, MM @ 3/1/*”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.8.4.3.0 = STRING:“PIC:4x OC-3 SONET, SMIR @ 3/2/*”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.8.4.4.0 = STRING:“PIC:4x OC-3 SONET, MM @ 3/3/*”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.8.5.1.0 = STRING:“PIC:4x CHDS3 IQ @ 4/0/*”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.8.5.3.0 = STRING:“PIC:1x CHOC12 IQ SONET, SMIR @ 4/2/*”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.8.5.4.0 = STRING:“PIC:4x OC-3 SONET, SMIR @ 4/3/*”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.9.1.0.0 = STRING:“Routing Engine 0”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.9.2.0.0 = STRING:“Routing Engine 1”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.10.1.1.0 = STRING:“FPM GBUS”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.10.1.2.0 = STRING:“FPM Display”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.12.1.0.0 = STRING:“CB 0”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.12.2.0.0 = STRING:“CB 1”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.15.1.0.0 = STRING:“SIB 0”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.15.2.0.0 = STRING:“SIB 1”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.15.3.0.0 = STRING:“SIB 2”SNMPv2-SMI::enterprises.2636.3.1.13.1.5.15.4.0.0 = STRING:“SIB 3”

環境に関連する値を得るには、オペレーターは、コンポーネントのハードウェアエントリーの末尾 4オクテットを取り、次のセクションのオブジェクトにそれを連結させる必要があります（ルーティングエンジンの末尾 4オクテットを太字表示してある）。


ルーティングエンジンCPU利用率

ハードウェア一覧クエリーから得た情報に基づいて、シャーシに取り付けられた 2つのルーティングエンジンの CPU利用率を取得するための新しいクエリーを作成します。これを行うには、CPU利用率OIDに 9.1.0.0および 9.2.0.0を追加します。

CPU Utilization OID:.1.3.6.1.4.1.2636.3.1.13.1.8.x.x.x.x

例：nms-1> snmpwalk -v2c -c tr4pp15t dunkel .1.3.6.1.4.1.2636.3.1.13.1.8.9.1.0.0SNMPv2-SMI::enterprises.2636.3.1.13.1.8.9.1.0.0 = Gauge32:3nms-1> snmpwalk -v2c -c tr4pp15t dunkel .1.3.6.1.4.1.2636.3.1.13.1.8.9.2.0.0SNMPv2-SMI::enterprises.2636.3.1.13.1.8.9.2.0.0 = Gauge32:0

これにより、ルーティングエンジン 0の CPU利用率は 3%、ルーティングエンジン 1の CPU利用率は 0%であることがわかります。ルーティングエンジン 0はプライマリルーティングエンジンで、ルーティングエンジン 1はバックアップであるため、正しい数値です。

これらの値を必ず別のソースから裏付けることを心がけているため、ルーターに対してshow chassis routing-engineコマンドを実行します。

ps@dunkel-re0> show chassis routing-engine Routing Engine status: Slot 0: Current state Master Election priority Master Temperature 45 degrees C / 113 degrees F CPU temperature 52 degrees C / 125 degrees F DRAM 3584 MB Memory utilization 9 percent CPU utilization: User 0 percent Background 0 percent Kernel 3 percent Interrupt 0 percent Idle 97 percent Model RE-A-2000 Serial ID 1000702757 Start time 2010-01-19 11:42:50 PST Uptime 21 hours, 50 minutes, 15 seconds Load averages: 1 minute 5 minute 15 minute 0.00 0.03 0.02Routing Engine status: Slot 1: Current state Backup Election priority Backup Temperature 43 degrees C / 109 degrees F CPU temperature 47 degrees C / 116 degrees F


DRAM 3584 MB Memory utilization 8 percent CPU utilization: User 0 percent Background 0 percent Kernel 0 percent Interrupt 0 percent Idle 100 percent Model RE-A-2000 Serial ID 1000699981 Start time 2010-01-19 11:28:08 PST Uptime 22 hours, 4 minutes, 52 seconds

このように、アイドル値が利用率値に一致します。利用率値とアイドル値の合計は、必ず 100%となることに注意してください。ルーティングエンジン 0 - 3% + 97% = 100%

ルーティングエンジン 1 - 0% + 100% = 100%

ルーティングエンジンメモリ利用率

SNMPを使用して、メモリ利用率を監視することもできます。ここでも、前述のハードウェア一覧クエリーで取得したハードウェアインデックスと、メモリ利用率OIDを組み合わせる方法をとります。

Memory Utilization OID:.1.3.6.1.4.1.2636.3.1.13.1.11.x.x.x.xWarning level:70%

例：nms1> snmpwalk -v2c -c tr4pp15t dunkel .1.3.6.1.4.1.2636.3.1.13.1.11.9.1.0.0SNMPv2-SMI::enterprises.2636.3.1.13.1.11.9.1.0.0 = Gauge32:9nms-1> snmpwalk -v2c -c tr4pp15t dunkel .1.3.6.1.4.1.2636.3.1.13.1.11.9.2.0.0SNMPv2-SMI::enterprises.2636.3.1.13.1.11.9.2.0.0 = Gauge32:8

ルーティングエンジン 0はメモリ利用率 9%で稼働し、ルーティングエンジン 1はメモリ利用率 8%で稼働していることが示されています。ここでも裏付けのために、ルーターに対して show chassis routing-

engineコマンドを実行します。ps@dunkel-re0> show chassis routing-engine Routing Engine status: Slot 0: Current state Master Election priority Master Temperature 45 degrees C / 113 degrees F CPU temperature 52 degrees C / 125 degrees F DRAM 3584 MB


Memory utilization 9 percent CPU utilization: User 0 percent Background 0 percent Kernel 3 percent Interrupt 0 percent Idle 97 percent Model RE-A-2000 Serial ID 1000702757 Start time 2010-01-19 11:42:50 PST Uptime 21 hours, 50 minutes, 15 seconds Load averages: 1 minute 5 minute 15 minute 0.00 0.03 0.02Routing Engine status: Slot 1: Current state Backup Election priority Backup Temperature 43 degrees C / 109 degrees F CPU temperature 47 degrees C / 116 degrees F DRAM 3584 MB Memory utilization 8 percent CPU utilization: User 0 percent Background 0 percent Kernel 0 percent Interrupt 0 percent Idle 100 percent Model RE-A-2000 Serial ID 1000699981 Start time 2010-01-19 11:28:08 PST Uptime 22 hours, 4 minutes, 52 seconds

裏付けテストにより、メモリ利用率の値が正しいことが実証されました。

ルーティングエンジン温度

情報をクエリーできる次の SNMPオブジェクトは、ルーティングエンジンの温度です。ジュニパーネットワークスのルーターは、高温時を示すハイレベルの赤いアラームが宣言されたときには自動的に電源を切って機器自体を保護しますが、悪影響を及ぼす前に問題を特定できるよう、ルーターのポーリングを行うことも重要です。しきい値は、プラットフォームやコンポーネントごとに異なります。show chassis

temperature-thresholdsコマンドを実行することで、各コンポーネントのしきい値を表示できます。


以下に show chassis temperature-thresholdsコマンドの出力サンプルを示します。いくつかの FPCおよび FEB（Forwarding Engine Board）を備えるデュアルルーティングエンジンのシャーシが示されています。

ps@dunkel-re0> show chassis temperature-thresholds Fan speed Yellow alarm Red alarmItem Normal High Normal Bad fan Normal Bad fanChassis default 48 54 65 55 75 65Routing Engine 0 70 80 95 95 110 110Routing Engine 1 70 80 95 95 110 110FPC 0 55 60 75 65 90 80FPC 1 55 60 75 65 90 80FPC 2 48 54 70 60 80 70FPC 3 48 54 70 60 80 70FPC 4 48 54 70 60 80 70FPC 5 48 54 70 60 80 70FEB 0 48 54 70 60 80 72FEB 1 48 54 70 60 80 72FEB 2 48 54 70 60 80 72FEB 3 48 54 70 60 80 72FEB 4 48 54 70 60 80 72FEB 5 48 54 70 60 80

コンポーネント温度のクエリーで使用した SNMPオブジェクトは、.1.3.6.1.4.1.2636.3.1.13.1.7.x.x.x.xです。ここでも前述の連結処理を使用します。以下にいくつかの例を示します。まずは、ルーティングエンジン 0（9.1.0.0）です。

nms1 > snmpwalk -v2c -c tr4pp15t dunkel .1.3.6.1.4.1.2636.3.1.13.1.7.9.1.0.0SNMPv2-SMI::enterprises.2636.3.1.13.1.7.9.1.0.0 = Gauge32:45

次は、ルーティングエンジン 1（9.2.0.0）です。nms-1> snmpwalk -v2c -c tr4pp15t dunkel .1.3.6.1.4.1.2636.3.1.13.1.7.9.2.0.0SNMPv2-SMI::enterprises.2636.3.1.13.1.7.9.2.0.0 = Gauge32:43

show chassis routing-engineコマンドを使用して、SNMP値が正しいことを実証します。

ps@dunkel-re0> show chassis routing-engine Routing Engine status: Slot 0: Current state Master Election priority Master Temperature 45 degrees C / 113 degrees F CPU temperature 52 degrees C / 125 degrees F DRAM 3584 MB Memory utilization 9 percent CPU utilization:


User 0 percent Background 0 percent Kernel 2 percent Interrupt 0 percent Idle 97 percent Model RE-A-2000 Serial ID 1000702757 Start time 2010-01-19 11:42:50 PST Uptime 22 hours, 2 minutes, 35 seconds Load averages: 1 minute 5 minute 15 minute 0.00 0.00 0.00Routing Engine status: Slot 1: Current state Backup Election priority Backup Temperature 43 degrees C / 109 degrees F CPU temperature 47 degrees C / 116 degrees F DRAM 3584 MB Memory utilization 8 percent CPU utilization: User 0 percent Background 0 percent Kernel 0 percent Interrupt 0 percent Idle 100 percent Model RE-A-2000 Serial ID 1000699981 Start time 2010-01-19 11:28:08 PST Uptime 22 hours, 17 minutes, 14 seconds

ここに示した SNMPクエリーから返された温度値は、CLI出力に一致しています。

SNMPトラップSNMPを使用することで、ポーリングだけでなく、特定の状況下で能動的にトラップを送信することができます。ネットワークデバイスから監視システムに対して積極的に問題やイベントが発生していることを伝達できるため、どのような NMSシステムにとっても極めて重要な機能です。正しく設定した SNMPトラップとSyslogメッセージを組み合わせることで、NMSシステムでネットワークを効率的に監視するために必要なものがすべて揃います。SNMPトラップ設定は、前のステップで実装した SNMPポーリング設定と似ています。唯一の違いは、SNMPコミュニティを追加で設定し、SNMPサーバーを追加しなければならない点です。まず、コミュニティとして tr4pp15tを設定した、172.19.110.10への SNMPトラップを設定します。ポーリング用に設定したコミュニティをトラップ用に使用することもできます。


さらに、受信するトラップのタイプも指定します。これらの追加設定を伴うSNMPは、以下のように設定します。

ps@dunkel-re0> configure Entering configuration mode[edit]ps@dunkel-re0# set snmp trap-group tr4pp15t targets 172.19.110.10 [edit]ps@dunkel-re0# set snmp trap-group tr4pp15t categories ? Possible completions:+ apply-groups Groups from which to inherit configuration data+ apply-groups-except Don’t inherit configuration data from these groups authentication Authentication failures chassis Chassis or environment notifications configuration Configuration notifications link Link up-down transitions remote-operations Remote operations rmon-alarm RMON rising and falling alarms routing Routing protocol notifications services Services notifications> sonet-alarms SONET alarm trap subcategories startup System warm and cold starts vrrp-events VRRP notifications

ここで、認証、シャーシ、設定、リンク、ルーティング、SONETアラーム、および起動の各カテゴリーに対してトラップを設定します。

[edit]ps@dunkel-re0# set snmp trap-group tr4pp15t categories authentication [edit]ps@dunkel-re0# set snmp trap-group tr4pp15t categories chassis [edit]ps@dunkel-re0# set snmp trap-group tr4pp15t categories configuration [edit]ps@dunkel-re0# set snmp trap-group tr4pp15t categories link [edit]ps@dunkel-re0# set snmp trap-group tr4pp15t categories routing [edit]ps@dunkel-re0# set snmp trap-group tr4pp15t categories sonet-alarms [edit]ps@dunkel-re0# set snmp trap-group tr4pp15t categories startup

show snmpコマンドを実行して（設定モードで）、加えた変更を含むSNMP設定を表示します。


[edit]ps@dunkel-re0# show snmp community tr4pp15t { authorization read-only; clients { 172.19.110.10/32; }}trap-group tr4pp15t { categories { authentication; chassis; link; routing; startup; configuration; sonet-alarms; } targets { 172.19.110.10; }}

このように、SNMP設定には、読み込み専用アクセスが与えられ、tr4pp15tコミュニティを使用したポーリングが許可されるポーリング元 172.19.110.10が含まれています。また、同じ tr4pp15tコミュニティを使用して、いくつかの異なるカテゴリーについて 172.10.110.10にSNMPトラップを送信する、SNMPトラップグループも含まれています。show | compareコマンドを実行して、設定（この場合は SNMP設定）に加えた変更を表示します。「-」は、削除項目を表し、「+」は追加項目を示します。

[edit]ps@dunkel-re0# show | compare [edit snmp]+ trap-group tr4pp15t {+ categories {+ authentication;+ chassis;+ link;+ routing;+ startup;+ configuration;+ sonet-alarms;+ }+ targets {+ 172.19.110.10;+ }+ }


設定をコミットします。[edit]ps@dunkel-re0# commit commit complete

ここでリンク遷移をトリガーして、設定内容の検証と裏付けを行います。ここでは、so-3/3/2の SONETリンクを無効化して、その結果を確認してみます。

ps@dunkel-re0> configure Entering configuration mode[edit]ps@dunkel-re0# set interfaces so-3/3/2 disable [edit]ps@dunkel-re0# commit commit complete

Resulting SNMP trap:

172.19.110.171:Link Down Trap (0) Uptime:22:24:50.09, IF-MIB::ifIndex.154 = INTEGER:154, IF-MIB::ifAdminStatus.154 = INTEGER: down(2), IF-MIB::ifOperStatus.154 = INTEGER: down(2), IF-MIB::ifName.154 = STRING: so-3/3/2

想定どおりに、SNMPトラップがトリガーされました。

まとめ運用状況の良いネットワークを稼働させるために、ネットワーク管理システムを実装し、その NMSシステムで効果的に問題を特定および通知するために必要なログやトラップを設定することは、必要な作業の半分しか占めていません。ここで説明したのは、運用状況の良いどのようなネットワークにとっても重要となる、先を見越して積極的に行う監視およびトラブルシューティングです。以降の章では、NMSを補完する、Junos CLIを介した能動的なトラブルシューティング（および監視）について説明します。

第5章

レイヤー1およびレイヤー2の監視

およびトラブルシューティング

重要なインタフェースコマンド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56

レイヤー1の監視およびトラブルシューティング . . . . . . . . . . . . . . . . . . . . . . . . . . .56

SONETアラームおよび不具合 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

レイヤー2の監視およびトラブルシューティング . . . . . . . . . . . . . . . . . . . . . . . . . .65

まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72


ネットワークの監視およびトラブルシューティングにおいては、OSIモデルのパラダイムを用いるのが有効な手段となります。これはネットワーク問題の根本的原因の多くは、レイヤー 1とレイヤー 2に存在するためであり、上位レイヤーのトラブルシューティングに不必要な時間を費やすことも珍しくありません。そのため、最初にレイヤー 1とレイヤー 2でネットワーク問題をトラブルシューティングするような手順を実践すべきです。レイヤー 1とレイヤー 2を調査し、あらゆる場所を監視およびトラブルシューティングする際、繰り返し見られる原則がいくつかあることに気付くことでしょう。そのテクノロジーが提供する各種機能を用いて、これらのレイヤーにおけるルーターおよびスイッチの役割を理解してください。

警告 ! これ以降の章やセクションでは、監視およびトラブルシューティングという用語は（第 3章と第 4章で説明したように）Syslogおよび SNMPトラップを指します。また、本書で示す SyslogおよびSNMP設定に近いものが、すでに設定されていることを前提とします。

ジュニパーネットワークスのルーターは、SONET、ISDN、イーサネット、PPPをはじめ、多数のレイヤー 1およびレイヤー 2技術をサポートします。Junosでは、これらプロトコルの運用を監視するために、各種のシステムロギング、SNMP、および操作機能が提供されます。SyslogとSNMPは、リンクダウンやリンクアップなど、レイヤー 1およびレイヤー 2での問題に対して、ハイレベルで有用な情報を提示します。さらに詳細に監視するには、トレーシング設定や一部のコマンドラインの操作が必要になります。

重要なインタフェースコマンドインタフェースの監視で使用する最も重要な CLIコマンドは、show

interface extensiveおよび monitor interfaceです。 show interface extensiveコマンドには、物理（レイヤー 1および 2）インタフェースと設定した論理（レイヤー 2および 3）インタフェースの両方に関するすべての情報が含まれます。

レイヤー 1の監視およびトラブルシューティングレイヤー 1は、ネットワーク構成要素が手の加えられていないデータを、媒体を介して送受信するための方法を定義する、OSIモデル内の基盤レイヤーです。レイヤー 1プロトコルとして良く知られるものに、SONET/SDHおよびイーサネットがあります。以下の例ではSONETを使用していますが、ここで示す方法はどのレイヤー 1技術にも適用できます。

第5章：レイヤー1およびレイヤー2の監視およびトラブルシューティング 57

以下に SONETインタフェースに対して実行した show interface

extensiveコマンドの出力サンプルを示します。注目すべきセクションは太字で表示しており、出力サンプルの後に説明します。

ps@dunkel-re0> show interfaces so-2/0/0 extensive Physical interface: so-2/0/0, Enabled, Physical link is Up Interface index:162, SNMP ifIndex:154, Generation:163 Link-level type:PPP, MTU:4474, Clocking:Internal, SONET mode, Speed:OC12, Loopback:None, FCS:16, Payload scrambler:Enabled Device flags :Present Running Interface flags:Point-To-Point SNMP-Traps Internal:0x4000 Link flags :Keepalives Hold-times :Up 0 ms, Down 0 ms Keepalive settings:Interval 10 seconds, Up-count 1, Down-count 3 Keepalive statistics: Input :0 (last seen: never) Output:0 (last sent: never) LCP state:Opened NCP state:inet:Opened, inet6:Not-configured, iso:Not-configured, mpls: Not-configured CHAP state:Closed PAP state:Closed CoS queues :8 supported, 8 maximum usable queues Last flapped :2010-01-19 11:49:06 PST (1d 02:43 ago) Statistics last cleared:2010-01-20 14:32:52 PST (00:00:02 ago) Traffic statistics: Input bytes : 192 760 bps Output bytes : 89 808 bps Input packets: 4 1 pps Output packets: 1 1 pps IPv6 transit statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0 Input errors: Errors:0, Drops:0, Framing errors:0, Runts:0, Giants:0, Bucket drops:0, Policed discards:0, L3 incompletes:0, L2 channel errors:0, L2 mismatch timeouts:0, HS link CRC errors:0, HS link FIFO overflows:0 Output errors: Carrier transitions:0, Errors:0, Drops:0, Aged packets:0, HS link FIFO underflows:0, MTU errors:0 Egress queues:8 supported, 4 in use Queue counters: Queued packets Transmitted packets Dropped packets 0 best-effort 2 2 0 1 expedited-fo 0 0 0 2 assured-forw 0 0 0 3 network-cont 2 2 0 SONET alarms :None SONET defects :None

SONET PHY: Seconds Count State PLL Lock 0 0 OK PHY Light 0 0 OK SONET section: BIP-B1 0 0 SEF 0 0 OK LOS 0 0 OK LOF 0 0 OK ES-S 0 SES-S 0 SEFS-S 0 SONET line: BIP-B2 0 0 REI-L 0 0 RDI-L 0 0 OK AIS-L 0 0 OK BERR-SF 0 0 OK BERR-SD 0 0 OK ES-L 0 SES-L 0 UAS-L 0 ES-LFE 0 SES-LFE 0 UAS-LFE 0 SONET path: BIP-B3 0 0 REI-P 0 0 LOP-P 0 0 OK AIS-P 0 0 OK RDI-P 0 0 OK UNEQ-P 0 0 OK PLM-P 0 0 OK ES-P 0 SES-P 0 UAS-P 0 ES-PFE 0 SES-PFE 0 UAS-PFE 0 Received SONET overhead: F1 :0x00, J0 :0x00, K1 :0x00, K2 :0x00 S1 :0x00, C2 :0xcf, C2(cmp) :0xcf, F2 :0x00 Z3 :0x00, Z4 :0x00, S1(cmp) :0x00 Transmitted SONET overhead: F1 :0x00, J0 :0x01, K1 :0x00, K2 :0x00 S1 :0x00, C2 :0xcf, F2 :0x00, Z3 :0x00 Z4 :0x00 Received path trace: pilsener-re0 so-2/2/0 70 69 6c 73 65 6e 65 72 2d 72 65 30 20 73 6f 2d pilsener-re0 so- 32 2f 32 2f 30 00 00 00 00 00 00 00 00 00 00 00 2/2/0........... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0d 00 ................



Transmitted path trace: dunkel-re0 so-2/0/0 64 75 6e 6b 65 6c 2d 72 65 30 20 73 6f 2d 32 2f dunkel-re0 so-2/ 30 2f 30 00 00 00 00 00 00 00 00 00 00 00 00 00 0/0............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ HDLC configuration: Policing bucket:Disabled Shaping bucket :Disabled Giant threshold:4484, Runt threshold:3 Packet Forwarding Engine configuration: Destination slot:2, PLP byte:1 (0x00) Direction :Output CoS transmit queue Bandwidth Buffer Priority Limit % bps % usec 0 best-effort 95 590976000 95 0 low none 3 network-control 5 31104000 5 0 low none Logical interface so-2/0/0.0 (Index 66) (SNMP ifIndex 179) (Generation 134) Flags:Point-To-Point SNMP-Traps 0x4000 Encapsulation:PPP Protocol inet, MTU:4470, Generation:141, Route table:0 Addresses, Flags:Is-Preferred Is-Primary Destination:18.32.74.0/30, Local:18.32.74.1, Broadcast:18.32.74.3, Generation:144

実際に show interface extensiveコマンドまたは monitor interface

コマンドを実行したときに何に注目すべきかを理解できるよう、この出力をレイヤー単位で詳細に見ていきます。レイヤー 1およびレイヤー 2技術の監視およびトラブルシューティングで重要なことは、プロトコルによる監視方法、エラーによる接続動作の影響、およびそれらのエラーがどのようにオペレータに表示されるかを理解することです。

SONETモード

ジュニパーネットワークスの SONET PICは、SONETモードまたはSDHモードで動作します。

SONET（Synchronous Optical Networking）および SDH （Synchronous Digital Hierarchy）は、Telcordia Technologies社の『Generic Requirements documents GR-253-CORE』の一部として開発されました。この文書では、光ファイバーケーブルを介してビットストリームを多重化する 2つの方法について解説しています。SONETとSDHは、非常に良く似たプロトコルです。SDHは後から開発されたもので、SONETの上位集合と見なすことができますが、SDHは世界中で採用されているのに対して、SONETの採用は北米に限定されるため、SDHが標準として捉えられています。


プロトコルの実際の仕組みは非常に複雑であり、本書が目的とする範囲を超えます。ここで把握すべきことは、SONET/SDHレイヤーによって実行されるカプセル化とインターリービングにより、極めて低遅延が実現できる点です。SONET/SDH設定は、シャーシ階層レベルで行われ、PIC上の全ポートに適用されます。SONETとSDHの不一致があると、SONETフレーム同期損失エラー（後述）を引き起こすことがあります。

FCS

FCS、すなわちフレームチェックサムは、パケット検証に用いられます。ジュニパーネットワークスのデバイスは、デフォルト動作として 16ビットフレームチェックサムを使用しますが、信頼性を向上させる 32ビットチェックサムで設定することもできます。ただし、ネットワーク構成要素によってはサポートされない場合もあります。

チェックサムエラーを特定する最も早い方法は、show interface

[interface name] extensiveコマンドを繰り返し実行するか、monitor

interface [interface name]コマンドを使用して、フレーミングエラーを監視する方法です。フレーミングエラーが急速に増加する場合は、一般に、チェックサムエラーの発生を示しています。

ペイロードスクランブリングペイロードスクランブリング（showコマンドの出力で太字表示）は、SONET接続障害の多くのケースで原因とされるものです。多くのSONETパラメータと同様、ペイロードスクランブリングは回線の両端で一致しなければなりません。両端の間で不一致があると、SONETエラーを引き起こします。

ITU-T GR-253標準など、いくつかの転送標準では、デジタルストリーム中に、ある一定の密度で（0ではなく）1が含まれている必要があります。この要件が課せられる主な理由は、タイミングリカバリのためです。例えば、T1で必要となる 1の割合は 12.5%、すなわち 1バイト当たり 1ビットです。

この要件を満たすために、暗号化アルゴリズムとしてペイロードスクランブリングを使用し、ジュニパーネットワークスのルーターの SONETインタフェースで、デフォルトで有効化されるようにします。ペイロードスクランブリング不一致のトラブルシューティングには、注意が必要です。ペイロードスクランブリング不一致は、接続のどちら側でもSONETレイヤー問題（不具合など）を引き起こすことはありませんが、ペイロードスクランブリングが有効化されたログを設定してある側では、ジュニパーネットワークスのルーターで giant（ジャイアント）と表示されるエラーが記録されます。ペイロードスクランブリングが設定されていない側では、フレーミングエラーが表示されます。


ベストプラクティス FCSと同様、両側で同じ内容のペイロードスクランブリングが設定されていることを確認してください。また、両側でペイロードスクランブリングを設定することを推奨します。

入力エラーさまざまな SONETエラーによって入力エラーがトリガーされます。原因はそれぞれ異なるものの、何らかの問題を示しており、原因の調査と修正が必要です。フレーミングエラー、ラント、ジャイアントは、通常は設定の誤りが原因です。フレーミングエラーは、FCSの不一致（例えば、一方の側が 16、もう一方が 32など）またはペイロードスクランブリングの不一致が原因で発生します。

ラントは、受信パケットが最小フレームサイズ（SONETでは 64バイト）より小さいときに発生します。これらは主にケーブル配線や接続の問題によって生じるため、限られたケースです。

ジャイアントは、受信パケットが最大フレームサイズ（16KB）より大きいときに発生します。これらは、前述のようにペイロードスクランブリングの不一致が原因で発生することもありますが、他の条件によって起こることもあります。入力ジャイアントが継続し、原因として設定の不一致を除外できる場合は、回線プロバイダに連絡して問題を解決するための支援を要請してください。

SONETアラームおよび不具合SONETは、ジュニパーネットワークスのデバイスで採用される最も複雑なレイヤー 1技術であるため、レイヤー 1におけるトラブルシューティング例として用いることにします。SONETリンクのトラブルシューティングでは、SONETの階層特性を理解することが重要です。SONET/SDH階層は、図5-1に示すように、セクション、ライン、パスレイヤーの 3つのレイヤーで構成されます。

階層の最下位レベルにあるセクションは、ルーター、信号再生器、または ADM（Add-Drop Multiplexor）などのネットワーク構成要素で終端可能な単一の光ファイバー接続として定義されます。この役割を担うデバイスは、多くの場合、セクション終端装置（STE：Section Terminating Equipment）と呼ばれます。

ラインレイヤーは、SONET/SDHフレームとの情報の同期および多重化を行います。ライン終端装置（LTE：Line Terminating Element）には、ルーターや ADMがあります。


パスレイヤーでは、ルーターなどのパス終端装置（PTE：Path Terminating Element）によって SONET/SDH以外のネットワークとSONET/SDHネットワークが接続されます。この階層により、特定レイヤーでの問題を素早く切り分けできるようになります。

図 5-1 SONETネットワークのサンプル

以降のセクションでは、図 5-1を用いて、一般的な SONETエラー、その主な原因、およびトラブルシューティングの開始場所に関するいくつかの推奨事項を挙げます。

LOS（Loss of Signal）LOS（Loss of Signal：信号損失）アラームは、隣接の SONET機器の送信ポートからルーターの受信ポートへの接続において、物理リンクの問題が発生していることを示すものです。LOSアラームの発生場所を特定するには、ルーターポートと最初の SONETネットワーク構成要素の間の接続を確認します。LOS発生時に showコマンドを実行した場合、詳細出力には以下が含まれることがあります。

� アクティブなアラーム：LOL、PLL、LOS

� アクティブな不具合：LOL、PLL、LOF、LOS、SEF、AIS-L、AIS-P、PLM-P

LOF（Loss of Frame）SONETでは、セクションオーバーヘッド内の A1および A2バイトを用いて、特定のビットパターンを使用してフレームを揃えます。構成要素で、3ミリ秒間連続してこのパターン内でエラーを検知すると、LOF（Loss of Frame：フレーム同期損失）エラーが発生します。LOFエラーが発生した場合は、ルーターと最初の SONETネットワーク構成要素の間の接続で、ネットワーク構成要素間にフレーミングの不一致（SONETとSDH、など）がないことを確認します。

セクションセクション

ラインラインライン

パス

セクションセクション

ルーター1 リピーター1 ルーター2リピーター2


AIS（Alarm Indication Signal）AIS（Alarm Indication Signal：アラーム表示信号）は、エラー状態を知らせるために下流に送信される信号です。以下の 2種類のAISアラームがあります。

� AIS-L（Alarm Indication Signal Line）：上流の SONETセクション上で LOSまたは LOFが検知されると、STEによって下流の LTEに送信されます。

� AIS-P（Alarm Indication Signal Path）：上流の SONETセクション上で LOSまたは LOFが検知されると、LTEによって下流の PTEに送信されます。

RDI（Remote Defect Indication）RDI（Remote Defect Indication：リモート障害表示）は、AISを補完するもので、エラーの検知時に上流に送信される信号です。この信号は、AISと同様、パスバージョンとラインバージョンがあります。

� RDI-L（Remote Defect Indication Line）：AIS-Lまたは低レベルの不具合が検知されると、上流のピア LTEに送信されます。

� RDI-P（Remote Defect Indication Path）：信号内の不具合（一般には、AIS-P）が検知されると、上流のピアPTEに送信されます。

REI（Remote Error Indication）REI（Remote Error Indication：リモートエラー表示）は、エラー状態を知らせるために上流に送信される信号です。以下の 2種類のREIアラームがあります。

� REI-L（Remote Error Indication Line）：B2バイト内でエラーが検知されると、上流の LTEに送信されます。

� REI-P（Remote Error Indication Path）：B3バイト内でエラーが検知されると、上流の PTEに送信されます。

BER（Bit Error Rate）BER（Bit Error Rate：ビット誤り率）は、BIP-B2エラー数が特定のしきい値に達すると表示されるアラームです。これらのエラーカウンタは、前述の show interface extensiveコマンドの出力に示されています。しきい値に応じて、以下の 2種類の BERアラームがあります。どちらのケースでも、インタフェースはダウンします。ビット誤り率 10^-6に達すると、BERR-SD（Bit Error Rate-Signal Degrade）が表示されます。


ビット誤り率 10^-3に達すると、BERR-SF（Bit Error Rate-Signal Failure）が表示されます。ビット誤りが発生する原因には、以下のものがあります。

� 光ファイバーの低下 � 光受信機または受信機の問題 � 光ファイバーのコネクターの汚れ � クロックの問題 � 光信号の減衰が大きすぎる � BERアラームの計算で BIP-B1および BIP-B3が使用されていない

PLM（Payload Label Mismatch）C2バイトは、イーサネットヘッダー内のイーサタイプフィールドのように、SONETヘッダーで伝送するペイロードタイプを識別する方法として用いられています。この値のデフォルトはCFで、これはペイロードスクランブリングを伴わない IP within PPPを示します。

このバイトに対する最も一般的な代替設定値は 16で、これはペイロードスクランブリングを伴う IP within PPPを示します。ネットワーク構成要素間で C2値が異なると、回線がダウンし、RDI-P（Remote Defect Indicator [Path]）および PLM-P（Path Label Mismatch [Path]）で不具合が生じます。 show interfacesコマンドの実行による詳細出力には、これらのタイプのエラーとともに現在の C2バイト設定も表示されます。C2が0x00に設定されると、UNEQ-P（Unequipped Payload）アラームがトリガーされ、プロビジョニング問題が示されます。

LOP-P（Loss of Pointer Path）LOP-P（Loss of Pointer Path：ポインターパス損失）アラームは、プロビジョニング問題が発生している可能性があることを示すもので、ジュニパーネットワークスのルーターでペイロードポインターが有効であるかを判断できないときに発生します。ルーターは、ラインオーバーヘッド内の H1および H2バイトを監視します。このアラームは、通常は SONET回線の初期プロビジョニング時に発見され、回線をネットワークに組み込んだ後にはほとんど出現しません。

PLL（Phase Lock Loop）PLL（Phase Lock Loop：位相同期ループ）アラームは、PLLがタイミングデバイスに同期できない場合に発生するもので、ハードウェ


アまたはネットワークのタイミングに関する問題の可能性を示しています。問題の原因は、ルーター上のシステムボードのタイプに応じて異なります。例：OC48-SM-IR PICを備えるM20および M40インターネットルーター、および OC192ボードを備えるM160インターネットルーターでは、以下の原因が考えられます。

� 外部クロックを設定した場合は、送信デバイス上の許容差から外れたクロック

� 内部クロックを設定した場合は、送信デバイス上の許容差から外れたクロック、または送信クロックを得るために使用する内部クロックにボードが同期できない問題

問題をさらに詳細に診断するには、以下を試します。 � 外部クロックを設定します。アラームが消えた場合、送信クロックを得るために使用する内部クロックにボードが同期していない可能性があります。

� 内部クロックを設定して、ループバック光ファイバーケーブルが接続されていることを確認します。それでもPLLアラームが引き続き発生する場合は、高い可能性でハードウェア問題が生じています。ただし、ボードのインバウンド側またはアウトバウンド側のどちらの方向で発生しているかを特定できない可能性があります。

レイヤー 2の監視およびトラブルシューティングOSIモデルの次の層であるレイヤー 2は、同一ネットワークセグメント上の隣接するネットワークノード間における論理データフレームの送信を管理します。レイヤー 2プロトコルには、イーサネット（レイヤー1とレイヤー 2の両方で動作する）、フレームリレー、および HDLCなどがあります。

本セクションでは、PPP（Point-to-Point Protocol）の監視およびトラブルシューティングについて説明します。PPPは、WANリンクを介してルーターを接続するために良く用いられるレイヤー 2プロトコルであり、ジュニパーネットワークスのルーターでは、シリアル接続用のデフォルトプロトコルとして採用されています。レイヤー 1でのトラブルシューティングと同様に、レイヤー 2で調べるべき対象は、show

interfaceコマンドの実行による出力に示されます。

以下の出力例は、前述の SONETインタフェースに対するものと同じですが、ここではレイヤー 2（PPP）に焦点を当てます。

[edit]ps@dunkel-re0> show interfaces so-1/2/3 Physical interface: so-1/2/3, Enabled, Physical link is Up Interface index:148, SNMP ifIndex:133


Description:Connection to kenny so-1/2/3 Link-level type:PPP, MTU:4474, Clocking:Internal, SONET mode, Speed:OC3, Loopback:None, FCS:16, Payload scrambler:Enabled Device flags :Present Running Interface flags:Point-To-Point SNMP-Traps Internal:0x4000 Link flags :Keepalives Keepalive settings:Interval 10 seconds, Up-count 1, Down-count 3 Keepalive:Input:275076 (02:44:12 ago), Output:275032 (02:44:09 ago) LCP state:Opened NCP state:inet:Opened, inet6:Not-configured, iso:Not-configured, mpls: Not-configured CHAP state:Closed PAP state:Closed CoS queues :4 supported, 4 maximum usable queues Last flapped :2010-04-09 14:38:52 PDT (2d 23:50 ago) Input rate :656 bps (0 pps) Output rate :696 bps (0 pps) SONET alarms :None SONET defects :None

Logical interface so-1/2/3.0 (Index 69) (SNMP ifIndex 142) Flags:Point-To-Point SNMP-Traps 0x4000 Encapsulation:PPP Protocol inet, MTU:4470 Flags:None Addresses, Flags:Is-Preferred Is-Primary Destination:10.33.18.4/30, Local:10.33.18.6, Broadcast:10.33.18.7

PPPに関する情報は、上記では太字で表示されており、その動作の重要な側面を示します。LCP（Link Control Protocol）および NCP（Network Control Protocol）は、PPPスイート内のプロトコルで、

PPPのリンクおよびネットワーク機能のパラメータと動作を管理します。LCPは、リンクパラメータのネゴシエーション（パケット送信サイズ）と、リンクが（基準セットに基づいて）許容できるものかどうかの検証を行います。LCPがオープン状態にならない限り、PPPは継続できません。LCPによるネゴシエーションの後、NCPはレイヤー 3プロトコルモジュールを使用して、多岐にわたるレイヤー 3プロトコルに対するパラメータのネゴシエーションを行います。こうすることで、新しいレイヤー 3プロトコルをサポートできるように PPPを変更することが不要になります。このケースで考慮すべきNCPモジュールは、IPCP（Internet Protocol Control Protocol）です。IPCPは、圧縮メカニズム、IPアドレッシング（動的な加入者環境など）など、IPレイヤーパラメータやその他の値のネゴシエーションを行います。特定のレイヤー 3プロトコルに対して IPCPがオープンな状態でなければ、そのタイプのパケットを送信することはできません。


注 NCPモジュールには、IPv6CP for IP version 6、IPX（IPxCP for Internet Packet Exchange）および ATCP（AppleTalk Control Protocol）などもあります。

大半の状況では、これらすべてのパラメータのデフォルト値を使用すれば問題ありません。ただし、レイヤー 1については、両側で一致することが必要であるため、LCPまたは NCPがオープン状態にならない状況では、まず初めに調べるべき箇所であるといえます。CHAPおよび PAPプロトコルは、多くの PPP問題の原因となることがあります（非動的なアドレス環境）。CHAPおよび PAPは、ピアのアイデンティティを認証するために使用され、通常は、NCPによるネゴシエーション完了後に動作します。

CHAPまたは PAPの障害が発生すると、NCPおよび LCPはクローズ状態となり、プロセスが再開します。CHAPおよび PAPは、どちらも隣接機器を認証するためにパスワードを使用しますが、異なるメカニズムを採用しています。PAPはパスワードをプレーンテキストで送信するため安全ではありませんが、CHAPはMD5ハッシュを用いることで、そうした脆弱性を回避します。どちらのプロトコルも、大規模なシリアルリンクではそれほど採用されません。一般に、加入者環境でクライアントのアイデンティティを検証するために限定的に使用されます。CHAPまたは PAPを使用した場合には、両側で認証およびパスワードのタイプを確認することを推奨します。以下に、パスワード設定に誤りがある PAP認証の設定サンプルを示します。ここでは、例として、問題の切り分けに traceoptionsを使用しています。この例では、PPPリンクを介してトラフィックを渡すことができず、LCPがオープンではないことがわかりました。

ps@dunkel-re0> ping 10.33.18.5 count 5 PING 10.33.18.5 (10.33.18.5):56 data bytes

--- 10.33.18.5 ping statistics ---5 packets transmitted, 0 packets received, 100% packet loss

ps@dunkel-re0> show interfaces so-1/2/3 Physical interface: so-1/2/3, Enabled, Physical link is Up Interface index:148, SNMP ifIndex:133 Description:Connection to maibock Link-level type:PPP, MTU:4474, Clocking:Internal, SONET mode, Speed:OC3, Loopback:None, FCS:16, Payload scrambler:Enabled Device flags :Present Running Interface flags:Point-To-Point SNMP-Traps Internal:0x4000 Keepalive settings:Interval 10 seconds, Up-count 1, Down-count 3 Keepalive:Input:0 (never), Output:0 (never) LCP state:Down NCP state: inet:Not-configured, inet6:Not-configured, iso:Not-configured, mpls: Not-configured


CHAP state:Closed PAP state:Closed CoS queues :4 supported, 4 maximum usable queues Last flapped :2010-04-09 14:38:52 PDT (3d 00:34 ago) Input rate :80 bps (0 pps) Output rate :88 bps (0 pps) SONET alarms :None SONET defects :None

Logical interface so-1/2/3.0 (Index 73) (SNMP ifIndex 521) Flags:Hardware-Down Point-To-Point SNMP-Traps 0x4000 Encapsulation:PPP Protocol inet, MTU:4470 Flags:Protocol-Down Addresses, Flags:Dest-route-down Is-Preferred Is-Primary Destination:10.33.18.4/30, Local:10.33.18.6, Broadcast:10.33.18.7

pingの試行とインタフェースの出力により、LCPがダウンしていることが示されています。このリンクを介してトラフィックを渡せない理由がわかりました。この設定では、CHAP認証を使用していることが示されているため、トラブルシューティングを開始すべき箇所であるといえます。

ps@dunkel-re0> show configuration interfaces so-1/2/3 description “Connection to maibock”;unit 0 { ppp-options { chap { default-chap-secret “$9$PfF/9A0OIcF3hreKx7ik.539BIcM87cyvL”; ## SECRET-DATA } } family inet { address 10.33.18.6/30; }}

問題が CHAPに関連していないことを最も早く裏付ける方法は、接続の両側でパスワード（この例では ppp-password）を再入力する方法です。しかし、Junosのデバッグ機能を示すために、問題の診断には traceoptionsを使用しています。Junosの traceoptionsは、プロトコルまたは機能のデバッグ情報を提供します。一般に、プロトコルの traceoptionsは、そのプロトコルに対応する階層レベルで設定します。PPPの場合、traceoptionsは [edit protocols ppp]階層で設定します。traceoptionsには、主に 2つの設定パラメータがあります。それは、デバッグメッセージのログが記録されるファイルと、ログ記録対象の情報タイプを指定するフラグです。この例では、ファイル名は「ppp-log.txt」です。以下に、PPP traceoptionsの設定オプションを示します。


[edit]ps@dunkel-re0# set protocols ppp traceoptions flag ? Possible completions: access Trace access code address-pool Trace address pool code all Trace all areas of code auth Trace authentication code chap Trace CHAP code ci Trace ci code config Trace configuration code ifdb Trace interface database code lcp Trace LCP state machine code memory Trace memory management code message Trace message processing code mlppp Trace MLPPP code ncp Trace NCP state machine code pap Trace PAP code ppp Trace PPP protocol processing code radius Trace RADIUS processing code redundancy Trace redundancy code rtsock Trace routing socket code session Trace session management code signal Trace signal handling code timer Trace timer code ui Trace user interface code

PPPには多数の traceoptionsフラグがありますが、CHAPに問題があると疑う場合は、そこから調査を開始すべきです。PPP traceoptionsは、出力を特定の重要度に制限するレベルパラメータも提供します。この例では、まずレベルとして「all」を使用し、以下のように traceoptions設定をそのまま使用します。

ps@dunkel-re0> show configuration protocols ppp traceoptions { file ppp-log.txt; level all; flag chap;}

この設定をコミット後、問題を診断するための次のステップは、traceoptionsファイルの監視です。これを行うには、monitor start [filename]コマンドを実行します。

ps@dunkel-re0> monitor start ppp-log.txt


このコマンドは、UNIX環境での tailコマンドに相当し、ユーザーがファイルへの追加を監視できるようにするものです。しばらくすると、画面上に以下が表示されます。

ps@dunkel-re0> *** ppp-log.txt ***Apr 12 16:12:20 so-1/2/3.0:CHAP - Stopping protocol timerApr 12 16:12:20 so-1/2/3.0:CHAP - Starting authenticationApr 12 16:12:20 so-1/2/3.0:CHAP - End authen(0x8231004):FAILURE

ログ内で最も重要な行は、障害エラーです。認証が失敗し、両側でパスワードをリセットすべきであることがわかります。

Junosでは、PPPの状態を監視するための CLIコマンドがいくつか提供されています。最も役立つコマンドとしては、show ppp

interface [interface name] extensiveおよび show ppp summaryがあります。以下に、現在のダウンした状態でこれらのコマンドを実行した場合の出力例を示します。

ps@dunkel-re0> show ppp interface so-1/2/3 extensive Sessions for interface so-1/2/3 Session so-1/2/3.0, Type:PPP, Phase:Establish LCP State:Creq-sent Last started:2010-04-12 16:16:16 PDT Last completed:2010-04-12 16:16:14 PDT Negotiated options: Authentication protocol:CHAP, Authentication algorithm:MD5, Magic number:2543706641, MRU:4470 Authentication:CHAP State:Closed Last started:2010-04-12 16:16:14 PDT Last completed:2010-04-12 16:13:26 PDT IPCP State:Closed Last started:2010-04-12 16:13:26 PDT Last completed:2010-04-12 16:13:26 PDT Negotiated options: Local address:10.33.18.6, Remote address:10.33.18.4, Primary DNS:0.0.0.0, Secondary DNS:0.0.0.0

ps@dunkel-re0> show ppp summary Interface Session type Session phase Session flagsso-1/2/3.0 PPP Authenticate


運用時の設定では、show ppp interface extensiveコマンドの実行による出力で、LCPおよび IPCP（および設定したその他のレイヤー 3プロトコル）は「Opened」状態にあり、show ppp summaryにはセッションフェーズとして「Network」が示されているべきです。両側でパスワードをリセットすると、以下のログが表示されます（この時点でも監視を継続しているはずです）。

Apr 12 16:13:26 so-1/2/3.0:CHAP - Starting protocol timer (2 sec, 0 nsec)Apr 12 16:13:26 so-1/2/3.0:CHAP - Stopping protocol timerApr 12 16:13:26 so-1/2/3.0:CHAP - Starting authenticationApr 12 16:13:26 so-1/2/3.0:CHAP - End authen(0x8231004):SUCCESS

SUCCESSメッセージが表示されています。この後、回線をもう一度pingすると、PPPが正常に機能していることが CLI操作によって検証されます。

ps@dunkel-re0> show ppp interface so-1/2/3 extensive Sessions for interface so-1/2/3 Session so-1/2/3.0, Type:PPP, Phase:Network LCP State:Opened Last started:2010-04-12 16:19:41 PDT Last completed:2010-04-12 16:19:41 PDT Negotiated options: Authentication protocol:CHAP, Authentication algorithm:MD5, Magic number:2544040945, MRU:4470 Authentication:CHAP State:Success Last started:2010-04-12 16:19:41 PDT Last completed:2010-04-12 16:19:41 PDT IPCP State:Opened Last started:2010-04-12 16:19:41 PDT Last completed:2010-04-12 16:19:41 PDT Negotiated options: Local address:10.33.18.6, Remote address:10.33.18.5, Primary DNS:0.0.0.0, Secondary DNS:0.0.0.0

ps@dunkel-re0> show ppp summary Interface Session type Session phase Session flagsso-1/2/3.0 PPP Network


ベストプラクティスこの時点で、LCPと IPCPの状態が「Opened」になり、show ppp summaryによってセッションフェーズが「Network」であると表示されます。監視セッションを終了する前に、PPPのデバッグで用いた traceoptions設定を削除してください。traceoptionsは、他のルーターに影響を与えませんが、無駄な traceoptions設定やファイルが作成されます。

これを行うには、設定モードで delete protocols ppp traceoptions

コマンドを実行します。ps@dunkel-re0> configure Entering configuration mode

[edit]ps@dunkel-re0# delete protocols ppp traceoptions

[edit]ps@dunkel-re0# commit and-quit re0: configuration check succeedsre1: commit completere0: commit completeExiting configuration mode

monitor stopコマンドを実行することで、ppp-log.txtファイルの監視を停止できます。監視対象は自身のターミナルに限定され、ログアウトしたときに自動的に停止することに注意してください。ps@dunkel-re0> monitor stop

まとめ本章では、SONETおよび PPPを使用して、レイヤー 1および 2のアラームやエラーの監視方法とトラブルシューティング方法についてまとめました。SONETを使用した理由は、ジュニパーネットワークスのデバイスで最も多く採用される、最も複雑なレイヤー 1技術であるためです。また、PPPを使用した理由は、広く採用されており相互運用性に優れているからです。しかし、この同じアプローチを、イーサネットを含む他のレイヤー 1またはレイヤー 2技術にも適用できます。

SONET、イーサネット、およびその他のレイヤー 1またはレイヤー2技術で使用できる、このアプローチは以下のとおりです。


� プロトコルで提供する機能、操作、および情報を使用します。 � この情報は、show interface extensiveコマンドの実行による出力に含まれています。

� show interface extensiveコマンドの実行による出力はスナップショットですが、monitor interfaceコマンドの実行ではリアルタイムの情報が提供され、インタフェースの最も重要な統計、警告、エラー、および属性が更新されながら表示されます。

以下に、monitorコマンドの実行時に UNIXターミナル上で表示される情報の例を示します。

dunkel-re0 Seconds:36 Time:10:32:10

Delay:0/0/19

Interface: so-2/0/0, Enabled, Link is Up

Encapsulation:PPP, Keepalives, Speed:OC12

Traffic statistics: Current delta

Input bytes: 408874 (0 bps) [0]

Output bytes: 444937 (0 bps) [0]

Input packets: 31104 (0 pps) [0]

Output packets: 31361 (0 pps) [0]

Encapsulation statistics:

Input keepalives: 15527 [0]

Output keepalives: 15537 [0]

LCP state:Down

Error statistics:

Input errors: 0 [0]

Input drops: 0 [0]

Input framing errors: 255 [0]

Input runts: 0 [0]

Input giants: 0 [0]

Policed discards: 0 [0]

L3 incompletes: 255 [0]

L2 channel errors: 0 [0]

L2 mismatch timeouts: 0 Carrier transitiZ [0]

Interface warnings:

o Received keepalive count is zero

o INET NCP is not Opened

o LCP state is not Opened

Next=’n’, Quit=’q’ or ESC, Freeze=’f’, Thaw=’t’, Clear=’c’, Interface=’i’


ベストプラクティス FCS、ペイロードスクランブリング（SONETおよび SDHの両方）、速度、フロー制御、二重モード（すべてのイーサネット）などのレイヤー1設定と、認証などのレイヤー 3設定が一致していることを確認してください。また、ネットワークにおける各デバイスの役割についても理解してください（イーサネットネットワークよりもSONETネットワークで重要となる）。

第6章

レイヤー3の監視

RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98


本書では、これまでにレイヤー 1およびレイヤー 2プロトコルの監視およびトラブルシューティングについて説明しました。レイヤー 1およびレイヤー 2での問題の多くは、その設定が局所的にのみ影響する完結型のシステムに切り分けされます。

レイヤー 3の監視およびトラブルシューティングでは、IPネットワークは相互に接続および依存しているシステムであるため、障害や変更が生じるとグローバルな規模で影響があるという点を理解することが不可欠です。

本章では、レイヤー 3 IPネットワークを効果的に監視する方法について説明します。大半のオペレータは、レイヤー 1およびレイヤー 2の監視と同様、問題を特定するために Syslog、SNMP、および監視システムを活用します。レイヤー 3ネットワーク監視は、レイヤー 1やレイヤー 2よりも非常に複雑です。処理対象のデータ量が多いため、障害点になりうる箇所が多くなるのが、その理由です。相互接続による IPネットワークの特性も、根本的原因の迅速な特定を難しくしている要因です。レイヤー 3 IPネットワークでは、以下を監視します。

� NMSシステムで適切なログを受け取るよう、一般的に使用されることが多いプロトコルに関連するログ記録設定

� ログおよび SNMPトラップ、さらにはいくつかの重要なプロトコル関連 SNMPオブジェクト

� RIP、IS-IS、OSPF、BGPなど、一般的に導入される IPプロトコル用の便利なオペレーションモードコマンド

� 主にルートプロトコル関連イベントのログ記録および SNMPトラップを行うための RPD（Routing Protocol Process）

注各プロトコルには、そのプロトコル固有のイベントに対して作成される独自のログおよびトラップのセットがあります。これらのログやトラップは、自動的に実行されるものもあれば、設定が必要なものもあります。例えば、BGPで隣接機器の状態変化のログを記録するには、log-updownステートメントの設定は不可欠です。

RIP

RIPは、ディスタンスベクトル型プロトコルであるため、OSPFやIS-ISなどのリンクステート型プロトコルのように隣接関係を確立しません。RIPアドバタイズメントは、単なるネットワーク上でのマルチキャストであり、受信したいルーターで更新を処理できます。受動的な通知であるため、隣接機器状態はなく、ネットワークセグメント上でのRIPルーターの接続が確立またはダウンしてもRIPに関連するログは記録されません。

第6章：レイヤー3の監視 77

RIPオペレーションモードコマンド

RIPの動作を監視するには、まずデバイスで提供される標準的な操作や機能から確認します。 show rip neighborコマンドを実行すると、RIP用に設定したインタフェースが表示されます。コマンド名が紛らわしいため注意が必要ですが、このコマンドを実行してもRIP隣接機器に関する情報は表示されません（前述のように、存在しない）。

ps@dunkel-re0> show rip neighbor Source Destination Send Receive InNeighbor State Address Address Mode Mode Met -------- ----- ------- ----------- ---- ------- --- so-2/0/0.0 Up 18.32.74.1 224.0.0.9 mcast both 1

この例では、ルーターでインタフェース so-2/0/0に対するRIP更新を送受信するよう設定されています。これは、設定内容からも確認できます（必ず裏付けを取ること）。

ps@dunkel-re0> show configuration protocols rip group core-interfaces { neighbor so-2/0/0.0;}

この設定からは、ルーターに対して指定した動作が実際に行われていることがわかります。ルーター動作をより深く理解するために、ルーターで RIP更新を送受信しているかを確認できることが役立ちます。これを行うのが、show rip statisticsコマンドです。

ps@dunkel-re0> show rip statistics RIPv2 info: port 520; holddown 120s. rts learned rts held down rqsts dropped resps dropped 0 0 0 0

so-2/0/0.0:1 routes learned; 0 routes advertised; timeout 180s; update interval 30sCounter Total Last 5 min Last minute------- ----------- ----------- -----------Updates Sent 0 0 0Triggered Updates Sent 0 0 0Responses Sent 0 0 0Bad Messages 0 0 0RIPv1 Updates Received 0 0 0RIPv1 Bad Route Entries 0 0 0RIPv1 Updates Ignored 0 0 0RIPv2 Updates Received 7 7 3RIPv2 Bad Route Entries 0 0 0RIPv2 Updates Ignored 0 0 0Authentication Failures 0 0 0RIP Requests Received 0 0 0RIP Requests Ignored 0 0 0


このように、RIPでは RIPv2更新メッセージを受信していることがわかります。これは良い兆候です。Junosでは、デフォルトで、RIPでルーティング情報をアドバタイズしないよう設定されることから、更新の出力がないことは問題ありません。このテーブル内容を更新させるには、ルーティング情報をエクスポートするようRIPを設定する必要があります。このネットワークでは、この SONETリンクの反対側のルーターでルーティング情報をアドバタイズしています（出力の太字表示された RIPv2 Updates Receivedおよび 1 routes learnedカウンタ）。 show route protocol ripコマンドを実行することで、デバイスで RIP更新を受信および処理していることが確認できます。

ps@dunkel-re0> show route protocol rip

inet.0:10 destinations, 12 routes (10 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both

10.200.7.2/32 *[RIP/100] 00:00:02, metric 2, tag 0 > to 18.32.74.2 via so-2/0/0.0224.0.0.9/32 *[RIP/100] 00:15:13, metric 1 MultiRecv

__juniper_private1__.inet.0:5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)__juniper_private2__.inet.0:1 destinations, 1 routes (0 active, 0 holddown, 1 hidden)__juniper_private1__.inet6.0:5 destinations, 7 routes (5 active, 0 holddown, 0 hidden)

IS-IS

IS-ISは、リンクステート型プロトコルであり、より豊富な監視ツールセットを備えています。本セクションでは、ルーター上でその IS-IS動作を監視するために使用できるログ記録、SNMPトラップ、および操作ツールについて説明します。

ログ記録

IS-ISでは、隣接関係プロセスのフィニットステートマシンに基づいて情報のログを記録します。IGPがネットワークの到達可能性に直接関連しているか（すべてのルートが IGP内に収まる場合）、または BGPに対してネクストホップ到達可能性を提供し、MPLSの基盤プロトコルとしての役割を果たすことで接続性に間接的に関連しているため、IP問題に対してネットワークを監視する上で、これらのログが重要になります。さらに、IGPダウンイベントによってネットワーク内で再収束がトリガーされる可能性があり（可能性が高い）、準最適ルートまたは他のリンクの過剰利用にもつながります。どのような状況でも、特定の隣接関係の障害を解決するため、また予期せぬ事態の発生時にそれを緩和


するためにも、トポロジーが変更されたことを把握することが重要です。隣接関係変更に対して記録される基本的な IS-ISログは、隣接関係の確立と隣接関係の喪失です。ここでは、隣接関係はレベル 2回線として設定されていますが、それ以外は通常の設定です。

ps@dunkel-re0> show configuration protocols isis level 1 disable;interface so-2/0/0.0;

初めて隣接関係が確立されると、ルーターで ADJUP Syslogメッセージのログを記録します。

Jan 22 15:15:50 172.19.110.171 rpd[4550]:RPD_ISIS_ADJUP:IS-IS new L2 adjacency to pilsener-re0 on so-2/0/0.0

リンクダウンが発生すると、以下のログがトリガーされます。Jan 22 15:28:21 172.19.110.171 rpd[4550]:RPD_ISIS_ADJDOWN:IS-IS lost L2 adjacency to pilsener-re0 on so-2/0/0.0, reason:Interface Down

接続の反対側にあるルーターで、ルーティングエンジンはダウンするが、リンクは確立されたままであるソフト障害が発生した場合は（キープアライブが失われる）、以下のメッセージがログに記録されます。

Jan 22 15:31:25 172.19.110.171 rpd[4550]:RPD_ISIS_ADJDOWN:IS-IS lost L2 adjacency to pilsener-re0 on so-2/0/0.0, reason:Aged Out

最後に、設定内でレベルの不一致がある場合は、以下のメッセージが表示されます。

Jan 22 15:32:33 172.19.110.171 rpd[4550]:RPD_ISIS_ADJDOWN:IS-IS lost L2 adjacency to pilsener-re0 on so-2/0/0.0, reason:Level Mismatch

SNMPトラップJunosでは、IS-IS状態変化が発生したときに SNMPトラップを送信するように設定することもできます。Junosは、デフォルトでは、こうした状況でトラップを送信しないよう設定されていますが、トラップが確実に送信されるには、イベントオプションを設定しなければなりません。以下のイベントオプション設定で示すように、イベントオプションを使用することで、特定のローカルログイベントが発生したときに指定したアクションを実行できるようになります。

ps@dunkel-re0> show configuration event-options policy isisNbrStateChange { events [ rpd_isis_adjdown rpd_isis_adjup ]; then { raise-trap; }}


このイベントオプション設定によって、ログファイルに rpd_isis_adjdown

または rpd_isis_adjupのどちらかが出現したときに、ルーターからSNMPトラップが送信されます。以下の例で、同じ隣接関係の変化が発生した場合に、結果として送信されるSNMPトラップを比較できます。IS-IS隣接関係の確立：

dunkel-re0.juniper.net [UDP:[172.19.110.171]:62313]:Trap , DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks:(27422739) 3 days, 4:10:27.39, SNMPv2-MIB::snmpTrapOID.0 = OID: SNMPv2-SMI::enterprises.2636.4.12.0.1, SNMPv2-SMI::enterprises.2636.3.35.1.1.1.2.2 = STRING:“RPD_ISIS_ADJUP”, SNMPv2-SMI::enterprises.2636.3.35.1.1.1.3.2 = Hex-STRING:07 DA 01 16 17 39 33 00 2B 00 00 , SNMPv2-SMI::enterprises.2636.3.35.1.1.1.4.2 = INTEGER:7, SNMPv2-SMI::enterprises.2636.3.35.1.1.1.5.2 = INTEGER:4, SNMPv2-SMI::enterprises.2636.3.35.1.1.1.6.2 = Gauge32:4550, SNMPv2-SMI::enterprises.2636.3.35.1.1.1.7.2 = STRING:“rpd”, SNMPv2-SMI::enterprises.2636.3.35.1.1.1.8.2 = STRING:“dunkel-re0”, SNMPv2-SMI::enterprises.2636.3.35.1.1.1.9.2 = STRING:“RPD_ISIS_ADJUP:IS-IS new L2 adjacency to pilsener-re0 on so-2/0/0.0”, SNMPv2-MIB::snmpTrapEnterprise.0 = OID:SNMPv2-SMI::enterprises.2636.1.1.1.2.9

IS-ISリンクダウン：dunkel-re0.juniper.net [UDP:[172.19.110.171]:62313]:Trap , DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks:(27426926) 3 days, 4:11:09.26, SNMPv2-MIB::snmpTrapOID.0 = OID:SNMPv2-SMI::enterprises.2636.4.12.0.1, SNMPv2-SMI::enterprises.2636.3.35.1.1.1.2.3 = STRING:“RPD_ISIS_ADJDOWN”, SNMPv2-SMI::enterprises.2636.3.35.1.1.1.3.3 = Hex-STRING:07 DA 01 16 17 3A 20 00 2B 00 00 , SNMPv2-SMI::enterprises.2636.3.35.1.1.1.4.3 = INTEGER:6, SNMPv2-SMI::enterprises.2636.3.35.1.1.1.5.3 = INTEGER:4, SNMPv2-SMI::enterprises.2636.3.35.1.1.1.6.3 = Gauge32:4550, SNMPv2-SMI::enterprises.2636.3.35.1.1.1.7.3 = STRING:“rpd”, SNMPv2-SMI::enterprises.2636.3.35.1.1.1.8.3 = STRING:“dunkel-re0”, SNMPv2-SMI::enterprises.2636.3.35.1.1.1.9.3 = STRING:“RPD_ISIS_ADJDOWN: IS-IS lost L2 adjacency to pilsener-re0 on so-2/0/0.0, reason:Interface Down”, SNMPv2-MIB::snmpTrapEnterprise.0 = OID:SNMPv2-SMI::enterprises.2636.1.1.1.2.9Soft failure on the remote side: dunkel-fxp0.pslab.juniper.net [UDP:[172.19.110.171]:62313]:Trap , DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks:(27434764) 3 days, 4:12:27.64, SNMPv2-MIB::snmpTrapOID.0 = OID:SNMPv2-SMI::enterprises.2636.4.12.0.1, SNMPv2-SMI::enterprises.2636.3.35.1.1.1.2.5 = STRING:“RPD_ISIS_ADJDOWN”, SNMPv2-SMI::enterprises.2636.3.35.1.1.1.3.5 = Hex-STRING:07 DA 01 16 17 3B 33 00 2B 00 00 , SNMPv2-SMI::enterprises.2636.3.35.1.1.1.4.5 = INTEGER:6, SNMPv2-SMI::enterprises.2636.3.35.1.1.1.5.5 = INTEGER:4, SNMPv2-SMI::enterprises.2636.3.35.1.1.1.6.5 = Gauge32:4550, SNMPv2-SMI::enterprises.2636.3.35.1.1.1.7.5 = STRING:“rpd”, SNMPv2-SMI::enterprises.2636.3.35.1.1.1.8.5 = STRING:“dunkel-re0”, SNMPv2-SMI::enterprises.2636.3.35.1.1.1.9.5 = STRING:“RPD_ISIS_ADJDOWN: IS-IS lost L2 adjacency to pilsener-re0 on so-2/0/0.0, reason:Aged Out”, SNMPv2-MIB::snmpTrapEnterprise.0 = OID:SNMPv2-SMI::enterprises.2636.1.1.1.2.9


レベルの不一致：dunkel-fxp0.pslab.juniper.net [UDP:[172.19.110.171]:62313]:Trap , DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks:(27438490) 3 days, 4:13:04.90, SNMPv2-MIB::snmpTrapOID.0 = OID:SNMPv2-SMI::enterprises.2636.4.12.0.1, SNMPv2-SMI::enterprises.2636.3.35.1.1.1.2.7 = STRING:“RPD_ISIS_ADJDOWN”, SNMPv2-SMI::enterprises.2636.3.35.1.1.1.3.7 = Hex-STRING:07 DA 01 17 00 00 1C 00 2B 00 00 , SNMPv2-SMI::enterprises.2636.3.35.1.1.1.4.7 = INTEGER:6, SNMPv2-SMI::enterprises.2636.3.35.1.1.1.5.7 = INTEGER:4, SNMPv2-SMI::enterprises.2636.3.35.1.1.1.6.7 = Gauge32:4550, SNMPv2-SMI::enterprises.2636.3.35.1.1.1.7.7 = STRING:“rpd”, SNMPv2-SMI::enterprises.2636.3.35.1.1.1.8.7 = STRING:“dunkel-re0”, SNMPv2-SMI::enterprises.2636.3.35.1.1.1.9.7 = STRING:“RPD_ISIS_ADJDOWN: IS-IS lost L2 adjacency to pilsener-re0 on so-2/0/0.0, reason:Level Mismatch”, SNMPv2-MIB::snmpTrapEnterprise.0 = OID:SNMPv2-SMI::enterprises.2636.1.1.1.2.9

IS-ISオペレーションモードコマンド

IS-ISプロトコルには、多数の運用コマンドがあります。これらのコマンドを実行することで、IS-IS隣接関係、プロトコル状態、およびルーティング情報に関連する情報を表示できます。最も良く用いられるのは、show isis adjacencyコマンドです。このコマンドを実行すると、現在の IS-IS隣接機器とその状態が表示されます。状態は、FSM（Finite State Machine：フィニットステートマシン）での隣接関係の進行状況を反映したものです。

ここでは、IS-IS FSMを説明するため、単純に Upは良好であるとします。IS-IS隣接関係は、Newステージと Initializingステージを経由して、最終的に Up状態になります。

ps@dunkel-re0> show isis adjacency Interface System L State Hold (secs) SNPAso-2/0/0.0 pilsener-re0 2 New 23

ps@dunkel-re0> show isis adjacency Interface System L State Hold (secs) SNPAso-2/0/0.0 pilsener-re0 2 Initializing 26

ps@dunkel-re0> show isis adjacency Interface System L State Hold (secs) SNPAso-2/0/0.0 pilsener-re0 2 Up 26

隣接関係が形成されない理由はたくさんありますが、以下に主なものを挙げます。

� ファミリー ISOに対してインタフェースが設定されていない � NSAPアドレスの欠如または重複（Junosでは、NSAPアドレスは lo0.0インタフェース上のファミリー ISOアドレスとして設定される）


� レベルの不一致 � エリアの不一致 � 認証タイプまたはキーの障害

いずれの状況でも、リンクの両側の設定が一致することを確認してください。隣接関係が形成されたことで、IS-ISデータベースに関する有用な情報があるはずです。IS-ISでは、レベル 1情報とレベル 2情報に対してそれぞれ 1つずつ、合計 2つのデータベースが維持されます。レベル 1は無効化されているため、レベル 2データベースのみ表示されます。show isis databaseコマンドの実行による詳細出力オプションを使用して、IS-ISデータベースを参照します。

ps@dunkel-re0> show isis database detail IS-IS level 1 link-state database:

IS-IS level 2 link-state database:

pilsener-re0.00-00 Sequence:0x7, Checksum:0xd28e, Lifetime:1155 secs IS neighbor: dunkel-re0.00 Metric: 10 IP prefix:10.200.7.2/32 Metric: 0 Internal Up IP prefix:18.32.74.0/30 Metric: 10 Internal Up

dunkel-re0.00-00 Sequence:0x1e5, Checksum:0x75f2, Lifetime:1163 secs IS neighbor: pilsener-re0.00 Metric: 10 IP prefix:10.200.7.1/32 Metric: 0 Internal Up IP prefix:18.32.74.0/30 Metric: 10 Internal Up

想定どおり、レベル 2データベースにのみ IS-IS情報が表示されます。データベースには、ルーターのローカルループバックアドレス、/30ネットワークが接続する隣接機器（pilsener-re0）、および Pilsenerのループバックアドレスが表示されます。情報は IS-ISデータベースに格納されているため、ルーターでは IS-ISに基づいてルーティング情報を取得できるはずです。これを確認するために、show route protocol

isisコマンドを実行します。ps@dunkel-re0> show route protocol isis


10.200.7.2/32 *[IS-IS/18] 00:00:41, metric 10 > to 18.32.74.2 via so-2/0/0.0

想定どおりです。ルーターでは、IS-ISに格納されている情報に基づいて、Pilsenerへのループバックアドレスへのルートが選択されました。


IS-IS全体の運用状況を監視することも役立ちます。IS-ISプロトコルを監視する上で、show isis overviewコマンドおよび show isis

statisticsコマンドが役立ちます。show isis overviewの出力の大半は、設定に基づきます。

ps@dunkel-re0> show isis overview Instance: master Router ID:10.200.7.1 Adjacency holddown: enabled Maximum Areas:3 LSP life time:1200 Attached bit evaluation: enabled SPF delay:200 msec, SPF holddown:5000 msec, SPF rapid runs:3 IPv4 is enabled, IPv6 is enabled Traffic engineering: enabled Restart:Enabled Restart duration:210 sec Helper mode:Enabled Level 1 Internal route preference:15 External route preference:160 Wide metrics are enabled, Narrow metrics are enabled Level 2 Internal route preference:18 External route preference:165 Wide metrics are enabled, Narrow metrics are enabled

この出力には、IPルーター IDが示されます。これは、[edit routing-

options]階層レベルで設定できますが、デフォルトは lo0.0インタフェースの IPアドレスか、lo0.0インタフェースが存在しない場合は最も低い数字の IPインタフェースの IPアドレスに設定されます。

ここでは lo0.0インタフェースは、IPアドレス 10.200.7.1として設定されているため、ルーターではこのアドレスをルーター IDとして選択しました。また、LSPライフタイム、ATT（attached）ビット評価、SPFオプション、MPLSトラフィック制御サポート、グレースフルリスタートパラメータなどのデフォルト値とともに、優先ルートや測定方法を含むレベル固有の設定も表示されます。これらはすべて、設定可能なパラメータです。

警告 ! 対象ネットワークの適切なデフォルト値を把握しておいてください。これらの設定可能なパラメータを調整する明確な理由がある場合を除き、パラメータ変更しないことを推奨します。

show isis statisticsコマンドを実行することで、隣接機器との通信およびプロトコル処理の両面での IS-IS動作に関する統計情報が表示されます。


ps@dunkel-re0> show isis statistics IS-IS statistics for dunkel-re0:PDU type Received Processed Drops Sent RexmitLSP 2 2 0 13 0IIH 7 7 0 7 0CSNP 45 45 0 90 0PSNP 12 12 0 1 0Unknown0 0 0 0 0Totals 66 66 0 111 0

Total packets received:66 Sent:104

SNP queue length:0 Drops:0LSP queue length:0 Drops:0SPF runs:8Fragments rebuilt:13LSP regenerations:0Purges initiated:0

最初のセクションには、IS-ISメッセージタイプに基づく受信パケット数、処理パケット数、ドロップしたパケット数、送信パケット数、再送パケット数が示されます。急激に増加するドロップ数および /または再送数は、多くの場合、何らかの問題があることを示しているため、この接続についてレイヤー 1からトラブルシューティングを開始すべきです。Total packets receivedから始まる 2番目のセクションには、処理情報が表示されます。ここでは、キューには SNP（Sequence Number PDU）または LSP（Link-State PDU）パケットはありません。これらの値が常に 0以外の場合またはドロップ数カウンタが増分する場合（またはその両方）、問題が発生している可能性があります。

SPF実行数は、SPFアルゴリズムが実行された回数です。この数値が急激に増加している場合、一般に、ネットワークリンクがフラッピングしているか、別の問題によって（IS-ISへの）再配布ルートが追加および撤回されていることを意味します。show isis spfコマンドを実行することで、SPFの実行頻度や SPF実行のトリガーなど、SPF固有の情報をより詳細に得られます。

ps@dunkel-re0> show isis spf log IS-IS level 1 SPF log:

IS-IS level 2 SPF log:Start time Elapsed (secs) Count ReasonFri Jan 29 11:36:31 0.000015 2 ReconfigFri Jan 29 11:36:41 0.000032 3 New adjacency pilsener-re0 on so-2/0/0.0

この出力には、SPFは 3回実行され、最も近い（最後の）実行は新しい隣接関係によるものであることが示されています。SPFは常に実行されていないため、IS-ISネットワークは安定しているようです。


OSPF

OSPFと IS-ISは、動作上、非常に良く似ています。どちらも一連のhelloメッセージとFSMを使用して、隣接機器との関係を形成します。また、どちらもリンクステート型データベースを作成および同期し、これらのデータベースからルーティング情報を得ます。

ログ記録

IS-ISでも重視されるように、OSPFの実行でもログ記録は重要です。以下に、OSPFで記録できるログをいくつか示します。隣接機器の確立：

Jan 28 09:52:34 172.19.110.171 rpd[4550]:RPD_OSPF_NBRUP:OSPF neighbor 18.32.74.2 (so-2/0/0.0) state changed from Init to ExStart due to 2WayRcvd (event reason: neighbor detected this router)Jan 28 09:52:34 172.19.110.171 rpd[4550]:RPD_OSPF_NBRUP:OSPF neighbor 18.32.74.2 (so-2/0/0.0) state changed from Exchange to Full due to ExchangeDone (event reason:DBD exchange of slave completed)

リンクダウン：Jan 28 09:54:38 172.19.110.171 rpd[4550]:RPD_OSPF_NBRDOWN:OSPF neighbor 18.32.74.2 (so-2/0/0.0) state changed from Full to Down due to KillNbr (event reason: interface went down)

リモート側のソフト障害：Jan 28 09:55:56 172.19.110.171 rpd[4550]:RPD_OSPF_NBRDOWN:OSPF neighbor 18.32.74.2 (so-2/0/0.0) state changed from Full to Down due to InActiveTimer (event reason: neighbor was inactive and declared dead)

SNMPトラップ

IS-ISの場合とは異なり、Junosでは OSPFの隣接関係で変化があったときに、デフォルトで SNMPトラップを送信します。IS-ISのときと同様、これらの異なるトラップを示します。隣接機器の確立：

dunkel-re0.juniper.net [UDP:[172.19.110.171]:62313]:Trap , DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks:(77178300) 8 days, 22:23:03.00, SNMPv2-MIB::snmpTrapOID.0 = OID: SNMPv2-SMI::mib-2.14.16.2.2, SNMPv2-SMI::mib-2.14.1.1.0 = IpAddress:10.200.7.1,


SNMPv2-SMI::mib-2.14.10.1.1.18.32.74.2.0 = IpAddress:18.32.74.2, SNMPv2-SMI::mib-2.14.10.1.2.18.32.74.2.0 = INTEGER:0, SNMPv2-SMI::mib-2.14.10.1.3.18.32.74.2.0 = IpAddress:10.200.7.2, SNMPv2-SMI::mib-2.14.10.1.6.18.32.74.2.0 = INTEGER:8, SNMPv2-MIB::snmpTrapEnterprise.0 = OID: SNMPv2-SMI::enterprises.2636.1.1.1.2.9

SNMPトラップは明らかに暗号化されています（snmpttのように、復号化するためのオープンソースツールもある）。しかし、ここには必要な情報が含まれています。上記のトラップでは、重要な箇所を太字で表示しています。オブジェクト 2.14.10.1.6.[neighbor address].0

は、ospfNbrState MIB内にあります。各値の持つ意味を示します。 1 - down

2 - attempt 3 - init 4 - twoWay 5 - exchangeStart 6 - exchange 7 - loading 8 - full

この SNMPトラップからの情報に基づき、OSPF隣接機器は状態 8（full）にあります。リンクダウン：

dunkel-re0.juniper.net [UDP:[172.19.110.171]:62313]:Trap , DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks:(77303649) 8 days, 22:43:56.49, SNMPv2-MIB::snmpTrapOID.0 = OID: SNMPv2-SMI::mib-2.14.16.2.2, SNMPv2-SMI::mib-2.14.1.1.0 = IpAddress:10.200.7.1, SNMPv2-SMI::mib-2.14.10.1.1.18.32.74.2.0 = IpAddress:18.32.74.2, SNMPv2-SMI::mib-2.14.10.1.2.18.32.74.2.0 = INTEGER:0, SNMPv2-SMI::mib-2.14.10.1.3.18.32.74.2.0 = IpAddress:10.200.7.2, SNMPv2-SMI::mib-2.14.10.1.6.18.32.74.2.0 = INTEGER:1, SNMPv2-MIB::snmpTrapEnterprise.0 = OID: SNMPv2-SMI::enterprises.2636.1.1.1.2.9

この例では、トラップにより隣接機器 18.32.74.2が状態 1（down）に遷移したことが示されています。また、同時に受信したリンクダウントラップにより、OSPFダウントラップの理由もわかります。

10.200.7.1:Link Down Trap (0) Uptime:8 days, 22:43:56.49, IF-MIB::ifIndex.179 = INTEGER:179, IF-MIB::ifAdminStatus.179 = INTEGER: up(1), IF-MIB::ifOperStatus.179 = INTEGER: down(2), IF-MIB::ifName.179 = STRING: so-2/0/0.0


SNMPポーリングすべてのOSPF OID（Object Identifiers）は、OIDとして 1.3.6.1.2.1.14を持つMIB（Management Information Base）に属します。OSPFオブジェクトは多数ありますが、最も多くのケースで監視対象となるMIBはOSPF隣接機器状態（ospfNbrState）です。この OIDの形式は、1.3.6.1.2.1.14.10.1.6.[neighbor address]です。これは隣接機器のアドレスです。同一隣接機器に対して複数の OSPF隣接関係を形成できることから、隣接機器のルーター IDではないことに注意してください。

nms-1> snmpwalk -v2c -c tr4pp15t cartman 1.3.6.1.2.1.14.10.1.6SNMPv2-SMI::mib-2.14.10.1.6.18.32.74.2.0 = INTEGER:8

このオブジェクトの値は、8が「full」に対応する前述のマッピングと同じです。18.32.74.2の隣接機器との隣接関係は full状態にあります。

OSPF運用コマンド

OSPFと IS-ISは良く似たプロトコルであるため、OSPFのオペレーションモードコマンドは IS-ISの同コマンドと良く似ています。OSPFコマンドには、隣接機器およびデータベースの状態、処理の概要、およびOSPF通知ルートを確認するためのものがあります。

まず、隣接関係プロセスの監視から始めます。OSPFの隣接関係は、IS-ISと同様、最終的に full状態まで進むフィニットステートマシンに従います。ポイントツーポイントリンクでは、隣接機器は full状態まで非常に速く進みます。

ps@dunkel-re0> show ospf neighbor Address Interface State ID Pri Dead18.32.74.2 so-2/0/0.0 Full 10.200.7.2 128 39

イーサネット LANなどのマルチアクセスネットワークでは、ルーターで DR（Designated Router）および BDR（Backup Designated Router）を選出する必要があるため、より長い時間がかかります。以下に示すように、隣接関係は Init状態から開始して、DRとBDRが選出される 2Way状態に進みます。そのステップが完了すると、ルーターではデータベース同期に進み、最後に Full同期を達成します。以下の出力に、この進行状況が示されています。

ps@dunkel-re0> show ospf neighbor Address Interface State ID Pri Dead172.19.110.187 fe-0/0/0.0 Init 10.200.7.2 128 34


ps@dunkel-re0> show ospf neighbor Address Interface State ID Pri Dead172.19.110.187 fe-0/0/0.0 2Way 10.200.7.2 128 37

ps@dunkel-re0> show ospf neighbor Address Interface State ID Pri Dead172.19.110.187 fe-0/0/0.0 Full 10.200.7.2 128 35

OSPF隣接関係は、以下のいずれかの状態になります。 � Init：自身のルーター IDが隣接機器リスト内にない状態で、ルーターから helloを受信した。

� 2Way：自身のルーター IDが隣接機器リスト内、DR、およびBDR選出ステージにある状態で、ルーターからhelloを受信した。

非 DRルーターは、マルチアクセスネットワークでは、この状態までしか進まないことに注意してください。

� ExStart：マスター /スレーブ関係およびシーケンス番号が確立された。

� Exchange：データベース記述子パケットが交換され、欠損している LSAが要求された。

� Loading：要求された LSAがデータベースに追加された。IS-ISと同様に、隣接関係が形成されない理由は多数あります。以下に、主な原因をいくつか挙げます。

� エリアの不一致 � 認証タイプまたはキーの障害 � タイマーの不一致 � サブネットの不一致 � MTUの不一致（隣接関係が EXSTARTでスタックする。発生する可能性が高いので覚えておくこと）

いずれの状況でも、リンクの両側の設定が一致することを確認してください。Full状態になった OSPF隣接関係が形成されたことで、OSPFデータベースに関する有用な情報があります。IS-ISプロトコルの（レベルに基づいた）データベース分離と同様、OSPFでも、ルーターが接続されている各エリアについて個別のデータベースが作成されます。この例では、ルーターはエリア0にのみ接続しているため、以下のようにエリア0データベースにのみ情報が格納されています。


ps@dunkel-re0> show ospf database detail OSPF link state database, Area 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len Router *10.200.7.1 10.200.7.1 0x80000006 290 0x22 0x307a 60 bits 0x0, link count 3 id 10.200.7.1, data 255.255.255.255, Type Stub (3) TOS count 0, TOS 0 metric 0 id 10.200.7.2, data 18.32.74.1, Type PointToPoint (1) TOS count 0, TOS 0 metric 1 id 18.32.74.0, data 255.255.255.252, Type Stub (3) TOS count 0, TOS 0 metric 1Router 10.200.7.2 10.200.7.2 0x80000005 303 0x22 0x3078 60 bits 0x0, link count 3 id 10.200.7.2, data 255.255.255.255, Type Stub (3) TOS count 0, TOS 0 metric 0 id 10.200.7.1, data 18.32.74.2, Type PointToPoint (1) TOS count 0, TOS 0 metric 1 id 18.32.74.0, data 255.255.255.252, Type Stub (3) TOS count 0, TOS 0 metric 1

ここでは、Dunkelおよび Pilsenerの両ルーターで、各ルーターの接続に関する情報が含まれるタイプ 1（ルーター）LSAをアドバタイズしています。両ルーターとも 1つの OSPF接続しかないため（互いへの接続）、それらのルーター LSAは似ています。どちらも自身のルーター IDとともに、相互の接続が含まれています。データベースに情報が格納されているため、ルーターではルーティング情報を取得できます。Dunkelでは、OSPFを介して 10.200.7.2（Pilsenerのループバック）を通知されており、OSPF接続を介してその接続先にルートを設定しました。 show route protocol ospfコマンドの実行による出力に表示されるとおり、設定したルートにはプラス記号またはアスタリスクが付けられるため、識別できます。

ps@dunkel-re0> show route protocol ospf inet.0:14 destinations, 17 routes (14 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both

10.200.7.2/32 *[OSPF/10] 00:10:15, metric 1 > via so-2/0/0.018.32.74.0/30 [OSPF/10] 00:10:20, metric 1 > via so-2/0/0.0224.0.0.5/32 *[OSPF/10] 00:10:47, metric 1 MultiRecv

また、18.32.74.0/30への OSPFルートもあることがわかります。これは Dunkelを Pilsenerに接続しているネットワークです。このルートが設定されていない理由は、Dunkelがこのネットワークに直接接続されている（つまりより適した）ルートであるためです。そのルートを表示してみます。


ps@dunkel-re0> show route 18.32.74.0/30


18.32.74.0/30 *[Direct/0] 00:15:06 > via so-2/0/0.0 [OSPF/10] 00:15:05, metric 1 > via so-2/0/0.0

OSPFが有効化されると同時に、224.0.0.5に対するOSPFルートが作成されました。このマルチキャストグループは OSPFによって使用され、すべての OSPFルーターではそれをリッスンすることが求められています。OSPFでは、すべての DRおよび BDRがリッスンすることが求められるマルチキャストグループ 224.0.0.6も使用します。OSPFプロセスの状態は、show ospf overviewコマンドおよび show

ospf statisticsコマンドを実行して調べることができます。ps@dunkel-re0> show ospf overview Instance: master Router ID:10.200.7.1 Route table index:0 Full SPF runs:6, SPF delay:0.200000 sec, SPF holddown:5 sec, SPF rapid runs:3 LSA refresh time:50 minutes Area:0.0.0.0 Stub type:Not Stub Authentication Type:None Area border routers:0, AS boundary routers:0 Neighbors Up (in full state):1

このコマンドの実行によって、SPF遅延（SPF実行のためにトポロジー変更後に待機する時間）および SPFホールドダウン（SPF実行間の待機時間）など、設定可能ないくつかのパラメータ値が表示されます。このコマンドはさらに、このルーターが接続しているエリア、接続しているエリアのタイプ（Not Stub/Stub/Stub NSSA）、それらのエリア内で隣接機器に対して使用している認証、それらのエリア内のABR、ASBR、隣接機器の台数など、ネットワークに関する重要な情報も提供します。show ospf statisticsコマンドは、show isis statisticsコマンドのように、送受信したパケット数およびそのタイプ、さらには OSPF LSAの送信、再送、および処理に関する追加情報などをユーザーに示します。このコマンドは、LSAキューおよび受信エラーに関する情報も提供します。どちらの値も0または 0に近い値に維持されるべきです。


ps@dunkel-re0> show ospf statistics

Packet type Total Last 5 seconds Sent Received Sent Received Hello 7 5 0 0 DbD 3 2 0 0 LSReq 0 0 0 0LSUpdate 4 3 0 0 LSAck 2 3 0 0

DBDs retransmitted : 0, last 5 seconds : 0LSAs flooded : 2, last 5 seconds : 0LSAs flooded high-prio : 0, last 5 seconds : 0LSAs retransmitted : 2, last 5 seconds : 0LSAs transmitted to nbr : 0, last 5 seconds : 0LSAs requested : 0, last 5 seconds : 0LSAs acknowledged : 2, last 5 seconds : 0

Flood queue depth : 0Total rexmit entries : 0db summaries : 0lsreq entries : 0

Receive errors: None

BGPBGPは、ディスタンスベクトル型プロトコルのような挙動をとりますが、ピアとの隣接関係も形成します。BGPの状態および動作を監視するために、さまざまな Syslogロギング、SNMPポーリングおよびトラップ、各種機能および操作オプションが提供されます。

まず、BGPに関連するいくつかの Syslogメッセージについて説明します。

ログ記録BGP Syslogメッセージは、主に BGPセッションの状態に関連するものです。ジュニパーネットワークスのルーターでは、set protocols

bgp log-updownコマンドを実行して、セッション状態の変化をログに記録するように BGPを設定しなければなりません。このコマンドは、BGPグループまたは隣接機器レベルでも使用できますが、最も役立つのはプロトコルレベルでの使用です。

ここでは、DunkelとPilsenerの間でピアリングを確立するシンプルな内部 BGPセッションを示します。セッショングループの確立とダウンによる、結果の Syslogメッセージも併せて示されます。


ps@dunkel-re0> show configuration protocols bgp log-updown;group ibgp { type internal; local-address 10.200.7.1; peer-as 1; neighbor 10.200.7.2;}

隣接機器の確立：Jan 29 11:47:44 172.19.110.171 rpd[4550]:RPD_BGP_NEIGHBOR_STATE_CHANGED:BGP peer 10.200.7.2 (Internal AS 1) changed state from OpenConfirm to Established (event RecvKeepAlive)

ピアのリセットによる隣接機器のダウン：Jan 29 11:48:25 172.19.110.171 rpd[4550]: bgp_read_v4_message:NOTIFICATION received from 10.200.7.2 (Internal AS 1): code 6 (Cease) subcode 4 (Administratively Reset)Jan 29 11:48:25 172.19.110.171 rpd[4550]:RPD_BGP_NEIGHBOR_STATE_CHANGED:BGP peer 10.200.7.2 (Internal AS 1) changed state from Established to Idle (event RecvNotify)

リモート側でピアが設定されないことによる隣接機器のダウン：Jan 29 11:50:38 172.19.110.171 rpd[4550]: bgp_read_v4_message:NOTIFICATION received from 10.200.7.2 (Internal AS 1): code 6 (Cease) subcode 3 (Peer Unconfigured)Jan 29 11:50:38 172.19.110.171 rpd[4550]:RPD_BGP_NEIGHBOR_STATE_CHANGED:BGP peer 10.200.7.2 (Internal AS 1) changed state from Established to Idle (event RecvNotify)

ピアのタイムアウトによる隣接機器のダウン：Jan 29 11:54:28 172.19.110.171 rpd[4550]: bgp_hold_timeout:NOTIFICATION sent to 10.200.7.2 (Internal AS 1): code 4 (Hold Timer Expired Error), Reason: holdtime expired for 10.200.7.2 (Internal AS 1), socket buffer sndcc:57 rcvcc:0 TCP state:4, snd_una:2737938411 snd_nxt:2737938468 snd_wnd:16417 rcv_nxt:3889039076 rcv_adv:3889055460, hold timer 0Jan 29 11:54:28 172.19.110.171 rpd[4550]:RPD_BGP_NEIGHBOR_STATE_CHANGED:BGP peer 10.200.7.2 (Internal AS 1) changed state from Established to Idle (event HoldTime)

SNMPトラップ

BGPでは、隣接機器の状態変化に対してSNMPトラップを作成します。これらは、mib-2.15.3.1.2.[neighbor address]オブジェクトに含まれています。状態の通知には、以下のようにマッピングされた整数が用いられます。1 - idle 2 - connect 3 - active


4 - opensent 5 - openconfirm 6 - established

以下に、10.200.7.2の BGPピアに焦点を当て、隣接機器の状態変化に基づいた、いくつかの BGPトラップ例を示します。隣接機器の確立：

cartman-fxp0.pslab.juniper.net [UDP:[172.19.110.171]:62313]:Trap , DISMAN- EVENT-MIB::sysUpTimeInstance = Timeticks:(87163316) 10 days, 2:07:13.16, SNMPv2-MIB::snmpTrapOID.0 = OID: SNMPv2-SMI::mib-2.15.7.1, SNMPv2-SMI::mib-2.15.3.1.14.10.200.7.2 = Hex-STRING:04 00 , SNMPv2-SMI::mib-2.15.3.1.2.10.200.7.2 = INTEGER:6, SNMPv2-MIB::snmpTrapEnterprise.0 = OID: SNMPv2-SMI::enterprises.2636.1.1.1.2.9

隣接機器のダウン：cartman-re0.juniper.net [UDP:[172.19.110.171]:62313]:Trap , DISMAN-EVENT- MIB::sysUpTimeInstance = Timeticks:(87321153) 10 days, 2:33:31.53, SNMPv2-MIB::snmpTrapOID.0 = OID: SNMPv2-SMI::mib-2.15.7.2, SNMPv2-SMI::mib-2.15.3.1.14.10.200.7.2 = Hex-STRING:06 07 , SNMPv2-SMI::mib-2.15.3.1.2.10.200.7.2 = INTEGER:1, SNMPv2-MIB::snmpTrapEnterprise.0 = OID: SNMPv2-SMI::enterprises.2636.1.1.1.2.9

BGPでの SNMPポーリング

Junosでは、BGPの動作を監視するためにポーリングできる、さまざまな SNMPオブジェクトがサポートされます。その種類は、本書ではすべて説明しきれないほど多岐にわたるため、ピア状態およびプレフィックスカウンタなど、良く使用されるいくつかのOIDに絞って説明します。

ジュニパーネットワークスのデバイスのすべての BGP情報は、OIDとして 1.3.6.1.4.1.2636.5.1.1を持つ、jnxBgpM2 MIB に含まれています。ピア状態は、jnxBgpM2PeerState MIBに含まれています（1.3.6.1.4.1.2636.5.1.1.2.1.1.1.2）。前述の状態マッピングがここでも適用されるため、値 6はピアが確立されたことを意味します。

nms-1> snmpwalk -v2c -c tr4pp15t dunkel .1.3.6.1.4.1.2636.5.1.1.2.1.1.1.2SNMPv2-SMI::enterprises.2636.5.1.1.2.1.1.1.2.0.1.10.200.7.1.1.10.200.7.2 = INTEGER:6

各ピアに対する有用な情報を得るためには、まず、ピアの SNMPインデックスを取得します。ルーターでは、BGPピアインデックステーブルを作成します。この情報には、jnxBgpM2PeerIndex MIB（1.3.6


.1.4.1.2636.5.1.1.2.1.1.1.14）を介してアクセスできます。返される文字列の形式は、SNMPv2-SMI::enterprises.2636.5.1.1.2.1.1.1.14.0.1.[local address].[peer address] = index:です。

nms-1> snmpwalk -v2c -c tr4pp15t cartman 1.3.6.1.4.1.2636.5.1.1.2.1.1.1.14SNMPv2-SMI::enterprises.2636.5.1.1.2.1.1.1.14.0.1.10.200.7.1.1.10.200.7.2 = Gauge32:0

この情報に基づき、10.200.7.1（ローカル）から 10.200.7.2（ピア）までの BGPセッションには、インデックス 0が与えられています。ピア固有のクエリーを実行するときに、これを使用できます。

一般的には、nxBgpM2PrefixInPrefixes、jnxBgpM2PrefixInPrefixesAccepted、および jnxBgpM2PrefixInPrefixesRejectedを使用します。これらは、受信プレフィックス総数、許可プレフィックス総数、拒否プレフィックス総数に関する情報を提供するものです。それぞれのOIDは、1.3.6.1.4.1.2636.5.1.1.2.6.2.1.7、1.3.6.1.4.1.2636.5.1.1.2.6.2.1.8、および 1.3.6.1.4.1.2636.5.1.1.2.6.2.1.9であり、以下の形式を使用します。1.3.6.1.4.1.2636.5.1.1.2.6.2.1.7.[index]

受信プレフィックス総数：nms-1> snmpwalk -v2c -c tr4pp15t cartman 1.3.6.1.4.1.2636.5.1.1.2.6.2.1.7.0SNMPv2-SMI::enterprises.2636.5.1.1.2.6.2.1.7.0.1.1 = Gauge32:7

許可プレフィックス総数：nms-1> snmpwalk -v2c -c tr4pp15t cartman 1.3.6.1.4.1.2636.5.1.1.2.6.2.1.8.0SNMPv2-SMI::enterprises.2636.5.1.1.2.6.2.1.8.0.1.1 = Gauge32:1

拒否プレフィックス総数：> snmpwalk -v2c -c tr4pp15t cartman 1.3.6.1.4.1.2636.5.1.1.2.6.2.1.9.0SNMPv2-SMI::enterprises.2636.5.1.1.2.6.2.1.9.0.1.1 = Gauge32:6

SNMPを介して、合計で 7つのルート受け取ったことがわかります。そのうちの 1つがインデックス 0のピア（10.200.7.2）から許可され、残り6つは拒否されています。show bgp summaryコマンドを実行して、裏付けをとります。

ps@dunkel-re0> show bgp summary Groups:1 Peers:1 Down peers:0Table Tot Paths Act Paths Suppressed History Damp State Pendinginet.0 7 1 0 0 0 0Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Damped...10.200.7.2 1 130 123 0 11 53:55 1/7/0 0/0/0


BGPオペレーションモードコマンド

大半の BGPオペレーションモードコマンドは、隣接機器に関する情報や、それらピアから受信、許可、および拒否されたプレフィックス数を表示します。最も頻繁に使用するのは、show bgp summaryコマンドです。以下に示すように、すべてのBGP隣接機器、それらの状態、ピアから受け取ったプレフィックスに関する情報を示します。

ps@dunkel-re0> show bgp summary Groups:1 Peers:1 Down peers:0Table Tot Paths Act Paths Suppressed History Damp State Pendinginet.0 4 1 0 0 0 0Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Damped...10.200.7.2 1 220 211 0 11 1:33:38 1/7/0 0/0/010.200.7.3 1 0 0 0 0 1:52 Active

ここでは、10.200.7.2から 7つのルートを受け取り、そのうちの 1つが許可されました。セッションが確立されていない場合は、10.200.7.3へのセッションで示されるように、active/received/

dampenedプレフィックス数の代わりに状態が表示されます。また、どちらのピアもAS 1内にあり、10.200.7.2へのセッションが確立してからの経過時間は 1:33:38で、10.200.7.3へのセッションは 2分近くダウンしていることがわかります。セッションが確立またはダウンしてから経過した時間を把握することは、状態の変化とネットワークイベントや設定との関係性を理解する上で役立ちます。show bgp neighborコマンドを実行することで、各 BGPピアの追加情報が提供されます。このコマンドで、特定のピアを指定して（例えば、show bgp neighbor 10.200.7.2）、そのピア固有の情報を表示できます。このオプションを省略した場合は、すべてのピアに関する情報が表示されます。

ps@dunkel-re0> show bgp neighbor 10.200.7.2 Peer:10.200.7.2+53667 AS 1 Local:10.200.7.1+179 AS 1 Type:Internal State:Established Flags:<Sync> Last State:OpenConfirm Last Event:RecvKeepAlive Last Error:Cease Options:<Preference LocalAddress LogUpDown PeerAS Refresh> Local Address:10.200.7.1 Holdtime:90 Preference:170 Number of flaps:11 Last flap event:RecvNotify Error:‘Hold Timer Expired Error’ Sent:1 Recv:0 Error:‘Cease’ Sent:1 Recv:10 Peer ID:10.200.7.2 Local ID:10.200.7.1 Active Holdtime:90 Keepalive Interval:30 Peer index:0 BFD: disabled, down


NLRI advertised by peer: inet-unicast NLRI for this session: inet-unicast Peer supports Refresh capability (2) Table inet.0 Bit:10000 RIB State:BGP restart is complete Send state: in sync Active prefixes: 1 Received prefixes: 7 Suppressed due to damping: 0 Advertised prefixes: 5 Last traffic (seconds):Received 18 Sent 3 Checked 59 Input messages: Total 287 Updates 11 Refreshes 0 Octets 5730 Output messages:Total 278 Updates 0 Refreshes 0 Octets 5308 Output Queue[0]:0

この出力は、明らかに多くの情報を含んでいます。設定に関する情報や、状態に関する情報も含まれています。最初の数行は、セッションの現在および最近の状態を反映したものです。現在の状態はEstablished、最後の状態は OpenConfirmであり（BGPフィニットステートマシンにおける Establishedに先行するステップ）、セッションの最後のエラーメッセージは Ceaseでした。

さらにセッションタイプとして Internalが示されており、これが内部BGP（iBGP）セッションであることがわかります。ローカルアドレスは 10.200.7.1（iBGPの一般表記である lo0.0アドレス）、ホールドタイマーは 90、キープアライブは 30（デフォルト値）にそれぞれ設定されています。さらに、ピアインデックス（SNMPの説明で使用したものと同一）やこのセッションでサポートする機能が inet-unicast（他のオプションとしては inet-multicastまたは inet-vpnがある）であることがわかります。終盤の show bgp neighborの出力には、プレフィックスに関する情報が示され、7つのプレフィックスを受け取り、そのうちの 1つを使用していることがわかります。抑制されたルートはなく、5つのルートがピアにアドバタイズされています。その情報に続くのは、BGP制御トラフィック統計です。その他の重要な BGP運用コマンドには、BGPを介して受け取った全ルートを表示する show route protocol bgp、ピアにアドバタイズされたルートを表示する show route advertising-protocol bgp

[neighbor]、あるピアから受け取ったルートを表示する show route

receive-protocol bgp [neighbor]などがあります。以下に、show

route protocol bgpコマンドの実行による出力を示します。ps@dunkel-re0> show route protocol bgp



10.200.7.2/32 [BGP/170] 02:04:22, localpref 100, from 10.200.7.2 AS path:I > via so-2/0/0.018.32.74.0/30 [BGP/170] 01:44:10, localpref 100, from 10.200.7.2 AS path:I > via so-2/0/0.0112.74.9.0/30 *[BGP/170] 02:04:22, localpref 100, from 10.200.7.2 AS path:I > via so-2/0/0.0172.19.110.0/23 [BGP/170] 02:04:22, localpref 100, from 10.200.7.2 AS path:I > via so-2/0/0.0181.21.0.0/22 [BGP/170] 02:04:22, localpref 100, from 10.200.7.2 AS path:I > via so-2/0/0.0192.168.0.0/16 [BGP/170] 02:04:22, localpref 100, from 10.200.7.2 AS path:I > via so-2/0/0.0199.0.65.0/24 [BGP/170] 02:04:22, localpref 100, from 10.200.7.2 AS path:I > via so-2/0/0.0

ここでも、文字 +または *は、そのルートが使用されていることを示します。この情報は、受け取ったルート 7つのうち、1つ（112.74.9.0/30）を使用しているという show bgp neighborの出力に一致します。

次に、ピアに対して何がアドバタイズされているかを確認します。ps@dunkel-re0> show route advertising-protocol bgp 10.200.7.2

inet.0:16 destinations, 22 routes (16 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path* 4.18.99.0/24 Self 100 I* 10.200.7.1/32 Self 100 I* 10.200.7.3/32 Self 100 I* 18.32.74.0/30 Self 100 I* 172.19.110.0/23 Self 100 I

この出力は、10.200.7.2のピアに対して 5つのルートがアドバタイズされているという show bgp neighborコマンドの出力に一致します。ルートのローカル優先度として 100（デフォルト）、ASパスにはInternal（内部）を意味する Iが設定され、ルートの接続元はローカル ASであることを意味します。 show route receive-protocol bgp [neighbor]コマンドを実行することで、隣接機器から受け取ったルートが表示されます。前に実行したshow bgp neighborの出力から、7つのルートが示されることが想定されます。


ps@dunkel-re0> show route receive-protocol bgp 10.200.7.2

inet.0:16 destinations, 22 routes (16 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 10.200.7.2/32 10.200.7.2 100 I 18.32.74.0/30 10.200.7.2 100 I* 112.74.9.0/30 10.200.7.2 100 I 172.19.110.0/23 10.200.7.2 100 I 181.21.0.0/22 10.200.7.2 100 I 192.168.0.0/16 10.200.7.2 100 I 199.0.65.0/24 10.200.7.2 100 I

これは、show bgp neighborの出力に基づいた想定内容と一致するだけでなく、7つのルートを受け取り、そのうちの 1つ（112.74.9.0/30へのルート）を使用しているという show route protocol bgpの出力に基づいた想定内容にも一致します。

まとめ各プロトコルには、そのプロトコル固有のイベントに対して作成される独自のログおよびトラップのセットがあります。これらのログやトラップには、設定が必要なものもあります。

レイヤー 3で監視を行う際には、IPネットワークは相互接続されたシステムであり、OSIモデルの下位レイヤーには依存しないことを理解することが非常に重要です。技術者または NMSシステムのどちらであっても、問題の根本的原因を素早く特定するためには、システムログや SNMPトラップを収集することが有益な手段です。

レイヤー 3での問題が、レイヤー 1およびレイヤー 2での問題によって引き起こされることは珍しくありません。そのため、前述のように何らかのコマンドを実行する前に、可能性として考えられる原因を絞り込むことから始めるトラブルシューティング戦略を確立し、OSIモデルに従い、プロトコルで提供される操作や機能を効果的に活用することは、ネットワーク問題を素早く切り分けて解決する上で不可欠です。

第7章

レイヤー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.1traceroute 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.1traceroute 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


Dunkelは 18.32.75.1であるため、ここを調査の開始箇所とすべきです。このケースでは、Dunkelでのルーター操作と、その後で行うPilsenerでのルーター操作によって、サービスプロバイダへのリンクがダウンしたことが判明します（おそらく、SyslogまたはSNMPによって通知済み）。この時点で、接続のローカル側のハードウェアを取り付け直し、再設定、および /または交換して、正常に動作することを確認します。問題が引き続き発生する場合は、サービスプロバイダに連絡してサポートを要請してください。ポイントツーポイントではないイーサネット接続など、接続のリモート側の障害が発生しても回線がダウンしない状況もあります。ここで、図 7-3に示すように、サービスプロバイダへの接続を、サービスプロバイダにてレイヤー 2スイッチを経由してからルーターに接続するイーサネットリンクに変更します。図 7-4には、サービスプロバイダルーターの障害を示します（または、サービスプロバイダスイッチからサービスプロバイダルーターへの接続の障害）。

図 7-3および 7-4 サービスプロバイダへのイーサネットリンクとその障害

以下に、このタイプの障害が発生している状況で tracerouteを実行した場合の出力を示します。

server % traceroute 4.2.2.1traceroute 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


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台のルーター（直接接続されたルーター同士が多い）が、特定の宛先に対するネクストホップとして互いを選択した場合に発生します。これは、スタティックルート環境で多く見られます。ルーティングループは、ルート変動が生じている場合にも発生しますが、そうした状況ではループは必ずしも持続的に発生はしません。ルート変動については、本章で後述します。図 7-5に示すトポロジーへの追加を例にとります。企業環境が拡張されたため、LANアグリゲーションルーター Altbierの追加が必要になりました。Altbierは、Dunkelとほぼ同じように設定されています。Pilsenerを経由するデフォルトルートをOSPFから受け取っています。Pilsenerは、Altbierをネクストホップとする 18.32.76.0/23ネットワークへのスタティックルートを持ちます。


図 7-5 2台目の LANアグリゲーションルーターの追加

Altbierは、Pilsenerをネクストホップとするデフォルトスタティックルートを持ちます。Dunkelに接続されたホストから tracerouteを実行すると、以下が出力されました。

server% traceroute 18.32.76.7traceroute to 18.32.76.7 (18.32.76.7), 30 hops max, 40 byte packets 1 18.32.75.1 (18.32.75.1) 4.157 ms 3.735 ms 2.478 ms ßdunkel 2 18.32.74.6 (18.32.74.6) 8.913 ms 5.878 ms 5.518 ms ß pilsener 3 18.32.74.62 (18.32.74.62) 12.153 ms 7.266 ms 5.775 ms ß altbier 4 18.32.76.7 (18.32.76.7) 6.013 ms 4.567 ms 3.612 ms ß destination

このシナリオでルーティングループを引き起こす可能性のある障害としては、18.32.76.0/24ネットワークへの Altbierリンクの障害が挙げられます。Pilsenerでは、Altbierで発生している障害をまったく認識しておらず、18.32.76.0/23ネットワークへのスタティックルートを引き続き使用するために、ルーティングループが生じます。パケットが Altbierに到達すると、18.32.76.0/24ネットワークへのインタフェースがダウンしているため、そのネットワークへのルートがありません。次善のルートは Pilsenerへ向かうデフォルトルートですが、スタティックルートのためにパケットは Altbierに送り返されます。

server% traceroute 18.32.76.7traceroute to 18.32.76.7 (18.32.76.7), 30 hops max, 40 byte packets 1 18.32.75.1 (18.32.75.1) 6.156 ms 2.181 ms 1.534 ms ß dunkel 2 18.32.74.6 (18.32.74.6) 9.631 ms 10.610 ms 3.273 ms ß pilsener 3 18.32.74.62 (18.32.74.62) 3.315 ms 3.728 ms 6.280 ms ß altbier 4 18.32.74.61 (18.32.74.61) 4.833 ms 8.704 ms 6.481 ms ß pilsener 5 18.32.74.62 (18.32.74.62) 7.148 ms 7.928 ms 3.979 ms ß altbier 6 18.32.74.61 (18.32.74.61) 3.779 ms 4.372 ms 3.427 ms ß pilsener 7 18.32.74.62 (18.32.74.62) 4.701 ms 4.005 ms 9.300 ms ß altbier 8 18.32.74.61 (18.32.74.61) 7.323 ms 7.616 ms 2.357 ms ß pilsener 9 18.32.74.62 (18.32.74.62) 3.373 ms 3.322 ms 10.979 ms ß altbier10 18.32.74.61 (18.32.74.61) 3.315 ms 10.498 ms 4.453 ms ß pilsener


この tracerouteで示されるように、PilsenerとAltbierの間のトラフィックはループしています。問題を疑うべき箇所は明確です。ルーティングループで問題が発生している箇所は、ほぼ常に、トラフィックがループしているルーターのいずれかです。この例では、どちらのルーターも問題に関与しています。対象ネットワークへの Altbierの接続はダウンしており、そのネットワークへのインタフェースもダウンしているにもかかわらず、Pilsenerはトラフィックを Altbierに送っています。

ネットワークオペレータが最初にとるべきステップは、18.32.76.0/24ネットワークへの Altbierの接続を修復することです。そして後で、Altbierで OSPFを使用して、そのネットワークへの接続が確立している限りルートのアドバタイズを行うなど、設定をより動的なアーキテクチャに移行させるのが良策です。全停止障害に救いがあるとすれば、それが完結している点です。曖昧さ、矛盾、不確定な要素がありません。tracerouteを実行するだけで、問題が発生している場所を特定し、それを確定させるためにどのデバイスにログインすべきかがわかります。

回線過剰利用のトラブルシューティング回線の過剰利用は、パケットロスを多々引き起こしますが、厄介なのは間欠的である点です。トラフィックのタイプ（一貫性があるかバースト性があるか）、トラフィック量（過剰利用の程度が若干であるか劇的であるか）、および Class-of-Serviceの設定に応じて、パケットフローごとに経験するパケットロスのレベルは異なります。第 2章で示した障害例では、回線の過剰利用が生じているシナリオに対する一貫性のあるトラブルシューティングアプローチとフィックステストの適用について説明しました。

ルート変動のトラブルシューティングルート変動は、特定と素早い切り分けが最も困難な問題の 1つです。ルート変動では、全停止障害、一部停止障害、ジッター増加など、さまざまな兆候が見られます。ルーティングテーブルでルートの追加と削除が素早く繰り返された場合に、ルート変動が発生します。これは、急激な回線の遷移、共有ルートの再配布、その他さまざまな理由で発生します。


ルート変動の問題を特定する最良の方法は、発生時に観察することです。これは、2つの方法で達成できます。まず、tracerouteを複数回実行することで、ルートが変動するに伴って使用される多数の異なるパスを確認できます。その後で、変動が発生しているルーター上でshow routeコマンドを実行します。これにより、複数のネクストホップおよび /または異なるプロトコルから受け取ったルートの組み合わせが示されます。前述の 18.32.76.0/24ネットワークに対してAltbierが接続を失ったシナリオは、ルート変動の問題を引き起こす状況へと簡単に発展します。リンクアップ時には、トラフィックは想定どおりに流れます。しかし、リンクダウンが発生すると、PilsenerとAltbierの間のトラフィックはループします。このリンクが急激に遷移した場合には、ユーザーやオペレータは、正常なトラフィックフローとトラフィックループを交互に経験することになります。このケースでは、ルート変動とルーティングループの両方が発生します。共有ルートの再配布も、ルート変動を引き起こします。共有ルートの再配布は、2つのプロトコルが相互に再配布されるときに発生します。慎重に設定しない場合、このタイプのアーキテクチャはネットワーク障害を引き起こし、トラブルシューティングを困難にします。この手法は、移行期間に最も多く用いられます（EIGRPからOSPFへの移行など）。しかし、他の問題を解決するために、この手法を長期間にわたり採用し続けるネットワークもあります。

ここでは、共有ルート再配布がどのようにルート変動を引き起こすのかを理解するために、遷移する例を示します。現在のネットワークを例にとりますが、図 7-6に示すように、サービスプロバイダとの関係を（スタティックルートを使用しない）BGPピアリング関係に変更します。

図 7-6 eBGPによるインターネットサービスプロバイダとの接続


この Pilsenerとサービスプロバイダの間のセッションで、以下のように、サイトのネットワーク（18.32.72.0/21）に対してアグリゲーションルートを通知し、フルインターネットルーティングテーブルを受け取ります。

ps@pilsener-re0> show bgp summary Groups:1 Peers:1 Down peers:0Table Tot Paths Act Paths Suppressed History Damp State Pendinginet.0 10007 10007 0 0 0 0Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...4.10.33.2 3356 10019 29 0 0 11:14 10007/10007/10007/0 0/0/0/0

特定のプレフィックス（4.0.0.0/8）に対してルートが頻繁にフラッピングしている間に、インターネット上の接続先に対してテストを実行することで、ルート変動が明らかになります。

ps@pilsener-re0> ping 4.2.2.1 PING 4.2.2.1 (4.2.2.1):56 data bytesping: sendto:No route to hostping: sendto:No route to hostping: sendto:No route to hostping: sendto:No route to host64 bytes from 4.2.2.1: icmp_seq=4 ttl=64 time=0.524 ms64 bytes from 4.2.2.1: icmp_seq=5 ttl=64 time=0.697 ms64 bytes from 4.2.2.1: icmp_seq=6 ttl=64 time=0.558 ms64 bytes from 4.2.2.1: icmp_seq=7 ttl=64 time=0.579 ms64 bytes from 4.2.2.1: icmp_seq=8 ttl=64 time=0.625 ms64 bytes from 4.2.2.1: icmp_seq=9 ttl=64 time=0.582 ms64 bytes from 4.2.2.1: icmp_seq=10 ttl=64 time=0.563 msping: sendto:No route to hostping: sendto:No route to hostping: sendto:No route to hostping: sendto:No route to hostping: sendto:No route to hostping: sendto:No route to hostping: sendto:No route to host64 bytes from 4.2.2.1: icmp_seq=18 ttl=64 time=0.613 ms64 bytes from 4.2.2.1: icmp_seq=19 ttl=64 time=0.585 ms64 bytes from 4.2.2.1: icmp_seq=20 ttl=64 time=0.642 ms64 bytes from 4.2.2.1: icmp_seq=21 ttl=64 time=0.605 ms64 bytes from 4.2.2.1: icmp_seq=22 ttl=64 time=0.562 ms64 bytes from 4.2.2.1: icmp_seq=23 ttl=64 time=0.589 ms64 bytes from 4.2.2.1: icmp_seq=24 ttl=64 time=0.607 ms


この間に、pingおよび tracerouteを実行することで、4.0.0.0/8への BGPルートが確立と喪失を繰り返すことがわかります。その結果、このネットワーク内の任意接続先に対してパケットロスを間欠的に経験することもわかります。これまで説明してきた裏付けの重要性から、接続先4.2.2.1に対してshow routeコマンドを実行し、変動を観察します。

ps@pilsener-re0> show route 4.2.2.1


4.0.0.0/8 *[BGP/170] 00:00:07, localpref 100 AS path:3356 I > to 4.10.33.2 via so-2/2/0.0




4.0.0.0/8 *[BGP/170] 00:00:02, localpref 100 AS path:3356 I > to 4.10.33.2 via so-2/2/0.0

ps@pilsener-re0> traceroute 4.2.2.1 traceroute to 4.2.2.1 (4.2.2.1), 30 hops max, 40 byte packets1 4.10.33.2 (4.10.33.2) 0.231 ms 0.411 ms 0.376 ms2 4.1.18.21 (4.1.18.21) 0.193 ms 0.469 ms 0.288 ms3 4.2.2.1 (4.2.2.1) 0.587 ms 0.612 ms 0.517 msps@pilsener-re0> traceroute 4.2.2.1 traceroute to 4.2.2.1 (4.2.2.1), 30 hops max, 40 byte packetstraceroute: sendto:No route to host 1 traceroute: wrote 4.2.2.1 40 chars, ret=-1

この状況では、サービスプロバイダに連絡し、ルートのアドバタイズと撤回が繰り返されている理由について問い合わせることを推奨します。一貫性のないパケットロスは、素早く特定して解決することが難しくなります。しかし、これは多くの場合、回線の過剰利用、ルート変動、急激に遷移する回線、あるいはそれらの組み合わせによって発生します。


遅延のトラブルシューティング遅延とは、送信元から送信先にパケットが届くのにかかる時間が遅れる現象です。遅延問題の根本的原因の特定と切り分けは、非常に困難です。それは、遅延に一貫性がなく、特定のトラフィックタイプに限定され、再現が難しいことがあるためです。ネットワークのトポロジー、採用するプロトコル、ネットワークの現在の状態、有効にしている機能（Class-of-Serviceなど）を理解することは、遅延問題（およびその損失については後述）を解決する上で役立ちます。

遅延問題は、特に音声 /動画など、リアルタイムのアプリケーションで深刻な問題を引き起こします。問題を報告しているユーザーは、遅延が原因であることを認識していないこともあります。問題レポートには、単に通話の途切れや動画でノイズが生じていると記載されているかもしれません。HTTPなどの通常のトラフィックでは、遅延パケットが発生しても、受信者は次のパケットを受信できるまで待つだけで、その時間も一瞬であることが多いため、それほど大きな問題にはなりません。しかし、音声 /動画ストリームでパケットの遅延が長くなると、受信者側にとってはパケットが消失した状況と何ら変わりのない深刻な事態となります。遅延問題をトラブルシューティングする際の最初のステップは、トラフィックが最適パスを辿っているかを特定することです。これには、当然ながらネットワークに対する深い理解が必要ですが、準最適ルーティングを引き起こすような障害が現時点で発生しているかを把握することも不可欠です。

ネットワーク例で tracerouteを実行すると、ネットワーク、Dunkel、Pilsener、サービスプロバイダの順に、トラフィックが最適パスを通過していることがわかります。

次のステップは、遅延を誘発しているネットワークホップを特定することです。以下の tracerouteの実行で、ルーター 2と3の間のホップで明らかな遅延を引き起こしていることがわかります。

server% traceroute 4.2.2.1traceroute to 4.2.2.1 (4.2.2.1), 30 hops max, 40 byte packets 1 18.32.75.1 (18.32.75.1) 4.435 ms 3.117 ms 3.413 ms ßDunkel 2 18.32.74.6 (18.32.74.6) 4.935 ms 12.434 ms 2.826 ms ß Pilsner 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) 128.269 ms 137.346 ms 133.977 ms

5～ 10ミリ秒程度の遅延が、ルーター 2と3の間のホップで 100ミリ秒以上まで急激に長くなっています。


詳細な調査をすべき箇所が特定できました。この時点では、問題の原因はルーター 2またはルーター 3上でキューイングしている受信または送信トラフィックであると推測できます。大きなパケットキューイングが発生しているため、最初に確認すべき箇所はルーター 2からルーター 3へのリンクです。

このリンクでは、利用率が低ければパケットキューイングは発生しないため、利用率が高いことが想定できます。そのため、show

interfacesコマンドを実行して、ルーター 3へのトラフィックを処理しているルーター 2のインタフェースを確認します。

ps@pilsener> show interfaces fe-0/0/1Physical interface: fe-0/0/1, Enabled, Physical link is Up Interface index:128, SNMP ifIndex:61 Link-level type:Ethernet, MTU:1518, Speed:100mbps, Loopback:Disabled, Source filtering:Disabled, Flow control:Enabled Device flags :Present Running Interface flags:SNMP-Traps Internal:0x4000 CoS queues :4 supported, 4 maximum usable queues Current address:00:90:69:6b:14:00, Hardware address:00:90:69:6b:14:00 Last flapped :2010-01-12 06:00:14 EST (2w5d 22:24 ago) Input rate :71441794 bps (46877 pps) Output rate :96542771 bps (63598 pps) Active alarms :None Active defects :None

Logical interface fe-0/0/1.0 (Index 67) (SNMP ifIndex 56) Description:Connection to service provider 1 Flags:SNMP-Traps 0x4000 VLAN-Tag [ 0x8100.5 ] Encapsulation:ENET2 Input packets :0 Output packets:0 Protocol inet, MTU:1500 Flags:None Addresses, Flags:Is-Preferred Is-Primary Destination:4.10.33.0/30, Local:4.10.33.1/30, Broadcast:4.10.33.2

Logical interface fe-0/0/1.32767 (Index 68) (SNMP ifIndex 58) Flags:SNMP-Traps 0x4000 VLAN-Tag [ 0x0000.0 ] Encapsulation:ENET2 Input packets :0 Output packets:0

このリンクは、過剰利用されている可能性が高いことがわかります。キュー統計を確認して、裏付けをとります。ジュニパーネットワークスのルーターでは、デフォルトで 2つのキューが有効化されます。一方は、ルーティングプロトコルおよび制御プレーントラフィックを制御するためのネットワーク制御キューです。帯域幅の 5%およびバッファ容量の 5%が割り当てられます。もう一方は、他のトラフィック用のベストエフォートキューで、帯域幅の残りの 95%およびバッファ容量の 95%を使用します。


このリンクで、ある程度規模の大きなキューが発生しているかどうかを確認するには、show interface queueコマンドを実行します。このトラフィックはベストエフォートキューにあることを把握しているため、この転送クラスに限定してコマンドを実行できます。

ps@pilsener> show interfaces queue fe-0/0/1 forwarding-class best-effort Physical interface: fe-0/0/1, Enabled, Physical link is Up Interface index:137, SNMP ifIndex:32Forwarding classes:8 supported, 8 in useEgress queues:8 supported, 8 in useQueue:0, Forwarding classes: best-effort Queued: Packets : 12196904 3179 pps Bytes : 643712025753 9004563 bps Transmitted: Packets : 12196904 3179 pps Bytes : 643712025753 9004563 bps Tail-dropped packets : 0 0 pps RED-dropped packets : 0 0 pps Low : 0 0 pps Medium-low : 0 0 pps Medium-high : 0 0 pps High : 0 0 pps RED-dropped bytes : 0 0 bps Low : 0 0 bps Medium-low : 0 0 bps Medium-high : 0 0 bps High : 0 0 bps

このインタフェースで、キューイングが発生しています。約 9メガビットのトラフィックがキューにあり、遅延を引き起こしている原因であると考えられます。このようなキューイング問題には、3つの解決方法があります。

� 音声、動画、およびその他のリアルタイムトラフィックを EF（Expedited Forwarding）キューに分類して、ベストエフォートキューよりも高い優先度を設定します。

� すべての送信トラフィックが有効であるかどうかを調べます。 � サービスプロバイダへの接続スピードを向上させます。


まとめレイヤー 3の監視およびトラブルシューティングは、レイヤー 1およびレイヤー 2とは根本的に異なるものの、同じ手法とアプローチを用いてレイヤー 3での問題を切り分けして、解決することができます。本書でこれまで説明してきた一貫性のある論理的アプローチをとり、フィックステストを適用することで、迅速な診断とサポート可能な短期的フィックスの実装が可能になります。レイヤー 3でトラブルシューティングを行う際は、それが相互接続されたシステムであり、ネットワーク内の一部のルーターが別のルーターの挙動に基づいて動作する可能性があることを念頭に置いてください。その一例は、ルートタギングとClass-of-Serviceマーキングです。ネットワークの運用経験、採用するプロトコルや通常条件下での運用状況を理解していることに代わるものはありません。しかし、各プロトコルがどのように機能し、Junosで提供される機能、操作、ツールの活用方法を明確に理解するとともに、ネットワークを運用するための正しいアプローチをとることで、こうした作業が非常に容易になります。

114

次のステップと参照 URL

www.juniper.net/dayone

本書の印刷版を読んでいる場合、このサイトからPDF版をダウンロードできます。PDF版の付録には、補足情報が含まれています。さらに、このサイトでは、現在入手可能な他の Day Oneシリーズについても確認できます。

www.juniper.net/junos

Junosの導入およびトレーニングに関して必要なすべての情報は以下のサイトで入手できます。

http://forums.juniper.net/jnet

ジュニパーネットワークスがスポンサーとなっている J-Netコミュニケーションフォーラムは、ジュニパーネットワークスの製品、テクノロジー、およびソリューションに関する情報、ベストプラクティス、および疑問点を共有するための場です。是非、この無料フォーラムに参加登録してください。

www.juniper.net/techpubs

このサイトでは、ジュニパーネットワークスが開発したすべての製品資料を無料で利用できます。各製品シリーズのページから、Junosオペレーティングシステムに関する必要な情報を見つけてください。

www.juniper.net/books

ジュニパーネットワークスは複数の出版社と協力し、ネットワーク管理者にとって不可欠なトピックを扱った技術書を制作、出版しています。今後も増え続ける新刊リストをご確認ください。『Junos High Availability』の特別価格での提供については、ivページをご覧ください。

www.juniper.net/jp/jp/training/fasttrack

トレーニングコースをオンライン、オンサイト、または世界中にあるパートナートレーニングセンターで受講できます。ジュニパーネットワークス技術認定資格プログラム（JNTCP）では、ジュニパーネットワークス製品の設定およびトラブルシューティング能力を示すことにより、認定資格を取得することができます。エンタープライズルーティング、スイッチング、またはセキュリティの認定資格を短期間で取得したい方は、オンラインコース、受講者ガイド、およびラボガイドをご利用ください。

Documents

Junos の基本 - Juniper Networks...Junos について Junos® は、ルーティング、スイッチング、セキュリティをカバーする高信 頼性かつ高性能なネットワークOSです。新サービス導入に伴う所要期

Junos の基本 - Juniper Networks...Junos について Junos® は、ルーティング、スイッチング、セキュリティをカバーする高信頼性かつ高性能なネットワークOSです。新サービス導入に伴う所要期