Junos の基本 ® Day One：Junosの監視および トラブルシューティング 著者：ジェイミー・パナゴス、 アルバート・スタッティ 第1章：根本的原因の特定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 第2章：フィックステストの適用. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17 第3章：CLIの操作 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 第4章：システムの監視およびトラブルシューティング . . . . . . . . . . . . . . . . . . . . . 39 第5章：レイヤー1およびレイヤー2の監視およびトラブルシューティング . . . . 55 第6章：レイヤー3の監視. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 第7章：レイヤー3のトラブルシューティング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99 ii © 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 iii 本書を読む前に知っておくべきこと 対象ネットワークで採用しているトポロジー、トラフィックフロー、 およびプロトコルをしっかりと理解していること Junos CLI に精通していること Syslog や SNMP などのネットワーク監視プロトコルを扱った 経験があること ネットワーク管理システムで何を行い、どのように行うかなど、 理解していること OSI モデルと、それがネットワークプロトコルやネットワーク構 成要素にどのように適用されるのかを把握していること 本書の学習目標 デバイスにログインしなくても、ネットワークで発生している問 題の原因と場所を予測すること 技術者および監視システムがネットワークを運用する上で必要と なるすべての情報をまとめた監視およびトラブルシューティング の標準テンプレートを作成すること 異なるプロトコルや技術にわたり、迅速かつ効果的なトラブル シューティングを行えるよう OSI モデルを活用すること Junos が備える機能を用いて、デバイスおよびネットワークの 正常性を監視し、ネットワークダウンタイムを短縮すること ネットワークに対する処置の適確性を確認するための独自テスト を開発すること 注 お客様のご意見やご批評をお聞かせください。ご提案は、dayone@ juniper.net まで電子メールでお送りください。 iv 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% の割引が適用されます。 第1章 根本的原因の特定 フィックステスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 本書で使用するネットワーク . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6 Day One：Junosの監視およびトラブルシューティング 問題のトラブルシューティングで達成すべき第一の目標とは、その根 本的原因の特定です。本セクションでは、ネットワーク問題の根本的 原因を素早く特定するために、手がかりやツールを使用するアプロー チについて説明します。このアプローチを使用することで、経験の浅 いネットワークエンジニアから経験を積んだシニアネットワークエン ジニアまで、調査に要する時間を短縮してダウンタイムを短縮し、最 終的にはコストまで削減できるようになります。 デバイスやネットワーク管理システムにログインしなくても、問題の 性質、調査すべき箇所や事柄を予測することは可能です。問題の特 性を理解するための基本的な質問セットに答えることで、これが可能 になります。 注 この時点では、まだ問題の解決策は見つからないかもしれません。 しかし、ほとんどの状況に対応する不変の質問セットに従うことで、 選択肢を絞り込むことがきるようになります。これらの質問で得られ る答えの内容も重要ですが、ネットワークの監視とトラブルシューティ ングで一貫性が保たれることも同じくらい重要です。 ヒント コンピュータネットワークの複雑性により、原因ではないかと疑った 機器が実際には正常に動作しており、真の根本的原因がネットワー クの別のレイヤー内にある機器であると判明することがあります。 ルーターが、レイヤー 4 での問題を引き起こすことがあります。ある いは、スイッチが、通常はレイヤー 3 での問題と思われる問題を引 き起こすことがあります。要するに、間違った場所で原因を探そうと している可能性があります。そのため、最初に導き出した予測や疑 いを完全に却下せずに、3 次元で立体的に当てはめてみてください。 図 1-1a、1-1b、1-1c、および 1-1d に、ジュニパーネットワークスの 各種デバイスおよびネットワークに対する監視およびトラブルシュー ティングのアプローチ方法を示します。各図は、問題の範囲の提示 から開始します。例えば、図 1-1a は、単一ユーザーが単一接続先に 接続できないネットワーク問題に対するアプローチ方法を示していま す。その後で、影響を受けるトラフィックのタイプ、問題の発生が継 続的または散発的か、さらにはトラブルシューティング作業を集中的 に行う場所を絞り込むことができます。 第1章：根本的原因の特定 問題の範囲 単一ユーザー 単一接続先 接続元ユーザー すべて 継続的 または 散発的 接続先 継続的 一部の プロトコルで一貫 している サービスプロバイダ 散発的 継続的 回線または ルート変動 一部の プロトコルで一貫 していない 散発的 ファイアウォール トラフィックタイプ 問題の一貫性 図 1-1a 単一ユーザーが単一接続先に接続できない トラブルシューティング集中箇所 7 8 Day One：Junosの監視およびトラブルシューティング 問題の範囲 単一ユーザー すべての接続先 接続元ユーザー 継続的 すべて 散発的 継続的 一部の プロトコルで一貫 している 散発的 一部の プロトコルで一貫 していない 継続的 散発的 ファイアウォール トラフィックタイプ 問題の一貫性 図 1-1b 単一ユーザーがすべての接続先に接続できない トラブルシューティング集中箇所 第1章：根本的原因の特定 問題の範囲 すべてのユーザー 単一接続先 接続先 継続的 すべて 散発的 サービスプロバイダ 継続的 一部の プロトコルで一貫 している 散発的 一部の プロトコルで一貫 していない 継続的 散発的 ファイアウォール トラフィックタイプ 問題の一貫性 図 1-1c すべてのユーザーが単一接続先に接続できない トラブルシューティング集中箇所 9 10 Day One：Junosの監視およびトラブルシューティング 問題の範囲 すべてのユーザー すべての接続先 アグリゲーション ポイントの問題 継続的 すべて 散発的 サービスプロバイダ 継続的 一部の プロトコルで一貫 している 回線ダウン 散発的 一部の プロトコルで一貫 していない 継続的 ファイアウォール 散発的 ネットワーク全体の 障害 トラフィックタイプ 問題の一貫性 図 1-1d すべてのユーザーがすべての接続先に接続できない トラブルシューティング集中箇所 第1章：根本的原因の特定 11 ヒント これらの図は、ネットワーク障害の範囲および考えられる原因を特定す る上で役立ちます。この情報を次に示すフィックステストとともに使用す ることで、より素早く問題を切り分け、顧客へのサービス提供を復旧で きるようになります。 フィックステスト 本書を通して、フィックステストと呼ばれる共通の質問セットを作業者と 作業自体に適用します。この質問セットの一例を以下に示します（これ を例として、独自のフィックステストを作成することを推奨する）。 問題の範囲は ? 障害の範囲や規模が何を意味するのかは、人によって異なります。例え ば、主要アカウントで 1 つの Web サイトをダウンロードするのに時折 時間がかかっただけでも、それを大災害として捉える人もいれば、ネッ トワーク全体がダウンしたときに初めて重大事であると捉える人もいま す。この質問については、感情や主観を排除した客観的な目で問題を 調べることが求められます。これは、障害を把握する第一歩として最も 重要なことです。 影響を受ける接続元ネットワークはいくつあるか ? 問題が生じている接続先はどこか ? これに答えることで、問題が接続元、接続先、あるいはより大規模な領 域で発生しているのかを把握できます。単一ユーザー（またはネットワー ク）が、すべての接続先に対して問題が発生していると報告している場 合は、接続元に近いネットワーク構成要素に作業対象を絞るべきです。 多くのユーザーが、単一の接続先（またはネットワーク）に対して問題 が発生していると報告している場合は、接続先に近い箇所で発生してい るか、ピアリングポイントなどのネットワーク相互接続箇所で生じている 問題に起因している可能性があります。問題の発生場所を接続元また は接続先のどちらかに切り分けできない場合、その事象はおそらくネッ トワーク全体で発生しているため、緊急事態として捉えるべきです。 問題を最初に報告したのは誰か ? この質問は、問題が最初に発生した場所（ネットワークに関連するため、 地理的な場所）を特定する上で役立ちます。問題が接続元に関連した もの、接続先に関連したもの、またはネットワーク全体にわたる障害の いずれであっても、この質問に答えることで集中的に最初に調べるべき 箇所を絞り込むことができます。 12 Day One：Junosの監視およびトラブルシューティング 影響を受けるトラフィックのタイプは（複数の場合あり）? この質問の答えは、問題が発生しているのが OSI モデルのどのネット ワークレイヤーであるかを把握する上で役立ちます。接続性が完全に 失われた状況は、通常、レイヤー 3 で問題が発生しているか回線がダ ウンしていることを示します。レイヤー 2 での問題は、一般に、プロ トコルに限定されるものでありませんが、全停止障害を引き起こす可 能性は極めて低いといえます。上位レイヤー（レイヤー 4、5、6、7） での問題は、多くの場合、ファイアウォールに関連する問題が原因です。 この質問に答えることで、集中的に調査すべきエリアだけでなく、問 題を引き起こしている機器を特定できるようになります。レイヤー 2 で の問題は、一般に、イーサネットスイッチか、またはルーターおよび エンドホストポート上のレイヤー 2 エラーに焦点を当てるべきであるこ とを示します。レイヤー 3 での問題は、エンドホスト上のルーターお よび IP スタックを確認すべきであることを示します。 問題の発生は継続的であるか、散発的か ? 継続的に発生する問題は、一般に、設定の誤りやハードウェア障害な どの持続的な問題が原因です。散発的に発生する問題は、一般に、ルー トや回線のフラッピングなど繰り返し発生する問題、あるいはトラフィッ クの一時的な増加によるトラフィックスパイクによる影響を示していま す。ここでも、これらの質問に答えることで、最初に調べるべき箇所を 特定できるようになります。 継続的に発生する問題については、最近、ネットワークに対して何らか の変更が加えられたかを確認するためにログを調べます。また、障害 が発生し始めたときに、何らかの管理作業が予定されていたかをオペ レーションセンターに問い合わせます。こうしたケースに該当しない場 合は、次に、ハードウェアが問題の原因となっているかの特定を試みま す。前述の質問に対する答えは、調査開始場所の特定に役立つはずです。 散発的に発生する問題は、特定が若干難しくなります。トラフィックス パイクは、特に、インタフェースでの送受信レートをポーリングするた めのネットワーク管理システムが導入されている場合には、比較的容 易に特定できます。問題の範囲や規模に基づいて、さらに調査が必要 な疑わしいインタフェースを特定します。 この時点で問題が明白にならない場合は、繰り返し発生する、あるい は何らかの変動に関する問題である可能性があります。Syslog やそ の他の NMS ユーティリティを利用することは、フラッピングしている リンクを特定する上で役立ちます。また、前述の質問に対する答えに 基づいて、調査箇所をある程度絞り込めるようになるはずです。ルー ト変動の問題の場合は、調査対象のネットワークごとに、できる限り 徹底的に接続元から接続先まで、さらには接続先から接続元の双方向 のパスをたどりながら、ルーティング変更があるかどうか各ホップを監 視する必要があります。 第1章：根本的原因の特定 本書で使用するネットワーク 本書では、コアネットワークとして、図 1-2 に示すトポロジーを使用し ます。これは、キャリアやサービスプロバイダなどが採用する大規模 なネットワークを表すために、2 つの企業環境ネットワークによる構 成が示されています。ネットワーク規模にかかわらず、適用する監視 およびトラブルシューティングのスキルは共通ですが、当然ながら大 規模なネットワークでは、そのスキルの適用範囲が広くなり、作業も 多くなります。 図 1-2 本書で使用するネットワークトポロジー 物理的な設計 このトポロジーで示す物理的な設計は、2 つの主要サイト（シカゴお よびボストン）、遠隔地にある 2 つのサイト（イリノイ州ピオリアおよ びアイスランドのレイキャビク） 、およびシカゴサイト内にある小さな データセンターをサポートする比較的シンプルな企業環境ネットワー クを表しています。この物理的な設計の最大の目的は、できる限りの 13 14 Day One：Junosの監視およびトラブルシューティング 冗長性をもたらしながら、拡張性も与えることです。ネットワークのコ アには、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 技術を用いた擬似有線による論理接続によって も接続されています。これらの接続は、ネットワークの他の場所から は他の物理媒体と同じように機能しているように見えますが、論理接 続であるため、監視およびトラブルシューティングの面では異なります。 第1章：根本的原因の特定 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 コマンドを実行しなくても、何を調査すべきか大まかに把握できるよ うにすることです。調査すべき場所だけでなく、調査すべき対象 の目 安が示されます。さらに、トリアージや通知手順を開始するための追 加人員や、必要であればイベント管理グループを確保するために先制 的に通知することができます。人員を追加できれば、問題の早期解決 にもつながります。 15 16 Day One：Junosの監視およびトラブルシューティング ヒント 前線のサポート要員は、実際に問い合わせを受ける前に問題を認識し ていることで、より最適なサポートを提供できるようになります。また、 サポート要員から運用部門およびエンジニアリング部門へのフィード バックは、問題の切り分けと解決に役立ちます。 本書では、どのような問題の根本的原因を特定するときにも、共通の アプローチを使用します。本書では、前述の質問に答えて問題を切り 分けるアプローチ方法について説明するとともに、根本的原因の特定 に役立つ機能や操作も示します。 最後に、顧客に影響を及ぼさないよう先を見越して問題を探し出せる ように、管理および監視手法を見直し、障害発生時にそれらの手法を どのように適用するかについて説明します。 本書で示すすべての監視およびトラブルシューティング手法は、Junos OS リリース 10.1 に基づきます。 第2章 フィックステストの適用 トラフィック制御および過負荷のトラブルシューティング . . . . . . . . . . . . . . . . . . . 18 フィックステスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 18 Day One：Junosの監視およびトラブルシューティング 問題の根本的原因を特定できたら（第 1 章）、次のステップでは、そ れを解決します。本章では、短期的フィックスおよび長期的フィックス の 2 つのタイプのフィックスについて説明します。 意図的に汎用的な呼び方をしていますが、短期的フィックスや極端な ケースではハッキングも、本書で定義する以下のフィックステスト基準 を満たせば容認できる解決方法となることを示します。 フィックスが他の問題を引き起こさないこと フィックスが再起動後も有効であること フィックスが明確に伝達されること フィックスの運用方法がわかりやすいこと フィックスが、ある程度の期間内に長期的フィックスで置き換え られること これらの要件が満たされた場合、その短期的フィックスは完全に容認 できるものです。どの（短期的または長期的）フィックスも、必ず迅 速なサービス提供の復旧を最大の目標とするべきです。 トラフィック制御および過負荷のトラブルシューティング このフィックステストアプローチの優れた例として、短期的にはトラ フィック制御、長期的には容量アップグレードが挙げられます。図 1-2 に示すネットワークを例にとります。両サービスプロバイダから BGP を介してフルインターネットルーティングテーブルを受け取ります。ま た、ローカルプリファレンスを使用して、シカゴをプライマリ出口ポイ ントとして選択し、ボストンのピアリングポイントをバックアップとして 設定します。AS パスプリペンドを使用して、戻りトラフィックが必ずシ カゴの接続を経由するようにしていますが、複数のユーザーから、ピー ク時間帯のインターネットアクセスが遅いとの苦情を受けています。 この問題は、すべてのユーザーおよびすべての外部接続先で発生して いることから、単一ユーザーに限定的な問題ではなく、任意のアグリ ゲーションポイント（出口ポイントなど）で発生している可能性がある ことが推測できます。さらに、問題が散発的に発生することから、ト ラフィックレベルに関連していることも推測できます。 ネットワーク管理システムを使用するか（図 2-1）、CLI でトラフィック レベルを確認することで（図 2-1 の後）、このネットワークでは、シカ ゴのプライマリサービスプロバイダへのアウトバウンドのギガビット イーサネットリンクが過剰利用されていることがわかります。ネットワー クオペレータには、図 2-1 のようなグラフが示されます。 第2章：フィックステストの適用 図 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 利用状況グラフ 19 20 Day One：Junosの監視およびトラブルシューティング 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:0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 13986 6993 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/ Received/Damped... 第2章：フィックステストの適用 10.25.30.1 0/0/0 10.25.30.3 0/0/0 18.32.16.102 0/0/0 10 7013 7112 0 0 13:07 6993/6993/0 10 28 7111 0 0 12:41 0/0/0 107 7006 6277 0 0 8:10 0/6993/0 の出力を見ると、AS 107 は 6993 のルートを送信し ていますが、そのどのルートも boston-edge-1 ではアクティブではあ りません。これは、現在「0/6993/0」と表示しているフィールドに示 されています。最初の値はアクティブなルート数、2 番目の値は受け取っ たルート数、最後の値は減衰ルート数を示します。この BGP セッショ ンに適用したポリシーを見直すには、以下のように show configuration protocols bgp group [group-name] コマンドを使用します。 show bgp summary 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-insecondary 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, * = Both 8.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 21 22 Day One：Junosの監視およびトラブルシューティング [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 第2章：フィックステストの適用 BGP 23 AS path:44 107 I Communities:107:100 Localpref:100 Router ID:10.25.30.1 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 24 Day One：Junosの監視およびトラブルシューティング 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:0 Table Tot Paths Act Paths Suppressed History Damp State inet.0 13986 6993 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn Received/Damped... 10.25.30.1 10 7013 7112 0 0 13:07 0/0/0 10.25.30.3 10 28 7111 0 0 12:41 0/0/0 18.32.16.102 107 7006 6277 0 0 8:10 0/0/0 Pending 0 State|#Active/ 5737/6993/0 0/0/0 1256/6993/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 第2章：フィックステストの適用 BGP 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 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 25 26 Day One：Junosの監視およびトラブルシューティング ル ー タ ー へ の 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/17 Interface: so-3/2/2, Enabled, Link is Up Encapsulation:PPP, Keepalives, Speed:OC12 Traffic 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) 第2章：フィックステストの適用 Output rate :6739379368 bps (23159379 pps Active defects :None Active alarms :None 太字で表示された行には、シカゴのプロバイダの接続上の出力トラ フィックレベルが約 670 メガビットまで低減したことがわかります。こ れは、アウトバウンドトラフィック利用率を 70% まで低減させるという 当初の目標を達成しています。 フィックステスト ユーザーが遭遇していた接続に関する問題を解決するよう、ネットワー クトラフィックを正しく制御できました。これは短期的なフィックスであ るため、短期的フィックステストを実行して、内容が容認できるものか を確認する必要があります。 フィックスが他の問題を引き起こしていないか ? 明らかな問題は生じていません。NMS システムを使用して、ボストン の回線を毎日監視し、トラフィックピーク時に回線の過剰利用が発生し ていないことを確認します。 フィックスが再起動後も有効であるか ? はい。 フィックスが明確に伝達されているか ? これは、あなた次第です。通常の状況では、この問題をトラッキング するチケットを更新し、フィックスの詳細、監視対象、関連する問題の エスカレーションのタイミングを説明した電子メールを運用担当者に送 信します。 フィックスの運用方法はわかりやすいか ? はい、フィックスはわかりやすいものです。ここでは、サービスプロバ イダから提供されたコミュニティを使用して、ボストンのピアリングポ イントを優先するよう一部のトラフィックを制御しています。 27 28 Day One：Junosの監視およびトラブルシューティング フィックスがある程度の期間内に長期的フィックスで置き換えられるか ? 残念ながら、さまざまな要素に依存します。サービスプロバイダ側で アップグレードに取り組む必要があります。また、ローカルループプ ロバイダ側では、新しい回線を設置しなければならない可能性があり ます。これが許容できる期間内に完成するかはわからないにしても、 障害が発生したシナリオにおいて、トラフィック制御が最も適した短期 的フィックスであったのは事実です。 第3章 CLIの操作 環境コマンド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 シャーシコマンド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Request Support Informationコマンド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 30 Day One：Junosの監視およびトラブルシューティング ネットワークの安定性と常に高いアップタイムを維持するためには、 問題が発生すると同時にトラブルシューティングを行えることが不可欠 です。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 active Alarm time Class Description 2010-01-19 11:47:35 PST Major PEM 3 Not OK シャーシで、PEM（Power Entry Module）3 に関する問題が生じ ているようです。通常、これは電源に関する問題を指し示します。ケー ブルが外れているか、サーキットブレーカに問題があります。問題の 詳細を把握するには、show chassis environment pem コマンドを実行 します。 第3章：CLIの操作 ps@dunkel-re0> show chassis environment pem PEM 0 status: State Online Temperature OK DC Output: OK PEM 1 status: State Online Temperature OK DC Output: OK PEM 2 status: State Online Temperature OK DC Output: OK PEM 3 status: State Present PEM 3 は Present として表示されていることから、問題の原因は電源 入力にあると推測できます。また、ここでは図 1-1 の意思決定ツリー を利用します。例えば、現場の技術者に、ケーブルとサーキットブレー カが正常に機能していることを確認してもらうことから開始します。 show chassis environment コマンドを実行して、デバイスの現在の環 境データをすべて表示します。 ps@dunkel-re0> show chassis environment Class Item Status Temp PEM 0OK PEM 1OK PEM 2OK PEM 3 C heck Routing Engine 0 OK Routing Engine 1OK CB 0OK CB 1OK SIB 0OK SIB 1OK SIB 2OK SIB 3OK FPC 0 IntakeOK FPC 0 ExhaustOK FPC 1 IntakeOK FPC 1 ExhaustOK FPC 2 IntakeOK FPC 2 ExhaustOK FPC 3 IntakeOK FPC 3 ExhaustOK FPC 4 IntakeOK FPC 4 ExhaustOK FPM GBUSOK Measurement 45 43 41 39 41 41 41 44 31 42 31 41 30 41 32 43 31 42 33 degrees degrees degrees degrees degrees degrees degrees degrees degrees degrees degrees degrees degrees degrees degrees degrees degrees degrees degrees C C C C C C C C C C C C C C C C C C C / / / / / / / / / / / / / / / / / / / 113 degrees F 109 degrees F 105 degrees F 102 degrees F 105 degrees F 105 degrees F 105 degrees F 111 degrees F 87 degrees F 107 degrees F 87 degrees F 105 degrees F 86 degrees F 105 degrees F 89 degrees F 109 degrees F 87 degrees F 107 degrees F 91 degrees F 31 32 Day One：Junosの監視およびトラブルシューティング Fans Misc Top Left Front fanOK Top Right Rear fanOK Top Right Front fanOK Top Left Rear fanOK Bottom Left Front fanOK Bottom Right Rear fanOK Bottom Right Front fanOK Bottom Left Rear fanOK Rear Fan 1 (TOP)OK Rear Fan 2OK Rear Fan 3OK Rear Fan 4OK Rear Fan 5OK Rear Fan 6OK Rear Fan 7 (Bottom)OK CIPOK Spinning Spinning Spinning Spinning Spinning Spinning Spinning Spinning Spinning Spinning Spinning Spinning Spinning Spinning Spinning at at at at at at at at at at at at at at at normal normal normal normal normal normal normal normal normal normal normal normal normal normal normal speed speed speed speed speed speed speed speed speed speed speed speed speed speed speed 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 第3章：CLIの操作 DRAM Memory utilization CPU utilization: User Background Kernel Interrupt Idle Model Serial ID Start time Uptime Load averages: 512 MB 36 percent 2 0 4 0 94 percent percent percent percent percent RE-2.0 c40000078cf97701 2010-01-12 05:56:58 EST 7 days, 21 hours, 4 seconds 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 33 34 Day One：Junosの監視およびトラブルシューティング Routing Engine status: Slot 1: Current state Election priority Temperature CPU temperature DRAM Memory utilization CPU utilization: User Background Kernel Interrupt Idle Model Serial ID Start time Uptime 43 47 3584 8 0 0 0 0 100 Backup Backup degrees C / 109 degrees F degrees C / 116 degrees F MB percent percent percent percent percent percent RE-A-2000 1000699981 2010-01-19 11:28:08 PST 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.02 Routing Engine status: Slot 1: Current state Present 第3章：CLIの操作 Present 状態にあるルーティングエンジンは、それがルーターに取り 付けられているものの、正しく機能していないことを示します。他の ルーティングエンジンが通常起動を実行していることが原因である可 能性があります。しかし、この状態が継続する場合、またはルーティ ングエンジンがまったく表示されない場合は、高い確率でトラブル シューティングが必要となります。 可能であれば、デバイスをコンソールポートに接続してみます。コン ソールポートが応答しない場合は、現場の技術者にルーティングエン ジンの取り外しと取り付け直しを依頼し、その作業中にコンソールポー トを監視してください。それでも画面上に出力されない場合、または 出力されるがルーティングエンジンが起動しない場合は、さらに詳細 なトラブルシューティングを行うために JTAC にケースとして申請する か、RMA を依頼してください。 show chassis fpc コマンドおよび show chassis fpc pic-status コマ ンドを実行することで、取り付けてある FPC および PIC の現在の状 態に関する情報が提供されます。 ps@dunkel-re0> show chassis fpc Temp CPU Utilization (%) Slot State (C) Total Interrupt 0 Online 42 2 0 1 Online 40 1 0 2 Online 41 1 0 3 Online 43 1 0 4 Online 42 1 0 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 BASE Slot 1 Online M320 E2-FPC Type 3 PIC 0 Online 4x OC-48 SONET PIC 1 Online 8x 1GE(TYPE3), IQ2 Slot 2 Online M320 E2-FPC Type 2 PIC 0 Online 4x OC-12 SONET, SMIR PIC 1 Online 2x OC-12 ATM-II IQ, MM Slot 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, MM Slot 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 Memory Utilization (%) DRAM (MB) Heap Buffer 1024 2 49 1024 2 49 1024 2 49 1024 2 50 1024 2 49 35 36 Day One：Junosの監視およびトラブルシューティング 通 常 の 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 Slot State (C) Total Interrupt DRAM (MB) 0 Online 42 4 0 1024 1 Online 40 1 0 1024 2 Online 41 1 0 1024 3 Online 43 1 0 1024 4 Offline ---Restarted by cli command--5 Empty 6 Empty 7 Empty ps@dunkel-re0> show chassis fpc Temp CPU Utilization (%) Memory Slot State (C) Total Interrupt DRAM (MB) 0 Online 42 4 0 1024 1 Online 40 1 0 1024 2 Online 41 1 0 1024 3 Online 43 1 0 1024 4 Present 42 5 Empty 6 Empty 7 Empty ps@dunkel-re0> show chassis fpc Temp CPU Utilization (%) Memory Slot State (C) Total Interrupt DRAM (MB) 0 Online 42 4 0 1024 1 Online 40 1 0 1024 2 Online 41 1 0 1024 3 Online 43 1 0 1024 4 Online 40 1 0 1024 5 Empty 6 Empty 7 Empty Utilization (%) Heap Buffer 2 49 2 49 2 49 2 50 Utilization (%) Heap Buffer 2 49 2 49 2 49 2 50 Utilization (%) Heap Buffer 2 49 2 49 2 49 2 50 2 49 の再起動 第3章：CLIの操作 37 PIC を 再 起 動 する に は、 ま ず request chassis pic fpc-slot [slotnumber] 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 verify ps@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 verify ps@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’ 38 Day One：Junosの監視およびトラブルシューティング SFTP を使用して保存したファイルをダウンロードします。 server-1>sftp ps@dunkel Connecting to dunkel... ps@dunkel’s password: sftp> get rsi-dunkel-01202010.log Fetching /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/log sftp> get messages Fetching /var/log/messages to messages /var/log/messages sftp> get chassisd Fetching /var/log/chassisd to chassisd /var/log/chassisd 100% 32KB 31.7KB/s 00:00 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 40 Day One：Junosの監視およびトラブルシューティング 接続性やプロトコルを調べ始める前に、システムが正常に稼働して いることを確認する必要があります。本章では、基本的な Syslog、 SNMP ポーリング、SNMPトラップ、および CLI の操作について説明し、 システムの運用状況を評価できるようにします。また、本章は、後述 の監視およびトラブルシューティングに関する考察の基盤となります。 Syslog システム管理者は、システムログ、変更ログ、およびインタラクティブ コマンドを収集することで、そうした Syslog ファイルを用いてトラブ ルシューティングと監視を行えるようになります。同時に、設定変更に 合わせてネットワークイベントが発生しているかを確認する上でも役 立ちます。Syslog ファイルは、可能な状況で、問題の根本的原因を 適切に警告、通知、および特定するために十分な情報を Syslog サー バーに提供することができます。 ジュニパーネットワークスは、プラットフォームに応じて、ハードディス クドライブまたはコンパクトフラッシュディスクの /var/log ディレクト リ内のファイルにメッセージを書き込むローカルロギングと、Syslog メッセージが遠隔地にある Syslog サーバーに送信されるリモートロ ギングの両方を提供します。 ベストプラクティス ローカルのハードドライブまたはコンパクトフラッシュディスクに書き 込まれるデータ量を制限するために、ローカルシステムロギングを少 なめに設定することを推奨します。ロギングレベルは後から増加でき、 トラブルシューティングが必要となったときに追加でトレーシングを有 効にできます。 リモートシステムロギングの設定は、より自由度が高いものの、収集 する情報の有用性に基づいて判断すべきです。習慣的に繰り返される ログメッセージの量が多くなると、実際の障害に関連する Syslog メッ セージを探し出すのが難しくなり、問題の早期解決が行えないどころ か、障害が長引くことになります。 また、ログ監視を行うのがシステムなのか人間なのかに応じて、収集 対象となる Syslog メッセージを決定します。人間がログの監視を担 当する場合、各メッセージは短く、重要なメッセージのみ記録すべき です。必要な状況下では、技術者に通知して、より詳細な調査を依頼 します。 ネットワーク監視システムで Syslog メッセージをトラッキングする場 合、きめ細かな影響特定と根本的原因の正確な切り分けを行えるよう、 より詳細なメッセージを収集することが役立ちます。 第4章：システムの監視およびトラブルシューティング 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 サーバーで特定のメッセージをフィルタリングできるようにす 41 42 Day One：Junosの監視およびトラブルシューティング るものです。Syslog サーバー管理者は、 このファシリティーを使用して、 ファイルに送られるメッセージをフィルタリングします。以下のルーター は、追加のローカルロギングと、172.19.110.10 にある Syslog サーバー にシステムログを送信するよう設定されています。 ps@dunkel-re0> configure Entering configuration mode [edit] ps@dunkel-re0# set system syslog host [edit] ps@dunkel-re0# set system syslog host [edit] ps@dunkel-re0# set system syslog host [edit] ps@dunkel-re0# set system syslog host [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 172.19.110.10 any notice 172.19.110.10 interactive-commands any 172.19.110.10 change-log any 172.19.110.10 facility-override local3 これにより、Syslog サーバーでは notice レベルのログ、変更ログ、 インタラクティブコマンドを受け取り、それらは local3 のファシリ ティーオーバーライドで送信されます。 第4章：システムの監視およびトラブルシューティング 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 complete Resulting 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 43 44 Day One：Junosの監視およびトラブルシューティング 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.0 SNMPv2-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.0 Timeout:No Response from dunkel. クエリーがタイムアウトしたため、172.19.110.10 からの SNMP クエリー のみをルーターでリッスンしていることがわかります。 第4章：システムの監視およびトラブルシューティング 情報をクエリーできる 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.5 SNMPv2-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 @ 45 46 Day One：Junosの監視およびトラブルシューティング 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 オクテットを太字表示してある）。 第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.0 SNMPv2-SMI::enterprises.2636.3.1.13.1.8.9.1.0.0 = Gauge32:3 nms-1> snmpwalk -v2c -c tr4pp15t dunkel .1.3.6.1.4.1.2636.3.1.13.1.8.9.2.0.0 SNMPv2-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.02 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 47 48 Day One：Junosの監視およびトラブルシューティング DRAM Memory utilization CPU utilization: User Background Kernel Interrupt Idle Model Serial ID Start time Uptime 3584 MB 8 percent 0 0 0 0 100 percent percent percent percent percent RE-A-2000 1000699981 2010-01-19 11:28:08 PST 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.x Warning level:70% 例： nms1> snmpwalk -v2c -c tr4pp15t dunkel .1.3.6.1.4.1.2636.3.1.13.1.11.9.1.0.0 SNMPv2-SMI::enterprises.2636.3.1.13.1.11.9.1.0.0 = Gauge32:9 nms-1> snmpwalk -v2c -c tr4pp15t dunkel .1.3.6.1.4.1.2636.3.1.13.1.11.9.2.0.0 SNMPv2-SMI::enterprises.2636.3.1.13.1.11.9.2.0.0 = Gauge32:8 ルーティングエンジン 0 はメモリ利用率 9% で稼働し、ルーティング エンジン 1 はメモリ利用率 8% で稼働していることが示されています。 ここでも裏付けのために、ルーターに対して show chassis routingengine コマンドを実行します。 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 第4章：システムの監視およびトラブルシューティング Memory utilization CPU utilization: User Background Kernel Interrupt Idle Model Serial ID Start time Uptime Load averages: 9 percent 0 0 3 0 97 Routing Engine status: Slot 1: Current state Election priority Temperature CPU temperature DRAM Memory utilization CPU utilization: User Background Kernel Interrupt Idle Model Serial ID Start time Uptime 43 47 3584 8 0 0 0 0 100 percent percent percent percent percent RE-A-2000 1000702757 2010-01-19 11:42:50 PST 21 hours, 50 minutes, 15 seconds 1 minute 5 minute 15 minute 0.00 0.03 0.02 Backup Backup degrees C / 109 degrees F degrees C / 116 degrees F MB percent percent percent percent percent percent RE-A-2000 1000699981 2010-01-19 11:28:08 PST 22 hours, 4 minutes, 52 seconds 裏付けテストにより、メモリ利用率の値が正しいことが実証されました。 ルーティングエンジン温度 情報をクエリーできる次の SNMP オブジェクトは、ルーティングエン ジンの温度です。ジュニパーネットワークスのルーターは、高温時を 示すハイレベルの赤いアラームが宣言されたときには自動的に電源を 切って機器自体を保護しますが、悪影響を及ぼす前に問題を特定で きるよう、ルーターのポーリングを行うことも重要です。しきい値は、 プラットフォームやコンポーネントごとに異なります。show chassis temperature-thresholds コマンドを実行することで、各コンポーネント のしきい値を表示できます。 49 50 Day One：Junosの監視およびトラブルシューティング 以下に show chassis temperature-thresholds コマンドの出力サンプ ルを示します。 いくつかの FPC および FEB（Forwarding Engine Board）を備えるデュアルルーティングエンジンのシャーシが示されて います。 ps@dunkel-re0> show chassis temperature-thresholds Fan speed Yellow alarm Item Normal High Normal Bad fan Chassis default 48 54 65 55 Routing Engine 0 70 80 95 95 Routing Engine 1 70 80 95 95 FPC 0 55 60 75 65 FPC 1 55 60 75 65 FPC 2 48 54 70 60 FPC 3 48 54 70 60 FPC 4 48 54 70 60 FPC 5 48 54 70 60 FEB 0 48 54 70 60 FEB 1 48 54 70 60 FEB 2 48 54 70 60 FEB 3 48 54 70 60 FEB 4 48 54 70 60 FEB 5 48 54 70 60 Red alarm Normal Bad fan 75 65 110 110 110 110 90 80 90 80 80 70 80 70 80 70 80 70 80 72 80 72 80 72 80 72 80 72 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.0 SNMPv2-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.0 SNMPv2-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: 値が正し 第4章：システムの監視およびトラブルシューティング User Background Kernel Interrupt Idle Model Serial ID Start time Uptime Load averages: Routing Engine status: Slot 1: Current state Election priority Temperature CPU temperature DRAM Memory utilization CPU utilization: User Background Kernel Interrupt Idle Model Serial ID Start time Uptime 0 0 2 0 97 43 47 3584 8 0 0 0 0 100 percent percent percent percent percent RE-A-2000 1000702757 2010-01-19 11:42:50 PST 22 hours, 2 minutes, 35 seconds 1 minute 5 minute 15 minute 0.00 0.00 0.00 Backup Backup degrees C / 109 degrees F degrees C / 116 degrees F MB percent percent percent percent percent percent RE-A-2000 1000699981 2010-01-19 11:28:08 PST 22 hours, 17 minutes, 14 seconds ここに示した SNMP クエリーから返された温度値は、CLI 出力に一致 しています。 SNMPトラップ SNMP を使用することで、ポーリングだけでなく、特定の状況下で能 動的にトラップを送信することができます。ネットワークデバイスから 監視システムに対して積極的に問題やイベントが発生していることを伝 達できるため、どのような NMS システムにとっても極めて重要な機能 です。正しく設定した SNMP トラップと Syslog メッセージを組み合わ せることで、NMS システムでネットワークを効率的に監視するために 必要なものがすべて揃います。 SNMP トラップ設定は、前のステップで実装した SNMP ポーリング設 定と似ています。唯一の違いは、SNMP コミュニティを追加で設定し、 SNMP サーバーを追加しなければならない点です。まず、コミュニティ として tr4pp15t を設定した、172.19.110.10 への SNMP トラップを設 定します。ポーリング用に設定したコミュニティをトラップ用に使用す ることもできます。 51 52 Day One：Junosの監視およびトラブルシューティング さらに、受信するトラップのタイプも指定します。これらの追加設定を 伴う 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# [edit] ps@dunkel-re0# [edit] ps@dunkel-re0# [edit] ps@dunkel-re0# [edit] ps@dunkel-re0# [edit] ps@dunkel-re0# [edit] ps@dunkel-re0# set snmp trap-group tr4pp15t categories authentication set snmp trap-group tr4pp15t categories chassis set snmp trap-group tr4pp15t categories configuration set snmp trap-group tr4pp15t categories link set snmp trap-group tr4pp15t categories routing set snmp trap-group tr4pp15t categories sonet-alarms set snmp trap-group tr4pp15t categories startup show snmp コマンドを実行して（設定モードで） 、加えた変更を含む SNMP 設定を表示します。 第4章：システムの監視およびトラブルシューティング [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; + } + } 53 54 Day One：Junosの監視およびトラブルシューティング 設定をコミットします。 [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 56 Day One：Junosの監視およびトラブルシューティング ネットワークの監視およびトラブルシューティングにおいては、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の監視およびトラブルシューティング 以 下 に 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 57 58 Day One：Junosの監視およびトラブルシューティング 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, S1 :0x00, C2 :0xcf, C2(cmp) :0xcf, Z3 :0x00, Z4 :0x00, S1(cmp) :0x00 Transmitted SONET overhead: F1 :0x00, J0 :0x01, K1 :0x00, S1 :0x00, C2 :0xcf, F2 :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 32 2f 32 2f 30 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 00 00 00 00 00 00 00 0d K2 F2 :0x00 :0x00 K2 Z3 :0x00 :0x00 2d 00 00 00 pilsener-re0 so2/2/0........... ................ ................ 第5章：レイヤー1およびレイヤー2の監視およびトラブルシューティング Transmitted path trace: dunkel-re0 so-2/0/0 64 75 6e 6b 65 6c 2d 72 65 30 20 73 6f 2d 32 30 2f 30 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 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 % bps 0 best-effort 95 590976000 3 network-control 5 31104000 2f 00 00 00 % 95 5 dunkel-re0 so-2/ 0/0............. ................ ................ Buffer Priority usec 0 low 0 low Limit none 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 が標準として捉えられています。 59 60 Day One：Junosの監視およびトラブルシューティング プロトコルの実際の仕組みは非常に複雑であり、本書が目的とする範囲 を超えます。ここで把握すべきことは、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（ジャイアント）と 表示されるエラーが記録されます。ペイロードスクランブリングが設 定されていない側では、フレーミングエラーが表示されます。 第5章：レイヤー1およびレイヤー2の監視およびトラブルシューティング ベストプラクティス 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 があります。 61 62 Day One：Junosの監視およびトラブルシューティング パスレ イヤ ーで は、 ル ーター などの パス 終 端 装 置（PTE：Path Terminating Element）によって SONET/SDH 以外のネットワーク と SONET/SDH ネットワークが接続されます。この階層により、特定 レイヤーでの問題を素早く切り分けできるようになります。 ルーター1 リピーター1 セクション リピーター2 セクション ライン セクション ライン ルーター2 セクション ライン パス 図 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、など）がないことを確認します。 第5章：レイヤー1およびレイヤー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）が表示されます。 63 64 Day One：Junosの監視およびトラブルシューティング ビット誤り率 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 がタ イミングデバイスに同期できない場合に発生するもので、ハードウェ 第5章：レイヤー1およびレイヤー2の監視およびトラブルシューティング アまたはネットワークのタイミングに関する問題の可能性を示していま す。問題の原因は、ルーター上のシステムボードのタイプに応じて異 なります。例： 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 65 66 Day One：Junosの監視およびトラブルシューティング 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 がオープンな状態でなければ、そのタイプの パケットを送信することはできません。 第5章：レイヤー1およびレイヤー2の監視およびトラブルシューティング 注 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 67 68 Day One：Junosの監視およびトラブルシューティング 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 の設定 オプションを示します。 第5章：レイヤー1およびレイヤー2の監視およびトラブルシューティング [edit] ps@dunkel-re0# set protocols Possible completions: access Trace address-pool Trace all Trace auth Trace chap Trace ci Trace config Trace ifdb Trace lcp Trace memory Trace message Trace mlppp Trace ncp Trace pap Trace ppp Trace radius Trace redundancy Trace rtsock Trace session Trace signal Trace timer Trace ui Trace ppp traceoptions flag ? access code address pool code all areas of code authentication code CHAP code ci code configuration code interface database code LCP state machine code memory management code message processing code MLPPP code NCP state machine code PAP code PPP protocol processing code RADIUS processing code redundancy code routing socket code session management code signal handling code timer code 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 69 70 Day One：Junosの監視およびトラブルシューティング このコマンドは、UNIX 環境での tail コマンドに相当し、ユーザーが ファイルへの追加を監視できるようにするものです。しばらくすると、 画面上に以下が表示されます。 ps@dunkel-re0> *** ppp-log.txt Apr 12 16:12:20 Apr 12 16:12:20 Apr 12 16:12:20 *** so-1/2/3.0:CHAP - Stopping protocol timer so-1/2/3.0:CHAP - Starting authentication 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 so-1/2/3.0 PPP Authenticate Session flags 第5章：レイヤー1およびレイヤー2の監視およびトラブルシューティング 運用時の設定では、show ppp interface extensive コマンドの実行に よる出力で、LCP および IPCP（および設定したその他のレイヤー 3 プロトコル）は「Opened」状態にあり、show ppp summary にはセッショ ンフェーズとして「Network」が示されているべきです。 両側でパスワードをリセットすると、以下のログが表示されます（こ の時点でも監視を継続しているはずです） 。 Apr Apr Apr Apr 12 12 12 12 16:13:26 16:13:26 16:13:26 16:13:26 so-1/2/3.0:CHAP so-1/2/3.0:CHAP so-1/2/3.0:CHAP so-1/2/3.0:CHAP - Starting protocol timer (2 sec, 0 nsec) Stopping protocol timer Starting authentication 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 so-1/2/3.0 PPP Network Session flags 71 72 Day One：Junosの監視およびトラブルシューティング ベストプラクティス この 時 点 で、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 succeeds re1: commit complete re0: commit complete Exiting configuration mode monitor stop コマンドを実行することで、ppp-log.txt ファイルの監 視を停止できます。監視対象は自身のターミナルに限定され、ログア ウトしたときに自動的に停止することに注意してください。 ps@dunkel-re0> monitor stop まとめ 本章では、SONET および PPP を使用して、レイヤー 1 および 2 の アラームやエラーの監視方法とトラブルシューティング方法についてま とめました。SONET を使用した理由は、ジュニパーネットワークスの デバイスで最も多く採用される、最も複雑なレイヤー 1 技術であるた めです。また、PPP を使用した理由は、広く採用されており相互運用 性に優れているからです。しかし、この同じアプローチを、イーサネッ トを含む他のレイヤー 1 またはレイヤー 2 技術にも適用できます。 SONET、イーサネット、およびその他のレイヤー 1 またはレイヤー 2 技術で使用できる、このアプローチは以下のとおりです。 第5章：レイヤー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’ 73 74 Day One：Junosの監視およびトラブルシューティング ベストプラクティス FCS、ペイロードスクランブリング（SONET および SDH の両方）、 速度、 フロー制御、二重モード（すべてのイーサネット）などのレイヤー 1 設定と、認証などのレイヤー 3 設定が一致していることを確認してく ださい。また、ネットワークにおける各デバイスの役割についても理 解してください（イーサネットネットワークよりも SONET ネットワー クで重要となる）。 第6章 レイヤー3の監視 RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98 76 Day One：Junosの監視およびトラブルシューティング 本書では、これまでにレイヤー 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の監視 RIP オペレーションモードコマンド RIP の動作を監視するには、まずデバイスで提供される標準的な操 作や機能から確認します。 show rip neighbor コマンドを実行すると、RIP 用に設定したインタ フェースが表示されます。コマンド名が紛らわしいため注意が必要で すが、このコマンドを実行しても RIP 隣接機器に関する情報は表示さ れません（前述のように、存在しない）。 ps@dunkel-re0> show rip neighbor Source Neighbor State Address ------------ ------so-2/0/0.0 Up 18.32.74.1 Destination Address ----------224.0.0.9 Send Mode ---mcast Receive Mode ------both In Met --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 0 0 0 resps dropped 0 so-2/0/0.0:1 routes learned; 0 routes advertised; timeout 180s; update interval 30s Counter Total Last 5 min Last minute ----------------- ----------- ----------Updates Sent 0 0 0 Triggered Updates Sent 0 0 0 Responses Sent 0 0 0 Bad Messages 0 0 0 RIPv1 Updates Received 0 0 0 RIPv1 Bad Route Entries 0 0 0 RIPv1 Updates Ignored 0 0 0 RIPv2 Updates Received 7 7 3 RIPv2 Bad Route Entries 0 0 0 RIPv2 Updates Ignored 0 0 0 Authentication Failures 0 0 0 RIP Requests Received 0 0 0 RIP Requests Ignored 0 0 0 77 78 Day One：Junosの監視およびトラブルシューティング このように、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 224.0.0.9/32 *[RIP/100] 00:00:02, metric 2, tag 0 > to 18.32.74.2 via so-2/0/0.0 *[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 ダウンイベントによってネットワーク内で再収束がトリガー される可能性があり（可能性が高い）、準最適ルートまたは他のリン クの過剰利用にもつながります。どのような状況でも、特定の隣接関 係の障害を解決するため、また予期せぬ事態の発生時にそれを緩和 第6章：レイヤー3の監視 するためにも、トポロジーが変更されたことを把握することが重要で す。隣接関係変更に対して記録される基本的な 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; } } 79 80 Day One：Junosの監視およびトラブルシューティング このイベントオプション設定によって、ログファイルに rpd_isis_adjdown または rpd_isis_adjup のどちらかが出現したときに、ルーターから SNMPトラップが送信されます。以下の例で、同じ隣接関係の変化が 発生した場合に、結果として送信される SNMPトラップを比較できます。 IS-IS 隣接関係の確立： dunkel-re0.juniper.net [UDP:[172.19.110.171]:62313]:Trap , DISMAN-EVENTMIB::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-EVENTMIB::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.9 Soft failure on the remote side: dunkel-fxp0.pslab.juniper.net [UDP:[172.19.110.171]:62313]:Trap , DISMAN-EVENTMIB::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 第6章：レイヤー3の監視 レベルの不一致： dunkel-fxp0.pslab.juniper.net [UDP:[172.19.110.171]:62313]:Trap , DISMAN-EVENTMIB::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 so-2/0/0.0 pilsener-re0 L State 2 New ps@dunkel-re0> show isis adjacency Interface System so-2/0/0.0 pilsener-re0 L State Hold (secs) SNPA 2 Initializing 26 ps@dunkel-re0> show isis adjacency Interface System so-2/0/0.0 pilsener-re0 L State 2 Up Hold (secs) SNPA 23 Hold (secs) SNPA 26 隣接関係が形成されない理由はたくさんありますが、以下に主なもの を挙げます。 ファミリー ISO に対してインタフェースが設定されていない NSAP アドレスの欠如または重複（Junos では、NSAP アドレ スは lo0.0 インタフェース上のファミリー ISO アドレスとして設 定される） 81 82 Day One：Junosの監視およびトラブルシューティング レベルの不一致 エリアの不一致 認証タイプまたはキーの障害 いずれの状況でも、リンクの両側の設定が一致することを確認してくだ さい。 隣接関係が形成されたことで、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 inet.0:8 destinations, 9 routes (8 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 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 へのループバックアドレスへのルートが選択されました。 第6章：レイヤー3の監視 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 routingoptions] 階層レベルで設定できますが、デフォルトは 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 動作に関する統計情報が表示 されます。 83 84 Day One：Junosの監視およびトラブルシューティング ps@dunkel-re0> show isis statistics IS-IS statistics for dunkel-re0: PDU type Received Processed LSP 2 2 IIH 7 7 CSNP 45 45 PSNP 12 12 Unknown0 0 0 Totals 66 66 Drops 0 0 0 0 0 0 Sent 13 7 90 1 0 111 Rexmit 0 0 0 0 0 Total packets received:66 Sent:104 SNP queue length:0 Drops:0 LSP queue length:0 Drops:0 SPF runs:8 Fragments rebuilt:13 LSP regenerations:0 Purges 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 Reason Fri Jan 29 11:36:31 0.000015 2 Reconfig Fri Jan 29 11:36:41 0.000032 3 New adjacency pilsener-re0 on so-2/0/0.0 この出力には、SPF は 3 回実行され、最も近い（最後の）実行は新 しい隣接関係によるものであることが示されています。SPF は常に実 行されていないため、IS-IS ネットワークは安定しているようです。 第6章：レイヤー3の監視 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 (so2/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 (so2/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-EVENTMIB::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, 85 86 Day One：Junosの監視およびトラブルシューティング SNMPv2-SMI::mib-2.14.10.1.1.18.32.74.2.0 SNMPv2-SMI::mib-2.14.10.1.2.18.32.74.2.0 SNMPv2-SMI::mib-2.14.10.1.3.18.32.74.2.0 SNMPv2-SMI::mib-2.14.10.1.6.18.32.74.2.0 SNMPv2-MIB::snmpTrapEnterprise.0 = OID: SNMPv2-SMI::enterprises.2636.1.1.1.2.9 = = = = IpAddress:18.32.74.2, INTEGER:0, IpAddress:10.200.7.2, INTEGER:8, 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-EVENTMIB::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 第6章：レイヤー3の監視 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.6 SNMPv2-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 18.32.74.2 so-2/0/0.0 State Full ID 10.200.7.2 Pri 128 Dead 39 イーサネット LAN などのマルチアクセスネットワークでは、ルーター で DR（Designated Router） お よ び BDR（Backup Designated Router）を選出する必要があるため、より長い時間がかかります。以 下に示すように、隣接関係は Init 状態から開始して、DR と BDR が 選出される 2Way 状態に進みます。そのステップが完了すると、ルー ターではデータベース同期に進み、最後に Full 同期を達成します。 以下の出力に、この進行状況が示されています。 ps@dunkel-re0> show ospf neighbor Address Interface 172.19.110.187 fe-0/0/0.0 State Init ID 10.200.7.2 Pri 128 Dead 34 87 88 Day One：Junosの監視およびトラブルシューティング ps@dunkel-re0> show ospf neighbor Address Interface 172.19.110.187 fe-0/0/0.0 State 2Way ID 10.200.7.2 Pri 128 Dead 37 ps@dunkel-re0> show ospf neighbor Address Interface 172.19.110.187 fe-0/0/0.0 State Full ID 10.200.7.2 Pri 128 Dead 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 データベースにのみ情報が格納されています。 第6章：レイヤー3の監視 ps@dunkel-re0> show ospf database detail OSPF link state database, Area 0.0.0.0 Type ID Adv Rtr Seq Age Router *10.200.7.1 10.200.7.1 0x80000006 290 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 1 Router 10.200.7.2 10.200.7.2 0x80000005 303 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 Opt Cksum Len 0x22 0x307a 60 0x22 0x3078 60 ここでは、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 18.32.74.0/30 224.0.0.5/32 *[OSPF/10] 00:10:15, metric 1 > via so-2/0/0.0 [OSPF/10] 00:10:20, metric 1 > via so-2/0/0.0 *[OSPF/10] 00:10:47, metric 1 MultiRecv また、18.32.74.0/30 への OSPF ルートもあることがわかります。こ れは Dunkel を Pilsener に接続しているネットワークです。このルー トが設定されていない理由は、Dunkel がこのネットワークに直接接 続されている（つまりより適した）ルートであるためです。そのルー トを表示してみます。 89 90 Day One：Junosの監視およびトラブルシューティング ps@dunkel-re0> show route 18.32.74.0/30 inet.0:14 destinations, 17 routes (14 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 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 に近い値に維持されるべ きです。 第6章：レイヤー3の監視 ps@dunkel-re0> show ospf statistics Packet type Hello DbD LSReq LSUpdate LSAck DBDs LSAs LSAs LSAs LSAs LSAs LSAs Total Sent 7 3 0 4 2 retransmitted flooded flooded high-prio retransmitted transmitted to nbr requested acknowledged Flood queue depth Total rexmit entries db summaries lsreq entries Received 5 2 0 3 3 : : : : : : : : : : : Last 5 seconds Sent Received 0 0 0 0 0 0 0 0 0 0 0, 2, 0, 2, 0, 0, 2, last last last last last last last 5 5 5 5 5 5 5 seconds seconds seconds seconds seconds seconds seconds : : : : : : : 0 0 0 0 0 0 0 0 0 0 0 Receive errors: None BGP BGP は、ディスタンスベクトル型プロトコルのような挙動をとりますが、 ピアとの隣接関係も形成します。BGP の状態および動作を監視する ために、さまざまな Syslog ロギング、SNMP ポーリングおよびトラッ プ、各種機能および操作オプションが提供されます。 まず、BGP に関連するいくつかの Syslog メッセージについて説明し ます。 ログ記録 BGP Syslog メッセージは、主に BGP セッションの状態に関連する ものです。ジュニパーネットワークスのルーターでは、set protocols bgp log-updown コマンドを実行して、セッション状態の変化をログに 記録するように BGP を設定しなければなりません。このコマンドは、 BGP グループまたは隣接機器レベルでも使用できますが、最も役立 つのはプロトコルレベルでの使用です。 ここでは、Dunkel と Pilsener の間でピアリングを確立するシンプル な内部 BGP セッションを示します。セッショングループの確立とダウ ンによる、結果の Syslog メッセージも併せて示されます。 91 92 Day One：Junosの監視およびトラブルシューティング 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 0 Jan 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 第6章：レイヤー3の監視 4 - opensent 5 - openconfirm 6 - established 以下に、10.200.7.2 の BGP ピアに焦点を当て、隣接機器の状態変 化に基づいた、いくつかの BGP トラップ例を示します。 隣接機器の確立： cartman-fxp0.pslab.juniper.net [UDP:[172.19.110.171]:62313]:Trap , DISMANEVENT-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-EVENTMIB::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.2 SNMPv2-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 93 94 Day One：Junosの監視およびトラブルシューティング .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.[loc al 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.14 SNMPv2-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、jnxBgpM2PrefixInPrefi xesAccepted、および 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.0 SNMPv2-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.0 SNMPv2-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.0 SNMPv2-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:0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 7 1 0 0 0 0 Peer 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 第6章：レイヤー3の監視 BGP オペレーションモードコマンド 大半の BGP オペレーションモードコマンドは、隣接機器に関する情 報や、それらピアから受信、許可、および拒否されたプレフィックス 数を表示します。最も頻繁に使用するのは、show bgp summary コマ ンドです。以下に示すように、すべての BGP 隣接機器、それらの状態、 ピアから受け取ったプレフィックスに関する情報を示します。 ps@dunkel-re0> show bgp summary Groups:1 Peers:1 Down peers:0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 4 1 0 0 0 0 Peer 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/0 10.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 95 96 Day One：Junosの監視およびトラブルシューティング 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 Input messages: Total 287 Updates 11 Output messages:Total 278 Updates 0 Output Queue[0]:0 Checked 59 Refreshes 0 Refreshes 0 Octets 5730 Octets 5308 この出力は、明らかに多くの情報を含んでいます。設定に関する情 報や、状態に関する情報も含まれています。最初の数行は、セッ ションの現在および最近の状態を反映したものです。現在の状態は 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 inet.0:16 destinations, 22 routes (16 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 第6章：レイヤー3の監視 10.200.7.2/32 18.32.74.0/30 112.74.9.0/30 172.19.110.0/23 181.21.0.0/22 192.168.0.0/16 199.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 [BGP/170] 01:44:10, localpref 100, from 10.200.7.2 AS path:I > via so-2/0/0.0 *[BGP/170] 02:04:22, localpref 100, from 10.200.7.2 AS path:I > via so-2/0/0.0 [BGP/170] 02:04:22, localpref 100, from 10.200.7.2 AS path:I > via so-2/0/0.0 [BGP/170] 02:04:22, localpref 100, from 10.200.7.2 AS path:I > via so-2/0/0.0 [BGP/170] 02:04:22, localpref 100, from 10.200.7.2 AS path:I > via so-2/0/0.0 [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 つのルートが示されることが想定さ れます。 97 98 Day One：Junosの監視およびトラブルシューティング 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 100 Day One：Junosの監視およびトラブルシューティング 本章では、レイヤー 3 のトラブルシューティングについて説明します。 IP ネットワークをトラブルシューティングするための手順と指針を構築 するために、第 1 章で示したガイドラインに戻り、繰り返し適用できる プロセスを確立します。 遭遇する可能性があるすべての IP 問題について説明することはほぼ 不可能であるため、本章では、ネットワーク問題の素早い切り分けと 解決を達成できるような、効果的なアプローチの仕方について説明し ます。 障害のタイプ まず、IP 障害をタイプ別に分類します。 パケットロス：パケットロスとは、パケットが宛先まで届かない現 象で、さまざまな原因によって起こります。最も一般的な原因とし ては、回線のダウン、 （正確な）ルーティング情報の欠如、ルーティ ングループ、回線の過剰利用（Class-of-Service を伴うまたは伴 わない場合）が挙げられます。多くの場合、セキュリティデバイス も（意図的な）パケットドロップを引き起こす原因となりますが、 ファ イアウォールは本書が目的とする範囲外のため言及しません。 遅延：遅延とは、パケットが宛先に届くまでの時間が遅れる現 象で、準最適ルーティングまたは Class-of-Service キューイン グが原因で起こります。これに関連するジッター も遅延の一種で、 IP ネットワーク上で音声や映像をやり取りする環境では大きな 問題となります。ジッターの主な原因は、Class-of-Service（ま たはその欠如）です。 注 IP ネットワークをトラブルシューティングする上で最も重要なのは、使 用するプロトコルと、どのようにそれらが相互に作用するのかをしっ かりと理解することです。スペースの制約上、RIP、IS-IS、OSPF、 BGP について詳細に解説することができないため、本章ではネット ワーク上で稼働するプロトコルと、それらがどのように相互に作用す るかについて十分に理解していることを前提としています。 パケットロスのトラブルシューティング パケットロスは、ほぼ常に以下のいずれかの原因によって生じるため、 ネットワーク問題の中でも比較的容易に対処できるものの 1 つです。 回線およびハードウェアの障害（全停止障害） ルーティングループ（全停止障害） 回線の過剰利用（一部停止障害） ルート変動（一部停止障害） 第7章：レイヤー3のトラブルシューティング これらのタイプの障害をトラブルシューティングするために、関与して いるルーター（1 つまたは複数）の特定、根本的原因の特定、さらに 可能な場合には問題の解決をそれぞれ素早く行うためのステップに ついて順に説明していきます。 回線の障害 障害の中でも、全停止障害は、容易に解決できることが多々あります。 全停止障害をトラブルシューティングする上で最も重要なのは切り分 けです。それは、解決には設定の変更、ハードウェアの再起動また は交換、あるいは回線提供通信事業者への連絡が必要となる可能性 があるためです。 このタイプの障害をトラブルシューティングする際に最も役立つツール は、traceroute です。traceroute は、TTL（Time-To-Live）値を 1 から 1 ずつ増分しながら宛先に一連のパケットを送信します。ルーター では、IP パケットを受信したときに TTL の値を 1 だけ小さくすること が求められています。TTL 値が 0 になると、ルーターは ICMP timeexceeded メッセージを送信しなければなりません。この ICMP メッ セージは、送信ルーターにその特定のホップの IP アドレスを知らせる ものです。 このプロセスはパス内の各ホップで繰り返されるため、送信ルーター はパス内の各ホップの IP アドレスを得ることができます。この情報は、 障害の根本的原因を特定しようとするオペレータにとって非常に有用 です。 注 traceroute の最後の応答ホップが問題の原因であるとの認識は、よ くある誤解です。応答するということは、ホストではそのルーターに 対して到達可能性があり、そのルーターもまたホストに対して到達可 能性があることを意味します。 一般に、問題があると疑うべき箇所は、応答した最後のホップと応答 しなかった最初のホップの間、または応答しなかった最初のホップ上 です。この単一コマンドを使用する上で重要なことは、作業を集中的 に行う場所を即座に発見できるということです。 図 7-1 に示すネットワークを例にとります。 図 7-1 シンプルなネットワークトポロジー 101 102 Day One：Junosの監視およびトラブルシューティング このネットワークは、サイト内に配置した 2 つのルーターで構成され ています。一方の Dunkel（伝統的なビールから命名）は、 コーポレー ト LAN のアグリゲーションを行うルーターで、 もう一方の Pilsener（人 気の高いビールから命名）はサービスプロバイダに接続するルーター です。Pilsener には、サービスプロバイダがネクストホップであるデ フォルトのスタティックルートがあり、このルートをサイト内の IGP で ある OSPF に配布しています。これにより、Dunkel では、Pilsener がネクストホップであるデフォルトルートを得ます。LAN 上のサーバー およびホストには、Dunkel がネクストホップであるデフォルトのスタ ティックルートがあります。 まず、すべてのシステムが想定どおりに機能しているケースで、イン ターネット上のある宛先に traceroute を実行した例を見てみます。 server% traceroute 4.2.2.1 traceroute to 4.2.2.1 (4.2.2.1), 30 hops max, 40 byte packets 1 18.32.75.1 (18.32.75.1) 2.617 ms 1.690 ms 2.851 ms ß Dunkel 2 18.32.74.6 (18.32.74.6) 3.386 ms 3.370 ms 5.570 ms ß Pilsener 3 4.10.33.2 (4.10.33.2) 13.513 ms 3.905 ms 5.060 ms ß Service provider hop 1 4 4.1.18.21 (4.1.18.21) 3.778 ms 5.237 ms 5.413 ms ß Service provider hop 2 5 4.2.2.1 (4.2.2.1) 10.876 ms 12.568 ms 5.991 ms ß Destination 図 7-2 に示すように、このネットワークの最も一般的な障害点は、サー ビスプロバイダへのリンクです。次に、この障害をシミュレーションし て、もう一度 traceroute を実行してみます。 図 7-2 サービスプロバイダリンク障害 図 7-2 に示すシナリオで traceroute を実行すると、以下のとおりと なります。 ps@dunkel> show route 4.2.2.1 ps@dunkel> Pilsener からサービスプロバイダへのデフォルトスタティックルートは、 リンクがダウンすると消え、このルートは OSPF には配布されなくなり、 結果的に Dunkel では 4.2.2.1 へのルートがなくなります。Dunkel は、 destination host unreachable エラーメッセージで応答します。 これは、 実行した traceroute の最終行の文字 !H で示されています。 server% traceroute 4.2.2.1 traceroute to 4.2.2.1 (4.2.2.1), 30 hops max, 40 byte packets 1 18.32.75.1 (18.32.75.1) 1.983 ms 2.440 ms 2.414 ms 2 18.32.75.1 (18.32.75.1) 2.883 ms !H 4.136 ms !H 3.799 ms !H 第7章：レイヤー3のトラブルシューティング Dunkel は 18.32.75.1 であるため、ここを調査の開始箇所とすべき です。このケースでは、Dunkel でのルーター操作と、その後で行う Pilsener でのルーター操作によって、サービスプロバイダへのリンク がダウンしたことが判明します（おそらく、Syslogまたは SNMP によっ て通知済み）。この時点で、接続のローカル側のハードウェアを取り 付け直し、再設定、および / または交換して、正常に動作することを 確認します。問題が引き続き発生する場合は、サービスプロバイダに 連絡してサポートを要請してください。 ポイントツーポイントではないイーサネット接続など、接続のリモー ト側の障害が発生しても回線がダウンしない状況もあります。ここで、 図 7-3 に示すように、サービスプロバイダへの接続を、サービスプ ロバイダにてレイヤー 2 スイッチを経由してからルーターに接続する イーサネットリンクに変更します。図 7-4 には、サービスプロバイダ ルーターの障害を示します（または、サービスプロバイダスイッチか らサービスプロバイダルーターへの接続の障害）。 図 7-3 および 7-4 サービスプロバイダへのイーサネットリンクとその障害 以下に、このタイプの障害が発生している状況で traceroute を実行 した場合の出力を示します。 server % traceroute 4.2.2.1 traceroute to 4.2.2.1 (4.2.2.1), 30 hops max, 40 byte packets 1 18.32.75.1 (18.32.75.1) 2.891 ms 0.594 ms 1.595 ms 2 18.32.74.6 (18.32.74.6) 2.425 ms 2.544 ms 2.642 ms 3 * * * trace は Pilsener まで到達しました。それは、サービスプロバイダ へのイーサネット接続の終端装置が（リンクアップしていない）ルー ターではなく、（リンクアップしている）スイッチであるため、接続自 体は確立された状態を維持します。これは、Pilsener のデフォルト スタティックルートは有効状態を維持し、引き続きデフォルトルートを OSPF に配布することを意味します。 103 104 Day One：Junosの監視およびトラブルシューティング ps@pilsener> show route 4.2.2.1 inet.0:11 destinations, 12 routes (11 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[Static/5] 00:00:33 > to 192.168.14.10 via fe-0/0/1.0 Pilsener とネクストホップ（サービスプロバイダ）の間で traceroute がばらついていることから、調査の開始箇所として適しているのは Pilsener です。次のステップとしては、Pilsener にログインし、上記 の show route コマンドを実行して、接続のリモート側（192.168.14.10） に ping を試行します。それに失敗した場合は、サービスプロバイダ に連絡してください。 この障害はリンクダウンイベントがないため、NMS システムで検知す る方が難しい可能性があります。このタイプの障害を監視システムで 唯一検知できるのは、性能管理および接続性の保証を行うために何 らかのプローブ機能を併用している場合です。多くの NMS システム では、Nagios および WhatsUp Gold のように、こうした目的のた めに複数の異なる宛先への ping を監視する機能を備えています。 ps@router-3> ping 192.168.14.10 PING 192.168.14.10 (192.168.14.10):56 data bytes ^C --- 192.168.14.10 ping statistics --5 packets transmitted, 0 packets received, 100% packet loss ルーティングループのトラブルシューティング 全停止障害は、ルーティングループが原因で発生することがあります。 ルーティングループは、2 台のルーター（直接接続されたルーター同 士が多い）が、特定の宛先に対するネクストホップとして互いを選択 した場合に発生します。これは、スタティックルート環境で多く見られ ます。ルーティングループは、ルート変動が生じている場合にも発生 しますが、そうした状況ではループは必ずしも持続的に発生はしませ ん。ルート変動については、本章で後述します。 図 7-5 に示すトポロジーへの追加を例にとります。企業環境が拡張さ れたため、LAN アグリゲーションルーター Altbier の追加が必要にな りました。 Altbier は、Dunkel とほぼ同じように設定されています。Pilsener を 経由するデフォルトルートを OSPF から受け取っています。Pilsener は、Altbier をネクストホップとする 18.32.76.0/23 ネットワークへの スタティックルートを持ちます。 第7章：レイヤー3のトラブルシューティング 図 7-5 2 台目の LAN アグリゲーションルーターの追加 Altbier は、Pilsener をネクストホップとするデフォルトスタティック ルートを持ちます。Dunkel に接続されたホストから traceroute を 実行すると、以下が出力されました。 server% traceroute 18.32.76.7 traceroute 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.7 traceroute 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 ß altbier 10 18.32.74.61 (18.32.74.61) 3.315 ms 10.498 ms 4.453 ms ß pilsener 105 106 Day One：Junosの監視およびトラブルシューティング この traceroute で示されるように、Pilsener と Altbier の間のトラ フィックはループしています。問題を疑うべき箇所は明確です。ルーティ ングループで問題が発生している箇所は、ほぼ常に、 トラフィックがルー プしているルーターのいずれかです。この例では、どちらのルーター も問題に関与しています。対象ネットワークへの Altbier の接続はダウ ンしており、そのネットワークへのインタフェースもダウンしているにも かかわらず、Pilsener はトラフィックを Altbier に送っています。 ネットワークオペレータが最初にとるべきステップは、18.32.76.0/24 ネットワークへの Altbier の接続を修復することです。そして後で、 Altbier で OSPF を使用して、そのネットワークへの接続が確立して いる限りルートのアドバタイズを行うなど、設定をより動的なアーキテ クチャに移行させるのが良策です。 全停止障害に救いがあるとすれば、それが完結している点です。曖昧 さ、矛盾、不確定な要素がありません。traceroute を実行するだけで、 問題が発生している場所を特定し、それを確定させるためにどのデバ イスにログインすべきかがわかります。 回線過剰利用のトラブルシューティング 回線の過剰利用は、パケットロスを多々引き起こしますが、厄介なの は間欠的である点です。トラフィックのタイプ（一貫性があるかバース ト性があるか）、トラフィック量（過剰利用の程度が若干であるか劇的 であるか）、および Class-of-Service の設定に応じて、パケットフロー ごとに経験するパケットロスのレベルは異なります。第 2 章で示した 障害例では、回線の過剰利用が生じているシナリオに対する一貫性の あるトラブルシューティングアプローチとフィックステストの適用につい て説明しました。 ルート変動のトラブルシューティング ルート変動は、特定と素早い切り分けが最も困難な問題の 1 つです。 ルート変動では、全停止障害、一部停止障害、ジッター増加など、さ まざまな兆候が見られます。ルーティングテーブルでルートの追加と 削除が素早く繰り返された場合に、ルート変動が発生します。これは、 急激な回線の遷移、共有ルートの再配布、その他さまざまな理由で 発生します。 第7章：レイヤー3のトラブルシューティング ルート変動の問題を特定する最良の方法は、発生時に観察することで す。これは、2 つの方法で達成できます。まず、traceroute を複数 回実行することで、ルートが変動するに伴って使用される多数の異な るパスを確認できます。その後で、変動が発生しているルーター上で show route コマンドを実行します。これにより、複数のネクストホップ および / または異なるプロトコルから受け取ったルートの組み合わせ が示されます。 前述の 18.32.76.0/24 ネットワークに対して Altbier が接続を失った シナリオは、ルート変動の問題を引き起こす状況へと簡単に発展しま す。リンクアップ時には、 トラフィックは想定どおりに流れます。しかし、 リンクダウンが発生すると、Pilsener と Altbier の間のトラフィックは ループします。このリンクが急激に遷移した場合には、ユーザーやオ ペレータは、正常なトラフィックフローとトラフィックループを交互に 経験することになります。このケースでは、ルート変動とルーティング ループの両方が発生します。 共有ルートの再配布も、ルート変動を引き起こします。共有ルートの 再配布は、2 つのプロトコルが相互に再配布されるときに発生します。 慎重に設定しない場合、このタイプのアーキテクチャはネットワーク障 害を引き起こし、トラブルシューティングを困難にします。この手法は、 移行期間に最も多く用いられます（EIGRP から OSPF への移行など）。 しかし、他の問題を解決するために、この手法を長期間にわたり採用 し続けるネットワークもあります。 ここでは、共有ルート再配布がどのようにルート変動を引き起こすの かを理解するために、遷移する例を示します。現在のネットワークを 例にとりますが、図 7-6 に示すように、サービスプロバイダとの関係 を（スタティックルートを使用しない）BGP ピアリング関係に変更し ます。 図 7-6 eBGP によるインターネットサービスプロバイダとの接続 107 108 Day One：Junosの監視およびトラブルシューティング この Pilsener とサービスプロバイダの間のセッションで、以下のよう に、サイトのネットワーク（18.32.72.0/21）に対してアグリゲーショ ンルートを通知し、フルインターネットルーティングテーブルを受け取 ります。 ps@pilsener-re0> show bgp summary Groups:1 Peers:1 Down peers:0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 10007 10007 0 0 0 0 Peer 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 bytes ping: sendto:No route to host ping: sendto:No route to host ping: sendto:No route to host ping: sendto:No route to host 64 bytes from 4.2.2.1: icmp_seq=4 ttl=64 time=0.524 ms 64 bytes from 4.2.2.1: icmp_seq=5 ttl=64 time=0.697 ms 64 bytes from 4.2.2.1: icmp_seq=6 ttl=64 time=0.558 ms 64 bytes from 4.2.2.1: icmp_seq=7 ttl=64 time=0.579 ms 64 bytes from 4.2.2.1: icmp_seq=8 ttl=64 time=0.625 ms 64 bytes from 4.2.2.1: icmp_seq=9 ttl=64 time=0.582 ms 64 bytes from 4.2.2.1: icmp_seq=10 ttl=64 time=0.563 ms ping: sendto:No route to host ping: sendto:No route to host ping: sendto:No route to host ping: sendto:No route to host ping: sendto:No route to host ping: sendto:No route to host ping: sendto:No route to host 64 bytes from 4.2.2.1: icmp_seq=18 ttl=64 time=0.613 ms 64 bytes from 4.2.2.1: icmp_seq=19 ttl=64 time=0.585 ms 64 bytes from 4.2.2.1: icmp_seq=20 ttl=64 time=0.642 ms 64 bytes from 4.2.2.1: icmp_seq=21 ttl=64 time=0.605 ms 64 bytes from 4.2.2.1: icmp_seq=22 ttl=64 time=0.562 ms 64 bytes from 4.2.2.1: icmp_seq=23 ttl=64 time=0.589 ms 64 bytes from 4.2.2.1: icmp_seq=24 ttl=64 time=0.607 ms 第7章：レイヤー3のトラブルシューティング この間に、ping および traceroute を実行することで、4.0.0.0/8 へ の BGP ルートが確立と喪失を繰り返すことがわかります。その結果、 このネットワーク内の任意接続先に対してパケットロスを間欠的に経験 することもわかります。これまで説明してきた裏付けの重要性から、接 続先 4.2.2.1 に対して show route コマンドを実行し、変動を観察します。 ps@pilsener-re0> show route 4.2.2.1 inet.0:10017 destinations, 10017 routes (10017 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 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 ps@pilsener-re0> show route 4.2.2.1 ps@pilsener-re0> show route 4.2.2.1 inet.0:10017 destinations, 10017 routes (10017 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 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 packets 1 4.10.33.2 (4.10.33.2) 0.231 ms 0.411 ms 0.376 ms 2 4.1.18.21 (4.1.18.21) 0.193 ms 0.469 ms 0.288 ms 3 4.2.2.1 (4.2.2.1) 0.587 ms 0.612 ms 0.517 ms ps@pilsener-re0> traceroute 4.2.2.1 traceroute to 4.2.2.1 (4.2.2.1), 30 hops max, 40 byte packets traceroute: sendto:No route to host 1 traceroute: wrote 4.2.2.1 40 chars, ret=-1 この状況では、サービスプロバイダに連絡し、ルートのアドバタイズと 撤回が繰り返されている理由について問い合わせることを推奨します。 一貫性のないパケットロスは、素早く特定して解決することが難しくなり ます。しかし、これは多くの場合、回線の過剰利用、ルート変動、急激 に遷移する回線、あるいはそれらの組み合わせによって発生します。 109 110 Day One：Junosの監視およびトラブルシューティング 遅延のトラブルシューティング 遅延とは、送信元から送信先にパケットが届くのにかかる時間が遅れ る現象です。遅延問題の根本的原因の特定と切り分けは、非常に困 難です。それは、遅延に一貫性がなく、特定のトラフィックタイプに限 定され、再現が難しいことがあるためです。ネットワークのトポロジー、 採用するプロトコル、ネットワークの現在の状態、有効にしている機能 （Class-of-Service など）を理解することは、遅延問題（およびそ の損失については後述）を解決する上で役立ちます。 遅延問題は、特に音声 / 動画など、リアルタイムのアプリケーション で深刻な問題を引き起こします。問題を報告しているユーザーは、遅 延が原因であることを認識していないこともあります。問題レポートに は、単に通話の途切れや動画でノイズが生じていると記載されている かもしれません。HTTP などの通常のトラフィックでは、遅延パケット が発生しても、受信者は次のパケットを受信できるまで待つだけで、 その時間も一瞬であることが多いため、それほど大きな問題にはなり ません。しかし、音声 / 動画ストリームでパケットの遅延が長くなると、 受信者側にとってはパケットが消失した状況と何ら変わりのない深刻 な事態となります。 遅延問題をトラブルシューティングする際の最初のステップは、トラ フィックが最適パスを辿っているかを特定することです。これには、当 然ながらネットワークに対する深い理解が必要ですが、準最適ルーティ ングを引き起こすような障害が現時点で発生しているかを把握するこ とも不可欠です。 ネットワーク例で traceroute を実行すると、ネットワーク、Dunkel、 Pilsener、サービスプロバイダの順に、トラフィックが最適パスを通 過していることがわかります。 次のステップは、遅延を誘発しているネットワークホップを特定するこ とです。以下の traceroute の実行で、ルーター 2 と 3 の間のホップ で明らかな遅延を引き起こしていることがわかります。 server% traceroute 4.2.2.1 traceroute to 4.2.2.1 (4.2.2.1), 30 hops max, 40 byte packets 1 18.32.75.1 (18.32.75.1) 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 ミ リ秒以上まで急激に長くなっています。 第7章：レイヤー3のトラブルシューティング 詳細な調査をすべき箇所が特定できました。この時点では、問題の 原因はルーター 2 またはルーター 3 上でキューイングしている受信ま たは送信トラフィックであると推測できます。大きなパケットキューイ ングが発生しているため、最初に確認すべき箇所はルーター 2 から ルーター 3 へのリンクです。 このリンクで は、 利 用 率 が 低 けれ ば パケットキューイング は 発 生 しないため、 利用率が高いことが想定できます。そのため、show interfaces コマンドを実行して、ルーター 3 へのトラフィックを処理し ているルーター 2 のインタフェースを確認します。 ps@pilsener> show interfaces fe-0/0/1 Physical 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% を使用します。 111 112 Day One：Junosの監視およびトラブルシューティング このリンクで、ある程度規模の大きなキューが発生しているかどうかを 確認するには、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:32 Forwarding classes:8 supported, 8 in use Egress queues:8 supported, 8 in use Queue: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）キューに分類して、ベストエフォー トキューよりも高い優先度を設定します。 すべての送信トラフィックが有効であるかどうかを調べます。 サービスプロバイダへの接続スピードを向上させます。 第7章：レイヤー3のトラブルシューティング まとめ レイヤー 3 の監視およびトラブルシューティングは、レイヤー 1 およ びレイヤー 2 とは根本的に異なるものの、同じ手法とアプローチを用 いてレイヤー 3 での問題を切り分けして、解決することができます。 本書でこれまで説明してきた一貫性のある論理的アプローチをとり、 フィックステストを適用することで、迅速な診断とサポート可能な短期 的フィックスの実装が可能になります。 レイヤー 3 でトラブルシューティングを行う際は、それが相互接続さ れたシステムであり、ネットワーク内の一部のルーターが別のルーター の挙動に基づいて動作する可能性があることを念頭に置いてくださ い。その一例は、ルートタギングと Class-of-Service マーキングで す。ネットワークの運用経験、採用するプロトコルや通常条件下での 運用状況を理解していることに代わるものはありません。しかし、各 プロトコルがどのように機能し、Junos で提供される機能、操作、ツー ルの活用方法を明確に理解するとともに、ネットワークを運用するた めの正しいアプローチをとることで、こうした作業が非常に容易にな ります。 113 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）では、ジュニパーネットワーク ス製品の設定およびトラブルシューティング能力を示すことにより、認 定資格を取得することができます。エンタープライズルーティング、ス イッチング、 またはセキュリティの認定資格を短期間で取得したい方は、 オンラインコース、受講者ガイド、およびラボガイドをご利用ください。
© Copyright 2024 Paperzz
