Cisco テクニカル ソリューション シリーズ:IP テレフォニー ソリューション ガイド
IP テレフォニー ネットワークの運用
IP テレフォニー ネットワークの運用
発行日;2012/01/08 | ドキュメントご利用ガイド | ダウンロード ; この章pdf | フィードバック

目次

IP テレフォニー ネットワークの運用

関連情報

運用サポートとプラニング

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

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

ライフ サイクル管理

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

サービス レベルの目標

関係者の決定

サービス要素の定義

対処的サービス要素

予防的サービス要素

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

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

ネットワーク管理

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

障害管理

構成管理

課金管理

性能管理

機密管理

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

CiscoWorks2000

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

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

管理ツールの選択基準

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

障害管理

構成ファイルの管理

ソフトウェアの管理

課金管理

性能管理

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

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

Cisco IP Phoneの管理

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

計画、設計、および実装

日常の運用

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

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

IP テレフォニー ネットワークの保護

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

物理セキュリティの確立

ネットワーク要素の保護

Telnet アクセス

Cisco IOS ルータ

Catalyst イーサネット スイッチ

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

適切なパスワードの選択

セキュア シェル

簡易ネットワーク管理プロトコル(SNMP)

HTTP

Cisco Discovery Protocol

警告バナー

回線設定

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

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

ネイバー認証

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

IP ネットワークの設計

VoIP ゲートウェイの保護

ファイアウォール

侵入検知システム

CallManager サーバの保護

パッチ

不要なサービスの停止

ファイル システム アクセスの保護

システムの監査およびロギング

IIS の保護

SQL Server の保護

会議ソフトウェアおよび会議サービスのアンインストール

CallManager SNMP の構成

独立した TFTP サーバの使用

独立したサーバへのすべての IP Phoneの Web サービスの移動

IP テレフォニー ネットワークのトラブルシューティング

トラブルシューティング ツール

Cisco CallManager Administration の詳細

Microsoft Performance Monitor

Microsoft Event Viewer

CallManager トレース

SDL トレース

スニッフィング トレース

コール詳細レコード(CDR)とコール管理レコード(CMR)

Q.931 Translator

Cisco CallManager デバイスのトラブルシューティング

音声品質

IP Phoneのリセット

コール ドロップ

Cisco CallManager の機能問題

サーバ応答の低速化

ゲートウェイを経由するリオーダー トーン

ゲートウェイ登録の問題

ゲートキーパー登録の問題

Cisco IP Phoneの初期化プロセス

Skinny Station の登録プロセス

Cisco CallManager の初期化プロセス

自己起動プロセス

Cisco CallManager の登録プロセス

Cisco CallManager のキープアライブ プロセス

コール フロー時における Cisco IP Phoneと Cisco IP Phone間の Skinny Station メッセージの交換

Cisco CallManager クラスタ間のコール フローのトレース

Cisco IOS ゲートウェイ

国際電話番号のダイヤル後のビジー信号の発生

クラスタ間 IP Phone 対 IP Phone

コール フローのトレース

失敗したコール フロー

コール詳細レコード

レコードの書き込み

レコードの読み込み

レコードの削除

テーブル スキーマ

既知の問題

コール詳細レコードのフィールド

コール タイプ別にログされたコール レコード

コール タイプ別にログされたコール管理レコード

コーデック タイプ(圧縮/ペイロード)

理由コード

アラーム

IP テレフォニー ネットワークの運用

この章の構成は、次のとおりです。

運用サポートとプラニング

ネットワーク管理

IP テレフォニー ネットワークの保護

IP テレフォニー ネットワークのトラブルシューティング

関連情報

関連情報については、次の Web サイトを参照することもできます。

Cisco Network Monitoring and Event Correlation Guidelines

http://www.cisco.com/warp/partner/synchronicd/cc/pd/wr2k/tech/cnm_rg.htm

Cisco MIB Files

http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml

Cisco IP Telephony Troubleshooting Guide for Cisco CallManager Release 3.0(1)

http://www.cisco.com/warp/public/788/AVVID/ts_ccm_301_sec1.htm

CiscoWorks Enterprise Network Management Solutions

http://www.cisco.com/univercd/cc/td/doc/pcat/index.htm#CFHBHEAF

運用サポートとプラニング

テレコミュニケーション ネットワーク、データ ネットワーク、およびサーバは現在、程度の差はあれ独立したグループにより管理されています。したがって、グループの管理者は適正かつ容易にサービスの問題を識別することができます。一般的に、パフォーマンス、キャパシティ、プロビジョニング、障害管理、在庫管理などに関わる運用プロセスは、グループ間で話し合わなくても各グループで独自に管理されています。また、各グループでは、既存の要件を満たす独自の目標またはサービス要件を含むそれぞれ独立したサポート計画を立案しています。

しかし、IP テレフォニー ソリューションでは、新しいサポート モデルが次の理由で必要です。

グループまたは個人レベルで今まで相互の対話は必要なかったが、IP テレフォニー ソリューションでは相互に密接に作業する必要がある。

特定の IP テレフォニー の要件を満たすには、新しいサポート プロセスが必要になる。

新しい役割と責務が IP ソリューションのすべての領域における各レベルでサポートを確実にするために必要となる。

音声トラフィックのアベイラビリティを向上するためのサービス要件が拡張される必要がある。

長期間にわたって一貫性のある信頼性の高いソリューションを実現するには、システムの運用をサポートする組織が、そのサポート要件を検討することをお勧めします。これらの要件には、役割と責務の変更、新しいプロセスの追加、プロセスの変更、およびサービス定義の変更を含めることができます。サポート要件の検討では、まず IP テレフォニー ソリューションの技術的な制約を検討し、続いてその役割と責務を決定してから、最後にサービス要素を定義および承認すると最善の検討策となります。

表 6-1 では、IP テレフォニー の運用に関する多くの運用要件をリストで示します。

 

表 6-1 技術サポート対応表

構成
障害
パフォーマンス
セキュリティ
アカウンティング

IP テレフォニー アプリケーション レベル

変更管理
MAC プロセス

ダイヤル計画

CallManager アプリケーションとアベイラビリティの監視

CallManager 使用率コール

音声品質

ユーザ ID

パスワード

コール詳細レコード

課金不正の検出

プラットフォーム オペレーティング システム

CallManagerのバックアップと復旧

モニタ装置、SNMP モニタリング

ディスク スペース

RAM

CPU

ユーザ ID

パスワード

システム イベント ログ

LAN/WAN ネットワーク

DCHP、DNS、TFTP、および IP アドレス

Catalyst スイッチとルータ

LAN トラフィックのデバイス リソース

ユーザ ID

パスワード

システム ログ

NAT キット

ハードウェア

サーバ、スイッチ、ルータ、および
ケーブリング配線

24x7x4 障害対応オンサイト サポート

MTBF(平均故障間隔)

MTTR(平均修復時間)

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

 

表 6-2 技術上の目標および制約

リスクまたは制約
制約のタイプ
予想されるインパクト

ネットワーク全体の遅延が一貫して 250 ミリ秒またはそれ以下の VoIP 要件

IP テレフォニー または VoIP アプリケーション

一貫して 25ミリ秒またはそれ以下のジッタを要求する VoIP ジッタ

IP テレフォニー または VoIP アプリケーション

IP テレフォニー のテクノロジー安定性とソリューション経過時間

IP テレフォニー または VoIP アプリケーション

エンドツーエンド パフォーマンスのジッタと遅延を管理するパフォーマンス ツールが設定されない

ライフ サイクル プロセス/テクノロジー

中/高

一部のゲートウェイにおけるシングル ポイント障害

テクノロジー

中(ただし、冗長となる可能性あり)

一部の CallManager クラスタにおけるシングル ポイント障害

テクノロジー

中(ただし、冗長となる可能性あり)

現在のテレコミュニケーション インフラを利用して存在する電話に対して、配線室に UPS システムがない、および非常用電源がない

テクノロジー

中(ただし、ソリューションあり)

電話の IP 管理がない

テクノロジー

中~低

冗長性のない DHCP サービス

テクノロジー

冗長性のない DNS サービス

テクノロジー

音声ゲートウェイのダウンした IDNS チャネルを特定するツールまたはプロセスがない

ライフ サイクル プロセス/テクノロジー

キャパシティに対する付加的な音声トラフィックへのインパクト

テクノロジー

中低

LAN 環境に QOS が設定されていない

テクノロジー(ただし、アップグレード可能)

CallManager の問題を特定するために、アラートと SYSLOG リビューのプロセスを高度化する必要がある

ライフ サイクル管理

ハードウェア障害による CallManager またはゲートウェイの交換を 4 時間で達成できるチームが指定されていない

ライフ サイクル管理

CallManagerの問題に対するネットワークの解決が容易になる

ライフ サイクル管理

重要なサイトへの冗長な WAN リンクにおける帯域幅の冗長性がない

テクノロジー(ただし、アップグレード可能)

サービス レベルの目標

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

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

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

ソフトウェアの信頼性

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

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

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

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

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


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


 

表 6-3 IP テレフォニー のサービス目標

ネットワーク領域
アベイラビリティ目標
測定方法
平均ネットワーク応答時間目標
許容最大
応答時間
許容最大ジッタ

LAN

99.99%

Ping モニタリング(ツールは未定)

50 ミリ秒未満(ラウンドトリップ ping)

250 ミリ秒

20 ミリ秒
(特定されるジッタ測定)

WAN

99.9%

Ping モニタリング(ツールは未定)

100 ミリ秒未満(ラウンドトリップ ping)

250 ミリ秒

20 ミリ秒
(特定されるジッタ測定)

関係者の決定

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

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

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

サービス要素の定義

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

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

対処的サービス要素

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

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

障害モニタリング

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

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

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

災害回復プロセス

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

予防的サービス要素

変更管理

MAC(移動、追加、変更)プロセス

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

IP/DHCP 管理

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

不正アクセスの検出

課金

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

対処的サービス要素

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

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

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

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

 

表 6-4 サポート重大度

重大度 1
重大度 2
重大度 3
重大度 4
重大なビジネスへの影響
損失または劣化による重大なビジネスへの影響(可能な回避方法あり)
特定のネットワーク機能が欠落または劣化する(冗長性の損失など)
組織のビジネスに影響しない機能クエリーまたは障害

LAN ユーザまたはサーバ セグメントの障害

重要な WAN サイトの障害

サイトの 25% 以上の電話の障害、または機能の重大な劣化

5 ~ 99 ユーザに影響するキャンパス LAN の障害

国内 WAN サイトの障害

海外 WAN サイトの障害

重大なパフォーマンスの影響

サイトの 15% 以上の電話の障害、または機能の若干劣化

キャンパス LAN パフォーマンスの影響

LAN 冗長性の喪失

単一の電話の停止またはサービスに影響する問題

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

 

表 6-5 階層型サポートの例

サポート階層
責務
目標

階層 1

24 時間のヘルプ デスク サポート

サポート コールの応答、トラブル チケットの発行、最高 15 分間までの問題検討

チケットの文書化および適切な階層 2 サポートへエスカレート

着信コールの 40% を解決する

階層 2

キュー モニタリング、ネットワーク管理ステータス モニタリング

ソフトウェア問題のトラブル チケットの発行

実装

階層 1、ベンダーおよび階層 3 のエスカレーションからのコールの応答

解決にいたるまでのコール所有権の保持

着信コールの 100% を解決する

階層 3

階層 2 のすべての優先順位 1 の問題に対する即時サポート

階層 2 の SLA 解決期間内に解決されていないすべての問題に関するサポート対応

問題として残さない

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

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

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

 

表 6-6 サービス応答と解決目標

重大度
ヘルプ デスク応答
階層 2 の
応答
オンサイトの階層 2
ハードウェア交換
解決

1

階層 2、ネットワーク運用管理者にただちにエスカレート

5 分

2 時間

2 時間

4 時間

2

階層 2、ネットワーク運用管理者にただちにエスカレート

5 分

4 時間

4 時間

8 時間

3

15 分

2 時間

12 時間

24 時間

36 時間

4

15 分

4 時間

3 日間

3 日間

6 日間

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

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

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

 

表 6-7 重大度レベル エスカレーションの対応表

経過時間
重大度 1
重大度 2
重大度 3
重大度 4

5 分

ネットワーク運用管理者、階層 3 のサポート、ネットワーキングの監督者

 

 

 

1 時間

ネットワーク運用管理者、階層 3 のサポート、ネットワーキングの監督者への進捗報告

ネットワーク運用管理者、階層 3 のサポート、ネットワーキングの監督者への進捗報告

 

 

2 時間

VP へのエスカレーション、監督者、運用管理者への進捗報告

 

 

 

4 時間

ルートによる根本原因の分析結果を、VP、ネットワーク運用管理者、階層 3 のサポート、ネットワーキングの監督者へ説明

解決しない場合には CEO 通知が必要

VP へのエスカレーション

監督者と運用管理者への進捗報告

 

 

24 時間

 

 

ネットワーク運用管理者

 

5 日間

 

 

 

ネットワーク運用管理者

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

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-8 デバイス ダウン検出のモニタリング

デバイス タイプ
問題の特定方法
ポーリング間隔
または検出間隔
処置

CallManager

SNMP ポーリング

5 分

NOC で優先順位 1 のチケットを作成(CM 冗長性については優先順位 3)

PSTN ゲートウェイ

SNMP ポーリング

5 分

NOC で優先順位 1 のチケットを作成(CM 冗長性については優先順位 3)

音声メール ゲートウェイ

SNMP ポーリング

5 分

NOC で優先順位 2 のチケットを作成(CM 冗長性については優先順位 3)

コア スイッチ

SNMP ポーリングおよびトラップ通知

5 分

NOC で優先順位 1 のチケットを作成(CM 冗長性については優先順位 3)

エッジ スイッチ

SNMP ポーリングおよびトラップ通知

5 分

優先順位 1 のチケットを作成

コア ルータ

SNMP ポーリングおよびトラップ通知

5 分

優先順位 1 のチケットを作成(CM 冗長性については優先順位 3)

デスクトップ

なし

適用なし

適用なし

IP Phone

なし

適用なし

適用なし

データ センターの
スイッチ リンク

SNMP ポーリングおよびトラップ通知

5 分

NOC で優先順位 1 のチケットを作成(リンクの冗長性については優先順位 3)

コア スイッチ リンク

SNMP ポーリングおよびトラップ通知

5 分

NOC で優先順位 1 のチケットを作成(リンクの冗長性については優先順位 3)

コア ルータ リンク

SNMP ポーリングおよびトラップ通知

5 分

NOC で優先順位 1 のチケットを作成(リンクの冗長性については優先順位 3)

WAN スイッチ リンク

SNMP ポーリングおよびトラップ通知

5 分

NOC で優先順位 1 のチケットを作成(リンクの冗長性については優先順位 3)

エッジ スイッチ トランク

SNMP ポーリングおよびトラップ通知

5 分

優先順位 1 のチケットを作成(冗長性なし)

エッジ スイッチ ユーザ ポート

なし

適用なし

ユーザ レポート問題

デスクトップ

なし

適用なし

ユーザ レポート問題

IP Phone

なし

適用なし

ユーザ レポート問題

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

 

表 6-9 ネットワーク エラー

エラー カテゴリ
検出方法
しきい値
処置

ソフトウェア エラー(ソフトウェアによる強制クラッシュ)

SYSLOG ビューアを使用してシステム ログ メッセージを毎日確認する。これは 階層 2 のサポートが行う。

優先順位 0、1、および 2 の任意数のオカレンス。優先順位 3 以上の 100 個以上のオカレンス。

問題を確認し、新しいオカレンスの場合または問題に注意が必要な場合にはトラブル チケットを作成して送付する。

ハードウェア エラー(ハードウェアによる強制クラッシュ)

SYSLOG ビューアを使用してシステム ログ メッセージを毎日確認する。これは 階層 2 のサポートが行う。

優先順位 0、1、および 2 の任意数のオカレンス。優先順位 3 以上の 100 個以上のオカレンス。

問題を確認し、新しいオカレンスの場合または問題に注意が必要な場合にはトラブル チケットを作成して送付する。

プロトコル エラー
(IP ルーティング プロトコルのみ)

SYSLOG ビューアを使用して SYSLOG メッセージを毎日確認する。これは 階層 2 のサポートが行う。

優先順位 0、1、および 2 の 10 メッセージ/日。優先順位 3 以上の 100 個以上のオカレンス。

問題を確認し、新しいオカレンスの場合または問題に注意が必要な場合にはトラブル チケットを作成して送付する。

メディア制御エラー(FDDI、POS、およびファースト イーサネットのみ)

SYSLOG ビューアを使用してシステム ログ メッセージを毎日確認する。これは 階層 2 のサポートが行う。

優先順位 0、1、および 2 の 10 メッセージ/日。優先順位 3 以上の 100 個以上のオカレンス。

問題を確認し、新しいオカレンスの場合または問題に注意が必要な場合にはトラブル チケットを作成して送付する。

環境のメッセージ(電源および温度)

SYSLOG ビューアを使用してシステム ログ メッセージを毎日確認する。これは 階層 2 のサポートが行う。

任意のメッセージ。

新しい問題については、トラブル チケットを作成して送付する。

精度エラー(リンク入力エラー)

5 分間隔の SNMP ポーリング。NOC によって受信されたしきい値イベント。

入力または出力エラー。任意のリンクで 5 分間隔で 1 つのエラー。

新しい問題について、トラブル チケットを作成して階層 2 のサポートに送付する。

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

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

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

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

 

表 6-10 ネットワーク ファイルのバックアップおよび復旧サービス計画

デバイス
バックアップ方法
バックアップの責務
バックアップ期間
復旧の責務

CallManager

ネットワークの
CallManager ユーティリティを使用して サーバ XX のバックアップを行う

階層 2 の NT オペレーション(リモートの CallManager はバックアップしない)

毎日午前 6 時に完全バックアップを行う

階層 2 の NT オペレーション

IOS ゲートウェイ

ネットワーク TFTP

データ ネットワークの階層 2 のオペレーション

構成を変更した後

階層 2 のデータ ネットワーク オペレーション

IP Phone

CallManager に保存される情報なし

適用なし

適用なし

適用なし

DT-24 ゲートウェイ

CallManager に保存される情報なし

適用なし

適用なし

適用なし

その他のネットワーク デバイス

ネットワーク TFTP

データ ネットワークの階層 2 のオペレーション

構成を変更した後

階層 2 のデータ ネットワーク オペレーション

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 値を適用した場合に予想されるアベイラビリティを示します。

 

表 6-11 アベイラビリティと MTTR 値

デバイス
MTBF
4 時間の MTTR で持続するハードウェアのアベイラビリティ
24 時間の MTTR で持続するハードウェアのアベイラビリティの割合
4 時間のMTTR におけるアベイラビリティとデバイスの冗長性

デバイス 1

50,000 時間

99.992%

99.952%

99.99999%

デバイス 2

10,000 時間

99.996%

99.976%

99.99999%

組織では、ハードウェアを交換する方法には複数の選択肢があります。まず最も一般的な方法は、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 では、ユーザが追跡する情報を示します。

 

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

データベース レコードの情報
目的

ユーザ ID/ユーザ名

電話ユーザの特定

電話番号

電話番号の特定

電話区域

電話区域の特定

CallManager

電話に関連して設定されている CallManager の特定

クラスタ

設定されている CallManager クラスタを特定するため

電話モデル

電話モデルの特定(さらにシリアル番号も特定可能)

電話ボタン テンプレート

標準 IP Phone ボタン テンプレート、またはユーザ設定のテンプレート

デバイス プール

デバイス プールを使用して、Cisco CallManager の冗長化グループの分散をスケーリングおよび簡素化を行う。デバイス プールには、地域、日時グループ、および Cisco CallManager 冗長化グループを含めることができます。

コール検索スペース

コールの申し込み時にユーザが検索できるパーティションのリスト。検索スペース外の番号をダイヤルすると、話中音になります。

パーティション

電話、ルートパターン、ディレクトリ番号を含むユーザ/電話の到達可能性の特性。一例としては、パーティション名が Bldg-D という名前の ビルディング D に在籍するユーザがいます。

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

テレフォニー番号管理からディレクトリ番号を抽出する標準式(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-13 キャパシティ/パフォーマンス管理プロセス

プロセス
目標
検討期間

IP テレフォニー の
スケーラビリティ

CallManager を経由する電話および CallManager アプリケーションのスケーラビリティ要件を含む IP テレフォニー のスケーラビリティ要件を満たすことを確認する。

毎月または 3 ヶ月ごとに 1 回

ネットワーク パフォーマンス ベースラインの作成

安定したネットワーク パフォーマンス目標を満たし、予想されるアップグレード サイクル時間内に適切なキャパシティが存在することを確認するために、ネットワーク ベースラインを定期的に作成する。

毎月または 3 ヶ月ごとに 1 回

アプリケーション
プロファイリング

IP テレフォニー に影響を与えないように、新しいアプリケーションのベンチマークを作成してネットワークワーク動作を把握する。

新しいアプリケーションを配備する前

what-if 分析

ネットワークの変更が IP テレフォニー のパフォーマンスおよび音声品質に影響しないことを確認する。

リスクが生じるネットワーク変更が発生する前

パフォーマンスの例外分析

低パフォーマンス、高性能 CPU、大量の出力キュー、高いリンク使用率など、音声品質に影響するネットワーク パフォーマンスの例外を監視およびレポートする。

問題を特定して ASAP を解決する。

毎日

構成管理

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

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

 

表 6-14 構成管理プロセス

プロセス
目標
検討期間

ソフトウェア バージョンの管理

ソフトウェアのバージョンの一貫性を確実にし、必要に応じてアップグレード/変更を行う。

毎月 1 回

ハードウェア/トポロジの検討

ハードウェア検討のレベル、モジュール、およびプラットフォームの一貫性を確実にする。

毎月または 3 ヶ月ごとに 1 回

構成標準

デバイスのアクセス/管理、セキュリティ、デバイスの機能/動作に関連する標準デバイス構成ファイルを保守、検討、およびプッシュする。

常時

構成の監査

TACACS で記録された構成変更を監査するか、一貫性を確実にするために変更管理プロセスを変更する。

常時

品質改善

高いアベイラビリティと安定したパフォーマンスを維持している組織では、品質改善プロセスを用意しています。多くの場合、製造プロセスに応用されている「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 テレフォニー の運用要件を見積る際に使用します。

 

表 6-15 IP テレフォニー の運用要件

管理領域
運用要件
責任を負うグループ
所要時間
または員数

障害管理

CallManager、ネットワーク障害、アプリケーション アベイラビリティ、デバイス モニタリング、システムログ モニタリングを含む NOC モニタリング

NOC グループ

 

階層 2 の 24x7 障害対応サポートとオンサイト サポート

データ ネットワークの階層 2 のサポート

 

階層 3 のエスカレーション

データ ネットワークの階層 3 のサポート

 

障害管理ツール

NMS

 

メトリックとレポート

NMS

 

構成管理

主要な MAC 変更

データ ネットワークの階層 2 のサポート

 

電話 MAC

Telecom Operations

 

変更管理の制御

IS 変更管理

 

変更管理の計画

データ ネットワークの階層 2 のサポート

 

バックアップ/復元を含む CallManager の管理

NT オペレーション

 

IP/DHCP/TFTP/DNS 管理

NT オペレーション

 

IP アドレッシング計画

データ ネットワークの階層 2 のサポート

 

ダイヤル計画の管理

Telecom Operations

 

構成の一貫性

データ ネットワークの階層 2 のサポート

 

構成管理ツール

NMS

 

ケーブル設備とデータ ハードウェア

データ ネットワーク オペレーション

 

在庫管理

課金およびチャージバック

Telecom

 

在庫管理ツール

NMS

 

デバイスの在庫

NMS

 

不正の検出

Telecom

 

機密管理

ユーザ ID/パスワードの管理

セキュリティ オペレーション

 

物理セキュリティ

ファシリティ

 

性能管理

性能管理ツール

NMS

 

CallManager の使用状況

NT オペレーション

 

データ ネットワーク ベースラインの作成

データ ネットワークの階層 3 のサポート

 

変更管理の what-if 分析

データ ネットワークの階層 3 のサポート

 

パフォーマンスの例外分析および解決

データ ネットワークの階層 3 のサポート

 

アプリケーション プロファイリング

データ ネットワークの階層 3 のサポート

 

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

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

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

ネットワーク管理

ネットワーク管理を説明する上で最も頻繁に使用されるモデルは、ISO ネットワーク管理モデルです。このモデルでは、ネットワーク インフラストラクチャの管理のさまざまな局面を処理する際の 5 つの機能領域の概要を説明します。それらの機能領域には、障害、構成、課金、性能、および機密(業界では FCAPS と呼ばれる)が含まれます。このモデルとその機能領域を使用すると、ネットワーク管理ソリューションの評価および実装で明確なスコープと目標を定義できます。よって、管理システムの実装プロセスに関与するユーザは、機能領域のうちの一つ、またはそれらの組み合わせに重点を置くことができます。

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

この項では、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-16 Cisco CallManager を管理するための最小限の MIB 要件

MIB
説明

SNMPv2-SMI.my

管理情報の SNMPv2 構造

CISCO-TC.my

Cisco MIB テキストの表記法

SNMPv2-TC.my

SNMPv2 テキストの表記法

SNMP-FRAMEWORK-MIB.my

RFC-2271 の SNMP フレームワークの MIB

SNMPv2-CONF.my

SNMPv2 準拠の MIB ファイル

CISCO-SMI.my

管理情報の Cisco エンタープライズ構造

CISCO-CCM-MIB.my

Cisco CallManager の MIB ファイル

CISCO-CDP-MIB.my

Cisco Discovery Protocol の MIB ファイル

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

 

表 6-17 Cisco デバイスを監視するための追加 MIB

MIB
説明

CISCO-ENVMON-MIB.my

環境モニタリング

CISCO-FRAME-RELAY-MIB.my

フレームリレー モニタリング

CISCO-PROCESS-MIB.my

CPU およびプロセッシングのモニタリング

CISCO-RTTMON-MIB-120_5_T.my

ジッタ、遅延、およびパケット損失のモニタリング

CISCO-STACK-MIB.my

Catalyst スイッチ モニタリング

CISCO-STP-EXTNESIONS-MIB.my

スパニングツリー モニタリング

CISCO-SYSTEM-MIB.my

システム モニタリング

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

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

ネットワーク管理システムを効率にするには、必ず、システムログを設定する必要があります。各システム メッセージは重大度レベル別に定義され、発生した問題のテキスト説明が含まれます。重大度が最高のメッセージを受け取ると、ネットワーク オペレーションによって是正処置が行われます。重大度レベルのコードは、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 スイッチの基本構成

set logging server x.x.x.x (IP address of your CiscoWorks2000 Server)
set logging timestamp enable
set snmp community public read-only
set snmp community private read-write
set snmp trap enable
set snmp trap x.x.x.x (IP address of your SNMP Platform) public
 

ルータの基本構成

service timestamps log datetime
logging x.x.x.x (IP address of your CiscoWorks 2000 Server)
snmp-server community public ro
snmp-server community private rw
snmp-server enable traps
snmp-server host x.x.x.x (IP address of your SNMP Platform) public
 

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

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-18 コール管理サブシステムのエラー メッセージ

エラー メッセージ
説明

%CALL_MGMT-1-CALL_LIST: [chars]

ソフトウェア エラーによって内部データが破損したことを示す特定のメッセージ テキストは、コール管理ソフトウェアによって提供されます。

%CALL_MGMT-1-CALL_LIST: [chars]

メモリの消費状態を示す特定のメッセージ テキストは、コール管理ソフトウェアによって提供されます。

%CALL_MGMT-1-INITSYS: [chars]

初期障害を示す特定のメッセージ テキストは、コール管理ソフトウェアによって提供されます。このメッセージが表示されると、コール管理サブシステムが動作しません。

図 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 accounting

基本的な IP アカウンティングを使用可能にする

ip accounting access-violations

アクセス リストを通過できない IP トラフィックを特定できるように IP アカウンティングを使用可能にする

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

 

コマンド
目的

ip accounting-threshold t hreshold

作成するアカウンティング エントリの最大数を設定する

ip accounting-list ip-address wildcard

ホストのアカウンティング情報をフィルタに掛ける

ip accounting-transits count

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 の遅延プローブまたはジッタ プローブのジッタ、遅延、およびパケット損失を計算する方法を示します。計算は、送信された連続したパケットのタイム スタンプの送信および受信に基づいて行われます。

 

送信側
受信側

T1 パケット1 の送信

 

T2

パケット1 の受信

T3

パケット1 の応答の返信

T4 パケット1 の応答の受信

 

T5 パケット2 の送信

 

T6

パケット2 の受信

T7

パケット2 の応答の返信

T8 パケット2 の応答の受信

 

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

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

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

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

 

パケット1 を送信するルータ1

T1 = 0

パケット1 を受信する ルータ2

T2 = 20ms

パケット1 を返信するルータ2

T3 = 40ms

パケット1 の応答を受信する ルータ1

T4 = 60ms

パケット2 を送信するルータ1

T5 = 60ms

パケット2 を受信する ルータ2

T6 - 82ms

パケット2 を返信するルータ2

T7 = 104ms

パケット2 の応答を受信する ルータ1

T8 = 126ms

送信元から送信先までのジッタ(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 つは、音声コールのシミュレーションを実行できることです。たとえば、標準的な G.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 秒間スリープする

((1000 datagrams * 480 bytes per datagram)/ 60 seconds)) * 8 bits per byte = 64kb/s
 

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

rtr 1
type jitter dest-ipaddr 172.18.179.10 dest-port 14384 num-packets 1000
request-data-size 492
frequency 60
rtr schedule 1 life 2147483647 start-time now

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


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

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

 

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

saarouter1#
rtr responder
rtr 1
type jitter dest-ipaddr 172.18.179.10 dest-port 14384 num-packets 1000
request-data-size 492
frequency 60
rtr schedule 1 life 2147483647 start-time now
 
saarouter2#
rtr 1
type jitter dest-ipaddr 172.18.178.10 dest-port 14385 num-packets 1000
request-data-size 492
rtr schedule 1 life 2147483647 start-time now
 
saarouter3#
rtr 1
type jitter dest-ipaddr 172.18.179.100 dest-port 14385 num-packets 1000
request-data-size 492
frequency 60
rtr schedule 1 life 2147483647 start-time now
 
saarouter4#
rtr 1
type jitter dest-ipaddr 172.18.178.100 dest-port 14385 num-packets 1000
request-data-size 492
frequency 60
rtr schedule 1 life 2147483647 start-time now
 

サンプル データの収集

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
を参照してください。

 

表 6-19 Cisco IOS コマンド

Cisco IOS コマンド
目的
ルータ

aaa new-model

アクセス管理の主要な方法として、認証、許可、会計(AAA)を使用可能にする。

aaa accounting {system | network | connection | exec | command level} {start-stop | wait-start | stop-only} {tacacs+ | radius}

グローバル設定コマンドを指定して会計を使用可能にする。

aaa authentication login default tacacs+

ログイン デフォルトを使用して設定した端末回線への接続が TACACS+ によって認証されるか、何らかの理由で認証が失敗した場合には認証しないように、ルータを設定する。

aaa authorization exec default tacacs+ none

TACACS+ サーバに問い合わせることによって、ユーザに対して EXEC シェルの実行を許可するかどうかをチェックするように、ルータを設定する。

tacacs-server host tacacs+ server ip address

グローバル設定コマンドを使用して認証に使用される TACACS+ サーバを指定する。

tacacs-server key shared-secret

グローバル設定コマンドを使用して、TACACS+ サーバおよび Cisco ルータによって認識される共有秘密を指定する。

Catalyst スイッチ

set authentication login tacacs enable [all | console | http | telnet] [primary]

通常ログイン モードの TACACS+ 認証を使用可能にする。コンソール ポートまたは Telnet 接続を試行する場合には、コンソール または Telnet キーワードを使用して TACACS+ だけを使用可能にする。

set authorization exec enable {option} fallback option} [console | telnet | both]

通常ログイン モードの認証を使用可能にする。コンソール ポートまたは Telnet 接続を試行する場合には、コンソール または Telnet キーワードを使用して認証だけを使用可能にする。

set tacacs-server key shared-secret

TACACS+ サーバおよびスイッチによって認識される共有秘密を指定する。

set tacacs-server host tacacs+ server ip address

グローバル設定コマンドを使用して認証に使用される TACACS+ サーバを指定する。

set accounting commands enable {config | all} {stop-only} tacacs+

設定コマンドのアカウンティングを使用可能にする。

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 | disable}
set ip permit {enable | disable} [telnet | ssh | snmp]
set ip permit addr [mask] [telnet | ssh | snmp | all]
 

次に、 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 応答を定期的にテストします。

 

表 6-20 ネットワーク イベント通知(SNMP)要件

優先順位
カテゴリ/要件
SNMP 取得サポート1
SNMP
トラップ サポート1
NOC アクション
フレームリレー

1

DLCI の状態変更

要:RFC1315-MIB.my

階層 1 アクション

階層 2 エスカレーション/デバッグ

2

FECN

要:CISCO-FRAME-RELAY-MIB.my

不要

階層 2 デバッグ

2

BECN

要:CISCO-FRAME-RELAY-MIB.my

不要

階層 2 デバッグ

3

欠落または損失したパケット

要:CISCO-FRAME-RELAY-MIB.my

不要

階層 2 デバッグ

3

着信廃棄特性

要:CISCO-FRAME-RELAY-MIB.my

不要

階層 2 デバッグ

3

発信廃棄特性

要:CISCO-FRAME-RELAY-MIB.my

不要

階層 2 デバッグ

X.25

1

X.25 SVC の状態変更
(アップ/ダウン表示)

要:CISCO-CALL-HISTORY-MIB.my

不要

階層 1 アクション

階層 2 エスカレーション/デバッグ

2

インターフェイスの HTC 設定に基づく最大コールの設定

要:RFC1382-MIB.my

不要

階層 2 デバッグ

2

再伝送試行の超過

不要

階層 2 デバッグ

基本情報

2

CRC エラー

要:CISCO-INTERFACES-MIB-MIB.my

不要

階層 2 デバッグ

3

キャリア変換

要:CISCO-INTERFACES-MIB-MIB.my

不要

階層 2 デバッグ

3

入力エラー

要:CISCO-INTERFACES-MIB-MIB.my

不要

階層 2 デバッグ

3

出力バッファ障害

要:CISCO-INTERFACES-MIB-MIB.my

不要

階層 2 デバッグ

1.Cisco 7206 VXR のサポート

優先順位: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-21 障害管理用の SNMP MIB

CISCO-CCM-MIB
オブジェクト名
オブジェクトの説明
OID
ポーリング間隔
しきい値

ccmStatus

CallManager の現在のステータス。

.1.3.6.1.4.1.9.9.156.1.1.2.1.5

30 分

≠ 2

ccmPhoneStatus

IP Phoneの状態。IP Phone自体がローカルの CallManager に登録されると、IP Phoneの状態が不明からアクティブに変わります。

.1.3.6.1.4.1.9.9.156.1.2.1.1.7

30 分

≠アクティブ

ccmGatewayStatus

ゲートウェイの状態。ゲートウェイ自体がローカルの CallManager に登録されると、ゲートウェイの状態が不明から登録に変わります。

.1.3.6.1.4.1.9.9.156.1.3.1.1.5

30 分

≠登録

ccmGatewayTrunkStatus

トランクの状態。トランク自体がローカルの CallManager に登録されると、トランクの状態が不明からアップに変わります。

.1.3.6.1.4.1.9.9.156.1.4.1.1.5

30 分

≠アップ

ccmActivePhones

この CallManager に接続された IP Phone数とこの CallManager と頻繁に通信する(キープアライブを使用して)IP Phone数。

.1.3.6.1.4.1.9.9.156.1.5.1

1 時間

任意の未計画デルタ

ccmInActivePhones

CallManager に登録されているが、CallManagerと通信できないIP Phone数。CallManager が任意のキープアライブを受信しない場合、IP Phoneは CallManager と通信できないと考えられます。

.1.3.6.1.4.1.9.9.156.1.5.2

15 分

>0

ccmActiveGateways

この CallManager を使用して構成されたゲートウェイ数とその CallManager と頻繁に通信する(キープアライブを使用して)ゲートウェイ数。

.1.3.6.1.4.1.9.9.156.1.5.3

1 時間

任意の未計画デルタ

ccmInActiveGateways

CallManager に登録されているが、CallManager と通信できないゲートウェイ数。CallManager が任意のキープアライブを受信しない場合、ゲートウェイは CallManager と通信できないと考えられます。

.1.3.6.1.4.1.9.9.156.1.5.4

15 分

>0

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

 

表 6-22 CallManager SNMP トラップ

SNMP トラップ
OID

ccmCallManagerFailed

.1.3.6.1.4.1.9.9.156.2.0.1

ccmPhoneFailed

.1.3.6.1.4.1.9.9.156.2.0.2

ccmPhoneStatusUpdate

.1.3.6.1.4.1.9.9.156.2.0.3

ccmGatewayFailed

.1.3.6.1.4.1.9.9.156.2.0.4

ccmOutOfResource

.1.3.6.1.4.1.9.9.156.2.0.5

ccmGatewayLayer2Change

.1.3.6.1.4.1.9.9.156.2.0.6

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

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

 

表 6-23 IP テレフォニー ネットワーク管理製品

管理ツール/システム
サポートされている IP テレフォニー コンポーネント
機能

インフラストラクチャ管理

CiscoWorks2000

Resource Manager Essentials

ルータ

Catalyst LAN スイッチ

VoIP ゲートウェイ

IP Phone

設定ファイルの管理

システムログの管理

ソフトウェア イメージの管理

インベントリの管理

Campus Manager

ルータ

Catalyst LAN スイッチ

VoIP ゲートウェイ

IP Phone

ディスカバリおよびトポロジのマッピング

エンド ステーションおよびハンドセットの追跡

レイヤ 2/レイヤ 3 のパス分析

VLAN/LAN および ATM の設定

Traffic Director

ルータ

Catalyst LAN スイッチ

RMON/RMON 2 のトラフィック分析

トレンディング

リアルタイム分析

Internetwork Performance Monitor

ルータ

VoIP ゲートウェイ

サービス保証エージェント(SAA)機能を使用したパフォーマンス表示

Service Level Manager および Management Engine 1110

ルータ

VoIP ゲートウェイ

エンドツーエンド サービス モニタリング

CiscoView

ルータ

Catalyst LAN スイッチ

VoIP ゲートウェイ

デバイスレベル管理およびトラブルシューティング

Cisco Voice Manager

VoIP ゲートウェイ

ダイヤル プランの管理

QoS Policy Manager

ルータ

Catalyst LAN スイッチ

VoIP ゲートウェイ

デバイスでの QoS ポリシーの定義

User Registration Tracking

Catalyst LAN スイッチ

ユーザ登録ポリシー バインディングの作成

Cisco Secure ACS

ルータ

Catalyst LAN スイッチ

VoIP ゲートウェイ

認証、許可、会計のセキュリティ サーバ

ICS System Manager

ICS 7750

システム カードの設定および管理

その他のインフラストラクチャ コンポーネント

システムログ サーバ

ルータ

Catalyst LAN スイッチ

VoIP ゲートウェイ

CallManager

システムログの保守

SNMP トラップ レシーバ

ルータ

Catalyst LAN スイッチ

VoIP ゲートウェイ

SNMP トラップの受信

NTP サーバ

ルータ

Catalyst LAN スイッチ

VoIP ゲートウェイ

時間の同期化

CallManager 管理

Microsoft Event Viewer

CallManager

システムレベル メッセージの表示

Microsoft Performance Viewer

CallManager

システム パフォーマンス(CPU、ディスク)の表示

Compaq Insight Manager

Media Convergence Server

サービス特定の統計の提供

IP Phone管理

Network Registrar

IP Phone

DNS および DHCP の保守

IP テレフォニー ネットワークの保護

この項では、保護された IP テレフォニー ネットワークの設計および実装について説明します。ここでは、企業ネットワークの(SAFE)セキュリティ アーキテクチャに対するシスコの保護設計図に密着して説明します。ここでは、すべての内容ではなく、ネットワーク管理者、システム管理者、およびシステム エンジニアが IP テレフォニー ネットワークの構築時に利用する基本情報について説明します。また、ネットワークの保護とは、企業ネットワーク全体に配備されたネットワーク インフラストラクチャ コンポーネント、サーバのオペレーティング システム、およびアプリケーションに存在する最近の脆弱性に対して遅れないようにし、維持しなければならない持続的なプロセスである、ということを認識することが重要です。

音声通信の保護のテーマは、一般的に通信設計者に慎重を期する議題です。音声通信の保護はネットワーク コンバージェンスが設計モデルとして一般的に認められるようになるにつれ、さらに注目されています。IP テレフォニー の出現により、音声通信では 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 ルータ アクセス ― 仮想コンソールへのホスト

access-list 12 permit 172.21.167.0 0.0.0.255
line vty 0 4
access-class 12 in
login
password g0+$k1
 

Catalyst イーサネット スイッチ

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

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

set ip permit 172.21.167.0 0.0.0.255 telnet
set ip permit enable telnet
 

また、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 アクセス

set security acl ip ACCESS permit tcp 172.21.167.0 0.0.0.255 host 172.21.167.1 eq 23
set security acl ip ACCESS deny tcp any host 172.21.167.1 eq 23
set security acl ip ACCESS permit any any
commit security acl ACCESS
set security acl map ACCESS 10
 

図 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 ルータでのイネーブル パスワード

enable password Go-5m4LL
enable secret g0-B1g!
service password-encryption
 

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 を有効にする

username todd password 5y5c0jamS
aaa new-model
aaa authentication login default radius local enable
aaa authorization exec default group radius local none
aaa authorization network default group radius local none
aaa accounting exec default start-stop group radius
aaa accounting connection default start-stop group radius
aaa accounting system default start-stop group radius
aaa accounting update periodic 60
radius-server host 10.21.101.10
radius-server key 2B-$Ecur3
line vty 0 4
login authentication default
 

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

set tacacs server 10.21.101.10
set tacacs key 2B-$Ecur3
set tacacs attempts 3
set authentication login tacacs enable all primary
set authorization exec enable tacacs+ deny both
set accounting connect enable stop-only tacacs+
set accounting exec enable stop-only tacacs+
set accounting system enable stop-only tacacs+
set accounting system commands enable all stop-only tacacs+
set accounting update periodic 60
 

セキュア シェル

セキュア シェル(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 を使用可能にする

Hostname secure-router
ip domain-name cisco.com
crypto key generate rsa
ip ssh time-out 60
ip ssh authentication-retries 5
 

ユーザが 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 ルータ

access-list 12 permit 10.21.101.0 0.0.0.255
snmp-server community ph0oBar RO 12
access-list 13 permit host 10.21.101.10
snmp-server community ph0oBaz RW 13
 

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

Set snmp community read-only ph0oBar
Set snmp community read-write ph0oBaz
 

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

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

set ip permit 10.21.101.0 0.0.0.255 snmp
set ip permit enable snmp
 

例6-11 VACL コマンド文

set security acl ip ACCESS permit udp 10.21.101.0 0.0.0.255 host 172.21.167.1 eq 161
set security acl ip ACCESS permit udp 10.21.101.0 0.0.0.255 host 172.21.167.1 eq 162
set security acl ip ACCESS deny udp any host 172.21.167.1 eq 161
set security acl ip ACCESS deny udp any host 172.21.167.1 eq 162
set security acl ip ACCESS permit any any
commit security acl ACCESS
set security acl map ACCESS 10
 

HTTP

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


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


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

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

access-list 12 permit 10.21.101.0 0.0.0.255
ip http access-class 12
 

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 ルータでサービスを無効にする

no service tcp-small-servers
no service udp-small-servers
no service finger
 

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

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

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

no ip rcmd rcp-enable
no ip rcmd rsh-enable
 

ネイバー認証

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

HSRP

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

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

interface Ethernet 2/1
standby 21 authentication hsRp$af3
 

拡張 IGRP(EIGRP)

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

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

hostname denlab_gk
key chain gk-2-denver
key 1
key-string d3nV3r_gk
key 2
key-string d3nV3r_3640
!
interface Ethernet0
ip address 10.21.1.200 255.255.255.0
ip authentication mode eigrp 247 md5
ip authentication key-chain eigrp 247 gk-2-denver
 
 
hostname denver_3640
key chain denver-2-gk
key 1
key-string d3nV3r_gk
key 2
key-string d3nV3r_3640
!
interface FastEthernet0/0
ip address 10.21.1.1 255.255.255.0
ip authentication mode eigrp 247 md5
ip authentication key-chain eigrp 247 denver-2-gk
 

OSPF

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

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

router ospf 1
area 2 authentication message-digest
!
interface Ethernet 2/1
ip ospf message-digest-key 1 md5 0spFmd5
 

BGP

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

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

router bgp 1
neighbor 171.70.209.2 password BgP%md5
 

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

現在でも、正確なロギングは、侵入者を特定するには最も有効なツールの 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 ルータで使用可能になったネットワーク タイム プロトコル

clock timezone MST -7
clock summer-time MDT recurring
ntp update-calendar
ntp server 172.21.10.7
ntp authenticate
ntp authentication-key 1 md5 nTp-ru1e$
ntp trusted-key 1
 

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

set timezone Mountain -7
set summertime enable MDT
set summertime recurring
set ntp server 172.21.10.7
set ntp client enable
set ntp public_my trusted md5 nTp-ru1e$
set ntp authentication enable
 

タイムスタンプ

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

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

service timestamps debug datetime msec
service timestamps log datetime msec
 

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

set logging timestamps enable
 

システムログ サーバ

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

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

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

logging 10.21.101.10
logging facility local5
logging trap 5
 

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

set logging server 10.21.101.10
set logging server facility local5
set logging server severity 5
set logging server enable
 

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

 

表 6-24 ロギング重大度レベル

重大度レベル
説明

0:緊急事態

システムが使用不可

1:警報

即時処置が必要

2:重大

危険状態

3:エラー

エラー状態

4:警告

警告状態

5:通知

通常バグ ñ 重大な状態

6:情報

情報メッセージ

7:デバッグ

デバッグ メッセージ

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 アクセス リストの許可

access-list 101 permit ip 172.21.0.0 0.0.255.255 any
access-list 101 deny ip any any
access-list 102 deny ip 172.21.0.0 0.0.255.255 any
access-list 102 permit ip any any
interface Serial 2/1
ip access-group 101 out
ip access-group 102 in

ICMP リダイレクト

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

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

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

interface ethernet 0/1
no ip redirects

) 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 ファイアウォールの設定

ip inspect audit-trail
ip inspect max-incomplete low 150
ip inspect max-incomplete high 250
ip inspect one-minute low 100
ip inspect one-minute high 200
ip inspect udp idle-time 20
ip inspect dns-timeout 3
ip inspect tcp idle-time 1800
ip inspect tcp finwait-time 3
ip inspect tcp synwait-time 15
ip inspect tcp max-incomplete host 40 block-time 0
ip inspect name avvid_firewall tcp timeout 300
ip inspect name avvid_firewall udp
ip inspect name avvid_firewall tftp
ip inspect name avvid_firewall http
 
 
interface FastEthernet0/1
description This interface connects to the Data Network
ip address 172.21.100.1 255.255.255.0
ip access-group secure_avvid in
! Controlled access from the Data Network to the Voice Network
no ip directed-broadcast
no ip redirects
ip inspect avvid_firewall out
! Allows traffic originating from the voice network to access the data network
 
ip access-list extended secure_avvid
permit eigrp any any
! Allow routing protocol access to the voice network
 
permit tcp 172.21.167.0 0.0.0.255 10.21.100.0 0.0.0.255 eq www
permit tcp 172.21.167.0 0.0.0.255 10.0.0.0 0.255.255.255 eq telnet
permit tcp 172.21.167.0 0.0.0.255 10.0.0.0 0.255.255.255 eq 22
permit icmp 172.21.167.0 0.0.0.255 10.0.0.0 0.255.255.255 echo-reply log
permit icmp 172.21.167.0 0.0.0.255 10.0.0.0 0.255.255.255 echo log
permit udp 172.21.167.0 0.0.0.255 10.0.0.0 0.255.255.255 snmp
! Allow Network Admin subnet access to the Voice network and CallManager Cluster subnet
 
permit udp host 172.21.164.40 10.0.0.0 0.255.255.255 eq 67
permit udp host 172.21.164.40 10.0.0.0 0.255.255.255 eq 68
! 172.21.164.40 is the dhcp server - only needed if data network provides dhcp service to voice
 
permit tcp 172.21.0.0 0.0.255.255 10.21.100.0 0.0.0.255 eq 2748
! JTAPI for Softphones, IP-IVR, and IPCC to the CallManager subnet
 
permit udp 172.21.0.0 0.0.255.255 10.0.0.0 0.255.255.255 range 16384 32767
! RTP for SoftPhone and IP-IVR to communicate to IP Phones and VoIP gateway
 
permit tcp 172.21.0.0 0.0.255.255 10.21.100.0 0.0.0.255 eq 8404
! SoftPhone Directory service to CallManager cluster
 
permit tcp 172.21.0.0 0.0.255.255 host 10.21.101.11 eq 389
! SoftPhone access to the LDAP server
 
deny ip any any log
! explicit deny all with logging
 

VoIP ゲートウェイの保護

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


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


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

interface fastethernet 1/0
description VoIP (H.323 & MGCP) Gateway
ip address 10.21.101.1 255.255.255.0
ip access-group secure-gw in
no ip directed-broadcast
no ip redirects
 
ip access-list extended secure-gw
permit eigrp any any
! Allow routing protocol access to the VoIP Gateway
 
permit udp host 172.21.164.40 eq domain host 10.21.101.1
! Allow DNS lookups to the VoIP Gateway
 
permit tcp 172.21.167.0 0.0.0.255 eq 123 host 10.21.101.1
permit udp 172.21.167.0 0.0.0.255 eq 123 host 10.21.101.1
permit tcp 172.21.167.0 0.0.0.255 host 10.21.101.1 eq telnet
permit tcp 172.21.167.0 0.0.0.255 host 10.21.101.1 eq 22
permit icmp 172.21.167.0 0.0.0.255 host 10.21.101.1 echo-reply log
permit icmp 172.21.167.0 0.0.0.255 host 10.21.101.1 echo log
permit udp 172.21.167.0 0.0.0.255 host 10.21.101.1 snmp
! Allow Network Admin subnet access to the VoIP gateway
 
permit ip 10.21.100.0 0.0.0.255 host 10.21.101.1
! Allow CallManager Cluster Subnet full access to the VoIP gateway
 
permit udp 10.0.0.0 0.255.255.255 any range 16384 32767
! Allow IP Phones access to the VoIP gateway and beyond
 
permit udp 172.21.0.0 0.0.255.255 any range 16384 32767
! Allow SoftPhones access to the VoIP gateway and beyond
 
deny ip any any log
! explicit deny all with logging
 

ファイアウォール

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 の設定

access-list avvid_in permit udp 10.0.0.0 255.0.0.0 10.21.100.0 255.255.255.0 eq tftp
! Allow TFTP from the Voice Network to the CallManager Cluster Subnet
 
access-list avvid_in permit tcp 10.0.0.0 255.0.0.0 10.21.100.0 255.255.255.0 eq 2000
access-list avvid_in permit tcp 10.0.0.0 255.0.0.0 10.21.100.0 255.255.255.0 eq 2001
access-list avvid_in permit tcp 10.0.0.0 255.0.0.0 10.21.100.0 255.255.255.0 eq 2002
! Allow Skinny from the Voice Network to the CallManager Cluster Subnet
 
access-list avvid_in permit tcp 10.0.0.0 255.0.0.0 10.21.100.0 255.255.255.0 eq 1719
access-list avvid_in permit tcp 10.0.0.0 255.0.0.0 10.21.100.0 255.255.255.0 eq 1720
access-list avvid_in permit tcp 10.0.0.0 255.0.0.0 10.21.100.0 255.255.255.0 range 11000 11999
! H.323 access from the Voice Network to the CallManager Cluster Subnet
 
access-list avvid_in permit udp 10.0.0.0 255.0.0.0 10.21.100.0 255.255.255.0 eq 2427
access-list avvid_in permit tcp 10.0.0.0 255.0.0.0 10.21.100.0 255.255.255.0 eq 2428
! MGCP from the Voice Network to the CallManager Cluster Subnet
 
access-list avvid_in permit tcp 172.21.0.0 255.255.0.0 10.21.100.0 255.255.255.0 eq 2748
! CTI (TAPI and JTAPI) for SoftPhone to the CallManager Cluster Subnet
 
access-list avvid_in permit tcp 172.21.0.0 255.255.0.0 10.21.100.0 255.255.255.0 eq 8404
! SoftPhone Directory to the CallManager Cluster Subnet
 
access-list avvid_in permit tcp 172.21.167.0 255.255.255.0 10.21.100.0 255.255.255.0 eq www
access-list avvid_in permit tcp 172.21.167.0 255.255.255.0 10.21.100.0 255.255.255.0 eq telnet
access-list avvid_in permit tcp 172.21.167.0 255.255.255.0 10.21.100.0 255.255.255.0 eq 22
access-list avvid_in permit icmp 172.21.167.0 255.255.255.0 10.21.100.0 255.255.255.0 0
access-list avvid_in permit icmp 172.21.167.0 255.255.255.0 10.21.100.0 255.255.255.0 8
access-list avvid_in permit udp 172.21.167.0 255.255.255.0 10.21.100.0 255.255.255.0 eq snmp
! Allow Network Admin subnet access to CallManager Cluster subnet
 
access-list avvid_in permit tcp 172.21.0.0 255.255.0.0 10.21.100.0 255.255.255.0 eq www
! SoftPhone Telecaster HTTP access to the CallManager Cluster Subnet
 
ip address outside 10.21.199.2 255.255.255.0
! Interface attached to the Voice Network
 
ip address inside 10.21.100.1 255.255.255.0
! Interface attached to the CallManager Cluster
 
static (inside,outside) 10.21.100.0 10.21.100.0 netmask 255.255.255.0
! Do not NAT the CallManager Cluster address across the firewall
 
access-group avvid_in in interface outside
! Apply the access-list to the outside interface of the firewall
 

侵入検知システム

安全な IP テレフォニー のネットワークの設計で最後のステップとなるのが、ネットワークの IDS(Intrusion Detection Systems;侵入検知システム)を追加することです。IDS により、攻撃のプロファイルまたはシグニチャを調べる戦略的なサーバまたはネットワークに IP トラフィックが通過していることが調査されます。攻撃的特性をもつトラフィック ストリームが検知されると、IDS では、IDS 管理ステーションにアラームを通知するか、Cisco ルータの構成コールを送信して攻撃をブロックします。CallManager を含む重要なサーバには、ホスト ベースの侵入検知を検討する必要があります。

図 6-30 は、ネットワークの侵入検知システムを示します。

図 6-30 ネットワークの侵入検知システム

 

IDS システムは、既存のセキュリティ ポリシーの一部としてすべてのインターネット接続に配置する必要があります。同様に、パートナー接続に対して IDS システムの追加を検討する必要があります。IP テレフォニー ネットワークを構築する場合、追加の IDS システムを組織のデータ ネットワークと IP テレフォニー ネットワーク間に、さらに CallManager クラスタを保護する内部ファイアウォールに配置することを推奨します。

IP テレフォニー ネットワークと組織のデータ ネットワーク間のトラフィックを監視する IDS アプライアンス、または Catalyst モジュールでは、システムログ サーバと IDS システムの両方を使用して疑いのあるすべてのフローをログして、ネットワーク管理者に監査追跡を提供します。CallManager クラスタを保護する PIX ファイアウォール、または Cisco IOS ファイアウォールの内部にある IDS アプライアンス、または Catalyst モジュールを設定して、コール処理インフラストラクチャに対する攻撃をブロックします。つまり、意図的な悪意のある攻撃と診断されるトラフィックは、侵入検知システムがほぼリアルタイムでCallManager クラスタおよび IP テレフォニー を組織のデータ ネットワークに接続するルータを修正可能にすることによって回避されます。IDS は、そのシグニチャ データベースに基づいて攻撃を特定します。

CallManager サーバの保護

IP テレフォニー ネットワーク保護のネットワーク設計部分が完成したら、CallManager サーバの対処に取り掛かります。CallManager は、Microsoft Windows 2000 サーバ オペレーティング システムを使用する Compaq サーバまたは ICS 7750 SPE で稼動します。Windows 2000 は、デフォルトのファイル許可設定、向上した TCP/IP スタック、および設定の細分性により、本質的に以前の Microsoft OS よりも安全性が高くなっています。

ただし、すべてのオペレーティング システムの性質上、新たに検出された脆弱点が迅速に排除されていることを確認するために、システム管理者は常に監視し続ける必要があります。システムの修正は、新しいソフトウェアのデフォルトのインストール手順の変更から OS パッチを使用したカーネルの修正にまで及ぶ継続的な作業です。

CallManager に管理者のセキュリティ機能拡張を設定するには、次のステップを実行します。


ステップ 1 最新のパッチを使用して Windows 2000 オペレーティング システムを更新します。

ステップ 2 CallManager で実行中の使用しない、または不要なサービスおよびアプリケーションを終了します。

ステップ 3 セキュリティ設定を NTFS ファイル構造に適用します。

ステップ 4 システムのセキュリティ監査を有効にします。

ステップ 5 IIS 設定を確保認します。

ステップ 6 SQL サーバのインストールを確認します。

ステップ 7 CallManager にインストールされた音声会議/MTP ソフトウェア パッケージを削除します。

ステップ 8 CallManager SNMP を安全に設定します。

ステップ 9 CallManager で稼動している TFTP サーバーをシャットダウンして、IP Phoneおよび IP ゲートそれぞれの TFTP サーバをインストールします。

ステップ 10 すべての IP Phoneの Web サービスを別のサーバに移動します。


 

この項では、上述の各ステップについて詳しく説明します。 http://www.microsoft.com/security の Microsoft セキュリティ サイトを定期的にアクセスして、Microsoft オペレーティング システムのセキュア機能を使用して CallManager、その他のサーバおよびワークステーションを維持する新しい情報を得ることを強く推奨します。この作業は企業のセキュリティ ポリシーの一部にし、定期的に実行する必要があります。

現在のセキュリティおよび OS パッチの多くは、CallManager に付属しているオペレーティング システムのインストール CD-ROM によってすでに追加されています。新しいパッチは持続的にリリースされるため、ここで詳しく説明したすべてのステップに従って安全なシステムを確保していることを確認することが重要です。

パッチ

オペレーティング システムへのパッチの追加、および CallManager サーバのインストールと設定は、システム管理者にとって実装時に標準となる手順です。初期インストールが完了したら、システム管理者はすぐに Microsoft 社が推奨したセキュリティ パッチがインストールされ、CallManager の機能性は影響を受けていないことを確認する必要があります。Microsoft updates の Web サイト http://www.microsoft.com/technet/security/current.asp にアクセスすることが重要です。

OS のパッチが発行されるたびに、新しいセキュリティ パッチが実稼動環境で CallManager の機能性に影響しないことを確認し、それらのパッチを CallManager にインストールする必要があります。

不要なサービスの停止

Windows 2000 オペレーティング システムでインストールすると、デフォルトでは、CallManager で不要な多くのアプリケーションおよびサービスが使用可能になります。それらのサービスに関連する潜在的な脆弱点を排除できるように、それらのサービスを使用不可にすることができます。

サーバ保護の基本原則の 1 つは、実行中の各サービスによってセキュリティの潜在的な脆弱点が露呈することです。サービスを実行するたびにそれを保護するのは時間を浪費する困難な作業であるため、サービスに脆弱点があることがすぐに分からない場合でも、必須でないサービスをすべて使用不可にすることが適切です。

特にシステムで要求されない限り、次のサービスを停止して Manual に設定する必要があります。


) ICS 7750 システムでは、DHCP を使用不可にしたり、手動に設定したりしないでください。


Alerter サービス

Clipbook Server

Computer Browser

Distributed File System

DHCP Client

Messenger

Net Logon

Network DDE および Network DDE DSDM

Network Monitor Agent

Spooler サービス

SMTP サービス

NNTP サービス

DHCP サービス

DNS Server サービス

FTP Publishing サービス

Fax サービス

Net Meeting Remote Desktop Sharing

サブスクライバ CallManager では、上述のサービスだけでなく、次のサービスも使用不可にする必要があります。

IIS Admin サービス

World Wide Web Publishing サービス

すべての Web 管理タスクはパブリッシャで実行されるため、サブスクライバで実行するそれらのサービスを保持する理由はありません。パブリッシャには読み取りおよび書き込みのアクセス権がありますが、すべてのサブスクライバには読み取り専用のアクセス権しかありません。

ファイル システム アクセスの保護

不明なユーザは、CallManager システムにログインすることができません。デフォルトでは、Windows 2000 のファイル システムはあまり安全ではありません。ただし、別のユーザ アカウントとシステム アカウントの不適切な部分を削除して、正しい許可をファイル システム構造に適用すると、そのファイル システムをかなり安全に保護できます。

不要なサービスおよびアプリケーションの停止に加え、そのシステムへのアクセスを保護するにはキーポイントが 2 つあります。1 番目のキーポイントは、ファイル システム自体の NTFS 許可を保護する必要があることです。原則として、NTFS 許可は累積されます。つまり、任意のユーザがディレクトリへのアクセス権を持つ 2 つのグループのメンバーである場合、そのユーザは 2 つのグループの上位アクセス権を持つことになります。ただし、明示的にアクセス拒否が設定された場合には、例外となります。ディレクトリに 2 つのグループが割り当てられ、1 つのグループが明示的に拒否される場合、明示的な拒否が最優先されるため、両方のグループに属するユーザは拒否されます。

後で詳しく説明する 2 番目のキーポイントは、アクセス方式の保護に関連することです。IIS を使用したファイル システムへのアクセスは、Windows Explorer を使用したファイルへのリモート アクセスと似ています。共有とは、任意のユーザがリソースにアクセスできるように設定することです。また、IIS とは、一連のファイルまたはリソースを共有するごく一般的な手段です。任意のユーザが共有を使用してリソースにアクセスすると、そのユーザのアクセス権はその共有へのアクセス権を持つ任意のグループの累積アクセスとなります。

ただし、任意のユーザが共有を使用して NTFS 保護のリソースにアクセスすると、最も制限されたアクセスが適用されます。また、任意のユーザが IIS を使用した管理特権を持っていても、ファイル システム自体に読み取りアクセス権しか持っていない場合には、そのユーザのアクセス レベル全体が読み取り専用になります。

まず、アカウント自体を修正する必要があります。Guests アカウントを無効にし、Guests グループから任意のユーザを削除します。 System Tools > Local Users and Groups サブディレクトリからこの修正を実行できます。その後、 [スタート]>[プログラム]> Administrative Tools > Computer Management を選択します。

誤ったパスワードが何回も入力された場合、管理者アカウント以外のすべてのアカウントがロックされます。管理者になりすましてコマンドをやみくもに実行しようとする攻撃がどんなに多くても、Administrator アカウントではロックしません。Administrator アカウントの名前を CallmgrAdmin またはその他の適切な名前に変更することで、そのようなタイプの攻撃を減らすことができます。

図 6-31 は、Local Users and Groups ディレクトリの一例を示します。

図 6-31 Computer Management ウィンドウ

Windows 2000 アカウントの不適切な部分を削除する上でもう 1 つ推奨されるステップとなるのが、Everyone グループのすべての特権を保護することです。デフォルトでは、Everyone グループはあらゆるファイルへのアクセス権を持ちます。このアカウントは、ルート ファイル システムから削除する必要があります。ただし、Everyone を No Access に設定すると、管理者を含むすべてのユーザはそのファイル システムにアクセスできなくなります。Everyone グループをそのファイル システムから削除するには、次のステップを実行します。


ステップ 1 Window Explorer で c: ドライブを右クリックします。

ステップ 2 [プロパティ]に進み、 Security タブをクリックします。

ステップ 3 Administrator グループを追加します。

ステップ 4 すべての許可に完全アクセス権が与えられていることを確認します。

ステップ 5 Everyone グループを削除します。


 

システムの監査およびロギング

監査により、Windows 2000 の多くの特権タスクの使用状況を追跡できます。監査を使用可能にすると、Event Viewer が定期的に検討されるので、システムが攻撃を受けているかどうか、あるいは危うくされているかどうかを確認できます。 表 6-26 は、推奨される監査方式を示します。

 

表 6-26 監査方式

内容
ログ アクセス
ログ障害

アカウント ログイン イベントの監査

アカウント管理の監査

ディレクトリ サービス アクセスの監査

ログイン イベントの監査

不可

オブジェクト イベントの監査

ポリシー変更の監査

特権使用状況の監査

プロセス トラッキングの監査

不可

システム イベントの監査

SQL Server 7.0 には、非常に強力なプロファイラが備わっています。これにより、SQL サーバ内で発生した多くの内部イベントを分析できます。SQL Server で実行されたすべてのアクションをキャプチャし、それらのアクションを SQL Server Profiler に送信することによって、SQL Server Profiler でそれらのアクションを分析できます。次の方法を使用してキャプチャを表示できます。

画面でリアルタイムに表示する

テキスト ファイルに保存する

SQL Server テーブルに挿入する

SQL Server Profiler を使用して、次のイベントを含む、SQL Server 内で実行するすべてのイベントを実質的にキャプチャできます。

ログイン失敗

ロッキング : デッドロック

オブジェクト : 非公開

ストアド プロシージャ : 開始文

セッション : 接続解除

RPC : 完了

イベント時間と発信元を特定するには、この情報が非常に役に立ちます。

IIS の保護

IIS は、CallManager サーバの主要なコンポーネントです。CallManager のすべての管理は、このサービスを通過します。そこで問題となるのが、IIS がハッキング コミュニティでよく知られているいくつかの攻撃のターゲットになっていることです。そのため、IIS を保護するためにいくつかのステップを実行する必要があります。

W3C 拡張ログ形式の有効化

デフォルトのロギング メカニズムでは、サーバが攻撃を受けているかどうかを判断するのに十分な情報が記録されません。

索引付けのクリア

ソース コードの索引付けを行うと、攻撃者が Web ページのコンテンツを表示できるようになってしまいます。索引付けをクリアするには、次のステップを実行します。


ステップ 1 IIS MMC(Microsoft Management Console)を起動します。Web サイトの項目で右クリックし、
[プロパティ] を選択し、Web Site Properties に進みます。

ステップ 2 Home Directory タブをクリックします。

ステップ 3 Index this Directory および Directory Browsing Allowed の各オプションをクリアします。


 

未使用のスクリプト マッピングの削除

IIS は、ASP、SHTML、HTR などの一般的な各種ファイル名の拡張子をサポートするように事前に設定されています。それらの要求の処理は、システムに配置された各種 DLL によって対処されます。使用されない拡張子のマッピングを削除することで、考えられる攻撃ポイントを最小限にします。拡張子のマッピングを削除するには、次のステップを実行します。


ステップ 1 IIS MMC を起動します。Web サイトの項目で右クリックし、 [プロパティ] を選択し、
Web Site Properties に進みます。

ステップ 2 Home Directory タブをクリックします。

ステップ 3 Configuration タブをクリックします。

ステップ 4 App Mappings タブをクリックします。

ステップ 5 削除する必要のあるマッピングを削除します。


 

IIS 仮想ディレクトリの削除

IIS に含まれる、削除する必要のあるディレクトリは、次のとおりです。

IISAMPWD

IISSAMPLES

IISADMIN

IISHELP

すべてのサンプル アプリケーションのディレクトリの削除

次のディレクトリには、システムから削除する必要があるサンプル ファイルが含まれています。それらのディレクトリを削除すると、システムへのアクセス権を得るために攻撃者がサンプル ファイルのいずれか 1 つの脆弱性を利用できなくなります。

\Inetpub\iisamples

\Inetpub\scripts\samples

\Inetpub\wwroot\samples

\Program Files\Common Files\System\msadc\Samples

\WINNT\system32\inetsrv\adminsamples

\WINNT\system32\inetsrv\iisadmin

\WINNT\system32\inetsrv\iisadminpwd

Web アプリケーション スペースに適切な仮想ディレクトリ許可の設定

Web サーバで使用可能なファイルに正しい許可を適用することが重要です。それらの許可は、アクセス対象のファイルのタイプに応じて異なります。 表 6-27 は、遵守すべきガイドラインの概要を示します。

 

表 6-27 仮想ディレクトリ許可

ファイル タイプ
ファイル拡張子
ACL

CGI ファイルおよび関連するファイル

.EXE、.DLL、.CMD、.PL

Everyone:実行

管理者およびシステム:完全制御

スクリプト ファイル

.ASP

Everyone:実行

管理者およびシステム:完全制御

インクルード ファイル

.INC、.SHTML、.SHTM

Everyone:実行

管理者およびシステム:完全制御

静的コンテンツ

.HTML、.GIF、.JPEG

Everyone:実行

管理者およびシステム:完全制御

適切な IIS ログ ファイルの ACL の設定

不正ユーザがそのユーザのアクティビティを記録するログ ファイルを削除しないようにするには、IIS で生成されたログ ファイル(%systemroot%\system32\LogFiles)にファイル許可を設定します。その設定内容を 表 6-28 に示します。

 

表 6-28 ファイル許可の設定

ファイル タイプ
ファイル拡張子
ACL

ログ ファイル

.LOG

Everyone:実行

管理者およびシステム:完全制御

Microsoft MDAC 2.1.2.4202.3 のインストール

IIS と MDAC の任意のバージョンを設定した Web サイトでは、サイトの訪問者がシステムで特権アクションを実行する可能性があります。MDAC 2.1をインストールして、Safe Mode で起動するように設定することで、この脆弱性を排除します。次のようにレジストリ キーを変更します。

ハイブ : HKEY_LOACL_MACHINE\SOFTWARE

キー : \Microsoft\DataFactory\HandlerInfo

SQL Server の保護

SQL Server データベースは、CallManager の重要な部分です。コール処理セキュリティ全体を緩和するために、セットアップする SQL Server に簡単な変更をいくつか行うことができます。緊急の場合を除いて、日常の管理に sa アカウントを使用することは推奨しません。sa パスワードを設定すると、そのパスワードが保存され、すべての SQL Server の管理および構成に管理グループが使用されます。

SQL Server 管理に対する個別グループの使用

管理およびデータベースの設定に sa アカウントを使用するのではなく、管理特権に Windows 2000 グループを使用することを推奨します。これにより、グループ全体の Windows 2000 許可を使用した SQL Server へのアクセス権が、管理者に与えられます。

ローカル システム アカウントで実行する SQL Server の設定

Windows 2000 では、SQL Server が 3 つの関連プロセスとして実行されます。

MSSQLServer

SQLServerAgent

Microsoft Search

残りの CallManager のユーザ設定を適合させるために、この 3 つのサービスをローカル システム アカウントで実行する必要があります。Microsoft Search ではローカル システム アカウントを使用する必要があるため、Search Process と同じユーザとして実行するように、MSSQLServer と SQLServerAgent を設定できます。SQL Server をインストールしたら、SQL Server Enterprise Manager を使用して、それらのプロセスで使用するアカウントを変更します。

次の許可は、SQL Server 7.0 でそのタスクを正確に実行するために、ローカル システム アカウントに対して、設定する必要があります。

SQL Server ディレクトリの完全制御(デフォルトでは、\MSSQL7)

すべての .mdf、.ndf、および .ldf データベース ファイルの完全制御

次のレジストリ キーの完全制御

ハイブ: HKEY_LOACL_MACHINE\SOFTWARE

キー: \Microsoft\MSSQLServer

ハイブ: HKEY_LOACL_MACHINE\System

キー: \CurrentControlset\Services\MSSQLServer

SQL server の監査

SQL Server Enterprise Manager を使用して、そのサーバ ロギングを ALL に設定します。その後、監査情報が SQL Server 7.0 のエラー ログに書き込まれます。

会議ソフトウェアおよび会議サービスのアンインストール

CallManager サーバでは、ソフトウェア ベースの会議サービスをインストールしないことを推奨します。会議アプリケーションは、RTP/UDP VoIP ストリームを終端し、それらのストリームを 1 つにまとめて電話会議を行います。UDP は本質的に不安定なプロトコルであり、CallManager で UDP を終端すると、UDP が公開され、余計に攻撃を受けるリスクが伴います。ハードウェア ベースの会議ソフトウェアを使用するか、独立した Windows 2000 サーバに会議ソフトウェアをインストールすると、このリスクを減らすことができます。

CallManager SNMP の構成

CallManager の初回インストール時に Cisco Works オプションを選択した場合、CallManager サーバで SNMP は使用可能になります。Windows 2000 サーバで SNMP サービスを起動すると、いくつかの脆弱性が露呈します。このため、SNMP が必要でない場合には、SNMP サービスおよび設定を使用不可にすることを推奨します。それにもかかわらず、SNMP を使用し、CallManager および IP テレフォニー ネットワークを管理する場合は、次のステップを実行してシステムを保護します。


ステップ 1 デフォルトのコミュニティを変更します。

デフォルトでは、Windows 2000 によって READ コミュニティがパブリックとしてインストールされます。これを一意のコミュニティ名に変更する必要があります。READ および WRITE の各コミュニティ ストリングをパスワードとして処理します。それらのストリングをルート パスワードまたはルータ ログインとして選択する場合にも、同様に処理します。

ステップ 2 IP テレフォニー ネットワーク管理ワークステーションをトラップの送受信が可能な唯一のホストとして構成します。

IP テレフォニー ネットワークのネットワーク管理サーバだけが SNMP TRAP を送受信できます。SNMP 要求/応答がファイアウォールを経由しないようにするため、組織のデータ ネットワークおよび IP テレフォニー ネットワークの SNMP 管理サーバを分離することを強く推奨します。


 

独立した TFTP サーバの使用

TFTP サービスは、CallManager サーバで実行されません。TFTP では データの転送に UDP を使用するため、戦略的なサーバでの TFTP の実行に TFTP 特有のリスクが伴います。スケーラビリティとセキュリティを確保するためには、TFTP サーバを別々に構成する必要があります。TFTP サーバが使用できなくなると、IP Phoneが FLASH メモリに保存された設定とファームウェアのバージョンに完全に戻るため、音声ネットワークの中断が発生しないことに注意してください。

独立したサーバへのすべての IP Phoneの Web サービスの移動

IP Phoneのサービスに使用されるすべての Web プロキシ、および asp 機能を独立したサーバに移動する必要があります。こうすると、CallManager パブリッシャはプロキシ タイプの攻撃から保護されます。また、CallManager パブリッシャの保護の際に CallManager での処理能力を浪費しないようにします。

IP テレフォニー ネットワークのトラブルシューティング

この項では、IP テレフォニー ネットワークのトラブルシューティングで使用できるツールおよびアプリケーションについて説明します。次のトピックを重点的に解説します。

トラブルシューティング ツール

Cisco CallManager デバイスのトラブルシューティング

コール詳細レコード

ICS 7750 固有のトラブルシューティング情報については、 http://www.cisco.com/univercd/cc/td/doc/product/voice/ics7750/tblshoot の『Cisco ICS 7750 Administration and Troubleshooting Guide』を参照してください。

Cisco CallManager Administration の詳細

Cisco CallManager Administration により、システム、データベース、およびその他のコンポーネントのバージョン情報が提供されます。図 6-32 は、この情報を表示する関連画面を示します。開始ウィンドウで、 Details ボタンをクリックして使用中のバージョンを表示します。

図 6-32 Cisco CallManager Administration Version Information ウィンドウ

 

Cisco CallManager Administration の詳細については、 http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/3_0/index.htm を参照してください。

Microsoft Performance Monitor

Performance Monitor(PerMon)は Windows 2000 アプリケーションであり、これを使用して Cisco CallManager システムのアクティビティおよびステータスを表示できます。図 6-33 は、PerMon 画面を使用して表示できる属性を示します。この画面により、一般情報と特定情報がリアルタイムでレポートされます。Windows 2000 Performance Monitor を使用して、Cisco CallManager インストールに関するシステム統計情報とデバイス統計情報の収集および表示ができます。また、この管理ツールを使用すると、その各コンポーネントの操作を学習しなくても、システムを完全に理解することができます。

PerMon を使用して、システムの各種変数をリアルタイムでモニタリングできます。
Cisco CallManager のパラメータを追加すると、Cisco CallManager でシステムよって生成される統計情報を表示する条件を定義できます。たとえば、実行中のコール数を常時モニタリングしたり、特定のゲートウェイを現在通過しているコール数をモニタリングしたりすることができます。Performance には、Cisco CallManager 固有のステータス情報がリアルタイムで表示されます。

図 6-33 PerfMon ウィンドウ

 

Microsoft Performance のオープン

Cisco CallManager を稼動するサーバで Microsoft Performance をオープンするには、[スタート]>[設定]>[コントロール パネル]>[管理ツール]>[パフォーマンス]の順にクリックします。

パフォーマンスのカスタマイズ

モニタ対象にする Cisco CallManager 関連のパラメータを表示するには、パフォーマンス モニタをカスタマイズする必要があります。挿入するオブジェクト、カウンタ、およびインスタンスを選択します。オブジェクトとカウンタを使用して、Cisco CallManager の運用に合わせて Microsoft Performance をカスタマイズする方法の説明については、Remote Serviceability のマニュアルを参照してください。このマニュアルは、
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/3_0/service/index.htm
にあります。

Microsoft Event Viewer

Microsoft Event Viewer は Windows NT Server アプリケーションであり、Windows NT Server のシステム、セキュリティ、およびアプリケーション イベント(Cisco CallManager を含む)を表示します。サービス(TFTP を含む)でデータベース(トレース設定を取得)を読み取ることができない場合、Event Viewer にエラーが追加されます。Event Viewer だけがそれらのタイプのエラーを表示します。図 6-34 では、Windows NT Server で実行中のアプリケーション ログを示します。

図 6-34 Windows NT Server で実行中のアプリケーション ログ

 

Event Viewer のオープン

Cisco CallManager を稼動するサーバ PC で Event Log をオープンするには、[スタート]>[設定]> [コントロール パネル]>[管理ツール]>[イベント ビューア]の順にクリックします。Event Viewer にシステム セキュリティ、およびアプリケーションのエラー ログが表示されます。Cisco CallManager のエラーは、アプリケーション ログに記録されます。

イベントに関する詳細情報

ログのイベントをダブルクリックすると、図 6-35 に示すように、イベントに関する詳細情報が表示されます。

図 6-35 イベント プロパティの説明

 

CallManager トレース

CallManager トレースとは、ローカル ログ ファイルのことです。CallManager トレースを検討して、リクエストの発生または処理方法をモニタするときに、IP アドレス、TCP ハンドル、デバイス名、またはタイムスタンプを使用できます。このデバイス名をファイルの作成まで遡って追跡できます。そのファイルにはデバイスのプールおよびモデルが示されます。さらに、デバイスのプールおよびモデルを設定ファイルのプロトタイプの作成まで遡って追跡できます。設定ファイルのプロトタイプには、Cisco CallManager および TCP 接続ポートのネットワーク アドレスのリストが示されます。

CallManager トレースをモニタすると、ほとんどのトレース ラインに C++ クラスとルーチン名が含まれているのに注意してください。特定の要求のサービス提供に関連するほとんどのルーチンには、スレッド ID が標準形式で含まれます。

CallManager トレースについて、事例を用いて詳しく説明します。

CallManager トレースの出力

CallManager トレースは、Cisco CallManager アクティビティのトレースを保存するファイル(たとえば、CCM000000000)を生成します。CallManager トレースには、Cisco CallManager 初期化プロセス、登録プロセス、キープアライブ プロセス、コール フロー、ディジット分析、およびCisco IP Phone、ゲートウェイ、ゲートキーパーなどの登録済みデバイスに関する情報が備わっています。この情報は、Cisco CallManager のトラブルシューティング時に問題を特定するのに役立ちます。必要な情報および必要な情報だけを正確に追跡するには、トレース設定インターフェイスでオプションを設定する方法を理解することが重要です。

トレース ファイルは、デフォルトの場所 C:\Program Files\Cisco\Trace\CCM に保存されます。Cisco CallManagerを再起動するたびに、あるいは指定したライン数に達したときに、新しいトレース ファイルが開始します。

図 6-36 では、Cisco CallManager Administration のトレース設定インターフェイスを示します。所定の情報レベルを取得するには、トレースを使用可能にして、必要な詳細レベルを選択し、ユーザ マスクをチェックする必要があります。

図 6-36 Cisco CallManager Administration Trace Configuration Interface ウィンドウ

 

トレースが正確に設定されていない場合、大量の情報が生成され、問題の特定が非常に困難になります。次の項では、有用なトレースを正確に設定する方法について説明します。

トレースの設定

トレースは、ユーザ マスク フラグ(ビットとしても知られている)とトレース レベルで設定されます。Cisco CallManager Administration をオープンします。トレースをオンにするには、Service > Trace 画面でトレース パラメータ(設定サービス、ビットなどを含む)を設定します。Cisco CallManager のドキュメントには、Trace の on/off 設定の詳細、および設定サービスの User Mask および Level などが説明されています。このマニュアルは、
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/3_0/admin_gd/admin_gd/index.htm
にあります。

次の内容は、特定のプラットフォームに基づいて有効にするトレース マスク ビットの 2 つの例を示します。

通常メッセージ デバッグの場合、サブシステム ビット 5、6、7、8、11、12 をオンにする

ゲートウェイのデバッグの場合、サブシステム ビット 3、4、5、6、7、8、9、11、12、13 をオンにする

次の内容は、特定の問題に基づいて設定するトレース レベルの 2 つの例を示します。

通常デバッグの場合、Trace Level を ARBITRARY に設定する

通常のシステム実行の場合、Trace Level を ERROR に設定する

SDL トレース

SDL トレースには、トレースとアラーム(複数)に C レベル インターフェイスが備わっています。アラーム(複数)は、ファイル、データベース、Winsock にアクセスできない、あるいはその他のオペレーティング システムのリソースを割り当てることができないなどの予期しないイベントを管理者に知らせるために使用されます。

シスコ代理店エンジニアは、SDL トレースを使用してエラーの原因を突き止めます。SDL トレースに含まれる情報をすべて把握する必要はありません。ただし、TAC を使用して作業している間は、SDL を使用可能にして TAC に SDL トレースを設定するように要求される場合があります。SDL トレース ファイルは、ローカル ディレクトリ、Windows NT Event Viewer、および CiscoWorks 2000 に保存できます。サーバのパフォーマンスが低下しないようにするには、トレースをキャプチャした後に必ず SDL トレースをオフにします。

SDL トレースの使用可能化

SDL トレースは、Cisco CallManager Administration の Service > Service Parameter 領域で使用可能になります。TAC エンジニアによって要求された場合に限り、SDL トレースをオンにする必要があるので留意してください。図 6-37 で SDL トレースをオンにするために選択した値に注意してください。

図 6-37 Service Parameters Configuration ウィンドウ

 

SDL トレースを使用可能にしたら、そのトレースを収集します。そのトレースを ローカル ドライブに送信する場合、Cisco\Trace サブディレクトリでそれらのトレースを取得できます。また、トレース ファイルをイベント ログまたは CiscoWorks 2000 に送信することもできます。

表 6-32 に説明される SDL フラグ ビットは、Cisco CallManager Administration の Service > Service Parameter 領域で設定されます。次の内容は、特殊の問題に基づいて設定する値の 2 つの例を示します。

通常のコール デバッグに推奨される値は、SdlTraceTypeFlags=0x00000b04

下位レベルのデバッグまたはゲートウェイのデバッグに推奨される値は、SdlTraceTypeFlags=0x00004b05

 

表 6-29 SDL トレース タイプ フラグの定義

SDLTraceTypeFlag
定義

traceLayer1

= 0x00000001

すべてのレイヤ 1 トレースをオンにする

TraceDetailLayer1

= 0x00000002

レイヤ 1 詳細トレースをオンにする

TraceSdlLinkAdmin

= 0x00000004

クラスタ内の Cisco CallManager リンク間のトレース

traceUnused

= 0x00000008

未使用

traceLayer2

= 0x00000010

すべてのレイヤ 2 トレースをオンにする

traceLayer2Interface

= 0x00000020

レイヤ 2 インターフェイスのトレースをオンにする

traceLayer2TCP

= 0x00000040

レイヤ 2 TCPトレースをオンにする

TraceDetailLayer2

= 0x00000080

レイヤ 2 フレームの詳細ダンプ

traceLayer3

= 0x00000100

すべてのレイヤ 3 トレースをオンにする

traceCc

= 0x00000200

すべてのコール制御トレースをオンにする

traceMiscPolls

= 0x00000400

その他のポールのトレース

traceMisc

= 0x00000800

その他のトレースをオンにする
(データベース信号)

traceMsgtrans

= 0x00001000

メッセージ変換信号(TranslateIsdnToSdlReq、TranslateIsdnToSdlRes TranslateSdlToIsdnReq、TranslateSdlToIsdnRes)

traceUuie

= 0x00002000

UUIE 出力トレースをオンにする

traceGateway

= 0x00004000

ゲートウェイ信号

表 6-30 に説明のあるデータ ビットは、Cisco CallManager Administration の Service > Service Parameter 領域で設定されます。次の内容は、特殊の問題に基づいて設定する値の 2 つの例を示します。

通常のシステム デバッグに推奨される値は、SdlTraceDataFlags=0x110

SDL リンクに関する問題の追跡時に推奨される値は 0x13D(これは非コンパクト トレースの場合です。よって、コンパクト トレースを設定する場合は、ビット 0x200 を設定する必要があります。このビットは他のビットと組み合わせて設定できます。)

 

表 6-30 SDL トレース データ フラグの定義

SDLTraceDataFlag
定義

TraceSdlLinkState

= 0x001

SDL リンク初期化のトレースを使用可能にする

TraceSdlLowLevel

= 0x002

ファイル オープンおよびソケット イベントなどの下位レベルの SDL イベントのトレースを使用可能にする

TraceSdlLinkPoll

= 0x004

SDL リンク ポール メッセージのトレースを使用可能にする

TraceSdlLinkMsg

= 0x008

SDL リンク メッセージのトレースを使用可能にする

traceRawData

= 0x010

すべての信号で信号の生データのトレースを使用可能にする

TraceSdlTagMap

= 0x020

タグ マッピングを使用可能にする

traceCreate

= 0x100

トレースの作成および停止のプロセスを使用可能にする

TraceNoPrettyPrint

= 0x200

トレース ファイルの整形表示を使用不可にする


注意 ディスク スペースに関する警告:このインターフェイスから取得する情報はかなり詳細にわたるため、ディスク スペースを大量に消費する可能性があります。このため、所定の時間までトレース ファイルをオンにし、情報を検討するときにはトレースをオフにすることを推奨します。

スニッフィング トレース

スニッフィングとは、ネットワークで IP トラフィックをモニタしてトレース形式で情報を提供するソフトウェア アプリケーションです。スニッフィング トレースには、ネットワークのネットワーク トラフィック量とそのタイプに関する情報が備わっています。TCP/IP パケットまたは UDP パケットは、Cisco CallManager、および IP Phoneおよびゲートウェイなどのエンドポイント デバイスによって使用されるプロトコルです。スニッフィング トレースは、音声オーディオ問題、またはドロップしたコールの原因となるブロードキャスト トラフィック上位レベルを特定するのに役立ちます。一般的なスニッフィング アプリケーションとしては、Network Associates SnifferPro、Hewlett Packard Internet Advisor、および W&G Domino があります。Domino は、スニッフィング用のハードウェアとソフトウェア ソリューション、およびネットワーク アナライザを提供します。Domino を使用する場合には、キャプチャされるスニッフィング ファイル(SnifferPro アプリケーションなどから)の評価に分析ソフトウェアを使用することを推奨します。

スニッフィング トレース アプリケーション

次のリンクを利用して、市販されているいくつかのスニッフィング トレース アプリケーションに関する詳細について把握します。あらゆるスニッフィング アプリケーションは Cisco CallManager と連動して動作します。

Network Associates 社の SnifferPro

http://www.sniffer.com/

Acterna 社の Domino Analyzer

http://www.acterna.com/global/Products/descriptions/DA-3200/VoIP.html

コール詳細レコード(CDR)とコール管理レコード(CMR)

CDR とは、Cisco IP Phoneから発信した(試行した)あらゆるコールを記録するレポート オプションです。基本 CDR と診断用 CDR(または CMR)の 2 種類の CDR があります。CDR を使用可能にすると、SQL Server Enterprise Manager で CDR または診断用 CDR(CMR)をオープンできます。CDR ファイルは、Microsoft Access または Microsoft Excel などのほぼ同様のどのアプリケーションにエクスポートできる SQL データベースに保存されます。

CDR レコードには、課金レコードの生成に必要な情報が含まれます。分散環境では、すべての CDR データが中央設置場所(または、一連のロケーション)に収集されます。Cisco CallManager の障害によって、そのノードに関連する CDR データが取得できなくなることはありません。そのデータは、もはやフラット ファイルとして Cisco CallManage のディスクに保存されませんが、そのかわりに中央データベースにテーブル形式で保存されます。

レコードを書き込む前に Cisco CallManagerが失敗した場合には、コールのレコードは存在しません。つまり、コールが終了する前に 所定の Cisco CallManager が失敗すると、その Cisco CallManager でアクティブなコールのレコードが書き込まれません。

CDR および CMR の詳細については、このマニュアルのコール詳細レコードの項を参照してください。

提供される情報には、次の内容が含まれます。

レコードの読み取りおよび書き込み

確認されている問題

生成されるレコード タイプのリスト

各レコードに含まれるフィールドのリスト、およびフィールドで示す説明の内容

記録されたコール タイプの説明、および各コールに記録されるフィールド

CDR レコードに表示できる理由コードのリスト

CDR の使用可能化または使用不可化

デフォルトでは、システムのインストール時に CDR レコードの作成は使用不可になっています。CDR データを作成する場合は、Cisco CallManager Administration の Service > Service Parameters 領域で CDR を使用可能にする必要があります。システムが稼動している間は、CDR 処理をいつでも使用可能または使用不可にすることができます。よって、CDR を使用可能または使用不可にするために、Cisco CallManager を再起動する必要はありません。すべての変更に対して数秒以内で応答します。CDR データから切り離して、CMR または診断データを使用可能にします。CDR とコール診断の両方を使用可能にしなかった場合には、CMR データが生成されませんが、CMR データがなくても CDR データを生成および記録できます。

次のステップを実行して、CDR を使用可能にします。図 6-38 は、このプロセスに関連する画面を示します。


ステップ 1 Cisco CallManager Administration をオープンします。

ステップ 2 Service > Service Parameters を選択します。

ステップ 3 Cisco CallManager インストールの IP アドレスを選択します。

ステップ 4 設定されたサービスのリストから [Cisco CallManager] を選択します。

ステップ 5 パラメータのリストから CDREnabled を選択します。

ステップ 6 タイプを boolean として定義します。

ステップ 7 True の場合には、 [T] を選択します。

ステップ 8 Update をクリックします。

ステップ 9 クラスタの CallManager ごとにステップ 3 からステップ 8 を繰り返します。

結果 : コール処理レコードがただちにロギングを開始します。


注意 音声の接続性の追跡には、クラスタの Cisco CallManager ごとに CDR ロギングを使用可能にする必要があります。


 

図 6-38 Service Parameters Configuration ウィンドウでの CDR の使用可能化

 

CDR

CDR には基本情報が備わっています。この情報は、CallManager トレースに含まれる詳細情報を理解するのに役立ちます。基本 CDR によって、発信番号、着信番号、送信元 IP アドレス、送信先 IP アドレス、コール時間などの情報が提供されます。CDR は、電話問題のトラブルシューティングに役立ちます。たとえば、ユーザが特定の時間に発生したコールに関する問題をレポートする場合、そのコールおよびその他のコールに関する追加情報を把握するために、その特定時間の前後に作成された CDR を調べることができます。CDR は、一般的に課金目的で使用されます。

診断用 CDR(CMR とも呼ばれる)

診断用 CDR には、送信されたパケット数、受信されたパケット数、なくなったパケット数、ジッタおよび遅延の長さなどの詳細コール情報が備わっています。また、この詳細レベルには、一方向の音声などのいくつかの問題の説明が備わっています。たとえば、送信したパケットのサイズ 10,000 であるのに対し、受信したサイズが 10 しかない場合には、一方向の音声の問題が指摘されます。

Q.931 Translator

Cisco CallManager に同梱されている Q.931 Translator は、H.225 セットアップ メッセージの CallManager トレースを読みやすくするために、IOS 対応形式に変換するために使用するツールです。H.225 は、H.323 プロトコル スタックの一部です。これは、コール制御シグナリングに使用され、Q.931 に基づいています。よって、このツールが有用となるのは、H.323 ゲートウェイ(Cisco IOS ルータ)またはその他の H.323 デバイス(Microsoft NetMeeting など)にアクセスするコールの場合に限ります。

変換プロセスについて

Message Translator の役割は、Cisco CallManager のログ ファイルから受信するデータをフィルタに掛け、それらのデータを解析し、Cisco IOS 対応メッセージに変換することです。アプリケーションには、次に示すように Message Translator インターフェイスにメッセージが表示されます。

Message Translator の使用

次の手順に従ってメッセージ変換プロセスを開始し、Cisco CallManager のログ ファイルをディレクトリ構造で探します。図 6-39 は、対応する変換画面を示します。

図 6-39 Q931 Message Translator

 


ステップ 1 C:\Program Files\Cisco\Bin\q931translator.exe から Q.931 Translator を起動します。

ステップ 2 まず、File メニューをプルダウンして Open を選択します。

ステップ 3 ディレクトリのリストで変換するログ ファイルを選択します。

ステップ 4 ディレクトリ リストから選択したログ ファイルを保存するには、そのファイルが変換された Cisco IOS ログ ファイルであることを識別できるような名前を入力します。選択したログ ファイルが Message Translator の最上部にあるボックスにロードされます。

ステップ 5 変換するメッセージを選択します。選択したメッセージの Cisco IOS 変換が画面最下部の ISDN 変換ボックスにただちに表示されます。

ステップ 6 変換したファイルを保存しておくと、後で活用することができます。これを行うには、File メニューをプルダウンし、Save As IOS オプションを選択します。これで、すべての ISDN メッセージがログ ファイルに変換および保存されます。


 

Cisco CallManager デバイスのトラブルシューティング

この項では、Cisco CallManager および関連デバイスで発生する可能性がある、一般的ないくつかの問題のカテゴリについて説明します。各問題のカテゴリでは、問題の特定に役立つトラブルシューティング ツールが提案されます。このマニュアルでは、起こり得る問題の一般的なカテゴリ、およびそれらの問題のトラブルシューティング方法に関する提案について説明します。ただし、これは問題および解決の完全なリストではありません。このマニュアルで説明されるツールおよびユーティリティを使用して解決できない問題が発生した場合には、サポートについて、Cisco Tecnical Assistance Center(TAC)にお問い合わせください。TAC に連絡する前に、収集した診断情報(トレースなど)だけでなく、Cisco CallManager Administration Details も必ず入手してください。

ここで説明する問題のカテゴリは、次のとおりです。

音声品質

IP Phoneのリセット

コール ドロップ

Cisco CallManager の機能問題

サーバ応答の低速化

ゲートウェイを経由するリオーダー トーン

ゲートウェイ登録の問題

ゲートキーパー登録の問題

Cisco IP Phoneの初期化プロセス

Skinny Station の登録プロセス

Cisco CallManager の初期化プロセス

自己起動プロセス

Cisco CallManager の登録プロセス

Cisco CallManager のキープアライブ プロセス

コール フロー時における Cisco IP Phoneと Cisco IP Phone間の Skinny Station メッセージの交換

Cisco CallManager クラスタ間のコール フローのトレース

Cisco IOS ゲートウェイ

国際電話番号のダイヤル後のビジー信号の発生

クラスタ間 IP Phone 対 IP Phone

コール フローのトレース

失敗したコール フロー

音声品質

音声品質の問題には、通話中の音声の途切れまたは乱れが含まれます。一般的な問題には、音声の一時中断(言葉が途切れるような)の原因となる音声の途切れや、あるいは音声が歪む雑音(エコー)だったり、または話される言葉が弱ったり、ロボットの声のように聞こえたりする悪影響などが含まれます。一方向の音声(つまり、2 人の間の会話ですべて聞こえるのが 1 人だけの場合)は、実質的には音声品質の問題ではありません。これについては、この項の後半で説明します。

音声の問題は、次の 1 つまたは 2 つ以上のコンポーネントが原因と考えられます。

ゲートウェイ

IP Phone

ネットワーク

音声品質の問題のトラブルシューティングを正確に行うには、ドロップと遅延についてインフラストラクチャおよびすべてのデバイスを検討する必要があります。

i ボタン ヘルプ

Cisco IP Phone 7960 には、予測される音声問題の診断に使用するツールがもう 1 つあります。通信中のコールで、i ボタンを 2 回(素早く)押すと、平均および最大のジッタ カウンタだけでなく、パケットの受信および転送の統計情報を含む情報画面が IP Phoneに表示されます。この画面では、 ジッタ は最近到達した 16 パケットの平均で、最大ジッタは平均ジッタの最高ウォーターマークなので注意してください。情報には、次の内容が含まれます。

RxType/TxType:現在通信中のコールで使用されているコーデックです。

RxSize/TxSize:ミリ秒単位で測定される、各パケットのペイロードのサイズです。

RxCnt/TxCnt:現在通信中のコールで送受信されたパケット数です。

AvgJtr:最近の 16 個の RTP パケットで測定された平均ジッタです。

MaxJtr:RTP 受信ストリームの継続期間中に測定された最大ジッタです。注 : これは、ストリーム単位のジッタであり、コールの継続期間のジッタではありません。コールを保留にすると、そのストリームは停止し、保留を解除すると、新しいストリームを作成します。

RxDisc:廃棄された受信パケット数です。

RxLost:リモート側からのパスでロスしたパケット数です。

遅延およびパケットロスの最も一般的な発生源は、高速インターフェイスから低速インターフェイスへのフローが発生するデバイスです。たとえば、ルータで 100 MB のファースト イーサネット インターフェイスを LAN に接続し、低速フレームリレーを WAN に接続する場合が挙げられます。リモート側との通信時に限り、品質の低下が発生する場合(もう一方の方向では音声品質が良好であるのに対し、リモート側だけに音声品質の低下がレポートされる)、次の項目は問題の最も可能性が高い原因となります。

音声トラフィックの優先順位をデータ トラフィックよりも高くなるように、ルータが正しく設定されていない。

WAN が対応する通信中のコールが多すぎる(つまり、受信可能なコール数を制限するコール アドミッション制御がない)。

物理ポートのエラーがある。

WAN 自体に輻輳がある。

LAN で最も一般的な問題となるのが、物理レベルのエラー(CRC エラーなど)です。その原因は、ケーブルおよびインターフェイスの不良、あるいは誤って設定されたデバイス(ポート速度、デュープレックス ミスマッチなど)です。トラフィックがシェアドメディア デバイス(ハブなど)とクロスしていないことを確認してください。また、ネットワークの経路を流れるトラフィックが予想以上に遅いパスを通過している可能性もあります。QoS が正確に設定されている場合には、コール アドミッション制御がない可能性があります。コール アドミッション制御は、各自のトポロジに応じて、Cisco CallManager Administration 設定の Locations を使用するか、ゲートキーパーとして Cisco IOS ルータを使用することで確立できます。いずれの場合でも、WAN 全体で対応できるコール数を常に知っておく必要があります。可能な場合には、前に説明したように無音抑止を使用不可にすることによってそのコール数をテストしてから、2 つのサイト間でコールを発信します。コールは保留または消音にしないでください。その理由は、このときパケットが伝送されなくなるからです。WAN 全体の最大コール数に関しては、すべてのコールを受け入れ可能な品質にする必要があります。もう 1 回コール発信を試行するときにファースト ビジー音が返されることを確認するためにテストしてください。

音声の途切れ、または乱れ

最も一般的な問題の 1 つが、音声の途切れです(多くの場合、言葉が間違っている、または言葉または文章で音節がないと説明される)。これに対して一般的な原因となるのが、パケットの欠落またはジッタ(またはその両方)です。パケット欠落とは、音声パケットがドロップしたか、あまりにも遅れて到達したので使用できなかったために、音声パケットがその送信先に到達しないことです。ジッタとは、パケット到達時間の変動のことです。理想的な状況では、一方の IP Phoneから他方の IP Phoneに送信するすべての VoIP パケットが、きっちりと 20 ミリ秒ごとに 1 個の割合で到達します。これは、パケットがポイント A からポイント B までに到達する所要時間ではなく、単に到達時間の変動を表します。

実際のネットワークでは、遅延が変動する多くの発信元があります。制御できない発信元もあれば、制御できる発信元もあります。パケット音声ネットワークでは、遅延の変動を完全になくすことはできません。IP Phoneおよびその他の音声対応デバイスの DSP(デジタル信号処理)は、遅延の変動を想定して音声の一部をバッファするように設計されています。このデジッタリングは、音声パケットがその送信先に到達し、従来の音声ストリームに挿入できる場合(つまり、ユーザの耳に聞こえる、またはデジタル PCM ストリームを経由して PTSN に送信される)に限り行われます。Cisco IP Phone 7960 は、音声サンプルを 1 秒だけバッファできます。一度に大量に発生したパケットを受信する場合、Cisco IP Phone 7960 は、ジッタ制御の試行でそれらのパケットを再生できる意味では、ジッタ バッファを適応できます。また、ネットワーク管理者は、事前に QoS(サービス品質)とその他の指標を適用し、パケット到達時間の間で変動を最小限にする必要があります(特にコールがワイドエリア ネットワークを通過する場合)。

音声の途切れまたは乱れが発生した場合、まず、音声のパスを特定する必要があります。コールの音声ストリームのパスで各ネットワーク デバイス(スイッチおよびルータ)を識別します。音声が 2 つの IP Phone間、IP Phoneとゲートウェイ間となる場合、複数の区間(IP Phoneからトランスコーディング デバイス、およびそのデバイスからもう 1 つの IP Phone)に存在することに留意してください。問題が 2 つのサイト間のみ、任意のゲートウェイのみ、あるいは任意のサブネットなどに発生するかどうかを識別します。これは、さらに注意深く調べる必要があるデバイスの範囲を限定するのに役立ちます。次に、無音抑止(Voice Activation Detection または VAD としても知られる)をまだ使用不可にしていない場合、無音抑止を使用不可にします。これは、多くの場合に最適な手段となります。このメカニズムでは、音声が無音のときに何らかの音声を送信しないようにすることで帯域幅を保存しますが、言葉の初めに顕著な(容認できない)クリッピングが発生する原因となる場合があります。これは、Cisco CallManager Administration の Service > Service Parameters を選択することで使用不可にできます。そこで、図 6-40 に示すようにサーバと Cisco CallManager を選択します。さらに、SilenceSuppressionSystemWide を [F] に設定します(その代わりに、
SilenceSuppressionWithGateways を [F] に設定できますが、これは H.323 ゲートウェイまたは MGCP ゲートウェイに適用されません)。判断に迷う場合には、その両方に対して Value F を選択することにによって、それらをオフにします。

図 6-40 SilenceSuppressionSystemWide の設定表示

 

ネットワーク アナライザを使用できる場合に、無音抑止を使用不可にすると、2 つの IP Phone間でモニタされたコールでは 1 秒ごとに 50 パケット(20 ミリ秒ごとに 1 パケット)が到達します。正確にフィルタを掛けると、パケットが欠落しているか、過剰に遅延しているかどうかを確認できます。

クリッピングの原因となるのは遅延そのものではなく、遅延の変動だけなので留意してください。 表 6-31 では、20 ミリ秒の音声パケット(RTP ヘッダーをもっている)間の到達時間に関する完全なトレースを示します。品質が低下したコール(多くのジッタが発生するコールなど)では、到達時間がかなり変化します。

 

表 6-31 「完全な」トレースの出力例

パケット番号
時間、絶対(ミリ秒)
時間、デルタ(ミリ秒)

1

0

 

2

0.02

20

3

0.04

20

4

0.06

20

5

0.08

20

パケット アナライザをネットワークの各種ポイントに設定すると、遅延の発生源まで絞り込むことができます。アナライザが使用可能でない場合、他の方式が必要となります。音声のパスで各デバイスのインターフェイス統計情報を調べることが重要です。音声品質が低下したコールを追跡するもう 1 つのツールは、Diagnostic Call Detail Records(CDR)です。CDR の詳細については、「ツールおよびユーティリティ」の項と「コール詳細レコード」の項を参照してください。

すべてのコールに対してジッタおよび遅延の値を取得できます(ただし、コールが終了した後に限る)。図 6-41 は、診断用 CDR(実際のテーブル名は CallDetailRecordDiagnostic)の例を示します。送信パケット数、受信パケット数、ロスト パケット数、ジッタ、および遅延がすべて記録されます。globalCallID 値を使用して通常の CDR テーブルでコールを検索し、切断解除の理由およびその他の情報を取得できます。図 6-41 では、両方のテーブルをオープンした状態を示します。診断用 CDR では、この情報をレポートできるかもしれないあらゆるデバイスが含まれることに注目ください。そのため、2 つの Cisco IP Phone間で問題が発生した場合、各コールについて 2 つのテーブル項目を確認します。たとえば、Cisco IOS ゲートウェイを通過するコールがある場合、ゲートウェイでは、この情報を含む SQL データベースを通知するメカニズムがないため、ゲートウェイではなく、Cisco IP Phoneの診断情報を確認するだけです。

図 6-41 コール詳細レコードの診断例

 

クラッキング

「品質の低下」の別の徴候と考えられるのが、クラッキングです。これは、電源装置の不良、またはある場所での IP Phoneの近くでの強力な電気的障害によって発生することがあります。電源装置を交換するか、IP Phoneを別の場所に移動してください。

エコー

エコー(送話者エコーとしても知られる)は、図 6-42 に示されるように、プライマリ信号パスに送信される送話者のスピーチ エネルギーが遠端の受信パスに連結されると発生します。送話者は、そのとき自分の声が聞こえ、その声はエコー パスの遅延合計時間によって遅延が発生したものです。エコーは、従来の PBX ネットワークに発生していたかもしれないが、遅延が短いのでエコーに気付かないのを思い出すことは重要です。

図 6-42 エコー効果の図示

 

図 6-42 では、John の音声が反響します。従来のネットワークでは、遅延がかなり短いので、その音声の反響に気付きません。ユーザにとっては、エコーよりもサイド トーンのように聞こえます。VoIP ネットワークでは、このエコーが聞こえます。これは、エコーが聞こえるほど十分な遅延がパケット化と圧縮によって挿入されるためです。留意すべき重要点は、エコーの原因には必ずアナログ コンポーネントとアナログ回線が伴うことです。たとえば、IP パケットは方向転換して低い音声レベルの発信元に戻ることはできません。デジタル T1/E1 回線では、そのようなことはあり得ません。そのため、一方の Cisco IP Phoneから他方の IP Phoneへのコールでは、問題が発生しません。ただし、例外となるのが、一方の側がスピーカ フォンを使用して音声のボリュームをかなり高くしたり、音声ループが作成される何らかの状態が発生したりする場合です。

エコー問題のトラブルシューティングを行う場合、テストまたは調査対象の IP Phoneがスピーカ フォンを使用していないこと、そのヘッドセットのボリュームが適切なレベルに設定(最大音声レベルの 50 パーセントで開始)されていることを確認します。ほとんどの場合、デジタルまたはアナログのゲートウェイを経由する PSTN に接続したときに問題が発生します。Cisco IP Phone ユーザは、自分の音声が反響する問題が発生する場合があります。問題の実際の発生源は、ほぼ必ず終端にありますが、大半は RSTN で何らかの変更を行うことができません。そのため、最初のステップとして、使用されているゲートウェイを判別します。デジタル ゲートウェイが使用されている場合、信号の強度を弱くして反響するエネルギーが減少するように、送信方向(PSTN に向かって)にパッディングを追加することができます。さらに、受信レベルを調整して、反響音をさらに減らすことができます。1 回の調整は微量にすることを念頭に置いておくことが非常に重要です。信号の減衰量があまりにも大きいと、両方向の音声が聞こえなくなります。代わりに、キャリアに連絡して、回線をチェックするように要求することもできます。北米で一般的な T1/PRI 回線では、入力信号が -15 dB です。その信号レベルが非常に高い場合(たとえば、-5 dB)、エコーが発生する可能性が高くなります。

エコーが発生するすべてのコールのログを保持します。問題の発生時間、発信元の電話番号、および発信先の電話番号すべてが記録されます。ゲートウェイは、32 ミリ秒までのエコー キャンセレーションを設定できます。反響音の遅延がこれよりも長い場合には、エコー キャンセレーションが正常に機能できなくなります。これは、ローカル コールの問題ではありません。長距離コールでは、セントラル オフィスのネットワークにエコー キャンセラが構築する必要があります。これが、エコーが発生するコールの外線電話番号をメモしておくことが重要となる理由の 1 つです。

したがって、上述の John の場合では、エコーが PSTN 側の任意の場所に発生しています。エコーの原因がネットワークのどこかにあると主張される場合があります。これは事実ですが、エコーについて次のような事実があることも念頭に置くことが必要です。

アナログ回線がエコーの原因となる ― デジタル回線または IP ネットワークでビットが送信パスから受信パスに漏出することはありません。

エコー キャンセレーション

Cisco IOS ゲートウェイおよび Skinny ゲートウェイには、組み込みのエコー キャンセレーションがあります。エコー キャンセレーションとは、テール回線での漏出によって発生するエコー のレベルを低減するデバイスです。次の説明では、エコー キャンセラの機能と効果について解説します。特に次の内容について詳しく解説します。

テール回線

エコー キャンセラ カバレッジ

キャンセルできないエコー

持続的なエコーのトラブルシューティング

テール回線

テール回線とは、パケット音声ゲートウェイの PSTN 側に接続されたあらゆるコンポーネントです。テール回線には、すべてのスイッチ、マルチプレクサ、配線、PBX など、音声ゲートウェイと IP Phone間のあらゆるコンポーネントが含まれます。

図 6-43 エコー キャンセレーション効果の図示

 

図 6-43 では、Rx 信号は IP ネットワークから発信する John の音声で、Tx 信号は Jane の音声と John の音声のエコーの混合です。

エコー キャンセラは、PSTN 方向に対してのみ機能します。エコー キャンセラは、接続先のテール回線で生成されたエコーだけを除去します。さらに、テール回線から発信し、IP ネットワークへ向かっている信号のエコー部分を除去します。エコー キャンセラは、テール回線の電気的な特性を知り、テール独自のモデルをメモリに形成することで、エコーを除去します。このモデルを使用して、現在および過去の Rx 信号(John の音声)に基づいて独自の「推定されたエコー」を形成します。John の音声が、この機能的なモデルを通過すると、John のエコー信号が推定されます。その後、この推定された「John のエコー」は、テール回線から発信する実際の Tx 信号から除去されます。

エコー キャンセラ カバレッジ

エコー キャンセラのカバレッジ(テール カバレッジまたはテールの長さ)とは、エコー キャンセラのパラメータです。これにより、メモリでテール回線の長さが制御されてから、キャンセル可能なエコーの時間ウィンドウが決定されます。

図 6-44 時間と対比したエコーのピーク振幅の図示

 

図 6-44 では、ピークはテール回線の各エコーに対応しています。このシステムには、3 つのエコーがあります(約 3 ミリ秒後に強いエコー、約 7 ミリ秒後と 9 ミリ秒後に弱いエコー)。約 12ミリ秒後に、インパルス応答で意味のあるエネルギーがなくなります。この 3 つのエコーをすべてキャンセルするには、そのようなテール回線に対応するエコー キャンセラを少なくとも 12 ミリ秒のテール カバレッジでプロビジョニングする必要があります。この回線に関しては、1 度目のエコーが 5 ミリ秒の時間ウィンドウの範囲に入るため、カバレッジが 5 ミリ秒のエコー キャンセラがかなり良好に機能しますが、そのエコー キャンセラでは 2 度目の 2 つのエコーを「確認」できないため、それらのエコーがキャンセルされずに残ってしまいます。エコー キャンセラが静的なテール回線に対応することを再度重視することが重要です。テール カバレッジ パラメータは、IP ネットワーク、ラウンドトリップ遅延、またはネットワークの遅延が変動していることとは無関係です。


) QoS(サービス品質)により、所定の輻輳レベルのネットワークのエンドツーエンドの遅延は、改善される場合があります。遅延が短いほど、発生するエコーに悩まされることは少なくなります。ただし、QoS の形式によるエコー感知度に対する危険ゾーン以下に遅延を減らすことはできません。QoS は、エコー以外の点で役に立ちますが、エコーに対処する魔法の QoS スイッチは存在せず、今後も存在しないでしょう。


回線でエコー キャンセラが機能していることを確認する 1 つの方法は、コールを発信して、その直後に言葉を繰り返して発声することです。そこで、音声メール システムに発信している場合には、回線の他方の終端側が無音であるべきなので、アナウンス音声が終わるまで待機してから、実験を開始します。エコー キャンセラを使用可能にし、そのシステムのエコーをキャンセル可能にした場合、最初のいくつかの発話に対してエコーが聞こえ、その後次第に衰退するのが分かります。数秒間の発話後、エコーは消えていくか、コールの開始時のエコー レベルに比べて非常に弱くなります。これは、エコー キャンセラが機能していることを示します。エコー キャンセラは、調査しているテール回線を認識しないで、開始することを念頭に置いてください。仮想テール回線モデルを形成するには、テール回線を通過する一定量の発話およびエコーをモニタする必要があります。この試行期間は、エコー キャンセラのコンバージェンス時間として知られています。通信中の発話の最初の数秒以内にコンバージェンスが予期されます。コンバージェンス時間が経過しても、時間の経過とともにエコーが弱くならない場合には、次の 2 つの可能性が考えられます。

1. エコー キャンセラが無効か、破損している

2. エコーの発生源がキャンセルできない

その他の宛先にコールを発信して、標準的なエコーの減衰動作を捜してください。

キャンセルできないエコー

キャンセルできないエコーとは、1)聞こえないようにするには大きすぎるエコー、または 2)エコー キャンセラのカバレッジの時間ウィンドウを超えた遅延が発生したエコーです。エコーがあまりにも大きいと、エコーが Jane の音声のようによく聞こえます(エコー キャンセラの観点から言えば)。つまり、エコー キャンセラによる減衰よりもさらに減衰を行って、感知できないようにする必要があります。テール回線(複数の PSTN ホップを含む)、一部の長距離トランク、および一連のデジタル リンクとアナログ リンクの交替によって、テール カバレッジ ウィンドウを超えるエコーが発生します。

持続的なエコーのトラブルシューティング

エコーが依然として持続し(コールが終わるまで続く)、エコー キャンセラが動作していることを明示している場合、これは、エコー キャンセラで修正できないエコーであることを示します。したがって、エコーが大きすぎるか(確率的に高い)、その遅延が長すぎるか(確率的に低い)のいずれかです。そこで、2 つの問題が発生します。第 1 に、どちらのケースかを特定すること、第 2 に、エコーを修正する場所を突き止めることです。

1. エコー キャンセラが ON にプロビジョニングされ、カバレッジが最大に設定されていることを確認します。

2. 出力インピーダンスと出力レベルを、ゲートウェイのアナログ音声ポートに接続したアナログ通信機器に合わせます。

3. 問題が発生しているテール回線を特定します。

4. 発信先の IP Phoneがスピーカ フォンまたはヘッドセットの場合、おそらくすぐに中断できます。スピーカ フォンまたはヘッドセットを一般的な受話器に交換して、エコーが正常に衰退するかどうかを確認します。

5. 音声ゲートウェイのエコー キャンセラが ON(Skinny ゲートウェイが常に ON に設定される)にプロビジョニングされ、そのカバレッジが最大に設定されていることを確認します。エコー キャンセラの通常の動作をテストします(つまり、数秒間の会話でエコーが衰退するかどうか)。上述の手順に従って、エコー キャンセラが正常に機能することを確認します。

エコー キャンセラでエコーを検出するためには、送信音声と受信エコーの間の差異を少なくともCisco IOS ゲートウェイで 10 dB、Skinny ゲートウェイで 15dB にする必要があります。15 dB 以上の差異が最適です。IOS Gateway を使用している場合、「show call active voice」コマンドを実行して、Tx レベルおよび Rx レベルをモニタできます。声の強弱をつけて発話しながら、このコマンドを数回実行して、その結果を記録します。Tx と Rx 間の dB レベルの差異が 10 dB 近く、あるいはそれ未満の場合、エコー キャンセラでコンバージョンが行われない原因となります。この場合、PSTN で送受信する信号を減衰またはパッディングすることで、その問題を軽減できます。Tx と Rx 間の信号レベルの差異が 15 dB 以上の場合、エコー キャンセラのカバレッジ期間外でエコーが発生することを示します。

Skinny ゲートウェイ(6608、つまり DT-24/DE-30)のパッディングの設定を調整するには、Device -> Gateway をクリックします。調整するゲートウェイを検索および選択し、設定の最下部までスクロールします。図 6-45 は、この設定画面を示します。

図 6-45 Skinny ゲートウェイ設定の表示例

 

Cisco IOS Gateways でパッディングを調整するには、次の構成設定値を選択します。

voice-port 3/0:23
input gain -6
output attenuation 5
echo-cancel coverage 32
 

ゲートウェイで増幅および減衰の調整が有効にならない場合、プロバイダと共同作業を行って各自のゲートウェイで有効になる信号レベルを調整してください。

一方向の音声または音声なし

コール時に、一方の送話者が他方の送話者の声が聞こえないときに、一方向の音声が発生します。これは、Cisco IOS ゲートウェイが正しく設定されていない、ファイアウォール、またはルート指定問題かデフォルト ゲートウェイ問題が中でもその原因となります。

コール時に一方向の音声または音声なしが発生する原因は、数多くあります。最も一般的な原因となるのが、正しく構成されていないデバイスです。たとえば、Cisco CallManager は、Cisco IP Phoneのコール セットアップを処理します。2 つの Cisco IP Phone間(または Cisco IP Phoneとゲートウェイ間)では、実際の音声ストリームが発生します。したがって、コールを発信する IP Phoneに発信先の IP Phoneへの IP ルートがない場合、Cisco CallManager で発信先の IP Phoneに信号を送る(ベルを鳴らす)ことができるということが十分に考えられます。一般的に、これが発生するのは、IP Phoneのデフォルトのゲートウェイが正しく設定されていない(手作業または DHCP サーバ)場合です。

コールで持続的に一方向の音声が発生する場合、IP Phoneと同じサブネット上にあり、同じデフォルトのゲートウェイを持つ PC を IP Phoneとして使用して、発信先の Cisco IP Phoneを PING します。発信先の IP Phone(発信先の IP Phoneと同じデフォルトのゲートウェイを持つ)と同じサブネット上にある PC を導入し、発信元の IP Phoneを PING します。両方のテストは正常に機能するはずです。また、音声トラフィックは、一方向または両方向の音声をブロックできるファイアウォールまたはパケット フィルタ(ルータのアクセス リストなど)による影響を受けます。音声対応の Cisco IOS ゲートウェイを通過するときに限り、一方向の音声が発生する場合、そのゲートウェイの設定を入念にチェックします。IP ルーティングを使用可能にする必要があります(その設定を調べて、その先頭近くに no ip routing コマンドがないことを確認する)。また、WAN 全体の帯域幅を節約するために RTP ヘッダー圧縮を使用している場合、WAN 回線に接続する音声トラフィックを搬送する各ルータで RTP ヘッダー圧縮が使用可能であることを確認します。ただし、RTP ヘッダーを一方のエンドで圧縮し、他方の WAN 側で圧縮解除できないという状況は発生しません。IP Phoneまたはゲートウェイが実際にパケットを送受信していることを確認できるため、一方向の音声問題のトラブルシューティングを行う場合に、スニッフィングが非常に有効なツールとなります。診断用 CDR は、送受信したパケットをログするため、コールで一方向の音声が発生しているかどうかを判断するのに役立ちます(「音声の途切れ、または乱れ」を参照)。また、コール中に Cisco IP Phone 7960 で i ボタンを 2 回(素早く)押して、送受信したパケットに関する詳細を表示することもできます。


) コールを消音中にしている(IP Phoneの消音ボタンを押した)場合、パケットは送信されません。保留ボタンを押すと、音声ストリームが停止するため、いずれの方向でもパケットが送信されません。保留ボタンを解除すると、すべてのパケット カウンタがリセットされます。TX カウンタおよび RX カウンタを同一の状態にするために、両方のデバイスで無音抑止を使用不可にする必要があるので留意してください。システム全体で使用不可抑止を使用不可にしても、Cisco IOS ゲートウェイには影響しません。


MTP および一方向の音声

コールで MTP(メディアの停止ポイント)を使用している場合(H.323 バージョン 2 をサポートしない H.323 デバイスを使用して、保留、転送などの追加サービスをサポートするため)、割り当てられた MTP が正常に機能しているかどうかを確認するためにチェックします。Cisco IOS ルータでは、H.323 バージョン 2 のリリース 11.3(9)NA と 12.0(3)T をサポートします。Cisco IOS リリース 12.0(7)T で開始すると、オプションの H.323 Open/Close LogicalChannel がサポートされ、追加サービスにソフトウェア ベースの MTP はもはや必要となりません。

MTP デバイスは、会議ブリッジとトランスコーダと同様に 2 つ以上の音声ストリームをブリッジします。MTP、会議ブリッジ、またはトランスコーダが正常に機能しない場合、一方向の音声または音声損失が考えられます。MTP をシャットダウンし、MTP が問題の原因となっているかどうかを調べます。

IP Phoneのリセット

次の 2 つのいずれかの理由で、IP Phoneの電源をいったん切ってから改めて投入するか、電話をリセットします。

Cisco CallManager に接続している TCP の障害発生

IP Phoneのキープアライブ メッセージの確認応答の受信失敗

IP Phoneのリセットのトラブルシューティングを行うには、次のステップを実行します。


ステップ 1 問題に関連するリリース ノートについては、CCO( http://www.cisco.com/ にある Cisco Connection Online)で Cisco CallManager リリース ノートをチェックします。

ステップ 2 IP Phoneがリセットしている場合、Event Viewer をチェックします。図 6-46 に示すように、IP Phoneのリセットは情報イベントと見なされます。

図 6-46 Event Viewer Information ウィンドウ

 

ステップ 3 IP Phoneのリセットと、リセットした前後の時間に発生したと思われるエラーを調べます。

ステップ 4 CallManager トレースを開始して、リセットしている IP Phoneの一般的な特性を識別することによって、問題を特定します。たとえば、すべての IP Phoneが同じサブセット、同じ VLAN などに配置されているかどうかをチェックします。トレースを調べて、次の内容を判断します。

a. リセットがコール中に継続的に、あるいは断続的に発生しているか。

b. Cisco IP Phone 7960、Cisco IP Phone 30VIP などに対して、IP Phoneのモデルの類似性があるかどうか。

ステップ 5 頻繁にリセットする IP Phoneでスニッフィング トレースを開始します。IP Phoneがリセットした後、トレースを調べて TCP リトライが発生しているかどうかを判断します。TCP リトライが発生している場合には、ネットワーク問題があることを示します。トレースでは、IP Phoneが 7 日ごとにリセットするなどのように、リセットの何らかの一貫性を示すことがあります。これは、7 日ごとに DHCP リース期限が切れることを示す場合があります(この値はユーザが設定できるため、2 分ごとなどのような設定をする)。


 

コール ドロップ

コールが予定よりも早く終了すると、コール ドロップが発生します。CDR を使用してコール ドロップの考えられる原因を判断します(特に問題が断続的に発生する場合)。コール ドロップは、間違った PRI 設定やエラーなど、IP Phoneまたはゲートウェイのリセット(前述の項を参照)、回線の問題の結果として発生します。

最初のステップでは、この問題を 1 つの IP Phoneまたは 1 つの IP Phone グループに特定するかどうかを判断します。多くの場合、問題が発生した IP Phoneはすべて特定のサブネットまたはロケーションにあります。次のステップでは、図 6-47 に示したように、IP Phoneまたはゲートウェイのリセットについて Event Viewer をチェックします。

図 6-47 コール ドロップの原因の診断時にアクセスした Event Viewer 画面

 

リセットした IP Phoneごとに警告とエラー メッセージが 1 つずつあります。このケースでは、問題の多くが、IP Phoneが Cisco CallManager との TCP 接続をキープアライブ状態にできないため、Cisco CallManager でその接続をリセットすることです。これが発生するのは、IP Phoneを切ったか、ネットワークに問題がある可能性があるためです。コール ドロップが断続的な問題である場合、図 6-48 に示すように、IP Phone登録を記録するために、Microsoft Performance を使用すると便利です。

図 6-48 IP Phone登録の確認に使用する Microsoft Performance 画面

 

Cisco Access DT-24+ など特定のゲートウェイを通過するときにだけ、問題が発生すると思われる場合、トレースを使用可能にするかまたは CDR を表示する(あるいはその両方)ことが最適な手段となります。CDR ファイルには、問題の原因の判断に役立つ COT(Cause Of Termination)が含まれます。図 6-49 は、COT 検索における CDR ファイルの表示を示します。

図 6-49 COT 評価に使用する CDR ファイル ビューの例

 

接続解除の理由種別(コールを接続解除した側に応じて origCause_value および destCause_value)は、 http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/dbook/disdn.htm にある Q.931 接続解除理由コードと対応します。図 6-49 では、理由 16 は通常のコール クリアを意味します。コールがゲートウェイを通過して PSTN に向かっている場合、CDR を使用してコールを接続解除した側を判断できます。同じ情報の多くは Cisco CallManager でトレースを使用可能にすることによって取得できます。トレース ツールは、最終手段として、またはネットワークがまだ実稼動していない場合に限り、使用します。

ロードのチェック

すべての問題と同様に、最新のソフトウェア ロード、新しいパッチ、または問題に関連するリリース ノートについては、IP Phoneおよびゲートウェイのロードと CCO( http://www.cisco.com/ にある Cisco Connection Online)をチェックしてください。

Cisco CallManager の機能問題

会議ブリッジまたはメディアの停止ポイントなどの機能を Cisco CallManager と併用すると、問題が発生する場合があります。これらの機能問題のいくつかは、設定エラーまたはリソースの不足によって発生します。たとえば、指定した Ad Hoc 会議のリソース数が超過した場合、ユーザが電話会議を行うことができない場合です。そこで、ユーザが会議機能を開始しようとすると、コールがドロップしてしまいます。これが間違いなく使用可能な会議リソース数に関する問題である場合には、Cisco CallManager の機能問題と考えられます。会議リソースが要求されても、使用できなかった回数は、Microsoft Performance でログされるカウンタの 1 つです。会議リソースが使用可能でも、会議サービスが停止した場合にも、同様の動作が発生します。

コーデック/地域 : コーデック ミスマッチ

オフフックにしたときにリオーダー トーンが聞こえる場合、これは地域間のコーデック不一致の結果と考えられます。両方のコール終端で少なくとも 1 つの共通コーデック(G.711 など)をサポートしていることを確認します。サポートしていない場合には、トランスコーダーを使用する必要があります。

地域によって、その他の各地域で使用できるコーデックのサポート範囲が指定されます。つまり、あらゆるデバイスは地域に属します。


) Cisco IOS ルータを含むコーデック ネゴシエーションはサポートされていません。


Region1<->Region2 = G.711 は、Region1 のデバイスと Region2 のデバイス間のコールが、G.711(G.711、G.729、G.723 などでサポートされるコーデック)と同じあるいはそれ以下の帯域幅が必要な G.711 またはその他サポートされたコーデックを使用できることを示します。

各デバイスには、次のコーデックがサポートされます。

Cisco IP Phone 79xx:G.711A-law/µ-law、G.729

Cisco IP Phone SP12 series and VIP 30:G.711A-law/µ-law、G.723.1

Cisco Access Gateway DE30 および DT-24+:.711A-law/µ-law、G.723.1

Cisco Catalyst WS-X6608-T1/E1:G.711A-law//µ-law、G.729

ロケーション

番号をダイヤルした後にリオーダー トーンが聞こえる場合、コール終端のデバイスの 1 つが配置されたロケーションに対して Cisco CallManager の帯域割り当てが超過していること(24k 未満)が考えられます。Cisco CallManager では、コールを発信する前に各デバイスで 24k の帯域幅が使用可能であるかをチェックします。使用可能な帯域幅が 24k 未満の場合、Cisco CallManager ではコールをセットアップしないため、リオーダー トーンが聞こえてしまいます。

12:42:09.017 Cisco CallManager|Locations: Orig=1 BW=12 Dest=0 BW=-1 (-1 implies infinite bw available)
12:42:09.017 Cisco CallManager|StationD - stationOutputCallState tcpHandle=0x4f1ad98 12:42:09.017 Cisco CallManager|StationD - stationOutputCallInfo CallingPartyName=, CallingParty=5003, CalledPartyName=, CalledParty=5005, tcpHandle=0x4f1ad98
12:42:09.017 Cisco CallManager|StationD - stationOutputStartTone: 37=ReorderTone tcpHandle=0x4f1ad98
 

コールを確立すると、Cisco CallManager ではそのコールで使用されるコーデックに応じてロケーションから帯域幅を減らします。Cisco CallManager では、そのコールが G.711 を使用している場合には 80k、G.723 を使用している場合には 24k、G.729 を使用している場合には 24k をロケーションから減らします。

会議ブリッジ

次の情報を利用して、会議ブリッジを使用できない問題のトラブルシューティングを行います。これは、ソフトウェアまたはハードウェアの問題と考えられます。

まず、Cisco CallManager で登録した会議ブリッジのリソース(ソフトウェアまたはハードウェア)が使用可能であるかどうかをチェックします。これをチェックするには、Microsoft Performance を使用して使用可能なユニキャスト会議数をチェックします。

Cisco IP Voice Media Streaming アプリケーションで会議ブリッジ機能を実行します。次のトレースで示すように、Cisco IP Media Streaming の 1 つのソフトウェアをインストールすると、16 個の使用可能なユニキャスト会議(1 会議につき 3 人)がサポートされます。

10:59:29.951 Cisco CallManager|UnicastBridgeControl - wait_capabilities_StationCapRes - Device= CFB_kirribilli - Registered - ConfBridges= 16, Streams= 48, tcpHandle=4f12738
10:59:29.951 Cisco CallManager|UnicastBridgeManager - UnicastBridgeRegistrationReq - Device Registration Complete for Name= Xoð_ô%ð_ - DeviceType= 50, ResourcesAvailable= 16, deviceTblIndex= 0
 

次のトレースで示すように、1 つの E1 ポート(8x E1 ポートを含む WS-X6608-E1 カード)により、5 つの使用可能なユニキャスト会議(最大会議サイズ = 6)がサポートされます。

11:14:05.390 Cisco CallManager|UnicastBridgeControl - wait_capabilities_StationCapRes - Device= CFB00107B000FB0 - Registered - ConfBridges= 5, Streams= 16, tcpHandle=4f19d64
11:14:05.480 Cisco CallManager|UnicastBridgeManager - UnicastBridgeRegistrationReq - Device Registration Complete for Name= Xoð_ô%ð_ - DeviceType= 51, ResourcesAvailable= 5, deviceTblIndex= 0
 

次の Cisco Catalyst 6000 8 Port Voice T1/E1 および Services Module のハードウェア トレースは、カードの E1 ポート 4/1 が会議ブリッジとして Cisco CallManager に登録されていることを示します。

greece-sup (enable) sh port 4/1
Port Name Status Vlan Duplex Speed Type
----- ------------------ ---------- ---------- ------ ----- ------------
4/1 enabled 1 full - Conf Bridge
Port DHCP MAC-Address IP-Address Subnet-Mask
-------- ------- ----------------- --------------- ---------------
4/1 disable 00-10-7b-00-0f-b0 10.200.72.31 255.255.255.0
Port Call-Manager(s) DHCP-Server TFTP-Server Gateway
-------- ----------------- --------------- --------------- ---------------
4/1 10.200.72.25 - 10.200.72.25 -
Port DNS-Server(s) Domain
-------- ----------------- -------------------------------------------------
4/1 - 0.0.0.0
Port CallManagerState DSP-Type
-------- ---------------- --------
4/1 registered C549
Port NoiseRegen NonLinearProcessing
----- ---------- -------------------
4/1 disabled disabled
 

次に、会議数が超過したために問題が発生したかどうかを判断するために、会議(Ad Hoc または Meet-Me)に設定された最大ユーザ数をチェックします。

問題のトランスコーディング

Cisco Catalyst 6000 8 Port Voice T1/E1 および Services Module でハードウェア トランスコーダをインストールしても、予期したように機能しない場合(つまり、共通のコーデックを持たない 2 人のユーザ間にコールを発信できない)、使用可能なトランスコーダのリソースが Cisco CallManager に登録されているかどうかをチェックします(トランスコーダハードウェアにする必要があります)。Microsoft Performance を使用して、 MediaTermPointsAvailable の数が使用可能であることをチェックします。

次のトレースに示されるように、1 つの E1 ポート(8x E1 ポートを含む WS-X6608-E1 カード)には、16 コールのトランスコーダ/MTP リソースが備わっています。

11:51:09.939 Cisco CallManager|MediaTerminationPointControl - Capabilities Received - Device= MTP00107B000FB1 - Registered - Supports 16 calls
 

次の Services Module つきの Cisco Catalyst 6000 8 Port Voice T1/E1 のハードウェア トレースは、カードの E1 ポート 4/2 がMTP/トランスコーダとして Cisco CallManager に登録していることを示します。

greece-sup (enable) sh port 4/2
Port Name Status Vlan Duplex Speed Type
----- ------------------ ---------- ---------- ------ ----- ------------
4/2 enabled 1 full - MTP
Port DHCP MAC-Address IP-Address Subnet-Mask
-------- ------- ----------------- --------------- ---------------
4/2 disable 00-10-7b-00-0f-b1 10.200.72.32 255.255.255.0
Port Call-Manager(s) DHCP-Server TFTP-Server Gateway
-------- ----------------- --------------- --------------- ---------------
4/2 10.200.72.25 - 10.200.72.25 -
Port DNS-Server(s) Domain
-------- ----------------- -------------------------------------------------
4/2 - 0.0.0.0
Port CallManagerState DSP-Type
-------- ---------------- --------
4/2 registered C549
Port NoiseRegen NonLinearProcessing
----- ---------- -------------------
4/2 disabled disabled

) 会議ブリッジとトランスコーダ/MTPの両方に対して、同じ T1/E1 ポートを設定することはできません。


同じコーデックがサポートされていない低ビット レート コード(G.729、G.723 など)を使用して 2 つのデバイス間でコールするためには、トランスコーダのリソースが必要です。図 6-50 は、これから説明する基本的なトランスコーダの実装を示します。

図 6-50 トランスコーダの実装環境

 

図 6-50 では、地域 1 と 地域 2 間のコーデックが G.729 というように Cisco CallManager で設定していることを前提とします。次のシナリオが考えられます。

IP Phone A の発信者がコールを発信する場合、Cisco CallManager ではその IP Phoneが Cisco IP Phone 7960 で、G.729 をサポートしていることを認識します。ディジットが収集された後、Cisco CallManager ではコールの発信先が 地域 2 のユーザ D であることを判別します。発信先のデバイスも G.729 をサポートしているため、コールがセットアップされ、IP Phone A と IP Phone D 間で直接音声が流れます。

IP Phone B の発信者が Cisco IP Phone 12SP+ を使用して IP Phone D にコールを発信した場合には、Cisco CallManager では発信元の IP Phoneが G.723 または G.711 しかサポートしていないことを認識します。そこで、Cisco CallManager ではトランスコーディング リソースを割り当て、IP Phone B とトランスコーダ間は G.711 で、トランスコーダと IP Phone D 間は G.729 で音声が流れるようにする必要があります。トランスコーダを使用できない場合、IP Phone D のベルは鳴りますが、応答直後にコールは接続解除されます。

IP Phone B の発信者が IP Phone F(Cisco IP Phone 12SP+)にコールを発信した場合、地域間で使用するコーデックとして G.729 が設定されますが、実際には 2 つの IP Phoneは G.723 を使用します。両方の終端が G.723 をサポートし、G.723 が G.729 よりも狭い帯域幅を使用するので、G.723 が使用されます。

Cisco uOne 音声メール システム(G.711 のみサポート)または G.711 用に構成された Cisco IOS ルータを地域 1 に追加する場合、地域 2 からコールするときには、トランスコーディング デバイスを使用する必要があります。トランスコーディング デバイスを使用できない場合には、コールが失敗します。

MTP リソースの問題

MTP リソースの問題が原因と考えられるのは、コールを確立しても、H323v2をサポートしない H.232 デバイスで追加サービスが使用できない場合です。第 1 に、Cisco CallManager に登録した使用可能な MTP リソース(ソフトウェアまたはハードウェア)があるかどうかを判断します。これを行うには、Microsoft Performance を使用して MediaTermPointsAvailable の数をチェックします。

次のトレースで示すように、1 つの MTP ソフトウェア アプリケーションでは 24 コールをサポートします(MTP を使用して、H323v2をサポートしない H.323 デバイスに追加サービスをサポートする)。

10:12:19.161 Cisco CallManager|MediaTerminationPointControl - Capabilities Received - Device= MTP_kirribilli. - Registered - Supports 24 calls
 

次のトレースで示すように、1 つの E1 ポート(8x E1 ポートを含む WS-X6608-E1 カード)には、16 コールの MTP リソースが備わっています。

11:51:09.939 Cisco CallManager|MediaTerminationPointControl - Capabilities Received - Device= MTP00107B000FB1 - Registered - Supports 16 calls
 

次の Cisco Catalyst 6000 8 Port Voice T1/E1 および Services Module のハードウェア トレースは、カードの E1 ポート 4/2 がMTP/トランスコーダとして Cisco CallManager に登録していることを示します。

greece-sup (enable) sh port 4/2
Port Name Status Vlan Duplex Speed Type
----- ------------------ ---------- ---------- ------ ----- ------------
4/2 enabled 1 full - MTP
Port DHCP MAC-Address IP-Address Subnet-Mask
-------- ------- ----------------- --------------- ---------------
4/2 disable 00-10-7b-00-0f-b1 10.200.72.32 255.255.255.0
Port Call-Manager(s) DHCP-Server TFTP-Server Gateway
-------- ----------------- --------------- --------------- ---------------
4/2 10.200.72.25 - 10.200.72.25 -
Port DNS-Server(s) Domain
-------- ----------------- -------------------------------------------------
4/2 - 0.0.0.0
Port CallManagerState DSP-Type
-------- ---------------- --------
4/2 registered C549
Port NoiseRegen NonLinearProcessing
----- ---------- -------------------
4/2 disabled disabled
 

第 2 に、Cisco CallManager Administration の Gateway Configuration 画面の Media Termination Point Required チェック ボックスが選択されているかどうかを確認します。

第 3 に、Cisco CallManager で必要な MTP デバイス数が割り当てられていることを確認します。

CCM ファイルから抜粋:

15:22:23.848 Cisco CallManager|MediaManager(40) started
15:22:23.848 Cisco CallManager|MediaManager - wait_AuConnectRequest
15:22:23.848 Cisco CallManager|MediaManager - wait_AuConnectRequest - Transcoder Enabled
15:22:23.848 Cisco CallManager|MediaManager - wait_AuConnectRequest - party1(16777357), party2(16777358), proxies=1, connections=2, current proxies=0
15:22:23.848 Cisco CallManager|MediaManager - wait_AuConnectRequest - proxy connections
15:22:23.848 Cisco CallManager|MediaManager - wait_AuConnectRequest - allocating MTP(ci=16777359)
15:22:23.848 Cisco CallManager|MediaManager - wait_AllocateMtpResourceRes
15:22:23.848 Cisco CallManager|MediaManager - wait_AllocateMtpResourceRes - start 2 connections
15:22:23.848 Cisco CallManager|MediaManager - wait_AllocateMtpResourceRes - creating connection between party1(16777357) and party2(16777359)
15:22:23.848 Cisco CallManager|MediaManager - wait_AllocateMtpResourceRes - creating connection between party1(16777358) and party2(16777359)
15:22:23.848 Cisco CallManager|MediaCoordinator - wait_MediaCoordinatorAddResource - CI=16777359 count=1
15:22:23.848 Cisco CallManager|MediaCoordinator - wait_MediaCoordinatorAddResource - CI=16777359 count=2
 

ダイヤル計画

ダイヤル計画とは、番号またはグループ番号から構成されているリストです。このリストは、特定の数字列を収集して、コールの送信先となるデバイス(電話、ゲートウェイなど)を Cisco CallManager に通知します。ダイヤル計画は、ルータのスタティック ルーティング テーブルに類似しています。必ず、ダイヤル計画の構想、基本的なコール ルーティング、およびプラニングが入念に検討されていること、また、構成も適切に行われていることを確認してから、ダイアル計画に問題があると思われる場合のトラブルシューティングを行ってください。実際、プラニングと構成に問題があることが多いのです。

ダイアル計画に関する問題をトラブルシューティングするときは、次の観点から考察してください。

コール発信元の DN(Directory Number;電話番号)は何番か。

この DN のコール検索スペースがあるか。

該当する場合、DN に関連付けられているデバイス(Cisco IP Phoneなど)のコール検索スペースがあるか。正確なデバイス、複数の回線特性がサポートされ、複数のデバイスに DN が設定できることを確認します。デバイスのコール検索スペースには注意します。コールの発信元が Cisco IP Phoneの場合、特定回線(DN)とその回線に関連付けられているデバイスにそれぞれ、コール検索スペースがあることを忘れないでください。コール検索スペースは、コールの発信時に結合されます。例として、回線インスタンス 1000 に AccessLevelX のコール検索スペースがあり、Cisco IP Phone(内線 1000 が設定された)にそのコール検索スペースとして AccessLevelY があるとします。その場合、その回線特性からコールが発信されると、Cisco CallManager ではコール検索スペースの AccessLevelX と AccessLevelY を含むパーティション全体を検索します。

コール検索スペースに関連付けられているパーティションがあるか。

コールが通過する(あるいはしない)デバイスのパーティションがあるか。

何番の電話番号がダイヤルされているか。発信者側でセカンダリ ダイヤル トーンが検出されるか、ダイヤルの進捗状況を注意深く観察します。すべての番号が入力された後、発信者に何か聞こえるか(リオーダー トーン、ファースト ビジー音)。何らかの応答がある前に、プログレス トーンがあるか。発信者は、最後の番号を入力した後、ディジット間タイマー切れになるまで、最低でも必ず 10 秒間待機してください。

Cisco CallManager Administration でルート計画レポートを生成します。そのレポートを使用して、コールに割り当てられているコール検索スペース内のパーティションに対してルート パターンをすべて調べます。

必要に応じて、ルート パターンやルート フィルタを追加または修正します。

コールの送信先にルート パターンが見つかる場合、パターン ポイントのルート リストまたはゲートウェイに注意します。

ルート リストについては、リストの一部であるルート グループ、およびルート グループの一部であるゲートウェイをチェックします。

アプリケーション デバイスが Cisco CallManager に登録されていることを確認します。

Cisco CallManager へのアクセス権がない場合、 show tech コマンドを使用してこの情報をキャプチャして確認します。

@ 記号に注意します。これは、多くの異なる事柄を含むために展開できるマクロです。多くの場合、フィルタリング オプションと併用されます。

デバイスがパーティションの一部ではない場合には、ヌルまたはデフォルトのパーティションの一部であると考えられます。あらゆるユーザはそのようなデバイスをコールできません。ヌル パーティションは必ず最後に検索されます。

9.@ パターンと一致し、10 秒経過してからコールが通過する外線電話番号にダイヤルする場合、フィルタリング オプションをチェックします。7 桁の番号にダイヤルする場合、9.@ パターンでは 10 秒待機します(デフォルト)。Route Filter を LOCAL-AREA-CODE DOES-NOT- EXIST および END-OF-DIALING DOES-NOT-EXIST と呼ばれるパターンに適用する必要があります。

パーティション

ルート パーティションは、Cisco CallManager ソフトウェアのエラー処理機能を継承します。つまり、コンソールと CCM ファイル トレースにより、ロギング情報とエラー メッセージが提供されます。それらのメッセージは、トレースのディジット分析コンポーネントの一部となります。次のトレースで示すように、パーティション、コール検索スペースの設定、各パーティションの一部となるデバイスに加え、パーティションに関連するコール検索スペースを把握することが、問題判別に重要となります。

次のトレースは、デバイスに割り当てられているコール検索スペース内のダイヤル番号の一例です。CallManager トレースの詳細については、このマニュアル事例を参照してください。

08:38:54.968 Cisco CallManager|StationInit - InboundStim - OffHookMessageID tcpHandle=0x6b88028
08:38:54.968 Cisco CallManager|StationD - stationOutputDisplayText tcpHandle=0x6b88028, Display= 5000
08:38:54.968 Cisco CallManager|StationD - stationOutputSetLamp stim: 9=Line instance=1 lampMode=LampOn tcpHandle=0x6b88028
08:38:54.968 Cisco CallManager|StationD - stationOutputCallState tcpHandle=0x6b88028
08:38:54.968 Cisco CallManager|StationD - stationOutputDisplayPromptStatus tcpHandle=0x6b88028
08:38:54.968 Cisco CallManager|StationD - stationOutputSelectSoftKeys tcpHandle=0x6b88028
08:38:54.968 Cisco CallManager|StationD - stationOutputActivateCallPlane tcpHandle=0x6b88028|
08:38:54.968 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="")
 

トレース(上述)のディジット分析コンポーネントでは、 pss (コール検索スペースとも呼ばれる、パーティション検索スペース)がコールを発信するデバイスにリストされます。次のトレースでは、 RTP_NC_Hardwood;RTP_NC_Woodland;Local_RTP が、このデバイスにコールを許可するパーティションであることが分かります。

08:38:54.968 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist
08:38:540.968 Cisco CallManager|StationD - stationOutputStartTone: 33=InsideDialTone tcpHandle=0x6b88028
08:38:55.671 Cisco CallManager|StationInit - InboundStim - KeypadButtonMessageID kpButton: 5 tcpHandle=0x6b88028
08:38:55.671 Cisco CallManager|StationD - stationOutputStopTone tcpHandle=0x6b88028
08:38:550.671 Cisco CallManager|StationD - stationOutputSelectSoftKeys tcpHandle=0x6b88028
08:38:550.671 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", pss=]RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="5")
08:38:550.671 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist
08:38:560.015 Cisco CallManager|StationInit - InboundStim - KeypadButtonMessageID kpButton: 0 tcpHandle=0x6b88028
08:38:560.015 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="50")
08:38:560.015 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist
08:38:560.187 Cisco CallManager|StationInit - InboundStim - KeypadButtonMessageID kpButton: 0 tcpHandle=0x6b88028
08:38:560.187 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="500")
08:38:560.187 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist
08:38:560.515 Cisco CallManager|StationInit - InboundStim - KeypadButtonMessageID kpButton: 3 tcpHandle=0x6b88028
08:38:560.515 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="5003")
08:38:560.515 Cisco CallManager|Digit analysis: analysis results
08:38:56.515 Cisco CallManager||PretransformCallingPartyNumber=5000
 

前述の例から、 PotentialMatchesExist が、完全一致が見つかり、それに従ってコールをルーティングするまでダイヤルされた番号のディジット分析の結果であることに注意することが重要です。

後述のトレースでは、ダイヤルした番号(1001)がデバイスのコール検索スペースにない場合を示します。この場合も、最初のディジットがダイヤルされる直前まで、ディジット分析ルーチンに可能性のある一致があったことに注意することが重要です。ディジット 1 に関連するルート パターンが、デバイスのコール検索スペース「RTP_NC_Hardwood;RTP_NC_Woodland;Local_RTP」にないパーティションにあります。したがって、その電話にはリオーダー トーン(reorder tone)が流れます。

08:38:580.734 Cisco CallManager|StationInit - InboundStim - OffHookMessageID tcpHandle=0x6b88028
08:38:580.734 Cisco CallManager|StationD - stationOutputDisplayText tcpHandle=0x6b88028, Display= 5000
08:38:580.734 Cisco CallManager|StationD - stationOutputSetLamp stim: 9=Line instance=1 lampMode=LampOn tcpHandle=0x6b88028
08:38:58.734 Cisco CallManager|StationD - stationOutputCallState tcpHandle=0x6b88028 08:38:58.734 Cisco CallManager|StationD - stationOutputDisplayPromptStatus tcpHandle=0x6b88028
08:38:580.734 Cisco CallManager|StationD - stationOutputSelectSoftKeys tcpHandle=0x6b88028
08:38:580.734 Cisco CallManager|StationD - stationOutputActivateCallPlane tcpHandle=0x6b88028|
08:38:580.734 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="")
08:38:580.734 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist
08:38:580.734 Cisco CallManager|StationD - stationOutputStartTone: 33=InsideDialTone tcpHandle=0x6b88028
08:38:590.703 Cisco CallManager|StationInit - InboundStim - KeypadButtonMessageID kpButton: 1 tcpHandle=0x6b88028
08:38:590.703 Cisco CallManager|StationD - stationOutputStopTone tcpHandle=0x6b88028
08:38:590.703 Cisco CallManager|StationD - stationOutputSelectSoftKeys tcpHandle=0x6b88028
08:38:590.703 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="1")
08:38:590.703 Cisco CallManager|Digit analysis: potentialMatches=NoPotentialMatchesExist
08:38:590.703 Cisco CallManager|StationD - stationOutputStartTone: 37=ReorderTone tcpHandle=0x6b88028
 

ルートのパーティションは、パーティション名をシステムの各電話番号に関連付けることによって機能します。電話番号を発信できるのは、発信が許可されているパーティションのリストにあるパーティション(そのパーティション検索スペース)が、発信するデバイスに含まれている場合に限ります。この方式は、ルーティングを強力に制御します。

コールが発信されると、ディジット分析では、パーティション検索スペースで指定されるアドレスのパーティションでダイヤルされたアドレスだけを解決します。各パーティション名は、ダイヤル可能なグローバル アドレス スペースの個々のサブセットで構成されます。ディジット分析では、リストされた各パーティションから、ダイヤルしたディジットの順番と最も一致するパターンを取得します。その後、一致しているパターンから、最も一致するパターンを選択します。2 つのパターンがダイヤルしたディジットの順番と同様に一致する場合、ディジット分析では、パーティション検索スペースで最初にリストされたパーティションに関連付けられたパターンを選択します(詳細については、最近接一致ルーティング(Closest-Match Routing)に関するマニュアルを参照)。

セキュリティ

Cisco CallManager では、ユーザがセキュリティ上安全なダイヤル計画を構築できるように、その構成が可能です。この構成は、パーティションおよびコールの検索スペースに加え、ルート パターンの @ マクロ(North American Numbering Plan を意味する)のセクションに基づいた非常に一般的なフィルタ(市外局番など)を使用して行います。パーティションおよびコールの検索スペースは、セキュリティに不可欠の機能であり、特にマルチテナント環境と各ユーザー レベルの作成に有効な機能です。フィルタリングとは、コール検索スペース/パーティション構想のサブセットです。このフィルタリングにより、セキュリティ計画はさらに緻密になります。

前述の説明のように、フィルタリングは、ダイヤル計画を拡張した機能となります。とはいえ、フィルタリング問題をトラブルシューティングするときに、CallManager トレースを実行することはお勧めできません。このトレースでは、得られる情報は不十分であり、副次的に引き起こされる障害も深刻になると想定されるからです。

Cisco CallManager で snow tech コマンドを実行します。 表 6-32 では、ルート フィルタのセッションに表示される情報を示します。

 

表 6-32 snow tech コマンドによるルート フィルタ セクションの出力

名前
dialPlanWizardG
文節

CiscoDallasInte

1

(INTERNATIONAL-

CiscoRTPTollByP

1

(AREA-CODE == 9

CiscoRTPLongDis

1

(AREA-CODE EXIS

CiscoDallasToll

1

(AREA-CODE == 9

CiscoDallas911R

1

(SERVICE == 911

CiscoRTPLocal7D

1

(AREA-CODE DOES

CiscoDallasLong

1

(AREA-CODE EXIS

CiscoRTP911RF

1

(SERVICE == 911

CiscoRTPInterna

1

(INTERNATIONAL-

CiscoDallasLoca

1

(LOCAL-AREA-COD

このフィルタ セクション表示は、その出力の一部です。しかし、ここに表示の出力には、すべてのルート フィルタのリストが表示されています。 snow コマンドでは、どのフィルタがどのルート パターンに関連付けられているかを確認することはできません。ダイヤル計画を十分に把握するには、別の方法として、Route Plan Report ウィンドウに移動する方法があります。図 6-51 は、右上部にあるオプション View In File の位置を示しています。 表 6-33 では、コンマで区切られた形式で出力されているファイルを Microsoft Excel または同様のアプリケーションで表示した例を示しています。

図 6-51 Route Plan Report ウィンドウ - View In File オプション

 

 

表 6-33 ルート計画レポート

パターン/DN
パーティション
パターンの使用状況
デバイス名
デバイスの説明

1000

 

Device

SEP003094C2635E

Telecaster

1010

 

Device

SEP003094C2635E

Telecaster

1111

 

Device

SEP00308062CDF1

SEP00308062CDF1

1211

 

Device

SEP00308062CDF1

SEP00308062CDF1

2999

 

Device

SAA0010EB007FFE

SAA0010EB007FFE

4444

 

Device

SEP003094C2635E

Guest

4500

 

Conference

9.@

CiscoRTPLocalPT

Route

CiscoRTPLocalRL

9.@

CiscoDallasLocalPT

Route

CiscoDallasLocalRL

9.@

CiscoRTPIntlPT

Route

CiscoRTPIntlRL

9.@

CiscoDallasLongDistPT

Route

CiscoDallasLongDistRL

9.@

CiscoRTP911PT

Route

CiscoRTP911RL

9.@

CiscoRTPLongDistPT

Route

CiscoRTPLongDistRL

9.@

CiscoTollByPassToDallasPT

Route

CiscoTollByPassToDallasRL

9.@

CiscoDallasIntlPT

Route

CiscoDallasIntlRL

9.@

CiscoDallas911PT

Route

CiscoDallas911RL

9.@

CiscoTollByPassToRTPPT

Route

CiscoTollByPassToRTPRL

表 6-33 の出力では、ルート パターンとそれに対応するパーティションを示します。この出力によって、電話番号のルート フィルタまたはコール検索スペースは示されません。詳細情報は、実際のルート計画レポートで入手できます。Cisco TAC に問い合わせる場合、このページを電子メールで送信してください(Cisco CallManager にアクセスできない場合)。

サーバ応答の低速化

サーバ応答が遅くなる場合、なんらかの問題が発生していると想定されます。次のような問題が考えられます。

デュプレックス ミスマッチ:スイッチのデュプレックスが Cisco CallManager のデュプレックスと一致しない場合、サーバからの応答が遅くなります。パフォーマンスを最適にするには、両方のスイッチとサーバを 100/Full に設定してください。いずれかのスイッチまたはサーバで Auto を使用することは推奨されません。変更内容を有効にするには、MCS サーバを再起動する必要があります。

スクリーン セーバー:一部のスクリーン セーバー(特にOpenGL スクリーン セーバー)は、アクティブ時に CPU すべてを消費します。シスコは、CallManager でスクリーン セーバーを無効にすることを推奨します。

サード パーティ製のソフトウェア :サード パーティ製のソフトウェアはサポートされていません。極力、使用しないようにお勧めします。Virus Scanners などのソフトウェアは、Cisco CallManager のリソースを浪費し、さらにその他の問題を引き起こします。CCO の Cisco CallManager Software Center の報告により、Cisco CallManager にインストールするソフトウェアは必ず 1 つだけにします。このページで入手可能なすべてのソフトウェアは検査済みで、シスコによってサポートされています。また、Windows 2000 のサービス パックおよび最新パッチは、必ずこのページからダウンロードします。CallManager の詳細については、
http://www.cisco.com/cgi-bin/tablebuild.pl/callmgr
を参照してください。

ゲートウェイを経由するリオーダー トーン

ユーザが制限されているコール、またはブロックされている番号を発信すると、ゲートウェイを経由するコール発信にリオーダー トーンが入ります。ダイヤル番号がサービス適用外の場合、または PSTN の機器またはサービスに問題のある場合、リオーダー トーン(reorder tone)が発せられることがあります。リオーダー トーンの原因となるデバイスが登録されていることを確認します。さらに、ダイヤル計画の構成をチェックして、コールを正常にルーティングできることを確認します。

ゲートウェイを経由するリオーダー トーンのトラブルシューティングを行うには、次のステップを実行します。

1. ゲートウェイをチェックして、最新のソフトウェア ロードを使用していることを確認します。

2. 最新のソフトウェア ロード、新しいパッチ、または問題に関連するリリース ノートについては、CCO( http://www.cisco.com/ にある Cisco Connection Online)をチェックしてください。

3. CallManager トレースを起動して、問題を再現します。Cisco CallManager で許可されるコール数が制限される場合、ロケーション ベースのアドミッション制御またはゲートキーパー ベースのアドミッション制御の設定に問題があると、リオーダー トーンが発生します。CallManager トレースで、発信場所を突き止め、その発信がルート パターンやコール検索スペース、またはその他の構成設定によって意図的にブロックされたかどうかを判断します。

4. また、発信が PSTN を経由する場合にも、リオーダー トーンが発生します。Q.931 接続解除メッセージについて、CallManager をチェックしてください。Q.931 接続解除メッセージがある場合、発信先によって接続解除され、その状態を修正できないことを示します。

ゲートウェイ登録の問題

Cisco CallManager のゲートウェイで発生する最も一般的な問題の 1 つは、登録の問題です。登録に失敗する場合は、さまざまな理由があります。

この項では、類似していても、本質的に異なる 2 つのゲートウェイのカテゴリについて説明します。Analog Access AS-X、AT-X、および Digital Access DT-24+ と DE-30 は、1 つのカテゴリに属しています。このカテゴリのゲートウェイは、ネットワーク管理プロセッサ(NMP)に直接接続しないスタンドアロン装置です。2 つ目のカテゴリには、Analog Access WS-X6624 と Digital Access WS-X6608 が含まれます。それらのゲートウェイは、Catalyst 6000 シャーシにインストールされるブレードで、NMP に直接接続して制御とステータス設定を行います。

後述の例で説明するメッセージは、ボールド体で表記されます。これにより、メッセージが確認しやすくなります。実際のディスプレイ出力では、テキストはボールド体ではありません。出力例は、WS-X6624 からの出力です。

まず、ゲートウェイを起動して、動作していることをチェックします。すべてのゲートウェイには、ゲートウェイ ソフトウェアが正常に動作しているときに 1 秒ごとに点滅する ハートビート LED があります。LED がまったく点滅しない、あるいは点滅の速度が非常に速い場合、ゲートウェイは動作していません。通常は、その結果、ゲートウェイが自動的にリセットされます。また、約 2、3 秒後に登録プロセスを完了できない場合にも、ゲートウェイは自動的にリセットするのが通常です。したがって、場合により、デバイスのリセット中にハートビート LED が観察されることがよくあります。10 ~ 15 秒の間に通常のパターンで点滅しない場合、ゲートウェイに重大な障害があります。AS-X ゲートウェイまたは AT-X ゲートウェイでは、前面パネルの一番右寄りにある緑の LED がハートビート LED です。DT-24+ゲートウェイまたは DE-30+ ゲートウェイでは、カード上部の一番左寄りにある赤の LED がハートビート LED です。Analog Access WS-X6624 では、前面近くの一番右寄りのカードの先端にあるブレード(フロント パネルからは見えない)の内側にある緑の LED がハートビート LED です。最後に、Digital Access WS-X6608 では、ブレード上の 8 つのスパンそれぞれにハートビート LED があります。背面方向に約 2/3 進んだところにあるカード全体に 8 つの赤の LED があります(前面パネルからは見えない)。

次に、ゲートウェイがその IP アドレスを受信していることをチェックします。スタンドアロン ゲートウェイでは、DHCP または BOOTP を経由してその IP アドレスを受信する必要があります。Catalyst ゲートウェイは、DHCP、BOOTP を経由して、またはNMP による手動設定によって、その IP アドレスを受信できます。DHCP サーバへのアクセス権がある場合、スタンドアロン ゲートウェイをチェックする最適な方法は、デバイスが IP アドレスの明確なリース権を取得していることを確認することです。サーバでゲートウェイを表示する場合、これが有用な表示になりますが、決定的なものではありません。DHCP サーバでリース権を削除してから、ゲートウェイをリセットします。数分以内にリース権を持つゲートウェイがサーバに再表示される場合、この領域は良好に機能しています。表示されない場合、ゲートウェイは DHCP サーバと通信できないか(ルータが間違って構成され、DHCP ブロードキャストに転送されていないか、あるいはサーバを実行しているかを確認)、肯定応答を受信できません(IP アドレス プールが削除されているかを確認)。前述の可能性をチェックしても、解決しない場合、勘によるスニッフィング トレースを使用して特定の問題を判別します。

Catalyst 6000 ゲートウェイの場合、NMP がそのゲートウェイと通信できることを確認する必要があります。これをチェックするには、NMP からその内部 IP アドレスを PING します。IP アドレスは、次の形式になります。

127.1.module.port

そこで、この例の場合、次のように PING を実行します。

Console (enable) ping 127.1.7.1
127.1.7.1 is alive
 

PING が機能した場合、「sh-port」コマンドを使用して IP アドレス情報を表示します。さらに、IP アドレス情報と TFTP IP アドレス情報が正確であることを確認します。ゲートウェイが有効な DHCP 情報の取得に失敗した場合、トレーシー ユーティリティ(Cisco TAC によってサポートされる)を使用して、問題を判別できます。Cat6000 CLI から次のようにコマンドを発行します。

tracy_start mod port

この例では、WS-X6624 はモジュール 7 です。また、単一 860 プロセッサしかないため、ポート 1 になります。次のようにコマンドを発行します。

tracy_start 7 1

次の出力は、ゲートウェイ ボード自体の 860 コンソール ポートから実際に出力されたものです。ただし、トレーシー コマンドの出力は、860 コンソール ポートのリモート コピーだけです。

| |
| |
| | | | | |
| | | | | | | | | |
| | | | | | |:.:| | | | | | |:..
C i s c o S y s t e m s
CAT6K Analog Gateway (ELVIS)
APP Version : A0020300, DSP Version : A0030300, Built Jun 1 2000 16:33:01
ELVIS>> 00:00:00.020 (XA) MAC Addr : 00-10-7B-00-13-DE
00:00:00.050 NMPTask:got message from XA Task
00:00:00.050 (NMP) Open TCP Connection ip:7f010101
00:00:00.050 NMPTask:Send Module Slot Info
00:00:00.060 NMPTask:get DIAGCMD
00:00:00.160 (DSP) Test Begin -> Mask<0x00FFFFFF>
00:00:01.260 (DSP) Test Complete -> Results<0x00FFFFFF/0x00FFFFFF>
00:00:01.260 NMPTask:get VLANCONFIG
00:00:02.870 (CFG) Starting DHCP
00:00:02.870 (CFG) Booting DHCP for dynamic configuration.
00:00:06.570 (CFG) DHCP Request or Discovery Sent, DHCPState = INIT_REBOOT
00:00:06.570 (CFG) DHCP Server Response Processed, DHCPState = INIT_REBOOT
00:00:06.780 (CFG) IP Configuration Change! Restarting now...
00:00:10.480 (CFG) DHCP Request or Discovery Sent, DHCPState = INIT
00:00:14:480 (CFG) DHCP Timeout Waiting on Server, DHCPState = INIT
00:00:22:480 (CFG) DHCP Timeout Waiting on Server, DHCPState = INIT
00:00:38:480 (CFG) DHCP Timeout Waiting on Server, DHCPState = INIT
 

前述のタイムアウト メッセージが連続してスクロールし続ける場合、DHCP サーバの通信に問題があります。Catalyst 6000 ゲートウェイのポートが正確な VLAN であることをチェックします。

この情報は、以前の show port コマンドにあります。DHCP サーバが Catalyst 6000 ゲートウェイと同じ VLAN にない場合、適切な IP ヘルパー アドレスが、DHCP 要求を DHCP サーバに転送するように設定されていることを確認します。ゲートウェイがリセットするまで、ゲートウェイを VLAN 番号変更後の INIT 状態にしておくことができます。この状態の場合、ゲートウェイをリセットできます。860 をリセットするたびに、トレーシー(tracy)セッションが消失します。したがって、既存のセッションを閉じて、次のコマンドを発行することで、新しいセッションを再度確立します。

tracy_close mod port

tracy_start mod port

このチェックをすべて行っても、DHCPState = INIT が表示されている場合には、DHCP サーバが正確に機能していることを確認するためにチェックします。正確に機能している場合、スニッフィング トレースを起動して、要求が送信され、サーバが応答していることを確認します。

DHCP が正確に機能すると、ゲートウェイには、トレーシー デバッグ ユーティリティを使用できる IP アドレスが設定されます。このユーティリティは、Catalyst ゲートウェイの NMP コマンド セットの組み込み機能です。これは、スタンドアロン ゲートウェイ用の Windows 98/NT/2000 で稼動するヘルパー アプリケーションとして有用です。ヘルパー アプリケーションのトレーシー ユーティリティを使用するには、割り当てられた IP アドレスを使用してゲートウェイに接続する必要があります。このトレーシー アプリケーションは、すべてのゲートウェイで機能します。これにより、ゲートウェイごとにトレース ウィンドウが表示され(1 回に 8 つのゲートウェイをトレース可能)、指定するファイルに直接トレースをログできます。

次のステップでは、TFTP サーバの IP アドレスが正確にゲートウェイに設定されたことを確認します。通常、この確認はオプション 66(名前別または IP アドレス別)、オプション 150(IP アドレスのみ)、またはsi_addr(IP アドレスのみ)を選択して DHCP によって行われます。サーバに複数のオプションがある場合、si_addr はオプション 150 よりも優先度が高く、オプション 150 はオプション 66 よりも優先度が高くなります。オプション 66 で TFTP サーバの DNS_NAME が提示される場合、DHCP で DNS サーバの IP アドレスを指定し、さらにオプション 66 で入力した名前を正確な TFTP サーバの IP アドレスにする必要があります。NMP では、DHCP を無効にするように Catalyst ゲートウェイを構成できます。さらに、NMP オペレーターは手作業でコンソールにすべての構成パラメータ(TFTP サーバのアドレスを含む)を入力する必要があります。

それに加え、ゲートウェイでは、DNS を使用して名前 CiscoCMI を常に解決を試みます。正常に解決すると、CiscoCMI の IP アドレスがあらゆるアドレスよりも優先度が高くなります。NMP で DHCP を無効にした場合でも、DHCP サーバまたは NMP によって、そのアドレスがTFTP サーバのアドレスとして通知されます。

tracy ユーティリティを使用することで、現在の TFTP サーバの IP アドレスをゲートウェイでチェックできます。次のコマンドを入力して、構成タスク番号を取得します。

TaskID: 0
Cmd: show tl
 

config または CFG を含む行を確認し、対応する番号を次の行の taskID に使用します。たとえば、Digital Access WS-X6624 ゲートウェイの場合、DHCP 情報をダンプするコマンドは次のようになります。

TaskID: 6
Cmd: show dhcp
 

その後、TFTP サーバの IP アドレスが明確に表示されます。そのアドレスが正しくない場合には、そのアドレスによって提供される DHCP オプションとその他の情報が正確であることを確認します。

TFTP アドレスを正確にしたら、次のステップでは、ゲートウェイでその構成ファイルを TFTP サーバから取得していることを確認します。トレーシー出力で次の内容が表示された場合、TFTP サーバが正常に機能していないか、ゲートウェイが Cisco CallManager に構成されていない可能性があります。

00:09:05.620 (CFG) Requesting SAA00107B0013DE.cnf File From TFTP Server
00:09:18.620 (CFG) TFTP
Error: Timeout Awaiting Server Response for .cnf File!
 

ゲートウェイで構成ファイルを受信していない場合、ゲートウェイでは TFTP サーバと同じ IP アドレスに接続します。冗長 Cisco CallManager のゲートウェイ リストをゲートウェイで受信する必要がありクラスタ化された環境でない限り、この接続は正常に確立されます。カードでその TFTP 情報を正確に受信していない場合には、Cisco CallManager で TFTP サービスをチェックし、そのサービスが実行されていることを確認します。さらに、Cisco CallManager で TFTP トレースもチェックします。

別の一般的な問題として、ゲートウェイが Cisco CallManager で正確に構成されていないことが挙げられます。典型的なエラーとなるのが、ゲートウェイの MAC アドレスの入力ミスです。その問題が MAC アドレスの入力ミスによる場合、NMP コンソールで次のメッセージがおそらく 2 分ごとに表示されます。

2000 Apr 14 19:24:08 %SYS-4-MODHPRESET:Host process (860) 7/1 got reset asynchronously
2000 Apr 14 19:26:05 %SYS-4-MODHPRESET:Host process (860) 7/1 got reset asynchronously
2000 Apr 14 19:28:02 %SYS-4-MODHPRESET:Host process (860) 7/1 got reset asynchronously
 

ゲートウェイが Cisco CallManager データベースにない場合、トレーシー出力は次のようになります。

00:00:01.670 (CFG) Booting DHCP for dynamic configuration.
00:00:050.370 (CFG) DHCP Request or Discovery Sent, DHCPState = INIT_REBOOT
00:00:05.370 (CFG) DHCP Server Response Processed, DHCPState = BOUND
00:00:05.370 (CFG) Requesting DNS Resolution of CiscoCM1
00:00:05.370 (CFG) DNS Error on Resolving TFTP Server Name.
00:00:05.370 (CFG) TFTP Server IP Set by DHCP Option 150 = 10.123.9.2
00:00:050.370 (CFG) Requesting SAA00107B0013DE.cnf File From TFTP Server
00:00:05.370 (CFG) TFTP Error: .cnf File Not Found!
00:00:05.370 (CFG) Requesting SAADefault.cnf File From TFTP Server
00:00:05.380 (CFG) .cnf File Received and Parsed Successfully.
00:00:05.380 (CFG) Updating Configuration ROM...
00:00:05.610 GMSG: GWEvent = CFG_DONE --> GWState = SrchActive
00:00:05.610 GMSG: CCM#0 CPEvent = CONNECT_REQ --> CPState = AttemptingSocket
00:00:05.610 GMSG: Attempting TCP socket with CCM 10.123.9.2
00:00:05.610 GMSG: CCM#0 CPEvent = SOCKET_ACK --> CPState = BackupCCM
00:00:05.610 GMSG: GWEvent = SOCKET_ACK --> GWState = RegActive
00:00:05.610 GMSG: CCM#0 CPEvent = REGISTER_REQ --> CPState = SentRegister
00:00:05.680 GMSG: CCM#0 CPEvent = CLOSED --> CPState = NoTCPSocket
00:00:05.680 GMSG: GWEvent = DISCONNECT --> GWState = Rollover
00:00:200.600 GMSG: GWEvent = TIMEOUT --> GWState = SrchActive
00:00:200.600 GMSG: CCM#0 CPEvent = CONNECT_REQ --> CPState = AttemptingSocket
00:00:200.600 GMSG: Attempting TCP socket with CCM 10.123.9.2
00:00:200.600 GMSG: CCM#0 CPEvent = SOCKET_ACK --> CPState = BackupCCM
 

ロード情報が正しくない、またはロード ファイルが損失した場合には、別の登録問題が考えられます。また、TFTP サーバが機能していない場合も、そのような問題が考えられます。この場合、TFTP サーバでファイルが見つからないことレポートされたことがトレーシーに明確に示されます。

00:00:070.390 GMSG: CCM#0 CPEvent = REGISTER_REQ --> CPState = SentRegister
00:00:080.010 GMSG: TFTP Request for application load A0021300
00:00:080.010 GMSG: CCM#0 CPEvent = LOADID --> CPState = AppLoadRequest
00:00:080.010 GMSG: ***TFTP Error: File Not Found***
00:00:080.010 GMSG: CCM#0 CPEvent = LOAD_UPDATE --> CPState = LoadResponse
 

この場合、正確なロード名が A0020300 であるのに対し、ゲートウェイがアプリケーション ロード A0021300 を要求していることが確認できます。Catalyst 6000 ゲートウェイの場合、それに対応する DSP ロードも取得するために新しいアプリケーション ロードが必要なときに、同様の問題が発生します。新しい DSP ロードが見つからない場合にも、同様のメッセージが表示されます。

次の内容は、間違ったアプリケーション ロードを取得するように、Analog Access WS-X6224 が構成されている場合の出力です。出力の内容は、ゲートウェイが Cisco CallManager で構成されていない場合の出力と類似しています。

| |
| |
| | | | | |
| | | | | | | | | |
| | | | | | |:.:| | | | | | |:..
C i s c o S y s t e m s
CAT6K Analog Gateway (ELVIS)
APP Version : A0020300, DSP Version : A0030300, Built Jun 1 2000 16:33:01
ELVIS>> 00:00:00.020 (XA) MAC Addr : 00-10-7B-00-13-DE
00:00:00.050 NMPTask:got message from XA Task
00:00:00.050 (NMP) Open TCP Connection ip:7f010101
00:00:00.050 NMPTask:Send Module Slot Info
00:00:00.060 NMPTask:get DIAGCMD
00:00:00.160 (DSP) Test Begin -> Mask<0x00FFFFFF>
00:00:01.260 (DSP) Test Complete -> Results<0x00FFFFFF/0x00FFFFFF>
00:00:01.260 NMPTask:get VLANCONFIG
00:00:020.030 (CFG) Starting DHCP
00:00:020.030 (CFG) Booting DHCP for dynamic configuration.
00:00:050.730 (CFG) DHCP Request or Discovery Sent, DHCPState = INIT_REBOOT
00:00:050.730 (CFG) DHCP Server Response Processed, DHCPState = BOUND
00:00:050.730 (CFG) Requesting DNS Resolution of CiscoCM1
00:00:050.730 (CFG) DNS Error on Resolving TFTP Server Name.
00:00:050.730 (CFG) TFTP Server IP Set by DHCP Option 150 = 10.123.9.2
00:00:050.730 (CFG) Requesting SAA00107B0013DE.cnf File From TFTP Server
00:00:050.730 (CFG) .cnf File Received and Parsed Successfully.
00:00:050.730 GMSG: GWEvent = CFG_DONE --> GWState = SrchActive
00:00:050.730 GMSG: CCM#0 CPEvent = CONNECT_REQ --> CPState = AttemptingSocket
00:00:050.730 GMSG: Attempting TCP socket with CCM 10.123.9.2
00:00:050.730 GMSG: CCM#0 CPEvent = SOCKET_ACK --> CPState = BackupCCM
00:00:050.730 GMSG: GWEvent = SOCKET_ACK --> GWState = RegActive
00:00:050.730 GMSG: CCM#0 CPEvent = REGISTER_REQ --> CPState = SentRegister
00:00:06.320 GMSG: CCM#0 CPEvent = LOADID --> CPState = LoadResponse
00:01:360.300 GMSG: CCM#0 CPEvent = TIMEOUT --> CPState = BadCCM
00:01:360.300 GMSG: GWEvent = DISCONNECT --> GWState = Rollover
00:01:460.870 GMSG: CCM#0 CPEvent = CLOSED --> CPState = NoTCPSocket
00:01:510.300 GMSG: GWEvent = TIMEOUT --> GWState = SrchActive
00:01:510.300 GMSG: CCM#0 CPEvent = CONNECT_REQ --> CPState = AttemptingSocket
00:01:510.300 GMSG: Attempting TCP socket with CCM 10.123.9.2
00:01:510.300 GMSG: CCM#0 CPEvent = SOCKET_ACK --> CPState = BackupCCM
00:01:510.300 GMSG: GWEvent = SOCKET_ACK --> GWState = RegActive
00:01:510.300 GMSG: CCM#0 CPEvent = REGISTER_REQ --> CPState = SentRegister
00:01:510.890 GMSG: CCM#0 CPEvent = LOADID --> CPState = LoadResponse
 

ここで異なる点は、ゲートウェイが LoadResponse ステージに入ったまま、タイムアウトになってしまうことです。この問題は、Cisco CallManager Administration の Device Defaults 領域でロード ファイル名を修正することで解決できます。

MRP/ASI のトラブルシューティング

ICS 7750 用の Multiservice Route Processor/ATM Service Interface(MRP/ASI)システム カードは、Cisco ハードウェアと Cisco IOS ソフトウェアを稼動するマルチ サービス ルータ/音声ゲートウェイ カードです。このシステム カードでは、デジタルおよびアナログの音声トランクゲートウェイと WAN インターフェイスをサポートしています。

ブート シーケンスおよびゲートウェイの登録問題のトラブルシューティングについては、『Cisco ICS 7750 Administration and Troubleshooting Guide』の「 T roubleshooting ICS 7750 Booting Problems 」の項を参照してください。

ゲートキーパー登録の問題

ゲートウェイとゲートキーパー間のトラブルシューティングを開始する前に、ネットワーク内に IP 接続性があることを確認してください。IP 接続性があることを前提として、この項の情報を利用してゲートウェイのトラブルシューティングを行います。

クラスタ間のトランクのみ

Cisco CallManager リリース 3.0(1) またはそれ以降のバージョンでゲートキーパー制御が有効なのは、クラスタ間のトランクだけなので注意してください。ゲートキーパーはその他のデバイスに構成可能ですが、その構成がサポートされていません。

アドミッション拒否

アドミッション拒否(ARJ;Admission Reject)が発行されるのは、Cisco CallManager がゲートキーパーに登録されていても、電話コールを送信できない場合です。ゲートキーパーが ARJ を発行した場合、特にゲートキーパーの構成問題に重点を置きます。また、トラブルシューティングの一般的なガイドラインは次のとおりです。

1. ゲートウェイからゲートキーパーまでの IP 接続性を確認します。

2. ゲートキーパーのステータスを表示して、ゲートキーパーの状態がアップになっていることを確認します。

3. ゲートキーパーに定義されたゾーン サブネットがあることを確認します。そのサブネットがあった場合、ゲートウェイのサブネットが、許可されたサブネットにあることを確認します。

登録拒否

登録拒否(RRJ;Registration Reject)が発行されるのは、Cisco CallManager がゲートキーパーに登録できない場合です ゲートキーパーが RRJ を発行した場合、特にゲートキーパーの構成問題に重点を置きます。

また、トラブルシューティングの一般的なガイドラインは次のとおりです。

1. ゲートウェイからゲートキーパーまでの IP 接続性を確認します。

2. ゲートキーパーのステータスを表示して、ゲートキーパーの状態がアップになっていることを確認します。

3. ゲートキーパーに定義されたゾーン サブネットがあることを確認します。そのサブネットがあった場合、ゲートウェイのサブネットが、許可されたサブネットにあることを確認します。

Cisco IP Phoneの初期化プロセス

Cisco IP Phoneの初期化(またはブート アップ)プロセスの詳細は、次のとおりです。

1. 初期化では、適切な場合、Cisco IP Phoneが要求を DHCP サーバに送信して、IP アドレス、DNS サーバのアドレス、および TFTP サーバ名やアドレスを取得します。オプションが DHCP サーバに設定されます(オプション 066、オプション 150 など)また、DHCP サーバに設定した場合(オプション 003)、デフォルトのゲートウェイ アドレスも取得します。

2. DHCP によって、TFTP サーバの DNS 名が送信される場合、その名前を IP アドレスにマッピングするために、DNS サーバの IP アドレスが要求されます。DHCP サーバによって TFTP サーバの IP アドレスが送信される場合には、このステップは省略されます。この事例では、DNS が構成されていないために、DHCP サーバによって TFTP の IP アドレスが送信されます。

3. DHCP 応答に TFTP サーバ名が含まれていない場合、Cisco IP Phoneではデフォルトのサーバ名を使用します。

4. 構成ファイル(.cnf ファイル)が TFTP サーバから取得されます。すべての .cnf ファイルには、SEP<mac_address.cnf> という名前があります。「SEP」とは Selsius Ethernet Phone の略語です。その電話を初めて Cisco CallManager に登録する場合、デフォルト ファイル(SEPdefault.cnf)が Cisco IP Phoneにダウンロードされます。この事例では、最初の Cisco IP Phoneで IP アドレス 172.16.70.230(その MAC アドレスは SEP0010EB001720)を使用し、2 番目の IP Phoneで IP アドレス 172.16.70.231(その MAC アドレスは SEP003094C26105)を使用します。

5. すべての .cnf ファイルには、CallManager デバイスの CallManager グループに定義された CallManager の IP アドレスが含まれます。

6. Cisco IP Phoneが Cisco CallManager に接続および登録されると、Cisco CallManager では、実行する実行可能ファイルのバージョン(ロード IDと呼ばれる)を Cisco IP Phoneに通知します。指定したバージョンが、Cisco IP Phoneで実行中のバージョンと一致しない場合、Cisco IP Phoneでは新しい実行可能ファイルを TFTP サーバから要求して、自動的にリセットします。

Skinny Station の登録プロセス

Cisco IP Phoneは、Cisco Skinny Station Protocol を使用して Cisco CallManager と通信します。登録プロセスを使用して、Skinny Station(Cisco IP Phoneなど)ではその所在とコール発信可能であることを Cisco CallManager に通知します。図 6-52 では、Cisco IP Phone(ステーション)と Cisco CallManager 間で交換される各種メッセージを示します。Skinny Station の登録プロセスの主なメッセージは、 表 6-34 で説明します。

図 6-52 Skinny Station Protocol のメッセージ交換例

 

 

表 6-34 Skinny Station の登録プロセスの説明

メッセージ
説明

Station Register

ステーションは、その所在を知らせるためにこのメッセージを制御の Cisco CallManager に送信します。

Station Reset

Cisco CallManager は、このメッセージをステーションのコマンドに送信して、そのプロセスをリセットします。

Station IP Port

ステーションは、このメッセージを送信して RTP ストリームと併用するユーザ データグラム プロトコル(UDP)ポートを Cisco CallManager に提供します。

Station Register Acknowledge

Cisco CallManager は、このメッセージを送信してステーションの登録を確認応答します。

Station Register Reject

Cisco CallManager は、このメッセージを送信して、指定された電話からの登録を拒否します。

char text[StationMaxDisplayTextSize];
};
 

ここで :

text は、文字列(最大の長さ 33 バイト)です。ここには、登録拒否の理由のテキスト説明が入力されます。

Station Capabilities Request

Cisco CallManager は、このメッセージを送信して現在のステーション機能を要求します。ステーション機能には、圧縮規格とその他の H.323 機能が含まれます。

Station Version Request

ステーションは、このメッセージを送信して、ステーションのソフトウェア ロードのバージョン番号を要求します。

Station Version Response

Cisco CallManager は、このメッセージを送信して、適切なソフトウェア バージョン番号をステーションに通知します。

Station Capabilities Response

ステーションは、Station Capabilities Request に応答して、このメッセージを Cisco CallManager に送信します。ステーション機能は、Cisco CallManager にキャッシュされ、H.323 準拠の端末と端末機能との折衝に使用されます。

Station Button Template Request

ステーションは、このメッセージを送信して、ステーション特定の端末または Cisco IP Phoneのボタン テンプレート定義を要求します。

Station Button Template Response

Cisco CallManager は、このメッセージを送信して、ステーションに含まれるボタン テンプレート情報を更新します。

Station Time Date Request

ステーションは、このメッセージを送信して、内部使用またはテキスト文字列として表示するために、現在の日時を要求します。

Station Define Time and Date

Cisco CallManager は、このメッセージを送信して、日時情報をステーションに提供します。これにより、ステーションの時間が同期化されます。

Cisco CallManager の初期化プロセス

この項では、CCM1(IP アドレス172.16.70.228 で識別される)からキャプチャされるトレースを使用して、Cisco CallManager の初期化プロセスについて説明します。前に説明したように、エンドポイント間に送信されるあらゆるパケットの詳細がトレースに明記されるため、CallManager トレースは非常に効果的なトラブルシューティング ツールとなります。この項では、Cisco CallManager の初期化時に発生するイベントについて説明します。トレースの読み方を理解すると、さまざまな Cisco CallManager プロセスのトラブルシューティングを正しく行うことができ、電話会議、コール転送などのサービスにおいて Cisco CallManager プロセスの効果を発揮できます。

Cisco CallManager の CCM トレース ユーティリティによる次のメッセージに、1 つの Cisco CallManager(この場合は CCM1)の初期化プロセスが示されます。以降の各メッセージの説明を確認してください。

最初のメッセージは、Cisco CallManager で初期化プロセスが開始されたことを示します。

2 番目のメッセージは、Cisco CallManage でデフォルトのデータベース値を読み取ることを示します(この場合、プライマリ データベースまたはパブリッシャ データベース)。

3 番目のメッセージは、CallManager がクラスタにあるその他の CallManager に対して TCP ポート 8002 を確立し、そのサーバと通信することを示します。

4 番目のメッセージは、これまでのメッセージを受信した後に、Cisco CallManager で 2 つ目の Cisco CallManager つまり、CCM 2(172.16.70.229)がそのリストに追加されることを示します。

5 番目のメッセージは、Cisco CallManager が起動し、Cisco CallManager バージョン 3.0.20 を実行していることを示します。

16:02:47.765 CCM|CMProcMon - CallManagerState Changed - Initialization Started.
16:02:47.796 CCM|NodeId: 0, EventId: 107 EventClass: 3 EventInfo: Cisco CM Database Defaults Read
16:02:49.937 CCM| SDL Info - NodeId: [1], Listen IP/Hostname: [172.16.70.228], Listen Port: [8002]
16:02:49.984 CCM|dBProcs - Adding SdlLink to NodeId: [2], IP/Hostname: [172.16.70.229]
16:02:510.031 CCM|NodeId: 1, EventId: 1 EventClass: 3 EventInfo: Cisco CallManager Version=<3.0(0.20)> started
 

自己起動プロセス

Cisco CallManager が起動および稼動すると、その内部で他にも複数のプロセスを起動します。その一部のプロセス(MulticastPoint Manager、UnicastBridge Manager、ディジット分析)を次に示します。これらのプロセス時に表示されるメッセージは、Cisco CallManager の機能に関連する問題のトラブルシューティングを行うときに非常に役立ちます。

たとえば、ルート リストが機能せず、使用できないと仮定します。この問題のトラブルシューティングを行うには、それらのトレースを監視し、Cisco CallManager がRoutePlanManager を起動したかどうか、さらにルート リストをロードするかどうかを判別します。次のサンプル構成では、RouteListName=''ipwan'' および RouteGroupName=''ipwan'' がロードおよび起動しています。

16:02:51.031 CCM|MulicastPointManager - Started
16:02:51.031 CCM|UnicastBridgeManager - Started
16:02:51.031 CCM|MediaTerminationPointManager - Started
16:02:51.125 CCM|MediaCoordinator(1) - started
16:02:510.125 CCM|NodeId: 1, EventId: 1543 EventClass: 2 EventInfo: Database manager started
16:02:510.234 CCM|NodeId: 1, EventId: 1542 EventClass: 2 EventInfo: Link manager started
16:02:510.390 CCM|NodeId: 1, EventId: 1541 EventClass: 2 EventInfo: Digit analysis started
16:02:51.406 CCM|RoutePlanManager - Started, loading RouteLists
16:02:51.562 CCM|RoutePlanManager - finished loading RouteLists
16:02:51.671 CCM|RoutePlanManager - finished loading RouteGroups
16:02:51.671 CCM|RoutePlanManager - Displaying Resulting RoutePlan
16:02:51.671 CCM|RoutePlanServer - RouteList Info, by RouteList and RouteGroup Selection Order
16:02:51.671 CCM|RouteList - RouteListName=''ipwan''
16:02:51.671 CCM|RouteList - RouteGroupName=''ipwan''
16:02:51.671 CCM|RoutePlanServer - RouteGroup Info, by RouteGroup and Device Selection Order
16:02:51.671 CCM|RouteGroup - RouteGroupName=''ipwan''
 

次のトレースは、デバイス 172.16.70.245 を追加する RouteGroup を示します。このデバイスは、別のクラスタに配置される CallManager で、H.323 デバイスと見なされます。この場合、RouteGroup は、Cisco IOS ゲートキーパーの許可を持つ 172.16.70.245 のコールをルーティングするために作成されます。別のクラスタに配置された Cisco IP Phoneのコールをルーティングする問題が発生した場合、次のメッセージが問題の原因を特定するのに役立ちます。

16:02:51.671 CCM|RouteGroup - DeviceName=''172.16.70.245''
16:02:51.671 CCM|RouteGroup -AllPorts
 

一部の初期化プロセスは、Cisco CallManager で DN を追加していることを示します。これらのメッセージを確認することで、Cisco CallManager でデータベースからルート パターンを読み取ったかどうかを判断できます。

16:02:510.671 CCM|NodeId: 1, EventId: 1540 EventClass: 2 EventInfo: Call control started
16:02:51.843 CCM|ProcessDb - Dn = 2XXX, Line = 0, Display = , RouteThisPattern, NetworkLocation = OffNet, DigitDiscardingInstruction = 1, WhereClause =
16:02:51.859 CCM|Digit analysis: Add local pattern 2XXX , PID: 1,80,1
16:02:51.859 CCM|ForwardManager - Started
16:02:51.984 CCM|CallParkManager - Started
16:02:52.046 CCM|ConferenceManager - Started
 

次のトレースでは、Cisco CallManager の DeviceManager で静的に 2 つのデバイスを初期化しています。IP アドレス 172.17.70.226 のデバイスはゲートキーパーで、IP アドレス 172.17.70.224 のデバイスは別のクラスタにある もう 1 つの Cisco CallManager です。もう 1 つの Cisco CallManager は、H.323 ゲートウェイとしてこの Cisco CallManager に登録されます。

16:02:52.250 CCM|DeviceManager: Statically Initializing Device; DeviceName=172.16.70.226
16:02:52.250 CCM|DeviceManager: Statically Initializing Device; DeviceName=172.16.70.245
 

Cisco CallManager の登録プロセス

CallManager トレースのもう 1 つ重要となる部分が、登録プロセスです。デバイスの電源を投入すると、デバイスは DHCP を使用して情報を取得し、その .cnf ファイルの TFTP サーバに接続してから、その .cnf ファイルで指定された Cisco CallManager に接続します。デバイスは、MCGP ゲートウェイ、Skinny ゲートウェイ、または Cisco IP Phoneになります。したがって、Cisco IP テレフォニー ネットワークで、デバイスが正常に登録されているかどうかを検出できることが重要になります。

次のトレースでは、Cisco CallManager が登録するために新しい接続を受信しています。登録するデバイスは、 MTP_nsa-cm1 (CCM1 の MTP サービス)と CFB_nsa-cm1 (CCM1 の会議ブリッジ サービス)です。Cisco CallManager で稼動しているソフトウェア サービスがありますが、それらのサービスは別の外部サービスとして内部で処理されるため、デバイス名だけでなく、tcpHandle、ソケット番号、およびポート番号も割り当てられます。

16:02:52.750 CCM|StationInit - New connection accepted. DeviceName=, TCPHandle=0x4fbaa00, Socket=0x594, IPAddr=172.16.70.228, Port=3279, StationD=[0,0,0]
16:02:52.750 CCM|StationInit - New connection accepted. DeviceName=, TCPHandle=0x4fe05e8, Socket=0x59c, IPAddr=172.16.70.228, Port=3280, StationD=[0,0,0]
16:02:52.781 CCM|StationInit - Processing StationReg. regCount: 1 DeviceName=MTP_nsa-cm1, TCPHandle=0x4fbaa00, Socket=0x594, IPAddr=172.16.70.228, Port=3279, StationD=[1,45,2]
16:02:52.781 CCM|StationInit - Processing StationReg. regCount: 1 DeviceName=CFB_nsa-cm1, TCPHandle=0x4fe05e8, Socket=0x59c, IPAddr=172.16.70.228, Port=3280, StationD=[1,96,2]
 

次のトレースでは、Skinny Station メッセージが Cisco IP Phoneと Cisco CallManager 間に送信されます。Cisco IP Phone(172.16.70.231)は、Cisco CallManager に登録しています。詳細については、この項の前半で説明した Skinny Station メッセージを参照してください。Cisco CallManager では、Cisco IP Phoneからの登録要求を受信した直後に、TCPHandle 番号をこのデバイスに割り当てます。この番号は、デバイスまたは Cisco CallManager を再起動するまで変わりません。よって、デバイスの TCPHandle 番号(16 進法で表される)を検索または追跡することによって、特定のデバイスに関連するすべてのイベントを監視できます。さらに、Cisco CallManager によって、ロード ID が Cisco IP Phoneに与えられるので注意してください。このロード ID に基づいて、Cisco IP Phoneではそのデバイスに対応する実行可能ファイル(TFTP サーバから取得)を実行します。

16:02:570.000 CCM|StationInit - New connection accepted. DeviceName=, TCPHandle=0x4fbbc30, Socket=0x5a4, IPAddr=172.16.70.231, Port=52095, StationD=[0,0,0]
16:02:570.046 CCM|NodeId: 1, EventId: 1703 EventClass: 2 EventInfo: Station Alarm, TCP Handle: 4fbbc30, Text: Name=SEP003094C26105 Load=AJ.30 Parms=Status/IPaddr LastTime=A P1: 2304(900) P2: -414838612(e74610ac)
16:02:57.046 CCM|StationInit - ***** InboundStim - AlarmMessageID tcpHandle=0x4fbbc30 Message="Name=SEP003094C26105 Load=AJ.30 Parms=Status/IPaddr LastTime=A" Parm1=2304 (900) Parm2=-414838612 (e74610ac)
16:02:570.093 CCM|StationInit - Processing StationReg. regCount: 1 DeviceName=SEP003094C26105, TCPHandle=0x4fbbc30, Socket=0x5a4, IPAddr=172.16.70.231, Port=52095, StationD=[1,85,1]
16:02:57.093 CCM|StationInit - InboundStim - IpPortMessageID: 32715(0x7fcb) tcpHandle=0x4fbbc30
 

Cisco CallManager のキープアライブ プロセス

ステーション、デバイス、またはサービスと Cisco CallManager では、次のメッセージを使用して相互の通信間チャネルの知識を保持します。また、次のメッセージを使用して、Cisco CallManager とステーション間の通信リンクを確実に通信状態にするキープアライブ シーケンスを開始します。次のメッセージは、Cisco CallManager またはステーションから発信することができます。

16:03:02.328 CCM|StationInit - InboundStim - KeepAliveMessage - Forward KeepAlive to StationD. DeviceName=MTP_nsa-cm2, TCPHandle=0x4fa7dc0, Socket=0x568, IPAddr=172.16.70.229, Port=1556, StationD=[1,45,1]
16:03:02.328 CCM|StationInit - InboundStim - KeepAliveMessage - Forward KeepAlive to StationD. DeviceName=CFB_nsa-cm2, TCPHandle=0x4bf8a70, Socket=0x57c, IPAddr=172.16.70.229, Port=1557, StationD=[1,96,1]
16:03:060.640 CCM|StationInit - InboundStim - KeepAliveMessage - Forward KeepAlive to StationD. DeviceName=SEP0010EB001720, TCPHandle=0x4fbb150, Socket=0x600, IPAddr=172.16.70.230, Port=49211, StationD=[1,85,2]
16:03:06.703 CCM|StationInit - InboundStim - KeepAliveMessage - Forward KeepAlive to StationD. DeviceName=SEP003094C26105, TCPHandle=0x4fbbc30, Socket=0x5a4, IPAddr=172.16.70.231, Port=52095, StationD=[1,85,1]
 

次のトレースのメッセージは、キープアライブ シーケンスを表しています。キープアライブ シーケンスとは、Cisco CallManager とステーション間の通信リンクが通信中であることを示します。次のメッセージも、Cisco CallManager またはステーションから発信することができます。

16:03:02.328 CCM|MediaTerminationPointControl - stationOutputKeepAliveAck tcpHandle=4fa7dc0
16:03:02.328 CCM|UnicastBridgeControl - stationOutputKeepAliveAck tcpHandle=4bf8a70
16:03:060.703 CCM|StationInit - InboundStim - IpPortMessageID: 32715(0x7fcb) tcpHandle=0x4fbbc30
16:03:06.703 CCM|StationD - stationOutputKeepAliveAck tcpHandle=0x4fbbc30
 

この項では、Cisco IP Phone(話番号 1000)による同じクラスタ内の別の Cisco IP Phone(電話番号 1001)への発信について説明します。クラスタとは、Cisco CallManager のグループです。クラスタには、1 つのサーバ(パブリッシャの SQL データベース)とサブスクライバの SQL データベースを組み込む 1 つ以上のサーバがあります。中央集中型の処理モデルでは、すべての電話を 1 つの CallManager に登録する必要があります。

シスコのサンプル トポロジーでは、CCM1 がパブリッシャで、CCM2 がサブスクライバです。2 つの Cisco IP Phone(1000 と 1001)は、CCM2 に登録されます。コール フローは、図 6-53 に示されています。Cisco IP Phoneがオフフックの場合、その電話では初期化時に確立した TCP ハンドルを経由して CallManager への Skinny Station メッセージを開始します。コール制御シグナリングを 2 つのCisco IP Phoneと Cisco CallManager 間に確立した後、図 6-53 に示すように、2 つの電話間に RTP ストリームのフローが開始します。このクラスタ間コールの Skinny Station コール フローのメッセージについては、次の項で説明します。

図 6-53 同一クラスタ内でのコール フローの例

 

コール フロー時における Cisco IP Phoneと Cisco IP Phone間の Skinny Station メッセージの交換

図 6-54 では、2 つの Skinny Station 間のメッセージ交換の例を示します。Skinny Station(つまり、Cisco IP Phone)では、Cisco CallManager との接続を開始します。その後、CiscoCallManager ではディジット分析を実行してから、発信先の Skinny Station との制御セッションをオープンします。次の図で示すように、Skinny Station メッセージは簡単な英語で書かれているため、エンドユーザは容易に理解できます。そのため、この項では、これらのメッセージについて説明しません。ただし、それらのコール フローの Skinny Station メッセージについては、後の項でトレースを調べるときに詳しく説明します。

図 6-54 Skinny Station 間のメッセージ交換の例

 

Cisco CallManager クラスタ間のコール フローのトレース

次の CallManager トレースでは、クラスタ内のコール フローについて詳しく調べていきます。コール フローの Cisco IP Phoneは、DN、tcpHandle、および IP アドレスによって識別できます。Cisco IP Phone(DN=1001、tcpHandle=0x4fbbc30、IP アドレス=172.16.70.231)は、同一クラスタ内にある別の Cisco IP Phone(DN=1000、tcpHandle=0x4fbb150、IP アドレス=172.16.70.230)に発信しています。TCP ハンドル値、タイムスタンプ、またはデバイス名を調べることで、デバイスを監視できることを念頭に置いてください。デバイスをリブートするか、オフラインにするまで、デバイスのハンドル値は変わりません。

次のトレースは、Cisco IP Phone(1001)がオフフックになっていることを示します。また、固有のメッセージ、TCP ハンドル、および DN も示します。このトレースは Cisco IP Phoneに表示されます。ユーザはどのディジットもダイヤルしていないため、この時点では着番号がありません。次の情報は、Cisco IP Phoneと Cisco CallManager 間の Skinny Station メッセージの形式になります。

16:05:41.625 CCM|StationInit - InboundStim - OffHookMessageID tcpHandle=0x4fbbc30
16:05:41.625 CCM|StationD - stationOutputDisplayText tcpHandle=0x4fbbc30, Display= 1001\
 

次のトレースは、Skinny Station メッセージが Cisco CallManager から Cisco IP Phoneに送信されることを示します。最初のメッセージは、発信側の Cisco IP Phoneのランプをオンにします。

16:05:41.625 CCM|StationD - stationOutputSetLamp stim: 9=Line instance=1 lampMode=LampOn tcpHandle=0x4fbbc30
 

stationOutputCallState メッセージは、一定のコール関連情報をステーションに通知するために、Cisco CallManager によって使用されます。

16:05:41.625 CCM|StationD - stationOutputCallState tcpHandle=0x4fbbc30
 

stationOutputDisplayPromptStatus メッセージは、コール関連のプロンプト メッセージを Cisco IP Phoneに表示するために、Cisco CallManager によって使用されます。

16:05:41.625 CCM|StationD - stationOutputDisplayPromptStatus tcpHandle=0x4fbbc30
 

stationOutputSelectSoftKey メッセージは、電話に表示する特定のソフト キーのセットを Skinny Station で選択するために、Cisco CallManager によって使用されます。

16:05:41.625 CCM|StationD - stationOutputSelectSoftKeys tcpHandle=0x4fbbc30
 

次のメッセージは、表示用の正確な回線コンテキストについて Skinny Station に指示するために、Cisco CallManager によって使用されます。

16:05:41.625 CCM|StationD - stationOutputActivateCallPlane tcpHandle=0x4fbbc30
 

次のメッセージでは、ディジット分析プロセスが着信ディジットを識別し、考えられるルーティングの一致についてそれらのディジットをチェックする準備が整っていることろ示します。エントリ cn=1001 は、発信側の番号を表します。 dd=îî は、ダイヤルされたディジットを表します。これは着信側の番号です。StationInit メッセージは電話によって送信され、Station ID メッセージは Cisco CallManager によって送信され、ディジット分析は Cisco CallManager によって実行されるので注意してください。

16:05:410.625 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="")
16:05:410.625 CCM|Digit analysis: potentialMatches=PotentialMatchesExist
 

次のデバッグ メッセージは、Cisco CallManager が発信側の Cisco IP Phoneに内部ダイヤル トーンを鳴らしていることを示します。

16:05:41.625 CCM|StationD - stationOutputStartTone: 33=InsideDialTone tcpHandle=0x4fbbc30
 

Cisco CallManager では、着信メッセージを検出し、Cisco IP Phoneでキーパッド ボタン 1 が押されたことを認識すると、すぐに出力トーンを停止します。

16:05:42.890 CCM|StationInit - InboundStim - KeypadButtonMessageID kpButton: 1 tcpHandle=0x4fbbc30
16:05:45.140 CCM|StationInit - Offhook
16:05:42.890 CCM|StationD - stationOutputStopTone tcpHandle=0x4fbbc30
16:05:420.890 CCM|StationD - stationOutputSelectSoftKeys tcpHandle=0x4fbbc30
16:05:420.890 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="1")
16:05:42.890 CCM|Digit analysis: potentialMatches=PotentialMatchesExist
16:05:430.203 CCM|StationInit - InboundStim - KeypadButtonMessageID kpButton: 0 tcpHandle=0x4fbbc30
16:05:430.203 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="10")
16:05:430.203 CCM|Digit analysis: potentialMatches=PotentialMatchesExist
16:05:430.406 CCM|StationInit - InboundStim - KeypadButtonMessageID kpButton: 0 tcpHandle=0x4fbbc30
16:05:430.406 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="100")
16:05:430.406 CCM|Digit analysis: potentialMatches=PotentialMatchesExist|
16:05:430.562 CCM|StationInit - InboundStim - KeypadButtonMessageID kpButton: 0 tcpHandle=0x4fbbc30
16:05:430.562 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="1000")
 

Cisco CallManager は、一致に十分なディジットを受信すると、ディジット分析の結果をテーブル形式で表示します。一致がすでに見つかっているため、Cisco CallManager では、その時点以後に電話で発信された余分なディジットをすべて無視します。

16:05:430.562 CCM|Digit analysis: analysis results
16:05:43.562 CCM||PretransformCallingPartyNumber=1001
|CallingPartyNumber=1001
|DialingPattern=1000
|DialingRoutePatternRegularExpression=(1000)
|PotentialMatches=PotentialMatchesExist
|DialingSdlProcessId=(1,38,2)
|PretransformDigitString=1000
|PretransformPositionalMatchList=1000
|CollectedDigits=1000
|PositionalMatchList=1000
|RouteBlockFlag=RouteThisPattern
 

次のトレースは、Cisco CallManager がこの情報を着信側の IP Phone(IP Phoneは tcpHandle 番号によって識別される)に送信していることを示します。

16:05:43.578 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, CalledPartyName=1000, CalledParty=1000, tcpHandle=0x4fbb150
 

次のトレースは、Cisco CallManager が、着信側の Cisco IP Phoneのコール表示のランプを点滅させるように指示していることを示します。

16:05:430.578 CCM|StationD - stationOutputSetLamp stim: 9=Line instance=1 lampMode=LampBlink tcpHandle=0x4fbb150
 

次のトレースでは、Cisco CallManager が、リンガー、表示通知、およびその他のコール関連情報を着信側の Cisco IP Phoneに提供していることを示します。この場合も同様に、同じ tcpHandle がトレース全体で使用されるため、すべてのメッセージが同じ Cisco IP Phoneに送信されることを確認できます。

16:05:43.578 CCM|StationD - stationOutputSetRinger: 2=InsideRing tcpHandle=0x4fbb150
16:05:43.578 CCM|StationD - stationOutputDisplayNotify tcpHandle=0x4fbb150
16:05:43.578 CCM|StationD - stationOutputDisplayPromptStatus tcpHandle=0x4fbb150
16:05:43.578 CCM|StationD - stationOutputSelectSoftKeys tcpHandle=0x4fbb150
 

また、Cisco CallManager も、同様の情報を発信側の Cisco IP Phoneに提供しているので注意してください。ここでも、tcpHandle を使用して、Cisco IP Phone間を区別します。

16:05:43.578 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, CalledPartyName=, CalledParty=1000, tcpHandle=0x4fbbc30
16:05:43.578 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, CalledPartyName=1000, CalledParty=1000, tcpHandle=0x4fbbc30
 

次のトレースでは、Cisco CallManager が、警告音または呼び出し音を発信側の Cisco IP Phoneに鳴らし、接続が確立したことを通知していることを示します。

16:05:430.578 CCM|StationD - stationOutputStartTone: 36=AlertingTone tcpHandle=0x4fbbc30
16:05:430.578 CCM|StationD - stationOutputCallState tcpHandle=0x4fbbc30
16:05:430.578 CCM|StationD - stationOutputSelectSoftKeys tcpHandle=0x4fbbc30
16:05:430.578 CCM|StationD - stationOutputDisplayPromptStatus tcpHandle=0x4fbbc30
 

この時点では、着信側の Cisco IP Phoneはオフフックです。したがって、Cisco CallManager では、発信側の呼び出し音の生成を停止します。

16:05:450.140 CCM|StationD - stationOutputStopTone tcpHandle=0x4fbbc30
 

次のメッセージでは、Cisco CallManager が、他のデバイスからユニキャスト音声ストリームを受信するために、Skinny Station に対して RTP ポートをオープンするように要求することを示します。これを行うには、Cisco CallManager は着信側の IP アドレスだけでなく、コーデック情報、および msec(ミリ秒)ごとのパケット サイズを提供します。PacketSize は、ミリ秒ごとのサンプリング時間を含む整数の値です。この値を使用して RTP パケットを作成します。

16:05:45.140 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x4fbbc30 myIP: e74610ac (172.16.70.231)
16:05:45.140 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 compressionType:(4)Media_Payload_G711Ulaw64k
 

同様に、Cisco CallManager は着信側(1000)に情報を提供します。

16:05:45.140 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x4fbb150 myIP: e64610ac (172.16.70.230)
16:05:45.140 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 compressionType:(4)Media_Payload_G711Ulaw64k
 

Cisco CallManager は、着信側の IP アドレスだけでなく、RTP ストリームのオープン チャネルの確立に対して、着信側から確認応答メッセージを受信しています。このメッセージは、Cisco CallManager に Skinny Station に関する 2 つの情報を通知します。最初の情報には、オープン要求のステータスが含まれます。次の情報にオープンした受信ポート番号が含まれます。IPAddr および Port の情報は、リモート エンドが RTP ストリームを送信するときに使用するため、次のコマンドで使用されます。

16:05:45.265 CCM|StationInit - InboundStim - StationOpenReceiveChannelAckID tcpHandle=0x4fbb150, Status=0, IpAddr=0xe64610ac, Port=17054, PartyID=2
 

次のメッセージは、指定されたリモート Cisco IP Phoneの IP アドレスおよびポート番号に音声ストリームを送信するようにステーションに指示するために、Cisco CallManager によって使用されます。

16:05:45.265 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x4fbbc30 myIP: e74610ac (172.16.70.231)
16:05:45.265 CCM|StationD - RemoteIpAddr: e64610ac (172.16.70.230) RemoteRtpPortNumber: 17054 msecPacketSize: 20 compressionType:(4)Media_Payload_G711Ulaw64k
 

次のトレースでは、前に説明したメッセージが着信側に送信されます。それらのメッセージの後に続いて、RTP メディア ストリームを示すメッセージが発着の両側で開始されています。

16:05:45.312 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x4fbb150 myIP: e64610ac (172.16.70.230)
16:05:450.328 CCM|StationD - RemoteIpAddr: e74610ac (172.16.70.231) RemoteRtpPortNumber: 18448 msecPacketSize: 20 compressionType:(4)Media_Payload_G711Ulaw64k
16:05:46.203 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x4fbbc30
 

発信側の Cisco IP Phoneがようやくオンフックになります。これにより、Skinny Station 間の RTP ストリームだけでなく、Skinny Station と Cisco CallManager 間のすべての制御メッセージが終了します。

16:05:46.203 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x4fbbc30
 

Cisco IOS ゲートウェイ

この項では、Cisco IOS ゲートウェイを監視するために、Cisco CallManager の機能をサポートする診断上の情報について説明します。特に、次の内容について詳しく解説します。

コール フローのトレース

Cisco IOS ゲートキーパーのデバッグ メッセージおよび show コマンド

Cisco IOS ゲートウェイのデバッグ メッセージおよび show コマンド

T1/PRI インターフェイスを使用した Cisco IOS ゲートウェイ

T1/CAS インターフェイスを使用した Cisco IOS ゲートウェイ

コール フローのトレース

この項では、Cisco CallManager トレース ファイル CCM000000000(ファイルの場所については、前の項を参照)の例を使用して、コール フローについて説明します。詳しいトレース情報はすでに前の事例(初期化、登録、キープアライブ メカニズムなど)で説明してあるため、この事例のトレースでは、コール フローだけに絞って解説します。

このコール フローでは、Cisco IP Phone(電話番号 1001)が、PSTN の任意の場所に設置された電話(電話番号 3333)に発信します。TCP ハンドル値、タイムスタンプ、またはデバイス名を調べることで、デバイスを監視できることを念頭に置いてください。デバイスをリブートするか、オフラインにするまで、デバイスのハンドル値は変わりません。

次のトレースは、Cisco IP Phone(1001)がオフフックになっていることを示します。また、固有のメッセージ、TCP ハンドル、および発番号も示します。このトレースは Cisco IP Phoneに表示されます。ユーザはどのディジットもダイヤルしていないため、この時点では発番号がありません。

16:05:46.37515:20:18.390 CCM|StationInit - InboundStim - OffHookMessageID tcpHandle=0x5138d98
15:20:18.390 CCM|StationD - stationOutputDisplayText tcpHandle=0x5138d98, Display=1001

次のトレースでは、ユーザが 1 回に 1つのディジット 3333 をダイヤルしていることを示します。番号 3333 は電話の着信先の番号です。この電話は PSTN の任意の場所に設置されています。Cisco CallManager の ディジット分析が現在アクティブで、コールのルーティングが必要な場所を検出するために分析しています。ディジット分析の詳細については、前の事例を参照してください。

15:20:180.390 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="")
15:20:190.703 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="3")
15:20:200.078 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="33")
15:20:200.718 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="333")
15:20:210.421 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="3333")
15:20:210.421 CCM|Digit analysis: analysis results

次のトレースでは、ディジット分析が完了し、発着信側が一致してその情報が解析されたことを示します。

|CallingPartyNumber=1001
|DialingPattern=3333
|DialingRoutePatternRegularExpression=(3333)
|PretransformDigitString=3333
|PretransformPositionalMatchList=3333
|CollectedDigits=3333
|PositionalMatchList=3333
 

次のトレースでは、番号 0 が発信場所、番号 1 が着信場所を示します。発信場所の帯域幅は、BW = -1 によって決定されます。値 -1 は、帯域幅が無限であることを示します。LAN 環境に設置された Cisco IP Phoneからコールが発信されたため、帯域幅は無限になります。着信場所の帯域幅は、BW = 64 によって決定されます。コールの着信先は PSTN に設置された電話で、使用するコーデック タイプは G.711(64Kbps)です。

15:20:21.421 CCM|Locations:Orig=0 BW=-1 Dest=1 BW=64 (-1 implies infinite bw available)
 

次のトレースは、発着信側の情報を示します。この例では、 John Smith などのように、管理者がデバイス名を設定していないため、発信側の名前と番号が同じです。

15:20:21.421 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, CalledPartyName=, CalledParty=3333, tcpHandle=0x5138d98
 

次のトレースを確認する前に、H.323 という用語の意味を理解することが重要です。簡単な説明ととして、H.323 セッションの確立時に使用するプロトコルがいくつかあります。プロトコル H.225 は、主にコール シグナリングに使用され、Q.931 のサブセットです。もう 1 つの プロトコル H.245 は、機能交換に使用されます。H.245 の非常に重要な機能の 1 つとなるのが、G.711、G.729 などの Compressor/Decompressor(codec)タイプの発信側と着信側間のネゴシエーションです。機能交換が完了すると、H.245 の次に重要な機能となるのが、発信側と着信側間の UDP ポートのネゴシエーションを実行することです。

次のトレースは、H.323 コードが初期化され、そのコードによって H.225 セットアップ メッセージが送信されていることを示します。また、従来の HDLC SAPI メッセージ、着信側の IP アドレス(16 進法表記)およびポート番号も確認できます。

15:20:21.421 CCM|Out Message -- H225SetupMsg -- Protocol= H225Protocol
15:20:21.421 CCM|MMan_Id= 1. (iep= 0 dsl= 0 sapi= 0 ces= 0 IpAddr=e24610ac IpPort=47110)
 

次のトレースは、H.225 アラート メッセージだけでなく、発着信側の情報も示します。また、Cisco IP Phoneの 16 進値の IP アドレスへのマッピングも示されます。172.16.70.231 は、Cisco IP Phone(1001)の IP アドレスです。

15:20:210.437 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, CalledPartyName=, CalledParty=3333, tcpHandle=0x5138d98
15:20:21.453 CCM|In Message -- H225AlertMsg -- Protocol= H225Protocol
15:20:21.953 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x5138d98 myIP: e74610ac (172.16.70.231)
 

次のトレースは、このコールに使用される圧縮タイプ(G.711 µ-law)を示します。

15:20:210.953 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 compressionType:(4)Media_Payload_G711Ulaw64k
 

H.255 アラート メッセージが送信されると、H.323 の次の部分によって、H.245 が初期化されます。次のトレースは、発着信側の情報と H.245 メッセージを示します。同じコールの継続を示す TCP ハンドル値は以前と同じなので注意してください。

15:20:22.062 CCM|H245Interface(3) paths established ip = e74610ac, port = 23752
15:20:22.062 CCM|H245Interface(3) OLC outgoing confirm ip = e24610ac, port = 16758
15:20:22.062 CCM|MediaManager - wait_AuConnectInfo - received response, forwarding
 

次のトレースは、前に説明したその他の情報だけでなく、H.225接続メッセージも示します。H.255 接続メッセージを受信した場合、コールが接続されています。

15:20:22.968 CCM|In Message -- H225ConnectMsg -- Protocol= H225Protocol
15:20:220.968 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, CalledPartyName=, CalledParty=3333, tcpHandle=0x5138d98
15:20:22.062 CCM|MediaCoordinator - wait_AuConnectInfoInd
15:20:220.062 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x4fbbc30 myIP: e74610ac (172.16.70.231)
15:20:220.062 CCM|StationD - RemoteIpAddr: e24610ac (172.16.70.226) RemoteRtpPortNumber: 16758 msecPacketSize: 20 compressionType:(4)Media_Payload_G711Ulaw64k
15:20:22.062 CCM|Locations:Orig=0 BW=-1Dest=1 BW=6(-1 implies infinite bw available)
 

次のメッセージは、Cisco IP Phone(1001)のオンフック メッセージが受信されていることを示しています。オンフック メッセージを受信した直後に、H.225 および Skinny の接続解除メッセージが送信され、H.225 全体のメッセージが表示されます。この最後のメッセージは、コールが終了したことを示します。

15:20:27.296 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x5138d98
15:20:27.296 CCM|ConnectionManager -wait_AuDisconnectRequest (16777247,16777248): STOP SESSION
15:20:27.296 CCM|MediaManager - wait_AuDisconnectRequest - StopSession sending disconnect to (64,5) and remove connection from list
15:20:27.296 CCM| Device SEP003094C26105 , UnRegisters with SDL Link to monitor NodeID= 1
15:20:27.296 CCM|StationD - stationOutputCloseReceiveChannel tcpHandle=0x5138d98 myIP: e74610ac (172.16.70.231)
15:20:27.296 CCM|StationD - stationOutputStopMediaTransmission tcpHandle=0x5138d98 myIP: e74610ac (172.16.70.231)
15:20:28.328 CCM|In Message -- H225ReleaseCompleteMsg -- Protocol= H225Protocol
 

Cisco IOS ゲートキーパーのデバッグ メッセージおよび show コマンド

前述の項では、Cisco CallManager トレースについて詳しく説明しました。この事例のトポロジーでは、debug ras が Cisco IOS ゲートキーパーでオンになっています。

次のデバッグ メッセージは、Cisco IOS ゲートキーパーが、Cisco CallManager(172.16.70.228)のアドミッション要求(ARQ)を受信していることを示します。それに続いて正常な RAS メッセージが示されます。最後に、Cisco IOS ゲートキーパーによって、でアドミッション確認(ACF)が Cisco CallManager に送信されます。

*Mar 12 04:03:57.181: RASLibRASRecvData ARQ (seq# 3365) rcvd from [172.16.70.228883] on sock [0x60AF038C]
*Mar 12 04:03:57.181: RASLibRAS_WK_TInit ipsock [0x60A7A68C] setup successful
*Mar 12 04:03:57.181: RASlibras_sendto msg length 16 from 172.16.70.2251719 to 172.16.70.228883
*Mar 12 04:03:57.181: RASLibRASSendACF ACF (seq# 3365) sent to 172.16.70.228
 

次のデバッグ メッセージは、コールが通信中であることを示しています。

*Mar 12 04:03:57.181: RASLibRASRecvData successfully rcvd message of length 55 from 172.16.70.228883
 

次のデバッグ メッセージは、Cisco IOS ゲートキーパーが Cisco CallManager(172.16.70.228)から解放要求(DRQ)を受信し、Cisco IOS ゲートキーパーが解放確認(DCF)を Cisco CallManager に送信していることを示します。

*Mar 12 04:03:57.181: RASLibRASRecvData DRQ (seq# 3366) rcvd from [172.16.70.228883] on sock [0x60AF038C]
*Mar 12 04:03:57.181: RASlibras_sendto msg length 3 from 172.16.70.2251719 to 172.16.70.228883
*Mar 12 04:03:57.181: RASLibRASSendDCF DCF (seq# 3366) sent to 172.16.70.228
*Mar 12 04:03:57.181: RASLibRASRecvData successfully rcvd message of length 124 from 172.16.70.228883
 

Cisco IOS ゲートキーパーの show gatekeeper endpoints コマンドは、すべての 4 つの Cisco CallManager が Cisco IOS ゲートキーパーに登録されることを示しています。この事例のトポロジーでは、4 つの Cisco CallManager(各クラスタに 2 つずつ)があります。この Cisco IOS ゲートキーパーには、2 つのゾーンがあり、各ゾーンに 2 つの CiscoCallManager があります。

R2514-1#show gatekeeper endpoints
GATEKEEPER ENDPOINT REGISTRATION
===================================
CallSignalAddr Port RASSignalAddr Port Zone Name Type
--------------- ----- --------------- ----- --------- ---- --
172.16.70.228 2 172.16.70.228 1493 gka.cisco.com VOIP-GW H323-ID: ac1046e4->ac1046f5
172.16.70.229 2 172.16.70.229 3923 gka.cisco.com VOIP-GW H323-ID: ac1046e5->ac1046f5
172.16.70.245 1 172.16.70.245 1041 gkb.cisco.com VOIP-GW H323-ID: ac1046f5->ac1046e4
172.16.70.243 1 172.16.70.243 2043 gkb.cisco.com VOIP-GW H32
3-ID: ac1046f5->ac1046e4
Total number of active registrations = 4
 

Cisco IOS ゲートウェイのデバッグ メッセージおよび show コマンド

前の項では、Cisco IOS ゲートキーパーの show コマンドおよびデバッグ出力について説明しました。この項では、Cisco IOS ゲートウェイのデバッグ出力および show コマンドに絞って解説します。この事例のトポロジーでは、コールは Cisco IOS ゲートウェイを経由します。Cisco IOS ゲートウェイは、T1/CAS インターフェイスまたは T1/PRI インターフェイスを使用して、PSTN または PBX とインターフェイスします。debug voip ccapi inout、debug h225 events、debug h225 asn1 などのコマンドのデバッグ出力を次に示します。

次のデバッグ出力では、Cisco IOS ゲートウェイが、H.225 のポート 2328 で Cisco CallManager(172.16.70.228)からの TCP 接続要求を許容していることを示しています。

*Mar 12 04:03:570.169: H225Lib::h225TAccept: TCP connection accepted from 172.16.70.228:2328 on socket [1]
*Mar 12 04:03:570.169: H225Lib::h225TAccept: Q.931 Call State is initialized to be [Null].
*Mar 12 04:03:570.177: Hex representation of the received TPKT03000065080000100
 

次のデバッグ出力では、H.225 データが この TCP セッションで Cisco CallManager から発信していることを示しています。このデバッグ出力では、protocolIdentifier に注意することが重要です。これは、使用されている H.323 バージョンを示します。次のデバッグは、H.323 バージョン 2 を使用していることを示しています。また、発信側の番号も示されています。

- Source Address H323-ID
- Destination Address e164
*Mar 12 04:03:570.177: H225Lib::h225RecvData: Q.931 SETUP received from socket [1]value H323-UserInformation ::=
*Mar 12 04:03:57.181: {
*Mar 12 04:03:57.181: h323-uu-pdu
*Mar 12 04:03:57.181: {
*Mar 12 04:03:57.181: h323-message-body setup :
*Mar 12 04:03:57.181: {
*Mar 12 04:03:57.181: protocolIdentifier { 0 0 8 2250 0 2 },
*Mar 12 04:03:57.181: sourceAddress
*Mar 12 04:03:57.181: {
*Mar 12 04:03:57.181: h323-ID : "1001"
*Mar 12 04:03:57.181: },
*Mar 12 04:03:570.185: destinationAddress
*Mar 12 04:03:570.185: {
*Mar 12 04:03:570.185: e164 : "3333"
*Mar 12 04:03:570.185: },
*Mar 12 04:03:570.189: H225Lib::h225RecvData: State changed to [Call Present].
 

次の内容は、Call Control Application Programming インターフェイス(CCAPi)のデバッグ出力です。CCAPi は、着信コールを示しています。次の出力では、発着信側の情報も示します。CCAPi はダイヤルピア 0 と一致します。0 がデフォルトのダイヤルピアになります。CCAPi は、発番号のその他のダイヤルピアを見つけることができないため、ダイヤルピア 0 と一致します。その結果、デフォルトのダイヤルピアを使用しています。

*Mar 12 04:03:570.189: cc_api_call_setup_ind (vdbPtr=0x616C9F54, callInfo={called=3333, calling=1001, fdest=1 peer_tag=0}, callID=0x616C4838)
*Mar 12 04:03:570.193: cc_process_call_setup_ind (event=0x617A2B18) handed call to app "SESSION"
*Mar 12 04:03:570.193: sess_appl: ev(19=CC_EV_CALL_SETUP_IND), cid(17), disp(0)
*Mar 12 04:03:570.193: ccCallSetContext (callID=0x11, context=0x61782BBC)
Mar 12 04:03:57.193: ssaCallSetupInd finalDest cllng(1001), clled(3333)
*Mar 12 04:03:570.193: ssaSetupPeer cid(17) peer list: tag(1)
*Mar 12 04:03:570.193: ssaSetupPeer cid(17), destPat(3333), matched(4), prefix(), peer(6179E63C)
*Mar 12 04:03:570.193: ccCallSetupRequest (peer=0x6179E63C, dest=, params=0x61782BD0 mode=0, *callID=0x617A87C0)
*Mar 12 04:03:570.193: callingNumber=1001, calledNumber=3333, redirectNumber=
*Mar 12 04:03:570.193: accountNumber=,finalDestFlag=1, guid=0098.89c8.9233.511d.0300.cddd.ac10.46e6
 

CCAPi では、ダイヤルピア 1 を着信パターン(着番号 3333)に合わせます。peer_tag はダイヤルピアを意味することに留意してください。また、要求パケットにある発着信側の番号に注意してください。

*Mar 12 04:03:570.193: peer_tag=1
*Mar 12 04:03:570.197: ccIFCallSetupRequest: (vdbPtr=0x617BE064, dest=, callParams={called=3333, calling=1001, fdest=1, voice_peer_tag=1}, mode=0x0)
 

次のデバッグ出力は、H.225 アラートメッセージが Cisco CallManager に戻されていることを示しています。

*Mar 12 04:03:570.197: ccCallSetContext (callID=0x12, context=0x61466B30)
*Mar 12 04:03:570.197: ccCallProceeding (callID=0x11, prog_ind=0x0)
*Mar 12 04:03:570.197: cc_api_call_proceeding(vdbPtr=0x617BE064, callID=0x12, prog_ind=0x0)
*Mar 12 04:03:570.197: cc_api_call_alert(vdbPtr=0x617BE064, callID=0x12, prog_ind=0x8, sig_ind=0x1)
*Mar 12 04:03:570.201: sess_appl: ev(17=CC_EV_CALL_PROCEEDING), cid(18), disp(0)
*Mar 12 04:03:570.201: ssa: cid(18)st(1)oldst(0)cfid(-1)csize(0)in(0)fDest(0)-cid2(17)st2(1)oldst2(0)
*Mar 12 04:03:570.201: ssaIgnore cid(18), st(1),oldst(1), ev(17)
*Mar 12 04:03:570.201: sess_appl: ev(7=CC_EV_CALL_ALERT), cid(18), disp(0)
*Mar 12 04:03:570.201: ssa: cid(18)st(1)oldst(1)cfid(-1)csize(0)in(0)fDest(0)-cid2(17)st2(1)oldst2(0)
*Mar 12 04:03:57.201: ssaFlushPeerTagQueue cid(17) peer list: (empty)
*Mar 12 04:03:57.201: ccCallAlert (callID=0x11, prog_ind=0x8, sig_ind=0x1)
*Mar 12 04:03:57.201: ccConferenceCreate (confID=0x617A8808, callID1=0x11, callID2=0x12, tag=0x0)
*Mar 12 04:03:57.201: cc_api_bridge_done (confID=0x7, srcIF=0x616C9F54, srcCallID=0x11, dstCallID=0x12, disposition=0, tag=0x0)value H323-UserInformation
*Mar 12 04:03:57.201: {
*Mar 12 04:03:57.201: h323-uu-pdu
*Mar 12 04:03:57.201: {
*Mar 12 04:03:57.201: h323-message-body alerting :
*Mar 12 04:03:57.201: {
*Mar 12 04:03:57.201: protocolIdentifier { 0 0 8 2250 0 2 },
*Mar 12 04:03:570.205: destinationInfo
*Mar 12 04:03:570.205: {
*Mar 12 04:03:570.205: mc FALSE,
*Mar 12 04:03:570.205: undefinedNode FALSE
*Mar 12 04:03:570.205: },
 

このパケットでは、Cisco IOS が H.245 アドレスおよびポート番号も CiscoCallManager に送信しているので注意してください。場合によっては、Cisco IOS ゲートウェイが到達不能なアドレスを送信することがあります。これは、音声なしまたは一方向の音声の原因となる可能性があります。

*Mar 12 04:03:570.205: h245Address ipAddress :
*Mar 12 04:03:570.205: {
*Mar 12 04:03:570.205: ip 'AC1046E2'H,
*Mar 12 04:03:570.205: port 011008
*Mar 12 04:03:570.205: },
*Mar 12 04:03:570.213: Hex representation of the ALERTING TPKT to send.0300003D0100
*Mar 12 04:03:570.213:
*Mar 12 04:03:570.213: H225Lib::h225AlertRequest: Q.931 ALERTING sent from socket [1]. Call state changed to [Call Received].
*Mar 12 04:03:570.213: cc_api_bridge_done (confID=0x7, srcIF=0x617BE064, srcCallID=0x12, dstCallID=0x11, disposition=0, tag=0x0)
 

次のデバッグ出力では、H.245 セッションが発生していることを示しています。各音声パケットのバイト数だけでなく、コーデック ネゴシエーションの機能表示も確認できます。

*Mar 12 04:03:570.217: cc_api_caps_ind (dstVdbPtr=0x616C9F54, dstCallId=0x11, srcCallId=0x12, caps={codec=0xEBFB, fax_rate=0x7F, vad=0x3, modem=0x617C5720 codec_bytes=0, signal_type=3})
*Mar 12 04:03:570.217: sess_appl: ev(23=CC_EV_CONF_CREATE_DONE), cid(17), disp(0)
*Mar 12 04:03:570.217: ssa: cid(17)st(3)oldst(0)cfid(7)csize(0)in(1)fDest(1)-cid2(18)st2(3)oldst2(1)
*Mar 12 04:03:570.653: cc_api_caps_ind (dstVdbPtr=0x617BE064, dstCallId=0x12, srcCallId=0x11, caps={codec=0x1, fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})
 

次のデバッグ出力では、発着信側が正確に折衝し、データが 160 バイトの G.711 コーデックに同意したことを示しています。

*Mar 12 04:03:570.653: cc_api_caps_ack (dstVdbPtr=0x617BE064, dstCallId=0x12, srcCallId=0x11, caps={codec=0x1, fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})
*Mar 12 04:03:570.653: cc_api_caps_ind (dstVdbPtr=0x617BE064, dstCallId=0x12, srcCallId=0x11, caps={codec=0x1, fax_rate=0x2, vad=0x2, modem=0x, codec_bytes=160, signal_type=0})
*Mar 12 04:03:570.653: cc_api_caps_ack (dstVdbPtr=0x617BE064, dstCallId=0x12, srcCallId=0x11, caps={codec=0x1, fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})
*Mar 12 04:03:570.657: cc_api_caps_ack (dstVdbPtr=0x616C9F54, dstCallId=0x11, srcCallId=0x12, caps={codec=0x1, fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})
*Mar 12 04:03:570.657: cc_api_caps_ack (dstVdbPtr=0x616C9F54, dstCallId=0x11, srcCallId=0x12, caps={codec=0x1, fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})
 

次のように、H.323 接続メッセージおよび接続解除メッセージを次に示します。

*Mar 12 04:03:590.373: cc_api_call_connected(vdbPtr=0x617BE064, callID=0x12)
*Mar 12 04:03:590.373: sess_appl: ev(8=CC_EV_CALL_CONNECTED), cid(18), disp(0)
*Mar 12 04:03:590.373: ssa: cid(18)st(4)oldst(1)cfid(7)csize(0)in(0)fDest(0)-cid2(17)st2(4)oldst2(3)
*Mar 12 04:03:590.373: ccCallConnect (callID=0x11)
*Mar 12 04:03:590.373: {
*Mar 12 04:03:590.373: h323-uu-pdu
*Mar 12 04:03:590.373: {
*Mar 12 04:03:590.373: h323-message-body connect :
*Mar 12 04:03:590.373: {
*Mar 12 04:03:590.373: protocolIdentifier { 0 0 8 2250 0 2 },
*Mar 12 04:03:590.373: h245Address ipAddress :
*Mar 12 04:03:590.373: {
*Mar 12 04:03:590.377: ip 'AC1046E2'H,
*Mar 12 04:03:590.377: port 011008
*Mar 12 04:03:590.377: },
*Mar 12 04:03:590.389: Hex representation of the CONNECT TPKT to send.03000052080
*Mar 12 04:03:590.393: H225Lib::h225SetupResponse: Q.931 CONNECT sent from socket [1]
*Mar 12 04:03:590.393: H225Lib::h225SetupResponse: Q.931 Call State changed to [Active].
*Mar 12 04:04:080.769: cc_api_call_disconnected(vdbPtr=0x617BE064, callID=0x12, cause=0x10)
*Mar 12 04:04:080.769: sess_appl: ev(12=CC_EV_CALL_DISCONNECTED), cid(18), disp(0)
 

T1/PRI インターフェイスを使用した Cisco IOS ゲートウェイ

前述のとおり、Cisco IOS ゲートウェイを経由するコールのタイプは 2つあります。つまり、Cisco IOS ゲートウェイは、T1/CAS インターフェイスまたは T1/PRI インターフェイスを使用して、PSTN または PBX とインターフェイスします。次の内容は、Cisco IOS ゲートウェイで T1/PRI インターフェイスを使用する場合のデバッグ出力です。

Cisco IOS ゲートウェイの debug isdn q931 コマンドがオンになっています。これにより、
Q.931(ISDN 環境の D チャネル、レイヤ 3 シグナリング プロトコル)が有効になります。T1/PRI インターフェイス以外からコールが発信されるたびに、セットアップ パケットが送信されます。セットアップ パケットは、必ず(プロトコル記述子)pd = 8 で、callref のランダム 16 進値を生成します。callref は、コールを追跡するために使用されます。たとえば、2 つのコールが発信された場合、callref 値を使用して RX(受信)メッセージを対象とするコールを判断できます。ベアラ機能 0x8890 は、64KB/秒のデータ コールを意味します。よって、ベアラ機能が 0x8890218F の場合、56KB/秒のデータ コールになります。また、音声コールの場合、ベアラ機能は 0x8090A3 になります。次のデバッグ出力では、ベアラ機能が 0x8090A3(音声用)を示します。また、発着信側の番号も示されます。

callref は、先頭バイトの高位ビットを使用して、TX と RX を区別します。ビット 0 は送信者(発信者)を示し、ビット 1 は受信者を示します。ルータは、ベアラ チャネル(B チャネル)を割り当てる PTSN または PBX に応じて完全に異なります。PSTN または PBX によってチャネルがルータに割り当てられない場合、コールをルーティングできません。この場合、CONNEECT メッセージがスイッチから受信されます。その参照番号は ALERTING で受信した番号と同じです(0x800B)。最後に、コールが接続解除されると、DISCONNECT メッセージの交換、それに続いて RELEASE メッセージと RELEASE_COMP メッセージを確認できます。RELEASE_COMP メッセージの後には、コール拒否の理由 ID が続きます。理由 ID は 16 進値で表されます。16 進値のデコードおよびプロバイダのフォローアップによって、原因の意味を理解できます。

*Mar 1 225209.694 ISDN Se115 TX -> SETUP pd = 8 callref = 0x000B
*Mar 1 225209.694 Bearer Capability i = 0x8090A3
*Mar 1 225209.694 Channel ID i = 0xA98381
*Mar 1 225209.694 Calling Party Number i = 0x2183, ’1001'
*Mar 1 225209.694 Called Party Number i = 0x80, ’3333'
*Mar 1 225209.982 ISDN Se115 RX <- ALERTING pd = 8 callref = 0x800B
*Mar 1 225209.982 Channel ID i = 0xA98381
*Mar 1 225210.674 ISDN Se115 RX <- CONNECT pd = 8 callref = 0x800B
*Mar 1 225210.678 ISDN Se115 TX -> CONNECT_ACK pd = 8 callref = 0x000B
*Mar 1 225215.058 ISDN Se115 RX <- DISCONNECT pd = 8 callref = 0x800B
*Mar 1 225215.058 Cause i = 0x8090 - Normal call clearing 225217 %ISDN-6
DISCONNECT Int S10 disconnected from unknown , call lasted 4 sec
*Mar 1 225215.058 ISDN Se115 TX -> RELEASE pd = 8 callref = 0x000B
*Mar 1 225215.082 ISDN Se115 RX <- RELEASE_COMP pd = 8 callref = 0x800B
*Mar 1 225215.082 Cause i = 0x829F - Normal, unspecified or Special intercept, call blocked group restriction
 

T1/CAS インターフェイスを使用した Cisco IOS ゲートウェイ

前述のとおり、Cisco IOS ゲートウェイを経由するコールのタイプは 2つあります。つまり、Cisco IOS ゲートウェイは、T1/CAS インターフェイスまたは T1/PRI インターフェイスを使用して、PSTN または PBX とインターフェイスします。次の内容は、Cisco IOS ゲートウェイで T1/CAS インターフェイスを使用した場合のデバッグ出力です。Cisco IOS ゲートウェイの debug cas がオンになっています。

次のデバッグ メッセージでは、Cisco IOS ゲートウェイによってオフフック信号がスイッチに送信されていることを示しています。

Apr 5 17:58:21.727: from NEAT(0): (0/15): Tx LOOP_CLOSURE (ABCD=1111)
 

次のデバッグ メッセージでは、Cisco IOS ゲートウェイから閉ループ信号を受信した後、スイッチによってウィンクが送信されていることを示しています。

Apr 5 17:58:210.859: from NEAT(0): (0/15): Rx LOOP_CLOSURE (ABCD=1111)
Apr 5 17:58:220.083: from NEAT(0): (0/15): Rx LOOP_OPEN (ABCD=0000)
 

次のデバッグ メッセージでは、Cisco IOS ゲートウェイがオフフックになっていることを示しています。

Apr 5 17:58:230.499: from NEAT(0): (0/15): Rx LOOP_CLOSURE (ABCD=1111)
 

次の内容は、コールが通信中における Cisco IOS ゲートウェイの show call active voice brief の出力を示しています。また、発着信側の番号とその他の有益な情報も示されます。

R5300-5#show call active voice brief
<ID>: <start>hs.<index> +<connect> pid:<peer_id> <dir> <addr> <state> tx:<packets>/<bytes> rx:<packets>/<bytes> <state>
IP <ip>:<udp> rtt:<time>ms pl:<play>/<gap>ms lost:<lost>/<early>/<late> delay:<last>/<min>/<max>ms <codec>
FR <protocol> [int dlci cid] vad:<y/n> dtmf:<y/n> seq:<y/n> sig:<on/off> <codec> (payload size)
Tele <int>: tx:<tot>/<v>/<fax>ms <codec> noise:<l> acom:<l> i/o:<l>/<l> dBm
511D : 156043737hs.1 +645 pid:0 Answer 1001 active
tx:1752/280320 rx:988/158080
IP172.16.70.228:18888 rtt:0ms pl:15750/80ms lost:0/0/0 delay:25/25/65ms g711ulaw
511D : 156043738hs.1 +644 pid:1 Originate 3333 active
tx:988/136972 rx:1759/302548
Tele 1/0/0 (30): tx:39090/35195/0ms g711ulaw noise:-43 acom:0 i/0:-36/-42 dBm
 

国際電話番号のダイヤル後のビジー信号の発生

問題

ユーザに設置の CM3.0 には、ルート パターンが適正に設定されていて、DT-24+ ゲートウェイまたは 6608 ゲートウェイに割り当てられています。市内番号および米国長距離番号のダイヤルには問題ありません。それに対し、国際番号をダイヤルすると、最初にポーズ音、次にビジー信号が聞こえてきます。

解決策

この問題は、CO スイッチでコール IE(Information Element;情報要素)が適切に処理される方法がないという既知の問題です。この問題を修正するには、図 6-55 に示すようにゲートウェイ構成から Cisco CallManager の発信側の IE タイプを unknown に設定します。

図 6-55 発信側の IE タイプの設定

 

クラスタ間 IP Phone 対 IP Phone

前述の事例の中に、Cisco IOS ゲートウェイからローカル PBX または PSTN の任意の場所に設置されている電話までの、クラスタ間コールおよび Cisco IP Phone コールのコール フローとトラブルシューティングの技法について詳しく説明しているところがあります。この事例では、Cisco IP Phoneが異なるクラスタ内に設置されている別の Cisco IP Phoneに発信する場合について検討します。このコールのタイプは、クラスタ間 Cisco IP Phoneコールとも呼ばれています。

サンプル トポロジー

図 6-56 では、この事例に使用されているトポロジーの例を示します。このトポロジーには、キャンパスに 2 つのクラスタがあり、それぞれのクラスタに 2 つの Cisco CallManager が配置されています。ほかにも、Cisco IOS ゲートウェイと Cisco IOS ゲートキーパーが配置されています。

図 6-56 クラスタ間トポロジーの例

 

クラスタ間の H.323 通信

図 6-56 のトポロジーで示すように、クラスタ 1 の Cisco IP Phoneは、クラスタ 2 の Cisco IP Phoneへ発信しています。クラスタ間の Cisco CallManager では、H.323 バージョン 2 プロトコルを使用して通信を行います。また、アドミッション制御を行うために Cisco IOS ゲートキーパーも配置されています。デバッグ出力および show コマンドの説明、および Cisco IOS ゲートキーパー、Cisco IOS ゲートウェイ、Cisco CallManager デバイス間のインターフェイスの詳細は、前の項を参照してください。

コール フローのプロセスは、図 6-57 に示されています。Cisco IP Phoneは、Skinny Station プロトコルを使用して Cisco CallManager と通信でき、Cisco CallManager は H.323 プロトコルを使用して Cisco IOS ゲートキーパーと通信できます。アドミッション要求メッセージ(ARQ)が Cisco IOS ゲートキーパーに送信され、そこで、H.323 バージョン 2 プロトコルを使用してクラスタ間コールが発信できると確認された後、Cisco IOS ゲートキーパーによってアドミッション確認メッセージ(ACF)が送信されます。これが完了すると、異なるクラスタにある Cisco IP Phone間で RTP プロトコルを使用して、音声パスが作成されます。

図 6-57 クラスタ間トポロジーのコール フロー プロセス

 

コール フローのトレース

この項では、CCM000000000 ファイルにキャプチャされた CallManager トレースの例を使用したコール フローについて説明します。このファイルの場所は、前の項に説明されています。詳しいトレース情報はすでに前の事例(初期化、登録、キープアライブ メカニズムなど)で説明しているため、この事例のトレースでは、コール フローだけに絞って解説します。

このコール フローでは、クラスタ 2 に配置されている Cisco IP Phone(2002)が、クラスタ 1 に配置されている Cisco IP Phone(1001)に発信しています。TCP ハンドル値、タイムスタンプ、またはデバイス名を調べることで、デバイスを監視できることを念頭に置いてください。デバイスをリブートするか、オフラインにするまで、デバイスのハンドル値は変わりません。

次のトレースでは、Cisco IP Phone(2002)がオフフックになっていることを示しています。また、固有のメッセージ、TCP ハンドル、および発番号も示します。このトレースは Cisco IP Phoneに表示されます。次のデバッグ出力では、着番号、H.225 接続、および H.245 確認メッセージを確認できます。コーデックのタイプは G.711 µ-law です。

16:06:13.921 CCM|StationInit - InboundStim - OffHookMessageID tcpHandle=0x1c64310
16:06:13.953 CCM|Out Message -- H225ConnectMsg -- Protocol= H225Protocol
16:06:13.953 CCM|Ie - H225UserUserIe IEData= 7E 00 37 05 02 C0 06
16:06:13.953 CCM|StationD - stationOutputCallInfo CallingPartyName=, CallingParty=2002, CalledPartyName=1001, CalledParty=1001, tcpHandle=0x1c64310
16:06:14.015 CCM|H245Interface(2) OLC indication chan number = 2
16:06:14.015 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x1c64310 myIP: e74610ac (172.16.70.231)
16:06:140.015 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 compressionType:(4)Media_Payload_G711Ulaw64k
16:06:14.062 CCM|StationInit - InboundStim - StationOpenReceiveChannelAckID tcpHandle=0x1c64310, Status=0, IpAddr=0xe74610ac, Port=20444, PartyID=2
16:06:14.062 CCM|H245Interface(2) paths established ip = e74610ac, port = 20444
16:06:14.187 CCM|H245Interface(2) OLC outgoing confirm ip = fc4610ac, port = 29626
 

次のトレースでは、IP アドレスおよび 16 進値に関連付けられる発着信側の番号を確認できます。

16:06:14.187 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x1c64310 myIP: e74610ac (172.16.70.231)
16:06:140.187 CCM|StationD - RemoteIpAddr: fc4610ac (172.16.70.252)
 

次のトレースでは、Cisco IP Phone(2002)のパケット サイズと MAC アドレスを示します。これらのトレースに続いて、接続解除メッセージ、その後にオンフック メッセージがあります。

RemoteRtpPortNumber: 29626 msecPacketSize: 20 compressionType:(4)Media_Payload_G711Ulaw64k
16:06:160.515 CCM| Device SEP003094C26105 , UnRegisters with SDL Link to monitor NodeID= 1
16:06:16.515 CCM|StationD - stationOutputCloseReceiveChannel tcpHandle=0x1c64310 myIP: e74610ac (172.16.70.231)
16:06:16.515 CCM|StationD - stationOutputStopMediaTransmission tcpHandle=0x1c64310 myIP: e74610ac (172.16.70.231)
16:06:160.531 CCM|In Message -- H225ReleaseCompleteMsg -- Protocol= H225Protocol
16:06:16.531 CCM|Ie - Q931CauseIe -- IEData= 08 02 80 90
16:06:16.531 CCM|Ie - H225UserUserIe -- IEData= 7E 00 1D 05 05 80 06
16:06:16.531 CCM|Locations:Orig=1 BW=64 Dest=0 BW=-1 (-1 implies infinite bw available)
16:06:160.531 CCM|MediaManager - wait_AuDisconnectRequest - StopSession sending disconnect to (64.2) and remove connection from list
16:06:16.531 CCM|MediaManager - wait_AuDisconnectReply - received all disconnect replies, forwarding a reply for party1(16777219) and party2(16777220)
16:06:16.531 CCM|MediaCoordinator - wait_AuDisconnectReply - removing MediaManager(2) from connection list
16:06:16.734 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x1c64310
 

失敗したコール フロー

次の項では、次 CallManager トレースで示されているように、失敗したクラスタ間のコール フローについて説明します。下のトレースは、Cisco IP Phone(1001)がオフフックになっていることを示します。TCP ハンドルが Cisco IP Phoneに割り当てられています。

16:05:330.468 CCM|StationInit - InboundStim - OffHookMessageID tcpHandle=0x4fbbc30
16:05:33.468 CCM|StationD - stationOutputDisplayText tcpHandle=0x4fbbc30, Display= 1001
16:05:330.484 CCM|StationD - stationOutputSetLamp stim: 9=Line instance=1 lampMode=LampOn tcpHandle=0x4fbbc30
 

次のトレースでは、ユーザが Cisco IP Phoneの着信側番号をダイヤルし、番号一致にディジット分析の処理実行していることを示します。

16:05:330.484 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="")
16:05:330.484 CCM|Digit analysis: potentialMatches=PotentialMatchesExist
16:05:350.921 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="2")
16:05:35.921 CCM|Digit analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist
16:05:360.437 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="20")
16:05:360.437 CCM|Digit analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist
16:05:360.656 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="200")
16:05:360.656 CCM|Digit analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist
16:05:360.812 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="2000")
 

これで、ディジット分析が完了し、その結果が次のトレースに示されます。次に示す
PotentialMatches=NoPotentialMatchesExist
参照は、CiscoCallManager がこの電話番号の一致を確認できないことを示すので注意することが重要です。最後に、リオーダー トーンが発信側(1001)に送信され、オンフック メッセージがそれに続きます。

16:05:360.812 CCM|Digit analysis: analysis results
16:05:360.812 CCM||PretransformCallingPartyNumber=1001
|CallingPartyNumber=1001
|DialingPattern=2XXX
|DialingRoutePatternRegularExpression=(2XXX)
|PotentialMatches=NoPotentialMatchesExist
|CollectedDigits=2000
16:05:36.828 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, CalledPartyName=, CalledParty=2000, tcpHandle=0x4fbbc30
16:05:360.828 CCM|StationD - stationOutputStartTone: 37=ReorderTone tcpHandle=0x4fbbc30
16:05:370.953 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x4fbbc30
 

コール詳細レコード

この項では、コール詳細レコード(CDR)とコール管理レコード(CMR、また、診断用 CDR とも呼ばれる)の詳細について説明します。

CDR レコードは、プロセスの後処理に使用されるためにデータベースに書き込まれます。それらの後処理には、多くの機能が含まれていますが、主として課金とネットワーク分析で占められています。

データベースは、Microsoft SQL Server 7.0 データベースを使用します。データベースへのアクセスは、Open DataBase Connectivity(ODBC)を使用して行われます。

データベース内のすべてのテーブルには、読み取り専用アクセス、CDR テーブルおよび CMRテーブルには読み取り/書き込みアクセスが提供されます。

CDR レコード データを使用するには、CDR に関連するデバイス タイプに関する情報を取得するため、データベース内のその他のテーブルを読み取る場合があります。CDR レコードにリストされるデバイス テーブルと IP アドレスのデバイス間の相関は簡単ではないため、既知の問題としてこの項の後半にリストされています。

この項で説明する内容は、次のとおりです。

レコードの書き込み

レコードの読み込み

レコードの削除

テーブル スキーマ

既知の問題

コール詳細レコードのフィールド

コール タイプ別にログされたコール レコード

コール タイプ別にログされたコール管理レコード

コーデック タイプ(圧縮/ペイロード)

理由コード

アラーム

レコードの書き込み

Cisco CallManager では、コールが各 Cisco CallManager の構成とある程度整合性が取れるように、SQL データベースに CDR レコードを書き込みます。この構成は、Cisco CallManager Administration の Service Parameters 画面で設定されます。

最終的に、すべてのレコードはクラスタのプライマリ データベースに書き込まれます。サブスクライバでは、CDR データをサブスクライバのローカル データベースに書き込んでから、そのデータをパブリッシャ データベースに複製します(デフォルトでは、60 秒ごとに複製)。プライマリ データベースを使用できない場合、レコードはその他のいずれかのバックアップ データベースに書き込まれます。プライマリ データベースが使用できるようになったら、新しいレコードをプライマリ データベースに書き込み続け、ローカルで書き込まれたレコードはプライマリ データベースに移動されます。

レコードの読み込み

SQL データベースからデータを読み込む最も簡単な方法は、ODBC を使用することです。適切な接続文字列は、次のようになります。

DRIVER={SQL Server};SERVER=machineX;DATABASE=CCM0300
 

正確なデータベース名が使用されていることを確認します。Cisco CallManager リリース 3.0(1) のソフトウェア バージョンを既存のインストールにインストールする場合、新しいインストールによる要求に応じてデータベースを移行する場合があります。この場合、古いデータベースと新しいデータベースが混在することになります。よって、データベースの名前の番号に 1 を追加することによって、それらの名前を区別します。たとえば、元の名前が CCM0300 だとします。移行後、新しいデータベース名は CCM0301になります。番号が一番大きいデータベースを使用する必要があります。

クラスタによって現在使用されているプライマリ データベース(マシンおよび名前)を表示するには、Cisco CallManager Administration の Details ボタンをクリックします(Help をクリックすると、Welcome 画面に移動し、そこに Details ボタンが表示されます)。データベースのホストとして機能するマシンのレジストリもチェックできます。DBConnection0 と呼ばれる項目については、レジストリ キー HKEY_LOCAL_MACHINE/Software/Cisco Systems Inc/DBL を調べます。この文字列項目には、プライマリ データベースのマシン名とデータベース名を含む上に示した文字列と同様の接続文字列が含まれます。

アクセスは、SQL ユーザの使用によって制御されます。 表 6-35 では、Cisco CallManager データベースのアクセス時に使用すべきユーザ ID とパスワードを示します。

 

表 6-35 Cisco CallManager データベースに使用するユーザ ID とパスワードの例

テーブル
SQL ユーザ ID
パスワード
機能

CallDetailRecord, CallDetailRecordDiagnostic

CiscoCCMCDR

dipsy

読み取り/書き込み

(その他)

CiscoCCMReader

cowboys

読み取り専用

レコードの削除

Cisco CallManager では、CDR データの後処理にサード パーティ製のアプリケーションを使用するため、すべてのアプリケーションでデータ入力を完了したら、CDR データを削除する必要があります。この作業には、データベースの修正が伴うため、Cisco CCMCDR ユーザがその作業を実行する必要があります。

CDR レコードが設定した最大数(1000 万件の CDR レコード)まで蓄積した場合、1 日に 1 回関連するCMR レコードとともに最も古い CDR レコードが削除されます。

分析後に CDR データを削除する場合、同様に関連するすべての CMR レコードも必ず削除してください。

テーブル スキーマ

CDR の各フィールドの形式と使用方法に関する詳細については、この項の後半で説明します。

使用するプライマリ テーブルは、CallDetailRecord テーブル(CDR レコードを保持する)と CallDetailRecordDiagnostic テーブル(CMR レコードを保持する)です。CallDetailRecord テーブルは、GlobalCallID の 2 つのカラム GlobalCallID_callManagerId と GlobalCallID_callId によって CallDetailRecordDiagnostic テーブルに関連します。1 つの CDR に対して複数の CMR が存在する場合があります。

CallDetailRecord テーブルには、コールのエンドポイントおよびコールのその他のコールの制御/ルーティングに関する情報が保持されます。CallDetailRecordDiagnostic テーブルには、コールのストリームされた音声の品質に関する情報が保持されます。

既知の問題

Cisco CallManager リリース 3.0(1) には、CDR に関して既知の問題があります。次に、いくつかの問題を説明します。

IP から デバイス名への変換

CDR テーブルには、コールのエンドポイントに対する IP アドレスがリストされています。それらの IP アドレスはデバイス名に容易に変換されるわけでなく、デバイスのタイプを決定します。

オンネット対オフネット

コールが完全に IP ネットワークに留まるか、あるいは少なくともローカル システム内部に留まるかを認識するのは困難です。解決策の 1 つとしては、コールの両終端のデバイスのタイプをチェックすることです。両方とも電話の場合、コールはオンネットの状態であると推定できます。ただし、一方がゲートウェイの場合は、推測を広める必要があります。ゲートウェイのデバイスのタイプが POTS またはステーション ポート付きの Analog Access である場合、コールは、市内のアナログ電話に向かっているか、PSTN から外れただけに過ぎない場合があります。コールがオフネットであるかどうかを推定するには、ダイヤルした番号を調べ、その番号と既知のダイヤル計画を関連付けてください。それ以外の場合、コールはほとんどオフネット状態です。

オフネット ディジット ダイヤラー

コールがゲートウェイから外れた場合、ゲートウェイに着信するようにダイヤルされた番号は、PSTN に送信される番号にならない場合があります ゲートウェイの性能には問題ないと思われるため、さらに電話番号を修正してください。この場合には、Cisco CallManager では認識されず、CDR ではオフネット送信された実際のディジットを反映していません。

コール詳細レコードのフィールド

この項では、現在のレコードのすべてのフィールドが定義されています。フィールド タイプとは、Cisco CallManager によって使用されるフィールド タイプであり、必ずしもデータベースの CDR レコードに定義されているフィールド タイプではありません。データベースのフィールド定義は、データの保存に適していますが、データの解釈には、ここで定義されているフィールド タイプが必要です。

符号なし整数はすべて、32 ビット の符号なし整数となります。

フィールド データの変換

フィールドを表示するには、一部のフィールドでは、10 進法形式から別の形式に変換する必要があります。この項では、フィールド値、その変換方法やその方法に関する情報の入手先が定義されています。

タイム値

すべてのタイム値は、符号なしの 32ビット整数で表されています。この符号なし整数は、データベースでは符号付き整数で表示されます。

このフィールドは、Windows NT(2000)のシステム ルーチンから取得される time_t 値です。その値は、世界標準時(UTC)であり、1970 年 1 月 1 日の 午前 12 時(00:00:00)以来から秒数で表されます。

タイムスタンプの解読

Microsoft Excel を使用して式を書き込むと、このタイムスタンプの変換を少しだけ容易にすることができます。値が セル A1 にある場合、次のように別のセルを作成できます。

=A1/86400+DATE(1970,1,1)
 

1 日は 86400 秒です。

次に、Excel 上で、結果のセルを日時フィールドとして書式設定します。

IP アドレス

すべての IP アドレスは、システムに符号なし整数で保存されます。データベースでは、IP アドレスが符号付き整数で表示されます。符号付き 10 進値を IP アドレスに変換するには、最初にその値を 16 進値に変換します(実際に符号なし整数となるように考慮する)。32 ビットの 16 進値は 4 バイトで表されます。また、4 バイトは逆順に入ります(Intel 標準)。IP アドレスを取得するには、バイトの順序を逆順にしてから、各バイトを 10 進値に変換します。その結果、4 バイトはドット付き IP アドレスの 4 バイトのフィールドで表されます。


) IP アドレスの低位バイトに最上位ビット セットがある場合、データベースでは、IP アドレスが負数で表示されています。


IP アドレスの変換

例 1

たとえば、IP アドレス 192.168.18.188 の場合、次のように表示されます。

データベース表示 = -1139627840

これは、0xBC12A8C0 の 16 進値に変換されます。

16 進バイトの逆順 = C0A812BC

CO A8 12 BC

16 進から 10 進に変換されたバイト = 192 168 18 188(192.168.18.188 で表示される)

例 2

IP アドレス 192.168.18.59

データベース表示 = 991078592

これは、0x3B12A8C0 の 16 進値に変換されます。

バイト順序の逆順 = C0A8123B

C0 A8 12 3B

16 進から 10 進に変換されたバイト = 192 168 18 59(192.168.18.59 で表示される)

CDR フィールド定義

表 6-36 では、CDR のフィールド定義を示します。

表 6-36 CDR フィールド定義

フィールド
定義

cdrRecordType

このレコードのタイプ

符号なし整数

この特定のレコード タイプを指定します。これは、コール レコードの開始(0)、コール レコードの終了(1)、または CMR レコード(2)から選択できます。

globalCallIdentifier

グローバル コール ID

グローバル コール ID は、いずれも符号なし整数である 2 つのフィールドで構成されます。その値は符号なし整数として処理する必要があります。

2 つのフィールドは次のとおりです。

符号なし整数 GlobalCallID_CallID

符号なし整数 GlobalCallID_CallManagerID

これは、コール全体に割り当てられるコール ID です。標準コールに関連するすべてのレコードには、同じグローバル コール ID が割り当てられます。

origLegCallIdentifier

発信レッグ コール ID

符号なし整数

これは、コールの発信側レッグの追跡に使用される固有の ID です。また、クラスタ内でも固有です。

dateTimeOrigination

コール発信の日時

符号なし整数

これは、コールの発信デバイスがオフフックになった時間、または外部コールがシステムで初めて認識された時間(Setup メッセージを受信した時間)を表します。その値は、世界標準時(UTC)であり、1970 年 1 月 1 日の 午前 12 時(00:00:00)以来から秒数で表されます。

origNodeId

発信者のノード ID

符号なし整数

このフィールドは、コール発信者がこのコール時に登録された Cisco CallManager クラスタ内のノードを表します。

origSpan

発信者のスパンまたはポート

符号なし整数

コールがゲートウェイ経由で発信された場合、このフィールドには発信者のポート番号またはスパン番号が含まれます。ゲートウェイを経由しない場合、このフィールドにはゼロ(0)が含まれます。

callingPartyNumber

発信側番号

25 文字まで

これは、コール発信元のデバイスの電話番号です。

origIpPort

発信側の IP ポート

符号なし整数

このフィールドには、コール発信元のデバイスの IP ポートが含まれます。

origIpAddr

発信側の IP アドレス

符号なし整数

このフィールドには、コール発信元のデバイスの IP アドレスが含まれます。

originalCallingPartyNumberPartition

発信側のパーティション

50 文字まで

このフィールドには、発信側に関連するパーティションが含まれます。

origCause_Location

ISDN ロケーション値

符号なし整数

このフィールドには、原因情報要素のロケーション値が含まれます。

origCause_Value

発信側のコール終了理由

符号なし整数

この原因は、発信デバイスのコールが終了した理由を表します。送信、転送などの場合、コール終了の理由が発信デバイスと終了デバイスで異なる場合があります。したがって、各コールに関連付けられた理由フィールドが 2 つあります。通常は、2 つの理由フィールドは同じになります。

origMediaTransportAddress_IP

発信者のメディア接続の IP アドレス

符号なし整数

これは、発信者が接続したメディア ストリームの宛先 IP アドレスです。

origMediaTransportAddress_Port

発信者のメディア接続のポート

符号なし整数

これは、発信者が接続したメディア ストリームの宛先ポートです。

origMediaCap_payloadCapability

発信者によって使用されるコーデック タイプ

符号なし整数

このフィールドには、このコール時に発信者が送信側で使用されたコーデック タイプ(圧縮またはペイロード タイプ)が含まれます。これは、その受信側で使用されたコーデック タイプとは異なる場合があります。

origMediaCap_maxFramesPerPacket

データ パケットのミリ秒数

符号なし整数

このフィールドには、このコールの発信者によって宛先に送信されたデータ パケットのミリ秒数が含まれます。実際のサイズは、データの生成に使用されているコーデック タイプに応じて異なります。

origMediaCap_g723BitRate

G.723 によって使用されるビット レート

符号なし整数

G.723 によって使用されるビット レートを定義します。2 つのビット レート値があります(1 =5.3K ビット レートおよび 2 = 6.3K ビット レート)。

lastRedirectDn

このコールを最後にリダイレクトしたパーティの電話番号

25 文字まで

これは、コールをリダイレクトした最後のデバイスの電話番号です。このフィールドは、会議電話、転送サービスなどリダイレクトしたコールだけが適用されます。

lastRedirectDnPartition

このコールを最後にリダイレクトした電話番号のパーティション

50 文字まで

これは、コールをリダイレクトした最後のデバイスのパーティションです。このフィールドは、会議電話、転送サービスなどリダイレクトしたコールだけが適用されます。

destLegIdentifier

コールの宛先レッグのコール ID

符号なし整数

これは、コールの宛先レッグの追跡に使用される固有の ID です。また、クラスタ内でも固有です。

destNodeId

コールの宛先が登録されたノードのノード ID

符号なし整数

宛先デバイスがこのコール時に登録された Cisco CallManager クラスタ内のノードです。

dest Span

宛先のスパンまたはポート

符号なし整数

コールがゲートウェイ経由で終了した場合、このフィールドには宛先のポート番号またはスパン番号が含まれます。ゲートウェイを経由しない場合、このフィールドには 0(ゼロ)が含まれます。

destIpAddr

コールの送達先の IP アドレス

符号なし整数

このフィールドには、コールを終了したデバイスのシグナリング接続の IP アドレスが含まれます。

destIpPort

コールの送達先の IP ポート

符号なし整数

このフィールドには、コールを終了したデバイスのシグナリング接続の IP ポートが含まれます。

originalCalledPartyNumber

コール発信者から受信した宛先

25 文字まで

このフィールドには、コールの発信者によってダイヤルされたディジットに基づいて本来のコールを拡張した電話番号が含まれます。コールが普通に完了した場合(転送されなかったことを意味する)、この電話番号は必ず
finalCalledPartyNumber
と同じになります。コールが転送された場合、このフィールドには転送前のコールの本来の宛先が含まれます。

originalCalledPartyNumberPartition

着信側のパーティション

50 文字まで

このフィールドには、着信側に関連するパーティションが含まれます。

finalCalledPartyNumber

コールの送達先の宛先

25 文字まで

このフィールドには、コールを実際に拡張した電話番号が含まれます。コールが普通に完了した場合(転送されなかったことを意味する)、この電話番号は必ず originalCalledPartyNumber と同じになります。コールが転送された場合、このフィールドにはすべての転送が完了した後の最後の宛先の電話番号が含まれます。

finalCalledPartyNumberPartition

コールの最後の宛先に関連するパーティション

50 文字まで

このフィールドには、コールを実際に拡張した宛先に関連するパーティションが含まれます。通常のコールでは、このフィールドは、
originalCalledPartyNumberPartition
と同じになります。コールが転送された場合、このフィールドにはすべての転送が完了した後の最後の宛先のパーティションが含まれます。

destCause_location

着信側の理由ロケーション

符号なし整数

これは、原因情報要素の ISDN ロケーション値です。

destCause_value

着信側のコール終了理由

符号なし整数

この原因は、終端デバイスのコールが終了した理由を表します。送信、転送などの場合、コール終了の理由がコール着信者とコール発信者で異なる場合があります。したがって、各コールに関連付けられた理由フィールドが 2 つあります。通常は、2 つの理由フィールドは同じになります。ビジー デバイスが転送されるコールを拡張しようとすると、コールが転送先に接続した場合でも、理由コードが Busy に反映されてしまいます。

destMediaTransportAddress_IP

宛先の発信メディア接続の IP アドレス

符号なし整数

これは、宛先が接続したメディア ストリームの発信 IP アドレスです。

origMediaTransportAddress_Port

宛先の発信メディア接続のポート

符号なし整数

これは、宛先が接続したメディア ストリームの発信者のポートです。

destMediaCap_payloadCapability

送信側の宛先によって使用されたコーデック タイプ

符号なし整数

このフィールドには、このコール時にその送信側で使用されたコーデック タイプ(圧縮またはペイロード タイプ)が含まれます。これは、その受信側で使用されたコーデック タイプとは異なる場合があります。

destMediaCap_maxFramesPerPacket

データ パケットのミリ秒数

符号なし整数

このフィールドには、このコールの宛先によって発信者に送信されたデータ パケットのミリ秒数が含まれます。実際のサイズは、データの生成に使用されているコーデック タイプに応じて異なります。

destMediaCap_g723BitRate

G.723 によって使用されるビット レート

符号なし整数

G.723 によって使用されるビット レートを定義します。2 つのビット レート値があります(1 =5.3K ビット レートおよび 2 = 6.3K ビット レート)。

dateTimeConnect

接続の日時

符号なし整数

これは、コールが発信デバイスと終端デバイス間に接続した日時です。その値は、世界標準時(UTC)であり、1970 年 1 月 1 日の 午前 12 時(00:00:00)以来から秒数で表されます。

dateTimeDisconnect

接続解除の日時

符号なし整数

これは、コールが発信デバイスと終端デバイス間で接続解除した、あるいはコールが接続しなかった場合でも、コールが分解された日時です その値は、世界標準時(UTC)であり、1970 年 1 月 1 日の 午前 12 時(00:00:00)以来から秒数で表されます。

duration

コール時間

これは、コールが接続した秒数です。接続の日時と接続解除の日時の間は異なります。

CMR フィールド定義

表 6-37 では、CMR(診断用 CDR)のフィールド定義を示します。

 

表 6-37 フィールド定義

フィールド
定義

cdrRecordType

このレコードのタイプ

符号なし整数

この特定のレコード タイプを指定します。これは、CMR レコードに設定されます。

globalCallIdentifier

このコールのグローバル コール ID

グローバル コール ID は、いずれも符号なし整数である 2 つのフィールドで構成されます。その値は符号なし整数として処理する必要があります。

2 つのフィールドは次のとおりです。

これは、コール全体に割り当てられるコール ID です。標準コールに関連するすべてのレコードには、同じグローバル コール ID が割り当てられます。

nodeID

Cisco CallManager のノード ID

このレコードが生成された Cisco CallManager 内のノード。

callIdentifier

コール ID

符号なし整数

これは、このレコードに関連するコール レッグを識別するコール レッグ ID です。

directoryNum

このコールで使用された電話番号

これは、それらの診断が収集されたデバイスの電話番号です。

directoryNumPartition

電話番号に関連するパーティション

これは、このレコードの電話番号のパーティションです。

dateTimeStamp

コール終了の日時

これは、デバイスがオンフックになったおおよその時間を表します。電話が診断情報の要求に応答するときに、その時間がレコードに入力されます。これは、 time_t 値です。

numberPacketsSent

送信されたパケット数

この接続で送信を開始してからデバイスによって送信された RTP データ パケットの合計数。接続が receive only モードに設定された場合には、値が 0 になります。

numberOctetsSent

他のパーティに送信されたデータのオクテット(バイト)数

この接続で送信を開始してからデバイスによって RTP データ パケットで送信されたペイロード オクテット(よって、へッダーとパッディングは含まれない)の合計数。接続が receive only モードに設定された場合には、値が 0 になります。

numberPacketsReceived

このコール時に受信したデータ パケット数

この接続で受信を開始してからデバイスによって受信された RTP データ パケットの合計数。マルチキャスト コールの場合、そのカウントには異なる発信元から受信したパケットが含まれます。接続が send only モードに設定された場合には、値が 0 になります。

numberOctetsReceived

このコール時に受信したデータのオクテット(バイト)数

この接続で受信を開始してからデバイスによって RTP データ パケットで受信されたペイロード オクテット(よって、へッダーとパッディングは含まれない)の合計数。マルチキャスト コールの場合、そのカウントには異なる発信元から受信したパケットが含まれます。接続が send only モードに設定された場合には、値が 0 になります。

numberPacketsLost

この接続時に損失したパケット

受信を開始してから RTP データ パケット損失したその合計数。この数値は、予測パケット数として定義され、実際に受信したパケット数よりも少なくなります。そこで受信したパケット数には、遅延または重複したパケットが含まれます。したがって、遅延したパケットは損失としてカウントされず、重複がある場合には損失がマイナスになる場合があります。予想パケット数は、延長した最後のシーケンス番号を受信するために定義されます。また、モードの場合に定義されるように、受信した最初のシーケンス番号が少なくなります。接続が send only モードに設定された場合には、値が 0 になります(詳細については、RFC 1889 を参照)。

ジッタ

この接続時の着信間ジッタ

RTP データ パケットの着信間時間の統計的な変動の予想値。ミリ秒単位で測定され、符号なしの整数で表されます。着信間ジッタ J は、受信者のパケット スペースの差異 D の平均偏差を対のパケットの送信者と比較するために定義されます。計算アルゴリズムの詳細については、RFC 1889 を参照してください。接続が send only モードに設定された場合には、値が 0 になります。

latency

この接続に発生した遅延

値はネットワーク遅延をミリ秒単位で予想した値です。これは、RTP Control Protocol(RTCP)メッセージの送信者によって示される RTP ネットワーク タイム プロトコル(NTP)タイムスタンプとそれらのメッセージの受信時に予想される受信者の NTP タイムスタンプ間の差異の平均値です。すべての予想を合計してから、受信した RTCP メッセージ数で割ることで、平均が算出されます。詳細については、コメント要求(RFC)1889を参照してください。

コール タイプ別にログされたコール レコード

2 者間で行われる通常コールごとに、CDR エンドコール レコードが 1 つログされます。各エンド コール レコードには、前述の表で説明したすべてのフィールド(一部のフィールドは使用されない場合がある)が含まれます。フィールドを使用していない場合、そのフィールドが ASCII 文字列フィールドの場合にはブランク、数値フィールドの場合には 0 になります。コールに追加サービスが含められている場合、エンド コール レコードを追加して書き込むことができます。

CDR エンド コール レコードに加え、エンドポイントごとに 1 つの CMR レコードをコールに含めることができます。それぞれ Cisco IP Phoneを使用した 2 者間の通常コールでは、2 つの CMR レコードが書き込まれます(1 つは発信側、もう 1 つはそのコールの着信側)。

この項では、システム内の各種コール タイプに応じて書き込まれるレコードについて説明します。

通常コール(Cisco IP Phoneと Cisco IP Phone間)

通常コールでは、コールごとに 3 つのレコードをログします。EndCall に各エンドポイント用に 1 つの診断レコードを加えた 3 つのレコードです。EndCall レコードでは、すべてのフィールドに有効な情報を含めることができます。 CdrLogCallsWithZeroDurationFlag フラグが有効(true に設定)でなければ、時間が必ずゼロ以外の数値になります。 originalCalledPartyNumber フィールドには、 finalCalledPartyNumber フィールドと同じ電話番号が含まれます。

放棄されたコール

時間が 0 のコールのロギングは一般的にオプションであり、それらのレコードがログされません。時間が 0 のロギング コールを有効にする場合、次の内容に注意してください。

コールが途中で放棄された場合は(電話がいったんオフフックにされ、またオンフックに戻される場合など)、各種フィールドにはデータは含まれません。この場合、
originalCalledPartyNumber
finalCalledPartyNumber 、それらのフィールドに関連するパーティション、 destIpAddr dateTimeConnect の各フィールドはブランクになります。接続されなかったすべてのコールは、ゼロ秒の 時間 になります。また、コールが放棄されると、理由コールも 0 (ゼロ)になります。

ユーザが電話番号をダイヤルし、接続される前にコールを放棄した場合、 First Dest および Final Dest の各フィールドとそれに関連するパーティションに、コールを拡張している電話番号とパーティションが含まれます。 Dest IP フィールドはブランクに、期間はゼロになります。

転送またはリダイレクトされたコール

転送されたレコードのコール レコードは、通常のコールのコール レコードと同じになります( originalCalledPartyNumber フィールドと originalCalledPartyNumberPartition フィールドは除く)。それらのフィールドには、コールの発信者によってダイヤルされた本来の宛先の電話番号とパーティションが含まれます。コールが転送された場合には、 finalCalledPartyNumber フィールドと finalCalledpartyNumberPartition フィールドが異なり、コールの最後の宛先の電話番号とパーティションが含まれます。さらに、コールが転送されると、 lastRedirectDn フィールドと lastRedirectDnPartition フィールドに、このコールを転送またはリダイレクトした最後の電話の電話番号とパーティションが含まれます。

ビジー状態のコールまたは宛先が間違ったコール

それらのコールは、通常コールとしてログされ、すべての関連フィールドにデータが含まれます。Called Party Cause フィールドには、コールが接続されなかった理由を示す理由コードが含まれ、Called Party IP フィールドと Date/Time Connect フィールドはブランクになります。発信側でコールを放棄した場合、理由は NO_ERROR (0) になります。時間は必ずゼロ秒になります。
CdrLogCallsWithZeroDurationFlag
が有効でなければ、それらのコールはログされません。

コール タイプ別にログされたコール管理レコード

Cisco IP Phone間の通常コールでは、2 つの CMR レコードがログされます。各コールの CMR レコードには、前述で説明したすべてのレコードが含まれます。コールに追加サービスが含まれる場合、複数のレコードに書き込むことができます。この項では、システムにある各種コール タイプに応じて診断レコードが書き込まれる場合について説明します。

通常コール

通常コールでは、コールごとに 2つの CMR レコード、コールに関連する各電話に 1 つの CMR レコードをログされます。現在では、Cisco IP Phoneと MGCP ゲートウェイだけが、診断情報の要求に応答できます。すべてのフィールドには、有効な情報が含まれます。

放棄されたコール

コールが放棄された場合(電話がいったんオフフックにされ、またオンフックに戻される場合など)、ストリーミング データに関連するすべてのフィールドはブランク(ゼロ)になります。このため、ストリーミング接続が確立されないため、データは転送されません。
CdrLogCallsWithZeroDurationFlag
を無効にした場合、ブランク フィールドがあるレコードはログされません。

転送されたコール

転送されたコールのコール レコードは、通常コールのコール レコードと同じです。

ビジー状態のコールまたは宛先が間違っているコール

通常の場合、実際に接続されたコールを表すレコードだけがログされます。宛先が間違っているコールをログするには、 CdrLogCallsWithZeroDurationFlag を有効にする必要があります。有効にした場合、すべてのコールがログされます(電話がオフフックから、またオンフックになった場合も含む)。

コールがログされると、それらのコールは、通常コールとしてログされ、すべての関連フィールドにデータが含まれます。コールが宛先に接続されなかった場合には、ログはコールにつき 1 つのレコードしかありません。そのレコードは、コールの発信側にログされます。

コーデック タイプ(圧縮/ペイロード)

表 6-38 では、各コーデック タイプに対する値を示し、その説明をします。

 

表 6-38 コーデックの説明

コーデック
説明

1

標準外

2

G711A-law 64k

3

G711A-law 56k

4

G711µ-law 64k

5

G711µ-law 56k

6

G722 64k

7

G722 56k

8

G722 48k

9

G7231

10

G728

11

G729

12

G729AnnexA

13

Is11172AudioCap

14

Is13818AudioCap

15

G729AnnexB

32

64k データ

33

56k データ

80

GSM

81

ActiveVoice

82

G726_32K

83

G726_24K

84

G726_16K

理由コード

表 6-39 では、Cause フィールドに表示される理由コードを示します。

 

表 6-39 理由コードの説明

理由コード
説明

0

エラーなし

1

(未割り当て)番号

2

特定の中継ネットワークへのルートがない(米国内使用)

3

宛先へのルートがない

4

特殊情報トーンを送信

5

間違ってダイヤルされたトランク プレフィックス(米国内使用)

6

チャネル受諾が不可

7

確立されているチャネルで受諾され、送達されているコール

8

優先権

9

優先権:再使用に予約された回線

16

通常コールのクリア

17

ユーザ側のビジー

18

ユーザ応答なし

19

ユーザから応答なし(ユーザ アラート)

20

サブスクライバ応答なし

21

拒否されたコール

22

変更された番号

26

選択されていないユーザのクリア

27

宛先の障害

28

無効な番号形式(アドレスが不完全)

29

拒否されたファシリティ

30

STATUS ENQUIRY への応答

31

通常、指定なし

34

無効な回線/チャネル

38

ネットワークの障害

39

固定フレーム モード接続のアウト オブ サービス

40

固定フレーム モード接続(オプション)

41

一時的な障害

42

スイッチ装置の輻輳

43

廃棄されたアクセス情報

44

要求された回線/チャネルが無効

46

ブロックされた優先順位コール

47

無効なリソース、指定なし

49

無効な QOS

50

要求されたファシリティがサブスクライブされていない

53

サービス オペレーション違反

54

禁止された着信コール

55

非公開ユーザ グループ(CUG)で禁止された着信コール

57

許可されていないベアラ機能

58

現在使用できないベアラ機能

62

指定された発信アクセス情報とサブスクライバ クラスの不一致

63

無効なサービスまたはオプション、指定なし

65

実装されていないベアラ機能

66

実装されていないチャネル タイプ

69

実装されていないファシリティの要求

70

制限されたデジタル情報のベアラ機能のみ有効(米国内使用)

79

設定されていないサービスまたはオプション、指定なし

81

無効なコール参照値

82

存在しないチャネルの指定

83

保留されたコールが存在するが、このコール ID がない

84

使用中のコール ID

85

保留されたコールなし

86

クリアされたコール ID をコールが要求している

87

非公開ユーザ グループ(CUG)のメンバーでないユーザ

88

適合しない宛先

90

宛先番号の紛失およびサブスクライブされない DC

91

無効な中継ネットワークの選択(米国内使用)

95

無効なメッセージ、指定なし

96

必須の情報要素の欠落

97

存在しないまたは設定されていないメッセージ

98

メッセージがコール状態と適合しない、またはメッセージ タイプが存在しないか、設定されていない

99

情報要素またはパラメータが存在しないか、実装されていない

100

情報要素の内容が無効

101

メッセージがコール状態に適合しない

102

タイマーの期限が切れる前にコールが終了したため、回復ルーチンが実行されエラーから回復した

103

存在しないまたは実装されていないパラメータ パス(米国内使用)

110

認識されないパラメータがある廃棄されたメッセージ

111

プロトコル エラー、指定なし

126

コール スプリット。これは、Cisco 特有のコードです。コールがスプリットして終了するため(コールは最後に転送されたコールの一部ではない)、転送オペレーション時にコールが終了したときに使用します。これは、転送オペレーションの一部として終了するコールを決定するのに役立ちます。

127

インターワーキング、指定なし

アラーム

アラームは、CDR または 診断データが有効の状態で、データベースにデータを書き込むことができない場合に発行されます。

CDR データの書き込み不可(アラーム番号 1711、重大なアラーム)

データベースをオープンしようとしても、オープンできません。考えられる原因は、次のとおりです。

Cisco CallManager に十分な権限がないため、データベースの書き込みにファイルをオープンできない。Cisco CallManager に書き込み権限が与えられているか確認してください。

パスが設定されていないか、あるいはデータベース用のサーバがダウンしている。