Dépannage des problèmes de performances de débit DOCSIS RPD

Introduction

Ce document décrit comment dépanner les problèmes de performances du périphérique Cisco Remote PHY (RPD).

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• SPR
• Routeur haut débit convergent Cisco (cBR)-8
• Spécification DOCSIS (Data Over Cable Service Interface Specification)

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

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. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

Le scénario considéré dans cet article implique un RPD provisionné par le Cisco cBR-8 en tant que CCAP (Converged Cable Access Platform). Le protocole PTP (Precision Time Protocol) est utilisé pour synchroniser une horloge principale externe avec le cBR-8 et le RPD qui agissent comme horloge secondaire. Pour plus d'informations sur la façon dont la conception PTP dans cet environnement, vous pouvez vous référer à Recommandations de conception PTP pour les réseaux R-PHY.

Il ne s'agit pas d'une liste complète d'étapes permettant de résoudre les problèmes de performances avec RPD, bien que ce soit un bon début pour isoler le problème.

Dépannage

Si vous observez une dégradation des performances avec le déploiement RPD et que vous souhaitez effectuer un dépannage initial, vous ne savez pas exactement par où commencer.

Cette section décrit certains problèmes courants qui peuvent être la cause possible des problèmes de rendement des SPR.

Messages MAP tardifs

Une condition de message tardif d'allocation de bande passante en amont (MAP) se produit lorsqu'un modem reçoit un message MAP à un moment donné, après que les intervalles de temps décrits dans le message se sont déjà produits.  Le modem ne peut pas utiliser ce message MAP, il ne peut donc pas envoyer de trafic sur les autorisations attribuées.

Quelques MAP tardifs peuvent entraîner une réduction des débits de trafic en amont, ainsi qu'une réduction des débits de trafic TCP en aval, car les ACK en amont sont retardés. S'il y a suffisamment de MAP en retard, les modems ne peuvent pas effectuer la maintenance de la station et se déconnecter.

Un autre symptôme peut être l’abandon de paquets lorsque vous envoyez une requête ping docsis <MAC_ADDR> à partir du cBR-8 vers un modem connecté à un RPD.

Avec Remote PHY (R-PHY), le cBR-8 envoie des messages MAP aux modems dans un tunnel DPI (Downstream External PHY Interface) et au RPD dans un tunnel UEPI (Upstream External PHY Interface). Ces messages ont une qualité de service (QoS) supérieure avec une valeur DSCP (Differentiated Services Code Point) de 46 (transfert express - EF).

Si un message MAP destiné à la SPR est abandonné dans le CIN, la SPR n'est pas en mesure d'utiliser ces mini-lots et les comptabilise comme « non mappés ». Si le message MAP arrive en retard au RPD, il compte d'abord les mini-lots comme non mappés, puis, après avoir reçu le MAP en retard, il incrémente le nombre de mini-lots en retard.

Les MAP précoces sont également possibles, mais ne se produisent généralement que lorsque l'horloge PTP est éteinte dans le cBR-8 ou le RPD.

Les MAP se chevauchent parfois lorsque les messages MAP sortent de la séquence, mais avec une fréquence de 2 ms seulement, ce n'est généralement pas un problème. Le nombre réel de mini-lots dans un message MAP est basé sur la configuration de mini-lot pour chaque canal en amont. Si une liaison ascendante utilise deux tops d'horloge par mini-logement (répandu pour le module SC-QAM 6,4 MHz), un MAP de 2 ms comporte 160 mini-logements.

Afin de vérifier si sur le RPD vous recevez des messages MAP tardifs, exécutez ces commandes pour accéder à la console RPD. Exécutez ensuite la commande show upstream map counter <rf port> <channel> plusieurs fois et vérifiez si le compteur « Discarded minislots (late maps) » augmente :

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

Remarque : chaque fois que vous exécutez la commande show upstream map counter, tous les compteurs sont réinitialisés à 0 mais le mini-lot Last mapped

Conseil : à partir de la version 6.x de RPD, vous pouvez exécuter la commande show tech-support, qui collecte plusieurs occurrences de show upstream map counter et d'autres commandes, donc utiles pour la comparaison des compteurs.

Si vous exécutez le logiciel RPD version 5.x ou inférieure, vous pouvez exécuter la commande show tech avec l'utilisation du script disponible ici : Capture show tech on rpd ou commande limitée sur les deux RPD, supervisor.

La page liée contient des instructions sur la façon d'installer le script et des exemples d'utilisation, à la fin de laquelle vous pouvez trouver le fichier Script-Readme.tar disponible pour le téléchargement. Ce fichier contient le script sh_tech_rpd.tcl et le fichier sh_tech_rpd-README.txt avec les instructions et les exemples d'utilisation.

Le script a une option (-c) afin de collecter un ensemble supplémentaire de commandes listées dans un fichier texte, les deux commandes à émettre sur le RPD lui-même et sur le superviseur cBR-8 sont acceptées (toutes les procédures expliquées dans le lien mentionné précédemment et le fichier readme).

Cette fonctionnalité fait l'utilisation de ce script, de façon intéressante, également dans les versions RPD qui incluent la commande show tech-support.

Cause potentielle 1. Délai CIN, latence, gigue

Le réseau d'interconnexion convergée (CIN) qui relie le coeur du CCAP et les RPD peut introduire des retards qui doivent être pris en compte dans le temporisateur d'avance MAP. En cas de modification du CIN, par exemple si un autre routeur a été ajouté, vous avez peut-être introduit un délai plus long.

Le temporisateur avancé MAP est utilisé par le CCAP pour empêcher les messages MAP tardifs. Ce minuteur est basé sur des microsecondes () et peut être configuré de manière statique par l'opérateur par interface de câble ou calculé de manière dynamique par le cBR-8.

La valeur dynamique est la somme de l'intervalle de temps en aval (680 s avec SC-QAM avec 256-QAM), du délai de traitement MAP du modem (600 s), du délai de réseau interne CCAP (300 s), de la valeur de sécurité avancée MAP (1 000 s par défaut) et du décalage temporel maximal du modem (basé sur le modem le plus éloigné).

Avec R-PHY, le délai interne CCAP est désormais remplacé par un délai réseau, qui est de 500 par défaut. Compte tenu de la conception CIN, cette valeur peut être supérieure au paramètre par défaut et peut changer au fil du temps.

Les valeurs d'avance MAP d'un flux ascendant peuvent être affichées avec cette commande :

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 distance entre le cBR-8 et le RPD combinée aux retards des périphériques CIN dépasse la valeur par défaut du retard réseau de 500, des messages MAP tardifs sont possibles.

Il existe deux méthodes pour traiter le paramètre de délai réseau par défaut lorsque cela représente un problème, et les deux sont définies par RPD sur le cBR-8 :

• Configurez le délai de manière statique.
• Réglez le cBR-8 pour mesurer et régler le délai périodiquement.

Le délai réseau peut être configuré de manière statique par RPD sur le cBR-8, comme indiqué ici :

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>

Pour le délai réseau dynamique, le cBR-8 s'appuie sur une fonction de mesure de latence appelée DEPI Latency Measurement (DLM), qui détermine le délai unidirectionnel dans le chemin aval.

Le cBR-8 envoie un paquet DLM avec son horodatage, puis le RPD marque son horodatage sur le paquet DLM lors de sa réception, et le renvoie au cBR-8.

Notez que Cisco prend en charge l'option requise où RPD marque le paquet le plus proche de son interface d'entrée, et non de sa sortie.

Le cBR-8 prend la moyenne des 10 dernières valeurs DLM et l'utilise comme valeur de délai réseau dans le calcul d'avance MAP. Les horodatages du cBR-8 et du RPD sont basés sur les horloges de référence PTP.

Avertissement : si PTP est instable, les valeurs DLM et finalement le temporisateur MAP sont instables.

Par défaut, DLM est désactivé et peut être activé avec la commande network-delay dlm <seconds> comme indiqué. Une fois activé, un paquet DLM est envoyé périodiquement au RPD conformément à la valeur configurée.

Il existe également une option mesure seule qui peut être ajoutée, qui mesure simplement le délai CIN sans ajustement de la valeur de délai réseau.

Il est recommandé d'activer DLM au minimum dans le paramètre de mesure seule, afin de surveiller le délai 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

Pour plus d'informations sur cette fonctionnalité, cliquez ici ; Mesure de la latence DEPI

La sécurité avancée MAP peut également être modifiée manuellement dans la configuration d'interface de câble (les valeurs par défaut sont de 1 000 s pour le facteur de sécurité et de 18000 s pour l'avance maximale) :

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

Attention : des délais CIN très courts peuvent également entraîner des messages MAP tardifs

Des problèmes ont été observés avec le trafic DOCSIS en amont abandonné lorsque le temporisateur d'avance MAP est inférieur à 2500.

Certains modems peuvent prendre plus de temps pour traiter les messages MAP, et ce délai supplémentaire peut entraîner des messages MAP tardifs pour ces modems (la RPD n'affiche peut-être pas le décompte MAP tardif si elle a pu obtenir le message à temps).

Un temporisateur MAP avancé faible est possible avec des valeurs DLM très faibles, ou avec un faible délai de réseau manuel ou une configuration MAP avancée de sécurité. Les valeurs de délai réseau dans le calcul avancé MAP peuvent être aussi basses que 30 s (même si la moyenne DLM est inférieure).

Il est recommandé d'utiliser l'option DLM « mesure seule » ou d'augmenter le facteur de sécurité pour l'avance MAP dynamique jusqu'à ce que le temporisateur d'avance MAP soit supérieur à 2500.

Cause potentielle 2. Bogue logiciel

Afin de vérifier si un bogue logiciel entraîne un échec de synchronisation, il est recommandé d'ouvrir une demande de service auprès de Cisco pour étudier plus en détail le cas spécifique.

La solution au cas où vous rencontriez un défaut logiciel est généralement une mise à niveau logicielle vers l'une des versions qui contient le correctif. Étant donné qu'il existe une corrélation de compatibilité entre les versions logicielles cBR-8 et RPD, il est important de choisir la version appropriée pour les deux périphériques.

Afin de vous aider à choisir le bon Cisco IOS® XE pour chaque logiciel RPD, vous pouvez trouver les compatibilités de version logicielle entre cBR-8 et RPD dans les Guides d'installation et de mise à niveau PHY à distance de Cisco.

Dans ce tableau, vous pouvez trouver un résumé de la compatibilité des versions logicielles entre cBR-8 et RPD, avec les versions logicielles disponibles au moment de la rédaction :

Compatibilité des versions entre Cisco cBR-8 et Cisco RPD
Version de Cisco cBR-8	Version de version compatible RPD
Cisco IOS® XE Everest 16.6.x	Logiciel Cisco 1x2 RPD 2.x
Fuji Cisco IOS® XE 16.7.x	Logiciel Cisco 1x2 RPD 3.x
Fuji Cisco IOS® XE 16.8.x	Logiciel Cisco 1x2 RPD 4.x
Cisco IOS® XE Fuji 16.9.x	Logiciel Cisco 1x2 RPD 5.x
Cisco IOS® XE Gibraltar 16.10.1c	Logiciel Cisco 1x2 RPD 6.1, 6.2, 6.3
Cisco IOS® XE Gibraltar 16.10.1d	Logiciel Cisco 1x2 RPD 6.4, 6.5, 6.7
Cisco IOS® XE Gibraltar 16.10.1f	Logiciel Cisco 1x2 RPD 6.6, 6.7
Cisco IOS® XE Gibraltar 16.10.1g	Logiciel Cisco 1x2 RPD 7.1, 7.2, 7.3, 7.4.x, 7.5
Cisco IOS® XE Gibraltar 16.12.1	Logiciel Cisco 1x2 RPD 7.1, 7.2, 7.3, 7.4.x, 7.5
Cisco IOS® XE Gibraltar 16.12.1w	Logiciel Cisco 1x2 RPD 7.1, 7.2, 7.3, 7.4.x, 7.5
Cisco IOS® XE Gibraltar 16.12.1x	Logiciel Cisco 1x2 RPD 7.6, 7.7
Cisco IOS® XE Gibraltar 16.12.1y	Logiciel Cisco 1x2 RPD 7.8, 7.8.1, 8.2
Cisco IOS® XE Gibraltar 16.12.1z	Logiciel Cisco 1x2 RPD 8.3, 8.4, 8.5
Cisco IOS® XE Gibraltar 17.2.1	Logiciel Cisco 1x2 RPD 8.1, 8.2, 8.3, 8.4, 8.5

Latence en amont

Comme nous l'avons vu dans la section précédente, de longs délais CIN peuvent entraîner des problèmes de messages MAP tardifs et peuvent être résolus par l'augmentation du délai d'avance MAP. Ceci crée à son tour un délai plus long entre la demande et l'octroi, ce qui entraîne une latence en amont accrue.

Puisque les flux de trafic en amont réguliers utilisent des requêtes de connexion, le test de vitesse du trafic en amont peut apparaître normal, et les flux vocaux avec le service d'autorisation non sollicitée (UGS) ne sont pas affectés, car aucune requête n'est nécessaire.

Cependant, les vitesses du trafic TCP en aval peuvent être réduites en raison du manque de accusés de réception en amont en temps voulu. Bien qu'il soit possible d'adresser les retards de traitement et de mise en file d'attente sur le CIN, il est peu probable que les signaux voyagent plus rapidement sur une distance donnée.

Cisco a développé DOCSIS Predictive Scheduling (DPS) pour réduire le délai de demande-subvention dans les applications R-PHY avec des délais CIN plus longs. DPS accorde de manière proactive des autorisations aux modems en fonction de l'utilisation historique, afin de réduire le délai de demande-autorisation.

DPS est une méthode de planification pré-standard, similaire à Proactive Grant Service (PGS) décrit dans la récente spécification Low Latency DOCSIS (LLD).  Cependant, DPS peut être activé par interface et est appliqué à tous les flux de service en amont. Le protocole PGS est appliqué au trafic en tant que type de flux de service. Il nécessite donc des modifications du fichier de configuration du modem.

DPS peut être activé avec la commande d'interface : cbr8(config-if)#cable upstream dps

Bien que DPS soit disponible depuis l'ajout de la prise en charge de R-PHY au cBR-8, il ne s'agit pas d'une fonctionnalité officiellement prise en charge pour le moment. Néanmoins, DPS peut être efficace pour résoudre le débit TCP en aval lent associé aux accusés de réception différés.

Paquets L2TP (Layer 2 Tunneling Protocol) dans le désordre

Sur la console RPD, tapez cette commande plusieurs fois afin de vérifier si les compteurs « SeqErr-pkts » et « SeqErr-sum-pkts » sont positifs et augmentent, ce qui indique que les paquets L2TP sont dans le désordre :

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      

Cause potentielle 1. Équilibrage de charge

Dans certaines conditions particulières, comme l'encombrement des liaisons dans le CIN par exemple, l'équilibrage de charge peut contribuer au problème des paquets reçus dans le désordre à la destination.

Si vous en avez la possibilité, afin de vérifier si l'équilibrage de charge déclenche ce problème, vous pouvez tester pour appliquer un chemin unique où l'équilibrage de charge est configuré. Si cela résout le problème des paquets dans le désordre, vous avez la confirmation du déclencheur et pouvez étudier plus en détail la cause première dans votre réseau.

Cause potentielle 2. Abandons de paquets

1. Vérifiez si les erreurs et les pertes augmentent sur les compteurs cBR-8 sur l'interface de la carte DPIC où le RPD est connecté, en utilisant la commande show interface comme montré ici.

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. Vérifiez du côté RPD s'il y a des erreurs, des paquets abandonnés et dans le désordre sur les interfaces et les compteurs en aval.

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. Vérifiez les compteurs InterLaken en aval plusieurs fois afin de voir s'il y a des erreurs et si les compteurs augmentent. Pour ce faire, vous devez entrer dans l'interface de console de la carte de ligne comme indiqué ici.

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. Prenez un modem connecté à ce RPD (canaux DS liés uniquement) et envoyez-lui des paquets (par exemple, des requêtes ping) afin de vérifier si les paquets envoyés correspondent au flux aval injecté sur les compteurs du module JIB. Assurez-vous que la base de données JIB DS a envoyé tous les paquets de données DS pour la trame DEPI sur la console de la carte de ligne. Dans cette sortie, vous pouvez voir comment voir le numéro de séquence de paquets à partir d'une sortie de flux de service de modem. Ce numéro de séquence augmente pour chaque paquet de données envoyé.

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

Envoyez des requêtes ping à ce modem à partir de la ligne de commande cBR-8, dans une autre fenêtre :

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#

Vérifiez le delta après le test :

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

Calculez le delta après le test : le compteur est non signé sur 16 bits, donc si le compteur est inversé, le delta doit être calculé avec cette formule :

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

Exemple :

Initial Sequence Number = 50967

Final Sequence Number = 2391

Packets sent: 1000000




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

En raison de la nature des abandons, le problème peut se situer dans le CIN (par exemple, des liaisons goulot d'étranglement, des collisions, des erreurs CRC) qui doivent être étudiées plus en détail dans le réseau CIN entre le cBR-8 et le RPD. Si des chutes sont observées aux points 3 et 4, il est recommandé de faire appel à Cisco pour une étude plus approfondie sur le cBR-8.

Perte PTP ou déverrouillage périodique

Comme vous le savez probablement, le PTP est essentiel aux opérations normales de la SPR. Par conséquent, les paquets PTP doivent avoir une priorité élevée dans QoS, et les abandons de paquets PTP ne sont pas un bon signe.

Sur la console RPD, vous pouvez afficher les statistiques PTP et vérifier que les compteurs « DELAY REQUEST » et « DELAY RESPONSE » correspondent étroitement. Si vous voyez un grand écart à la place, il peut être un indicateur de pertes PTP dans le réseau :

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

Remarque : sur cBR-8, PTP a la priorité la plus élevée pour l'horloge, ce qui signifie qu'une fois qu'il est configuré, il est utilisé même pour les cartes de ligne RF. Par conséquent, une source non fiable provoquerait des problèmes sur l'ensemble du châssis.

Pour plus d'informations sur la configuration et le dépannage de l'horloge PTP, vous pouvez lire l'article Recommandations de conception PTP pour les réseaux R-PHY.

CIN encombré

Le CIN peut être considéré comme une extension du plan de contrôle du coeur CCAP, donc s'il y a 1000 Mbits/s de trafic DOCSIS et vidéo en aval pour un RPD donné, alors cette quantité de capacité doit être allouée dans le CIN, plus une certaine capacité supplémentaire pour la surcharge L2TPv3 utilisée par les tunnels DEPI.

En cas d’encombrement du CIN, certains paquets peuvent être retardés ou perdus.

Cause potentielle 1. QoS

Par défaut, le cBR-8 et les RPD marquent les paquets associés au trafic PTP et les messages MAP avec le DSCP 46 (EF).  D'autres messages de contrôle DOCSIS, tels que les descripteurs de canal en amont (UCD), la demande de bande passante du modem et la réponse de plage, utilisent également DSCP 46 :

Élément	Comportement par saut (PHB)	Valeur DSCP
Données DOCSIS (L2TP)	Meilleur effort	0
PTP	EF	46
GCP	Meilleur effort	0
MAP/UCD (L2TP, contrôle DOCSIS)	EF	46
BWR et RNG-REG	EF	46
Vidéo	CS4	32
MDD (L2TP, contrôle DOCSIS), voix	CS5	40

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

Le CIN doit être sensible à la QoS afin que ces paquets de priorité élevée subissent un délai minimal.

L'encombrement qui crée des paquets abandonnés ou de longs délais de file d'attente a créé des problèmes PTP, des messages MAP tardifs et un débit réduit. Ces types de problèmes peuvent être observés en observant les files d'attente d'interface sur les périphériques cBR-8, RPD et CIN.

Si des messages PTP ou MAP sont abandonnés ou retardés, comme cela est évident avec l'instabilité de l'horloge ou les messages MAP tardifs, alors la capacité CIN ou la conception QoS doit être prise en compte, car ils sont envoyés avec une priorité élevée.

DLM n'est pas conçu pour gérer les courtes durées de gigue, car le cycle d'interrogation minimum est d'une seconde. Il ne peut donc pas éliminer les messages MAP tardifs dans ce cas.

Cause potentielle 2. Trafic au mieux retardé

Actuellement, les marques de paquets DLM ne sont pas configurables et utilisent le meilleur effort (DSCP 0). Dans certains cas, le CIN connaît une congestion qui entraîne un long délai de file d'attente limité au trafic au mieux.

Cela se traduit généralement par une réduction des débits de trafic TCP en aval, car les retards CIN peuvent créer des pertes de vitesse relativement importantes en raison d'ACK en amont manqués ou retardés.

Dans ce cas, aucun message MAP tardif ou problème PTP n'est observé, car ces paquets de priorité élevée ne sont pas retardés.

Puisque les paquets DLM sont marqués comme trafic au mieux, ce type de gigue CIN peut provoquer des pics dans les valeurs DLM. Si DLM est utilisé pour régler dynamiquement le délai réseau, cette gigue peut entraîner une augmentation inutile du temporisateur d'avance MAP, ce qui entraîne une augmentation des délais d'octroi de requête en amont.

Dans ce cas, il est recommandé d'utiliser une valeur de délai réseau statique. Cisco étudie également les options permettant d'activer les valeurs DSCP au-delà du simple meilleur effort sur DLM dans les prochaines versions. Cela peut aider à réduire le délai d'octroi de requête en amont, mais ne résout peut-être pas les problèmes de débit TCP si les accusés de réception sont retardés dans le CIN.

Informations connexes

• Mesure de la latence DEPI
• Recommandations de conception PTP pour les réseaux R-PHY
• Technical Support & Documentation - Cisco Systems