Résolution des problèmes de performances dans les réseaux constitués de modems câbles

Introduction

Un certain nombre de problèmes peuvent affecter la performance et la vitesse des modems câble dans un système Data-over-Cable Service Interface Specifications (DOCSIS). Ce document cherche à décrire les principales causes du ralentissement du débit du point de vue d’un prestataire de services par câble.

Ce document examine d'abord comment déterminer avec précision les niveaux de débit qu'un utilisateur final atteint et comment s'assurer que les performances mesurées sont celles du réseau câblé plutôt que celles d'Internet en général.

La section suivante examine les raisons les plus courantes de la lenteur des performances et propose des solutions. Ces questions comprennent :

• Performances limitées par les limites du fichier de configuration DOCSIS.

• Performances de téléchargement en rafale ou inconstantes dues à l'utilisation d'un schéma de limitation de débit sous-optimal sur le système de terminaison de modem câble (CMTS).

• Congestion des canaux en amont et en aval.

• Réseau de liaison ou encombrement Internet.

• Bruit ou erreurs sur le câblage.

• Sous équipement d'abonné (CPE) alimenté.

Chacun de ces éléments, individuellement ou en combinaison, peut affecter le débit et les performances d’un réseau câblé.

Ce document ne traite pas du dépannage d'une perte totale de connectivité sur le réseau câblé ou de modems câble ne se connectant pas. Reportez-vous plutôt à la section Dépannage des modems câble uBR qui ne sont pas disponibles en ligne pour ce type de problème.

Avant de commencer

Conditions préalables

Aucune condition préalable spécifique n'est requise pour ce document.

Components Used

Les informations dans ce document sont basées sur les versions de logiciel et de matériel ci-dessous.

• Logiciel Cisco IOS® Version 12.1(9)EC pour les CMTS uBR7200 et uBR7100.

• Gamme de produits CMTS Cisco uBR7100, uBR7200 et uBR7200VXR.

• Les informations de ce document sont pertinentes pour toutes les autres versions actuellement disponibles du logiciel Cisco IOS basé sur DOCSIS 1.0 pour les équipements CMTS de marque Cisco.

Les informations présentées dans ce document ont été créées à partir de périphériques dans un environnement de laboratoire spécifique. All of the devices used in this document started with a cleared (default) configuration. Si vous travaillez dans un réseau opérationnel, assurez-vous de bien comprendre l'impact potentiel de toute commande avant de l'utiliser.

Détermination précise des niveaux de performance atteints

Mesure des parties correctes du système

Il existe plusieurs façons d'évaluer la vitesse et les performances d'un système, mais il est important de comprendre exactement quelles parties du système sont testées. Considérez le schéma ci-dessous.

Figure 1 (Pour voir ce diagramme en format vidéo, cliquez ici.)

Dans ce diagramme, il y a plusieurs composants :

• Réseau hybride fibre optique coaxial entre l'utilisateur final et le CMTS.

• Segment de réseau CMTS local auquel le CMTS se connecte au réseau du fournisseur de services câblés.

• Réseau interne du fournisseur de services câblés.

• Internet public.

Lors d'un test de vitesse entre deux points, la vitesse de tous les composants réseau entre les deux points est mesurée.

Par exemple, si vous effectuez un test de vitesse entre le CPE et le serveur 3, qui est connecté à Internet via une ligne RNIS 128 Kbits/s, il n’y aura jamais de débits supérieurs à 128 Kbits/s, même si la bande passante disponible sur le segment de câble est supérieure à 128 Kbits/s.

La méthode la plus précise pour mesurer les performances du segment de câble lui-même consiste à effectuer un test de vitesse entre l’équipement d’abonné et le serveur 1, qui est connecté au même segment de réseau que le CMTS. En effet, le seul chemin que les données doivent parcourir est le segment de câble coaxial. Les données doivent également circuler sur le segment de réseau CMTS local, mais il est présumé que ce segment est à large bande passante (FastEthernet ou supérieur) et ne présente pas un niveau élevé de congestion.

Si, pour une raison quelconque, aucun serveur ne peut être connecté au segment de réseau CMTS local, la prochaine façon la plus précise de tester les performances du segment de câble consiste à effectuer un test de vitesse entre le CPE et le serveur 2. Il s'agit d'une mesure précise tant qu'il existe des liaisons à haut débit et non encombrées adéquates au sein du réseau interne du fournisseur de services câblés entre le CMTS et le CPE.

La manière la plus inexacte de déterminer les performances du segment de câble consiste à effectuer un test de vitesse entre l’équipement d’abonné et un serveur sur l’Internet public. En effet, il peut y avoir des liaisons encombrées dans l'Internet public entre le CPE et le serveur, ou il peut y avoir des liaisons à très basse vitesse dans le chemin entre le CPE et le serveur sur Internet.

Détermination du débit de téléchargement et de téléchargement

Il est très important de pouvoir obtenir une mesure objective des niveaux exacts de débit de téléchargement et de téléchargement avant de tirer des conclusions sur l'existence d'un problème de performances dans un système DOCSIS.

Le moyen le plus simple de déterminer la vitesse à laquelle les téléchargements et téléchargements se produisent est de télécharger ou de télécharger un fichier volumineux via FTP ou HTTP entre un périphérique CPE connecté à un modem câble et un serveur derrière le CMTS. La plupart des clients FTP et HTTP peuvent afficher la vitesse à laquelle un téléchargement ou un téléchargement se produit pendant le transfert ou une fois le transfert terminé. La vitesse de transfert observée à la suite de l'opération FTP ou HTTP représente généralement environ 90 % du débit total réel atteint. Ceci est dû au fait que la vitesse de transfert FTP ou HTTP affichée ne prend pas en compte la surcharge IP et DOCSIS supplémentaire qui doit circuler entre le périphérique CPE et le CMTS.

Il existe des méthodes plus précises de mesure du débit, par exemple en utilisant un équipement de test tiers dédié, tel qu'un Smartbits Netcom ou un générateur de paquets IXIA. Cependant, ces systèmes ne sont pas toujours facilement disponibles ou facilement connectés à un réseau de câblage de production. Il est important de noter que si des tests de débit sont effectués dans un environnement de laboratoire, l'utilisation d'un périphérique dédié révélera beaucoup plus d'informations que le simple test de téléchargement FTP ou HTTP.

Remarque : Le test de téléchargement et de téléchargement basé sur FTP ou HTTP n'est fiable que pour des vitesses de test d'environ 3 Mbits/s ou moins. À des vitesses plus élevées, la puissance de traitement du périphérique CPE, du serveur ou des cartes d'interface réseau (NIC) peut devenir un facteur limitatif dans le test. Pour les débits de test supérieurs à environ 3 Mbits/s, un équipement de test du débit de données dédié doit être utilisé.

Dans l'exemple suivant, un simple test de téléchargement et de téléchargement FTP est effectué entre un périphérique CPE connecté à un modem câble et un serveur FTP sur le réseau du fournisseur de services câblés. Le modem câble a téléchargé un fichier de configuration DOCSIS qui permet une vitesse de téléchargement maximale de 256 Kbits/s et une vitesse de téléchargement maximale de 64 Kbits/s. Dans ce test, un fichier de 3 Mo a été placé sur le serveur FTP à l'adresse IP 172.17.110.132. L'utilisateur du périphérique CPE reçoit un nom d'utilisateur et un mot de passe afin de pouvoir se connecter au serveur FTP afin qu'il puisse télécharger ce fichier à partir du serveur FTP, puis le recharger sur le serveur FTP. L'utilitaire FTP de ligne de commande est utilisé pour effectuer le transfert. Cet utilitaire est disponible dans pratiquement toutes les versions de Microsoft Windows et UNIX.

Un test similaire est effectué en configurant un serveur Web HTTP sur le réseau du fournisseur de services et en effectuant un téléchargement HTTP.

Figure 2

Note: 
!--- Comments are in blue.

C:\>ftp 172.17.110.132                    


!--- Initiate the FTP session to the server.
 

Connected to 172.17.110.132. 
220 Solaris FTP server (SunOS 5.6) ready. 
User (172.17.110.132:(none)): anonymous    


!--- Enter the FTP server username.
 

331 Guest login ok, send your complete e-mail address as password. 
Password: user@samplenetwork.com.au       


!--- Enter the FTP server password. 


230 User anonymous logged in. 
ftp> dir                                  


!--- View the contents of the current directory.
 

200 PORT command successful. 
150 ASCII data connection for /bin/ls (64.104.207.118,1282) (0 bytes). 
total 74932 
-rw-r--r--   1 root     other    3276800 Oct 10 19:31 cable.txt   


!--- A 3 M file that you can download.


226 ASCII Transfer complete. 
ftp: 105 bytes received in 0.12 Seconds 2.46 Kbytes/sec. 
ftp> bi                                  


!--- Turn on Binary File transfer mode.


200 Type set to I. 
ftp> get cable.txt                       


!--- Retrieve the file cable.txt and wait for it to download.
 
200 PORT command successful. 
150 Binary data connection for cable.txt (192.168.1.13,3154) (3276800 bytes). 
226 Binary Transfer complete. 
ftp: 3276800 bytes received in 111.35 Seconds 29.43 Kbytes/sec. 


!--- Download complete. It seems that the download occurred !--- at 29.43 Kbytes/sec, which equals 235 Kbits/sec. This is about 90 percent of !--- the allowed 256 Kbps download rate for the modem being tested.
 

ftp> put cable.txt                       


!--- Begin uploading the file. You need to make sure you have !--- the correct access in order to upload a file to the FTP server or !--- you may get an access-denied error.
 

200 PORT command successful. 
150 Binary data connection for cable.txt (192.168.1.13,3157). 
226 Transfer complete. 
ftp: 3276800 bytes sent in 432.49 Seconds 7.58 Kbytes/sec. 


!--- Upload Complete. Here you see the upload !--- occurred at 7.58 Kbytes/sec, !--- which is equivalent to 60.64 Kbits/sec. This !--- is about 90 percent of the allowed !--- 64 Kbps upload rate for the modem being tested.
 

ftp> quit                                


!--- Exit the FTP client application.
 
221 Goodbye.

Pendant le transfert FTP, il est possible de surveiller la progression du test sur le CMTS à l'aide de la commande show interface cable X/Y sid Z counters où le câble X/Y est l'interface de câble à laquelle le modem testé est connecté et Z est le numéro d'ID de service (SID) du modem testé. Cette commande indique le nombre d'octets transférés depuis ou vers un modem câble particulier. Par exemple, si le CPE testé se trouve derrière un modem câble avec l'adresse MAC 001.9659.4461.

Recherchez d'abord le numéro SID du modem testé à l'aide de la commande show cable modem. Dans ce cas, le SID du modem câble est 5.

uBR7246-VXR# show cable modem 0001.9659.4461 
Interface   Prim Online     Timing Rec    QoS CPE IP address      MAC address 
            Sid  State      Offset Power 
Cable3/0/U0 5    online     1996    0.25  5   2   10.1.1.24       0001.9659.4461

Pendant que le téléchargement est en cours, effacez tous les compteurs de paquets du CMTS à zéro à l'aide de la commande clear counters. Lorsque les compteurs sont désactivés, démarrez un chronomètre ou un minuteur.

uBR7246-VXR# clear counters              


!--- Reset packet counter to zero.

 
Clear "show interface" counters on all interfaces [confirm]     


!--- Start the stopwatch when you hit Enter.

Une fois que le chronomètre ou l'heure a lu exactement une minute, exécutez la commande show interface cable X/Y sid Z counters. Il peut être préférable de taper la commande d'abord, puis d'appuyer sur Entrée exactement lorsque le compteur indique une minute. Le test peut être effectué sur une période plus longue ou plus courte. Plus la période de test est longue, plus le résultat est précis, mais assurez-vous que le téléchargement ou le téléchargement ne se termine pas avant que le chronomètre atteigne le temps spécifié, sinon la mesure est inexacte.

uBR7246-VXR# show interface cable 3/0 sid 5 counters     


!--- Hit enter when stopwatch is at exactly one minute.
 
Sid   Inpackets  Inoctets   Outpackets Outoctets  Ratelimit  Ratelimit 
                                                  BWReqDrop  DSPktDrop 
5     4019       257216     3368       1921488    0          149 

uBR7246-VXR# 

Dans ce cas, la vitesse de téléchargement est testée. Le résultat de la commande show interface cable X/Y sid Z counter indique que sur une période d'une minute, 1 921 488 octets sont téléchargés par le modem câble. La conversion de 1 921 488 octets en bits révèle :

8 bits per byte * 1,921,488 bytes = 15,371,904 bits.

Ensuite, pour trouver le taux de téléchargement en bits par seconde, divisez ce nombre total de bits téléchargés par le temps nécessaire pour les télécharger en secondes.

15,371,904 bits / 60 seconds = 256 Kbps.

Le débit de téléchargement dans cet exemple est d'environ 256 Kbits/s, ce qui correspond au débit de téléchargement autorisé pour le modem câble testé.

Afin d'examiner la vitesse de chargement à l'aide de la commande show interface cable X/Y sid Z counters, la colonne Inoctets doit être utilisée pour déterminer le nombre d'octets envoyés dans la direction amont à partir du modem câble.

Reportez-vous au Guide de référence des commandes du câble à large bande Cisco pour plus d'informations sur la commande show interface cable sid counters.

Raisons potentielles de mauvaises performances

Performances limitées par le fichier de configuration DOCSIS

La première information à collecter lors du dépannage des performances lentes du modem câble est la classe de débit prescrite du modem câble. Lorsqu'un modem câble est mis en ligne, il télécharge un fichier de configuration DOCSIS qui contient les limites opérationnelles du modem câble, y compris les débits maximaux de téléchargement et de téléchargement. Dans des circonstances normales, le modem câble ne peut pas dépasser ces débits.

Au départ, il est nécessaire d’identifier l’adresse MAC d’un modem câble présentant des problèmes. Prise d'un modem avec l'adresse MAC 0050.7366.2223 qui a des problèmes avec un débit lent,. il est nécessaire de connaître la classe de profil de service utilisée par ce modem câble en exécutant la commande show cable modem <mac-address> comme indiqué dans l’exemple ci-dessous.

uBR7246-VXR# show cable modem 0050.7366.2223 
Interface   Prim Online     Timing Rec    QoS CPE IP address      MAC address 
            Sid  State      Offset Power 
Cable3/0/U1 1    online     1548    0.75  5   0   10.1.1.10       0050.7366.2223

Ici, il montre que ce modem câble a un profil de qualité de service (QoS) de 5. Afin de savoir à quels débits en aval et en amont correspond ce profil QoS, utilisez la commande show cable qos profile profile-number, où profile-number est le profil QoS intéressant.

uBR7246-VXR# show cable qos profile 5 
ID  Prio Max       Guarantee Max        Max   TOS  TOS   Create  B     IP prec. 
         upstream  upstream  downstream tx    mask value by      priv  rate 
         bandwidth bandwidth bandwidth  burst                    enab  enab 
5   0    64000     0         256000     1600  0x0  0x0   cm      no    no

Ici, il montre que le profil QoS 5 correspond à un service fournissant 256 Kbits/s en aval et 64 Kbits/s en amont. Tout équipement d’abonné connecté à des modems câble utilisant le profil QoS 5 ne peut pas dépasser ces limites. Les paramètres de profil QoS sont déterminés par le contenu des fichiers de configuration DOCSIS téléchargés par les modems câble à partir du serveur TFTP du système d'approvisionnement. Par conséquent, le profil QoS 5 du système peut ne pas être identique au profil QoS 5 dans l'exemple ci-dessus.

Si les performances de téléchargement et de téléchargement d'un utilisateur final correspondent aux limites indiquées dans son profil QoS, il obtient la classe de service et les niveaux de débit pour lesquels le modem câble a été provisionné et configuré. La seule façon d'augmenter le débit de téléchargement et de téléchargement consiste à remplacer le fichier de configuration DOCSIS téléchargé par le modem câble par un fichier dont le débit est plus élevé. Reportez-vous au document intitulé Création de fichiers de configuration DOCSIS 1.0 à l'aide de Cisco DOCSIS Configurator pour obtenir des instructions détaillées sur la création ou la modification d'un fichier de configuration DOCSIS.

Utilisation d'une méthode sous-optimale de limitation de débit

Lorsqu'un utilisateur final tente de télécharger des données à partir d'Internet à un débit supérieur à celui autorisé par le fichier de configuration DOCSIS de son modem câble, le CMTS doit limiter le débit du trafic envoyé à cet utilisateur afin de s'assurer qu'il ne consomme pas plus que sa part de bande passante autorisée.

De même, lorsqu'un utilisateur final tente de télécharger ou d'envoyer des données sur Internet à un débit supérieur à celui autorisé par le fichier de configuration DOCSIS, le modem câble lui-même doit empêcher le trafic excédentaire de circuler sur le segment de câble vers le CMTS. Si, pour une raison quelconque, le modem câble ne parvient pas à effectuer correctement la limitation de débit en amont, le CMTS interdit explicitement au modem câble de transmettre des données supérieures à la vitesse autorisée. Ce comportement sur le CMTS consiste à s'assurer que même un modem câble avec des caractéristiques « piratées » ne peut pas contourner les limites de débit de téléchargement attribuées par le fournisseur de services.

Le schéma de limitation de débit par défaut utilisé par le CMTS contrôle le débit du trafic à destination ou en provenance de chaque modem câble sur une période d’une seconde. Si le modem câble envoie ou reçoit plus de son quota par seconde en moins d'une seconde, le CMTS n'autorise pas le trafic supplémentaire vers ce modem câble pour le reste de la seconde.

Par exemple, prenez un modem câble avec un profil QoS permettant un débit de téléchargement de 512 Kbits/s. Si le modem câble télécharge 512 kilobits (64 kilo-octets) dans la première moitié d'une seconde, alors pour la seconde moitié, le modem câble n'est pas autorisé à télécharger quoi que ce soit. Ce type de comportement de limitation de débit peut avoir l'effet d'un modèle de téléchargement par rafale qui semble s'arrêter et commencer toutes les secondes ou deux.

Le meilleur schéma de limitation de débit en aval est l'algorithme de limitation de débit du segment de jeton avec formatage du trafic. Ce système de limitation de débit a été optimisé pour permettre une navigation Web fluide à un rythme régulier, tout en veillant à ce que les utilisateurs finaux ne soient pas autorisés à dépasser le débit de téléchargement prescrit tel que spécifié dans le fichier de configuration DOCSIS.

Ce schéma permet de mesurer le débit auquel un modem câble télécharge ou télécharge des données chaque fois qu’un paquet est envoyé à ou depuis le modem câble. Si l'envoi ou la réception du paquet en question entraîne le dépassement du débit de transfert autorisé par le modem, le paquet est mis en mémoire tampon ou mis en cache dans la mémoire CMTS jusqu'à ce que le CMTS puisse envoyer le paquet sans dépasser la limite de bande passante en aval.

Remarque : si le débit de trafic en aval dépasse constamment le débit autorisé en aval pour le modem câble, les paquets sont finalement abandonnés.

En utilisant cette méthode plus douce de limitation et de formatage de débit, la plupart des applications Internet basées sur TCP, telles que la navigation Web HTTP et les transferts de fichiers FTP, fonctionnent plus facilement et efficacement que lors de l'utilisation du schéma de limitation de débit par défaut.

Le schéma de limitation du débit du compartiment à jetons avec formatage du trafic peut être activé sur le chemin en aval d’une interface de câble en exécutant la commande de configuration d’interface de câble suivante :

uBR7246-VXR(config-if)# cable downstream rate-limit token-bucket shaping

Remarque : Il est fortement recommandé d'activer le formatage de compartiments à jetons sur le CMTS de l'utilisateur. Cette commande est prise en charge depuis les versions 12.0(5)T1 et 12.1(1)EC1 du logiciel Cisco IOS.

Le regroupement de jetons avec le schéma de formatage du trafic peut également être appliqué aux ports en amont, mais comme il incombe aux modems câble d'effectuer la limitation de débit en amont, le schéma de limitation de débit en amont appliqué au CMTS n'aura normalement aucun impact sur les performances d'un système.

uBR7246-VXR(config-if)# cable upstream 0 rate-limit token-bucket shaping

Reportez-vous au Guide de référence des commandes du câble à large bande de Cisco pour plus d'informations sur les commandes cable aval rate-limit et cable amont rate-limit.

Les utilisateurs peuvent voir à quel point le CMTS limite le trafic à un modem câble particulier à l'aide de la commande show interface cable X/Y sid <Z> counters, où le câble X/Y est l'interface de câble à laquelle le modem câble est connecté, et Z le numéro SID du modem observé. Cette commande indique le nombre de fois où le CMTS a abandonné un paquet en aval ou refusé d'autoriser un paquet en amont en raison du dépassement par le modem de ses limites de débit autorisées. Si aucune valeur n'est spécifiée pour Z, les informations de compteur pour tous les modems câble connectés au câble d'interface X/Y s'affichent.

uBR7246-VXR# show interface cable 3/0 sid 5 counters 
Sid   Inpackets  Inoctets   Outpackets Outoctets  Ratelimit  Ratelimit 
                                                  BWReqDrop  DSPktDrop 
5     150927     9662206    126529     72008199   0          5681

Le champ Ratelimit DSPktDrop indique combien de fois le CMTS a abandonné des paquets destinés au modem câble en raison de la tentative du modem de dépasser son débit en aval autorisé.

Le champ Ratelimit BWReqDrop indique combien de fois le CMTS a refusé de laisser un modem câble envoyer un paquet dans le chemin d'amont en raison de la tentative du modem de dépasser son débit en amont autorisé. Dans la plupart des cas, ce compteur doit toujours rester à 0. S’il monte significativement au-dessus de zéro, il se peut que le modem câble observé ne réalise pas correctement la limitation de débit en amont.

Remarque : Les valeurs affichées par la commande show interface cable X/Y sid Z counters peuvent être réinitialisées à zéro en exécutant la commande clear counters comme indiqué dans l'exemple ci-dessous.

uBR7246-VXR# show interface cable 3/0 sid counters 
Sid   Inpackets  Inoctets   Outpackets Outoctets  Ratelimit  Ratelimit 
                                                  BWReqDrop  DSPktDrop 
1     7          1834       7          1300       0          0 
2     2052       549150     0          0          0          0 
3     2          1244       2          708        0          0 
4     2          1244       2          714        0          0 
5     160158     10253220   134294     76423270   0          6023 
6     2          1244       2          712        0          0 
7     9          1906       4          858        0          0 
9     6          1076       3          483        0          0 
12    616        165424     0          0          0          0 
uBR7246-VXR# clear counters 
Clear "show interface" counters on all interfaces [confirm] <press enter here> 
uBR7246-VXR# show interface cable 3/0 sid counters 
Sid   Inpackets  Inoctets   Outpackets Outoctets  Ratelimit  Ratelimit 
                                                  BWReqDrop  DSPktDrop 
1     0          0          0          0          0          0 
2     0          0          0          0          0          0 
3     0          0          0          0          0          0 
4     0          0          0          0          0          0 
5     111        7104       92         52728      0          6 
6     0          0          0          0          0          0 
7     0          0          0          0          0          0 
9     0          0          0          0          0          0 
12    0          0          0          0          0          0

Reportez-vous au Guide de référence des commandes du câble à large bande Cisco pour plus d'informations sur la commande show interface cable sid counters.

Congestion des canaux en amont

Le canal en amont est normalement la ressource la plus précieuse dans un système de câblage. Actuellement, la plupart des fournisseurs de services de câblage utilisent une largeur de canal de 1,6 MHz et une modulation QPSK (Quadrature Phase Shift Keying) dans le chemin en amont. Cela équivaut à environ 2,5 Mbits/s de bande passante en amont disponible pour tous les utilisateurs connectés au canal en amont. Il est important de s'assurer que le canal en amont ne devient pas surutilisé ou encombré, sinon tous les utilisateurs de ce segment en amont souffrent de mauvaises performances.

L'utilisation en amont d'un port en amont particulier peut être obtenue en exécutant la commande CMTS show interface cable X/Y en amont <Z>, où cable X/Y est le numéro d'interface en aval et Z le numéro de port en amont. Si Z est omis, les informations relatives à tous les flux ascendants sur le câble d'interface X/Y s'affichent. Reportez-vous au Guide de référence des commandes du câble à large bande Cisco pour plus d'informations sur la commande show interface cable en amont.

uBR7246-VXR# show interface cable 6/0 upstream 0 
     Cable6/0: Upstream 0 is up 
     Received 71941 broadcasts, 27234 multicasts, 8987489 unicasts 
     0 discards, 140354 errors, 0 unknown protocol 
     9086664 packets input, 4394 uncorrectable 
     122628 noise, 0 microreflections 
     Total Modems On This Upstream Channel : 359 (354 active) 
     Default MAC scheduler 
     Queue[Rng Polls]  0/64, fifo queueing, 0 drops 
     Queue[Cont Mslots]  0/104, fifo queueing, 0 drops 
     Queue[CIR Grants]  0/64, fair queueing, 0 drops 
     Queue[BE Grants]  0/64, fair queueing, 0 drops 
     Queue[Grant Shpr]   0/64, calendar queueing, 0 drops 
     Reserved slot table currently has 0 CBR entries 
     Req IEs 64609697, Req/Data IEs 0 
     Init Mtn IEs 521851, Stn Mtn IEs 569985 
     Long Grant IEs 2781600, Short Grant IEs 2067668 
     Avg upstream channel utilization : 18% 
     Avg percent contention slots : 77% 
     Avg percent initial ranging slots : 2% 
     Avg percent minislots lost on late MAPs : 0% 
     Total channel bw reserved 37858000 bps 
     CIR admission control not enforced 
     Admission requests rejected 0 
     Current minislot count   : 7301855    Flag: 0 
     Scheduled minislot count : 7301952    Flag: 0

Sur le port en amont vu dans l'exemple, l'utilisation en amont est actuellement de 18 % et 359 modems sont connectés à ce port en amont.

Si l'utilisation du canal en amont est constamment supérieure à 75 % pendant la période de pointe, les utilisateurs finaux commencent à souffrir de problèmes tels que la latence, des temps de requêtes ping plus lents et une expérience Internet généralement plus lente. Si l'utilisation du canal en amont est constamment supérieure à 90 % pendant la période de pointe, les utilisateurs finaux connaissent un niveau de service extrêmement faible, car une grande partie des données en amont de l'utilisateur final devra être retardée ou rejetée.

L'utilisation des canaux en amont change au cours de la journée, car différents utilisateurs ont la possibilité d'utiliser leur modem câble. Il est donc important de surveiller l'utilisation en amont pendant les heures les plus chargées de la journée plutôt qu'à des heures d'utilisation réduites.

Les moyens de soulager la congestion en amont sont les suivants :

• Réduction du nombre de modems câble par câble en amont : s'il y a trop de modems câble connectés à un câble en amont particulier, ou si les utilisateurs d'un câble en amont particulier sont de gros utilisateurs de la bande passante en amont, la meilleure solution consiste à déplacer certains utilisateurs sur le port en amont congestionné vers un port en amont sous-utilisé, ou vers un port en amont complètement nouveau. Pour ce faire, il faut généralement déplacer un noeud de fibre d'un groupe de combinaison amont à un autre, ou diviser un groupe de combinaison amont en deux groupes de combinaison distincts. Pour plus d'informations, référez-vous à Quel est le nombre maximal d'utilisateurs par CMTS.

• Augmenter la largeur du canal en amont - Ceci implique une analyse rigoureuse et approfondie du spectre en amont afin de trouver une bande suffisamment large avec des caractéristiques de rapport signal-bruit (SNR) adéquates pour prendre en charge l'augmentation de la largeur du canal. La largeur du canal en amont ne doit pas être modifiée sans une planification minutieuse, car cette modification peut affecter d'autres services du système de câblage de l'utilisateur. La largeur du canal en amont peut être modifiée à l'aide de la commande cable interface cable (câble en amont) Z channel-width <new-channel-width> où Z est le numéro du port en amont et où la nouvelle largeur du canal est l'une des valeurs suivantes : 200000, 400000, 8000, ou par défaut 3200000. Voici un exemple.

  uBR7246-VXR(config-if)# cable upstream 0 channel-width 3200000
  

  Reportez-vous au Guide de référence des commandes du câble à large bande Cisco pour plus d'informations sur la commande show interface cable en amont.

• Remplacer le schéma de modulation numérique en amont par la modulation d'amplitude à 16 quadratures (MQ) - Une fois de plus, cela nécessite une analyse rigoureuse et approfondie du spectre en amont afin de vérifier s'il existe une bande de fréquences en amont disponible qui peut supporter la modulation à 16 QAM. Si cette analyse n'est pas effectuée correctement, il y a un risque que les performances soient encore réduites ou qu'une panne en amont complète se produise. Le schéma de modulation en amont peut être modifié en créant un profil de modulation en amont qui utilise la modulation 16-QAM, puis en l'appliquant à un port en amont. Voici un exemple.

  uBR7246-VXR(config)# cable modulation-profile 2 mix    
  
  
  !--- Create an optimized 16-qam/qpsk modulation profile.
   
  uBR7246-VXR(config)# interface cable 6/0 
  uBR7246-VXR(config-if)# cable upstream 0 modulation-profile 2
  
  

  Reportez-vous au Guide de référence des commandes du câble à large bande de Cisco pour plus d'informations sur les commandes cable modulation-profile et cable-amont modulation-profile. Voir aussi Configuration des profils de modulation de câble sur les systèmes de terminaison de modem câble de Cisco.

• Réduction du débit en amont autorisé par modem câble - En réduisant le débit maximal de transmission en amont dans les fichiers de configuration DOCSIS appropriés, les utilisateurs de modem câble ne peuvent pas transmettre à un débit aussi élevé dans la direction en amont et la congestion en amont est soulagée. L'aspect négatif de cette action est que les utilisateurs de modem câble sont limités à une classe de service plus lente. Reportez-vous à Création de fichiers de configuration DOCSIS 1.0 à l'aide de Cisco DOCSIS Configurator.

Note : Les mesures décrites dans cette section n'augmentent pas significativement les performances d'un système déjà encombré.

Congestion des canaux en aval

Le canal en aval a beaucoup plus de bande passante à partager qu'un canal en amont individuel. Par conséquent, le canal en aval n'est généralement pas aussi sujet à la congestion que le canal en amont. Cependant, plus d'utilisateurs partagent généralement un canal en aval que n'importe quel canal en amont, de sorte que si le canal en aval devient encombré, tous les utilisateurs connectés au segment en aval subissent des performances réduites.

Le tableau ci-dessous indique la bande passante descendante totale disponible associée aux quatre schémas de modulation descendante possibles disponibles dans les systèmes DOCSIS.

Schéma de modulation en aval	Bande passante descendante disponible
DOCSIS nord-américain 64-QAM	27 Mbits/s
DOCSIS nord-américain 256-QAM	38 Mbits/s
DOCSIS Euro 64-QAM	38 Mbits/s
DOCSIS Euro 256-QAM	54 Mbit/s

La majorité des systèmes câblés DOCSIS déploient actuellement un DOCSIS nord-américain 64-QAM et disposent donc de 27 Mbits/s par canal en aval.

L'utilisation du canal en aval peut être déterminée en exécutant la commande show interface cable X/Y, où cable X/Y est l'interface de câble observée. Le débit de sortie affiché en bits par seconde doit être comparé à la bande passante disponible en aval comme indiqué dans le tableau ci-dessus.

Dans l'exemple suivant, une interface utilisant la modulation numérique DOCSIS et 64-QAM en Amérique du Nord est analysée.

uBR7246-VXR# show interface cable 3/0 
Cable3/0 is up, line protocol is up 
  Hardware is BCM3210 ASIC, address is 0005.5fed.dca4 (bia 0005.5fed.dca4) 
  Internet address is 10.1.1.1.1/24 
  MTU 1500 bytes, BW 27000 Kbit, DLY 1000 usec, 
     reliability 255/255, txload 9/255, rxload 5/255 
  Encapsulation MCNS, loopback not set 
  Keepalive not set 
  ARP type: ARPA, ARP Timeout 04:00:00 
  Last input 00:00:00, output 00:00:00, output hang never 
  Last clearing of "show interface" counters 00:45:01 
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 
  Queueing strategy: fifo 
  Output queue :0/40 (size/max) 
  5 minute input rate 587000 bits/sec, 228 packets/sec 
  5 minute output rate 996000 bits/sec, 239 packets/sec 
     85560 packets input, 8402862 bytes, 0 no buffer 
     Received 1013 broadcasts, 0 runts, 0 giants, 0 throttles 
     247 input errors, 35 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
     65912 packets output, 38168842 bytes, 0 underruns 
     0 output errors, 0 collisions, 0 interface resets 
     0 output buffer failures, 0 output buffers swapped out

Le premier composant de ce résultat à noter est la bande passante de l'interface indiquée par le paramètre BW. Dans les versions 12.1(8)EC et ultérieures du logiciel Cisco IOS, cette valeur est ajustée automatiquement en fonction du schéma de modulation en aval et de la version de DOCSIS utilisée. Dans les révisions antérieures à la version 12.1(8)EC du logiciel Cisco IOS, cette valeur doit être configurée manuellement à l'aide de la commande d'interface de câble bandwidth <bandwidth-in-kilo-bits-per-seconde> ou reste à la valeur par défaut de 27 000 Kbits/s.

Le deuxième composant à noter est la charge de transmission comme indiqué par le paramètre txload. Ce paramètre donne une métrique sur 255 où 0/255 signifie qu'aucun trafic ne circule dans la direction aval jusqu'à 255/255, ce qui signifie que les données circulent en aval à la vitesse maximale possible (dans ce cas à 27 000 Kbits/s). Si ce paramètre s'exécute de manière constante à plus de 75 % pendant la période de pointe (par exemple, supérieur à 191/255), les utilisateurs finaux commencent à connaître un accès Internet plus lent et une latence plus élevée.

Le troisième composant à noter est le débit de sortie, qui montre le débit moyen en aval en bits par seconde. Si ce nombre dépasse de manière constante environ 75 % de la bande passante disponible en aval pendant la période de pointe, les utilisateurs finaux commencent à connaître un accès Internet plus lent et une latence plus élevée.

Par défaut, ces statistiques sont calculées sur une moyenne mobile de cinq minutes. (Reportez-vous à Présentation de la définition des bits par seconde (bits/s) à partir de la sortie de commande show interfaces pour obtenir des détails sur le calcul de la moyenne.) La période pendant laquelle cette moyenne est calculée peut être réduite à 30 secondes en exécutant la commande cable interface load-interval 30. En abaissant cette période à 30 secondes, une valeur plus précise et à jour est calculée pour chacun des paramètres abordés dans cette section.

L'utilisation du canal en aval change au cours de la journée, car différents utilisateurs ont la possibilité d'utiliser leur modem câble. Il est donc important de surveiller l'utilisation en aval pendant les heures les plus chargées de la journée plutôt qu'à des heures d'utilisation réduite.

Les moyens de soulager la congestion en aval sont les suivants :

• Réduction du nombre de modems câble par aval : si un trop grand nombre de modems câble sont connectés à un canal aval donné ou si les utilisateurs d'un canal aval donné sont de gros utilisateurs de la bande passante en aval, la meilleure solution consiste à déplacer certains utilisateurs sur le canal aval congestionné vers un autre canal en aval. Pour ce faire, il faut généralement diviser un groupe de noeuds de fibre en aval associés à l'aval en deux groupes distincts et attribuer chacun des nouveaux groupes à des canaux en aval distincts. Reportez-vous à Quel est le nombre maximal d'utilisateurs par CMTS.

• Modification du schéma de modulation numérique en aval à 256-QAM - Cette action nécessite une analyse rigoureuse et approfondie du spectre en aval afin de vérifier si le système peut prendre en charge un signal 256-QAM. Si cette analyse n'est pas effectuée correctement, il y a un risque que les performances soient encore réduites ou qu'une panne en aval complète se produise. Vous pouvez modifier le schéma de modulation en aval en exécutant la commande cable interface comme indiqué ci-dessous.

  uBR7246-VXR(config-if)# cable downstream modulation 256qam
  

  Reportez-vous au Guide de référence des commandes du câble à large bande de Cisco pour plus d'informations sur la commande de modulation descendante par câble.

• Réduction du débit en aval autorisé par modem câble - En réduisant le débit de transmission en aval maximal dans les fichiers de configuration DOCSIS appropriés, les utilisateurs de modem câble ne peuvent pas télécharger à un débit aussi élevé dans la direction en aval et la congestion en aval est soulagée. L'aspect négatif de cette action est que les utilisateurs de modem câble sont limités à une classe de service plus lente. Reportez-vous à Création de fichiers de configuration DOCSIS 1.0 à l'aide de Cisco DOCSIS Configurator.

  Note : Les mesures décrites dans cette section n'augmentent pas significativement les performances d'un système déjà encombré.

Liaison réseau ou encombrement Internet

Dans certains cas, les problèmes de performances ne sont pas dus à des problèmes de câblage ou de CMTS, mais peuvent être liés à la congestion ou aux problèmes du réseau de liaison que le CMTS utilise pour se connecter à Internet, ou à des parties d'Internet lui-même.

Le moyen le plus simple de déterminer si un problème d'encombrement du réseau de liaison est de connecter une station de travail au même segment de réseau que le CMTS et d'essayer de parcourir les mêmes sites Web que les utilisateurs finaux derrière les modems câble essaient d'atteindre. Si les performances sont encore lentes, un problème de performances se produit sur le réseau, qui n'est pas lié au CMTS ou au segment de câble. Si les performances du segment de réseau CMTS local sont nettement meilleures que celles des utilisateurs connectés aux modems câble, réorientez les efforts sur le CMTS et le segment de câble.

Figure 3

Dans le réseau ci-dessus, si le serveur 1, qui est connecté au même segment de réseau que le CMTS, obtient des performances lentes lors de la navigation sur Internet, alors la source du problème n'est pas le CMTS. Au lieu de cela, le goulot d'étranglement ou les performances posent problème ailleurs. Afin de déterminer où se trouve le problème, des tests de performances sont effectués entre le serveur 1 et divers autres serveurs au sein du réseau du fournisseur d'accès Internet (FAI) et de l'Internet public.

le bruit et les erreurs sur l’installation de câblage

En cas de bruit ou d’entrée excessifs dans un système de câblage, les paquets entre les modems câble et le CMTS peuvent être corrompus et perdus. Cela peut entraîner une dégradation significative des performances.

Outre une dégradation des performances et du débit, certains des principaux indicateurs de bruit ou de radiofréquence (RF) sont les suivants :

• Les modems câble se déconnectent ou restent bloqués de façon sporadique dans les états init(r1) ou init(r2).

• Un SNR faible estimé tel qu'indiqué dans la sortie d'un câble show controller X/Y en amont Z, où le câble X/Y est l'interface du câble observée et Z le port en amont observé. La spécification DOCSIS exige un rapport porteuse-bruit (CNR) d'au moins 25 dB pour tous les signaux en amont. Cela équivaut à un SNR d'environ 29 dB. Le système CMTS Cisco est capable de détecter de manière cohérente les signaux en amont QPSK à des niveaux SNR bien pires. Cependant, tous les fournisseurs de services câblés doivent s'efforcer de respecter les exigences CNR DOCSIS de leur système. Un exemple de sortie du câble de contrôleur X/Y en amont Z est présenté ci-dessous.

  uBR7246-VXR# show controller cable 6/0 upstream 0 
   Cable6/0 Upstream 0 is up 
    Frequency 25.200 MHz, Channel Width 1.600 MHz, QPSK Symbol Rate 1.280 Msps 
    Spectrum Group is overridden 
    SNR 28.6280 dB 
    Nominal Input Power Level 0 dBmV, Tx Timing Offset 6446 
    Ranging Backoff automatic (Start 0, End 3) 
    Ranging Insertion Interval automatic (102 ms) 
    Tx Backoff Start 0, Tx Backoff End 4 
    Modulation Profile Group 1 
    Concatenation is enabled 
    part_id=0x3137, rev_id=0x03, rev2_id=0xFF 
    nb_agc_thr=0x0000, nb_agc_nom=0x0000 
    Range Load Reg Size=0x58 
    Request Load Reg Size=0x0E 
    Minislot Size in number of Timebase Ticks is = 8 
    Minislot Size in Symbols = 64 
    Bandwidth Requests = 0x37EB54 
    Piggyback Requests = 0x11D75E 
    Invalid BW Requests= 0x102 
    Minislots Requested= 0x65B74A2 
    Minislots Granted  = 0x65B74A2 
    Minislot Size in Bytes = 16 
    Map Advance (Dynamic) : 2809 usecs 
    UCD Count = 23068 

  Dans l'exemple ci-dessus, la lecture SNR estimée est de 28,628 dB. Cela convient pour le fonctionnement en amont de QPSK. Notez que la figure SNR donnée dans le résultat de cette commande n'est qu'une estimation et ne remplace pas une figure SNR dérivée d'un analyseur de spectre ou d'un autre équipement d'essai approprié. Reportez-vous au Guide de référence des commandes du câble à large bande de Cisco pour plus d'informations sur la commande show controllers cable cable amont.

• Nombre croissant d'erreurs FEC (Corr Forward Error Correction) et Uncorr FEC dans la sortie d'une commande show cable hop. Corr FEC errors indique des données qui ont été endommagées par le bruit en amont mais qui ont pu être récupérées. Les erreurs FEC Uncorr indiquent que les données ont été endommagées par le bruit en amont et n'ont pas pu être récupérées, ce qui a entraîné des pertes de données et des performances plus lentes. Un exemple de résultat de la commande show cable hop est présenté ci-dessous.

  uBR7246-VXR# show cable hop cable 3/0 
  Upstream    Port       Poll Missed Min    Missed Hop   Hop     Corr    Uncorr 
  Port        Status     Rate Poll   Poll   Poll   Thres Period  FEC     FEC 
                         (ms) Count  Sample Pcnt   Pcnt  (sec)   Errors  Errors 
  Cable3/0/U0 25.200 Mhz 34   * * * set to fixed frequency * * * 196     55 
  Cable3/0/U1 25.200 Mhz 34   * * * set to fixed frequency * * * 1655    160 
  Cable3/0/U2 25.200 Mhz 34   * * * set to fixed frequency * * * 76525   9790 
  Cable3/0/U3 25.200 Mhz 34   * * * set to fixed frequency * * * 501     77 
  Cable3/0/U4 admindown  34   * * *   interface is down    * * * 0       0 
  Cable3/0/U5 admindown  34   * * *   interface is down    * * * 0       0 

  Dans l’exemple ci-dessus, chaque port actif en amont sur le câble 3/0 semble avoir subi une perte de paquets due au bruit. Le port en amont 0 semble être le moins affecté et le port en amont 2 semble être le plus affecté. Le facteur important à noter est la rapidité avec laquelle les erreurs FEC augmentent plutôt que le nombre total d'erreurs. Reportez-vous au Guide de référence des commandes du câble haut débit Cisco pour plus d'informations sur la commande show cable hop.

• Nombre élevé d'événements « flap » dans la sortie d'une commande show cable flap-list. Les statistiques de battement les plus pertinentes pour les problèmes de RF ou de bruit possibles sont la colonne Miss, qui indique les demandes de distance manquées, et la colonne P-Adj, qui indique des niveaux de puissance en amont qui varient rapidement. Un exemple de résultat de la commande show cable flap-list est présenté ci-dessous.

  uBR7246-VXR# show cable flap-list 
  MAC Address     Upstream     Ins   Hit   Miss  CRC   P-Adj Flap  Time 
  0000.d025.1b99  Cable3/0/U0  23    58    30    0     *27   77    Oct 23 03:08:23 
  0002.ddfa.0aa5  Cable3/0/U1  5     518   1260  0     0     131   Oct 23 03:09:43 
  0001.e659.43bd  Cable3/0/U1  541   342   1467  0     0     746   Oct 23 03:09:17 
  0001.7659.44c7  Cable3/0/U1  0     694   0     0     1     1     Oct 23 01:44:23 
  0050.9366.22d3  Cable3/0/U1  0     708   0     0     1     1     Oct 23 01:38:14 
  0001.f659.44e7  Cable3/0/U1  0     701   0     0     1     1     Oct 23 02:25:11 

• Modems câble affichant une "*" ou une « !—" dans la sortie d'une commande show cable modem ou show cable flap-list. Un "*" indique un modem câble qui modifie rapidement ses niveaux d'alimentation en amont. Cela indique une mauvaise connexion à l’installation de câblage, un amplificateur de chemin inverse défectueux ou une atténuation rapide de l’installation de câblage en raison de la température ou d’autres effets environnementaux. Un « !—" indique un modem câble qui a atteint son niveau d'alimentation maximal en amont. Cela indique une trop grande atténuation entre le modem câble et le CMTS, ou une mauvaise connexion entre le modem câble et le câblage. Un exemple de résultat de la commande show cable modem est présenté ci-dessous.

  uBR7246-VXR# show cable modem 
  Interface   Prim Online     Timing       Rec     QoS CPE IP address   MAC address 
              Sid  State      Offset       Power
  Cable3/0/U1 1    online     1549   !--- -1.00    5   0   10.1.1.10    005a.73f6.2213 
  Cable3/0/U0 2    online     1980         0.75    5   0   10.1.1.16    009b.96e7.3820 
  Cable3/0/U0 3    online     1981        *0.75    5   0   10.1.1.18    009c.96d7.3831 
  Cable3/0/U1 4    online     1924         0.25    5   0   10.1.1.24    000d.96c9.4441 
  Cable3/0/U1 5    online     1925         0.50    5   0   10.1.1.13    000e.96b9.4457 

  Dans l'exemple ci-dessus, le modem câble avec l'adresse MAC 005a.73f6.2213 transmet à sa puissance de sortie maximale. Ce modem ne peut donc pas transmettre au niveau correct. Par conséquent, les transmissions en amont de ce modem ne sont pas entendues aussi clairement que les transmissions en provenance d'autres modems. Le modem câble avec l'adresse MAC 009c.96d7.3831 présente une puissance de sortie variable due à une atténuation variable du système de câblage. Reportez-vous au Guide de référence des commandes du câble à large bande Cisco pour plus d'informations sur les commandes show cable modem et show cable flap-list.

Remarque : Pour plus de détails sur l'identification et la résolution des problèmes de bruit RF, reportez-vous à la section Détermination des problèmes de RF ou de configuration sur le CMTS et Connexion du routeur de la gamme Cisco uBR7200 à la tête de réseau du câble.

Utilisation élevée du CPU sur le CMTS

Dans certains cas, un système CMTS Cisco peut être surchargé en raison d'une configuration sous-optimale, d'une utilisation excessive de certaines fonctions de gestion ou d'un nombre très élevé de paquets routés par le système CMTS.

La meilleure façon de déterminer l'utilisation du processeur d'un système CMTS Cisco est d'exécuter la commande show process cpu. L'utilisation actuelle du processeur est indiquée sur la première ligne du résultat de la commande.

Dans les lignes de sortie affichées sous la première ligne, chaque processus exécuté sur le CMTS est affiché avec la partie du processeur utilisée par ce processus. Cette section de la sortie show process cpu permet de déterminer si un processus ou une fonction particulier est la cause d'un CPU CMTS élevé.

uBR7246-VXR# show process cpu 
CPU utilization for five seconds: 45%/21%; one minute: 45%; five minutes: 31% 
 PID  Runtime(ms)  Invoked  uSecs    5Sec   1Min   5Min TTY Process 
   1          12      9220      1   0.00%  0.00%  0.00%   0 Load Meter 
   2       69816  18276677      3  21.79% 22.10%  9.58%   2 Virtual Exec 
   3       36368      5556   6545   0.00%  0.06%  0.05%   0 Check heaps 
   4           0         1      0   0.00%  0.00%  0.00%   0 Chunk Manager 
   5          96      1436     66   0.00%  0.00%  0.00%   0 Pool Manager 
   6           0         2      0   0.00%  0.00%  0.00%   0 Timers 
   7           0         2      0   0.00%  0.00%  0.00%   0 Serial Backgroun 
   8           0         1      0   0.00%  0.00%  0.00%   0 CMTS ping 
   9       17020    101889    167   0.00%  0.00%  0.00%   0 EnvMon 
  10           0         1      0   0.00%  0.00%  0.00%   0 OIR Handler 
  . . . . . . . 
  <snip> 
  . . . . . . . 
  89        3304     81013     40   0.00%  0.00%  0.00%   0 PIM Process 
  90          12       769     15   0.00%  0.00%  0.00%   0 CEF Scanner 
  92           0       385      0   0.00%  0.00%  0.00%   0 DHCPD Timer 
  93          40     13058      3   0.00%  0.00%  0.00%   0 DHCPD Database

Dans l'exemple ci-dessus, la charge CPU actuelle sur le CMTS est de 45 %/21 %. Cela signifie que l'utilisation totale du processeur représente 45 % de la capacité du système. En outre, 21 % du processeur est utilisé pour les interruptions de service. Cette deuxième figure correspond généralement à la partie du processeur utilisée pour acheminer les paquets et commuter le trafic via le CMTS.

Si l'utilisation constante du CPU de cinq minutes dépasse 80 % pendant la période de pointe dans le système, les utilisateurs finaux peuvent commencer à connaître des performances plus lentes et une latence accrue. Si l'utilisation du processeur pendant cinq minutes dépasse constamment 95 % pendant la période de pointe, prenez des mesures urgentes pour vous assurer que le CMTS reste dans un état stable.

Les stratégies courantes de réduction de l'utilisation élevée du CPU sur le CMTS sont les suivantes :

• Mise à niveau vers le logiciel Cisco IOS Version 12.1(9)EC ou ultérieure, activation de la commande de configuration globale ip cef, et vérification qu'aucune interface sur le CMTS n'a la commande no ip route-cache configurée. Cela entraîne généralement une réduction de 10 à 15 % de l'utilisation du CPU lié au trafic. Assurez-vous que toutes ces étapes sont prises en compte.

• S'assurer que les stations d'administration SNMP (Simple Network Management Protocol) ne sont pas trop agressives dans l'interrogation du CMTS. Cela entraîne une utilisation élevée du CPU dans le processus SNMP IP.

• Ne pas exécuter la commande show tech plusieurs fois de suite. Cela conduit à une utilisation artificiellement élevée du CPU dans le processus Virtual Exec.

• Assurez-vous qu'aucune commande debug n'est exécutée sur le CMTS.

Pour plus d'informations sur l'utilisation élevée du CPU sur les routeurs Cisco, y compris les produits Cisco CMTS, référez-vous à Dépannage de l'utilisation élevée du CPU sur les routeurs Cisco.

Sous équipement CPE sous tension ou mal configuré

Dans de nombreux cas, la cause de la lenteur de l’accès à un réseau câblé est un problème dans l’équipement CPE de l’utilisateur final. Si un seul ou une poignée d'utilisateurs connaissent un débit lent et que le reste de la population d'utilisateurs ne rencontre aucun problème, cela indique clairement qu'il peut y avoir un problème unique dans l'environnement de cet utilisateur.

• Sous CPE sous tension ou surchargé - Si les utilisateurs finaux se plaignent de difficultés utilisent un équipement CPE obsolète, ou un équipement qui n'est peut-être pas assez puissant pour exécuter le système d'exploitation ou le logiciel d'accès à Internet de leur choix, cet utilisateur final aura des difficultés. La seule solution si c'est le cas est que l'utilisateur final mette à niveau son équipement CPE.

• Pare-feu ou logiciel de mesure des performances - Si l'utilisateur final exécute un pare-feu, une mesure des performances du réseau ou tout autre logiciel similaire, une bonne étape de dépannage consiste à demander à l'utilisateur de désactiver ce logiciel pour voir s'il a un effet sur les performances. Souvent, ce type de logiciel peut avoir un impact négatif sur les performances.

• Paramètres TCP/IP mal configurés - La plupart des fournisseurs de services exigent que les utilisateurs finaux disposent de leur équipement CPE pour acquérir une adresse IP, un masque de réseau, une passerelle par défaut et des serveurs DNS au moyen du protocole DHCP (Dynamic Host Configuration Protocol). Assurez-vous que les périphériques CPE des utilisateurs finaux qui rencontrent des problèmes sont configurés pour utiliser DHCP afin d'acquérir tous ces paramètres.

Si un utilisateur final prétend ne connaître aucun des problèmes mentionnés ci-dessus, confirmez que l'utilisateur final n'excède pas son débit maximal de téléchargement ou de téléchargement conformément aux sections ci-dessus.

Conclusion

Un réseau câblé DOCSIS est un système sophistiqué nécessitant une planification et une maintenance appropriées. La plupart des problèmes de performances dans les systèmes de câblage DOCSIS résultent directement du fait que la planification et la maintenance ne sont pas effectuées correctement. Dans le marché actuel de l'accès à Internet, où il existe une variété d'options d'accès à Internet à large bande, il est important que les fournisseurs de services câblés résolvent rapidement tout problème de performances ou de congestion dans leur système avant que les problèmes ne deviennent suffisamment importants pour que les utilisateurs finaux soient affectés de manière visible et, par conséquent, envisagent un autre moyen d'accès à large bande.

Informations connexes

• Résolution des problèmes de mise en ligne des modems câble uBR
• Identification des problèmes (RF ou configuration) sur le CMTS
• Connexion du routeur de la gamme Cisco uBR7200 à la tête de réseau du câble
• Dépannage de l'utilisation élevée du CPU sur les routeurs Cisco
• Support et documentation techniques - Cisco Systems