Solucionar problemas de desempenho de rendimento de DOCSIS RPD

Introduction

Este documento descreve como solucionar problemas de desempenho do dispositivo PHY remoto (RPD) da Cisco.

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento destes tópicos:

• RPD
• Roteador de banda larga convergente (cBR)-8 da Cisco
• Especificação de Interface de Serviço de Dados sobre Cabo (DOCSIS - Data Over Cable Service Interface Specification)

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

O cenário considerado neste artigo envolve um RPD provisionado pelo Cisco cBR-8 como Plataforma de Acesso a Cabo Convergente (CCAP). O Precision Time Protocol (PTP) é usado para sincronizar um relógio primário externo com o cBR-8 e o RPD que atuam como secundários. Para obter mais informações sobre como o design do PTP nesse ambiente, consulte Recomendações de design do PTP para redes R-PHY.

Esta não é uma lista abrangente de etapas para solucionar problemas de desempenho com RPD, embora seja um bom começo para isolar o problema.

Troubleshoot

Se você observar uma degradação de desempenho com a implantação de RPD e quiser executar uma solução de problemas inicial, não estará claro por onde começar.

Esta seção descreve alguns problemas comuns que podem ser a possível causa dos problemas de desempenho dos RPDs.

Mensagens de MAPA atrasadas

Uma condição de mensagem de mapa de alocação de largura de banda de upstream (MAP) atrasada ocorre quando um modem recebe uma mensagem MAP em um ponto no tempo, depois que os slots de tempo descritos na mensagem já ocorreram.  O modem não consegue usar essa mensagem MAP, portanto não consegue enviar nenhum tráfego nas concessões atribuídas.

Alguns MAPs atrasados podem causar taxas de tráfego de upstream reduzidas, bem como taxas de tráfego TCP de downstream reduzidas à medida que ACKs de upstream são atrasados. Se houver MAPs atrasados suficientes, os modems não poderão executar a manutenção da estação e ficarão off-line.

Outro sintoma pode ser quedas de pacotes quando você executa um ping docsis <MAC_ADDR> do cBR-8 para um modem conectado a um RPD.

Com PHY remoto (R-PHY), o cBR-8 envia mensagens MAP aos modems em um túnel de Interface PHY Externa Downstream (DEPI) e ao RPD em um túnel de Interface PHY Externa Upstream (UEPI). Essas mensagens têm uma marca de Qualidade de Serviço (QoS - Quality of Service) mais alta com um valor de Ponto de Código de Serviços Diferenciados (DSCP - Differentiated Services Code Point) de 46 (encaminhamento expresso - EF).

Se uma mensagem MAP destinada ao RPD for descartada no CIN, o RPD não poderá usar esses minislots e os contará como "não mapeados". Se a mensagem MAP chegar atrasada no RPD, ela inicialmente conta os minislots como não mapeados e, depois de receber o MAP atrasado, ela aumenta a contagem de minislots atrasados.

Os MAPs iniciais também são possíveis, mas geralmente só acontecem quando o relógio PTP está desligado no cBR-8 ou no RPD.

Os MAPs de sobreposição podem ocorrer quando as mensagens MAP saem da sequência, mas com uma frequência de apenas 2 ms, isso geralmente não é um problema. O número real de minislots em uma mensagem MAP é baseado na configuração de minislots para cada canal upstream. Se um upstream usa dois pulsos por minislot (popular para SC-QAM de 6,4 MHz), um MAP de 2 ms tem 160 minislots.

Para verificar se no RPD você recebe mensagens MAP atrasadas, execute estes comandos para acessar o console RPD. Em seguida, execute o comando show upstream map counter <rf port> <channel> várias vezes e verifique se o contador "Discarded minislots (late maps)" aumenta:

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

Observação: sempre que você executa o comando show upstream map counter, todos os contadores são redefinidos como 0, mas o último minislot mapeado

Dica: no RPD versão 6.x, você pode executar o comando show tech-support, que coleta várias ocorrências de show upstream map counter e outros comandos, portanto, úteis para comparação de contadores.

Se você executar o software RPD versão 5.x ou inferior, você pode executar o comando show tech com o uso do script disponível aqui: Capturar show tech no rpd ou comando limitado em ambos RPD, supervisor.

A página vinculada contém instruções sobre como instalar o script e exemplos de uso, no final das quais você pode encontrar o arquivo Script-Readme.tar disponível para download. Esse arquivo contém o script sh_tech_rpd.tcl e o arquivo sh_tech_rpd-README.txt com as instruções e exemplos de uso.

O script tem uma opção (-c) para coletar um conjunto adicional de comandos listados em um arquivo de texto, ambos os comandos a serem emitidos no próprio RPD e no supervisor cBR-8 são aceitos (todos os procedimentos explicados no link mencionado anteriormente e o arquivo readme).

Esse recurso faz uso desse script, curiosamente, também em versões RPD que incluem o comando show tech-support.

Causa potencial 1. Atraso, latência e instabilidade de CIN

A Rede de Interconexão Convergente (CIN) que liga o núcleo do CCAP e os RPDs pode introduzir atrasos que devem ser considerados no temporizador avançado do MAP. Se houver uma alteração na CIN, como, por exemplo, outro roteador foi adicionado, é possível que você tenha introduzido um atraso maior.

O temporizador avançado MAP é usado pelo CCAP para evitar mensagens MAP atrasadas. Esse temporizador é baseado em microssegundos (μs) e pode ser configurado estaticamente por interface de cabo pelo operador ou calculado dinamicamente pelo cBR-8.

O valor dinâmico é a soma do intervalo de tempo downstream (680 μs com SC-QAM com 256-QAM), atraso de processamento de MAP de modem (600 μs), atraso de rede interna CCAP (300 μs), valor de segurança avançada MAP (1000 μs por padrão) e deslocamento de tempo máximo do modem (com base no modem mais distante).

Com R-PHY, o atraso interno CCAP agora é substituído por um atraso de rede, que assume o padrão de 500 μs. Considerando o projeto da CIN, esse valor pode ser maior que o parâmetro padrão e pode mudar com o tempo.

Os valores avançados de MAP para um upstream podem ser exibidos com este comando:

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.

Se a distância entre a cBR-8 e a RPD combinada com os atrasos dos dispositivos CIN exceder o valor padrão de atraso de rede de 500 μs, as mensagens de MAP atrasadas serão possíveis.

Há dois métodos para lidar com o parâmetro de atraso de rede padrão quando isso representa um problema e ambos são definidos por RPD no cBR-8:

• Configure estaticamente o atraso.
• Defina a cBR-8 para medir e ajustar o atraso periodicamente.

O atraso de rede pode ser configurado estaticamente por RPD no cBR-8 como mostrado aqui:

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>

Para o atraso dinâmico da rede, o cBR-8 conta com um recurso de medição de latência chamado de DLM (Medição de latência DEPI), que determina o atraso unidirecional no caminho de downstream.

O cBR-8 envia um pacote DLM com seu carimbo de data/hora, o RPD marca seu carimbo de data/hora no pacote DLM quando recebido e o encaminha de volta para o cBR-8.

Observe que a Cisco suporta a opção necessária onde o RPD marca o pacote mais próximo à sua interface de entrada, não à saída.

A cBR-8 toma a média dos últimos 10 valores de DLM e a usa como o valor de atraso de rede no cálculo avançado de MAP. Os timestamps da cBR-8 e da RPD são baseados nos relógios de referência PTP.

Aviso: se o PTP estiver instável, o mesmo acontecerá com os valores DLM e, por fim, com o temporizador de avanço MAP.

Por padrão, a DLM está desativada e pode ser ativada com o comando network-delay dlm <seconds>, como mostrado. Uma vez ativado, um pacote DLM é enviado ao RPD periodicamente, de acordo com o valor configurado.

Há também uma opção apenas de medida que pode ser adicionada, que apenas mede o atraso CIN sem ajuste do valor de atraso da rede.

Recomenda-se ativar a DLM no mínimo no parâmetro measure-only para monitorar o atraso da 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

Mais informações sobre este recurso podem ser encontradas aqui; Medição de latência DEPI

A segurança avançada do MAP também pode ser alterada manualmente na configuração da interface do cabo (os valores padrão são 1000 μs para o fator de segurança e 18000 μs para o avanço máximo do mapa):

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

Cuidado: atrasos muito curtos de CIN também podem causar mensagens MAP atrasadas

Houve problemas observados com tráfego DOCSIS de upstream descartado quando o temporizador avançado MAP está abaixo de 2500 μs.

Alguns modems podem levar mais tempo para processar mensagens MAP e esse atraso extra pode causar mensagens MAP atrasadas para esses modems (o RPD possivelmente não mostra contagens MAP atrasadas se foi capaz de obter a mensagem a tempo).

Um temporizador avançado MAP baixo é possível com valores DLM muito baixos, ou com retardo de rede manual baixo ou configuração de segurança avançada MAP. Os valores de atraso da rede no cálculo avançado do MAP podem ser tão baixos quanto 30 μs (mesmo que a média de DLM seja menor).

Recomenda-se usar a opção "somente medida" da DLM ou aumentar o fator de segurança para avanço dinâmico do MAP até que o temporizador avançado do MAP esteja acima de 2500 μs.

Causa potencial 2. Erro de software

Para verificar se um bug de software causa uma falha de sincronização, é recomendável abrir uma solicitação de serviço com a Cisco para investigar melhor o caso específico.

A solução para o caso de ocorrer um defeito de software é geralmente uma atualização de software para uma das versões que contém a correção. Como há uma correlação de compatibilidade entre as versões de software cBR-8 e RPD, é importante escolher a versão correta para ambos os dispositivos.

Para ajudar a escolher o Cisco IOS® XE correto para cada software RPD, você pode encontrar as compatibilidades de versão de software entre cBR-8 e RPD nos Guias de instalação e atualização da PHY do Cisco Remote.

Nesta tabela, você pode encontrar um resumo da compatibilidade da versão do software entre cBR-8 e RPD, com as versões de software disponíveis no momento da escrita:

Compatibilidade de versão entre Cisco cBR-8 e Cisco RPD
Versão do Cisco cBR-8	Versão de lançamento compatível de RPD
Cisco IOS® XE Everest 16.6.x	Software Cisco 1x2 RPD 2.x
Cisco IOS® XE Fuji 16.7.x	Software Cisco 1x2 RPD 3.x
Cisco IOS® XE Fuji 16.8.x	Software Cisco 1x2 RPD 4.x
Cisco IOS® XE Fuji 16.9.x	Software Cisco 1x2 RPD 5.x
Cisco IOS® XE Gibraltar 16.10.1c	Software Cisco 1x2 RPD 6.1, 6.2, 6.3
Cisco IOS® XE Gibraltar 16.10.1d	Software Cisco 1x2 RPD 6.4, 6.5, 6.7
Cisco IOS® XE Gibraltar 16.10.1f	Software Cisco 1x2 RPD 6.6, 6.7
Cisco IOS® XE Gibraltar 16.10.1g	Software Cisco 1x2 RPD 7.1, 7.2, 7.3, 7.4.x, 7.5
Cisco IOS® XE Gibraltar 16.12.1	Software Cisco 1x2 RPD 7.1, 7.2, 7.3, 7.4.x, 7.5
Cisco IOS® XE Gibraltar 16.12.1w	Software Cisco 1x2 RPD 7.1, 7.2, 7.3, 7.4.x, 7.5
Cisco IOS® XE Gibraltar 16.12.1x	Software Cisco 1x2 RPD 7.6, 7.7
Cisco IOS® XE Gibraltar 16.12.1y	Software Cisco 1x2 RPD 7.8, 7.8.1, 8.2
Cisco IOS® XE Gibraltar 16.12.1z	Software Cisco 1x2 RPD 8.3, 8.4, 8.5
Cisco IOS® XE Gibraltar 17.2.1	Software Cisco 1x2 RPD 8.1, 8.2, 8.3, 8.4, 8.5

Latência de upstream

Conforme discutido na seção anterior, longos atrasos de CIN podem causar problemas de mensagens de MAP atrasadas e podem ser resolvidos com o aumento do temporizador avançado de MAP. Isso, por sua vez, cria um retardo de solicitação-concessão mais longo, o que leva ao aumento da latência de upstream.

Como os fluxos de tráfego upstream estáveis usam solicitações piggy-back, o teste de velocidade do tráfego upstream pode parecer normal, e também os fluxos de voz com Unsolicited Grant Service (UGS) não são afetados, pois nenhuma solicitação é necessária.

No entanto, as velocidades de tráfego TCP downstream podem ser reduzidas devido à falta de ACKs upstream oportunas. Embora seja possível lidar com atrasos de processamento e enfileiramento na CIN, não é provável que os sinais trafeguem mais rápido em uma determinada distância.

A Cisco desenvolveu o DOCSIS Predictive Scheduling (DPS) para reduzir o atraso de concessão de solicitação em aplicativos R-PHY com atrasos de CIN mais longos. O DPS oferece concessões proativas aos modems com base no histórico de uso, para minimizar o atraso de solicitação-concessão.

O DPS é um método de programação pré-padrão, semelhante ao Proactive Grant Service (PGS) descrito na recente especificação DOCSIS de Baixa Latência (LLD).  No entanto, o DPS pode ser ativado por interface e é aplicado a todos os fluxos de serviço upstream de melhor esforço. O PGS é aplicado ao tráfego como um tipo de fluxo de serviço, portanto, requer alterações no arquivo de configuração do modem.

O DPS pode ser ativado com o comando de interface: cbr8(config-if)#cable upstream dps

Embora o DPS esteja disponível desde que o suporte a R-PHY foi adicionado ao cBR-8, ele não é um recurso oficialmente suportado no momento. No entanto, o DPS pode ser eficaz para resolver o throughput de downstream de TCP lento associado a ACKs atrasados.

Pacotes L2TP (Layer 2 Tunneling Protocol) fora de ordem

No console RPD, digite este comando várias vezes para verificar se os contadores "SeqErr-pkts" e "SeqErr-sum-pkts" são positivos e aumentam, o que é uma indicação de pacotes L2TP fora de ordem:

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      

Causa potencial 1. Balanceamento de carga

Em algumas condições específicas, como o congestionamento de links na CIN, por exemplo, o balanceamento de carga pode contribuir para o problema de pacotes recebidos fora de ordem no destino.

Se você tiver a possibilidade, para verificar se o balanceamento de carga dispara esse problema, você pode testar para aplicar um único caminho onde o balanceamento de carga está configurado. Se isso resolver o problema de pacotes com problemas, você terá a confirmação do disparador e poderá investigar mais a causa raiz em sua rede.

Causa potencial 2. Quedas de pacotes

1. Verifique se há aumento de erros e quedas nos contadores cBR-8 na interface da placa DPIC à qual o RPD está conectado, com o uso do comando show interface como mostrado aqui.

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. Verifique no lado RPD se há erros, pacotes descartados e fora de ordem nas interfaces e nos contadores downstream.

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. Verifique os contadores InterLaken downstream várias vezes para ver se há erros e se os contadores aumentam. Para fazer isso, você precisa entrar na interface de console da placa de linha como mostrado aqui.

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. Pegue um modem conectado a esse RPD (somente canais DS vinculados) e envie pacotes (por exemplo, pings) a ele, para verificar se os pacotes enviados correspondem ao fluxo downstream injetado nos contadores do módulo JIB. Certifique-se de que o DS JIB tenha enviado todos os pacotes de dados DS para o quadro DEPI no console da placa de linha. Nesta saída, você pode ver como ver o número de sequência do pacote de uma saída de fluxo de serviço de modem. Esse número de sequência aumenta para cada pacote de dados enviado.

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

Envie alguns pings para esse modem a partir da linha de comando cBR-8, em outra janela:

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#

Verificar o delta após o ensaio:

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

Calcule o delta após o teste: o contador é de 16 bits sem sinal, portanto, se o contador rolar, o delta precisa ser calculado com esta fórmula:

(Initial Sequence Number + Number of Packets Sent) % 65536

Exemplo:

Initial Sequence Number = 50967

Final Sequence Number = 2391

Packets sent: 1000000




(50967+1000000)%65536 = 2391 <== Good, no packet was dropped before DEPI frame.

Como consequência da natureza das quedas, o problema pode estar na CIN (por exemplo, enlaces de gargalo, colisões, erros de CRC) que precisam ser investigados mais detalhadamente na rede CIN entre o cBR-8 e o RPD. Se forem observadas quedas nos pontos 3 e 4, é recomendável envolver a Cisco para uma investigação mais detalhada sobre a cBR-8.

Perda ou desbloqueio periódico do PTP

Como você provavelmente sabe, o PTP é essencial para operações normais de RPD. Portanto, os pacotes PTP devem ter alta prioridade em QoS e as quedas de pacotes PTP não são um bom sinal.

No console de RPD, você pode mostrar as estatísticas de PTP e verificar se os contadores "DELAY REQUEST" e "DELAY RESPONSE" estão intimamente correspondentes. Se, em vez disso, você vir uma grande lacuna, ela pode ser um indicador de quedas de PTP na rede:

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

Observação: no cBR-8, o PTP tem a prioridade mais alta para o relógio, o que significa que, uma vez configurado, é usado até mesmo para placas de linha RF. Portanto, uma fonte não confiável causaria problemas em todo o chassi.

Para obter mais informações sobre a configuração e solução de problemas do relógio PTP, você pode ler o artigo PTP Design Recommendations For R-PHY Networks.

CIN congestionado

A CIN pode ser vista como uma extensão do plano de controle do núcleo da CCAP, portanto, se houver 1000 Mbps de DOCSIS e tráfego de vídeo no downstream para um determinado RPD, então essa capacidade deve ser alocada na CIN, mais alguma capacidade adicional para a sobrecarga de L2TPv3 usada pelos túneis DEPI.

Se houver congestionamento na CIN, alguns pacotes poderão ser atrasados ou perdidos.

Causa potencial 1. qos

Por padrão, o cBR-8 e os RPDs marcam pacotes associados ao tráfego PTP e mensagens MAP com DSCP 46 (EF).  Outras mensagens de controle DOCSIS, como descritores de canal upstream (UCD), requisição de largura de banda de modem e resposta de intervalo também usam DSCP 46:

Item	Comportamento por salto (PHB)	Valor de DSCP
Dados DOCSIS (L2TP)	O melhor esforço	0
PTP	EF	46
GCP	O melhor esforço	0
MAP/UCD (L2TP, controle DOCSIS)	EF	46
BWR e RNG-REG	EF	46
Vídeo	CS4	32
MDD (L2TP, controle DOCSIS), voz	CS5	40

Fonte: Cisco Remote PHY Device Software Configuration Guide for Cisco 1x2 / Compact Shelf RPD Software 5.x

A CIN deve reconhecer a QoS para que esses pacotes de alta prioridade sofram um atraso mínimo.

O congestionamento que cria pacotes descartados ou longos atrasos na fila criou problemas de PTP, mensagens de MAP atrasadas e throughput reduzido. Esses tipos de problemas podem ser vistos pela observação de filas de interface nos dispositivos cBR-8, RPD e CIN.

Se as mensagens PTP ou MAP forem descartadas ou atrasadas, como evidente com a instabilidade do relógio ou com as mensagens MAP atrasadas, a capacidade CIN ou o design de QoS deverá ser endereçado, já que elas são enviadas com alta prioridade.

A DLM não se destina a lidar com durações curtas de jitter porque o ciclo mínimo de polling é de um segundo, portanto, não é capaz de eliminar mensagens MAP atrasadas nesse caso.

Causa potencial 2. Tráfego de melhor esforço atrasado

Atualmente, as marcas de pacote DLM não são configuráveis e usam o melhor esforço (DSCP 0). Houve casos em que a CIN experimenta congestionamento que leva a um retardo de fila longo limitado ao tráfego de melhor esforço.

Isso geralmente é mostrado como taxas de tráfego de downstream de TCP reduzidas, já que os atrasos de CIN podem criar quedas de velocidade relativamente grandes devido a ACKs de upstream perdidos ou atrasados.

Nesse caso, nenhuma mensagem de MAP atrasada ou problemas de PTP são observados, porque esses pacotes de alta prioridade não são atrasados.

Como os pacotes DLM são marcados como tráfego de melhor esforço, esse tipo de jitter CIN pode causar picos nos valores DLM. Se a DLM for usada para ajustar dinamicamente o atraso da rede, esse jitter pode causar um aumento desnecessário no temporizador avançado MAP, o que leva a maiores atrasos de solicitação-concessão de upstream.

Nesse caso, é recomendável usar um valor de atraso de rede estático. A Cisco também examina opções para ativar valores de DSCP além do melhor esforço em DLM em versões futuras. Isso pode ajudar a reduzir o atraso de solicitação-concessão de upstream, mas possivelmente não soluciona problemas de throughput de TCP se ACKs forem atrasados pela CIN.

Informações Relacionadas

• Medição de latência de DEPI
• Recomendações de design do PTP para redes R-PHY
• Suporte Técnico e Documentação - Cisco Systems