排除RPD DOCSIS吞吐量性能问题
下载选项
非歧视性语言
此产品的文档集力求使用非歧视性语言。在本文档集中，非歧视性语言是指不隐含针对年龄、残障、性别、种族身份、族群身份、性取向、社会经济地位和交叉性的歧视的语言。由于产品软件的用户界面中使用的硬编码语言、基于 RFP 文档使用的语言或引用的第三方产品使用的语言，文档中可能无法确保完全使用非歧视性语言。 深入了解思科如何使用包容性语言。
关于此翻译
思科采用人工翻译与机器翻译相结合的方式将此文档翻译成不同语言，希望全球的用户都能通过各自的语言得到支持性的内容。 请注意：即使是最好的机器翻译，其准确度也不及专业翻译人员的水平。 Cisco Systems, Inc. 对于翻译的准确性不承担任何责任，并建议您总是参考英文原始文档（已提供链接）。
目录
简介
本文档介绍如何对思科远程PHY设备(RPD)性能问题进行故障排除。
先决条件
要求
Cisco 建议您了解以下主题：
- RPD
- 思科融合宽带路由器(cBR)-8
- 有线数据服务接口规范(DOCSIS)
使用的组件
本文档不限于特定的软件和硬件版本。
本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。
背景信息
本文所考虑的场景包括Cisco cBR-8作为融合有线接入平台(CCAP)调配的RPD。Precision时间协议(PTP)用于将外部主时钟与cBR-8和RPD同步，后者作为辅助时钟使用。有关此环境中PTP设计的详细信息，请参阅R-PHY网络的PTP设计建议。
这不是用于排除RPD性能问题的完整步骤列表，尽管这是隔离问题的良好开端。
故障排除
如果您观察到RPD部署的性能下降，并且希望执行初始故障排除，则不清楚从何处开始。
本节介绍可能导致RPD性能问题的某些常见问题。
最近的MAP消息
当调制解调器在某个时间点收到MAP消息时，在消息中描述的时隙已经发生之后，会出现延迟的上行带宽分配映射(MAP)消息情况。 调制解调器无法使用此MAP消息，因此无法在分配的授权上发送任何流量。
由于上游ACK延迟，一些延迟MAP可能导致上游流量速率降低，以及下游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消息中的实际微时隙数取决于每个上行信道的minislot配置。如果上行链路每微时隙使用两个计时（通常用于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，但Last mapped 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管理引擎上发出的两个命令（前面提到的链接和自述文件中解释的所有过程）。
有趣的是，此功能还使用此脚本在包含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数据包时将其时间戳标记在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.软件 Bug
为了验证软件Bug是否导致同步故障，建议向思科提交服务请求，以进一步调查特定案例。
如果遇到软件缺陷，解决方案通常是升级到包含修复程序的其中一个版本。由于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之间的版本兼容性 |
|
| 思科cBR-8发行版本 |
兼容的RPD发行版本 |
| 思科IOS® XE Everest 16.6.x |
思科1x2 RPD软件2.x |
| 思科IOS® XE Fuji 16.7.x |
思科1x2 RPD软件3.x |
| 思科IOS® XE Fuji 16.8.x |
思科1x2 RPD软件4.x |
| 思科IOS® XE Fuji 16.9.x |
思科1x2 RPD软件5.x |
| 思科IOS® XE直布罗陀16.10.1c |
思科1x2 RPD软件6.1、6.2、6.3 |
| 思科IOS® XE直布罗陀16.10.1d |
思科1x2 RPD软件6.4、6.5、6.7 |
| 思科IOS® XE直布罗陀16.10.1f |
思科1x2 RPD软件6.6、6.7 |
| 思科IOS® XE直布罗陀16.10.1g |
Cisco 1x2 RPD软件7.1、7.2、7.3、7.4.x、7.5 |
| 思科IOS® XE直布罗陀16.12.1 |
Cisco 1x2 RPD软件7.1、7.2、7.3、7.4.x、7.5 |
| 思科IOS® XE直布罗陀16.12.1w |
Cisco 1x2 RPD软件7.1、7.2、7.3、7.4.x、7.5 |
| 思科IOS® XE直布罗陀16.12.1x |
思科1x2 RPD软件7.6、7.7 |
| 思科IOS® XE直布罗陀16.12.1y |
思科1x2 RPD软件7.8、7.8.1、8.2 |
| 思科IOS® XE直布罗陀16.12.1z |
思科1x2 RPD软件8.3、8.4、8.5 |
| 思科IOS® XE直布罗陀17.2.1 |
思科1x2 RPD软件8.1、8.2、8.3、8.4、8.5 |
上游延迟
如上一节所述，长CIN延迟会导致延迟MAP消息问题，并且可以通过MAP提前计时器增加来解决。这反过来又会造成更长的请求授权延迟，从而导致上游延迟增加。
由于稳定的上行流量使用回送请求，因此上行流量速度测试可能看起来正常，并且未经请求的授权服务(UGS)的语音流量不会受到影响，因为不需要请求。
但是，由于缺少及时的上游ACK，下游TCP流量速度可能会降低。虽然可以解决CIN上的处理和队列延迟，但不可能使信号在给定距离内传输得更快。
思科开发了DOCSIS预测调度(DPS)，以减少R-PHY应用中CIN延迟较长时的请求授予延迟。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.丢包
- 使用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
- 检查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
[…]
- 多次检查下游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#
- 使用连接到此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.
由于丢弃的性质，问题可能出在CIN（例如，瓶颈链路、冲突、CRC错误），在cBR-8和RPD之间的CIN网络中需要进一步研究。如果在点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.服务质量
默认情况下，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 |
来源：思科1x2/紧凑型机架RPD软件5.x的思科远程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吞吐量问题。
相关信息
修订历史记录
| 版本 | 发布日期 | 备注 |
|---|---|---|
3.0 |
18-Oct-2022 |
文档与文档编址和域标准保持一致。 |
1.0 |
28-Jun-2019 |
初始版本 |
由思科工程师提供
- Francesco Di Ciccio思科TAC工程师
反馈