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

はじめに

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

前提条件

要　件

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

• RPD
• Ciscoコンバージドブロードバンドルータ(cBR)-8
• データオーバーケーブルサービスインターフェイス仕様(DOCSIS)

使用するコンポーネント

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

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

バックグラウンド情報

この記事で検討するシナリオには、Converged Cable Access Platform(CCAP)としてCisco cBR-8によってプロビジョニングされるRPDが含まれます。 高精度時間プロトコル(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メッセージを送信します。これらのメッセージは、Differentiated Services Code Point(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>コマンドを複数回実行し、カウンタ「廃棄されたミニスロット（遅延マップ）」が増加するかどうかを確認します。

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以前を実行する場合は、Capture show tech on rpd or limited command on both RPD, supervisorのスクリプトを使用してshow techコマンドを実行できます。

リンク先のページには、スクリプトのインストール方法および使用例が記載されています。このページの最後には、ダウンロード可能な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)と呼ばれる遅延測定機能を利用します。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に送信されます。

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

CINの遅延を監視するために、measure-onlyパラメータで少なくとも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、max map advanceが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では、時間内にメッセージを取得できた場合、MAPカウントの遅延は表示されない可能性があります）。

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

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

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

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

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

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

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

アップストリーム遅延

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

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

ただし、ダウンストリームTCPトラフィック速度は、タイムリーなアップストリームACKの欠如により低下する可能性があります。CINでの処理とキューイングの遅延に対処することは可能ですが、特定の距離での信号の移動を高速化することはほとんどありません。

シスコは、より長いCIN遅延を伴うR-PHYアプリケーションの要求許可遅延を減らすために、DOCSIS Predictive Scheduling(DPS)を開発しました。DPSは、使用履歴に基づいて予防的にモデムに認可を提供し、要求/認可の遅延を最小限に抑えます。

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

DPSをイネーブルにするには、インターフェイスコマンドcbr8(config-if)#cable upstream dps

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

レイヤ2トンネリングプロトコル(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.Load Balance

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モジュールカウンタで挿入されたダウンストリームフローと一致するかどうかを確認するために、パケット（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の詳細な調査のためにCiscoに協力を依頼することを推奨します。

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が使用されます。したがって、信頼性の低い発信元はシャーシ全体に問題を引き起こします。

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を使用します。

出典：Cisco 1x2 / コンパクトシェルフRPDソフトウェア5.x用Cisco Remote PHY Device Software Configuration Guide

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

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

クロックの不安定性やMAPメッセージの遅延で明らかなように、PTPまたはMAPメッセージがドロップまたは遅延した場合、CINのキャパシティまたはQoSの設計に対処する必要があります。これらは高い優先度で送信されるためです。

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

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

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

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

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

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

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

関連情報

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