- このマニュアルについて
- Broadband Access Center for Cable の概要
- Broadband Access Center for Cable システム アーキテクチャ
- 設定のワークフローとチェックリスト
- DOCSIS 設定
- PacketCable 音声設定
- CableHome の設定
- データベース管理
- 管理者のユーザ インターフェイスにつ いて
- Broadband Access Center for Cable 管理者のユーザ インターフェイスの使 用方法
- Broadband Access Center for Cable の設定
- サンプル ユーザ インターフェイスの 設定および使用方法
- Broadband Access Center for Cable がサポートするツールと高度な概念
- アラートとエラー メッセージ
- PacketCable DHCP オプションと BACC プロパティのマッピング
- Broadband Access Center for Cable のアプリケーション プログラミング インターフェイスの使用例
- 用語集
- 索引
Cisco Broadband Access Center for Cable アドミニストレータ ガイド Release 2.7
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年5月30日
章のタイトル： DOCSIS 設定
DOCSIS 設定
この章では、BACC DOCSIS の配備を運用に移すためにチェックまたは設定する必要のある機能を示します。また、設定に先立って必要な情報を説明し、使用可能なツールについて説明します。
•
「ダイナミック DOCSIS テンプレートによる MIB の使用方法」
（注） この BACC リリースでサポートされる DOCSIS オプションについては、「DOCSIS オプションのサポート」を参照してください。
DOCSIS ワークフロー
DOCSIS プロビジョニングの仕様に含まれるプロビジョニング（ワークフロー）手順を図4-1 に示します。
表4-1 は、図4-1 に示されるさまざまな DOCSIS プロビジョニング手順で発生する可能性がある問題について説明します。
ダイナミック DOCSIS テンプレートによる MIB の使用方法
BACC に付属する MIB の完全なリストについては、「SNMP Varbind」を参照してください。
RDU にロードされる DOCSIS MIB には、2 つのバージョンがあります。
• DOCS-CABLE-DEVICE-MIB-OBSOLETE（実験的ブランチ）
• DOCS-CABLE-DEVICE-MIB（mib2 ブランチ）
これらの使用方法については、「DOCSIS MIB」を参照してください。
API の呼び出しを使用するか、rdu.properties を修正することにより、MIB を追加することができます。詳細については、「Euro-PacketCable の MIB の設定」を参照してください。
使用可能な MIB がないときに SNMP TLV をテンプレートに追加することができます。詳細については、「MIB を使用しない SNMP TLV の追加」を参照してください。
DOCSIS 設定のための BACC 機能
この項では、DOCSIS テクノロジーと関連する BACC の付加価値機能について説明します。
動的設定 TLV
これらの TLV は、動的 DOCSIS 設定の TFTP 要求が受け取られるたびに、DPE によって追加されます。
• TLV 19（TFTP Server Timestamp。オプション）：Configure DOCSIS Defaults ページに TFTP Time Stamp オプションとして表示されます。詳細については、表10-5を参照してください。この TLV では CMTS および DPE における NTP の同期が必要です。
• TLV 20（TFTP Server Provisioned Modem Address。オプション）：Configure DOCSIS Defaults ページに TFTP Modem Address Option として表示されます。詳細については、表10-5を参照してください。
• TLV 6（CM MIC Configuration Setting。必須）
• TLV 7（CMTS MIC Configuration Setting。必須）：Configure DOCSIS Defaults ページに CMTS Shared Secret として表示されます。詳細については、表10-5を参照してください。
（注） CMTS MIC を設定するときは、次の CMTS IOS リリースの依存関係に注意してください。
• TLV 39 または TLV 40 を含める場合、DOCSIS 2.0 CMTS MIC には CMTS IOS 12.3BC が必要です。
• 次の CMTS IOS コマンドが BACC によって設定されているものとします。
–ip dhcp relay information option
–no ip dhcp relay information check
–cable helper-address <x.x.x.x>
DPE TFTP IP 検証
DPE TFTP サーバは動的設定ファイルを対象に、TFTP クライアントの IP アドレスが DOCSIS ケーブル モデムの予期した IP アドレスに一致することを確認します。一致しない場合、要求は破棄されます。この機能に Cisco CMTS DMIC 機能との互換性はありません。
TFTP の動的構成要求における要求者の IP アドレスの検証をディセーブルにするには、次の no tftp verify-ip コマンドを使用します。
DOCSIS 1.0、1.1、2.0 のサポート
BACC 2.7 では DOCSIS 1.0、1.1、および 2.0 がサポートされます。BACC によって各 DOCSIS バージョンでサポートされる TLV およびオプションの詳細については、 第 12 章「Broadband Access Center for Cable がサポートするツールと高度な概念」 を参照してください。
BACC では、ケーブル モデムの DOCSIS バージョンを着信 DHCP 要求から検出することができます。また、GIADDR から DOCSIS バージョン番号へのマッピングを行う任意の顧客提供ソースから CMTS DOCSIS バージョンを検出することもできます。
DOCSIS バージョンは設定ファイル ユーティリティに指定できます。詳細については、「設定ファイル ユーティリティの使用方法」を参照してください。
DOCSIS バージョンに基づいた DOCSIS 設定ファイル
デフォルトの DOCSIS コード生成の拡張では、モデムをプロビジョニングするための DOCSIS バージョンを使用して、モデムに送信する DOCSIS 設定ファイルのファイル名を決定します。
次の新しいサービス クラス プロパティが、管理者のユーザ インターフェイスおよび BACC API でサポートされます。
DOCSIS 設定ファイル名を特定の DOCSIS バージョンと関連付けるために、これらのプロパティをオプションで DOCSIS サービス クラスに追加することができます。これらの各プロパティ（設定した場合）により、既存の DOCSIS 設定ファイル名プロパティで行われるように、サービス クラスとプロパティ値で指定されたファイルとの間に RDU によってデータベース関係を確立できます。
DOCSIS ネットワークのトラブルシューティング
共有 HFC ネットワーク全体にトール品質音声、データ サービス、およびマルチメディア アプリケーションを提供するために必要な帯域幅および遅延が DOCSIS によって保証されます。下位互換性があるように設計されているため、DOCSIS 1.0、1.1、および 2.0 モデムは同一ネットワークの同一スペクトラムで動作することができます。
（注） この項の大部分は、BACC および Cisco uBR7246 CMTS に関する DOCSIS テクノロジーの説明です。例は Cisco uBR7246 CMTS のものですが、その内容は他の CMTS ベンダーがサポートしなければならない DOCSIS 規格に関連しています。
ネットワーク層以上の設定
レンジングが正常に行われた後、動作するサポート サーバからケーブル モデムに追加の設定を行う必要があります。サーバから提供および設定されるサービスの集まりを Operational Support Services（OSS; オペレーション サポート サービス）と呼びます。
（注） この時点でモデムは機能しています。モデムは、ブリッジのように動作してかなり高速な伝送デバイスとなることもありますが、管理者の設定、診断、サービス クラス、セキュリティ、プライバシー、またはリモート ソフトウェア アップグレードの機能がないため、DOCSIS には準拠しません。
DHCP 状態の確立
MAC State --->>> 'establish_dhcp_state'
cmWriteFlashFile("CM_MACCONFIG", 0x8313db6, 0x12e) by TID 0x82eb0f8 (tConfigNV)
usrEraseSysFlash(1, 0x1e0400, 0x12e) by TID 0x82eb0f8 (tConfigNV)
.........cmWriteFlashFile("CM_DHCPLEASE", 0x810ebe4, 0x24) by TID 0x82d825c (tLease-0)
usrEraseSysFlash(1, 0x1e0200, 0x24) by TID 0x82d825c (tLease-0)
OSS の設定における最初のタスクは、DHCP によるネットワーク設定の取得です。ブロードキャスト DHCP DISCOVER メッセージがモデムによって発行されます。通常、ブロードキャスト メッセージはルータによって転送されませんが、UDP プロトコルの集合（このうちの 1 つが DHCP）に対しては、転送されるようにルータを設定することができます。DHCP サーバが DISCOVER に対して OFFER で応答すると、モデムはオファーされた設定の REQUEST を送信するように選択できます。
DHCP サーバは ACK（確認応答）または NAK（否定応答）で応答します。互換性のない IP アドレスとゲートウェイ アドレスの結果として NAK が返される場合があります。これは、モデムがあるダウンストリーム チャネルから別のサブネット上のダウンストリーム チャネルにホップした場合に発生する可能性があります。モデムがリースの更新を求めると、DHCP REQUEST メッセージの IP アドレスおよびゲートウェイ アドレスではネットワーク番号が異なり、DHCP サーバは REQUEST を NAK で拒否します。このような事態はまれで、モデムはリースを解放し DHCP DISCOVER メッセージからやり直します。
establish_dhcp_state マニフェストでは NAK でなくタイムアウトでエラーとなることがよくあります。効率的にトラブルシューティングするには、次の手順に従います。
• DHCP ログから DHCP サーバを診断する前に、モデムを調査する。
また、上記のレンジングでログ マスク 0xffff00bf を使用すると、モデムの始動時に発生する可能性があるほぼすべての問題をトラブルシューティングするのに役立ちます。これは、始動時エラーのトラブルシューティングを開始するのに最適です。DHCP メッセージの順序は、DISCOVER、OFFER、REQUEST、ACK でなければなりません。DHCP サーバから OFFER 応答がない状態でモデムが DISCOVER を送信している場合は、次のコマンドを使用して、uBR の UDP デバッグをオンにしてください。
（注） telnet セッションか、コンソール セッション以外のセッションを介してルータに接続している場合にデバッグ メッセージを表示するには、terminal monitor コマンド（省略形は term mon）が必要です。term mon をオフにするには、term no mon コマンドを使用するか、ログアウトします。
デバッグ メッセージの中にパケットが現れない場合、このモデムの接続先であるケーブル インターフェイスで ip helper-address 文の設定をチェックします。この文が正しく設定されていて、DHCP サーバのサブネットのパケット トレースでもモデムから DHCP パケットが送信されていないことが判明したら、モデムのケーブル インターフェイスの出力エラーを確認するか、または uBR のケーブル インターフェイスの入力エラーを確認します。減衰を高めてトランスミッタの電力を少し上げることも得策です。
パケットが DHCP サーバのサブネットに送信されている場合には、パラメータの要求エラーや割り当てエラーがないかどうかをモデムのデバッグ メッセージで再度チェックします。この段階のトラブルシューティングでは、モデムと DHCP サーバ間のルーティングを調査する必要があります。また、DHCP サーバの設定を再度チェックすることもお勧めします。
ToD 状態の確立
MAC State --->>> 'establish_tod_state'
モデムは、ネットワーク パラメータを取得した後に、Time Of Day（TOD; 時刻）サーバの時刻を要求する必要があります。TOD は UTC タイムスタンプ（1970 年 1 月 1 日からの秒数）を使用します。DHCP からのタイム オフセット オプション値を組み合せると、現在時刻を計算できます。時刻は、syslog とイベント ログのタイムスタンプに使用されます。
時刻のエラーは、ほとんどの場合、DHCP の設定に誤りがあることを示しています。TOD エラーにつながる設定の誤りには、IP アドレスやゲートウェイ アドレスの誤設定、間違った TOD サーバ アドレスがあります。モデムが保存した DHCP パラメータを次のコマンドを使用して調べ、再度トラブルシューティングをローカルで開始します。
セキュリティ アソシエーション状態
MAC State --->>> 'security_association_state'
これは、まだ定義されていない状態のためのプレースホルダーです。セキュリティ サーバとのセキュリティ アソシエーションによってモデムに IPsec のようなセキュリティが提供されることを想定しています。その設計および実装はまだ検討中です。その間、DOCSIS 1.0 ではこの状態について、セキュリティ サーバ用の DHCP オプションを含む将来の定義をモデムでサポートするように求めています。この状態が DOCSIS で定義されてモデムに実装されるまで、この状態に関する問題がモデムで発生することはまずありません。
設定ファイル状態
CM に対する設定および管理の主要インターフェイスは、プロビジョニング サーバからダウンロードした設定ファイルです。この設定ファイルには、ダウンストリーム チャネルとアップストリーム チャネルの識別情報および特性に加え、サービス クラス設定、ベースライン プライバシー設定、全般的な運用設定、ネットワーク管理情報、ソフトウェア アップグレード フィールド、フィルタ、およびベンダー固有の設定が含まれます。
この状態で起こる障害の一般的な理由としては、ファイルの欠落、ファイル アクセス権の誤り、TFTP サーバにアクセスできない、ファイル形式の誤り、ファイルに必須オプションがない、必須オプションの誤設定、オプションの誤りなどがあります。たとえば、不明な TLV または無効な TLV などです。
設定ファイルのトランザクションおよび解析を行うデバッグ コマンドを次に示します。
登録状態
MAC State --->>> 'registration_state'
設定後に、モデムは必要な設定のサブセットと共に登録要求（REG-REQ）を送信し、CM と CMTS の Message Integrity Check（MIC; メッセージの完全性チェック）も送信します。CM の MIC は設定ファイルの設定をハッシュ計算した結果であり、設定ファイルが中継時に改ざんされなかったことをモデムが確認する手段を提供します。CMTS の MIC も類似していますが、共有秘密情報の認証文字列用の設定も含まれます。この共有秘密情報は CMTS およびプロビジョニング サーバによって認識され、認証されたプロビジョニング サーバによって設定されたモデムだけが CMTS への登録を許可されることを保証します。
登録状態に関する問題は、ほとんどの場合、設定ファイルにエラーがあることを示しています。モデムと CMTS の両方で設定ファイルの設定がサポートされていることを確認してください。CMTS でサービス クラス プロファイルの作成が許可されていることを確認するか、または CMTS によって作成されたプロファイルを使用します。CMTS のケーブル インターフェイス設定および設定ファイルで、認証文字列を確認してください。
プライバシー状態の確立
MAC State --->>> 'establish_privacy_state'
次のすべての条件を満たす場合、モデムは Baseline Privacy Key Management プロトコルを介して CMTS とのベースライン プライバシーのネゴシエーションを行う必要があります。
• モデム ソフトウェアがベースライン プライバシーをサポートしている。
• サービス クラスが、プライバシーの有効なプロファイルである。
• ベースライン プライバシー設定が設定ファイルに存在する。
この状態で発生するエラーの原因として考えられるのは、設定ファイルの誤りです。CM と CMTS の両方でベースライン プライバシーがサポートされていることと、CMTS のインターフェイス設定および CM の設定ファイルでベースライン プライバシーが有効になっていることを確認してください。
暗号化のエクスポート制限によるエラーが発生する可能性もあります。一部のベンダーのモデムでは uBR7246 のインターフェイス設定で次のコマンドが必要になることがあります。
動作状態
MAC State --->>> 'operational_state' cmWriteFlashFile("CM_BOOT", 0x8109180, 0x13e) by TID 0x83049b8 (tMACCtrl)
usrEraseSysFlash(1, 0x1e0900, 0x13e) by TID 0x83049b8 (tMACCtrl)
登録およびベースライン プライバシー ネゴシエーション（必要な場合）が正常に行われると、モデムは動作状態となり、トラフィックを受け渡す準備ができます。
モデムは動作可能になりますが、動作状態を維持しない場合があります。これは、同期の損失や DHCP リース更新の障害などによって発生する可能性があります。
ケーブル モデムの状態のトラブルシューティング
この項では、次のケーブル モデムの状態について取り上げます。
• 「レンジング プロセス：init(r1)、init(r2)、および init(rc) 状態」
• 「online、online(d)、online(pk)、online(pt) 状態」
• 「reject(pk) および reject(pt) 状態」
オンライン状態
この項では、ケーブル モデムの オンライン状態 について説明し、この状態で示される Radio Frequency（RF; 無線周波数）問題などをトラブルシューティングする方法について説明します。
（注） ここで扱う問題の多くは、すべてではありませんが RF に関連する問題です。Cisco uBR7246VXR とそのドメインにある CM との問題をトラブルシューティングする一般的な方法を理解するには、この項を参照してください。
Cisco uBR7246VXR で最初に使用する最も便利なコマンドは show cable modem です。
Online State フィールドは状態を表します。状態は、 表 4-2 のいずれかになります。
|
|
|
|---|---|
ケーブル モデムが登録を試行したが、不正な Class of Service（COS; サービス クラス）により、登録は拒否された。 |
オフライン状態
場合によっては、ケーブル モデムが他の状態を循環してから、オフラインに戻ることがあります。ケーブル モデムで Quadrature Amplitude Modulation（QAM; 直交振幅変調）ロックが失敗する最も一般的な理由を次に示します。
• DOCSIS ファイルで指定されている周波数が正しくない。
• ダウンストリームのデジタル QAM 変調信号が存在しない。
• Cisco uBR7246VXR の cable modem change-frequency で指定されている周波数が正しくない。
次に示すのは、モデムで入力された show controllers cable-modem 0 の出力結果の一部です。
BCM Cable interface 0:
CM unit 0, idb 0x8086C88C, ds 0x8086E460, regaddr = 0x2700000, reset_mask 0x80
station address 0030.96f9.65d9 default station address 0030.96f9.65d9
PLD VERSION: 1
Concatenation: ON Max bytes Q0: 2000 Q1: 2000 Q2: 2000 Q3: 2000
MAC State is ds_channel_scanning_state, Prev States = 3
MAC mcfilter 01E02F00 data mcfilter 00000000
MAC extended header ON
DS: BCM 3300 Receiver: Chip id = BCM3300
US: BCM 3300 Transmitter: Chip id = 3300
Tuner: status=0x00
Rx: tuner_freq 529776400, symbol_rate 5361000, local_freq 11520000
snr_estimate 166(TenthdB), ber_estimate 0, lock_threshold 26000
QAM not in lock, FEC not in lock, qam_mode QAM_64 (Annex B)
Tx: tx_freq 27984000, symbol rate 8 (1280000 sym/sec)
power_level: 6.0 dBmV (commanded)
7 (gain in US AMP units)
63 (BCM3300 attenuation in .4 dB units)
上の出力例で Signal to Noise ratio（SNR; 信号対雑音比）の推定値は 16.6 dB です。CM が 64 QAM で正常に動作するための適切な値は 30 dB 以上です。DOCSIS のダウンストリームおよびアップストリームの信号については、RF 仕様を参照してください。場合によっては、良好な SNR（34 dB など）が得られているのに、インパルス ノイズなどのノイズが存在することがあります。これは、ゼロスパン モードで動作するスペクトル アナライザを使用しないと検出できません。インパルス ノイズを示すものとして、修正できないエラーがあります。このエラーは、次に示すように show interfaces cable 2/0 upstream 0 の出力結果に出現します。
Cable2/0: Upstream 0 is up
Received 46942 broadcasts, 0 multicasts, 205903 unicasts
0 discards, 12874 errors, 0 unknown protocol
（注） 値が 10,000 分の 1 を超えていれば、インパルス ノイズが存在すると考えられます。
252845 packets input, 1 uncorrectable
12871 noise, 0 microreflections Total Modems On This Upstream Channel : 3 (3 active)
Default MAC scheduler
Queue[Rng Polls] 0/64, fifo queueing, 0 drops
Queue[Cont Mslots] 0/104, fifo queueing, 0 drops
Queue[CIR Grants] 0/64, fair queueing, 0 drops
Queue[BE Grants] 0/64, fair queueing, 0 drops
Queue[Grant Shpr] 0/64, calendar queueing, 0 drops
Reserved slot table currently has 0 CBR entries
Req IEs 77057520, Req/Data IEs 0
Init Mtn IEs 1194343, Stn Mtn IEs 117174
Long Grant IEs 46953, Short Grant IEs 70448
Avg upstream channel utilization : 1%
Avg percent contention slots : 96%
Avg percent initial ranging slots : 4%
Avg percent minislots lost on late MAPs : 0%
Total channel bw reserved 0 bps
CIR admission control not enforced
Current minislot count : 7192093 Flag: 0
Scheduled minislot count : 7192182 Flag: 0
CM での最適な入力電力レベルは 0 dBmV であり、レシーバの範囲は -15 dBmv ～ +15 dBmV です。この値はスペクトル アナライザで測定できます。電力レベルが低すぎる場合は、『 Cisco uBR 7246 Hardware Installation Guide 』の指示に従って、アップコンバータを設定しなければならないことがあります。信号レベルが強すぎる場合は、高周波ポート接続でさらに減衰を加えることが必要な場合もあります。特定の周波数でノイズが多すぎる場合は、スペクトラム内で別の周波数の選択が必要になることがあります。
CM で QAM ロックが失敗しているかどうかを確認するには、 debug cable-modem mac log verbose をオンにします。次のような出力結果が表示されます。
CM で QAM ロックが失敗する別の理由として、アップコンバータで設定されたダウンストリーム中心周波数が正しくない場合があります。たとえば、北米の標準 6 MHz チャネル帯域に対応した National Television Systems Committee（NTSC）周波数マップによれば、中心周波数が 651 MHz のチャネル 100-100 は 648.0 ～ 654.0 を使用しています。しかし、ビデオ キャリア周波数で動作するように設計されたアップコンバータを使用している場合（たとえば、中心周波数よりも 1.75 MHz 低い周波数を使用する GI C6U など）、チャネル 100-100 では周波数を 649.25 MHz に設定する必要があります。
よくある別の誤りとして、Cisco Broadband Configurator（cisco.com からのダウンロードで入手可能）の Radio Frequency Info の下にある Downstream Frequency フィールドで正しくない周波数を指定することがあります。通常、このオプションで周波数値を指定する必要はありません。ただし、必要な場合（特定のモデムを異なる周波数でロックしなければならないときなど）には、前述のように適切な周波数値を選択する必要があります。次のデバッグ出力は、この場合を示しています。ここで、CM は初期状態で 453 MHz にロックされ、その後 DOCSIS 設定ファイルで指定された 535.25 MHz にロックされます。これによってケーブル モデムはリセットされ、このプロセスが無限に繰り返されます。
Cisco uBR7246VXR 上の cable modem change-frequency で指定された周波数が正しくない場合にも、CM で周波数の切り替えが発生します。ルータで設定された周波数が正しく選択されていなければ、上記と同様の結果になります。Cisco uBR7246VXR の cable modem change-frequency コマンドはオプションで、通常はデフォルトで省略されます。
ダウンストリーム チャネルの取得および遅延の計算が完了すると、次のタスクとして適切なアップストリーム チャネルの特定が行われます。ケーブル モデムは、アップストリーム チャネルの物理的なプロパティが含まれる Upstream Channel Descriptor（UCD; アップストリーム チャネル ディスクリプタ）を受信します。プロパティには、バースト ディスクリプタに定義されている周波数、変調、チャネル幅、およびその他のパラメータなどがあります。
ケーブル モデムが使用可能な UCD を見つけられない場合、そのモデムはアップストリーム サービスの提供されていないダウンストリーム チャネル上にある可能性があります。これは、ルータの設定に誤りがあるものと考えられます。この場合は、 show controller cable x コマンドを使用して確認できます。ケーブル モデムが使用可能な UCD を見つけられない別の理由としては、そのハードウェアまたは MAC がバースト ディスクリプタ内のパラメータをサポートしていないことが考えられます。これは、Cisco uBR7246VXR の設定に誤りがあるか、CM が DOCSIS に準拠していない可能性があります。
使用可能な UCD が見つかると、ケーブル モデムは MAP（帯域幅割り当てマップ）メッセージの受信を開始します。MAP にはアップストリームの帯域幅割り当て時間マップが含まれています。時間のセクションが各ミニスロットにマッピングされ、個々のモデムに割り当てられます。MAP には、ブロードキャスト、コンテンションベースの初期メンテナンス（またはブロードキャスト）レンジング用の領域もあります。ケーブル モデムは、Cisco uBR7246VXR がレンジング応答
（RNG-RSP）で応答するまで、MAP のこれらの領域にモデム自体の初期レンジング要求を送信する必要があります。
T2 タイマーが切れる前に CM が初期メンテナンス領域を見つけられない場合は、Cisco
uBR7246VXR の設定に誤りがないかどうかを確認してください。また、ルータのケーブル インターフェイスの insertion-interval も確認する必要があります。
レンジング プロセス：init(r1)、init(r2)、および init(rc) 状態
この段階では、CM はレンジング プロセスを開始し、適切な入力電力レベルで Cisco uBR7246VXR に到達するために必要な伝送電力レベルを計算します。通常良好とされる伝送電力は、およそ 40 ～ 50 dBmV です（uBR7246 入力電力が 0 dBmV である場合に基づく）。この値は、ハードウェアによっては異なる場合もあります。ダウンストリーム チャネルと同様に、アップストリーム チャネル内のキャリアも、Cisco uBR7246VXR レシーバがシンボルを識別できてビット誤り率が増加するほど高くない十分な強さを持つ必要があります。
CM はレンジング要求（RNG-REQ）メッセージを Cisco uBR7246VXR に送り、レンジング応答（RNG-RSP）メッセージが送り返されてくるか、または T3 タイマーが切れるのを待ちます。T3 のタイムアウトが発生した場合は、リトライ回数が増します。リトライ回数がリトライ最大回数よりも少なければ、ケーブル モデムはより高い電力レベルで別の RNG-REQ を送信します。レンジング プロセスは MAP の初期メンテナンス領域またはブロードキャスト領域で発生します。これは、Cisco uBR7246VXR が、MAP 内のユニキャスト送信に使用する Service Identifier（SID; サービス ID）をまだモデムに割り当てていないためです。このため、ブロードキャスト レンジングはコンテンション ベースとなり、コリジョンの影響を受けます。これを補正するため、ケーブル モデムは RNG-REQ 送信の間のランダムなバックオフ時間を計算するためのレンジング バックオフ アルゴリズムを備えています。このアルゴリズムは、 cable upstream range-backoff コマンドを使用して設定できます。伝送電力が Cisco uBR7246VXR に対して十分なレベルに達すると、Cisco uBR7246VXR は一時的な SID を含む RNG-RSP で RNG-REQ に応答します。この SID は、ユニキャスト レンジングで使用される MAP 内のユニキャスト送信領域の識別に使用されます。
次の出力は、init(r1) 状態にある CM が初期レンジング段階を完了できないことを示しています。
|
|
|
Offset |
Power |
|
|
|
|
|
|
|
12.00
|
|
0
|
|
|
次のデバッグは、CM がレンジング プロセスの完了に失敗して T3 タイマー切れとなり、リセットされる状況を示しています。Cisco uBR7246VXR が CMAC_LOG _ADJUST_TX_POWER メッセージを送信し、CM に対して電力を調整するよう指示を出していることがわかります。
次のコマンドにより、CM での伝送電力の状況を確認できます。
BCM Cable interface 0:
CM unit 0, idb 0x2010AC, ds 0x86213E0, regaddr = 0x800000, reset_mask 0x80
station address 0050.7366.2223 default station address 0050.7366.2223
PLD VERSION: 32
MAC State is wait_for_link_up_state, Prev States = 2
MAC mcfilter 00000000 data mcfilter 00000000
MAC extended header ON
DS: BCM 3116 Receiver: Chip id = 2
US: BCM 3037 Transmitter: Chip id = 30AC
Tuner: status=0x00
Rx: tuner_freq 0, symbol_rate 5055932, local_freq 11520000
snr_estimate 30640, ber_estimate 0, lock_threshold 26000
QAM not in lock, FEC not in lock, qam_mode QAM_64
Tx: tx_freq 27984000, power_level 0x20 (8.0 dBmV), symbol_rate 8 (1280000 sym/s)
ケーブル モデムがレンジング状態から先に進めない場合は、伝送電力レベルが十分でないことが原因と考えられます。低周波ポートで減衰を調整することにより伝送電力を調整できます。減衰を増やすと、結果的に伝送電力レベルが上昇します。20 ～ 30 dBmV の減衰から始めることをお勧めします。
初期レンジング init(r1) の後、ケーブル モデムは init(r2) に進みます。init(r2) では、ケーブル モデムからの送信が正しいタイミングで受信され、その送信が Cisco uBR7246VXR レシーバでの入力電力レベルの許容範囲に収まるようにするため、ケーブル モデムは送信のタイミング オフセットと電力レベルを設定する必要があります。この設定はユニキャストの RNG-REQ および RNG-RSP メッセージのやり取りを通じて実行されます。RNG-RSP メッセージには、ケーブル モデムで実行しなければならない電力およびタイミング オフセットの訂正値が含まれています。
ケーブル モデムは、RNG-RSP メッセージでレンジングの成功が示されるか、または init(rc) 状態への到達によってレンジングが完了するまで RNG-REQ を送信し続け、RNG-RSP ごとに調整を実行します。ケーブル モデムが init (r2) から先に進めない場合は、伝送電力を調整する必要があります。init(r2) 状態の CM の出力表示を次に示します。Rec Power 列の隣にある アスタリスク（*） 記号は、ノイズ電力調整機構がこのモデムでアクティブになっていることを示しています。 感嘆符（!） が表示された場合は、ケーブル モデムが最大伝送電力に達したことを意味します。
|
|
State |
Offset |
Power |
|
|
|
|
|
|
|
|
|
|
|
|
|
DHCP：init(d) 状態
レンジングが成功すると、次の段階として DHCP によるネットワーク設定の取得が行われます。
次の show cable modem の出力表示は、ケーブル モデムが init(d) 状態にあること、つまり DHCP 要求を CM から受信したことを示しています。
|
|
State |
Offset |
Power |
|
|
|
|
|
|
|
|
|
|
|
|
|
CM は init(r1) から init(d) までの状態を無限に循環することに注意してください。考えられる原因を次に示します。
• Cisco uBR7246VXR から DHCP サーバへの IP 接続性に関する問題。
• 間違ったデフォルト ゲートウェイが DHCP サーバで設定されている。
（注） Cisco uBR7246VXR から DHCP サーバに PING を実行することはできますが、DHCP に正しくないゲートウェイが設定されるという問題は起こる可能性があります。これは、DHCP は Cisco uBR7246VXR ケーブル インターフェイスのプライマリ IP アドレスに応答できますが、DHCP ディスカバリ フェーズでソース IP アドレスとして使用されるセカンダリ IP アドレスには応答できないためです。
DHCP 状態のマニフェストでエラーが NAK ではなくタイムアウトとして現れることがよくあります。DHCP メッセージの順序は、DISCOVER、OFFER、REQUEST、ACK でなければなりません。DHCP サーバから OFFER 応答がない状態でケーブル モデムが DISCOVER を送信している場合は、次のコマンドを使用して、Cisco uBR7246VXR の UDP デバッグ をオンにしてください。
デバッグ メッセージの中にパケットが現れない場合、このモデムの接続先であるケーブル インターフェイスで cable helper-address 文の設定をチェックします。この文が正しく設定されていて、DHCP サーバのサブネットのパケット トレースでもケーブル モデムから DHCP パケットが送信されていないことが判明したら、モデムのケーブル インターフェイスの出力エラーを確認するか、または Cisco uBR7246VXR のケーブル インターフェイスの入力エラーを確認します。減衰を高めて CM のトランスミッタの電力を少し上げることも得策です。
DHCP サーバのサブネットに送信されているパケットがあれば、パラメータの要求エラーや割り当てエラーがないかどうかをモデムのデバッグ メッセージでチェックします。この段階のトラブルシューティングでは、CM と DHCP サーバ間のルーティングを調査する必要があります。また、DHCP サーバの設定や DHCP のログについても再度チェックします。
CM で debug cable-modem mac log verbose コマンドを実行して得られたデバッグ例を次に示します。
DHCP：init(i) 状態
DHCP 要求への応答を受信して IP アドレスがケーブル モデムに割り当てられると、次の show cable modem コマンドで出力される状態は init(i) になります。
|
Sid |
State |
Offset |
Power |
|
|
|
|
|
|
|
|
|
|
|
|
|
上の結果では、CM が init(i) 状態から先に進んでいません。 show cable modem を繰り返し実行すると、一般にケーブル モデムは init(r1)、init(r2)、init(rc)、init(d) および init(i) の間を無限に循環します。
ケーブル モデムが init(i) から先に進まない理由として、よくある原因を次に示します。
• DHCP サーバで指定されている DOCSIS ファイルが正しくないか、または無効である。
• TFTP サーバの問題。IP アドレスが正しくない、TFTP サーバが到達不能であるなど。
• TOD またはタイミング オフセットの取得に関する問題。
ケーブル モデムは init(i) までは到達しているので、IP アドレスの取得までは完了していることがわかります。このことは、次に示すケーブルモデムでの debug cable-modem mac log verbose コマンドの出力表示からわかります。
同様に、TFTP サーバに関する問題でも同じようなエラーが見られ、結果としてケーブル モデムがリセットされて同じプロセスを無限に循環することになります。
Time of Day（TOD; 時刻）またはタイミング オフセットの取得に関する問題がある場合も、ケーブル モデムはオンライン ステータスに達しません。
（注） Cisco IOS バージョン 12.1(1) よりも前のバージョンでは、ケーブル モデムをオンラインにするために、TOD を DHCP サーバで指定する必要がありました。しかし、Cisco IOS バージョン 12.1(1) 以降では TOD は必要ありません。ただし、ケーブル モデムでは、次に示すように引き続きタイミング オフセットを取得する必要があります。
次のデバッグではタイム サーバを指定していませんが、DHCP サーバでタイミング オフセットを設定しているので、ケーブル モデムはオンラインになります。
DHCP サーバで Router オプション設定を含めなかったり、Router オプション フィールドで無効な IP アドレスを指定したりした場合にも、ケーブル モデムが init(i) 状態から先に進まなくなります。これを次の debug cable-modem mac log verbose の出力結果に示します。
TOD 交換：init(t) 状態
モデムは、ネットワーク パラメータを取得した後に、Time Of Day（TOD; 時刻）サーバの時刻を要求する必要があります。TOD は UTC タイムスタンプ（1970 年 1 月 1 日からの秒数）を使用します。DHCP からのタイム オフセット オプション値を組み合せると、現在時刻を計算できます。時刻は、syslog とイベント ログのタイムスタンプに使用されます。
次の例では、SID 1 および 2 のモデムが init(t) 状態にあります。Cisco IOS バージョン 12.1(1) よりも後の IOS では、TOD 交換に失敗した場合でもケーブル モデムがオンラインになります。次の show cable modem コマンドの出力結果を参照してください。
時刻のエラーは、ほとんどの場合、DHCP の設定に誤りがあることを示しています。TOD エラーにつながる設定の誤りには、次のものがあります。
タイム サーバへの PING を実行して、IP 接続性の問題がないこと、およびタイム サーバが使用可能であることを確認してください。
オプション ファイル転送開始：init(o) 状態
ケーブル モデムに対する設定および管理の主要インターフェイスは、プロビジョニング サーバからダウンロードした設定ファイルです。この設定ファイルには、ダウンストリーム チャネルとアップストリーム チャネルの識別情報および特性に加え、サービス クラス設定、ベースライン プライバシー設定、全般的な運用設定、ネットワーク管理情報、ソフトウェア アップグレード フィールド、フィルタ、およびベンダー固有の設定が含まれます。
ケーブル モデムが nit(o) 状態から先に進まない場合、通常は、ケーブル モデムが設定ファイルのダウンロードを開始したか、ダウンロードの準備ができているものの、ダウンロードが成功しなかったことを示しています。これには次の理由が考えられます。
• DOCSIS 設定ファイルが正しくない、壊れている、または見つからない。
• TFTP サーバが使用できないか IP 接続性がないため、TFTP サーバに到達できない。
• DOCSIS ファイル内の構成パラメータが無効であるか、または見つからない。
状態として必ずしも init(o) が示されるとは限らず、init(i) の後に init(r1) から init(i) までが循環することもあるので注意してください。より正確な状態を判断するには、 show controller cable-modem 0 mac state の出力を表示します。
MAC State:
|
configuration_file_state
|
Ranging SID:
|
4
|
Registered:
|
FALSE
|
Privacy Established:
|
FALSE
|
show cable modem の出力に init(o) が表示されるときに debug cable-modem mac log verbose を実行しても、設定ファイルが壊れているのか、または TFTP サーバの障害が原因なのかはわかりません。このデバッグはこれらの両方を指摘しています。
Cisco Broadband Configurator（cisco.com からのダウンロードで入手可能）における無効な構成パラメータの例として、ベンダー ID やベンダー固有情報が無効または見つからないことが挙げられます。この場合、次の出力表示と類似した結果になります。
online、online(d)、online(pk)、online(pt) 状態
次の状態は、ケーブル モデムがオンライン ステータスに達して、データの送受信が可能になったことを示します。
一方、online(d) は、ケーブル モデムがオンラインになったものの、ネットワーク アクセスが拒否されたことを示します。
online(d) になる原因は、通常、Cisco Broadband Configurator（cisco.com からのダウンロードで入手可能）の Radio Frequency info の下にある Network Access オプションが無効になっているためです。Network Access はデフォルトでは 有効 になっています。このことは、上の show cable modem の出力と、次の debug cable-modem mac log verbose の出力で確認できます。
また、ケーブル モデムで show controllers cable-modem 0 mac state の出力を調べて確認することもできます。
online とは、ケーブル モデムがオンラインになり、Cisco uBR7246VXR と通信できるようになったことを意味します。Baseline Privacy Interface（BPI; ベースライン プライバシー インターフェイス）が有効でない場合、ケーブル モデムの初期化は成功したとみなし、オンライン ステータスはデフォルト状態となります。BPI が設定されている場合には、ステータス online(pk) が表示されてから、そのすぐ後に online(pt) が表示されます。次のデバッグ出力表示は、ケーブル モデム側で debug cable-modem mac log verbose コマンドを使用して得られた出力のうち、登録に関する部分だけを示しています。
一般に、BPI に問題がある場合は、鍵認証の段階を通過できなかったことを示す reject(pk) が表示されます。この状態については、reject(pk) および reject (pt) の項で取り上げています。
BPI を正常に機能させるため、必ず Cisco uBR7246VXR とケーブル モデムの両方で BPI 対応イメージを実行してください。BPI 対応イメージ名には記号 K1 が含まれています。
また、Cisco Broadband Configurator（cisco.com からのダウンロードで入手可能）の Class of Service オプションの下で、必ず Baseline Privacy Enable フィールドに 1 を設定してください。Cisco uBR7246VXR では BPI 対応イメージを実行していて、ケーブル モデムでは実行していない場合、Cisco Broadband Configurator で BPI を有効にすると、ケーブル モデムが online と offline の間を循環します。
reject(pk) および reject(pt) 状態
次に示す Cisco uBR7246VXR での show cable modem の出力は、reject(pk) 状態を示しています。
|
Sid |
State |
Offset |
Power |
|
|
|
|
|
|
|
|
|
|
|
|
|
BPI の設定に問題があると、多くの場合、reject(pk) 状態が表示されます。一般に、この状態は次の原因によって起こります。
• 認証要求に含まれる CM の公開鍵が壊れている。イベントの正しい順序については、サンプルの debug cable privacy を参照してください。
• cable privacy authenticate-modem 設定コマンドが CMTS ルータには存在するが、RADIUS サーバには存在しない。
Reject(pt) は、通常、無効な Traffic Encryption Key（TEK; トラフィック暗号化鍵）が原因となって起こります。Cisco uBR7246VXR の debug cable privacy を使用した出力表示を次に示します。
02:32:08: 0x0000: 30 68 02 61 00 DA BA 93 3C E5 41 7C 20 2C D1 87
02:32:08: 0x0010: 3B 93 56 E1 35 7A FC 5E B7 E1 72 BA E6 A7 71 91
02:32:08: 0x0020: F4 68 CB 86 A8 18 FB A9 B4 DD 5F 21 B3 6A BE CE
02:32:08: 0x0030: 6A BE E1 32 A8 67 9A 34 E2 33 4A A4 0F 8C DB BD
02:32:08: 0x0040: D0 BB DE 54 39 05 B0 E0 F7 19 29 20 8C F9 3A 69
02:32:08: 0x0050: E4 51 C6 89 FB 8A 8E C6 01 22 02 34 C5 1F 87 F6
02:32:08: 0x0060: A3 1C 7E 67 9B 02 03 01 00 01
02:32:08: RSA public Key subject:
02:32:08: 0x0000: 30 7C 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01 05
02:32:08: 0x0010: 00 03 6B 00 30 68 02 61 00 DA BA 93 3C E5 41 7C
02:32:08: 0x0020: 20 2C D1 87 3B 93 56 E1 35 7A FC 5E B7 E1 72 BA
02:32:08: 0x0030: E6 A7 71 91 F4 68 CB 86 A8 18 FB A9 B4 DD 5F 21
02:32:08: 0x0040: B3 6A BE CE 6A BE E1 32 A8 67 9A 34 E2 33 4A A4
02:32:08: 0x0050: 0F 8C DB BD D0 BB DE 54 39 05 B0 E0 F7 19 29 20
02:32:08: 0x0060: 8C F9 3A 69 E4 51 C6 89 FB 8A 8E C6 01 22 02 34
02:32:08: 0x0070: C5 1F 87 F6 A3 1C 7E 67 9B 02 03 01 00 01
02:32:08: RSA encryption result = 0
02:32:08: RSA encrypted output:
02:32:08: 0x0000: B6 CA 09 93 BF 2C 05 66 9D C5 AF 67 0F 64 2E 31
02:32:08: 0x0010: 67 E4 2A EA 82 3E F7 63 8F 01 73 10 14 4A 24 ED
02:32:08: 0x0020: 65 8F 59 D8 23 BC F3 A8 48 7D 1A 08 09 BF A3 A8
02:32:08: 0x0030: D6 D2 5B C4 A7 36 C4 A9 28 F0 6C 5D A1 3B 92 A2
02:32:08: 0x0040: BC 99 CC 1F C9 74 F9 FA 76 83 ED D5 26 B4 92 EE
02:32:08: 0x0050: DD EA 50 81 C6 29 43 4F 73 DA 56 C2 29 AF 05 53
認証が失敗したときのケーブル モデムでのデバッグ出力例を次に示します。
同様に、Cisco uBR7246VXR での debug cable privacy は次のエラーを示します。
02:47:00: CMTS Received AUTH REQ.
02:47:00: Sending KEK REJECT.
02:47:05: %UBR7200-5-UNAUTHSIDTIMEOUT: CMTS deleted BPI unauthorized Cable Modem 0030.96f9.65d9
（注） ケーブル モデムは reject(pk) から init(r1) までを無限に循環し続けます。
これ以外に発生する可能性があるエラーとしては、暗号化のエクスポート制限によるものがあり、一部のベンダーのモデムでは Cisco uBR7246VXR のインターフェイス設定で次のコマンドが必要になることがあります。
登録：reject (m) 状態
設定後に、ケーブル モデムは必要な設定のサブセットと共に登録要求（REG-REQ）を送信し、ケーブル モデムと uBR7246 の Message Integrity Check（MIC; メッセージの完全性チェック）も送信します。ケーブル モデムの MIC は設定ファイルの設定をハッシュ計算した結果であり、設定ファイルが中継時に改ざんされなかったことをケーブル モデムが確認する手段を提供します。Cisco uBR7246VXR の MIC も類似していますが、cable shared-secret 認証文字列用の設定も含まれる点で異なります。この共有秘密情報は Cisco uBR7246VXR およびプロビジョニング サーバによって認識され、プロビジョニング サーバによって認証されたケーブル モデムだけがルータへの登録を許可されることを保証します。
reject(m) 状態となるケーブル モデムには、不正な MIC があります。これは、通常、次の理由によって発生します。
• ケーブル インターフェイスのもとで設定された cable shared-secret と、Cisco Broadband
Configurator（cisco.com からダウンロード可能）の Miscellaneous オプションの下にある CMTS Authentication 値が一致しない。
問題を修正するには、設定ファイルが有効であることを確認し、 CMTS Authentication の値と、ケーブル インターフェイスの cable shared-secret <line> で設定されている値が同一であることを確認してください。また、Cisco uBR7246VXR でサービス クラス プロファイルの作成が許可されていることを確認するか、あるいは Cisco uBR7246VXR によって作成されたプロファイルを使用します。
登録：reject (c) 状態
ケーブル モデムは、不正な Class of Service（COS; サービス クラス）が原因で登録に失敗すると、reject(c) 状態になります。通常は次の原因で起こります。
• uBR7246 が要求された特定の COS を与えることができない、または与えようとしない。
• Cisco Broadband Configurator（cisco.com からのダウンロードで入手可能）の Class of Service オプションにあるパラメータの設定が間違っている。たとえば、同じ ID を持つサービス クラスが 2 つあるなど。
ケーブル モデム側で得られた次の debug cable-modem mac log verbose の出力結果は、不正な COS が原因で登録に失敗したことを示しています。
同様に、Cisco uBR7246VXR での debug cable registration は次の内容を出力します。
CMTS registration debugging is on
sniper#
1d04h: %UBR7200-5-CLASSFAIL: Registration failed for Cable Modem 0001.9659.4461 on interface Cable2/0/U0:
Bad/Missing Class of Service Config in REG-REQ
フィードバック