RPD DOCSIS 처리량 성능 문제 해결

소개

이 문서에서는 Cisco RPD(Remote PHY Device) 성능 문제를 해결하는 방법에 대해 설명합니다.

사전 요구 사항

요구 사항

다음 주제에 대한 지식을 보유하고 있으면 유용합니다.

• RPD
• Cisco cBR(Converged Broadband Router)-8
• DOCSIS(Data Over Cable Service Interface Specification)

사용되는 구성 요소

이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.

배경 정보

이 문서에서 설명하는 시나리오에는 Cisco cBR-8에서 CCAP(Converged Cable Access Platform)로 프로비저닝하는 RPD가 포함됩니다. PTP(Precision Time Protocol)는 외부 주 클록을 보조 역할을 하는 cBR-8 및 RPD와 동기화하는 데 사용됩니다. 이 환경에서 PTP를 설계하는 방법에 대한 자세한 내용은 R-PHY 네트워크에 대한 PTP 설계 권장 사항을 참조하십시오.

이는 RPD의 성능 문제를 해결하기 위한 포괄적인 단계 목록이 아니지만, 문제를 격리하기 위해 시작하는 것이 좋습니다.

문제 해결

RPD 구축에서 성능 저하가 관찰되고 초기 트러블슈팅을 수행하려는 경우, 시작할 위치를 명확하지 않습니다.

이 섹션에서는 RPD 성능 문제의 가능한 원인이 될 수 있는 몇 가지 일반적인 문제에 대해 설명합니다.

늦은 MAP 메시지

메시지에 설명된 시간 슬롯이 이미 발생한 후 특정 시점에 모뎀이 MAP 메시지를 수신할 때 MAP(Late Upstream Bandwidth Allocation Map) 메시지 조건이 발생합니다.  모뎀에서 이 MAP 메시지를 사용할 수 없으므로 할당된 부여에 트래픽을 전송할 수 없습니다.

몇몇 늦은 MAP는 업스트림 트래픽 속도를 줄이는 것은 물론 업스트림 ACK가 지연될 때 다운스트림 TCP 트래픽 속도를 줄일 수 있습니다. 지연 MAP가 충분한 경우 모뎀은 스테이션 유지 관리를 수행할 수 없으며 오프라인으로 전환됩니다.

또 다른 증상은 cBR-8에서 RPD에 연결된 모뎀으로 ping docsis <MAC_ADDR>을 수행할 때 패킷을 삭제하는 것입니다.

R-PHY(Remote PHY)를 사용하는 경우 cBR-8은 MAP 메시지를 다운스트림 DEPI(External PHY Interface) 터널의 모뎀으로 보내고 UEPI(Upstream External PHY Interface) 터널의 RPD로 보냅니다. 이 메시지는 DSCP(Differentiated Services Code Point) 값이 46(빠른 전달 - EF)인 더 높은 QoS(Quality of Service) 마크를 가지고 있습니다.

RPD로 향하는 MAP 메시지가 CIN에서 삭제될 경우 RPD는 해당 미니슬롯을 사용할 수 없으며 이를 "매핑되지 않음"으로 계산합니다. MAP 메시지가 RPD에 늦게 도착하면 처음에 미니로트를 매핑되지 않은 것으로 계산한 다음 늦은 MAP를 받은 후 늦은 미니로트 수를 증가시킵니다.

초기 MAP도 가능하지만 일반적으로 cBR-8 또는 RPD에서 PTP 클럭이 꺼진 경우에만 발생합니다.

MAP 메시지가 순서를 벗어나면 MAP 중복이 발생할 수 있지만 빈도가 2ms에 불과하므로 일반적으로 문제가 되지 않습니다. MAP 메시지의 실제 미니슬롯 수는 각 업스트림 채널의 미니슬롯 컨피그레이션을 기반으로 합니다. 업스트림에서 미니슬롯당 2개의 틱을 사용하는 경우(6.4MHz SC-QAM에서 인기), 2ms 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 카운터 명령을 실행할 때마다 모든 카운터는 0으로 재설정되지만 마지막 매핑된 미니슬롯은 재설정됩니다

팁: RPD 버전 6.x에서 show tech-support 명령을 실행할 수 있습니다. 이 명령은 show upstream map counter 및 기타 명령의 여러 번을 수집하므로 카운터 비교에 유용합니다.

RPD 소프트웨어 버전 5.x 이하를 실행하는 경우 다음 위치에서 사용 가능한 스크립트를 사용하여 show tech 명령을 실행할 수 있습니다. rpd의 show tech 캡처 또는 RPD, supervisor 모두의 limited 명령.

연결된 페이지에는 스크립트 설치 방법에 대한 지침과 사용 예제가 포함되어 있으며, 이 지침의 끝에서 다운로드 가능한 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를 연결하는 CIN(Converged Interconnect Network)은 MAP Advance 타이머에서 처리해야 하는 지연을 유발할 수 있습니다. 예를 들어 다른 라우터가 추가된 것처럼 CIN에 변화가 있는 경우 더 높은 지연이 발생했을 수 있습니다.

MAP 고급 타이머는 늦은 MAP 메시지를 방지하기 위해 CCAP에서 사용합니다. 이 타이머는 마이크로초(μs) 단위로 운영자가 케이블 인터페이스별로 정적으로 구성하거나 cBR-8에서 동적으로 계산할 수 있습니다.

동적 값은 다운스트림 시간 간격(680μs, SC-QAM, 256QAM), 모뎀 MAP 처리 지연(600μs), CCAP 내부 네트워크 지연(300μs), MAP 고급 안전 값(기본값 1000μ), 최대 모뎀 시간 오프셋(가장 먼 모뎀 기준)의 합계입니다.

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 메시지가 가능합니다.

문제를 나타낼 때 기본 네트워크 지연 매개변수를 처리하는 방법에는 두 가지가 있으며, 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은 DLM(DEPI Latency Measurement)이라는 레이턴시 측정 기능을 사용하며, 이는 다운스트림 경로의 단방향 지연을 결정합니다.

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로 전송됩니다.

네트워크 지연값을 조정하지 않고 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 advance safety는 케이블 인터페이스 컨피그레이션에서 수동으로 변경할 수도 있습니다(기본값은 안전 계수의 경우 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 수를 표시하지 않을 수 있음).

낮은 MAP 고급 타이머는 매우 낮은 DLM 값 또는 낮은 수동 네트워크 지연 또는 MAP 고급 안전 컨피그레이션으로 가능합니다. MAP 사전 계산에서의 네트워크 지연 값은 (DLM 평균이 더 낮더라도) 30 μs만큼 낮을 수 있다.

DLM "측정 전용" 옵션을 사용하거나 MAP 고급 타이머가 2500μs를 초과할 때까지 동적 MAP 고급 안전 계수를 늘리는 것이 좋습니다.

잠재적 원인 2. 소프트웨어 버그

소프트웨어 버그로 인해 동기화 오류가 발생하는지 확인하려면 Cisco와 함께 서비스 요청을 열어 특정 사례를 자세히 조사하는 것이 좋습니다.

소프트웨어 결함을 발견하는 경우의 해결책은 대개 수정 사항이 포함된 릴리스 중 하나로 소프트웨어를 업그레이드하는 것입니다. cBR-8과 RPD 소프트웨어 릴리스 간에는 호환성 상관관계가 있으므로 두 장치 모두에 적합한 버전을 선택하는 것이 중요합니다.

모든 RPD 소프트웨어에 적합한 Cisco IOS® XE를 선택하려면 Cisco Remote PHY 설치 및 업그레이드 가이드에서 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 Software 2.x
Cisco IOS® XE Fuji 16.7.x	Cisco 1x2 RPD Software 3.x
Cisco IOS® XE Fuji 16.8.x	Cisco 1x2 RPD Software 4.x
Cisco IOS® XE Fuji 16.9.x	Cisco 1x2 RPD Software 5.x
Cisco IOS® XE Gibraltar 16.10.1c	Cisco 1x2 RPD Software 6.1, 6.2, 6.3
Cisco IOS® XE Gibraltar 16.10.1d	Cisco 1x2 RPD Software 6.4, 6.5, 6.7
Cisco IOS® XE Gibraltar 16.10.1f	Cisco 1x2 RPD Software 6.6, 6.7
Cisco IOS® XE Gibraltar 16.10.1g	Cisco 1x2 RPD Software 7.1, 7.2, 7.3, 7.4.x, 7.5
Cisco IOS® XE Gibraltar 16.12.1	Cisco 1x2 RPD Software 7.1, 7.2, 7.3, 7.4.x, 7.5
Cisco IOS® XE Gibraltar 16.12.1w	Cisco 1x2 RPD Software 7.1, 7.2, 7.3, 7.4.x, 7.5
Cisco IOS® XE Gibraltar 16.12.1x	Cisco 1x2 RPD Software 7.6, 7.7
Cisco IOS® XE Gibraltar 16.12.1y	Cisco 1x2 RPD Software 7.8, 7.8.1, 8.2
Cisco IOS® XE Gibraltar 16.12.1z	Cisco 1x2 RPD Software 8.3, 8.4, 8.5
Cisco IOS® XE Gibraltar 17.2.1	Cisco 1x2 RPD Software 8.1, 8.2, 8.3, 8.4, 8.5

업스트림 레이턴시

이전 섹션에서 설명한 것처럼, 긴 CIN 지연은 늦은 MAP 메시지 문제를 야기할 수 있으며, MAP 고급 타이머 증가로 해결할 수 있습니다. 그러면 요청-승인 지연이 더 길어지고, 이는 업스트림 레이턴시를 증가시킵니다.

안정된 업스트림 트래픽 흐름은 피기백 요청을 사용하므로 업스트림 트래픽 속도 테스트는 정상적으로 나타날 수 있으며, UGS(Unsolicited Grant Service)를 사용하는 음성 흐름에도 요청이 필요하지 않으므로 영향을 받지 않습니다.

그러나 적시에 업스트림 ACK가 없기 때문에 다운스트림 TCP 트래픽 속도를 줄일 수 있습니다. CIN에서 프로세싱 및 큐잉 지연을 해결할 수는 있지만, 신호가 지정된 거리 이상 더 빠르게 이동하도록 만들 가능성은 없습니다.

Cisco는 CIN 지연이 더 긴 R-PHY 애플리케이션의 요청 승인 지연을 줄이기 위해 DOCSIS DPS(Predictive Scheduling)를 개발했습니다. DPS는 요청-승인 지연을 최소화하기 위해, 과거 사용량을 기준으로 사전 대응적으로 모뎀에 승인을 제공합니다.

DPS는 최신 LLD(Low Latency DOCSIS) 사양에 설명된 PGS(Proactive Grant Service)와 유사한 사전 표준 스케줄링 방법입니다.  그러나 DPS는 인터페이스별로 활성화할 수 있으며 모든 최선형 업스트림 서비스 플로우에 적용됩니다. PGS는 서비스 흐름 유형으로 트래픽에 적용되므로 모뎀 구성 파일을 변경해야 합니다.

DPS는 interface 명령으로 활성화할 수 있습니다. cbr8(config-if)#cable upstream dps

R-PHY 지원이 cBR-8에 추가된 이후 DPS를 사용할 수 있었지만, 현재는 공식적으로 지원되는 기능이 아닙니다. 그럼에도 불구하고 DPS는 지연된 ACK와 관련된 느린 TCP 다운스트림 처리량을 해결하는 데 효과적일 수 있습니다.

L2TP(Out of Order Layer 2 Tunneling Protocol) 패킷

RPD 콘솔에서 이 명령을 여러 번 입력하여 "SeqErr-pkts" 및 "SeqErr-sum-pkts" 카운터가 양수이고 증가하는지 확인합니다. 이는 L2TP out of order 패킷을 나타냅니다.

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. 전송된 패킷이 JIB 모듈 카운터에서 주입된 다운스트림 흐름과 일치하는지 확인하기 위해 이 RPD(DS 채널이 바인딩되는 경우에만)에 연결된 모뎀을 가져와서 패킷(예: 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.

드랍의 특성상 문제는 cBR-8과 RPD 사이의 CIN 네트워크에서 추가로 조사되어야 하는 CIN(예: 병목 링크, 충돌, CRC 오류)에 있을 수 있습니다. 대신 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 시계 컨피그레이션 및 문제 해결에 대한 자세한 내용은 R-PHY Networks용 PTP Design Recommendations 문서를 참조하십시오.

정체 CIN

CIN은 CCAP 코어의 컨트롤 플레인의 확장으로 간주될 수 있습니다. 따라서 지정된 RPD에 대해 다운스트림에 1000Mbps의 DOCSIS 및 비디오 트래픽이 있는 경우 CIN에 그 많은 용량을 할당하고 DEPI 터널에서 사용되는 L2TPv3 오버헤드를 위한 약간의 추가 용량을 할당해야 합니다.

CIN에 혼잡이 있을 경우 일부 패킷이 지연되거나 손실될 수 있습니다.

잠재적 원인 1. QoS

기본적으로 cBR-8 및 RPD는 PTP 트래픽과 연결된 패킷 및 MAP 메시지를 EF(DSCP 46)로 표시합니다.  UCD(업스트림 채널 설명자), 모뎀 대역폭 요청 및 범위 응답과 같은 기타 DOCSIS 제어 메시지는 DSCP 46도 사용합니다.

항목	PHB(Per-Hop-Behavior)	DSCP 값
DOCSIS 데이터(L2TP)	최선형	0
PTP	EF	46
GCP	최선형	0
맵/UCD(L2TP, DOCSIS 제어)	EF	46
BWR 및 RNG-REG	EF	46
비디오	CS4	32
MDD(L2TP, DOCSIS 제어), 음성	CS5	40

출처: Cisco 1x2 / Compact Shelf RPD Software 5.x용 Cisco Remote PHY Device Software Configuration Guide

CIN은 QoS를 인식해야 하므로 높은 우선 순위 패킷에 최소 지연이 발생합니다.

삭제된 패킷 또는 긴 대기열 지연을 생성하는 혼잡으로 인해 PTP 문제, 늦은 MAP 메시지 및 처리량 감소가 발생했습니다. 이러한 유형의 문제는 cBR-8, RPD 및 CIN 디바이스에서 인터페이스 대기열을 관찰하면 확인할 수 있습니다.

PTP 또는 MAP 메시지가 클록 불안정성 또는 늦은 MAP 메시지와 함께 명백한 것처럼 삭제되거나 지연될 경우, CIN 용량 또는 QoS 설계가 우선 순위가 높은 상태로 전송되기 때문에 이를 해결해야 합니다.

DLM은 최소 폴링 주기가 1초이므로 지터의 짧은 기간을 처리하기 위한 것이 아니므로, 이 경우 지연 MAP 메시지를 제거할 수 없습니다.

잠재적 원인 2. 지연된 최선형 트래픽

현재 DLM 패킷 마크는 구성할 수 없으며 DSCP 0(best effort)을 사용합니다. CIN에서 혼잡이 발생하여 최선형 트래픽으로 긴 대기열 지연이 발생하는 경우가 있었습니다.

이는 일반적으로 감소된 TCP 다운스트림 트래픽 속도로 나타나는데, 이는 CIN 지연이 누락되거나 지연된 업스트림 ACK로 인해 상대적으로 큰 속도 저하를 생성할 수 있기 때문입니다.

이 경우, 이러한 높은 우선순위 패킷은 지연되지 않으므로 늦은 MAP 메시지 또는 PTP 문제가 관찰되지 않습니다.

DLM 패킷이 최선형 트래픽으로 표시되므로 이 유형의 CIN 지터는 DLM 값의 스파이크를 유발할 수 있습니다. DLM을 사용하여 네트워크 지연을 동적으로 조정하는 경우, 이 지터는 MAP 고급 타이머의 불필요한 증가를 유발하여 업스트림 요청-승인 지연을 증가시킬 수 있습니다.

이 경우 정적 네트워크 지연 값을 사용하는 것이 좋습니다. 또한 Cisco는 향후 릴리스에서 DLM에 대한 최선의 노력을 넘어 DSCP 값을 활성화하는 옵션도 살펴봅니다. 이렇게 하면 업스트림 요청-승인 지연을 줄일 수 있지만 CIN에서 ACK가 지연되는 경우 TCP 처리량 문제를 해결하지 못할 수 있습니다.

관련 정보

• DEPI 레이턴시 측정
• R-PHY 네트워크를 위한 PTP 설계 권장 사항
• 기술 지원 및 문서 − Cisco Systems