Solucionar problemas de rendimiento de RPD DOCSIS

Introducción

Este documento describe cómo resolver problemas de rendimiento del dispositivo PHY remoto (RPD) de Cisco.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• RPD
• Router de banda ancha convergente (cBR) de Cisco (8)
• Especificación de interfaz de servicio de datos sobre cable (DOCSIS)

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

El escenario considerado en este artículo involucra un RPD proporcionado por Cisco cBR-8 como Plataforma de acceso por cable convergente (CCAP). El protocolo de tiempo de precisión (PTP) se utiliza para sincronizar un reloj primario externo con el cBR-8 y el RPD que actúan como secundarios. Para obtener más información sobre cómo diseñar PTP en este entorno, puede consultar Recomendaciones de diseño PTP para redes R-PHY.

Esta no es una lista completa de pasos para resolver problemas de rendimiento con RPD, aunque es un buen comienzo para aislar el problema.

Troubleshoot

Si observa una degradación del rendimiento con la implementación de RPD y desea realizar una resolución de problemas inicial, no está claro por dónde empezar.

Esta sección describe algunos problemas comunes que pueden ser la causa posible de los problemas de rendimiento de los RPD.

Mensajes de MAP tardíos

Una condición de mensaje de mapa de asignación de ancho de banda ascendente (MAP) tardía ocurre cuando un módem recibe un mensaje MAP en un momento determinado, después de que ya se hayan producido las franjas horarias descritas en el mensaje.  El módem no puede utilizar este mensaje de MAP, por lo que no puede enviar ningún tráfico en los permisos asignados.

Unos pocos MAP tardíos pueden causar tasas de tráfico ascendente reducidas, así como tasas de tráfico TCP descendente reducidas a medida que se retrasan los ACK ascendentes. Si hay suficientes MAPs tardíos, los módems no pueden realizar el mantenimiento de la estación y quedan fuera de línea.

Otro síntoma puede ser la caída de paquetes cuando hace un ping docsis <MAC_ADDR> desde el cBR-8 a un módem conectado a un RPD.

Con PHY remoto (R-PHY), el cBR-8 envía mensajes MAP a los módems en un túnel de interfaz PHY externa (DEPI) descendente y al RPD en un túnel de interfaz PHY externa ascendente (UEPI). Estos mensajes tienen una marca de calidad de servicio (QoS) más alta con un valor de punto de código de servicios diferenciados (DSCP) de 46 (reenvío urgente - EF).

Si un mensaje MAP destinado al RPD se descarta en la CIN, el RPD no puede utilizar esos miniperíodos y los cuenta como "no asignados". Si el mensaje MAP llega tarde al RPD, inicialmente cuenta los miniperíodos como no asignados y luego después de recibir el MAP tardío, incrementa el recuento de miniperíodos tardíos.

Los MAPs tempranos también son posibles, pero por lo general solo ocurren cuando el reloj PTP está apagado en el cBR-8 o el RPD.

Los MAPs superpuestos pueden ocurrir cuando los mensajes MAP salen de la secuencia pero con una frecuencia de tan solo 2 ms, esto no suele ser un problema. El número real de miniperíodos en un mensaje MAP se basa en la configuración de miniperíodos para cada canal ascendente. Si un flujo ascendente utiliza dos ticks por minislot (popular para SC-QAM de 6,4 MHz), un MAP de 2 ms tiene 160 minislots.

Para verificar si en el RPD recibe mensajes MAP tardíos, ejecute estos comandos para acceder a la consola RPD. A continuación, ejecute el comando show upstream map counter <rf port> <channel> varias veces y compruebe si el 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

Nota: Cada vez que ejecuta el comando show upstream map counter, todos los contadores se restablecen a 0 pero Last maps minislot

Sugerencia: desde la versión 6.x de RPD, puede ejecutar el comando show tech-support, que recopila varias apariciones de show upstream map counter y otros comandos, por lo tanto, útiles para la comparación de contadores.

Si ejecuta la versión 5.x o inferior del software RPD, puede ejecutar el comando show tech con el uso del script disponible aquí: Capture show tech on rpd o el comando limited en ambos RPD, supervisor.

La página enlazada contiene instrucciones sobre cómo instalar el script y ejemplos de uso, al final de los cuales puede encontrar el archivo Script-Readme.tar disponible para su descarga. Este archivo contiene el script sh_tech_rpd.tcl y el archivo sh_tech_rpd-README.txt con las instrucciones y los ejemplos de uso.

La secuencia de comandos tiene una opción (-c) para recopilar un conjunto adicional de comandos listados en un archivo de texto, se aceptan ambos comandos para ser emitidos en el RPD mismo y en el supervisor cBR-8 (todos los procedimientos explicados en el link mencionado anteriormente y el archivo léame).

Esta función hace el uso de este script, curiosamente, también en las versiones de RPD que incluyen el comando show tech-support.

Causa potencial 1. Retraso, latencia y fluctuación de CIN

La red de interconexión convergente (CIN) que enlaza el núcleo CCAP y los RPD puede introducir retrasos que deben tenerse en cuenta en el temporizador de avance de MAP. Si se produce un cambio en la CIN, como, por ejemplo, si se ha agregado otro router, es posible que haya introducido un retraso mayor.

El CCAP utiliza el temporizador de avance de MAP para evitar mensajes de MAP tardíos. Este temporizador se basa en microsegundos (s) y el operador puede configurarlo estáticamente por interfaz de cable o calcularlo dinámicamente mediante cBR-8.

El valor dinámico es la suma del tiempo de flujo descendente entre hojas (680 con SC-QAM con 256-QAM), el retraso de procesamiento de la asignación de módem (600), el retraso de la red interna de CCAP (300), el valor de seguridad avanzada de MAP (1000 ‣ s de forma predeterminada) y el tiempo de desplazamiento máximo del módem (basado en el módem más distante).

Con R-PHY, la demora interna de CCAP ahora se reemplaza por una demora de red, que por defecto es de 500. Teniendo en cuenta el diseño de CIN, este valor puede ser mayor que el parámetro predeterminado y puede cambiar con el tiempo.

Los valores avanzados de MAP para un flujo ascendente se pueden mostrar con 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.

Si la distancia entre el cBR-8 y el RPD combinado con los retrasos de los dispositivos CIN excede el valor predeterminado de retraso de red de 500 s, es posible que se reciban mensajes de MAP tardíos.

Hay dos métodos para tratar el parámetro de demora de red predeterminado cuando esto representa un problema, y ambos se establecen por RPD en cBR-8:

• Configure estáticamente el retraso.
• Configure el cBR-8 para medir y ajustar el retraso periódicamente.

El retraso de red se puede configurar estáticamente por RPD en el cBR-8 como se muestra aquí:

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 la demora de red dinámica, el cBR-8 se basa en una función de medición de latencia llamada Medición de latencia DEPI (DLM), que determina la demora unidireccional en la trayectoria descendente.

El cBR-8 envía un paquete DLM con su marca de tiempo, luego el RPD marca su marca de tiempo en el paquete DLM cuando se recibe y lo reenvía de vuelta al cBR-8.

Tenga en cuenta que Cisco admite la opción requerida en la que el RPD marca el paquete más cercano a su interfaz de ingreso, no a la salida.

El cBR-8 toma el promedio de los últimos 10 valores DLM y lo utiliza como el valor de demora de red en el cálculo de avance de MAP. Las marcas de tiempo tanto del cBR-8 como del RPD se basan en los relojes de referencia PTP.

Advertencia: Si PTP es inestable, también lo son los valores DLM y, en última instancia, el temporizador de avance MAP.

De forma predeterminada, DLM está inhabilitado y se puede habilitar con el comando network-delay dlm <seconds> como se muestra. Una vez habilitado, un paquete DLM se envía al RPD periódicamente de acuerdo con el valor configurado.

También existe una opción solo medida que se puede agregar, que mide simplemente el retraso CIN sin ajustar el valor de retraso de la red.

Se recomienda habilitar DLM como mínimo en el parámetro de solo medida, para monitorear la demora 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

Puede encontrar más información sobre esta función aquí; Medición de latencia DEPI

La seguridad avanzada de MAP también se puede cambiar manualmente en la configuración de la interfaz de cable (los valores predeterminados son 1000 s para el factor de seguridad y 18000 s para el avance máximo de 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

Precaución: los retrasos muy cortos de CIN también pueden causar mensajes de MAP tardíos

Se han observado problemas con el tráfico DOCSIS ascendente descartado cuando el temporizador de avance de MAP es inferior a 2500.

Algunos módems pueden tardar más en procesar los mensajes MAP, y ese retraso adicional puede causar mensajes MAP tardíos para esos módems (el RPD posiblemente no muestre recuentos MAP tardíos si pudo obtener el mensaje a tiempo).

Un temporizador de avance de MAP bajo es posible con valores de DLM muy bajos, o con un retardo de red manual bajo o una configuración de seguridad avanzada de MAP. Los valores de retraso de red en el cálculo de avance de MAP pueden ser tan bajos como 30 s (incluso si el promedio de DLM es más bajo).

Se recomienda utilizar la opción "solo medida" de DLM o aumentar el factor de seguridad para el avance dinámico de MAP hasta que el temporizador de avance de MAP sea superior a 2500.

Causa potencial 2. Error de funcionamiento de software

Para verificar si un error de software causa una falla de sincronización, se recomienda abrir una solicitud de servicio con Cisco para investigar más a fondo el caso específico.

La solución en caso de que usted golpee un defecto de software es generalmente una actualización de software a una de las versiones que contiene la corrección. Dado que existe una correlación de compatibilidad entre las versiones de software de cBR-8 y RPD, es importante elegir la versión correcta para ambos dispositivos.

Para ayudar a elegir el Cisco IOS® XE correcto para cada software RPD, puede encontrar las compatibilidades de la versión de software entre cBR-8 y RPD en las Guías de Instalación y Actualización de PHY Remoto de Cisco.

En esta tabla puede encontrar un resumen de la compatibilidad de la versión de software entre cBR-8 y RPD, con las versiones de software disponibles en el momento de escribir:

Compatibilidad de versiones entre Cisco cBR-8 y Cisco RPD
Versión de lanzamiento de Cisco cBR-8	Versión de lanzamiento de RPD compatible
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	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	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	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

Latencia ascendente

Como se explicó en la sección anterior, los retrasos prolongados de CIN pueden causar problemas tardíos en los mensajes de MAP y pueden solucionarse con el aumento del temporizador de avance de MAP. Esto, a su vez, crea un retraso más largo en la concesión de solicitudes, lo que conduce a una mayor latencia ascendente.

Dado que los flujos de tráfico ascendente constantes utilizan solicitudes de conexión, la prueba de velocidad del tráfico ascendente puede parecer normal, y también los flujos de voz con el servicio de concesión no solicitado (UGS) no se ven afectados, ya que no se necesitan solicitudes.

Sin embargo, las velocidades de tráfico TCP descendente se pueden reducir debido a la falta de ACK ascendentes oportunos. Aunque es posible hacer frente a los retrasos de procesamiento y cola en la CIN, no es probable que las señales viajen más rápido a una distancia determinada.

Cisco ha desarrollado DOCSIS Predictive Scheduling (DPS) para reducir el retraso en la concesión de solicitudes en las aplicaciones R-PHY con mayores retrasos de CIN. DPS proporciona subvenciones a los módems de forma proactiva en función del uso histórico para minimizar el retraso de solicitud-concesión.

DPS es un método de programación previo al estándar, similar a Proactive Grant Service (PGS) descrito en la reciente especificación DOCSIS de baja latencia (LLD).  Sin embargo, DPS se puede habilitar por interfaz y se aplica a todos los flujos de servicio ascendente de mejor esfuerzo. PGS se aplica al tráfico como un tipo de flujo de servicio, por lo que requiere cambios en el archivo de configuración del módem.

DPS se puede habilitar con el comando de interfaz: cbr8(config-if)#cable upstream dps

Aunque DPS ha estado disponible desde que se agregó el soporte R-PHY al cBR-8, no es una función oficialmente soportada en este momento. Sin embargo, DPS puede ser efectivo para resolver el rendimiento descendente lento de TCP asociado con los ACK demorados.

Paquetes de protocolo de tunelación de capa 2 (L2TP) fuera de servicio

En la consola RPD, escriba este comando varias veces para verificar si los contadores "SeqErr-pkts" y "SeqErr-sum-pkts" son positivos y aumentan, lo que es una indicación de paquetes L2TP fuera de orden:

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. Equilibrio de carga

En algunas condiciones particulares, como la congestión de links en la CIN, por ejemplo, el equilibrio de carga puede contribuir al problema de los paquetes recibidos fuera de servicio en el destino.

Si tiene la posibilidad, para verificar si el balanceo de carga genera este problema, puede probar para forzar una sola trayectoria donde se configure el balanceo de carga. Si esto resuelve el problema de los paquetes fuera de servicio, tiene la confirmación del disparador, y puede investigar más la causa raíz en su red.

Causa potencial 2. Descartes de paquetes

1. Verifique si hay errores y caídas mayores en los contadores cBR-8 en la interfaz de la tarjeta DPIC donde está conectado el RPD, con el uso del comando show interface como se muestra aquí.

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 en el lado RPD si hay errores, paquetes perdidos y fuera de orden en las interfaces y los contadores de flujo descendente.

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 los contadores InterLaken descendentes varias veces para ver si hay errores y si los contadores aumentan. Para hacerlo, debe ingresar a la interfaz de la consola de la tarjeta de línea como se muestra aquí.

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. Tome un módem conectado a este RPD (canales DS asociados solamente), y envíe paquetes (por ejemplo, pings) a él, para verificar si los paquetes enviados coinciden con el flujo descendente inyectado en los contadores del módulo JIB. Asegúrese de que DS JIB envió todos los paquetes de datos DS para la trama DEPI en la consola de la tarjeta de línea. En esta salida, puede ver cómo ver el número de secuencia de paquetes de una salida de flujo de servicio de módem. Este número de secuencia aumenta para cada paquete de datos 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

Envíe algunos pings a este módem desde la línea de comandos de cBR-8, en otra ventana:

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#

Compruebe el delta después de la prueba:

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 el delta después de la prueba: el contador es de 16 bits sin signo, por lo que si el contador se desplaza, el delta debe calcularse con esta fórmula:

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

Ejemplo:

Initial Sequence Number = 50967

Final Sequence Number = 2391

Packets sent: 1000000




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

Como consecuencia de la naturaleza de las caídas, el problema puede estar en la CIN (por ejemplo, enlaces de cuello de botella, colisiones, errores CRC) que deben investigarse más a fondo en la red CIN entre el cBR-8 y RPD. Si en cambio se observan caídas en los puntos 3 y 4, se recomienda que Cisco realice una investigación adicional sobre el cBR-8.

Pérdida o desbloqueo de PTP de forma periódica

Como probablemente sabe, el PTP es esencial para las operaciones normales de RPD. Por lo tanto, los paquetes PTP deben tener alta prioridad en QoS, y las caídas de paquetes PTP no son una buena señal.

En la consola RPD, puede mostrar las estadísticas de PTP y verificar que los contadores "DELAY REQUEST" y "DELAY RESPONSE" estén estrechamente emparejados. Si, en cambio, observa una gran brecha, puede ser un indicador de caídas de PTP en la red:

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

Nota: En cBR-8, PTP tiene la prioridad más alta para el reloj, lo que significa que una vez configurado, se utiliza incluso para tarjetas de línea RF. Por lo tanto, una fuente no confiable causaría problemas en todo el chasis.

Para obtener más información sobre la configuración del reloj PTP y la resolución de problemas, puede leer el artículo Recomendaciones de diseño PTP para redes R-PHY.

CIN congestionada

La CIN se puede ver como una extensión del plano de control del núcleo de la CCAP, por lo que si hay 1000 Mbps de DOCSIS y tráfico de vídeo en el flujo descendente para un RPD determinado, se debe asignar esa capacidad en la CIN, más una capacidad adicional para la sobrecarga de L2TPv3 utilizada por los túneles DEPI.

Si hay congestión en la CIN, algunos paquetes pueden retrasarse o perderse.

Causa potencial 1. QoS

De forma predeterminada, el cBR-8 y los RPD marcan los paquetes asociados con el tráfico PTP y los mensajes MAP con DSCP 46 (EF).  Otros mensajes de control DOCSIS como los descriptores de canal ascendente (UCD), la solicitud de ancho de banda del módem y la respuesta de rango también utilizan DSCP 46:

Ítem	Per-Hop-Behavior (PHB)	Valor DSCP
Datos de DOCSIS (L2TP)	Mejor esfuerzo	0
PTP	EF	46
GCP	Mejor esfuerzo	0
MAP/UCD (L2TP, control DOCSIS)	EF	46
BWR y RNG-REG	EF	46
Video	CS4	32
MDD (L2TP, control DOCSIS), voz	CS5	40

Fuente: Guía de configuración del software del dispositivo PHY remoto de Cisco para Cisco 1x2 / Compact Shelf RPD Software 5.x

Las CIN deben tener en cuenta la QoS para que estos paquetes de alta prioridad experimenten un retraso mínimo.

La congestión que crea paquetes perdidos o largos retrasos en las colas ha creado problemas de PTP, mensajes de MAP tardíos y un menor rendimiento. Estos tipos de problemas se pueden observar mediante la observación de las colas de interfaz en los dispositivos cBR-8, RPD y CIN.

Si los mensajes PTP o MAP se descartan o se retrasan, como es evidente con la inestabilidad del reloj o los mensajes MAP tardíos, entonces la capacidad CIN o el diseño de QoS debe ser abordado, ya que estos se envían con alta prioridad.

DLM no está pensado para gestionar breves duraciones de fluctuación porque el ciclo de sondeo mínimo es de un segundo, por lo que no puede eliminar los mensajes de MAP tardíos en este caso.

Causa potencial 2. Tráfico de máximo esfuerzo retrasado

Actualmente, las marcas de paquetes DLM no se pueden configurar y utilizan el mejor esfuerzo (DSCP 0). Ha habido casos en los que las CIN experimentan congestión que provoca un retraso de cola largo limitado al tráfico de mejor esfuerzo.

Esto se ha mostrado típicamente como tasas de tráfico descendente TCP reducidas, ya que las demoras CIN pueden crear caídas de velocidad relativamente grandes debido a los ACK ascendentes perdidos o demorados.

En este caso, no se observan mensajes MAP tardíos o problemas PTP, porque estos paquetes de alta prioridad no se retrasan.

Dado que los paquetes DLM se marcan como tráfico de mejor esfuerzo, este tipo de fluctuación CIN puede causar picos en los valores DLM. Si se utiliza DLM para ajustar dinámicamente el retraso de la red, esta fluctuación puede causar un aumento innecesario en el temporizador de avance de MAP, lo que conduce a mayores retrasos de solicitud-concesión de flujo ascendente.

En este caso, se recomienda utilizar un valor de retraso de red estático. Cisco también estudia las opciones para habilitar los valores DSCP más allá del mejor esfuerzo en DLM en futuras versiones. Esto puede ayudar a reducir el retraso de solicitud-concesión ascendente, pero posiblemente no resuelva los problemas de rendimiento de TCP si los ACK se retrasan en la CIN.

Información Relacionada

• Medición de latencia DEPI
• Recomendaciones de diseño de PTP para redes R-PHY
• Soporte Técnico y Documentación - Cisco Systems