目录

简介

先决条件

要求

使用的组件

背景信息

故障排除

最近的MAP消息

潜在原因1.CIN延迟、延迟、抖动

潜在原因2.软件 Bug

上游延迟

无序的第2层隧道协议(L2TP)数据包

潜在原因1.负载平衡

潜在原因2.丢包

PTP定期丢失或解锁

拥塞的CIN

潜在原因1.服务质量

潜在原因2.延迟尽力传输流量

相关信息

简介

本文档介绍如何对思科远程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.丢包

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.

由于丢弃的性质，问题可能出在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吞吐量问题。

相关信息

- DEPI延迟测量

- R-PHY网络的PTP设计建议

- 技术支持和文档 - Cisco Systems