Cisco テクニカル ソリューション シリーズ：IP テレフォニー ソリューション ガイド

技術上の目標および制約の定義

サポート組織が技術的な観点から Cisco IP テレフォニー ソリューションの目標およびその制約を分析してみると、IP テレフォニー サービスのサービス レベル要件と、そのサービス目標が達成可能であるかを認識するのに役立ちます。また、このプロセスは、ユーザまたは顧客に対して達成可能なサービス レベルに関する予測を設定するのにも役立ちます。

まず、組織では、IP テレフォニー ソリューションに求められるサービス レベルを達成するのに伴うすべての技術的な目標、制約、およびサービス リスクを特定する作業を行います。制約の特定には、次のカテゴリの使用が役立ちます。

• ネットワークや IP テレフォニー テクノロジー、復元力、および構成

• プラニング、設計、インプリメンテーション、運用などのライフ サイクル管理

• IP テレフォニー アプリケーションの動作や要件

制約の特定後には、サービス レベルの目標における最大リスクまたはそのインパクトの程度により、その制約に優先順位を設定する必要があります。これは、組織が目指すサポート構想に優先順位を設定し、制約に容易に対処する方法を見出すのに役立ちます。

ネットワークや IP テレフォニー テクノロジー、復元力、および構成

IP テレフォニー に対するネットワーク テクノロジー、復元力、および構成などの種々の制約は、現在利用できるテクノロジー、ハードウェア、リンク、設計、または構成に関連する制限またはリスクとして定義されます。

テクノロジー上の制限には、現状のテクノロジーによりもたらされるすべての制約が含まれます。たとえば、冗長なネットワーク環境では、サブセカンドの収束時間がネットワーク全体の IP テレフォニー の音声品質を維持する上で非常に重要となりますが、現在のテクノロジーでは、そのサブセカンドでの時間が考慮されていません。別の制限としては、地上波リンクで伝送されるデータの実速度（約 100 マイル/ミリ秒）があります。この速度制限は、WAN 展開モデルにおける考慮事項として重要です。

ネットワーク ハードウェアに関する復元力リスクの調査では、ネットワークで定義されているパスに沿ってハードウェアのトポロジ、階層、モジュール方式、冗長性、および平均故障間隔（MTBF）に重点を置く必要があります。ネットワーク リンクの制約では、企業組織のネットワーク リンクおよびキャリア接続に重点を置く必要があります。リンクの制約には、リンクの冗長性と多様性、メディアの制約、配線インフラ、ローカル ループ接続、および長距離接続を含めることができます。

設計上の制約には、ネットワークの物理または論理上の設計と関連があり、その制約には、機器の設置にスペースからルーティング プロトコルをインプリメンテーションする際のスケーラビリティにいたるまであらゆる制約が含まれます。すべてのプロトコルおよびメディアの設計には、構成、アベイラビリティ、スケーラビリティ、パフォーマンス、およびキャパシティに関して考慮する必要があります。

次のネットワーク サービスに関する制約も考慮してください。

• CallManager の機能性と信頼性

• ゲートウェイの機能性と信頼性

• DHCP および DNS の信頼性

ライフ サイクル管理

ネットワークのライフ サイクルとは、プラニング、設計、インプリメンテーション、および運用のサイクルを意味します。ライフ サイクル管理では、ネットワークのプロセスと管理が定義され次の目的で使用されます。

• ソリューションを目標どおり展開する

• 問題を早期に発見し修復する

• キャパシティまたはパフォーマンスの問題を防止する

• ネットワークの設定には、一貫性をもたせ、またモジュール化を採用して、不必要な煩雑性と予期しない動作を少なくする

一般的に、専門知識とプロセスがアベイラビリティ低下の歯止めとなるため、ライフ サイクル管理の効果が重要になります。

IP テレフォニー アプリケーションの動作および要件

IP テレフォニー のトラフィックには、データ トラフィックとは異なる固有のパフォーマンス制約があります。ほとんどの IP アプリケーション トラフィックでは、再伝送を行い、帯域幅を効率的に使用する TCP を使用します。IP テレフォニー では、再伝送を行わない、RTP（リアルタイム プロトコル）を使用します。また、音声も遅延とジッタに反応します。エンドツーエンド遅延の妥当な制約は、250 ミリ秒（1/4 秒）です。ジッタ（つまり、音声パケット間の時間）は、25 ミリ秒未満にする必要があります。多くの場合、現在のデータ ネットワークでは、キューイング遅延または散発的に発生するネットワーク輻輳により、この一貫性のあるパフォーマンス問題を吸収できません。WAN 展開では、WAN のすべてのリンクで遅延が伴うため、ほとんどの場合に遅延はその要素となります。通常、データは約 100 マイル/ミリ秒で巡回できます。コーストツウコーストの接続では、回線のルーティングに応じて、一部の地域で遅延が 25 ～ 50 ミリ秒となる場合があります。ただし、多くの国際間の接続の場合には、遅延がさらに長くなります。

表 6-2 に示すワークシートと同様のワークシートを使用すると、IP テレフォニー 制約の特定に役立てることができます。また、組織では、その環境で予測されるテクノロジーの制約に加え、現在のサポート機能を考慮する必要もあります。アーキテクチャ、エンジニアリング、運用の各チームで予想されるすべての制約について検討することをお勧めします。

サービス レベルの目標

アベイラビリティおよびパフォーマンスを基準にして、サポート組織に期待されるサービス レベルが設定されます。また、アベイラビリティおよびパフォーマンスは、サービスおよびサポートの要件を定義する際にも役立ちます。一般的に、サービスの目標は、アベイラビリティおよびパフォーマンスにより設定されます。パフォーマンスには、遅延、ジッタ、最大スループット、帯域幅の契約などの要素が含まれる場合があります。IP テレフォニー のアベイラビリティには、ネットワーク全体のアベイラビリティだけでなく、IP テレフォニー およびゲートウェイのアベイラビリティも含まれます。

IP テレフォニー または VoIP の要件に基づいたパフォーマンス目標を定義する必要があります。また、ビジネス要件に基づいたアベイラビリティ目標を作成する必要がありますが、技術上の制約およびコストが常に主要な要素となります。次の領域を分析して、IP テレフォニー ソリューションの可能なアベイラビリティを決定します。

• ハードウェア パスの MTBF（平均故障間隔）と MTTR（平均修復時間）

• ソフトウェアの信頼性

• 災害への準備を含む電源/環境のアベイラビリティ

• キャリアまたはリンクのアベイラビリティ

• 冗長性、収束機能を含むネットワーク設計

• ユーザのエラーまたはプロセスの考慮事項（技術上の問題を隔離して解決するのに要する時間を含む）

サービス領域またはサービス パラメータを定義したら、前述のステップの情報を利用して、サービス規格の対応表を作成します。アベイラビリティは、前述の領域と予想されるサポート機能を調査した結果で定義される予想アベイラビリティに基づいています。また、ユーザと IT グループ間であいまいになっている領域も定義しておくこともお勧めします。たとえば、ラウンド トリップ PING の最大応答時間は、ユーザが音声コールで体感する応答時間とはまったく異なります。 表 6-3 では、大部分の組織の要件を満たすサービス規格を示します。

（注） Ping では、RTP の QOS 設定と多くのプラットフォームの PING プロセスの優先順位により、RTP または音声トラフィックの応答時間を必ずしも正確に測定するとは限りません。その代わりに、CiscoWorks2000 に組み込みの Cisco Internet Performance Monitor（IPM）などのパフォーマンス ツールを使用して、RTP トラフィック パフォーマンスを測定します。

関係者の決定

IP テレフォニー サポートでは、さまざまな関係部門、特にテレコミュンケーション部門、データ ネットワーキング部門、NT サーバ管理グループ、ユーザや部門のリーダーなどの間で、サービス レベル契約、または、少なくともサービス レベル定義が必要となります。

ある組織が IP テレフォニー サービスのサービス レベル契約を結ぶ場合には、組織の各部門の責任者と管理者は、ユーザの観点から各部門の役割および予想される責務を把握する必要があります。多くの場合、テレコミュニケーション サポートおよびデータ サポートに対するサービス定義を統合または再作成して、各部門で行っている現在のサポート機能と同期化する新しいサポート基盤を構築する必要があります。

IP テレフォニー の予想されるサービス要件については、次の項を参照してください。関係者は、IP テレフォニー のサポート要件を検討して各部門の役割と責務について十分に把握する必要があります。さらに、組織では、サービス要件の目標を十分に満たすための、人員計画や必要とされる専門知識を定義する必要があります。

サービス要素の定義

IP テレフォニー のサービス要素に対する種々の要件は、ある組織ではすでに、定義済みのサービス要素に組み込まれている場合があります。別の組織では、IP テレフォニー ソリューションに関連して新しいサービス要素を定義する場合があります。とはいえ、すべてのサービス定義は、役割と責務が IP テレフォニー に特有の問題に適切に対応して定義されているか、また定義されているサービス レベルが IP テレフォニー およびビジネスの要件を満たしているかの観点から再検討する必要があります。

サービス要素は、対処的サービス要素と予防的サービス要素の 2 つの異なるカテゴリに分類されます。対処的サービス要素では、IP テレフォニー の問題のレポート作成、およびその修復に必要なプロセスが定義されています。予防的サービス要素は、安定したパフォーマンス、音声品質、プロビジョニング、および変更管理とセキュリティを確保する手段として必要になります。IP テレフォニー に関して現在、定義されているサービス要素は、次のとおりです。

• 対処的サービス要素

–サービス修理の可能性および問題の優先順位付け

–問題のレポート作成とエスカレーション パス

–障害モニタリング

–デバイス ファイルのバックアップおよびその復旧

–ハードウェア交換およびオンサイト支援

–エスカレーション パスおよびその要件

–災害回復プロセス

–メトリックおよびレポーティング

• 予防的サービス要素

–変更管理

–MAC（移動、追加、変更）プロセス

–電話番号およびダイヤル計画の管理

–IP/DHCP 管理

–予防的ネットワーク管理プロセス

–不正アクセスの検出

–課金

次の項では、上述のサービス レベル要素に関連する、サービス レベル定義に付随する事項とその事例について説明します。

対処的サービス要素

対処的サービス要素は、IP テレフォニー の障害を堅実かつ迅速に判別して障害の修復をするために必要なプロセスが定義されます。各サービス領域には、検討を要するサービス要素の必須パラメータが含まれています。一部の例では、組織内で IP テレフォニー の運用サポート計画を作成するときに、テンプレートとして使用できるサービス レベル要素の例も含まれていることがあります。

サービスの対応策と問題の優先順位付け

サービス レベルを定義している文書の冒頭では、通常、特定されている問題に対する問題の対応策と問題の優先順位付けを文書化しておくことを要求しています。一般的には、これらのサービス レベル領域は、ヘルプ デスクに貯えてあるデータベース統計と定期的に行われるシステム監査を手がかりとして決定されます。通常、組織では、この領域に既存しているサービス レベルを再検討し、IP テレフォニー アプリケーション特有のサービス レベルに対する、問題の対応策と問題の優先順位を定義します。

表 6-4 では、IP テレフォニー ネットワークで発生する可能性のある問題に関連するサポート重大度を示します。組織によっては、表に示されているサポート プロセスで対処している場合、IP テレフォニー サービスには、重大度 5 が新たに必要になる場合があります。

問題に対する重大度を定義し終えたら、組織では、サポート プロセスを定義または調査して、サービス レスポンス定義を作成する必要のある場合があります。一般的に、サービス レスポンス定義には、トラブル チケットを使用して問題を追跡するために、ヘルプ デスクのソフトウェア サポート システムと連動している階層型サポート構造が必要です。また、各優先順位の応答時間と解決時間、優先順位別のコール数、および応答/解決の品質において、測定基準を用意しておく必要もあります。サポート プロセスを定義すると、組織および各サポート階層の役割と責務の目標を定義するのに役立ちます。これにより、組織が各サポート レベルについて、リソースの要件と専門知識のレベルを把握するのに役立ちます。 表 6-5 では、問題解決に階層型サポート体制をとっている組織の例を示します。

次のステップでは、サービス応答とサービス解決のサービス定義の対応表を作成します。この表により、ハードウェア交換などの問題を迅速に解決する方法の目標が設定されます。サービス応答時間と復旧時間はネットワークのアベイラビリティに直接影響するため、この領域の目標を設定することが重要になります。

また、問題解決時間をアベイラビリティ予測と基準を合わせる必要もあります。アベイラビリティ目標で、重大度の高い問題の原因が明らかになっていない場合には、組織はそれらの未解決問題の原因の究明と、その考えられる解決策を提示する作業をします。

表 6-6 では、サービス応答と解決目標の例を示します。

問題のレポートとエスカレーション

IP テレフォニー にかかわる問題が適切にレポートされるには、レポートが行われるプロセスが明確に定義されていて、また、その文書化とレポート方法が周知徹底している必要があります。これにより、異なるサポート組織が地理的な壁を越えて、問題を的確に処理することができます。また、サービス応答とサービス解決に加え、エスカレーション対応表を作成する必要もあります。エスカレーション対応表からは、上位の重大なサービス問題に使用可能なリソースが集中していることを確認するのに役立ちます。一般的に、問題の修復に集中している当事者が、その解決すべき問題に援助するリソースを追加するだけでよいと思うことはほとんどありません。追加リソースを通知すべき時期が定義されていると、管理面から問題を解決する意識を高め、以降の予防策をもたらすことになります。

表 6-7 では、重大度レベル エスカレーションの対応表の例を示します。

次に、問題のレポートとエスカレーション計画の例を示します。

1. 階層 1および階層 2 のサポート

米国外サイトの場合は、レポートされるすべての IP テレフォニー に関する問題の最初で単一の連絡先となるのが、International Response Center（IRC）です。また、米国内のすべての企業サイト、リモート サイト、および現地販売サイトの場合は、レポートされるすべての IP テレフォニー に関する問題の最初で単一の連絡先となるのが、Telecom Help Desk です。

米国外のサイトでは、IRC が問題に関する情報をログとして記録し、レポートされた問題の解決を試みます。また、IRC は、可能な場合はページング サービスを利用して、問題解決に責任のある管理者および技術者に注意を促す役割があります。サポートを担当する技術者には、勤務時間に携帯するポケットベルを通じて連絡を取ります。管理者には、グループ ポケットベル リストを通じて連絡を取ります。IRC が即時に問題を解決できない場合には、問題のトラブル チケットが階層 2 のサポートのネットワークおよびテレコミュニケーション オペレーションにエスカレーションや転送が行われます。

米国内では、Telecom Help Desk では問題に関する情報をログに記録し、レポートされた問題の解決にあたります。また、Telecom Help Desk では、必要に応じて TRC に連絡を取り、適切なページング サービスと通知サービスを提供します。問題が即時に解決されない場合には、階層 2 のサポート プロセスが要請され、Telecom Help Desk は階層 2 のプロセスで問題の解決にあたります。

2. 階層 2 のエスカレーションおよびサポート

レポートされた問題が階層 2 にエスカレーションされると、Telecom Operations（米国内）または Network および Telecom Operations（米国外）が、問題が解決するまでトラブル チケットの責任を持ち続けることになります。問題を LAN または WAN 特有の問題と隔離できる場合、問題の隔離と解決について 階層 2 レベルで LAN および WAN オペレーション グループに連絡を取ります。同様に、問題を NT オペレーション特有の問題と隔離できる場合、問題の隔離と解決について NT オペレーションに連絡を取ります。すべてのグループは、問題の解決について Telecom Operations または Network および Telecom Operations と協力します。

3. 階層 3 のエスカレーションおよびサポート

Telecom Operations（米国内）または Network および Telecom Operations（米国外）がLAN、WAN、および NT オペレーションとの連携で問題を解決できないと判断したら、その問題を階層 3 のサポートにエスカレーションされ、その問題の事例が World Wide Technical Assistance Center（WW TAC）に公開されます。

必要な場合にはベンダーの他のサポート チームと On-Site Support（OSS）チームへのエスカレーションを含めて、WWTAC が Telecom Operations と連携して作業を行い、できるだけ早急に問題を解決することが要求されます。

NT プラットフォーム関連と思われる問題、または WWTAC が On Site Support（OSS）を派遣して、NT オペレーティング システムが稼動しているサーバを交換する場合には、問題の解決における連携とコラボレーションについて、NT オペレーションと連絡を取ります。Telecom Operations または Network および Telecom Operations が、NT オペレーションと連絡を取る役割を果たします。

図 6-1 は、エスカレーション プロセスを図示したものです。

図 6-1 エスカレーション プロセス

Telecom Operations、ローカル サイト、Network および Telecom Operations のサポートおよび責務の限度

P1 および P2 の問題解決（障害対応サポートを含む）は、4 時間以内で解決されます。また、この解決では現地の地域担当者によって提供されるオンサイト アクセス権を持っていることを条件とします。現地でオンサイト アクセス権が提供されない場合、この問題事例が WW TAC および Cisco IT によって P3 問題事例として再分類され、問題を 1 日内で解決する目標が適用されます。

各サイトにおける P1 および P2 サポートのデュアル CallManager

NT オペレーションでは、デュアル プライマリ バックアップ CallManager を使用するサイトに限り、P1 および P2 サポートを提供します。

NT オペレーションは、LAN または WAN の問題によって NT オペレーションがサイトにアクセスできない場合には、サポートはベスト エフォートで行います。たとえば、LAN がダウンし、P1 としてレポートされず、その問題によって NT オペレーションが解決と修復のために CallManager にアクセスできない場合、NT オペレーションでは、その問題事例をネットワーキング問題事例のレポートされている優先順位のステータスに格下げします。すべての場合において、NT オペレーションは、CallManager へのリモート ネットワーク アクセスを妨げている原因になっている問題事例に対する一番低い優先順位と同等のサポートを提供します。NT オペレーションが、機器ユニットの一部またはサーバの交換が必要であり、企業の IT 部門が機器の 24x7x4 オンサイト サポート契約を購入していることが確認できないと分かった場合、NT オペレーションは、24x7x4 障害対応サポートを提供する責務がありません。

CallManager サーバのセキュリティおよびアクセス権限

P1 および P2 のサポートについては、NT オペレーションが IP テレフォニー CallManager を稼動している NT サーバへのアクセスに必要な権限をもっているかに応じて提供されます。

すべての IP テレフォニー CallManager サーバに対してドメイン名、URL、ユーザ ログイン、およびパスワードを提供、保守、通知する役割は、IT-Telecom が行います。ダイヤルアップ リモート制御ソフトウェアを使用して、ダイヤルイン リモート アクセスがサイトに提供されている場合、リモート アクセス コンソール サーバに対して、ダイヤルイン番号（ユーザ ログイン、パスワードを含む）を提供、保守、通信する役割は、IT-Telecom が行います。また、IP テレフォニー CallManager および NT オペレーションに対して適切なリモート アクセス クライアントおよびサーバを提供する役割も、IT-Telecom が行います。

障害モニタリング

IP テレフォニー ネットワークの障害モニタリング プロセスには、デバイス ダウンのモニタリング、リンク ダウンのモニタリング、およびネットワーク エラーのモニタリングを含める必要があります。IP テレフォニー コンポーネントに対してプロセスを定義してあれば、サポートと Network Operation Center（NOC）の責務が明確になるため、運用環境がさらに効果的に信頼性が高くなります。

表 6-8 は、デバイス ダウンのモニタリングの障害モニタリング サービス レベル定義の一例です。アラートおよびその処理方法を明確に把握できます。組織は、前述の定義の際にさらに作業を積み重ねて、確実に処理しなければならない場合があります。場合によっては、組織には日時に応じたさまざまなアラート、優先順位、およびエスカレーション パスを用意していることがあります。たとえば、ある組織では 7x24 NOC 体制が組まれていないが、サポート担当者に対して 24 時間のポケットベル通知があります。

表 6-9 では、ネットワーク エラーのサービス レベル定義の一例です。これにより、エラー アラート、責任者、問題の特定方法、問題発生時の動作について明確に把握できます。組織は、上述の定義に際してさらに作業を積み重ねて、確実に処理しなければならない場合があります。

デバイス ファイルのバックアップおよび復旧

ハードウェア問題によって、デバイス ファイルの破損または損失が常に発生する可能性があります。組織では、それに備えてネットワーク デバイスおよび CallManager システムのバックアップにプロセスを定義する必要があります。IOS ゲートウェイ デバイス、MGCP ゲートウェイ デバイスを含むほとんどのネットワーク デバイスでは、構成ファイルをバックアップするために TFTP がサポートされています。DT-24 ゲートウェイは、その構成を CallManager で維持します。そのため、新しい DT-24 ゲートウェイが必要な場合、CallManager に新しい MAC アドレスを構成する必要があります。CallManager システムでは、復旧が必要な場合に構成ファイルが手元になければならないため、復旧するために構成ファイルのセットだけでなく、システム ソフトウェア ロードが必要になります。CallManager のバックアップは、サポートされている別のシステムへのテープ ドライブ バックアップまたはネットワーク バックアップを使用して行います。

組織では、バックアップ時期、バックアップを実行する担当者、バックアップ テープまたはディレクトリの場所、および復旧の責任者を定義する必要があります。また、デバイスのバックアップおよび復旧のサービス計画を作成する必要もあります。

表 6-10 では、組織内で使用できるファイルのバックアップおよび復旧計画を示します。

CallManagerのバックアップに加え、組織は CallManager の構成と変更内容を管理する担当者を決定する必要があります。CallManager は NT デバイスであるため、NT サーバ管理グループがこのアクティビティの責任を果たすことになる場合があります。CallManager 構成の責務には、次の内容が含まれます。

• すべての CallManager の変更制御ログの追跡、管理、およびアーカイブ

• CallManager 構成の一貫性の維持

• バージョンおよびパッチを含む、CallManager ソフトウェアの一貫性の維持

• スケジュールのバックアップ

• 復旧プロシージャのバックアップ

ハードウェア交換およびオンサイト支援

組織では、ハードウェア交換プロセスおよびイト支援サポート機能を検討する必要があります。この検討は、新しい IP テレフォニー のアベイラビリティ目標とビジネス要件を満たしていることを確認するのに役立ちます。特にこれは、新しい IP テレフォニー のアベイラビリティ目標とネットワークに数多くのデバイス タイプがある場合に適用します。

次の 2 つの要素は、ハードウェア アベイラビリティの要因です。

• MTBF（Mean Time Between Failure）

平均故障間隔とは、デバイスの故障率を示します。Cisco は、Telcordia（旧 Bellcore）のパーツ カウント方式に基づいて理論的なアベイラビリティを維持します。各デバイスの故障率は、Telcordia TR-332 規格表の最新刊から引用されています。最終の予想 MTBF 値は 2 回です。これは Cisco の過去の経験に基づいて計算された結果です。

製品が市場にリリースされると、フィールド交換データが集められ、毎月更新される 3 ヶ月の具体的な MTBR 値が計算されます。この MTBR 数値は、Cisco Metrics データベースによってレポートされる稼動中の設置ベースと Returned Material Authorizations（RMAs）を基にしています。MTBR は、3 ヶ月間の設置ベースの運用総時間を過去 3 ヶ月の返品ユニット数で割って計算されます。この情報は、要求に応じて Cisco アカウント チームから入手できます。

• MTTR（Mean Time To Repair）

平均修復時間とは、サービスおよびサポート全体の目標を達成するために、サポート契約を設定するか、スペアの在庫を確保するための組織の責務です。 表 6-11 では、2 つの理論デバイスに対して異なる所定の MTTR 値を適用した場合に予想されるアベイラビリティを示します。

組織では、ハードウェアを交換する方法には複数の選択肢があります。まず最も一般的な方法は、Cisco SmartNET サポート契約です。これにより、約 1 営業日で返品されたハードウェアまたはコンポーネントと交換します。多くの場合、これは MTTR を短縮する目的でスペア プログラムと組み合わせています。別の方法には、4 時間のサポート契約があり、オンサイト支援とハードウェア交換は 4 時間となります。

また、スペア プログラムを成功させるには、複数のコンポーネントを確保しておく必要があります。ある組織では、Material Management と呼ばれるグループさえも立ち上げて、スペア サービスを行っています。スペア プログラムを総合的に成功させるには、次に示す要素が重要です。

• スペアの在庫管理および保管場所の管理

• 現在のソフトウェア要件に対してハードウェア コンポーネントを満たしているか定期的に検討

• 破損したコンポーネントが返品され、新しいスペアがスペア在庫に登録されたことを確認する RMA トラッキング

• 接地を確実に行ったうえでモジュールを挿入するハードウェア取り扱い手順

オンサイト支援とその運用時間は、ハードウェアのスペア プログラムに応じて異なります。Cisco サポートは、7x24 の 4 時間サービス契約を提供し、この領域においてサポートします。現在、組織に 7X24 サポートまたは 7X24 NOC の体制がない場合、営業時間外に発生する問題を特定し、修復する方法を検討しなければならない場合があります。

災害復旧

災害復旧計画には、重要なビジネス アプリケーションの実行に必要なハードウェアおよびソフトウェアと、災害発生時にスムーズに移行するための関連プロセスとが含まれます。IP テレフォニー アプリケーションでは、音声機能がデータ ネットワークと密接にかかわっているため、災害復旧にはデータ ネットワークとの新しい関係を作りあげる必要があります。

災害に備えるには、管理面から検討するのが最初のステップです。組織の各部門で必要になるリソースと時間を調達するには、上級管理者がビジネスに与える影響およびそのリスクを理解してサポートする必要があります。大規模のプロジェクトを推進するときと同様に、災害復旧には、上級管理者の強力な指導の下に、災害復旧計画の導入をサポートし、災害に対するプロセスを確立し、必要なリソースを配備する必要があります。管理面から対応策を確立するためには、次にいくつかの重要な作業があります。

• 考えられる災害のうち上位 10 件の特定、およびそのビジネスに与える影響をリストで作成（火災、地震、暴風など）

• 上級管理者とのリストの検討と管理面からの対応策

• 災害復旧計画プロセスおよび資金調達に関して上級管理者より承認

災害復旧計画に含める重要な項目は、次のとおりです。

• 計画グループの確立

• リスク評価およびリスク監査の実施

• ネットワークおよびアプリケーションの優先順位の設定

• 復旧計画の展開

• 在庫の更新と復旧計画の文書化

• 確認基準と復旧手順の展開

• 実装

回復力（resilience）およびバックアップ サービスは、災害復旧の根幹を占めているため、災害回復の基準を達成するために入念な検討が必要となります。ほとんどの場合、アベイラビリティを高く保つ設計が災害回復の基盤となります。この設計目標だけで小規模な災害または局地的な災害に十分対応できる場合があります。回復力計画およびバックアップ サービスに含まれる重要な作業は、次のとおりです。

• 回復力に対する評価 ñ 現実との格差とリスクを特定

• バックアップ サービスの検討

• ネットワーク回復力およびバックアップ サービスの実装

ベンダー サポート サービスを追加すると、災害復旧計画は強力になります。たとえば、企業個々に管理されているホット スタンバイ サイトや応答時間が速いオンサイト サービスなどです。多くの組織では、Sunguard などの組織から固有の災害復旧サービスを使用して、適切なバックアップ データ サービスを提供します。ベンダー サポートのトピックで重要な疑問点は、次のとおりです。

• サポート契約が交わされているか。

• ベンダーが災害復旧計画をに参加しているか、エスカレーション プロセスにベンダーが含まれているか。

• 災害復旧をサポートするためにベンダーが十分なリソースを確保しているか。

評価基準（metric）とレポート

定義済みの各サービス レベルに対する目標は、常に評価できるようにしておく必要があります。これにより、組織はサービス レベルの評価、ルートに関わるサービス問題の特定、および特定の目標に対して改善を行うことができます。まとめると、評価基準は、ネットワーク管理者のツールとなり、サービス レベルの管理に一貫性をもたせ、ビジネス要件に合わせてサービス レベルの改善の助けになります。

現在、多くの組織ではアベイラビリティ、パフォーマンス、およびネットワーク メトリックを収集していません。主な理由には、正確性、コスト、ネットワーク オーバーヘッド、および利用可能なリソースを提供できないことがあげられます。幸いなことに、多くの組織では正確性を完全に実現できないまでも低コスト、低オーバーヘッドのメトリックを策定して、サービス レベル管理の主要目標を達成しています。

一般的に、サービス レベルに対する評価基準では、アベイラビリティおよびパフォーマンスの評価が無視されています。組織の中には、メトリックを使用して成果を収めているケースがありますが、その評価基準には、非常に簡単な 2 つの方法を採用しています。1つ目の方法は、ネットワークのコア ロケーションからエッジに ICMP PING パケットを送信していることです。また、この方法を使用してパフォーマンスに関するデータも収集しています。この PING の方法で成果を収めている組織では、たとえば、デバイスのように LAN デバイスまたは国内の現地オフィスなどの「アベイラビリティ グループ」にグループ化しています。通常、組織では地域あるいはネットワークの重要なビジネス地域に応じて異なるサービス レベルの目標を設定しているため、このグループ化は非常に有効です。このグループ化により、メトリック グループはアベイラビリティ グループを使用してすべてのデバイスを平均化して、妥当な結果を得ることができます。

アベイラビリティを評価する 2 つ目の方法は、トラブル チケットと IUM（impacted user minutes; ユーザに影響する停止時間（分））と呼ばれる評価を使用します。この方法は、停止によって影響するユーザ数を集計し、その合計数を停止時間（分）で乗算します。期間内の合計時間（分）の割合として表すと、容易にアベイラビリティに変換できます。どの方法でも、ダウンタイムの根本的な原因を特定し、その評価をするのに役立ちます。そのため、より容易に改善の目標とすることができます。根本原因のカテゴリには、ハードウェア問題、ソフトウェア問題、リンクやキャリアの問題、電源や環境の問題、変更障害、およびユーザ エラーが含まれます。

大規模のネットワーク インフラ全体でパフォーマンスとジッタを一貫性のあるように評価する作業は、やはり困難な作業になります。Internet Performance Monitor（CiscoWorks2000 に同梱されている）などのいくつかのツールは、ネットワーク全体にアクセスするキー パスの評価に役立ちます。Ganymede 社の Chariot などのその他のツールは、特定のサーバまたはワークステーションに対してリアル タイムで VoIP トラフィックを使用してパフォーマンスとジッタを評価するのに役立ちます。

その他の目標として測定可能な対処的サポートには、コールの優先順位、問題解決の目標、または MTTR と問題エスカレーション時間別の対処的サービスに対する応答時間が含まれます。通常、対処的サポートの目標は、ヘルプ デスク データベースからレポートを抽出することで評価されます。この評価には、コールが最初にレポートされた（またはデータベースに入力された）時間、問題に取り組む担当者がコールを受けた時間、問題がエスカレーションされた時間、問題解決が完了した時間に対する個々のフィールドがデータベースに登録されている必要があります。この評価方式には、問題がデータベースに常に入力されていて、それに問題の更新もリアル タイムで行われるように管理が必要となる場合があります。場合によっては、組織はネットワーク イベントまたは電子メールの要求に対して、トラブル チケットを自動的に発行できます。これは、問題の開始時間を正確に特定するのに役立ちます。通常、この種の評価方式から生成されるレポートには、優先順位、ワーク グループ、および個人のユーザ別に問題がソートされ、考えられる問題を判別するのに役立ちます。

サービス レベル管理を成功させるもう 1 つの評価方式は、サービス レベル管理自体の検討です。サービス レベル契約が適切か、その検討を行う必要があります。サービス レベル管理の検討は、定義されたサービス レベルを評価および維持する責任のある担当者と月例ミーティングを行う必要があります。また、サービス レベル契約を検討する場合には、ユーザ グループもミーティングに参加する必要があります。したがって、ミーティングの目的は、サービス レベル定義を実測したパフォーマンス上から検討することと、そのパフォーマンスを改善することです。

月例ミーティングでは、特定期間に評価されたサービス レベルの再検討、各地区ごとに定めてある改善案の再検討、現在のサービス レベルの評価基準、および現在の評価基準に改善の余地がないか討議する内容の議事録をあらかじめ作成しておく必要があります。また、長期的には、組織は既定のサービス レベルに近づき、グループの有効性を判別します。このプロセスは、品質サイクルまたは品質改良プロセスに類似します。このミーティングは、各問題を取り上げ、根本的な原因に基づく解決策を決定するのに役立ちます。

予防的サービス要素

予防的サービス要素では、必要な商習慣の一部となる固有のプロセス、あるいはネットワーク全体の管理可能性、アベイラビリティ、およびパフォーマンスに推奨される固有のプロセスが定義されています。煩雑性を省き、問題発生時に問題を迅速に解決できるように、ネットワーク インフラ全体で構成、バージョンおよびモジュールの一貫性を維持することが、IP テレフォニー ネットワークを支障なく運用する秘訣の 1 つです。この項で説明する予防的サービス レベルの各要素には、推奨されるサービス レベル パラメータの検討が含まれています。場合によっては、組織内で IP テレフォニー の運用サポート計画を作成するときに、テンプレートの例として使用できるサービス レベル要素も含まれています。

変更管理

変更管理とは、一般的に、企業およびサービス プロバイダの組織内に導入されているプロセスで、ネットワークに一貫性をもたせ、またその変更を確実に行うのに役立つプロセスのことです。変更管理は、次の項目を確認しながら適切に行うと、アベイラビリティが向上します。

• ネットワーク変更が組織で最も重視されていること

• 変更が正常に行われること

• 変更によって、ユーザまたはお客様の影響が最小限になること

• 変更後の影響が事前に説明されていて、理解が得られていること

変更管理は、ネットワーク アベイラビリティに関連する最も重要なプロセスの 1 つとなります。変更管理の体制がないと、組織では、予定外のダウンタイムの多発、ネットワークの一貫性の低下、および変更による障害率の急激な上昇を招くことになります。また、ネットワークの一貫性に欠けていると、ネットワーク障害と修理時間の延長が多発します。このため、新たに成長しつつあるネットワークではこの変更管理が重要な目標業務として考えられています。

プロセスの移動、追加、変更

IP テレフォニー の実装の規模が広くなると、組織では IP Phoneのプロビジョニングおよびその移転のために MAC プロセス（Move, Add, Change Process）を準備しておく必要があります。このプロセスは、一貫した実装品質を使用していること、IP テレフォニー リソースが正確に設定されていること、現在のプロビジョニングと音声 IP Phoneサービス レベルを追跡することを確認するのに役立ちます。組織に複数のサイトがある場合には、電話の MAC 変更サービスをタイムリーに提供する上でこのプロセスが重要となります。また、VoIP ゲートウェイにアナログ電話が接続されている場合、組織では別の実装タイプを設定しなければならない場合があります。

まず、組織は電話の MAC 変更を担当するサポート グループを特定します。また、ビジネス要件も電話の MAC の予測サービス時間および予測ターンアラウンド時間を判断するのに役立ちます。その後、特定した組織は、電話 MAC の実行に使用するスタッフの配属レベルとその手順を決定する必要があります。

組織は、データベースまたはスプレッドシートですべての電話の情報を収集および保守する必要があります。一般的に、この情報には、電話、電話番号、およびユーザ情報が含まれます。

電話番号およびダイヤル計画の管理

多くの組織は、電話番号情報とダイヤル計画を管理する必要があります。一般的に、電話情報はテレコミュニケーション データベース、または場合によってはスプレッドシートにアーカイブされます。この情報は、電話ディレクトリ、電話番号と範囲、CallManager のスケーリング、課金、電話区域、電話の再構成、または交換および在庫の管理に活用できます。この情報の一部は、すべての電話のデフォルトになっている場合がありますが、電話の構成全体に対応できるようにその情報を追加できます。 表 6-12 では、ユーザが追跡する情報を示します。

組織は、電話とダイヤル計画管理についての標準を設定する必要があります。標準を設定する項目は、次のとおりです。

• テレフォニー番号管理からディレクトリ番号を抽出する標準式（5 桁のダイヤル プレフィックス + 内線番号または7 + 2620）

• 全社の IP Phoneについて、その企業「組織」名をデフォルトのグローバル パーティション名として標準化する

• クラスタ全体のコール検索スペースについて名前を標準化する

• 製品に付属のデフォルトの電話ボタンテンプレートを使用する

• ライン表示について「ニックネーム ラストネーム」を標準化する

• Cisco 製品 IDに基づいた電話の詳細を標準化する

電話番号をスケーリングしている組織については、継続中のダイヤル計画管理も考慮事項となる場合があります。現在、多くの組織には、4 桁または 5 桁の内線番号など短縮ダイヤルのサポートを含むダイヤル計画があります。組織は、地域または電話グループそれぞれの数字識別子を追跡して、スケーリング問題を定期的に判別します。多くの場合、組織は 4 桁ダイヤルから 5 桁ダイヤル、あるいはさらに 6 桁ダイヤルに移行して、組織内の電話量に対応しなければならない場合があります。

IP/DHCP/DNS/TFTP 管理

組織では、IP アドレス スペース、DHCP サーバ、および TFTP サーバのサポート計画も必要になります。現在ではすでに、組織は IP アドレッシングと電話との連携方法が定義されています。一般的に、次の 3 つの方法論から 1 つを使用しています。

• データ デバイスと同じサブネットを使用して IP アドレスを割り当てる

• 現在の IP アドレッシング計画を修正する

• IP Phoneに別々の IP サブネットを作成する

方法論を定義すると、IP Phoneに IP アドレスを割り当てることができます。また、多くの組織は、IP アドレスに関連付けられた標準 IP アドレス範囲と DNS 名を設定することを選択します。その後、その情報をプライマリ（おそらくバックアップ）DHCP サーバに設定する必要があります。さらに、組織はバックアップ ストレージに TFTP サーバが必要となります。IP/DHCP/DNS/TFTP 管理では、次の責務を考慮する必要があります。

IP アドレス管理

一般的に、IP アドレス管理はデータ ネットワーキング グループによって実施されます。これらのアクティビティは、すでにデータ ネットワーク管理に対して実施されている必要があります。

• 電話 IP アドレッシング方法論の特定

• IP Phoneに必要なネットワーク構成の変更

• IP Phoneおよびデータ デバイス サブネットの IP アドレス範囲の管理/割り当て/追跡

• DHCP によって割り当てられた IP Phoneに対して IP Phoneの DNS 標準の作成

DHCP 管理

通常、DHCP 管理には、NT サーバ管理要件と DHCP アプリケーション サポート要件が含まれます。DHCP サービスはオプション 150 をサポートするため、IP Phoneでは DHCP サーバから IP アドレスをダウンロードし、さらに要求を CallManager に転送してその構成をダウンロードすることができます。このオプションがなければ、IP Phoneを手作業で構成する必要があります。次のプロセスとその所有者は、DHCP 管理の一部と見なされます。

• DHCP ファイルの冗長化を含む、DHCP サーバの設計

• サーバ問題に関する DHCP サーバの管理およびサポート

• DHCP データベースのバックアップと復元

• DHCP サブネットの構成

• DHCP サブネット範囲キャパシティの検討

• DHCP 割り当ての構成

• DHCP 問題のサポート

DNS 管理

一般的に、DNS 管理はすでにデータ ネットワーキング プロセスの一部になっています。主に、DNS サーバは、ネームと IP のバインディングを実行するために使用されますが、IP アドレスの場所を保持するためにも使用されます。これは、IP アドレスの割り当ての有無を特定するのに役立ちます。ハイ アベイラビリティ アプリケーションとして VoIP をサポートするために適切な冗長化が実行されていることを確認するには、設計段階のときに DNS サーバを調査する必要があります。IP テレフォニーで重要となる DNS プロセスには、次の項目が含まれます。

• DNS サーバの管理

• DNS データベースのバックアップと復元

• デバイス MAC または DHCP IP アドレス範囲の DNS 更新

• DNS 解決問題のサポート

TFTP 管理

一般的に、TFTP サーバは、IOS ゲートウェイと IP Phoneを含むデータ ネットワーキング デバイス構成ファイルをアーカイブするために使用されます。また、CallManager クラスタの一部として TFTP サービスも設定できます。Cisco では、クラスタ構成で IP テレフォニー の TFTP サービス実施することを推奨しますが、汎用デバイス構成のバックアップにその他の TFTP サーバを使用できます。典型的に、TFTP サーバの管理の責務となるのは、次のとおりです。

• ファイルのクリーンナップ

• TFTP データベースのバックアップと復元

• TFTP サーバ問題のサポート

予防的ネットワーク管理プロセス

IP テレフォニー ネットワーク管理に対して予防的ネットワーク管理プロセスを特定しておくと、組織が成長と変遷を遂げても音声品質が従来どおり維持されていることを確認するのに役立ちます。予防的ネットワーク管理に含める特定目標は、次のとおりです。

• ネットワークをできるだけシンプルにするよう努め、継続中のネットワークの管理可能性およびサポート可能性を確実にする。

• ネットワークと IP テレフォニー ソリューションのスケーラビリティおよびパフォーマンスを長期間にわたって確実に継続することで、IP テレフォニー のパフォーマンスを維持および改善する。

• 長期間にわたってアベイラビリティおよび所有権コスト合計を改善するために品質を改善する。

これらの目標は、次の 3 つの管理領域に分類できます。

• キャパシティ/パフォーマンス管理

• 構成管理

• アベイラビリティ管理

キャパシティ/パフォーマンス管理

表 6-13 では、推奨される検討期間の他に、必要となる予防的プロセスを定義しています。

構成管理

構成管理プロセスは、構成、ソフトウェアのバージョン、ハードウェア モジュール、およびネットワーク トポロジに一貫性をもたせるようにするのに役立ちます。一貫性の観点から構成、バージョン、およびトポロジを構築してあれば、長期的にみてもコンプレックスになりにくい構成環境を維持するのに役立ちます。その結果、サポートと管理が容易になります。

また、コンプレックスの程度が低い環境では、バグや問題が少なく、修復時間も短くなるため、アベイラビリティがさらに向上することになります。 表 6-14 では、構成管理に対して予防的な観点からネットワーク管理に特定されているプロセスを示します。

品質改善

高いアベイラビリティと安定したパフォーマンスを維持している組織では、品質改善プロセスを用意しています。多くの場合、製造プロセスに応用されている「6-sigma」または「Total Quality Control」などの一般的な品質改善プロセスもネットワーク品質に直接適用することができます。これらのプロセスのキー ポイントとなるのが、目標の特定、目標と結び付けられる結果の評価、および希望する目標を達成するのに必要な改善の実践です。IP テレフォニー の配備に関連する目標には、アベイラビリティ、音声品質、トラブルチケットの低減、変更管理の実施、および迅速な問題解決が考えられます。改善案が成果を収めるには、目標が評価可能であること、および組織をあげて達成可能な目標を設定し、その成果が得られるように最大限の努力をする必要があります。

コール データ レコードのレポートおよび課金

多くの組織では、CallManager のレポート機能を使用して、コール データ レコードを作成することになります。コール データ レコードは、次のような場合に使用されます。

• ロード共有 CallManager システム全体のロード バランシングの決定

• トラブルシューティング（理由コード）

• 内部課金

• 不正の検出（通常、サード パーティ製のアプリケーションが必要）

• PSTN の原価計算（通常、サード パーティ製のアプリケーションが必要）

コール データ レコードを蓄積するには、CallManager でコール データ レコードのレポート機能を有効にする必要があります（デフォルトではオフ）。データ レコードは、CallManager SQL データベースに保存されます。また、管理者はリアルタイム コール データ情報を収集するために、トレース機能を有効にすることもできます。ファイルは無制限に蓄積されるため、定期的にアーカイブしたり、削除したりすることが必要になります。ファイルは、CallManager から TFTP 経由でコピーしたり、スプレッドシート アプリケーションにインポートしたりすることができます。すべてのフィールドはコンマで区切ります。

通常、課金はサードパーティ製の課金（チャージバック用）を使用して行います。また、組織では、原価計算エンジンを購入して課金およびチャージバックの PSTN コストを見積もります。不正検出用のソフトウェアも入手できます。その場合、しきい値を設定して異常なコール量、定義した量を上回る営業時間外のコール、または異常に高いコール コストを判別します。

コール データ レコードには、次の基本情報が含まれています。

• コール レコード ID

• コール元のタイムスタンプと日付

• コール元の電話番号

• コール元の IP アドレス

• コール先の電話番号

• コール先の IP アドレス

• コール接続解除のタイムスタンプと日付

• 直接接続時間

• 接続解除モード

• ジッタ、遅延を含む、コール品質情報

コール データ レコード機能の設定、データ レコード フィールドの完全なリスト、理由コード、およびコール データ レコード タイプの詳細については、 http://www.cisco.com/warp/public/788/AVVID/ts_ccm_301_sec2.htm を参照してください。

スタッフ配属およびサポート モデル

IP テレフォニー をサポートするには、スタッフ配属およびサポート モデルを修正しなければならない場合があります。データ ネットワーク管理者、システム管理者、および Telecom Operations を配備して、IP テレフォニー ソリューションの全体をサポートします。要約すると、スタッフ配属要件は、専門知識レベル、サポート契約、および組織が実装しているツール オートメーションから構成される 1 要素です。とはいえ、組織は、IP テレフォニー ソリューションを運用するためのすべての要件を調べ、個人および管理グループの能力に基づいたリソース数を決定する必要があります。また、組織は、インスタンス リモート サポートまたは MAC 変更などの IP テレフォニー サポートの一部を外部委託する場合もあります。

表 6-15 は、IP テレフォニー の運用要件を見積る際に使用します。

運用サポート計画の文書化と承認

運用サポート計画を立案するプロセスの最終ステップとなるのが、運用サポート計画の文書化と承認です。その計画には、すべてのサポートの責務、関係者、レポート要件、予想されるサービス レベル、およびサービス レベル契約を含める必要があります。IP テレフォニー の生産準備および運用の最初の数ヶ月間に、運用サポート計画にいくつかの修正が行われることが予想されます。よって、初期配備期間では、修正および追加事項を提案するために毎週ミーティングを行うことを推奨します。

また、サービス レベル契約も運用サポート計画に含まれます。IP テレフォニー 配備に予想されるサービス レベル計画には、音声アベイラビリティ、音声品質、ネットワーク パフォーマンス、優先順位別の障害修復時間、および MAC サービス レベルの可能性が含まれます。

ネットワーク管理の機能領域

この項では、ISO ネットワーク管理モデルの各機能領域の概要を簡潔に説明します。

• 障害管理

• 構成管理

• 課金管理

• 性能管理

• 機密管理

障害管理

障害管理では、ネットワーク インフラのネットワーク要素で問題を検出します。ハードウェアおよびソフトウェアの問題は、ネットワーク デバイスの破壊または劣化の原因となります。NOC の従業員は、管理システムを使用してネットワーク要素で検出される障害を他の従業員に通知します。ネットワーク要素が正確に構成されていれば、システム メッセージおよび通知を管理システムに転送することができます。また、ネットワーク要素によってレポートされた障害の重大度に基づいて、ネットワーク アベイラビリティへの影響を最小限に抑えるように処置を講じることができます。障害管理を正確に実行することは、障害検出の効果とネットワーク関連の適時な問題解決を確実にするために必要です。

構成管理

構成管理では、構成ファイル、ソフトウェア、アドレス、およびネットワーク要素の詳細なインベントリ情報を管理します。最新の構成管理システムでは、ネットワーク アクティビティのうちのトラブルシューティングに要する時間を著しく短縮することができます。また、完全かつ詳細なインベントリ情報により、ネットワーク ロールアウトの計画および予算割り当ての段階で、非常に多くの価値をもっています。

課金管理

ユーザおよびアプリケーションのトラフィックがネットワークで増加するにつれ、組織はネットワーク リソースの使用状況を追跡することが重要になります。トラフィック プロファイルを徹底的に把握することによって、ネットワーク計画者は異なるアプリケーションに対して優先順位を付け、十分な帯域幅を割り当てることができます。遅延に影響されやすい、重要なアプリケーションには、正規ユーザのトラフィックよりも高い優先順位を付けて、時間および帯域幅の要件を満たす必要があります。

一般的に、ネットワーク要素から収集された課金データの範囲は、トラフィック統計の簡単なレコードから詳細なレコードにまで及びます。このデータは計画に使用したり、または内部および外部エンティティにチャージバックを導入する必要がある企業の課金システムへの入力として使用したりできます。

性能管理

性能管理では、IT インフラストラクチャの各種コンポーネントのパフォーマンス レベルを測定します。十分なパフォーマンス レベルは、インフラストラクチャ全体のネットワーク、システム、およびアプリケーション コンポーネントに応じて異なります。各種コンポーネントのパフォーマンス測定はきわめて重要です。パフォーマンスの測定は、まず特定のメトリックを定義し、その後、定期的にそれらのデータを収集して実行されます。

組織内で確立した、パフォーマンス目標またはサービス レベル契約（SLA）に対して、収集したパフォーマンス データを測定します。また、履歴に基づくパフォーマンス データも、ネットワーク要素およびエンド システムの通常のオペレーション特性と使用状況のベースラインとして役立ちます。現行の形式で集められたパフォーマンス データにより、ネットワーク エンジニアリングでインフラストラクチャの成長に対して効果的な計画を立てることができます。

機密管理

機密管理は、インフラストラクチャのリソースへのアクセスを制御するさまざまな局面に関係します。セキュリティ処置を実施して、許可されたユーザだけがネットワーク プラットフォームおよび機密のビジネス情報のアクセス権を持っていることを保証できます。セキュリティ プロトコルまたはセキュリティ製品のどのような技術評価を実行するにしても、その前にセキュリティ ポリシーを策定する必要があります。また、提案されたセキュリティ機能またはセキュリティ ソリューションは、セキュリティ ポリシーに要約されている要件を満たす必要があります。セキュリティ機能の実装を徹底的にテストした後で、その機能を実際に配備します。

ネットワーク管理ソリューション

CiscoWorks2000

CiscoWorks2000の製品ラインには、2 つの重要な管理領域（ワイドエリアおよびローカルエリアの交換回線ネットワーク管理）に重点を置いたネットワーク管理ソリューションがあります。これらの各管理領域では、新規または既存の Cisco アプリケーションが Web ベースの拡張管理ソリューションに統合されます。

インターネット テクノロジーを使用方法および統合方法については、 http://www.cisco.com/warp/public/cc/pd/wr2k/ent/tech/bmi_wi.htm を参照してください。

CiscoWorks2000 製品ラインには、次にリストされたソリューションが含まれています。これらの製品の詳細を表示するには、 http://www.cisco.com/warp/public/cc/pd/wr2k にアクセスしてください。

• VPN/Security Management Solution

–VPN Monitor

–Resource Manager Essentials

–CiscoView

–Cisco Secure Policy Manager

• LAN Management Solution

–Campus Manager

–Device Fault Manager

–Content Flow Monitor

–CiscoView

–Resource Manager Essentials

• Routed WAN Management Solution

–Access Control List Manager

–Internetwork Performance Monitor

–CiscoView

–Resource Manager Essentials

• Service Management Solution

–Service Level Manager

–Management Engine 1100

–CiscoView

• Campus Bundle for AIX/HP-UX

上述のソリューションに加えて、CiscoWorks2000 製品ラインには次の拡張アプリケーションも用意されています。

• User Registration Tool（URT）

• CiscoWorks2000 Voice Manager（CVM）

表 6-23 では、使用可能なネットワーク管理ツール、および各ツールにサポートされている IP テレフォニー コンポーネントについて要約しています。

サードパーティ製のアプリケーション

ネットワーク管理プラットフォーム

ネットワーク管理プラットフォームによって、ネットワーク デバイスが検出され、それらのデバイスが情報用にポールされます。一般的なネットワーク管理プラットフォームには、次のものがあります。

• HP OpenView Network Node Manager

• Computer Associates Unicenter

• Tivoli NetView

• Aprisma Spectrum

各ネットワーク デバイスは、ネットワーク管理プラットフォームのコンソールでグラフィカルな要素を使用して表されます。グラフィカルな要素の各種カラーは、ネットワーク デバイスの現在の運用ステータスを示します。ネットワーク デバイスを構成して、簡易ネットワーク管理プロトコル（SNMP）と呼ばれる通知をネットワーク管理プラットフォームに送信するようにできます。通知を受信すると、ネットワーク デバイスを表すグラフィカルな要素のカラーは、受信した通知の重大度に応じて変わります。通知は通常、イベントと呼ばれ、ログ ファイルに書き込まれます。

特に重要なのは、最も新しいシスコ管理情報ベース（MIB）ファイルを SNMP プラットフォームにロードし、シスコ デバイスからの各種アラートが正確に解釈されていることを確認することです。シスコは、Web サイトcisco.com に各種ネットワーク デバイスを管理するための MIB ファイルを公開しています。そのサイトの URL は、 http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml です。

イベント相関ツール/Manager of Managers（MOM）

ネットワーク要素の数およびネットワーク問題の煩雑性の増加にともない、SYSLOG、TRAP、ログ ファイルなどの各種ネットワーク イベントを相関できるイベント管理システムを検討したい場合があります。イベント管理システムを支援するこのアーキテクチャは、Manager of Managers（MOM）とも呼ばれます。それは、ネットワーク上の他のネットワーク管理システム ステーションから情報を集め、ネットワーク問題の検出および診断に際してより予防的および効果的に NOC を表示できるためです。イベントの優先順位の設定と抑制により、ネットワーク運用担当者は重要なネットワーク イベントに専念することができます。現在、相関ツールとしては、次のものが使用できます。

• Cisco InfoCenter

• MicroMuse Netcool

• Veritas Nerve Center

• Smarts In Charge

• HP OpenView ECS

• Cisco Device Fault Manger/Voice Health Monitor

• Aprisma Spectrum

パフォーマンス ツール

さまざまなソリューション エンタープライズ環境のパフォーマンス管理のニーズに焦点をあて、販売されています。これらのシステムを使用すると、ネットワーク デバイスおよびネットワーク サーバからデータの収集、保存、およびプレゼンテーションを行うことができます。大部分の製品の Web ベースのインターフェイスにより、企業内のあらゆる場所からパフォーマンス データにアクセスできます。一般的によく配備されるパフォーマンス管理ソリューションには、次のものがあります。

• CiscoWorks2000 Internetwork Performance Monitor（IPM）

http://www.cisco.com/warp/public/cc/pd/wr2k/nemo/index.shtml

• Concord Network Health

http://www.concord.com/solutions/ent/

• InfoVista VistaViews

http://www.infovista.com/Pages/products/intr_vv.html

• SAS IT Service Vision

http://www.sas.com/products/itsv/index.html

• Trinagy TREND

http://www.trinagy.com/products/trend.asp

• MultiRouter Traffic Grapher（MRTG）

http://mrtg.hdl.com/mrtg.html

ネットワーク管理アーキテクチャ

ネットワーク管理システムの実装は、明確なアーキテクチャの存在にかかっています。アーキテクチャを持つシステムを適切に実装することが、配備の成功につながります。ネットワーク管理アーキテクチャとは、一定の運用機能を実行するためのユーザ要件、プロセス、およびツールを集めたものです。ネットワーキング テクノロジーの数および煩雑性の増加に伴い、実装の早期段階でのネットワーク管理アーキテクチャのコンポーネントを十分に理解することが重要です（シスコシステムズがデータ ネットワーク管理で必要な最小限のソリューションと考える参照アーキテクチャについては、「NMS リファレンス アーキテクチャ」を参照）。

ネットワーク管理システムを使用して、ネットワーク インフラストラクチャの運用に関連する管理機能を実行できます。システム実装の最初のステップは、管理ツールによって処理する必要がある機能の範囲、および明確な定義を設定することです。

ツールからの予測される入力/出力と同様に、管理する必要がある特定のネットワークの要素、およびテクノロジーを確認すると、能率的かつ効果的なネットワーク管理システムを構築する機会が増えることにつながります。

ユーザ要件を収集することは、新しい管理システムがエンド ユーザのニーズを満たし、エンド ユーザがネットワーク関連の作業を完了できるように支援することを確認することが重要です。また、組織内の複数のユーザ グループ間の通信を円滑にするには、明確なプロセスを確認し、定義する必要があります。

管理ツールの選択基準

ネットワーク管理ツールは、IT インフラストラクチャのコンポーネントを管理する数多くのベンダーによって提供されています。一般的に、機器ベンダーはベンダー特定のデバイスを管理する要素管理システム（EMS）を提供します。EMS に対して特定のベンダーの機器を使用してシームレスに作業することを期待できます。

さまざまなべンダーのどの汎用ネットワーク管理プラットフォームによっても、ベンダー特定の EMS で使用できる機能が増強されます。また、ネットワーク管理プラットフォームでは、ベンダー指定の管理情報ベースをサポートするので、複数のベンダーの機器を相互作用できます。

要素管理システムおよびネットワーク管理プラットフォームのオペレーティング システム（OS）の選択は、複数の内部および外部の要素に依存します。多くの場合、特定のオペレーティング システムに関する組織内の専門知識は、システムのバックアップおよび復元などの日常の保守作業を実行する際に必要となります。

ソフトウェア リリースのスケジュールおよび各種 OS プラットフォームのサポートについては、機器ベンダーによって異なります。ネットワーク要素を管理するツールを使用しないでネットワーク要素を配備するリスクを最小限に抑えるには、OS プラットフォームを十分に理解することが重要です。

統合

アプリケーションの構築に Web テクノロジーが採用されるにつれ、NMS ツールの統合に多数の新しい、革新的なオプションが出現しました。現在では、XML（Extensible Markup Language）、LDAP（Lightweight Directory Access Protocol）、およびその他の新しいデータベース テクノロジー等が、オープン標準となっています。

CiscoWorks2000 と NMS プラットフォームの統合の詳細については、 http://www.cisco.com/warp/public/cc/pd/wr2k/tech/cwnms_tb.htm を参照してください。

インターネット テクノロジーを使用して管理ツールと情報を統合する方法については、 http://www.cisco.com/warp/public/cc/pd/wr2k/ent/tech/bmi_wi.htm を参照してください。

ネットワーク管理システムのハイ アベイラビリティ

フォールト トレランス、またはソフトウェア、ハードウェア、およびネットワークの障害からの自動的回復能力は、ネットワーク管理システムのアベイラビリティを向上させるために重要になります。各オペレーティング システムとベンダーには、システムのハイ アベイラビリティを保証するための明確な実装方法があります。多くの場合、ディスクのミラーリングおよびクラスタリングを使用して、アプリケーションの持続的なサービス、およびデータ アベイラビリティを実現します。ホットスタンバイ システムでは、メイン システムからハートビート メッセージがないことを検出すると、失敗したシステムのタスクが自動的に再開されます。

アベイラビリティの高い管理システムを必要としている組織は、組織環境下での管理システムの実現可能性を理解するために、システム、ソフトウェア、および機器のベンダーと緊密に共同作業を行う必要があります。

ネットワークの管理情報ベースの要件

ネットワーク要素とエンド システムは、複数の管理機能をサポートすることで、リモート管理可能性を実現します。ネットワーク要素、またはエンド システムで最もよく使用される管理機能の 1 つが SNMP です。ネットワーク管理システムでは、管理コマンドを発行して、SNMP を使用してネットワーク要素とエンド システムの管理タスクおよびトラブルシューティング タスクをリモートで実行できます。リモートで管理することができるので、組織内で IT インフラストラクチャを稼動するコストが大幅に低減されます。

一般的には、HP OpenView Network Node Manager、Tivoli NetView などの SNMP プラットフォームを使用して、ネットワークからの SNMP データを管理します。プラットフォームでネットワークからのベンダー特有のデータおよびメッセージを正確に解釈するには、ベンダーの MIB をシステムにロードする必要があります。

また、特に重要であるのは、最新の Cisco MIB ファイルを SNMP プラットフォームにロードして、SNMP プラットフォームで Cisco デバイスすべてを管理できることを確認することです。正確な MIB がすべてロードされていない場合には、SNMP プラットフォームによって、処理されなかったメッセージを示すエラーがレポートされます。

表 6-16 は、Cisco CallManagerを管理するためにロードする必要がある MIB のリストを示します。表の中の最初の 6 つの MIB は、CallManager の MIB のロード時に CISCO-CCM-MIB.my、またはシステムでエラーを生成される前に、ロードする必要があります。

表 6-17 は、Cisco デバイスが SNMP プラットフォームによって管理できることを確認するのに役立つ追加 MIB のリストを示します。

システムログ ベースの要件

システム メッセージ ロギング（システム ログ）とは、ネットワーク要素を管理する付加的な方法です。システムログは、ネットワークの状態を判断したり、問題となる前に問題の先を見越して認識したりするのに最適な方法です。システム メッセージにより、デバイス レベル、プロトコル レベル、およびインターフェイス レベルでのデバイスの運用状態に関する情報が提供されます。

ネットワーク管理システムを効率にするには、必ず、システムログを設定する必要があります。各システム メッセージは重大度レベル別に定義され、発生した問題のテキスト説明が含まれます。重大度が最高のメッセージを受け取ると、ネットワーク オペレーションによって是正処置が行われます。重大度レベルのコードは、0 ～ 7 までの 1 桁の数値です。その数値が低いほど、ネットワークの状況はより深刻になります。

ネットワークのすべての Cisco デバイスには、システム メッセージ（IP Phoneの例外を含む）がサポートされています。それらのデバイスは、デバイスのデフォルト システム メッセージ（通常は レベル 6）を CiscoWorks2000 サーバに送信するように設定する必要があります。

容易な、管理可能なシステムログの実装を確実なものにするには、Cisco の Network Analysis Toolkit（NATkit）、その他の UNIX サーバなどの追加 システムログ サーバで CiscoWorks2000 をリモートでマウントして、システムログ ファイルにアクセスします。

ネットワーク タイム プロトコル

NTP（ネットワーク タイム プロトコル）により、ネットワーク化されたルータ、サーバ、およびその他のデバイスの共通タイム ベースが設定されます。タイムの同期により、特定のイベントに対するシステムログと Cisco IOS デバッグ出力を相互に関係付けることができます。たとえば、特定ユーザのコール レコードを 1 ミリ秒以内で見つけることができます。NTP とは、RFC-1305 に文書化された UDP/TCP（User Datagram Protocol/Transmission Control Protocol）ベースのプロトコルです。

通常、NTP ネットワークではタイム サーバに接続されたラジオ クロックまたはアトミック クロックなどの信頼性のあるタイム ソースからネットワーク タイムを取得します。その後、NTP はネットワーク全体にそのタイムを配布します。NTP は非常に効果的ですが、2 つのマシンを互いに 1 ミリ秒以内に同期化するには、わずか 1 パケット/分にする必要があります。経済的なタイム ソースとしては、イーサネットに接続した GPS（全方位測位システム）レシーバがあります。

システムログおよび SNMP イベントの相関を容易にするために、ネットワークに Cisco IOS の NTP 機能およびサービス タイム スタンプ機能を設定することを強く推奨します。

NTP の説明については、 http://www.eecis.udel.edu/~ntp/ を参照してください。

NTP を組み込む Cisco IOS の構成例については、 http://www.cisco.com/univercd/cc/td/doc/product/software/ios11/cbook/csysmgmt.htm#31645 を参照してください。

ネットワーク上での UDP メッセージのロードを減らし、確実に秩序正しくプロトコルを保守するにためには、プロトコルをルーティング プロトコルと非常によく似たクライアント サーバ モードを使用して、NTP を階層形式で設定する必要があります。たとえば、次のように設定します。

• メイン NTP サーバをコア ネットワーク デバイスのソースにする

• コア デバイスを分散デバイスのソースにする

• 分散デバイスをアクセス層デバイスの NTP ソースにする

さらに、NTP プロトコルは、3 つの NTP ソースをまとめて同位にし、クロックをネットワーク エレクトロニクス（および NMS）にまで設定すると最適化されます。現在では、NTP クライアントおよびサーバ モードは、サーバ イベントの相関が必要な場合、多くの UNIX バリエーションによって、サポートされます。

Voice over IP ネットワークと要素層の管理

この項では、VoIP（Voice over IP）管理を含むネットワーク管理システムで各種ツールを使用する方法の特定の例について説明します。また、この項では、次のネットワークおよび要素管理の製品に重点を置いて説明します。

• Resource Manager Essentials 3.1

• Campus Manager 3.0

• Internetwork Performance Monitor 2.2

「CallManager を使用したアプリケーション層の管理」では、Cisco CallManagerを使用したアプリケーションと音声管理について取り上げています。しかし、最新情報を確認するには、まず、実装の計画段階で特定の製品のリリース ノートを参照してください。

障害管理

障害管理は、インターフェイス レベル、デバイス レベル、およびプロトコル レベルで障害を確実に適時に検出するのに必要です。Cisco ルータ、LAN スイッチ、および CallManager で構成されているネットワーク上で障害を検出する方法は、いくつかあります。最も一般的な方法は、システムログ メッセージと SNMP トラップです。ほとんどの Cisco デバイスでは、システムログ メッセージをシステムログ サーバに送信することができます。システムログ メッセージとは、基本的にルータやスイッチおよび CallManager からの、Cisco デバイスの状態を説明するシステム メッセージです。デバイスによって転送された SNMP トラップにより、インターフェイスが増加または減少するかどうかなどについてデバイス障害の状態が通知されます。次の小項目では、ネットワークのネットワーク層を管理するためにシステムログと SNMP を使用する方法について説明します。CiscoWorks2000 は、この作業を容易にするのに役立ちます。

CiscoWorks2000 の基本要件

CiscoWorks2000 を確実に正常にインストールするために最も重要な事項は、次の 2 つです。

• 適切なハードウェア

• 正確なインストール順序

（注） NT インストールでは、インストール順序が特に重要です。

スイッチおよびルータの基本構成要件

CiscoWorks2000 製品を使用してスイッチとルータが機能できるように、スイッチとルータには基本構成要件が必要です。SNMP とシステムログは、CiscoWorks2000 の機能を完全に使用できるように設定する必要があります。

Integrated Communications System 7750（ICS 7750）では、ICSconfig を使用して SNMP とシステムログを設定します。したがって、ICS 7750 システムの CLI（コマンドライン インターフェイス）を使用して手作業で変更することは推奨しません。

（注） 実装時に、Catalyst スイッチに追加でレイヤ 3 カードおよびその他の特殊用途のラインカードを組み込む場合、組み込まれたすべてのカードはスイッチ全体と通信するために、基本構成に含める必要があります。

Catalyst スイッチの基本構成

ルータの基本構成

障害管理でのシステムログの使用

CiscoWorks2000 Resource Manager Essentials（Essentials）製品を使用して、ネットワーク エラーおよび VoIP エラーの具体的な検索に対して、システムログ ファイルの入手およびカスタム日報の作成を行うことができます。最も効率的なネットワーク管理の実装は、毎日システムログ ファイルを確認することです。通常、システムログ メッセージは NOC 担当者によって通知され、さらに処置を講じるために適切なレベルにエスカレートされます。

VoIP のシステムログ日報のカスタマイズ

図 6-2 では、VoIP のカスタマイズされたシステムログ日報を示します。このタイプのレポートは、24 時間のシステムログ レポートとして、Web ブラウザから CiscoWorks2000 Essentials で毎日アクセスする必要があります。環境に基づくレポートには、さらにメッセージを追加することができます。

図 6-2 Define Custom Report ウィンドウ

表 6-18 では、図 6-2 に示すカスタム レポートの定義に使用するコール管理サブシステムのエラー メッセージのリストを示します。

（注） システム メッセージは、Cisco IOS ソフトウェアの各バージョンの Web サイトで公開されます。http://www.cisco.com/univercd/cc/td/doc/product/software/ の Cisco IOS ソフトウェア構成マニュアルを参照してください。

図 6-3 に示すコール管理のエラー レポートを選択すると、カスタマイズされたレポートにより、音声システムのエラー メッセージ（ 表 6-18 に示す）のシステムログが解析されます。シスコシステムズでは、運用担当者がこのレポートを毎日実行し、エンジニアリングにレポートすることを推奨します。

図 6-3 Syslog 24-hour Report ウィンドウ

SNMP ポーリングおよび SNMP トラップの使用

SNMP を使用して構成された Cisco デバイスの運用状態を確認するには、そのデバイスをポーリングします。さらに、イベントの発生時にそのデバイスを使用して、トラップを管理ステーションに送信できます。SNMP トラップを送信できるようにネットワーク デバイスを構成することで、イベントを迅速に検出できます。その結果、ユーザはネットワークで障害状態および予測される問題を診断して判別できます。Cisco CallManager 3.x をポーリングして、次の内容を含む多くの各種ステータス情報を検出できます。

• 登録された電話数

• トランク ステータス

• ゲートウェイ ステータス

特定の MIB をポーリングしてしきい値を設定する方法については、SNMP プラットフォームのマニュアルを参照してください。シスコのハイ アベイラビリティ サービス チームには、次のような特定のネットワークについて MIB 推奨事項の追加マニュアルがあります。

• Open Shortest Path First（OSPF）

• Asynchronous Transfer Mode（ATM）

• Integrated Services Digital Network（ISDN）

上述の MIB 推奨事項については、シスコシステムズのエンジニアまたは販売担当者にお尋ねください。

シスコの Device Fault Manager の使用

CiscoWorks2000 Device Fault Manager（DFM）により、Cisco デバイスの障害をリアルタイムで詳しく分析することができます。DFM の機能は、次のとおりです。

• さまざまな障害状況について Cisco ベースのネットワークを監視する

• 障害状況を分析する

• 注意が必要な問題が発生したときに「高度な Cisco トラップ」を送信して、ユーザに通知する

次のように Cisco トラップを送信するために DFM を設定できます。

• ネットワークにインストールしたその他のマルチデバイス、マルチベンダーのイベント管理システムへの転送

• 電子メール/ポケットベルのゲートウェイへの送信

• DFM アラーム ウィンドウでの表示

図 6-4 は、DFM Monitoring Console ウィンドウを示します。

図 6-4 DFM Monitoring Console ウィンドウ ñ イベント メッセージの説明

（注） DFM Monitoring Console ウィンドウを初めて開いた場合には、右側のペインには何も表示されません。特定のイベント メッセージの説明を表示するには、上述の例で示したように DFM 管理対象のデバイスのリストからデバイス タイプを選んでから、デバイスを選択します。

構成ファイルの管理

ルータ、スイッチなどのネットワーク デバイスでは、構成ファイルの変更がよく行われます。重大な停止の原因となる構成ミスを防止するには、変更管理手順を整えておくことが重要です。変更中の障害に備えて、構成ファイルのバックアップ バージョンを用意しておく必要があります。また、既存の構成ファイルに変更した内容を追跡することも重要です。

変更要約レポートは、構成ファイルに変更した内容の詳細情報で構成されています。詳細情報には、ユーザ名、時間、および変更内容が含まれます。このレポートは、変更内容およびアカウンタビリティを追跡するのに役立ちます。CiscoWorks2000 Essentials で Web ベースの構成管理ツールを使用可能にすると、構成ファイルを管理するための数多くの作業を完全に自動化することができます。構成管理ツールを使用すると、次の作業を実行できます。

• Essentials の構成アーカイブから構成ファイルをデバイス、または複数のデバイスにプッシュする

• デバイスから構成ファイルを Essentials アーカイブにプルする

• アーカイブから最新の構成を抽出して、その構成をファイルに書き込む

• ファイルから構成をインポートして、その構成をデバイスにプッシュする

• Essentials アーカイブにある最新の 2 つの構成を比較する

• アーカイブから特定の日付またはバージョンよりも古い構成を削除する

• 始動構成を実行中の構成にコピーする

図 6-5 は、IP Phoneに接続した Cisco Catalyst スイッチの構成レポートの一例を示します。

図 6-5 デバイスの構成要約レポートの例

ソフトウェアの管理

ネットワーク デバイスに対するソフトウェアのアップグレードは、時間のかかる困難な作業です。ルータまたは LAN スイッチをアップグレードするには、異なるソフトウェア イメージを使用してデバイスを正常にロードできるようにする前に、複数の関連作業が必要となります。第 1 のステップとして、ベンダーのリリース ノートを確認し、その後、すべてのハードウェア要件およびソフトウェア依存関係が考慮されていることを確認します。

第 2 のステップとして、ベンダーの Web サイトまたは他の配布メカニズムから正確なイメージをダウンロードします。アップグレードがネットワーク サービスに影響しないことを確認するには、変更管理プロセスを実行する必要があります。シスコは、ソフトウェア アップグレードの各種作業を自動化する管理ツールを作成し、ソフトウェアのアップグレード プロセスを大幅に簡素化しています。CiscoWorks2000 の Software Image Management ツール（SWIM）により、ソフトウェア管理に関連する各種作業が自動化されます。

図 6-6 は、CiscoWorks2000 Essentials におけるソフトウェアの Image Library Summary ウィンドウの一例を示します。

図 6-6 Image Library Summary ウィンドウ

課金管理

課金管理には、多くの意味があります。従来のネットワーキング環境では、課金は一般的にキャパシティ計画または部門別チャージバックの目的で、IP ソースと送信先アドレスに基づいたトラフィック フローを追跡することを意味します。音声の分野では、課金は一般的にコールされた番号、コール時間などの情報を提供する CDR（コール詳細レコード）を意味します。コール詳細レコードの詳細については、 http://www.cisco.com/warp/public/788/AVVID/ts_ccm_301_sec7.htm を参照してください。

次の小項目では、いくつかの課金管理ツールについて簡単に要約します。

Cisco NetFlow および IP Acconting

適切な課金管理に向けての最初のステップは、すべての重要なネットワーク リソースの使用状況を測定することです。あらゆる SLA（サービスレベル契約）に基づく義務を定義する実用的な方法と SLA の条件外の動作に対する明確な結果を提示するため、従量制課金システムは SLA の最も重要な部分です。

Cisco NetFlow および Cisco IP Accounting は、ネットワーク リソース使用状況を測定するツールです。これらのツールを使用して収集されたデータを分析すると、現在の使用状況パターンを観察することができます。データは、プローブまたは Cisco NetFlow を使用して収集できます。Network Data Analyzer アプリケーションをインストールした Cisco NetFlow FlowCollector により、ルータおよび Catalyst スイッチからのデータが収集および分析されます。また、cflowd などのシェアウェア アプリケーションを使用して、NetFlow データ収集することもできます。

cflowd の詳細については、 http://www.caida.org/tools/measurement/cflowd/ を参照してください。

リソースの使用状況を継続して測定すると、継続した正確かつ適切なリソースにアクセスするために使用する情報だけでなく、課金情報も生成することができます。一般的によく配備される一部の課金管理ソリューションには、次のものがあります。

• Cisco Network Data Analyzer

• Cisco NetFlow Collector

• Apogee Networks

http://www.apogeenetworks.com

• XACCT Technologies, Inc.

http://www.xacct.com

• Telemate

http://www.telemate.net

NetFlow の有効化およびデータ収集方法

NetFlow（ネットワーク フロー）とは、入力側の測定技術です。これにより、ネットワークの計画、モニタリング、および課金のアプリケーションに必要なデータを収集できます。NetFlow は、企業のお客様のサービス プロバイダーまたは WAN アクセス ルータのエッジおよび集約ルータ インターフェイスに配備する必要があります。

シスコシステムズは、これらの戦略的に配置したルータでは、NetFlow サービスを含む NetFlow 配備の計画を慎重に進めることを推奨します。NetFlow は、ネットワークのルータごとに配備するのではなく、増加的（インターフェイスごとに）かつ戦略的（適切なルータ）に配備します。シスコ代理店の担当者はお客様と共同に作業して、お客様のトラフィック フロー パターン、ネットワーク トポロジ、およびアーキテクチャに基づいて NetFlow を有効にする重要なルーター、および重要なインターフェイスを決定します。

配備における重要な考慮事項には、次の内容が含まれます。

• NetFlow サービスは、エッジ メータリングおよびアクセス リスト パフォーマンス加速ツールとして活用し、CPU 使用率が高い状態で稼動するホット コア/バックボーン ルータまたはルータで有効にしません。

• アプリケーション主導のデータ収集の要件を把握します。課金アプリケーションには、ルータ フロー情報の発信と着信だけが必要ですが、モニタリング アプリケーションには、さらに包括的な（データを中心とした）エンドツーエンド ビューが必要です。

• フロー収集方法におけるネットワーク トポロジとルーティング ポリシーの影響を理解します。たとえば、トラフィックの発信または着信となる重要な集約ルータで NetFlow を有効にし、同じフロー情報の重複したビューを提供するバックボーン ルータまたは中継ルータでは NetFlow を有効にしないことで、重複したフローの収集を防止します。

• 中継キャリア事業（ネットワークに発信でも着信でもないトラフィックを搬送することを意味する）のサービス プロバイダーは、課金の目的でネットワーク リソースの中継トラフィックの使用状況を測定するために、NetFlow エクスポート データを使用する場合があります。

IP Accounting の構成

Cisco IP Accounting サポートにより、基本的な IP アカウンティング機能が提供されます。IP アカウンティングを使用可能にすると、送信元および送信先の IP アドレス形式で Cisco IOS ソフトウェアを使用して、交換されたバイト数とパケット数を確認できます。送信側の中継 IP トラフィックだけが測定されます。ソフトウェアによって、またはソフトウェアでの着信によって発生したトラフィックは、アカウンティング統計には含まれません。正確なアカウンティング合計を維持するには、ソフトウェアでアクティブ データベースとチェックポイント データベースの 2 つのデータベースを維持します。

Cisco IP Accounting サポートにより、IP アクセス リスト上の制限により通過できない IP トラフィックを示す情報も提供されます。IP アクセス リストに違反する IP 送信元アドレスを特定すると、セキュリティ違反となっている可能性のある試みが通知されます。また、データによって、IP アクセス リスト設定を確認する必要があることが示されます。この機能をユーザに対して使用可能にするには、 ip accouting access-violations コマンドを使用して、アクセス リスト違反の IP アカウンティングを使用可能にします。その後、ユーザは送信元と送信先の対のアクセス リストに対してセキュリティ違反を試みた 1 つのソースからのバイト数とパケット数が表示されます。デフォルトでは、IP アカウンティングには、アクセス リストを通過してルート指定されたパケット数が表示されます。

IP アカウンティングを使用可能にするには、インターフェイス設定モードで次の各インターフェイスのコマンドのいずれか 1 つを使用します。

その他の IP アカウンティング機能を設定するには、グローバル構成モードで次のコマンドのうちの一つ、または複数個を使用します。

性能管理

デバイスでサポートされる SNMP 管理プロトコルを使用して、ルータおよび LAN スイッチのパフォーマンスを分析することができます。各種パフォーマンス メトリックは、シスコ特定の管理情報ベース（MIB）と同様に標準プロトコルに定義されます。本書では、性能管理の詳細については説明していません。最小限、ルータおよびスイッチのパフォーマンス インジケータは、デバイス レベル、インターフェイス レベル、およびプロトコル レベルで収集する必要があります。ルータのデバイス レベルのパフォーマンス メトリックには、次の内容が含まれます。

• CPU 使用率

• メモリ使用率

• システム バッファ

IP テレフォニー 環境の性能管理のニーズに対して、多様なソリューションが市販されています。これらのシステムを使用して、ネットワーク デバイスおよびネットワーク サーバからデータの収集、保存、およびプレゼンテーションを行うことができます。次の性能管理ソリューションは、一般的によく配備されます。

• Concord Network Health

http://www.concord.com

• InfoVista VistaView

http://www.infovista.com

また、SNMP プラットフォームでは、詳細分析としきい値のモニタリングを行うために特定の MIB オブジェクト識別子（OID）をポーリングおよび保存することもできます。お客様独自の環境に適切なパフォーマンス OID を特定するために、お客様がシスコと共同作業を行うことを強く推奨します。また、現在の数多くの NMS 製品のデフォルト値が単に開始点であり、すべての状況に適切であるとは限らない場合があるため、しきい値についてもシスコと共同で見なおす必要があります。

• ネットワーク モニタリングおよびイベント相関のガイドラインについては、 http://www.cisco.com/warp/public/cc/pd/wr2k/tech/cnm_rg.pdf を参照してください。

• Cisco デバイス パフォーマンスの参考資料の購入については、 http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=1578701805&vm= にアクセスしてください。

音声品質メトリック

VoIP は、ネットワーク動作の影響を受けやすく、一般のユーザには受け入れられない程度にまで音声アプリケーションが劣化することがあります。音声アプリケーションに影響を及ぼすネットワーク動作には、次のものがあります。

• 遅延：ネットワークのポイント間移動に要する時間数。遅延は、一方向またはラウンドトリップのいずれかで測定できます。一方向の遅延の計算には、高価かつ高度なテスト ギアが必要であり、予算以上にコストがかかる上、ほとんどの企業のお客様の予算と専門知識を越えています。一方、ラウンドトリップ遅延の測定は容易であり、必要な機器もより安価です。

一方向の遅延を測定するのに十分な方法は、ラウンドトリップ遅延を測定してその結果を 2 で割ります。一般的に、VoIP ではコールの品質が受け入れ不可能になる約 150 ミリ秒までの遅延を許容できます。

• ジッタ：ポイント間の時間の経過に伴う遅延の変化。VoIP コールで伝送の遅延があまりにも著しく変化する場合、コールの品質がかなり劣化しています。ネットワークで許容可能なジッタ量は、音声パスのネットワーク機器にあるジッタ バッファ容量の影響を受けます。通常、ジッタ バッファの容量が大きいほど、ネットワークでのジッタの影響が少なくなります。

• パケット損失：音声アプリケーションが深刻に劣化する、データ パスに沿ったパケットの損失。

VoIP アプリケーションを配備する前に、音声アプリケーションが動作するかどうかを判断するために、データ ネットワーク上での遅延、ジッタ、およびパケット損失を評価することが非常に重要です。さらに、ジッタ、遅延、パケット損失の測定値は、正確な設計、データ ネットワーク機器でのトラフィックの優先順位付けとバッファ パラメータの設定に役立ちます。

サービス保証エージェントとラウンドトリップ時間モニタ

サービス保証エージェントとラウンドトリップ時間モニタ（RTTMON）MIB は Cisco IOS の機能です。これにより、データ ネットワークでテストを行い、遅延、ジッタ、およびパケットロスの統計情報を収集できます。

Internet Performance Monitor（IPM）はCisco ネットワーク管理アプリケーションであり、Cisco IOS 機能を設定し、RTR および RTTMON データを監視できます。また、RTR および RTTMON の Cisco IOS 機能を使用して、カスタマー エンド ステーションまたは IP Phoneのシミュレーションを行うためのエージェントとして小規模 Cisco IOS ルータを配備し、遅延、ジッタ、およびパケット損失を測定できます。そのルータは、遅延プローブまたはジッタ プローブと呼ばれます。さらに、RMON アラームおよびイベントのトリガーを使用して、遅延プローブまたはジッタ プローブを構成し、ベースライン値を決定した後にネットワークをモニタリングできます。これにより、遅延プローブまたはジッタ プローブで規定の遅延およびジッタのサービス レベルのネットワークをモニタリングし、しきい値を超えると、NMS ステーションに警告できます。

Cisco SAA のジッタ プローブでのジッタ計算

この項では、Cisco IOS での Cisco SAA の遅延プローブまたはジッタ プローブのジッタ、遅延、およびパケット損失を計算する方法を示します。計算は、送信された連続したパケットのタイム スタンプの送信および受信に基づいて行われます。

上述の 2 つのパケットの例の場合には、次のようになります。

• 送信元から送信先までのジッタ（JitterSD）=（T6-T2）-（T5-T1）

• 送信先から送信元までのジッタ（JitterDS）=（T8-T4）-（T7-T3）

ジッタは、2 つの連続したパケットごとのタイム スタンプを使用して計算されます。たとえば、次のようになります。

送信元から送信先までのジッタ（JitterSD）=（T6-T2）-（T5-T1）

送信元から送信先までのジッタ（JitterSD）=（82ms - 20ms）-（60ms - 0ms）= 2 ミリ秒プラスのジッタ SD

送信先から送信元までのジッタ（JitterDS）=（T8-T4）-（T7-T3）

送信先から送信元までのジッタ（JitterDS）=（126ms - 60ms）-（104ms - 40ms）= 2 ミリ秒プラスのジッタ DS

エコーまたはジッタのエージェント ルータの配備

Cisco 17xx（またはそれ以降）のルータと Cisco IOS バージョン 12.05T（またはそれ以降のバージョン）を配備して、Cisco IOS サービス保証エージェント機能を設定することによって、遅延およびジッタを測定できます。エンドツーエンド接続に統計情報を提供するために、ホストに並行してキャンパス ネットワークにルータを配置する必要があります。ネットワークの音声パスをできる限り測定するのは、実用的ではありません。したがって、標準的な音声パスの統計サンプリングを提供するために、標準的なホストの場所にプローブを配置する必要があります。例には次のものがあります。

• ローカル キャンパス間のパス

• 384KB のフレームリレー回線を経由するローカル キャンパスとリモート キャンパス間のパス

• 非同期転送モードの専用仮想回線（AMT PVC）を経由するローカル キャンパスとリモート キャンパス間

FXS ステーション ポートを使用して Cisco ルータに接続された従来の電話を使用した VoIP 配備の場合、その電話の接続先のルータが遅延プローブまたはジッタ プローブとして機能します。そのように配備すると、プローブによってルータに統計情報が収集され、SNMP MIB テーブルが読み込まれます。その後、Cisco IPM アプリケーション、コマンドライン、または SNMP ポーリング ツールを使用して、データを処理できます。さらに、ベースライン値が設定された後、遅延、ジッタ、およびパケット損失のしきい値を超える場合に、NMS ステーションにアラートを送信するように、RTR を設定することができます。

音声コールのシミュレーション

テスト メカニズムとして SAA を使用するメリットの 1 つは、音声コールのシミュレーションを実行できることです。たとえば、標準的な Ｇ.711 音声コールは、次の内容に従います。

• RTP/UDP ポート 14384 以上を使用する

• 速度を約 64KB/s にする

G.711 音声コールは、次に説明するように SAA の遅延プローブまたはジッタ プローブを設定することで、シミュレーションを実行できます。

ジッタ オペレーションでは、20 秒間で 64KB/秒の速度を提供するために次の内容に従う必要があります。

• 要求を RTP/UDP ポート番号 14384 に送信する

• 492 バイトのパケット（480 ペイロード と 12 バイトの RTP ヘッダー サイズ）と 28 バイト（IP と UDP）を送信する

• 各周波数サイクルで 1000 パケットを送信する

• 次の周波数サイクルを開始する前に、20 秒間で 20 ミリ秒ずつ各パケットを送信し、40 秒間スリープする

その後、ルータの設定が次のように表示されます。

（注） request-data-size では IP および UDP が考慮されません。つまり、ルータによって IP および UDP が自動的に内部サイズに追加されます。

図 6-7 は、60 秒ごとに 20 秒間の音声コールのシミュレーションを実行して、双方向の遅延、パケット損失、およびジッタを記録するために設定されたルータを示します。この例の遅延計算はラウンドトリップ時間となるため、一方向の遅延を求めるには、その時間を 2 で割ります。

図 6-7 遅延プローブまたはジッタ プローブの配備例

遅延プローブまたはジッタ プローブの配備例

サンプル データの収集

MIB テーブルのポーリング

遅延プローブまたはジッタ プローブは、後に SNMP MIB テーブルに配置されるデータの収集を開始します。特に重要なのは、次の 2 つのテーブルです。

• rttMonStats：最近の数時間のすべてのジッタ オペレーションの 1時間単位の平均を示します。

• rttMonLatestJitterOper：完了した最新のオペレーションの値を示します。

遅延およびジッタにおける一般的な統計については、rttMonStats テーブルを 1 時間ごとにポーリングする必要があります。より詳細な統計については、fttMonLatestJitterOper テーブルをジッタ オペレーション頻度（この例では 60 秒）よりも長い時間間隔でポーリングする必要があります。つまり、遅延プローブまたはジッタ プローブで 5 分ごとにジッタを計算する場合、5 分未満の時間間隔で MIB をポーリングしないでください。

図 6-8 では、HP OpenView（HPOV）の Network Node Manager MIB ポールから収集された rttMonJitterStats テーブルのデータを示します。

図 6-8 HPOV の Network Node Manager MIB ポール

レポート例

図 6-9 では、HPOV の Network Node Manager を使用して SNMP 経由で収集され、Microsoft Excel のスプレッドシートにエクスポートされた SAA データの例を示します。グラフは、遅延プローブおよびジッタ プローブの 1 つの対について 8 時間にわたる遅延、ジッタ、およびパケット損失のデータ ポイントを収集したものです。

図 6-9 遅延、ジッタ、およびパケット損失のグラフ

CiscoWorks2000 の Internetwork Performance Monitor ツールにより、ジッタ、遅延、およびパケット損失のモニタリングとレポートが容易になります。また、IPM アプリケーションにより、エージェント ルータの設定とレポート データの追跡が自動的に行われます。

図 6-10 では、Cisco IPM レポートの一例を示します。

図 6-10 Cisco IPM 履歴統計レポート

上に説明したジッタ、遅延、およびパケット損失のモニタリング方法はネットワーク動作を完全にはテストしませんが、それらの方法は、受け入れ可能なネットワーク特性のインジケータおよび VoIP などの時間に影響されやすいアプリケーションがネットワークでどのように機能するかを示すプレディクタとなります。

デバイス レベルでの機密管理

機密管理の目標は、ローカル ガイドラインに従ってネットワーク リソースへのアクセスを制御して、ネットワークが妨害（意図的または無意図的に）されないようにすることです。たとえば、機密管理サブシステムでは、ネットワーク リソースにログインするユーザをモニタできるため、不正なアクセス コードを入力したユーザに対してアクセスを拒否します。

機密管理の対象は非常に幅広いため、このマニュアルでは SNMP に関連するセキュリティおよび基本的なデバイス アクセスのセキュリティだけについてのみ説明します。拡張セキュリティの詳細については、次の URL を参照してください。

• http://www.cisco.com/univercd/cc/td/doc/cisintwk/ics/cs003.htm

• http://www.cisco.com/warp/public/cc/pd/wr2k/vpmnso/

機密管理を有効に実装するには、音声セキュリティ ポリシーおよび手順の準備から開始します。また、セキュリティとパフォーマンスに対する業界の最適な実施事例に従うすべてのルータおよびスイッチに対して、プラットフォーム特有の最小設定標準を作成することが重要です。

Cisco ルータおよび Cisco スイッチでのアクセスを管理する方法は種々あります。管理方法としては、次のものがあります。

• アクセス コントロール リスト（ACL）

• デバイスに対してローカルなユーザ IDとパスワード

• Terminal Access Controller Access Control System（TACACS）

TACACS とは、IFTF（RFC 1492）の標準セキュリティ プロトコルで、ネットワークのクライアント デバイス間および TACACS サーバで実行します。TACACS は、認証メカニズムであり、特権データベースへのリモート アクセスを要求するデバイスの ID を認証するために使用されます。TACACS は、シスコにより TACACS+（CiscoSecure とも呼ばれる）に拡張され、AAA アーキテクチャでは認証、許可、会計の各機能が独立しています。

シスコは TACACS+ を使用して、非特権モードおよび特権モードで Cisco デバイスにアクセスできるユーザを綿密に管理できます。マルチプル TACACS+ サーバは、フォールト トレランス用に構成できます。TACACS+ を使用可能にすると、ルータではユーザに対してユーザ名とパスワードの入力が要求されます。また、ルータおよびスイッチではユーザに対してユーザ名とパスワードの入力が要求されます。認証を設定して、ログイン管理または各コマンドの認証を行うことができます。

認証

認証とは、次の内容を含む、ユーザを識別するプロセスです。

• ログインとパスワード ダイアログ

• 身元照明要求と応答

• メッセージ サポート

認証は、ルータまたはスイッチへのアクセスを許可する前にユーザを識別する方法です。よって、認証と許可の間には基本的な関係があります。ユーザに付与する許可特権が多いほど、認証の条件はよりきびしいものにすべきです。

許可

許可により、ユーザが要求する各サーバに対するワンタイム許可、および許可を含むリモート アクセス管理が提供されます。Cisco ルータでは、ユーザの許可レベルの範囲は 0（最低レベル）～ 15（最高レベル）になります。

会計

会計により、ユーザ ID、開始時間および停止時間、実行されたコマンドなどの課金、監査、およびレポートに使用するセキュリティ情報の収集および送信ができます。また、ネットワーク管理者は、会計を使用して、ユーザが消費しているネットワーク リソース量だけでなく、ユーザがアクセスしているサービスも追跡できます。

表 6-19 は、Cisco ルータおよび Cisco スイッチで TACACS+、認証、許可、会計を使用するために指定する基本的なコマンド例のリストを示します。詳細なコマンドについては、
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/secur_r/srprt1/index.htm を参照してください。

Catalyst エンタープライズ LAN スイッチでコマンドライン インターフェイスへのアクセスをモニタおよび管理するために、AAA を設定する方法の詳細については、
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat5000/rel_5_4/config/authent.htm を参照してください。

SNMP セキュリティ

SNMP プロトコルを使用すると、CLI（コマンドラインインターフェイス）から発行されたものと類似するルータおよび Catalyst スイッチで設定を変更することができます。ネットワーク デバイスに適正なセキュリティ基準を設定して、SNMP を介して許可されていないアクセスおよび変更を防止する必要があります。コミュニティ ストリングの長さ、文字、および予測される問題については、標準パスワード ガイドラインに従う必要があります。また、コミュニティ ストリングは、あらかじめ設定されている公開デフォルト値および専用デフォルト値から変更することが重要です。

すべての SNMP 管理ホストには、スタティック IP アドレスを設定し、IP アドレスおよび ACL によって事前に定義されたネットワーク デバイスとの SNMP 通信の権利を明示的に付与する必要があります。また、Cisco IOS および Cisco Catalyst ソフトウェアには、セキュリティ機能があり、許可された管理ステーションだけにネットワーク デバイスでの変更の実行が許可されることを保証します。

ルータ セキュリティ機能

• SNMP 権限レベル：管理ステーションがルータで実行できるオペレーションのタイプを制限する。ルータの権限レベルには、読み取り専用（RO）および読み取りと書き込み（RW）の 2 つのタイプがあります。RO レベルでは、管理ステーションに対してルータ データの照会だけを許可します。ただし、ルータのリブート、実行するインターフェイスのシャットダウンなどの設定コマンドについては許可されません。そのようなオペレーションを実行できるのは、RW 権限レベルだけです。

• SNMP ACL：ルータによる管理情報の要求から特定の管理ステーションを制限するために、SMNP 権限機能と連動して使用できる。

• SNMP View：管理ステーションがルータから取得できる特定の情報を制限する。また、SNMP 権限レベルおよび ACL 機能と一緒に使用して、管理コンソールによるデータのアクセスを制限します。SNMP View の設定例については、
http://www.cisco.com/univercd/cc/td/doc/product/software/ios111/mods/1mod/1rbook/1rsysmgt.htm#xtocid27380181 を参照してください。

• SNMP Version 3：SNMPv3 によって、ネットワーク デバイスと管理ステーション間で管理データが安全に交換される。また、SNMPv3 の暗号化機能と認証機能により、管理コンソールへのパケット転送のセキュリティが確実に向上します。SNMPv3 は、Cisco IOS バージョン 12.0(3)T およびそれ以降のバージョンでサポートされます。SNMP View の技術的な概要については、 http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t3/snmp3.htm を参照してください。

• インターフェイスの ACL：IP スプーフィングなどの攻撃を防止するためにセキュリティ基準を指定できる。ルータの着信インターフェイスまたは発信インターフェイスに ACL を適用できます。

Catalyst LAN スイッチのセキュリティ機能

IP 許可リスト機能により、許可されていない送信元 IP アドレスからスイッチへの着信 Telnet および SNMP アクセスが制限されます。システムログ メッセージ、および SNMP トラップがサポートされていて、違反したアクセスまたは許可されていないアクセスが発生したときに、管理システムに通知されます。

set ip permit コマンド セットを使用して、IP 許可リストを使用可能または使用不可にするかを設定し、IP 許可リストに追加する IP アドレスを指定します。デフォルトでは、IP 許可リストは使用不可になっています。

次に、 set ip permit コマンドの構文について説明します。

enable ：IP 許可リストを有効にするキーワード

disable ：IP 許可リストを無効にするキーワード

telnet ：Telnet IP 許可リストを指定するキーワード（オプション）

ssh ：SSH IP 許可リストを指定するキーワード（オプション）

snmp ：SNMP IP 許可リストを指定するキーワード（オプション）

addr ：IP 許可リストに追加する IP アドレス（また、DNS を使用して解決可能な IP エイリアスまたはホスト名も使用できます）

mask ：指定した IP アドレスのサブネット マスク（オプション）

all ：IP 許可リストですべてのエントリを削除するキーワード（オプション）

CallManager を使用したアプリケーション層の管理

IP テレフォニー アーキテクチャの CallManager アプリケーションは、IP Phoneに対して数多くのコール処理機能を実行します。Media Covergence Server（MCS）と ICS 7750 は、CallManager ソフトウェアのホストであり、MCS と ICS 7750 は、Web インターフェイスと SNMP から完全に管理することができます。ソフトウェアに対する最新の機能拡張には、システムログに対するサポート、CallManager MIB、およびその他の Cisco 特定の MIB が含まれます。CallManager 管理は、システムの管理機能を使用して、既存のネットワーク システムに完全に統合することができます。

ネットワーク管理とアプリケーション管理の運営を容易にするには、図 6-11 に示すように Web インターフェイス レベルで CiscoWorks2000 RME と CallManager 3.x を統合します。

（注） RME と CallManager 3.x の構成の詳細は、CiscoWorks 2000 RME サーバ上にある Web のCiscoWorks 2000 ドキュメンテーションで入手できます。

図 6-11 CiscoWorks2000 RME と CallManager の統合

インベントリ管理

CallManager のインベントリ詳細は、ネットワーク管理プロトコル（SNMP）を使用して CallManager ソフトウェアから入手できます。CallManager 3.x ソフトウェアは、Cisco Discovery Protocol（CDP）をサポートしているため、CiscoWorks2000 LAN Management Solution（LMS）ソフトウェアで CallManager 3.x を自動検出できます。NMS を最も効率的に実装すると、インフラストラクチャ内のその他の要素を含んだ完全な CallManager のインベントリ入手できます。

トラブルシューティングの実行およびアップグレード プロセスでは、次の内容を把握する上でネットワーク管理者に役立つ最新の詳細なインベントリ情報が必要です。

• ソフトウェアの依存関係

• 機能要件

• ハードウェア要件

Web ベースのインベントリ ツールを使用すると、組織のあらゆる場所からのデバイス情報へのアクセス容易性が飛躍的に向上します。CallManager には、優れたインベントリ管理機能と要素管理機能が備わっています。図 6-12 では、CallManager ソフトウェアに表示される IP Phone インベントリ リストの一例を示します。CallManager には、説明だけでなく、各 IP Phoneのデバイス プール メンバーシップとデバイス名も表示されます。

図 6-12 CallManager インベントリ/要素管理レポート

CallManager アプリケーションから CallManager を管理することもできます。図 6-13 では、CallManager の追加、変更、削除、および再起動を実行できる CallManager Administration 画面を示します。

図 6-13 Cisco CallManager Configuration ウィンドウ

プロビジョニングとバルク管理

IP Phoneのプロビジョニングでは、Cisco CallManager でユーザ特定の構成パラメータを指定する必要があります。CallManager で大量のユーザを追加するには、Bulk Administration Tool（BAT）を使用します。事前に定義したユーザ属性はファイルに定義され、ソフトウェアにロードされます。これにより、各ユーザーを手作業で追加する際に関連するオーバーヘッドが減少します。また、ツールを使用して、データベースから大量のユーザを一括して削除できます。

図 6-14 は、Cisco CallManager BAT ウィンドウを示します。

図 6-14 Cisco CallManager Bulk Administration Tool ウィンドウ

BAT の詳細については、 http://www.cisco.com/univercd/cc/td/doc/product/voice/sw_ap_to/admin/index.htm を参照してください。

ゲートウェイおよびゲートキーパーの管理

CallManager ソフトウェアでは、PSTN でユーザに対して通信を確立する必要がある場合、音声ゲートウェイが使用されます。CallManager に登録されたゲートウェイを使用して、非 IP 環境のコールに対してシグナリングおよびコールを管理できます。複数のゲートウェイ タイプがあり、IP テレフォニー の配備におけるサイト固有の数多くの要件を満たします。これらのゲートウェイの範囲は、スタンドアロン システムから、Catalyst LAN スイッチに統合できる複数のモデルまでに及びます。CallManager に登録されたゲートウェイおよびトランクの運用ステータスは、Cisco CallManager MIB を組み込むネットワーク管理システムから取得することができます。

現在では、標準機関およびベンダーが VoIP ゲートウェイの追加管理に対して MIB を定義しています。これらの MIB が完成し、業界で導入されると、VoIP ゲートウェイの管理可能性が大幅に向上します。ゲートウェイおよびトランクのステータス特定の SNMP MIB については、 表 6-21 を参照してください。

現在の CallManager のバージョンでは、次の 3 つのタイプのゲートウェイ プロトコルをサポートします。

• Skinny Station Protocol

• Media Gateway Control Protocol（MGCP）

• H.323

シスコは、IP テレフォニー ネットワークと PSTN の接続には VoIP ゲートウェイを推奨します。VoIP ゲートウェイの詳細については、次を参照してください。

• http://www.cisco.com/warp/public/cc/pd/ga/prodlit/gatwy_wp.htm

• http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/3_0/admin_gd/3_0_5/p6gatewy.htm

図 6-15 は、Cisco CallManager Gateway Administration ウィンドウを示します。

図 6-15 Cisco CallManager Gateway Administration ウィンドウ

ゲートキーパーは、Cisco Multimedia Conference Manager（MCM）としても知られており、次の操作に使用される H.225 RAS メッセージ セットをサポートするデバイスです。

• コール アドミッション制御

• 帯域割り当て

• ダイヤル パターン解決

Cisco CallManager のクラスタごとに構成できるゲートキーパーは 1 つだけです。図 6-16 では、Cisco CallManager Gatekeeper Configuration ウィンドウを示します。

図 6-16 Cisco CallManager Gatekeeper Configuration ウィンドウ

音声ポート管理

CiscoWorks2000 Voice Manager 2.0（CVM）は、Web ベースの音声管理およびレポート ソリューションです。このアプリケーションには、音声ポートの構成とプロビジョニングの拡張機能、および VoIP、Voice over Frame Relay（VoFR）、および Voice over ATM（VoATM）の各ネットワーク配備に対して音声対応 Cisco ルータでダイヤル計画を作成および修正する拡張機能が備わっています。

CVM 2.0 の機能のについては、 http://www.cisco.com/warp/public/cc/pd/wr2k/cw2kvm/prodlit/cvm2_ds.htm を参照してください。

障害および性能の管理

CallManager で障害を検出できることは、ユーザに対するサービスの中断を確実に最小限に抑えるために不可欠です。データベースおよびコール処理の冗長化機能は、ソフトウェアに組み込まれたコール処理機能を組み合わせて使用すると、システムのアベイラビリティのレベルが高くなります。CallManager ソフトウェアの運用ステータスは、CallManager MIB をネットワーク管理システムに統合することによって、取得できます。MIB を SNMP プラットフォームでポーリングし、推奨されたしきい値と比較することができます。それらのしきい値を超えると、SNMP プラットフォームによってアラート メッセージが適切な担当者に送信されます。

CallManager の障害を管理するもう一つの方法は、Cisco Voice Health Monitor（VHM）を使用することです。Voice Health Monitor は CiscoWorks2000 アプリケーションであり、音声要素を事前にモニタして、Cisco 環境の状態をモニタし、ネットワーク ダウンタイムを最小限に抑えます。VHM アプリケーションでは、ネットワークのテストを総合的に行い、Cisco CallManager、Cisco スイッチ、および Cisco ルータ ゲートウェイのリアルタイム ステータス レポートの提供、迅速なトラブルシューティングの支援などによって、システムの信頼性を集中的に実証します。

Cisco VHM の一部の機能には、次のものが含まれます。

• ヘルス ダッシュボード：ネットワークの障害インジケータの表示

• Media Convergence Server のシステム、環境、アプリケーションの状態のステータス インジケータ

• 詳細デバイス ビュー：1 つのネットワーク要素に関する特定の情報

• システム情報：PC で実行しているアプリケーションのリスト

• ゲートウェイの登録およびステータス

• 障害イベント ブラウザ

• VoIP 特定の障害アラーム ビュー

• ネットワーク全体の障害アラーム ビュー

グラフィカル ユーザ インターフェイスをベースとした Voice Health Monitor アプリケーションを使用すると、種々の障害と VoIP コンポーネントを容易に表示できます。

図 6-17 は、障害の概要ウィンドウの一例を示します。NOC 担当者は、このウィンドウを使用してネットワーク全体の音声状態をリアルタイムでモニタできます。

図 6-17 Voice Health Monitor Fault ウィンドウ

図 6-18 は、VoIP コンポーネントのリアルタイム ステータス ビューの一例を示します。

図 6-18 Voice Health Monitor Status View ウィンドウ

Device Fault Manager（DFM）では、CISCO-CCM-MIB と COMPAQ サーバ MIB に基づいたデバイス固有の情報をリアルタイムで表示できます。

Voice Health Monitor には、デバイスことのリアルタイム ダッシュボードが表示されます。図 6-19 に示す device detail ウィンドウは、CallManager サーバ状態の日報として役立ちます。CallManager システム管理者は、このタイプの日報を印刷して、種々のリソースの追跡と将来のトレンドを予測することができます。

図 6-19 Voice Health Monitor Device Detail ウィンドウ

コール詳細レコードの管理

CallManager ソフトウェアのコール詳細レコードを使用すると、種々の目的で詳細情報を入手し、使用することができます。これらのレコードにより、トラブルシューティングが容易になり、課金管理および性能管理の実装に必要なデータが提供されます。レコードは、生成され、SQL（標準クエリー言語）データベースに書き込まれます。取得したデータは、ODBC（Open Database Connectivity）を使用してアクセスできます。

コール レコード フィールドに関する詳細については、『Cisco IP Telephony Troubleshooting Guide』を参照してください。このマニュアルを表示するには、
http://www.cisco.com/warp/public/788/AVVID/ts_ccm_301_sec7.htm にアクセスしてください。

Cisco ART を使用した音声品質の管理

Cisco CallManager の Administrative Reporting Tool（ART）は Web べースのレポート アプリケーションです。これにより、音声品質に関する情報を提供する次のレポートと、ゲートウェイ パフォーマンスのレポートが生成されます。

• サービスの品質

• トラフィック詳細

• ユーザ コール詳細

• 課金詳細

• ゲートウェイ詳細

• コール詳細レコード

Administrative Reporting Tool の詳細については、 http://www.cisco.com/univercd/cc/td/doc/product/voice/sw_ap_to/admin_rp/index.htm を参照してください。

ソフトウェアの管理

コールした Cisco MCS Backup Utility と MCS Restore Utility を使用して、Cisco CallManager のデータのバックアップおよび復元ができます（また、このツールは Cisco CallManager 3.1 をインストールすると、ICS 7750 でも使用できます）。システム障害時にデータのアベイラビリティを確実にするために、CallManager で通常のデータ バックアップを行うことを強く推奨します。オペレーティング システム、ハード ドライブ、ソフトウェア およびデータのバックアップおよび復元の手順については、Cisco CallManager ドキュメンテーション セットで入手するか、
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/3_0/index.htm を参照してください。

（注） 問題が迅速に解決されることを保証するには、運用担当者が上述のドキュメントに容易にアクセスできることが重要です。

MCS、ICS 7750、および CallManager における機密管理

MCS、ICS 7750、および CallManager へのアクセスは、パスワードによって保護されます。MCS システム、ICS 7750 システム、および CallManager ソフトウェアへのコンソールおよびリモート アクセスは、システム レベルで認証されます。そのシステムおよびソフトウェアにアクセスするパスワードは、システム管理の責任者だけに配布される必要があります。また、許可されていない人によるアクセスのリスクを減らすためには、インストール時にデフォルトの SNMP コミュニティ ストリングも変更する必要があります。ICS 7750 システムで SNMP コミュニティ ストリングを変更する場合には、必ず ICSconfig を使用します。

トラブルシューティング

Cisco CallManager には、トレース ファイル（SDI、SDL、および CCM の各トレース）、診断コール詳細レコード、システム イベントなどの組み込みトラブルシューティング機能が備わっています。システム イベントには、MCS サーバまたは ICS 7750 のシステム処理エンジン（SPE）によって生成されるシステムレベル イベント、および CallManager のシステムログ メッセージのサポートが含まれます。

トラブルシューティングの詳細については、『Cisco IP Telephony Troubleshooting Guide』を参照してください。このマニュアルを表示するには、
http://www.cisco.com/warp/public/788/AVVID/ts_ccm_301_sec7.htm にアクセスしてください。

Cisco IP Phoneの管理

IP Phoneのアドレッシングおよび登録

Cisco IP Phoneには、企業ネットワークで現在配備されている通常のアナログ電話で使用できる機能が用意されています。また、IP Phoneでは次の機能もサポートされています。

• コール転送

• 短縮ダイヤル

• コール転送

• 電話会議

• リダイヤル

IP Phoneを配備する前に、いくつかのコンポーネントが正確に動作することを確認する必要があります。それらのコンポーネントの一部には、次のものがあります。

• DHCP（動的ホスト制御プロトコル）

• TFTP（トリビアル ファイル転送プロトコル）

• DNS（ドメイン ネーム システム）のサーバ

これらのサーバにより、IP Phoneとその構成設定の自動登録に必要なサービスが提供されます。IP Phoneおよびネットワーク設定に関する情報を含む構成ファイルが、登録プロセス中に IP Phoneにダウンロードされます。

図 6-20 は、Cisco CallManager Phone Configuration ウィンドウを示します。

図 6-20 Cisco CallManager Phone Configuration ウィンドウ

Cisco IP Phoneの設定方法と管理方法の追加情報については、 http://www.cisco.com/en/US/products/hw/phones/ps379/products_administration_guide_books_list.html を参照してください。

電源管理

IP Phoneの電源は、次の 3 つの電源から得ることができます。

• 外部電源

• インライン電源付きスイッチング モジュール

• インライン電源パッチ パネル

スイッチング モジュールのホストとして機能する LAN スイッチで使用できるSNMP およびシステムログ サポートを使用して、スイッチング モジュールの管理をネットワーク管理システムに統合できます。システムログ メッセージは LAN スイッチによってサポートされ、電源のアベイラビリティ、ポート稼動ステータス、およびリンク ステータスをレポートします。スイッチング モジュール の LED は、ハードウェアの追加診断とステータス表示を知らせます。また、LAN スイッチの拡張 SNMP サポートを使用して、管理機能をリモートで実行できます。

Catalyst スイッチでのインライン電源ステータスのポーリングに使用する OID に関する追加情報については、 http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml を参照してください（この Web ページから OID リンクを選択して、現在使用できる OID のリストを表示します）。

トラブルシューティングとユーザの追跡

Campus Manager などの Cisco ネットワーク管理ツールには、IP ネットワークに着信した音声コールをトレースするために追加された機能が備わっています。Web ベースのアプリケーションでは、VoIP コールによってネットワークで使用されるシグナリング パスのトラブルシューティングだけでなく、データ パスのトレースも行うことができます。IP Phoneと一緒に レイヤ 2と レイヤ 3のデバイスが、音声コールによって取得された各ホップを示すトポロジ マップに表示されます。

図 6-21 は、Campus Manager で音声トレース パスの一例を示します。

図 6-21 音声トレース パスの例

Campus Manager の User Traking ソフトウェアの機能拡張により、アプリケーションでユーザとその電話に関連する情報を表示できます。トラブルシューティングの場合、CallManager がサポートする MIB によって、次の詳細情報が提供されます。

• IP アドレス

• 電話ステータス

• ユーザ名

• E.991 の場所

• ポート

• デバイス接続

CallManager および IP Phoneの管理に使用する SNMP MIB 変数のリストについては、
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml を参照してください（この Web ページから SNMP v1 MIB リンクを選択して、現在使用できる OID のリストを表示します）。

図 6-22 は、ユーザ追跡の電話テーブルの一例を示します。

図 6-22 ユーザ追跡の電話テーブルの例

CallManager トラブルシューティングの詳細については、『Cisco IP Telephony Troubleshooting Guide』を参照してください。このマニュアルを表示するには、
http://www.cisco.com/warp/public/788/AVVID/ts_ccm_301_sec7.htm にアクセスしてください。

NMS リファレンス アーキテクチャ

図 6-23 では、システムシステムズがデータ ネットワーク管理に対して最小限のソリューションと考えるリファレンス アーキテクチャを示します。そのアーキテクチャには、次のものが含まれます。

• 障害管理用の SNMP プラットフォーム

• 長期間の性能管理とトレンディング用のパフォーマンス モニタリング プラットフォーム

• 構成管理、システムログ収集、ハードウェアおよびソフトウェアのインベントリ管理用の CiscoWorks2000 サーバ（LMS バンドル付き）

図 6-23 NMS リファレンス アーキテクチャ

SNMP プラットフォームでは、CIM/XML 方式を使用して CiscoWorks2000 サーバと直接データを共有できます。また、シスコの Network Supported Accounts のお客様は、お客様の NSA エンジニアによる予防的モニタリングおよびトラブルシューティング サポートの追加に応じて、シスコの NATkit サーバを組み込むことができます。NATkit サーバには、リモート ディスク マウント（rmount）または CiscoWorks2000 サーバに常駐するデータへの ftp アクセス権があります。これにより、Cisco デバイスに設定されるシステムログ レシーバ数と、複数のメッセージによって発生する CPU ロードが減少します。

• Cisco Network Supported Accounts については、 http://www.cisco.com/warp/public/cc/serv/mkt/sup/ent/nsa/nsa_pl.htm を参照してください。

• Cisco NATkit ついては、 http://www.cisco.com/univercd/cc/td/doc/product/natkit/natk2010/5_nkitov.htm を参照してください。

ハードウェアおよびソフトウェアのコンポーネントに加え、NMS 実装を効率的にするには、明確なプロセスと手順を使用する必要があります。次の小項目では、シスコ担当者とシスコのお客様との話し合いに基づく提案事項について説明します。

• 計画、設計、および実装

• 日常の運用

計画、設計、および実装

1. 初期ネットワーク設計に NMS を組み込みます。CPU、メモリ、およびその他のハードウェア仕様に NMS プロトコル実行の追加オーバーヘッドが含まれることを確認します。また、ネットワーク デバイスの NMC 構成コマンドを特定し、企業の標準として使用される NMS 構成のテンプレートを作成します。

2. チェックリストを使用して、NMS システムの実装および承認テスト計画を作成します。すべての機能が予測どおりに動作することを確認して、その内容を記録します。

3. ネットワーク運用グループが受信すると予測されるすべての重要なイベントおよびアラート条件を特定します（例については、 表 6-20 を参照）。次の内容を含むイベントとアラートごとのサービス レベル契約（SLA）を書き込みます。

–反応時間

–応答時間

–修理時間

–エスカレーション手順

–担当者

4. プロセスの進捗状況を確認するには、テスト アラートを送信することで、NOC 応答を定期的にテストします。

• 優先順位：1 = 重大、2 = デバッグ、3 = 通知

• SNMP トラップ：しきい値のトリガー ポイントの生成

• CISCO 7206 VXR SNMP 取得サポート

–X.25 LAPB の拡張 SNMP MIB（RFC 1381）

–X.25 パケット層の拡張 SNMP MIB（RFC 1382）

–LAPB XID テーブル、X.25 切断回線テーブル、X.25 コール パラメータ テーブルの免除

• NOC アクション：階層 1 = ヘルプ デスク チーム、階層 2 = ネットワーク管理チームにエスカレーション

日常の運用

1. システムログを事前に毎日確認して、重要な管理を適切な担当者に転送するために、少なくとも 1 人の運用担当者を割り当てます。

2. 動向を特定するために、パフォーマンス データを毎日確認して、ネットワーク運用特性を調べる運用担当者を少なくとも 1 人割り当てます。

3. 運用担当者がログインのアクセス権を持ち、CallManager、IP Phone、CiscoWorks2000、メインフレーム アプリケーションなどの成果重視のアプリケーションおよびデバイスを設置していることを確認します。運用担当者がアプリケーション機能をより詳しく調べることで、問題と正確な処置を特定できることが、シスコの多くのお客様によって明らかにされています。

4. エンジニアレベルの担当者を少なくとも 1 人割り当て、トレンドおよびトラブルの特性を特定するために、週次、月次、年次単位のパフォーマンス データを調べます。

5. エンジニアレベルの担当者を少なくとも 1 人割り当て、受け入れ可能な応答時間と安定性を維持するために、ネットワークのユーザが検討するネットワーク セクションのネットワーク特性と動作を事前に調べて、文書化します。これにより、正常に動作するネットワークベースラインが提供されます。

CISCO-CCM-MIB を使用した Cisco CallManager の管理

表 6-21 Cisco CallManager MIB テーブルには、CallManager 、ゲートウェイ、トランク、および IP Phoneが動作していることを確認するためにモニタする最も重要な MIB オブジェクトのリストを示します。これらの MIB オブジェクト（OID）は、推奨された時間間隔で NMS プラットフォームによってポーリングされます。しきい値は、一般的な推奨値です。しきい値は、ご使用のネットワークで調整が必要となる場合があります。これらの特定の OID は障害管理に分類され、それらの OID が指定のしきい値を超えると、重大なシステム問題を示すため、ネットワーク運用担当者はただちに処置を取る必要があります。HPOV、Tivoli などの NMS プラットフォームでそれらのオブジェクトをポーリングするには、CISCO-CCM-MIB.my ファイルをシステムにロードする必要があります。

予防的なポーリングとしきい値のモニタリングを開始する方法については、SNMP プラットフォーム ベンダーのマニュアルを参照してください。

表 6-22 では、CISCO-CCM-MIB.my ファイルのロード時に NMS プラットフォームに自動的に追加される SNMP トラップ メッセージのリストを示します。SNMP トラップを送信するために CallManager を設定すると、CallManager サーバは、それらのエラー メッセージを NMS ステーションに送信します。

IP テレフォニー ネットワーク管理製品の要約

表 6-23 は、使用可能なネットワーク管理ツール、および各ツールにサポートされている IP テレフォニー コンポーネントのリストを示します。

セキュリティ ポリシーの最適事例

あらゆるセキュリティ実装での最初のステップは、セキュリティ ポリシーの確立です。このマニュアルではこれについて説明していませんが、その代わりに一連の推奨する最適事例の概要について説明します。それらの最適施策の実装は、組織のセキュリティ ポリシーによって実施するかどうかを決定します。この項では、次の最適施策について説明します。

• 物理セキュリティの確立

重要な通信機器に対して安全な物理境界を作成することは、安全なネットワークを構築する上で根本的な基盤となります。物理的に保護されていないネットワーク資産は、ネットワーク設計およびソフトウェア設定では、予測される不正な攻撃から保護することはできません。

• ネットワーク要素の保護

ルータ、イーサネット スイッチ、および VoIP ゲートウェイはネットワーク境界を定義し、すべてのネットワークに対してゲートウェイ インターフェイスとして機能します。また、音声およびデータ ネットワークに関してこれらの重要部分を保護することが、ネットワーク インフラストラクチャ全体で稼動する、データ、音声、およびビデオ アプリケーションを保護するための要件です。

• IP ネットワークの設計

堅実な IP ネットワーク設計の方針を理解し、遵守すると、ネットワークでスケールをエスカレーションして実行できるだけでなく、接続したすべてのデバイスのセキュリティも向上することができます。

• CallManager サーバの保護

実際の音声コール処理プラットフォームとインストールしたアプリケーションを保護することが、IP テレフォニー ネットワークの保護上でおそらく最も重要な最後のステップです。

これらの各ステップを分析し、構成例を以降の項で示します。

物理セキュリティの確立

多くのコンピュータ デバイスと同様に、Cisco ルータと Cisco スイッチ、およびその他のインフラストラクチャ コンポーネントは、物理アクセスを直接行う攻撃者による侵入または破壊から保護するようには設計されていません。許可されていないユーザによる物理アクセスを防止するには、適切なステップを実行する必要があります。

一般的な予防措置には、配線室およびデータ センターへのアクセスを信頼できると見なされるスタッフに制限することが含まれます。一般的に、信頼できるスタッフは、保護されているデバイスへの直接または間接アクセス権を持つため、物理アクセスで得るメリットがありません。信頼できないスタッフが存在する場合があるデータ センターでは、さらに厳しいセキュリティ対策が必要となる、各アイテムまたはラックのキャビネットを個別にロックする措置が必要となる場合があります。ドアにキー ロックまたは電子ロックを使用する場合には、ロックを回避する能力、あるいはロックを解錠できる施設、セキュリティおよび守衛スタッフを考慮します。

組織のインフラストラクチャ、通信、および電源装置への物理アクセス権を持つ担当者を定義するポリシーについては、システム管理者またはネットワーク管理者としてログイン許可を持つ担当者と同様に慎重に評価する必要があります。また、物理アクセス ログも慎重に維持する必要があります。さらに、物理アクセス ログを維持するコンピュータでは、ネットワーク タイム プロトコル（NTP）などの同期時間ソースを使用する必要があります。これにより、そのログを他のコンピュータ、ネットワーク要素、および通信機器のログと正確にクロス チェックすることができます。

追加ステップとして、IP ビデオ監視装置を各データ センター、および配線室に設置します。ビデオ記録を使用して、電子アクセス システムとリンクすることで、所定の保護環境への出入りをすべて追跡することができます。ビデオ アーカイブは、日時別、または物理的な場所の変化ごとにでさえ検索できます。たとえば、システム キャビネットが開いているすべての録画場面について、ビデオ ログを検索できます。さらに、リアルタイムのアラーム機能を有効にできます。それらの記録ツールは、攻撃者をキャッチしたり、攻撃の発生を突き止めたりするのに役立ちます。また、訴訟手続きの証拠として採用されます。

ネットワーク要素の保護

物理セキュリティを確立した後に、次のステップは、通信ネットワークを構成する実際のルータ、スイッチ、および VoIP ゲートウェイを保護することです。それらのネットワーク要素には、企業ネットワーク全体の物理的および論理的な接続性が備わっています。そのため、それらのネットワーク要素は十分な知識を持つハッカーの主なターゲットとなる可能性があります。

Cisco ルータの保護に関する最新情報については、『Improving Security on Cisco Routers』テクニカル ノートを参照してください。このテクニカル ノートを表示するには、
http://www.cisco.com/warp/public/707/21.html にアクセスしてください。

Telnet アクセス

現在でも、Telnet セッションによって CLI（コマンド行インターフェイス）から構成する方法が、ルータおよびスイッチを管理する最も一般的な方法です。したがって、それらのネットワーク要素を保護する最初のステップは、ルータおよびスイッチの仮想端末セッションにアクセスできるサブネットを限定することです。運用スタッフおよびネットワーク管理ホストの IP アドレス レンジへの仮想コンソール アクセスを制限する方法は、パスワードが漏出した場合でも、許可されていないユーザがネットワーク デバイスにアクセスできないようにするために役立ちます。

Cisco IOS ルータ

例6-1 では、仮想コンソールに接続するために、ネットワーク管理サブネット 172.21.167.0 でホストだけを許可する Cisco IOS ルータのアクセス リストを定義しています。

例6-1 Cisco IOS ルータ アクセス ― 仮想コンソールへのホスト

Catalyst イーサネット スイッチ

例6-2 では、Catalyst イーサネット スイッチの仮想コンソールに接続するために、ネットワーク 172.21.167.0 でホストだけを許可する IP 許可リストを定義しています。

例6-2 IP 許可リスト ― 仮想コンソールへのホスト

また、VLAN アクセス管理リスト（VACL）を使用して、IP 許可リストの機能性を果たすこともできます。VACL はハードウェア（Policy Feature Card [PFC]）によって処理されるため、VACL は IP 許可リストよりもかなり速く処理されます。

例6-3 では、VLAN 10 にマッピングされる VACL を定義しています。VLAN 10 は、IP アドレス 172.21.167.1 で Catalyst イーサネット スイッチの仮想コンソールにアクセスし、その他すべてのトラフィックが許可されている間にその他すべての仮想コンソールへの Telnet アクセスをブロックするために、Telnet を使用してネットワーク 172.21.167.0 でホストを許可します。

例6-3 VLAN にマッピングされる VACL ― ホストからの Telnet アクセス

図 6-24 では、ルータおよびスイッチの仮想端末セッションにアクセスできるサブネットを限定した結果を示します。

図 6-24 Telnet アクセスと制限

TACACS+ と RADIUS を使用したパスワードおよび認証

パスワードは、許可されていないルータおよびスイッチへのアクセスに対して、もう 1 つの重要な防御ラインとなります。ユーザ パスワードを管理する最適な方法は、TACACS+ 認証サーバまたは RADIUS 認証サーバでユーザ パスワードを維持することです。ただし、依然として多くのルータには、緊急用パスワードがあり、そのパスワードは、認証サーバのメンテナンス期間に必要となる特権アクセスに対してローカルで設定されたものです。ルータのパスワード公開の制限に対して、最大限の予防策を確実に実施するには、 service password-encryption を使用して、すべてのパスワードを暗号化する必要があります。さらに、イネーブル秘密を使用して設定アクセスをさらに隠蔽することを推奨します。 service password-encryption コマンドでは、アルゴリズムが弱い簡単なヴィジュネル暗号を使用して、イネーブル パスワードを暗号化します。有能な暗号使用者は、この暗号を非常に素早く復号することができます。ただし、 enable secret コマンドでは、MD5 という強力な一方向のハッシング アルゴリズムを使用して、秘密パスワードを暗号化します。MD5 ハッシュはディクショナリ攻撃を受けやすいので、必ず非英数字記号を含むパスワードを使用してください。

適切なパスワードの選択

理想的には、SofToken、SecurID、DES Gold Cards などのワンタイム パスワードを使用して、信頼できるユーザのパスワードを攻撃者が再利用できないようにします。ただし、多くの組織では、それらのツールが使いにくい、あるいは非常に高価であると考えています。通常のパスワードを使用する場合、辞書に載っている言葉を順序どおりの使用か、またはパスワードの正式ユーザを監視することによっては、推測できないパスワードを選ぶ必要があります。最高のセキュリティを維持するには、大文字と小文字を組み合わせるだけでなく、数字や句読記号も使用する必要があります。推奨するメンテナンス パスワードの設定の例を次に示します。例6-4 では、イネーブル秘密パスワードを入力してイネーブル モードに設定する必要があります。

例6-4 Cisco IOS ルータでのイネーブル パスワード

TACACS+ と RADIUS を使用した AAA

メンテナンスの緊急用パスワードを安全に設定すると、ネットワーク要素の日常のメンテナンスおよび設定にユーザのパスワードを設定できます。ネットワーク要素へのすべてのユーザ アクセスに対しては、堅実な認証、認証および会計（AAA）方式を使用する必要があります。

ユーザごとの AAA 機能を実行するために RADIUS または TACACS+ を使用することは、インフラストラクチャのデバイスのセキュリティ、およびアカウンタビリティを向上させるのに不可欠となります。これらの機能により、アカウントおよびパスワードの情報の中央集中型管理が可能になるため、信頼できるユーザの追加または削除時に、デバイスごとのメンテナンス作業（およびエラー）が排除されます。また、Cisco Secure ACS を構成して、強力なパスワード、パスワード エージング、および侵入のロックアウトを要求することもできます。

AAA に RADIUS または TACACS+ を使用すると、各ユーザには、ネットワーク デバイスにアクセスできる独自のパスワードが設定されます。AAA サーバを使用できない場合は、ルータの構成に保存されたローカルのユーザ名/パスワードのデータベースを使用して、シェルを開くことができます。この構成では、物理セキュリティが想定されていて、AAA はコンソール ポートで使用されません。例6-5 と例6-6 では、RADIUS を使用した Cisco IOS ルータと TACACS+ を使用した Catalyst スイッチで使用可能にする AAA を示します。

例6-5 RADIUS を使用した Cisco IOS ルータで AAA を有効にする

例6-6 TACACS+ を使用した Catalyst イーサネット スイッチで AAA を有効にする

セキュア シェル

セキュア シェル（SSH）とは、クライアントから Cisco ルータまでのシェル セッションを安全な、暗号化可能なアプリケーションです。Cisco IOSの選択バージョンで稼動する SSH バージョン 1 のサーバは、市販されている SSH クライアント ソフトウェアと互換性があります。Cisco SSH サーバでは、DES と 3DES の暗号化およびユーザ認証をサポートしています。

（注） 拡張暗号化コード（56 ビット、168 ビットのデータ暗号化機能セットなどを含む）を組み込みの Cisco IOS ソフトウェア イメージは、米国および国際政府機構の輸出規制の対象です。詳細については、シスコ代理店にお問い合わせください。または、
export@cisco.com まで電子メールでお問い合わせください。

例6-7 では、Cisco IOS で SSH を使用可能にするのに必要な構成ステップを示します。

例6-7 Cisco IOS で SSH を使用可能にする

ユーザが SSH を使用してルータにアクセスできるように、ユーザ名または AAA 認証サーバを設定する必要があります。また、有効なドメイン ネームを指定し、ネーム サービス ルックアップをルータ構成の一部にする必要があります。現在、Cisco IOS は SSH バージョン 1のみをサポートしています。

簡易ネットワーク管理プロトコル（SNMP）

SNMP は、ネットワーク要素を監視および構成する際に幅広く使用されます。SNMP では、コミュニティ ストリングに基づいた認証方式を採用します。このコミュニティ ストリングは、基本的にネットワーク要素のアクセスに使用されるパスワードとなります。SNMP バージョン 1 では、このパスワード文字列をクリアテキストでネットワーク全体に送信します。SNMP バージョン 2 では、MD5 をベースとしたダイジェスト認証方式をサポートし、各種管理データへのアクセスを制限できます。ほとんどの SNMP 実装では、ポーリング トランザクション プロセスの一部としてコミュニティ ストリングを送信するため、SNMP を活用する場合には、最低でも SNMP バージョン 2を使用することを推奨します。現時点では、Cisco CallManager バージョン 3.0(7) では SNMPv3 をサポートしていません。

SNMP をセキュリティ上安全に使用するには、次の 3 つの基本ルールに従います。

1. コミュニティ ストリングに public および private を使用しない

2. SNMP アクセスをいくつかの特定のホストまたはサブネットだけに制限する

3. 可能な場合には、SNMPv2 を使用する

仮想コンソールから表示および構成する情報も、SNMP 経由でアクセスできるため、このアクセス方式をできるだけ完全に制限することが極めて重要です。SNMP 書き込みの実行に必要な検査済みのホストだけに完全なアクセス権を設定する必要があります。

例6-8 から例6-11 は、コミュニティ ph0oBar を使用して SNMP 読み取りを実行するためにネットワーク 10.21.101.0 のホストだけ、また、コミュニティ ph0oBaz を使用して SNMP 書き込みを実行するためにホスト 10.21.101.10 だけを許可するアクセス リストを定義します。

例6-8 アクセス リスト ― Cisco IOS ルータ

例6-9 アクセス リスト ― Catalyst イーサネット スイッチ

IP 許可コマンド文または VACL 文を使用して、スイッチへの SNMP アクセスを制限できます。

例6-10 IP 許可コマンド文

例6-11 VACL コマンド文

HTTP

デフォルトでは、Web 設定はほとんどのプラットフォームで無効になっていますが、経験の浅いネットワーク管理者はその設定を有効にすることがよくあります。その設定サービスの無効化が適切でない場合には、HTTP アクセスを特定の管理アドレスに制限します。

（注） HTTP 設定が不要な場合には、その設定を無効にします。

例6-12 は、ルータが Cisco IOS ルータである場合の例です。ここでは、HTTP サーバに接続するためにネットワーク 10.21.101.0 のホストだけを許可するアクセス リストを定義します。

例6-12 アクセス リストの許可 ― HTTP サーバに対するホスト

Catalyst スイッチでは、 set ip http server disable コマンドを使用して、HTTP サーバを無効にできます。

Cisco Discovery Protocol

Cisco Discovery Protocol（CDP）は、ネットワーク管理に使用されるレイヤ 2 プロトコルです。このプロトコルにより、直接接続しているシステムはルータが Cisco デバイスであると認識し、実行しているモデル番号と Cisco IOS ソフトウェア バージョンを判別できるため、危険な状態となる可能性があります。また、この情報は、ルータ攻撃に使用される可能性もあります。 no cdp running グローバル構成コマンドを使用して CDP プロトコルを無効にするか、 no cdp enable コマンドを使用して各インターフェイスでそのプロトコルを無効にすることができます。

（注） ICS 7750 では、CDP を無効にしないでください。無効にすると、システム障害の原因となる場合があります。

Catalyst スイッチでは、 set cdp disable を使用してシステム全体で CDP を無効にするか、
set cdp disable mod_num/port_num を使用して各ポートで CDP を無効にすることができます。

警告バナー

banner login コマンドを使用して、許可されているユーザおよび許可されていないユーザに対して、ユーザのアクティビティを監視して無許可使用を禁止し、場合によっては無許可使用を告発することを通知します。

（注） バナーには、一般的に、組織、ルータ、またはネットワークに関する特定情報を含めません。

特定のバナー内容は、組織別または場所別に変わります。次の情報は、指針として参考にしてください。

• 特に許可された担当者だけがシステムにログインまたは使用し、場合によっては個人情報を使用してシステムの使用を許可することがあることを通告する。

• 許可されていないシステムの使用は違法であり、民事刑罰や刑事罰を受ける場合があることを通告する。

• 以降通告されることなくシステムの使用が記録または監視され、その結果ログが法廷で証拠として採用される場合があることを通告する。

• 特定の国内法によって要求される特有の通告

回線設定

transport input コマンドを使用することで、必要なプロトコルとの接続だけを受け入れるには、仮想端末回線（VTY;Virtual Terminal Line）を設定する必要があります。VTY でTelnet セッションだけを受信する場合、コマンドは次のようになります。

transport input telnet

Telnet および SSH が必要な場合、コマンドは次のようになります。

transport input telnet ssh

（注） 可能な場合には、接続プロトコルとして SSH だけを使用し、クリアテキスト Telnet を無効にします。

exec-timeout コマンドを使用して、VTY タイムアウトを設定する必要があります。これにより、アイドル セッションで VTY を無制限に消費することがなくなります。また、
service tcp-keepalives-in コマンドを使用して、着信接続に TCP キープアライブを使用できます。これは、攻撃および オーファン セッションから保護するのに役立ちます。

Catalyst スイッチでは、セッションのアイドル タイムアウトのデフォルトは 20 分です。
set logout timeout コマンドを使用して、このタイムアウトを設定できます。

フィンガーおよび TCP/UDP 小規模サーバ

デフォルトでは、いくつかのサービスが有効です。攻撃者はそのいずれかのサービスを使用して、難なくデバイス リソースを消費したり、その他のホストを直接攻撃したり、現在ネットワーク デバイスにアクセスしている運用スタッフに関する情報を入手したりすることができます。それらのサービスを無効にして、それらのサービスまたは提供される情報の不正使用を防止できます。例6-13 では、無効にした小規模サーバとフィンガー サービスを示します。

例6-13 Cisco IOS ルータでサービスを無効にする

リモート コピー/リモート シェル

一部のネットワーク管理者は、Berkeley Remote Copy（RCP）コマンドを使用してファイルをデバイスにコピーし、リモート シェル（RSH）コマンドを使用してログインしないでコマンドを実行します。ただし、他のオプション（Cisco IOS バージョン 12.1T の SSH サポートなど）が有効でない場合には、それらのサービスの認証が極端に弱くなり、それらのサービスを使用できなくなるので注意してください。

例6-14 Cisco IOS ルータで RCP サービスおよび RSH サービスを無効にする

ネイバー認証

認証をサポートするダイナミック ルーティング プロトコルを使用している場合、その認証を有効にすることが適切です。これは、インフラストラクチャのルーティング インテリジェンスに対する不正攻撃を防止します。また、ネットワークで正確に構成されていない 不適切な デバイスによって発生する損害を防止するのに役立ちます。ネイバーは、最も一般的なネットワーキング プロトコルを使用して、許可されていないデバイスがネットワークの安定性またはセキュリティに影響を与えていないことを確認するために、相互認証を行うことができます。それらの認証メカニズムは適正な運用を中断させる偶発的な攻撃を防止しますが、確信的な攻撃者を阻止するものとは期待されていません。

HSRP

例6-15 では、インターフェイス イーサネット 2/1 の HSRP グループ 21 に対して有効にした認証文字列「hsRp$af3」を示します。

例6-15 HSRP 認証を有効にする

拡張 IGRP（EIGRP）

例6-16 では、ゲートキーパーおよび 3640 ルータの 2 つのインターフェイス間に対して有効にした EIGRP 認証を示します。

例6-16 EIGRP 認証を有効にする

OSPF

例6-17 は、インターフェイス イーサネット 2/1 の エリア 2 に対して有効にした OSPF 認証文字列「0spFmd5」を示します。

例6-17 使用可能になった OSPF 認証

BGP

例6-18 では、ネイバー 171.70.209.2 の接続に対して使用可能にした BGP MD5 認証文字列「BgP%md5」を示します。

例6-18 使用可能にした BGP 認証

デバイス時間、タイムスタンプ、およびロギングの設定

現在でも、正確なロギングは、侵入者を特定するには最も有効なツールの 1 つです。正確なログを取得するには、次のステップをすべてのネットワーク要素で実行する必要があります。

ステップ 1 正確な中央集中型の時間源を使用するようにすべてのデバイスを構成します。

ステップ 2 Cisco IOS デバイスでタイムスタンプを使用可能にします。

ステップ 3 ロギング情報を受信するシステムログ サーバを指定します。

ネットワーク タイム プロトコル

NTP（ネットワーク タイム プロトコル）は、マシンのネットワーク タイムを同期化するように設計されたプロトコルです。NTP は UDP を通過し、次に IP を通過します。NTP は RFC 1305 に文書化されています。通常、NTP ネットワークでは、ネットワーク タイムは、タイム サーバに接続されたラジオ クロック、またはアトミック クロックなどの信頼性のある時間源から取得されます。その後、NTP はネットワーク全体にそのタイムを配信します。NTP は非常に効果的です。2 つのマシンを互いに 1 ミリ秒以内に同期化するには、わずか 1 パケット/分しか必要ありません。

図 6-25 では、企業は 1 つのルータを指定して Statum 1 クロックを照会しています。その後、その他すべてのネットワーク デバイスが順に NTP 情報を取得するために、この 1つのルータを照会します。NTP 認証を使用可能にすることを推奨します。

図 6-25 ネットワーク タイム プロトコル

例6-19 Cisco IOS ルータで使用可能になったネットワーク タイム プロトコル

例6-20 Catalyst イーサネット スイッチで使用可能になったネットワーク タイム プロトコル

タイムスタンプ

中央時間源を使用するようにすべてのデバイスを構成した後、ルータとスイッチの両方でログの正確なタイムスタンプを使用可能にする必要があります。

例6-21 Cisco IOS ルータで使用可能になったタイムスタンプ

例6-22 Catalyst イーサネット スイッチで使用可能になったタイムスタンプ

システムログ サーバ

すべてのシステム通知とエラー メッセージをロギングすると、ネットワークの運用ステータスの貴重な見識をたびたび得ることができます。アクセス リスト違反がログされると、ネットワークを調査中であるか、あるデバイスが危険にさらされたかを判断するため、デバイス間でそのログを関連付けることもできます。

次の例では、10.21.101.10 でシステムログ サーバ ロギングが使用可能になったこと示します。

例6-23 ロギング使用可能化 ― Cisco IOS ルータ

例6-24 ロギング使用可能化 ― Catalyst イーサネット スイッチ

表 6-24 では、使用可能なロギング重大度レベルのリストを示します。

IP ネットワークの設計

IP Phoneをインストールする前に、有効で安全な IP ネットワークを設計する必要があります。その設計には、次のものを含む必要があります。

• 個別のブロードキャスト ドメイン

• IP テレフォニー 機器の論理アソシエーション

• 分離された IP テレフォニー 管理サーバ

• セキュリティの関係

• 外部攻撃者および内部ユーザから保護された境界

安全な IP テレフォニー ネットワークを構築する場合、次のルールに従う必要があります。

• 独立した IP ネットワーク（VLAN）に、すべての CallManager、IP テレフォニー アプリケーション サーバ、および IP Phoneを設置します。また、それらの VLAN は、組織のデータ ネットワークによって使用される VLAN とは分離する必要があります。可能な場合には、RFC 1918 の IP アドレス スペース（インターネットへの経路がない）を使用して、さらに IP テレフォニー ネットワークを分離します。NAT については、コール センター アプリケーション、SoftPhone、または WebAttendant によって要求される場合に限り、慎重に使用する必要があります。

インターネット ゲートウェイ ルータとファイアウォールは、インターネットと IP テレフォニー 間接続の NAT 変換に対応できません。SoftPhone の実装により、別個のネットワークへの音声とデータの分離に影響を与えるデータ ネットワークに常駐するコンピュータに音声機能が設定されるので留意してください。

• IP フィルタまたはファイアウォールは、IP テレフォニー ネットワークと組織のデータ ネットワーク間のゲートウェイ ルータで使用し、組織のネットワーク内部から発生する可能性がある不正な攻撃を阻止する必要があります。

• また、ファイアウォールは、組織のインターネット接続、パートナー接続、および CallManager クラスタのフロントで使用する必要があります。

• 侵入検知ツールは、攻撃に対してモニタするネットワークの戦略ポイントに設定する必要があります。

ここで説明したルールについて、次に詳しく解説します。

VLAN および ブロードキャスト ドメインの作成と割り当て

パケットがレイヤ 3（IP）デバイスで衝突する場合には、IP テレフォニー ソリューションの大部分を実装する必要があります。プロトコル アーキテクチャ、MAC レイヤ、またはレイヤ 2 により、本来のセキュリティ能力が非常に低下します。このため、ブロードキャスト ドメインを理解して確立することが、安全な IP ネットワークを設計する際の基本的な指針です。攻撃デバイスがターゲット システムと同じブロードキャスト ドメインに常駐する場合、単純とはいえ危険な攻撃が多く発生する可能性があります。

この IP プロトコルに本来備わっている脆弱性を緩和するには、脆弱性が潜在する次のターゲット エンドポイントを常にそれらの独自のサブネットに設定して、残りのデータ ネットワークや相互のエンドポイントから分離する必要があります。

• サーバ

• CallManager クラスタ

• IP Phone

• VoIP ゲートウェイ

• ネットワーク管理ワークステーション

さらに、各デバイスでは別々のスイッチ セグメントを使用して、ネットワークに接続します。別々のセグメント（つまり、スイッチ型イーサネット インフラストラクチャ）を使用する理由は、攻撃者または攻撃アプリケーションによって、物理ワイヤを経由しているイーサネット トラフィックがスヌーピングまたはキャプチャされないようにするためです。各デバイスがスイッチ型インフラストラクチャを使用したネットワークに接続することを保証することで、パケット スニッフィング ツールが他のユーザのトラフィックのキャプチャに機能しなくなります。さらに、推奨する Cisco IP テレフォニー の設計モデルでは、802.1Q VLAN トランキング テクノロジーを使用することによって、IP Phoneと添付データそれぞれのサブネットを使用します。

図 6-26 は、一例の企業ネットワークを構成する主要な各コンポーネントを示します。

（注） すべての IP テレフォニー デバイスは、音声 IP ネットワーク 10.x.x.x の各種サブネットおよび VLAN に常駐し、PC、電子メール サーバ、DHCP サーバなどのすべてのデータ断片は、IP ネットワーク 172.21.x.x に常駐します。さらに、これは、別々のセグメントに常駐する各ユーザーおよびデバイスを含む完全なスイッチ型イーサネット環境です。

図 6-26 企業ネットワークの主要コンポーネント

（注） スタティック IP アドレスを割り当てるか、音声ネットワーク内に設置された IP テレフォニー 固有の分離した DHCP サーバを使用すると、組織の既存の DHCP サービスを使用するよりも IP Phoneの IP アドレス管理のソリューションの方がさらに安全になります。

IP アドレッシング および NAT

VLAN 配置が完了すると、実際の IP アドレッシングが実行されます。RFC 1918 パブリック アドレス スペースの使用は、IP テレフォニー ネットワークに対して推奨されます。

• 既存のデータ ネットワークで IP およびサブネットを再構成する必要がなければ、IP テレフォニー 配備が非常に容易になります。

• IP テレフォニー と データ ネットワークを容易に分離するには、異なるアドレス スペースを使用すると確定的になります。

• NAT（Network Address Translation）自体はセキュリティを保証するものではありませんが、適切に使用すると、IP テレフォニー ネットワークのセキュリティを補強するツールになります。

RFC 1918 アドレスおよび NAT の使用を含む、熟考された IP アドレッシング方式を使用すること、インターネット ゲートウェイ ルータまたはインターネット ファイアウォールを変更しなくても、IP テレフォニー ネットワークをインターネットから分離することができます。

図 6-27 は、NAT を使用した論理 IP アドレスの分離を示します。

図 6-27 NAT を使用した論理 IP アドレスの分離

パケット フィルタまたはファイアウォール機能の設定

IP フィルタの使用は、安全なネットワークを構築する上で不可欠な部分です。IP テレフォニー ネットワークの保護時に IP フィルタを使用することを強く推奨します。ほとんどの組織では、IP テレフォニー と データ ネットワークを分離するルータまたはファイアウォールに IP フィルタを設定します。

図 6-28 は、IP フィルタの配置を示します。

図 6-28 IP フィルタの配備

ダイレクテッド ブロードキャスト

IP ダイレクテッド ブロードキャストは、よく知られているサービス拒絶スマーフィング攻撃とその派生攻撃に使用されます。IP ダイレクテッド ブロードキャストとは、送信マシンに直接接続していないサブネットのブロードキャスト アドレスに送信されるデータグラムです。ダイレクテッド ブロードキャストは、ターゲット サブネットに到達するまで、ユニキャスト パケットとしてネットワーク経由でルーティングされます。そのサブネットでダイレクテッド ブロードキャストがリンク層ブロードキャストに変換されます。IP アドレッシング アーキテクチャの性質により、ターゲット サブネットに直接接続していない、連鎖しているルータの最後のルータだけが最終的にダイレクテッド ブロードキャストを識別できます。ダイレクテッド ブロードキャストは、正当な目的に使用されることもありますが、金融サービス業界以外では、そのような使用は一般的ではありません。

スマーフィング攻撃では、攻撃者はスプーフィングされた正当な送信元アドレスからダイレクテッド ブロードキャスト アドレスに ICMP（インターネット制御メッセージ プロトコル）のエコー要求を送信します。これにより、ターゲット サブネットのすべてのホストがスプーフィングされた送信元への応答を送信します。そのような要求の流れを継続的に送信することによって、攻撃者は大量の応答の流れを作り出します。その結果、スプーフィングされている正当なホスト アドレスに大量の返信が殺到します。

no ip directed-broadcast コマンドを使用して Cisco ルータ インターフェイスを設定した場合、ダイレクテッド ブロードキャストがそのインターフェイスのリンク層ブロードキャストに爆発的に展開されなければ、ダイレクテッド ブロードキャストはドロップされます。その結果、ターゲット サブネットに接続されるすべてのルータのあらゆるインターフェイスに no ip directed-broadcast コマンドを設定する必要がありますが、ファイアウォール ルータだけを構成するのは不十分なので注意してください。 no ip directed-broadcast コマンドは、Cisco IOS ソフトウェア バージョン 12.0 以降でデフォルトになっています。それ以前のバージョンでは、そのコマンドをすべての LAN インターフェイスに適用する必要があります。

ソースルート パケット

IP プロトコルでは、ソース ルーティング オプションがサポートされます。ソース ルーティング オプションを使用して、IP パケットの送信者はパケットがその最終の宛先に搬送されるルート、および一般的に応答が搬送されるルートを制御できます。ソース ルーティング オプションは、実際のネットワークで正当な目的に使用されることはほとんどなく、企業ネットワークのホストを攻撃するために使用されます。 no ip source-route コマンド セットを指定した Cisco ルータを使用すると、ソース ルーティング オプションを搬送する IP パケットが転送されません。企業内の IP テレフォニー およびデータ ネットワークを接続しているゲートウェイ ルータだけでなく、インターネットに接続したルータにも、このコマンドを使用する必要があります。

IP スプーフィング

多くの広範囲におよぶサービス拒絶攻撃は、攻撃者が偽造された（スプーフィングされた）送信元アドレスを使用して、パケットを送信できるようにすることで行われます。そのため、攻撃の正確な発信元を突き止めることが非常に難しくなります。サイトがそれらのタイプの送信元とならないようにするには、各自のアドレス スペース外の任意の送信パケットをブロックする必要があります。

例6-25 では、内部ネットワークと一致する送信元アドレスをもつ受信パケットをブロックするだけでなく、172.21.0.0 のサイトの架空アドレス ブロックとソースとしない送信パケットも阻止します。また、スプーフィングされたトラフィックを阻止するために、サービス プロバイダ ネットワークに RFC 2827 IP アドレス ブロッキングを設定することを推奨します。

例6-25 アクセス リストの許可

ICMP リダイレクト

ICMP リダイレクト メッセージにより、エンド ノードにその IP 宛先のパスとして特定のルータを使用するように通知されます。正常に機能している IP ネットワークでは、エンド ノードではなく、ルータによってリダイレクトがルータ独自のローカル サブネット上のホストだけに送信され、リダイレクトは複数のネットワーク ホップを経由しません。ただし、攻撃者はそれらのルールに違反する可能性があります。実際に、ルールに違反する攻撃があります。

この攻撃を避けるには、IP テレフォニー ネットワークとデータ ネットワーク間の境界ルータですべての ICMP リダイレクトをフィルタに掛けます。

例6-26 ICMP リダイレクトのフィルタリング

（注） ICMP リダイレクトのフィルタリングは、少なくとも 1 つのネットワーク ホップで攻撃者が開始したリダイレクト攻撃だけを阻止します。攻撃者が同じサブネットに接続している場合、依然としてこの攻撃を開始することが可能です。これが、ユーザ ワークステーション、データ サーバなどのすべての データ デバイスが、すべての音声デバイスとエンドポイントから分離したネットワークに常駐することを確認するというもう 1 つの理由です。

IP テレフォニー およびその他のサービスの許可

非常に厳しいセキュリティ ポリシーを持つ組織では、音声ネットワークとデータ ネットワーク間のあらゆる接続を禁止します。その禁止によって、攻撃の脅威がかなり低くなります。ただし、多くの組織は、データ ネットワークと IP テレフォニー ネットワーク間のとにかく最小限の通信をポリシー、アプリケーション、またはコスト的な理由で要求します。たとえば、一部の組織では、2 台目のサーバの購入に伴うコスト増加と管理の複雑化のため、音声デバイスとデータ デバイスに別々の DHCP サーバを使用する考えがない場合があります。

表 6-25 は、データ ネットワークとテレフォニー ネットワーク間に開放できる、あるいは開放する必要のあるアプリケーションとポートのリストを示します。

表 6-25 データ ネットワークとテレフォニー ネットワーク間で開放するアプリケーションおよびポート

アプリケーション	ポート	方向	要件
ルーティング プロトコル	プロトコルに依存する	方向：両方向	IP ルーティング
DHCP	UDP 67、68	送信元：音声ネットワーク 送信先：データ ネットワークの DHCP サーバ 方向：両方向	PC と IP Phoneに使用する 1 つの企業全体の DHCP。さらに安全性を高めるには、IP Phoneにスタティック IP アドレスを使用するか、IP テレフォニー 特定の分離した DHCP サーバを使用します。
ICMP	IP ICMP エコー	送信元/送信先：ネットワーク管理サブネットと音声ネットワーク 方向：両方向	基本的なトラブルシューティング。すべてのネットワーク管理ワークステーションにこの特権を付与するだけです。
NTP	TCP 123 UDP 123	送信元：ルータ、スイッチ、ゲートウェイ、CallManager、および管理サーバ 送信先：信頼できる企業の NTP サーバ 方向：一方向	トラブルシューティングおよびトラッキングに使用するすべてのネットワーク要素で同期化したタイムスタンプ。
Telnet	TCP 23	送信元：ネットワーク管理サブネット 送信先：音声ネットワーク 方向：一方向	構成とトラブルシューティング。Telnet よりも SSH の方を優先すべきです。ネットワーク管理ワークステーションにこの特権を付与するだけです。
SSH	TCP 22	送信元：ネットワーク管理サブネット 送信先：あらゆるサブネットのすべてのルータ 方向：一方向	構成とトラブルシューティング。SSH により、ネットワーク要素のより安全な管理方式が提供されます。
FTP	TCP 20, 21	送信元：音声ネットワークの CallManager パブリッシャと TFTP サーバ 送信先：データ ネットワーク FTP サーバ（組織のインターネット ファイアウォールの背後にある） 方向：一方向	Cisco Connection Online から IP テレフォニー ソフトウェアの新しいバージョンをダウンロードする場合、データ ネットワーク FTP サーバを使用してコードをダウンロードしてから、追加ステップとして IP テレフォニー ファイアウォールを通過する FTP にアクセスすることで、そのソフトウェアをダウンロードすることを推奨します。
RADIUS	UDP 1645, 1646, 1812, 1813	送信元：音声ネットワーク 送信先：組織の RADIUS サーバ 方向：一方向	ルータ、スイッチ、および VoIP ゲートウェイ アクセス設定。ポートは、Cisco IOS（1645-46）または CatOS（1812-13）に依存します。
TACACS+	TCP 49	送信元：IP テレフォニー ネットワーク 送信先：組織の TACACS+ サーバ 方向：一方向	ルータ、スイッチ、および VoIP ゲートウェイ アクセス設定。
DNS	UDP 53	送信元：音声ネットワーク 送信先：DNS サーバ 方向：一方向	CCM サーバ ルックアップ、TFTP サーバ ルックアップ、FTP サーバ ルックアップ、IP Phone、LDAP、ゲートウェイ、IP テレフォニー ネットワーク管理サーバ
LDAP	TCP 389	送信元：音声ネットワーク 送信先：LDAP サーバ 方向：一方向	LDAP 機能性
SoftPhone	TAPI/JTAPI = TCP 2748 VoIP メディア ストリーム = UDP 16384-32767	送信元/送信先：データネットワークと CallManager 方向：両方向	ユーザの PCに常駐する SoftPhone。SoftPhone の機能性により、音声機能は、別個のネットワークへの音声とデータの分離に影響を与えるデータ ネットワークに常駐するコンピュータに設定されます。
SoftPhone CCM Directory Lookup	TCP 8404	送信元：SoftPhone クライアント 送信先：CallManager の TCP ポート 8404 方向：一方向	CCM/SoftPhone ディレクトリ サービスの使用。 （注） TCP 389を使用して組織の LDAP サービスを照会するために、SoftPhone には LDAP クライアントもあります。
IP IVR	TAPI/JTAPI = TCP 2748 VoIP メディア ストリーム = UDP 16384-32767	送信元：IP IVR サーバ 送信先：音声ネットワーク 方向：両方向	IP IVR サーバを IP テレフォニー ネットワークではなく、データ ネットワークに配置する場合に要求されるだけです。このサービスをデータ ネットワークに配置すると、別個のネットワークへの音声とデータの分離に影響します。
IPCC	TAPI/JTAPI = TCP 2748	送信元：GeoTel IPCC サーバ 送信先：CallManager 方向：両方向	IPCC サーバを IP テレフォニー ネットワークではなく、データ ネットワークに配置する場合に要求されるだけです。このサービスをデータ ネットワークに配置すると、別個のネットワークへの音声とデータの分離に影響します。
HTTP	TCP 80	送信元：ネットワーク管理サブネットと場合によってはすべてのユーザ ワークステーション 送信先：CallManager 方向：一方向	音声ネットへの Web アクセス
Skinny Client	TCP 2000	送信元：CallManager 送信先：音声ゲートウェイ ルータ 方向：一方向	コールのセットアップおよび制御
Skinny ゲートウェイ（アナログ）	TCP 2001	送信元：CallManager 送信先：音声ゲートウェイ ルータ 方向：一方向	コールのセットアップおよび制御
Skinny ゲートウェイ（デジタル）	TCP 2002	送信元：CallManager 送信先：音声ゲートウェイ ルータ 方向：一方向	コールのセットアップおよび制御
H.323 RAS	TCP 1719	送信元：CallManager 送信先：音声ゲートウェイ ルータ 方向：一方向	コールのセットアップおよび制御
H.323（H.225）	TCP 1720	送信元：CallManager 送信先：音声ゲートウェイ ルータ 方向：一方向	コールのセットアップおよび制御
H.323（H.245）	TCP 11000 ～ 11999	送信元：CallManager 送信先：音声ゲートウェイ ルータ 方向：一方向	コールのセットアップおよび制御
MGCP	UDP 2427 および TCP 2428	送信元：CallManager 送信先：音声ゲートウェイ ルータ 方向：一方向	コールのセットアップおよび制御
SNMP	UDP 161	送信元：ネットワーク管理デバイス 送信先：SNMP 管理デバイス 方向：一方向	SNMP ネットワーク管理
SNMP TRAP	UDP 162	送信元：SNMP 管理デバイス 送信先：ネットワーク管理デバイス 方向：一方向	SNMP ネットワーク管理

例6-27 は、音声ネットワークとデータ ネットワーク間のゲートウェイとしてルータを示します。

例6-27 Cisco IOS ファイアウォールの設定

VoIP ゲートウェイの保護

VoIP ゲートウェイは、CallManager サーバからコール セットアップの試行を受け入れるだけです。これは、VoIP ゲートウェイのアクセス リストを設定することによって実行できます。例6-28 は、CallManager クラスタ サブネットからコール セットアップの試行を受け入れるだけの VoIP ゲートウェイを示します。

（注） この例では、VoIP ゲートウェイは音声ネットワークに常駐します。

例6-28 VoIP ゲートウェイ ルータ インターフェイスおよび ACL

ファイアウォール

IT 部門では、インターネット ファイアウォールをネットワーク セキュリティ インフラストラクチャの不可欠な部分であると考えています。この項の目的は、インターネット セキュリティではなく、IP テレフォニー セキュリティであるため、SAFE などの安全なネットワーク設計方式を使用して、インターネット セキュリティ ポリシーとアーキテクチャがすでに確立していることを前提とします。健全なセキュリティ ポリシーは、外部のパートナー接続にファイアウォール方式を追加する必要があることを要求します。それらの追加が実行されると、IP テレフォニー ネットワークが構築され、既存の IP データネットワークに接続されます。また、別のファイアウォールを CallManager クラスタと残りの組織のネットワーク間に追加する必要があります。

図 6-29 は、CallManager クラスタとネットワーク間のファイアウォールの配置を示します。

図 6-29 CallManager とネットワーク間のファイアウォールの配置

ファイアウォールは、Cisco Secure Integrated Software（Cisco IOS Firewall）を実行するルータ、PIX ファイアウォール、サード パーティ製のファイアウォールのいずれかから選択できます。ファイアウォールの基本的な選択基準は、次のとおりです。

• ファイアウォール セキュリティ機能の長所

• 接続を処理する速度

• ハイ アベイラビリティ

• ファイアウォールと既存のネットワーク インフラストラクチャの統合方法

CallManager クラスタと音声ネットワーク、データ ネットワーク間にファイアウォール配置することで、ネットワーク設計者は IP テレフォニー のコール処理インテリジェンスで最も重要なコンポーネントの漏洩をかなり減らすことができます。ファイアウォールは、すべての IP デバイスと CallManager 間で信頼できるプロキシとして機能し、認証されたトランザクションだけを許可するようにします。

このファイアウォールは、音声ネットワークと CallManager クラスタ サブネット間に配置されます。ファイアウォールが EIGRP トラフィックをパスできなくなるため、Network Address Translation（NAT）をこのファイアウォールで使用できないので注意してください。よって、CallManager クラスタを往復する経路を静的に構成し、必要に応じて再分散する必要があります。

例6-29 には、ファイアウォールから CallManager クラスタまでに許可できるトランザクションのリストが含まれます。

例6-29 PIX ファイアウォール ソフトウェア バージョン 5.x の設定