RPD DOCSISスループットパフォーマンスの問題のトラブルシューティング

概要

このドキュメントでは、Cisco Remote PHY Device(RPD)のパフォーマンス問題をトラブルシューティングする方法について説明します。

前提条件

要件

次の項目に関する知識があることが推奨されます。

• RPD
• Ciscoコンバージドブロードバンドルータ(cBR)-8
• Data Over Cable Service Interface Specification(DOCSIS)

使用するコンポーネント

このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

背景説明

この記事で考慮するシナリオには、Cisco cBR-8によってConverged Cable Access Platform(CCAP)としてプロビジョニングされるRPDが含まれます。Precision Time Protocol(PTP)は、外部プライマリクロックを、セカンダリとして機能するcBR-8およびRPDと同期するために使用されます。この環境におけるPTP設計の詳細については、『R-PHYネットワークのためのPTP設計の推奨事項』を参照してください。

RPDのパフォーマンスの問題をトラブルシューティングするための包括的な手順のリストではありませんが、問題を切り分けるにはよい方法です。

トラブルシュート

RPDの導入でパフォーマンスの低下が見られ、初期トラブルシューティングを実行する場合、どこから始めればよいのか明確ではありません。

このセクションでは、RPDのパフォーマンスの問題の原因となる可能性がある一般的な問題について説明します。

MAPメッセージの遅延

レイトアップストリーム帯域幅割り当てマップ(MAP)メッセージの状態は、モデムがある時点で、メッセージに説明されているタイムスロットがすでに発生した後にMAPメッセージを受信すると発生します。  モデムはこのMAPメッセージを使用できないため、割り当てられた認可でトラフィックを送信できません。

少数の遅延MAPでは、アップストリームACKが遅延するため、アップストリームトラフィックレートが低下し、ダウンストリームTCPトラフィックレートが低下する可能性があります。十分な遅延MAPがある場合、モデムはステーションメンテナンスを実行できず、オフラインになります。

別の症状として、cBR-8からRPDに接続されたモデムにping docsis <MAC_ADDR>を実行すると、パケットのドロップが発生する場合があります。

リモートPHY(R-PHY)では、cBR-8はダウンストリーム外部PHYインターフェイス(DEPI)トンネルのモデムとアップストリーム外部PHYインターフェイス(UEPI)トンネルのRPDにMAPメッセージを送信します。これらのメッセージは、DiffServコードポイント(DSCP)値が46(Express Forwarding - EF)の、より高いQuality of Service(QoS)マークを持ちます。

RPD宛てのMAPメッセージがCINでドロップされると、RPDはこれらのミニスロットを使用できなくなり、「マッピングなし」としてカウントされます。MAPメッセージがRPDに遅れて到着した場合、最初にミニスロットがマッピングされていないものとしてカウントされ、その後で遅延MAPを受信すると、遅延ミニスロットのカウントが増加します。

早期MAPも可能ですが、通常はcBR-8またはRPDのいずれかでPTPクロックがオフになっている場合にのみ発生します。

オーバーラップMAPは、MAPメッセージがシーケンスから外れた場合に発生する可能性がありますが、2ミリ秒の頻度で発生するため、通常は問題になりません。MAPメッセージ内のミニスロットの実際の数は、各アップストリームチャネルのミニスロット設定に基づきます。アップストリームがミニスロットごとに2つのティックを使用する場合（6.4 MHz SC-QAMで一般的）、2ミリ秒のMAPには160のミニスロットがあります。

RPDでMAPメッセージの遅延が発生しているかどうかを確認するには、次のコマンドを実行してRPDコンソールにアクセスします。次に、コマンドshow upstream map counter <rf port> <channel>を複数回実行し、カウンタ「Discarded minislots (late maps)」が増加するかどうかを確認します。

cbr8# ssh <RPD_IP_ADDR> -l admin
R-PHY>enable
R-PHY#show upstream map counter 0 0
Map Processor Counters
==============================================
Mapped minislots                  :     553309
Discarded minislots (chan disable):          0
Discarded minislots (overlap maps):          0
Discarded minislots (early maps)  :          0
Discarded minislots (late maps)   :          0 <= check if the counter increases
Unmapped minislots                :          0
Last mapped minislot              :   21900956

注：コマンドshow upstream map counterを実行するたびに、すべてのカウンタが0にリセットされますが、最後にマッピングされたミニスロットがリセットされます

ヒント:RPDバージョン6.xからは、show tech-supportコマンドを実行できます。このコマンドは、show upstream map counterコマンドとその他のコマンドの複数のオカレンスを収集するため、カウンタの比較に役立ちます。

RPDソフトウェアバージョン5.x以前を実行している場合は、次の場所で使用可能なスクリプトを使用してshow techコマンドを実行できます。Capture show tech on rpd or limited command on both RPD, supervisor。

リンク先のページには、スクリプトのインストール方法と使用例が記載されています。このページの最後には、ダウンロード可能なScript-Readme.tarファイルがあります。このファイルには、sh_tech_rpd.tclスクリプトとsh_tech_rpd-README.txtファイルが含まれており、手順と使用例が記載されています。

このスクリプトには、テキストファイルにリストされているコマンドの追加セットを収集するためのオプション(-c)があります。RPD自体とcBR-8スーパーバイザで発行されるコマンドの両方が受け入れられます（前述のリンクとreadmeファイルで説明されているすべての手順）。

この機能は、このスクリプトを使用します。興味深いことに、show tech-supportコマンドを含むRPDバージョンでも使用できます。

考えられる原因1.CIN遅延、遅延、ジッター

CCAPコアとRPDをリンクするConverged Interconnect Network(CIN)では、MAPアドバンスのタイマーで考慮する必要がある遅延が発生する可能性があります。別のルータが追加されたなど、CINに変更がある場合は、より大きな遅延が発生している可能性があります。

MAPアドバンスのタイマーは、MAPメッセージの遅延を防ぐためにCCAPによって使用されます。このタイマーはマイクロ秒(μs)に基づいており、オペレータがケーブルインターフェイスごとに静的に設定することも、cBR-8によって動的に計算することもできます。

ダイナミック値は、ダウンストリームタイムインターリーフ（256-QAMのSC-QAMで680 μs）、モデムのMAP処理遅延(600 μs)、CCAP内部ネットワーク遅延(300 μs)、MAPアドバンス安全値（デフォルトでは1000 μs）、および最大モデムタイムオフセット（最も遠いモデムに基づく）の合計です。

R-PHYでは、CCAPの内部遅延がネットワーク遅延（デフォルトは500 μs）に置き換えられています。CIN設計を考慮すると、この値はデフォルトパラメータよりも大きく、時間の経過とともに変更される可能性があります。

アップストリームのMAPアドバンス値は、次のコマンドで表示できます。

cbr8#show controllers upstream-Cable 2/0/5 us-channel 0 cdm-ump
<output omitted>
nom_map_adv_usecs 2899, max_map_adv_usecs 4080 mtn_map_adv 8080
map_adv_alg 1 dyn_map_adv_safety 1000 max_plant_delay 1800
cm_map_proc 600 intlv_delay 680 network_delay 500 max_tmoff 119
<output omitted>

MAPadvance = map_adv_safety (1000) + cm_map_proc (600) + intlv_delay (680) + network_delay (500)+ max_tmoff (119) = 2899 μs。

CINデバイス遅延と組み合わされたcBR-8とRPDの間の距離がネットワーク遅延のデフォルト値である500 μsを超えると、MAPメッセージが遅延する可能性があります。

デフォルトのネットワーク遅延パラメータが問題を示している場合に対処する方法は2つあり、どちらもcBR-8のRPDごとに設定されます。

• 遅延を静的に設定します。
• cBR-8を設定して、遅延を定期的に測定および調整します。

ネットワーク遅延は、次に示すように、cBR-8のRPDごとに静的に設定できます。

cbr8#conf t
cbr8(config)#cable rpd <name>
cbr8(config-rpd)#core-interface <interface_name>
cbr8(config-rpd-core)#network-delay static <CIN_delay_in_us>

動的なネットワーク遅延については、cBR-8はDEPI Latency Measurement(DLM)と呼ばれる遅延測定機能に依存しています。この機能は、ダウンストリームパスでの単方向遅延を決定します。

cBR-8はタイムスタンプ付きのDLMパケットを送信し、RPDは受信時にDLMパケットにタイムスタンプをマークして、cBR-8に転送します。

シスコでは、RPDが出力ではなく入力インターフェイスに最も近いパケットをマークする必須オプションをサポートしています。

cBR-8は最後の10個のDLM値の平均を取得し、それをMAPアドバンス計算のネットワーク遅延値として使用します。cBR-8とRPDの両方のタイムスタンプは、PTP基準クロックに基づいています。

警告:PTPが不安定な場合は、DLMの値と最終的にはMAPアドバンスのタイマーも不安定になります。

デフォルトではDLMは無効になっており、次に示すようにnetwork-delay dlm <seconds>コマンドで有効にできます。有効にすると、DLMパケットは設定された値に従って定期的にRPDに送信されます。

measure-onlyオプションを追加することもできます。このオプションでは、ネットワーク遅延値を調整せずにCIN遅延だけを測定します。

CIN遅延を監視するには、測定のみのパラメータでDLMを少なくとも有効にすることをお勧めします。

cbr8#conf t
cbr8(config)#cable rpd <name>
cbr8(config-rpd)#core-interface <interface_name>
cbr8(config-rpd-core)#network-delay dlm <interval_in_seconds> [measure-only]

Usage:

cbr8#show cable rpd a0f8.496f.eee2 dlm
DEPI Latency Measurement (ticks) for a0f8.496f.eee2
  Last Average DLM:              481
  Average DLM (last 10 samples): 452
  Max DLM since system on:       2436
  Min DLM since system on:       342
  Sample #     Latency (usecs)
  x------------x------------
  0            52
  1            41
  2            48
  3            41
  4            41
  5            44
  6            40
  7            45
  8            44
  9            41

この機能の詳細については、DEPI遅延測定を参照してください。

MAPアドバンスの安全性は、ケーブルインターフェイス設定で手動で変更することもできます(デフォルト値は、安全率が1000 μs、最大マップアドバンスが18000 μsです)。

cbr8#conf t
cbr8(config)#interface Cable1/0/0
cbr8(config-if)# cable map-advance dynamic 1000 18000

OR (if a mac-domain profile is used)

cbr8#conf t
cbr8(config)# cable profile mac-domain RPD
cbr8(config-profile-md)# cable map-advance dynamic 1000 18000

注意:CIN遅延が非常に短い場合も、MAPメッセージの遅延が発生する可能性があります

MAPアドバンスのタイマーが2500 μs未満の場合、アップストリームDOCSISトラフィックのドロップに関して問題が確認されています。

一部のモデムではMAPメッセージの処理に時間がかかり、さらに遅延が発生すると、これらのモデムに対してMAPメッセージが遅れる可能性があります（RPDが時間内にメッセージを取得できた場合、RPDはMAPの遅れカウントを表示しない可能性があります）。

DLM値が非常に低い場合、または手動ネットワーク遅延やMAPアドバンス安全設定が低い場合は、低いMAPアドバンスのタイマーが可能です。MAPアドバンス計算のネットワーク遅延値は、DLMの平均が低くても30 μs程度です。

DLMの「測定のみ」オプションを使用するか、MAPアドバンス・タイマーが2500μsを超えるまでダイナミックMAPアドバンスの安全率を上げることが推奨されます。

考えられる原因2.ソフトウェアの不具合

ソフトウェアの不具合が原因で同期が失敗しているかどうかを確認するには、シスコでサービスリクエストをオープンして、特定のケースをさらに調査することをお勧めします。

ソフトウェアの不具合が発生した場合の解決策は、通常、修正を含むリリースの1つにソフトウェアをアップグレードすることです。cBR-8とRPDソフトウェアリリースには互換性の相関関係があるため、両方のデバイスに適したバージョンを選択することが重要です。

すべてのRPDソフトウェアに適したCisco IOS® XEを選択するには、『Cisco Remote PHY Install and Upgrade Guides』でcBR-8とRPD間のソフトウェアバージョンの互換性を確認できます。

次の表に、cBR-8とRPD間のソフトウェアバージョンの互換性の概要と、このドキュメントの作成時点で使用可能なソフトウェアバージョンを示します。

Cisco cBR-8とCisco RPDのバージョン互換性
Cisco cBR-8リリースバージョン	互換性のあるRPDリリースバージョン
Cisco IOS® XE Everest 16.6.x	Cisco 1x2 RPDソフトウェア2.x
Cisco IOS® XE Fuji 16.7.x	Cisco 1x2 RPDソフトウェア3.x
Cisco IOS® XE Fuji 16.8.x	Cisco 1x2 RPDソフトウェア4.x
Cisco IOS® XE Fuji 16.9.x	Cisco 1x2 RPDソフトウェア5.x
Cisco IOS® XE Gibraltar 16.10.1c	Cisco 1x2 RPDソフトウェア6.1、6.2、6.3
Cisco IOS® XE Gibraltar 16.10.1d	Cisco 1x2 RPDソフトウェア6.4、6.5、6.7
Cisco IOS® XE Gibraltar 16.10.1f	Cisco 1x2 RPDソフトウェア6.6、6.7
Cisco IOS® XE Gibraltar 16.10.1g	Cisco 1x2 RPDソフトウェア7.1、7.2、7.3、7.4.x、7.5
Cisco IOS® XE Gibraltar 16.12.1	Cisco 1x2 RPDソフトウェア7.1、7.2、7.3、7.4.x、7.5
Cisco IOS® XE Gibraltar 16.12.1w	Cisco 1x2 RPDソフトウェア7.1、7.2、7.3、7.4.x、7.5
Cisco IOS® XE Gibraltar 16.12.1x	Cisco 1x2 RPDソフトウェア7.6、7.7
Cisco IOS® XE Gibraltar 16.12.1y	Cisco 1x2 RPDソフトウェア7.8、7.8.1、8.2
Cisco IOS® XE Gibraltar 16.12.1z	Cisco 1x2 RPDソフトウェア8.3、8.4、8.5
Cisco IOS® XE Gibraltar 17.2.1	Cisco 1x2 RPDソフトウェア8.1、8.2、8.3、8.4、8.5

アップストリーム遅延

前のセクションで説明したように、長いCIN遅延はMAPメッセージの遅延の問題を引き起こす可能性があり、MAPアドバンスのタイマーを増やすことで対処できます。その結果、要求と認可の遅延が長くなり、アップストリームの遅延が増加します。

安定したアップストリームトラフィックフローはピギーバック要求を使用するため、アップストリームトラフィック速度テストは正常に見える場合があります。また、Unsolicited Grant Service(UGS)の音声フローは、要求が必要ないため影響を受けません。

ただし、ダウンストリームTCPトラフィック速度は、タイムリーなアップストリームACKの不足により低下する可能性があります。CINでの処理とキューイングの遅延に対処することは可能ですが、信号が一定の距離を超えて高速に伝送されることはあまりありません。

シスコは、より長いCIN遅延を伴うR-PHYアプリケーションでの要求と許可の遅延を削減するために、DOCSIS予測スケジューリング(DPS)を開発しました。DPSは、過去の使用状況に基づいて予防的にモデムに認可を提供し、要求と認可の遅延を最小限に抑えます。

DPSは、最近の低遅延DOCSIS(LLD)仕様で説明されているProactive Grant Service(PGS)に似た事前標準スケジューリング方式です。  ただし、DPSはインターフェイスごとに有効にでき、すべてのベストエフォートアップストリームサービスフローに適用されます。PGSはサービスフロータイプとしてトラフィックに適用されるため、モデムコンフィギュレーションファイルの変更が必要です。

DPSはインターフェイスコマンドcbr8(config-if)#cable upstream dpsで有効にできます。

R-PHYのサポートがcBR-8に追加されて以来、DPSは使用可能になっていましたが、現時点では正式にサポートされている機能ではありません。ただし、DPSは、遅延したACKに関連する低速なTCPダウンストリームスループットを解決するのに効果的です。

Layer 2 Tunneling Protocol(L2TP)パケットの順序が正しくない

RPDコンソールで次のコマンドを複数回入力して、カウンタ「SeqErr-pkts」および「SeqErr-sum-pkts」が正で増加しているかどうかを確認します。これは、L2TPパケットの順序が正しくないことを示します。

R-PHY# show downstream channel counter dpmi
Chan Flow_id SessionId(dec/hex)      Octs       Sum-octs   SeqErr-pkts SeqErr-sum-pkts
0    0       4390912    / 00430000   328        22770      0           1         
0    1       4390912    / 00430000   25074      1179672    0           1         
0    2       4390912    / 00430000   6022168    271459412  0           1         
0    3       4390912    / 00430000   0          0          0           0      

考えられる原因1.ロードバランス

CINでのリンクの輻輳など、特定の状況では、ロードバランスが原因で、宛先でパケットが順不同で受信される問題が発生する可能性があります。

可能性がある場合は、ロードバランスがこの問題を引き起こすかどうかを確認するために、ロードバランスが設定されている単一のパスを強制するようにテストできます。これによりパケット順序が入れ替わる問題が解決した場合は、トリガーの確認が可能で、ネットワークの根本原因をさらに調査できます。

考えられる原因2.パケットドロップ

1. 次に示すようにshow interfaceコマンドを使用して、RPDが接続されているDPICカードインターフェイスのcBR-8カウンタでエラーとドロップが増加していないかを確認します。

cbr8#sh run | s cable rpd SHELF-RPD0
cable rpd SHELF-RPD0
 description SHELF-RPD0
 identifier a0f8.496f.eee2
[…]
 core-interface Te6/1/2
[…]
cbr8#show interface Te6/1/2
TenGigabitEthernet6/1/2 is up, line protocol is up
  Hardware is CBR-DPIC-8X10G, address is cc8e.7168.a27e (bia cc8e.7168.a27e)
  Internet address is 10.27.62.1/24
  MTU 1500 bytes, BW 10000000 Kbit/sec, DLY 10 usec,
     reliability 255/255, txload 90/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full Duplex, 10000Mbps, link type is force-up, media type is SFP_PLUS_10G_SR
  output flow-control is on, input flow-control is on
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:01, output 00:00:05, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/375/0/22 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 1002000 bits/sec, 410 packets/sec
  5 minute output rate 3535163000 bits/sec, 507528 packets/sec
     88132313 packets input, 26831201592 bytes, 0 no buffer
     Received 0 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 229326 multicast, 0 pause input
     179791508347 packets output, 164674615424484 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     13896 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 pause output
     0 output buffer failures, 0 output buffers swapped out

2. RPD側で、インターフェイスおよびダウンストリームカウンタにエラー、ドロップ、および順序の正しくないパケットが存在するかどうかを確認します。

R-PHY#show interface info
eth0      Link encap:Ethernet  HWaddr A0:F8:49:6F:EE:E4
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::a2f8:49ff:fe6f:eee4/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:303 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:44034 (43.0 KiB)
          Memory:1ae2000-1ae2fff
vbh0      Link encap:Ethernet  HWaddr A0:F8:49:6F:EE:E2
          inet addr:10.7.62.7  Bcast:10.7.62.255  Mask:255.255.255.0
          inet6 addr: fe80::a2f8:49ff:fe6f:eee2/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1174200 errors:0 dropped:0 overruns:0 frame:0
          TX packets:593404 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:90888838 (86.6 MiB)  TX bytes:52749774 (50.3 MiB)
vbh1      Link encap:Ethernet  HWaddr A0:F8:49:6F:EE:E3
          inet6 addr: fe80::a2f8:49ff:fe6f:eee3/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:2438 (2.3 KiB)

R-PHY#show downstream channel counter

------------------- Packets counter in TPMI -------------------

Level     Rx-pkts    Rx-sum-pkts
Node Rcv  4673022    2108792873
Depi Pkt  1696       774495

Port Chan SessionId(dec/hex)    Rx-pkts    Rx-sum-pkts
DS_0 0    4390912    /0x00430000 49032      22125274
DS_0 1    4390913    /0x00430001 49025      22116541
[…]
US_0 0    13893632   /0x00D40000 12193      5502543
US_0 1    13893633   /0x00D40001 12193      5501739
[…]

Port      Rx-pkts    Rx-sum-pkts Drop-pkts  Drop-sum-pkts
DS_0      3095440    1396529318  0          0
US_0      49215      22207507    0          0
US_1      0          4679        0          0

------------------- Packets counter in DPMI -------------------

Field        Pkts       Sum-pkts
Dpmi Ingress 12275995   1231753344
Pkt Delete   0          0
Data Len Err 0          0

Chan Flow_id SessionId(dec/hex)      Octs       Sum-octs   SeqErr-pkts SeqErr-sum-pkts
0    0       4390912    / 0x00430000   75         130496     0           1
0    1       4390912    / 0x00430000   15657      7208826    0           1
0    2       4390912    / 0x00430000   3181212    1431951867 0           1
0    3       4390912    / 0x00430000   0          0          0           0
[…]

------------------- Packets counter in DPS -------------------

Chan Tx-packets Tx-octets  Drop-pkts  Tx-sum-pkts Tx-sum-octs Drop-sum-pkts
0    50316      3273636    0          22126173    1439340721  0
1    50311      3272896    0          22117442    1438506648  0
2    50311      3272640    0          22121500    1438772715  0
3    50309      3272640    0          22122038    1438807607  0
[…]

3. ダウンストリームのInterLakenカウンタを複数回チェックして、エラーが発生しているかどうか、およびカウンタが増加しているかどうかを確認します。これを行うには、次に示すように、ラインカードのコンソールインターフェイスを入力する必要があります。

cbr8#request platform software console attach 6/0
#
# Connecting to the CLC console on 6/0.
# Enter Control-C to exit the console connection.
#
Slot-6-0>enable
Slot-6-0#
Slot-6-0#test jib4ds show ilkstat ?
  <0-3>  ILK Link (0-BaseStar0, 1-BaseStar1, 2-Cpu0, 3-Cpu1)

Slot-6-0#test jib4ds show ilkstat 0
Send Show-ilkstat IPC to CDMAN...Wait for output

Slot-6-0#
Jib4DS InterLaken Stats for BaseStar 0:
                    RX-Packets             RX-Bytes            TX-Packets             TX-Bytes
HUB Stats:         10425879607       14415939325556              75237425           8249683443
Chan    0:             4714787            360160866                109750             36594720
Chan    1:         10254597081       14397444921888                     0                    0
Chan    3:               63828             17214818                     0                    0
Chan    5:           166503829          18117169182              75127675           8213088761
PRBS  Err:                   0                    0                     0                    0
CRC32 Err:                   0                    0                     0                    0
CRC24 Err:                          0
Test-pattern-err:                   0

ILK Error log: ptr 0
Idx      Err1     Err2      Rst     Gtx0     Gtx1     Gtx2     Gtx3

Slot-6-0#

4. このRPDに接続されたモデム（DSチャネルボンディングのみ）を使用して、送信されたパケットがJIBモジュールカウンタに挿入されたダウンストリームフローと一致するかどうかを確認するために、RPDにパケット（pingなど）を送信します。DS JIBがラインカードコンソールでDEPIフレームのすべてのDSデータパケットを送信したことを確認します。この出力では、モデムサービスフローの出力からパケットシーケンス番号を確認する方法を示しています。このシーケンス番号は、送信されるデータパケットごとに増加します。

Slot-6-0#show cable modem 2cab.a40c.5ac0 service-flow verbose | i DS HW Flow
DS HW Flow Index			: 12473
Slot-6-0#test jib4ds show flow 12473
Send Show-FLOW IPC to CDMAN flow 12473 seg 6...Wait for output

Slot-6-0#
Jib4DS Show Flow: [Bufsz 4400]: HW Flow id:12473 [0x30b9] for segment 0
Valid        : TRUE
DSID         :            3 [       0x3]
Priority     :            0
Bonding Group:           62 [      0x3e]
Channel      :        65535 [    0xffff]
DS-EH        :            3 [       0x3]
Data Prof 1  :            0 [         0]
Data Prof 2  :            0 [         0]
No Sniff Enabled.

Slot-6-0#test jib4ds show dsid 3
Send Show-DSID 3 10 IPC to CDMAN...Wait for output

Slot-6-0#

Jib4DS DSID entry for DSID 3 [Bufsz 4400]:
SCC Bit         = 0x0
Sequence Number = 8

別のウィンドウで、cBR-8コマンドラインからこのモデムにpingを送信します。

cbr8#ping 10.0.0.3 rep 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 4/7/27 ms
cbr8#

テスト後のデルタを確認します。

Slot-6-0#test jib4ds show dsid 3
Send Show-DSID 3 10 IPC to CDMAN...Wait for output

Slot-6-0#

Jib4DS DSID entry for DSID 3 [Bufsz 4400]:
SCC Bit         = 0x0
Sequence Number = 108

テスト後にデルタを計算します。カウンタは16ビット符号なしカウンタです。そのため、カウンタがロールオーバーする場合は、次の式でデルタを計算する必要があります。

(Initial Sequence Number + Number of Packets Sent) % 65536

例：

Initial Sequence Number = 50967

Final Sequence Number = 2391

Packets sent: 1000000




(50967+1000000)%65536 = 2391 <== Good, no packet was dropped before DEPI frame.

ドロップの性質の結果として、問題はCINにある可能性があります（たとえば、ボトルネックリンク、コリジョン、CRCエラー）。この問題は、cBR-8とRPD間のCINネットワークでさらに調査する必要があります。代わりにポイント3と4でドロップが見られる場合は、cBR-8の詳細な調査のためにシスコに連絡することを推奨します。

PTPの損失または定期的なロック解除

ご存知のとおり、PTPは通常のRPD動作に不可欠です。したがって、PTPパケットはQoSにおいて高い優先度を持つ必要があり、PTPパケットのドロップは良い兆候ではありません。

RPDコンソールで、PTP統計情報を表示し、カウンタ「DELAY REQUEST」と「DELAY RESPONSE」が厳密に一致していることを確認できます。代わりに大きなギャップが見られる場合は、ネットワーク内のPTPドロップを示している可能性があります。

R-PHY#show ptp clock 0 statistics
 AprState    4  :
           2@0-00:06:25.877          1@0-00:06:16.234          0@0-00:03:42.629
           4@0-00:03:23.428
ClockState  5  :
           5@0-00:07:02.932          4@0-00:06:59.145          3@0-00:06:55.657
           2@0-00:06:26.657          1@0-00:06:25.834
BstPktStrm  1  :
           0@0-00:03:21.014
SetTime     1  :
  1000000000@0-00:03:24.776
StepTime    1  :
  -560112697@0-00:05:39.401
AdjustTime  44 :
          -8@0-00:52:03.776         -5@0-00:51:02.776          4@0-00:50:01.776
          -6@0-00:49:00.776         11@0-00:47:59.776          1@0-00:45:57.776
           5@0-00:44:56.776         -7@0-00:43:55.776        -22@0-00:42:54.776
streamId  msgType           rx          rxProcessed     lost        tx
0        SYNC              47479       47473           0           0
0        DELAY REQUEST     0           0               0           47473
0        P-DELAY REQUEST   0           0               0           0
0        P-DELAY RESPONSE  0           0               0           0
0        FOLLOW UP         0           0               0           0
0        DELAY RESPONSE    47473       47473           0           0
0        P-DELAY FOLLOWUP  0           0               0           0
0        ANNOUNCE          2974        2974            0           0
0        SIGNALING         34          34              0           32
0        MANAGEMENT        0           0               0           0
  TOTAL                    97960       97954           0           47505

注:cBR-8では、PTPはクロックに対して最も高いプライオリティを持ちます。つまり、いったん設定されると、RFラインカードにも使用されます。したがって、信頼性の低いソースはシャーシ全体に問題を引き起こします。

PTPクロックの設定とトラブルシューティングの詳細については、『R-PHYネットワークのためのPTP設計の推奨事項』を参照してください。

CINうっ血

CINはCCAPコアのコントロールプレーンの拡張と見なすことができます。そのため、特定のRPDのダウンストリームに1000 MbpsのDOCSISおよびビデオトラフィックがある場合、その容量をCINに割り当て、さらにDEPIトンネルによって使用されるL2TPv3オーバーヘッド用の追加の容量を割り当てる必要があります。

CINで輻輳が発生している場合、一部のパケットは遅延または損失する可能性があります。

考えられる原因1.QoS

デフォルトでは、cBR-8とRPDは、PTPトラフィックとMAPメッセージに関連付けられたパケットをDSCP 46(EF)でマーキングします。  アップストリームチャネル記述子(UCD)、モデム帯域幅要求、範囲応答などのその他のDOCSIS制御メッセージも、DSCP 46を使用します。

項目	Per-Hop-Behavior(PHB)	DSCP 値
DOCSISデータ(L2TP)	ベスト エフォート	0
PTP	EF	46
GCP	ベスト エフォート	0
MAP/UCD（L2TP、DOCSIS制御）	EF	46
BWRおよびRNG-REG	EF	46
ビデオ	CS4	32
MDD（L2TP、DOCSIS制御）、音声	CS5	40

出典：Cisco 1x2/コンパクトシェルフRPDソフトウェア5.x用Cisco Remote PHYデバイスソフトウェアコンフィギュレーションガイド

CINはQoSを認識する必要があるため、優先度の高いパケットの遅延は最小限に抑えられます。

パケットのドロップや長いキュー遅延を引き起こす輻輳により、PTPの問題、MAPメッセージの遅延、およびスループットの低下が発生しています。これらのタイプの問題は、cBR-8、RPD、およびCINデバイスのインターフェイスキューを観察することで確認できます。

PTPまたはMAPメッセージがドロップまたは遅延した場合（クロックの不安定性や遅延したMAPメッセージで明らかになる）、CIN容量またはQoS設計に対処する必要があります。これは、これらが高い優先順位で送信されるためです。

最小ポーリングサイクルは1秒であるため、DLMは短いジッタ期間を処理するようには設計されていません。したがって、この場合はMAPメッセージの遅延を解消できません。

考えられる原因2.遅延したベストエフォートトラフィック

現在、DLMのパケットマークは設定できず、ベストエフォート(DSCP 0)を使用します。CINで輻輳が発生し、長いキューの遅延がベストエフォートトラフィックに限定される場合があります。

これは通常、TCPダウンストリームトラフィックレートの低下として示されています。これは、CINの遅延により、アップストリームACKの損失または遅延が原因で比較的大きな速度のドロップが発生する可能性があるためです。

この場合、遅延したMAPメッセージやPTPの問題は発生しません。これは、これらの高優先度パケットが遅延しないためです。

DLMパケットはベストエフォートトラフィックとしてマークされるため、このタイプのCINジッタはDLM値の急上昇を引き起こす可能性があります。DLMを使用してネットワーク遅延を動的に調整する場合、このジッタによってMAPアドバンスのタイマーが不必要に増加し、アップストリームの要求と認可の遅延が増加する可能性があります。

この場合は、スタティックネットワーク遅延値を使用することを推奨します。シスコでは、将来のリリースでDLMでベストエフォート以外のDSCP値を有効にするオプションも検討しています。これはアップストリームの要求と許可の遅延を減らすのに役立ちますが、ACKがCIN全体で遅延している場合は、TCPスループットの問題に対処できない可能性があります。

関連情報

• DEPI遅延測定
• R-PHYネットワークに関するPTP設計の推奨事項
• テクニカル サポートとドキュメント – Cisco Systems