排除RPD DOCSIS吞吐量效能問題

簡介

本檔案介紹如何疑難排解思科遠端PHY裝置(RPD)效能問題。

必要條件

需求

思科建議您瞭解以下主題：

• RPD
• 思科融合式寬頻路由器(cBR)-8
• 有線電纜資料服務介面規範(DOCSIS)

採用元件

本文件所述內容不限於特定軟體和硬體版本。

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。

背景資訊

本文考慮的情況涉及Cisco cBR-8作為融合有線接入平台(CCAP)調配的RPD。精確時間協定(PTP)用於使外部主時鐘與作為輔助時鐘的cBR-8和RPD同步。有關此環境中PTP設計方式的更多資訊，請參閱適用於R-PHY網路的PTP設計建議。

這不是用於排除RPD效能問題的完整步驟清單，儘管這是隔離問題的良好開端。

疑難排解

如果您觀察到RPD部署的效能下降，並且希望執行初始故障排除，則不清楚從何處開始。

本節介紹一些可能導致RPD效能問題的常見問題。

延遲對映消息

當數據機在某個時間點收到MAP消息時，在消息中描述的時隙已經發生之後，發生延遲的上行頻寬分配對映(MAP)消息條件。  數據機無法使用此MAP消息，因此無法傳送所分配授權的任何流量。

幾個延遲的MAP可能導致上游流量速率降低，以及上游ACK延遲導致下游TCP流量速率降低。如果有足夠的延遲MAP，數據機無法執行站台維護並離線。

當您從cBR-8對連線到RPD的數據機執行ping docsis <MAC_ADDR>時，另一個症狀可能是資料包丟棄。

通過遠端PHY(R-PHY),cBR-8將MAP消息傳送到下游外部PHY介面(DEPI)隧道中的數據機，以及傳送到上游外部PHY介面(UEPI)隧道中的RPD。這些消息具有更高的服務品質(QoS)標籤，差分服務代碼點(DSCP)值為46（快速轉發 — EF）。

如果目的地為RPD的MAP消息在CIN中被丟棄，則RPD不能使用這些最小批次並將其計為「未對映」。如果MAP消息遲到RPD，它最初將最小批次計數為未對映，然後在收到遲到MAP後，會增加延遲最小批次計數。

早期MAP也是可能的，但通常只有在cBR-8或RPD的PTP時鐘關閉時才發生。

當MAP消息不按順序出現但只有2毫秒的頻率時，可能會發生重疊MAP，這通常不是問題。MAP消息中的最小批次的實際數量基於每個上游通道的最小批次配置。如果上游使用每微處理器2個計數（通常用於6.4 MHz SC-QAM），則2 ms 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，但最後對映的minislot

提示：從RPD 6.x版中，可以運行show tech-support命令，該命令將收集show upstream map counter和其他命令的多次出現情況，因此對計數器比較很有用。

如果運行RPD軟體版本5.x或更低版本，則可以使用以下可用指令碼運行show tech 命令：Capture show tech on rpd或limited command on both RPD， supervisor。

連結的頁面包含有關如何安裝指令碼和使用示例的說明，您可以在此頁面結尾找到可供下載的Script-Readme.tar檔案。此檔案包含sh_tech_rpd.tcl指令碼和sh_tech_rpd-README.txt檔案，其中包含說明和使用示例。

該指令碼有一個選項(-c)，用於收集文本檔案中列出的另一組命令，同時接受在RPD本身和cBR-8 Supervisor上發出的命令（上述連結和自述檔案中說明的所有步驟）。

有趣的是，此功能也利用此指令碼在包含show tech-support命令的RPD版本中使用。

潛在原因1.CIN延遲、延遲、抖動

連線CCAP核心和RPD的聚合互連網路(CIN)可能會引入延遲，這些延遲必須在MAP提前計時器中考慮。如果CIN中有更改（例如新增了另一台路由器），則可能是引入了更高的延遲。

CCAP使用MAP高級計時器來防止延遲的MAP消息。該計時器以微秒(μs)為單位，可以由操作員按電纜介面靜態配置，也可以由cBR-8動態計算。

動態值是下游時間間隔（680 μs與SC-QAM與256-QAM的間隔）、數據機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。

如果cBR-8和RPD與CIN裝置延遲結合的距離超過網路延遲預設值500μs，則可能產生延遲的MAP消息。

當預設網路延遲參數列示存在問題時，有兩種方法可以處理，這兩種方法都是根據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延遲測量(DLM)的延遲測量功能，該功能確定下游路徑中的單向延遲。

cBR-8傳送帶有其時間戳的DLM資料包，然後RPD在接收到的DLM資料包上標籤其時間戳，並將其轉發回cBR-8。

請注意，Cisco支援所需選項，其中RPD將資料包標籤得最靠近其輸入介面，而不是出口。

cBR-8取最後10個DLM值的平均值，並將其用作MAP高級計算中的網路延遲值。來自cBR-8和RPD的時間戳都基於PTP參考時鐘。

警告：如果PTP不穩定，DLM值以及最終的MAP高級計時器也會不穩定。

預設情況下，DLM處於禁用狀態，可以使用network-delay dlm <seconds>命令啟用它，如下所示。啟用後，DLM資料包將根據配置的值定期傳送到RPD。

還可以新增measure-only選項，該選項只測量CIN延遲，而不調整網路延遲值。

建議在measure-only引數中至少啟用DLM，以便監控CIN延遲。

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能夠及時獲取消息，則可能不會顯示延遲MAP計數）。

可以通過非常低的DLM值、低手動網路延遲或MAP高級安全配置實現低MAP高級計時器。在MAP高級計算中，網路延遲值可以低至30 μs（即使DLM平均值較低）。

建議使用DLM「measure-only」選項或增加動態MAP提前的安全係數，直到MAP提前計時器超過2500 μs。

潛在原因2.軟體錯誤

若要確認軟體錯誤是否導致同步失敗，建議與思科開啟服務要求，以進一步調查特定案例。

當您遇到軟體缺陷時，解決方案通常是將軟體升級至包含修補程式的其中一個版本。由於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直布羅陀版16.10.1c	Cisco 1x2 RPD軟體6.1、6.2、6.3
Cisco IOS® XE直布羅陀版16.10.1d	Cisco 1x2 RPD軟體6.4、6.5、6.7
Cisco IOS® XE直布羅陀版16.10.1f	Cisco 1x2 RPD軟體6.6、6.7
Cisco IOS® XE直布羅陀版16.10.1g	Cisco 1x2 RPD軟體7.1、7.2、7.3、7.4.x、7.5
Cisco IOS® XE直布羅陀版16.12.1	Cisco 1x2 RPD軟體7.1、7.2、7.3、7.4.x、7.5
Cisco IOS® XE直布羅陀版16.12.1w	Cisco 1x2 RPD軟體7.1、7.2、7.3、7.4.x、7.5
Cisco IOS® XE直布羅陀版16.12.1x	Cisco 1x2 RPD軟體7.6、7.7
Cisco IOS® XE直布羅陀版16.12.1y	Cisco 1x2 RPD軟體7.8、7.8.1、8.2
Cisco IOS® XE直布羅陀版16.12.1z	Cisco 1x2 RPD軟體8.3、8.4、8.5
Cisco IOS® XE直布羅陀版17.2.1	Cisco 1x2 RPD軟體8.1、8.2、8.3、8.4、8.5

上游延遲

如上一節所述，長CIN延遲可導致延遲MAP消息問題，並且可以通過MAP提前計時器增加來解決。這反過來會造成更長的請求授權延遲，導致上游延遲增加。

由於穩定的上游流量使用回送請求，因此上游流量速度測試可能看起來正常，並且未請求授權服務(UGS)的語音流量不會受到影響，因為不需要請求。

但是，由於缺少及時的上游ACK，下游TCP流量速度可能會降低。雖然可以解決CIN上的處理和排隊延遲，但這不可能使訊號在給定距離上傳輸得更快。

思科開發了DOCSIS預測排程(DPS)，以減少具有較長CIN延遲的R-PHY應用中的請求授予延遲。DPS根據歷史使用情況主動向數據機提供授權，以最大限度地減少請求授權延遲。

DPS是一種預標準排程方法，類似於最近低延遲DOCSIS(LLD)規範中描述的主動授權服務(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.負載平衡

在某些特殊情況下，例如在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通道）的數據機，將資料包（例如ping）傳送到它，以檢查已傳送的資料包是否與JIB模組計數器上注入的下游流相匹配。確保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.

由於丟包的性質，問題可能出在cBR-8和RPD之間的CIN網路中，需要進一步研究的CIN（例如，瓶頸鍊路、衝突、CRC錯誤）。如果在點3和4中觀察到丟包，建議與Cisco接洽，以便對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具有最高的時鐘優先順序，這意味著一旦配置，PTP甚至用於RF線卡。因此，不可靠的來源將導致整個機箱出現問題。

有關PTP時鐘配置和故障排除的詳細資訊，可以閱讀R-PHY網路的PTP設計建議文章。

擁塞CIN

CIN可以視為CCAP核心的控制平面的擴展，因此，如果給定RPD的下游有1000 Mbps的DOCSIS和影片流量，那麼必須在CIN中分配大量容量，另外還要為DEPI隧道使用的L2TPv3開銷分配一些額外容量。

如果CIN中存在擁塞，則可能會延遲或丟失某些資料包。

潛在原因1.Qos

預設情況下，cBR-8和RPD使用DSCP 46(EF)標籤與PTP流量和MAP消息關聯的資料包。  其他DOCSIS控制消息如上行通道描述符(UCD)、數據機頻寬請求和範圍響應也使用DSCP 46:

專案	每躍點行為(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遠端PHY裝置軟體配置指南

CIN必須具有QoS感知，以便這些高優先順序資料包具有最小延遲。

造成丟包或長隊列延遲的擁塞導致PTP問題、延遲MAP消息和吞吐量降低。通過觀察cBR-8、RPD和CIN裝置上的介面隊列，可以發現這些型別的問題。

如果PTP或MAP消息被丟棄或延遲，如時鐘不穩定或延遲MAP消息所明顯的，則必須解決CIN容量或QoS設計，因為這些消息以高優先順序傳送。

DLM不能處理較短的抖動持續時間，因為最小輪詢週期為一秒，因此在這種情況下不能消除延遲的MAP消息。

潛在原因2.延遲盡力流量

目前，DLM資料包標籤不可配置並使用盡力而為(DSCP 0)。已經出現過CIN出現擁塞的情況，導致長隊列延遲，僅限於盡力流量。

這通常顯示為TCP下游流量速率的降低，因為CIN延遲會由於上游ACK的丟失或延遲而造成相對較大的速度丟棄。

在這種情況下，不會觀察到延遲MAP消息或PTP問題，因為這些高優先順序資料包不會延遲。

由於DLM資料包被標籤為盡力流量，這種型別的CIN抖動會導致DLM值出現峰值。如果使用DLM來動態調整網路延遲，則此抖動會導致MAP預先計時器出現不必要的增加，從而導致上游請求授權延遲增加。

在這種情況下，建議使用靜態網路延遲值。思科還將考慮在未來的版本中啟用DSCP值的選項，而不僅僅是DLM上的盡力服務。這有助於減少上游請求授權延遲，但是如果跨CIN延遲ACK，則可能無法解決TCP吞吐量問題。

相關資訊

• DEPI延遲測量
• 適用於R-PHY網路的PTP設計建議
• 技術支援與文件 - Cisco Systems