Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
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 types de 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 au sens large.
La section suivante examine les raisons les plus courantes de la lenteur des performances et propose des solutions. Ces problèmes incluent :
Les performances sont limitées par les limites du fichier de configuration DOCSIS.
Performances de téléchargement en rafales ou inconstantes dues à l'utilisation d'un schéma de limitation de débit sous-optimal sur le système CMTS (Cable Modem Termination System).
Congestion des canaux amont et aval.
Congestion du réseau de liaison ou Internet.
Bruit ou erreurs sur le câblage.
Équipement d'abonné (CPE) sous tension.
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 complète de connectivité sur le réseau câblé ou des modems câblés ne se connectant pas. Reportez-vous plutôt à la section Dépannage des modems câble uBR qui ne sont pas en ligne pour ce type de problèmes.
Aucune condition préalable spécifique n'est requise pour ce document.
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 CMTS uBR7200 et uBR7100.
La suite de produits CMTS Cisco uBR7100, uBR7200 et uBR7200VXR.
Les informations contenues dans ce document sont pertinentes pour toutes les autres versions actuellement disponibles de la plate-forme logicielle Cisco IOS basée 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.
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. Examinez le schéma ci-dessous.
Figure 1 (pour voir ce schéma au format vidéo, cliquez ici.)
Dans ce schéma, il y a un certain nombre de composants :
Réseau hybride fibre/câble coaxial entre l'utilisateur final et le CMTS.
Segment de réseau CMTS local où 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 du réseau entre les deux points est mesurée.
Par exemple, si vous effectuez un test de vitesse entre l’équipement d’abonné et le serveur 3, qui est connecté à Internet via une ligne RNIS à 128 Kbits/s, il n’y aura jamais de vitesses supérieures à 128 Kbits/s, même si la bande passante disponible sur le segment de câble est supérieure à 128 Kbits/s.
La manière la plus précise de 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 emprunter 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 a une bande passante élevée (FastEthernet ou supérieure) et qu’il n’est pas encombré.
Si, pour une raison quelconque, aucun serveur ne peut être connecté au segment de réseau CMTS local, le moyen le plus précis suivant de tester les performances du segment de câble consiste à effectuer un test de vitesse entre l’équipement d’abonné et le serveur 2. Il s’agit d’une mesure précise à condition 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 l’équipement d’abonné et l’équipement d’abonné.
La manière la plus imprécise 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 sur l’Internet public entre l’équipement d’abonné et le serveur, ou des liaisons à très faible débit sur le chemin entre l’équipement d’abonné et le serveur sur Internet.
Il est très important de pouvoir obtenir une mesure objective des niveaux exacts de débit de chargement et de téléchargement atteints avant de pouvoir tirer des conclusions sur l'existence d'un problème de performance dans un système DOCSIS.
La façon la plus simple de déterminer la vitesse à laquelle les téléchargements et les téléchargements se produisent consiste à télécharger un fichier volumineux à l'aide de 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 sont capables d'afficher la vitesse à laquelle 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 est généralement d'environ 90 % du débit total réel atteint. En effet, la vitesse de transfert FTP ou HTTP affichée ne prend pas en compte la surcharge IP et DOCSIS supplémentaire qui doit être acheminée 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 dédié tiers, tel qu'un Netcom Smartbits ou un générateur de paquets IXIA, mais ces systèmes ne sont pas toujours facilement disponibles ou facilement connectés à un réseau câblé de production. Il est important de noter que si des tests de débit sont effectués dans un environnement de travaux pratiques, 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 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 vitesses de test supérieures à environ 3 Mbits/s, un équipement de test de débit de données dédié doit être utilisé.
Dans l'exemple suivant, un simple test 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 allant jusqu'à 256 Kbits/s et une vitesse de téléchargement allant jusqu'à 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 de pouvoir télécharger ce fichier à partir du serveur FTP, puis le télécharger à nouveau vers 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 dans 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 en utilisant la commande show interface cable X/Y sid Z counters où cable 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 0001.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 la progression du téléchargement, effacez tous les compteurs de paquets sur le CMTS à zéro à l'aide de la commande clear counters. Exactement quand les compteurs sont effacés, démarrez un chronomètre ou un chronomètre.
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, émettez 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 minuteur indique une minute. L'essai 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. Toutefois, assurez-vous que le téléchargement ne se termine pas avant que le chronomètre n'atteigne l'heure spécifiée, 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 déterminer 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.
Dans cet exemple, le débit de téléchargement 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 Innoctets 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 side counters.
La première information qui doit être recueillie lors du dépannage des performances lentes du modem câble est la classe prescrite de limitations de débit de service du modem câble. Lorsqu'un modem câble est mis en ligne, il télécharge un fichier de configuration DOCSIS contenant les limites de fonctionnement du modem câble, y compris les débits de chargement et de téléchargement maximaux. Dans des circonstances normales, le modem câble n'est pas autorisé à dépasser ces taux.
Au départ, il est nécessaire d’identifier l’adresse MAC d’un modem câble présentant des problèmes. Prendre un modem avec l'adresse MAC 0050.7366.2223 qui a des problèmes de débit lent, il est nécessaire de savoir quelle classe de profil de service ce modem câble utilise 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
Elle montre ici 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 ce profil de qualité de service correspond, utilisez la commande show cable qos profile profile-number, où profile-number est le profil de qualité de service d'intérêt.
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
Elle montre ici que le profil QoS 5 correspond à un service fournissant 256 Kbits/s en aval et 64 Kbits/s en amont. Aucun CPE connecté à des modems câble utilisant le profil QoS 5 ne peut dépasser ces limites. Les paramètres du 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 de mise à disposition. Par conséquent, le profil QoS 5 du système peut ne pas être le même que le profil QoS 5 de l'exemple ci-dessus.
Si les performances 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 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 les limites de débit sont plus élevées. Reportez-vous au document intitulé Building DOCSIS 1.0 Configuration Files Using Cisco DOCSIS Configurator pour obtenir des instructions détaillées sur la création ou la modification d'un fichier de configuration DOCSIS.
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 pour s'assurer que l'utilisateur 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 transiter par le segment de câble vers le CMTS. Si, pour une raison quelconque, le modem câble ne parvient pas à limiter correctement le débit en amont, le CMTS interdit explicitement au modem câble de transmettre des données à un débit supérieur au débit autorisé. Ce comportement sur le CMTS est de s'assurer que même un modem câble avec des caractéristiques "piratées" est incapable de subvertir les limites de débit de chargement assignées par le fournisseur de services.
Le schéma de limitation de débit par défaut utilisé par le CMTS surveille le débit du trafic vers ou depuis 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 plus le trafic à circuler vers ce modem câble pendant 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) au cours de la première moitié de seconde, le modem câble n'est pas autorisé à télécharger quoi que ce soit pendant la seconde moitié suivante. Ce type de comportement de limitation de débit peut avoir l'effet d'un modèle de téléchargement par salves qui semble s'arrêter et démarrer toutes les secondes ou deux.
Le meilleur schéma de limitation de débit en aval à utiliser est l'algorithme de limitation de débit token bucket avec formatage du trafic. Ce schéma de limitation de débit a été optimisé pour permettre une expérience de navigation Web fluide à un débit constant, tout en s'assurant que les utilisateurs finaux ne sont pas autorisés à dépasser le débit de téléchargement prescrit comme spécifié dans le fichier de configuration DOCSIS.
Le fonctionnement de ce schéma consiste à mesurer la vitesse à laquelle un modem câble télécharge ou télécharge des données chaque fois qu'un paquet est envoyé vers ou depuis le modem câble. Si l'envoi ou la réception du paquet en question entraîne le dépassement des débits de transfert autorisés par le modem, le paquet est mis en mémoire tampon ou 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 du trafic en aval dépasse systématiquement le débit en aval autorisé pour le modem câble, les paquets sont finalement abandonnés.
Grâce à cette méthode plus souple de limitation et de mise en forme du 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 plus efficacement que lorsqu'elles utilisent le schéma de limitation du débit par défaut.
Le schéma token-bucket rate-limit-with-traffic-shaping peut être activé sur le chemin descendant 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 vivement recommandé d'activer la mise en forme de saut de jeton 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 saut à jeton avec schéma de mise en forme du trafic peut également être appliqué à des ports en amont, mais comme il incombe aux modems câble d'effectuer une 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 haut débit Cisco pour plus d'informations sur les commandes cable aval rate-limit et cable upstream rate-limit.
Les utilisateurs peuvent voir à quel point le CMTS limite le trafic vers un modem câble particulier à l'aide de la commande show interface cable X/Y sid <Z>counters, où cable X/Y est l'interface câblée à laquelle le modem câble est connecté et Z est 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 des limites de débit autorisées par le modem. Si aucune valeur n'est spécifiée pour Z, les informations de compteur de tous les modems câble connectés au câble d'interface X/Y sont affichées.
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 en 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 s'élève sensiblement au-dessus de zéro, il se peut que le modem câble observé n'effectue 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 remises à 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 side counters.
Le canal en amont est normalement la ressource la plus précieuse dans un système câblé. Actuellement, la plupart des fournisseurs de services câblés utilisent une largeur de canal de 1,6 MHz et une modulation QPSK (Quadrature Phase Shift Keying) sur le chemin 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 amont ne soit pas surutilisé ou encombré, sinon tous les utilisateurs sur ce segment amont souffrent de performances médiocres.
L'utilisation en amont pour un port en amont particulier peut être obtenue en exécutant la commande CMTS show interface cable X/Y upstream <Z>, où cable X/Y est le numéro d'interface en aval et Z est le numéro de port en amont. Si Z est omis, les informations pour 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 upstream.
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 de 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 pour cent pendant la période d'utilisation maximale, les utilisateurs finaux commencent à souffrir de problèmes tels que la latence, des temps de « 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 pour cent pendant la période d'utilisation de pointe, les utilisateurs finaux subissent un niveau de service extrêmement médiocre, car une grande partie des données en amont de l'utilisateur final devra être retardée ou rejetée.
L'utilisation du canal en amont change au cours de la journée, car les différents utilisateurs ont la possibilité d'utiliser leur modem câble. Il est donc important de surveiller l'utilisation en amont aux heures les plus chargées de la journée plutôt qu'aux heures d'utilisation réduite.
Les moyens de soulager la congestion en amont sont les suivants :
Réduction du nombre de modems câble par port amont - Si trop de modems câble sont connectés à un port amont particulier, ou si les utilisateurs d’un port amont particulier sont des utilisateurs intensifs de bande passante en amont, la meilleure solution consiste à déplacer certains utilisateurs sur le port amont encombré vers un port amont sous-utilisé, ou vers un port amont complètement nouveau. Pour ce faire, on déplace généralement un noeud de fibre d'un groupe de combinaison en amont à un autre ou on divise un groupe de combinaison en amont en deux groupes de combinaison distincts. Pour plus d'informations, référez-vous à Quel est le nombre maximal d'utilisateurs par CMTS.
Augmentation de la largeur de canal en amont - Cela implique une analyse rigoureuse et approfondie du spectre en amont pour trouver une bande suffisamment large avec des caractéristiques de rapport signal/bruit (SNR) adéquates pour prendre en charge la largeur de canal accrue. La largeur du canal en amont ne doit pas être modifiée sans une planification minutieuse, car cette modification peut potentiellement affecter d'autres services du système câblé de l'utilisateur. La largeur du canal en amont peut être modifiée à l’aide de la commande d’interface de câble cable upstream Z channel-width <new-channel-width> où Z est le numéro de port en amont et la nouvelle largeur de canal est 200000, 400000, 800000, 1600000 (valeur par défaut) ou 3200000. Un exemple est donné ci-dessous.
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 upstream.
Changement du schéma de modulation numérique en amont en modulation d'amplitude en quadrature 16 (QAM) - Encore une fois, cela nécessite une analyse rigoureuse et approfondie du spectre en amont afin de vérifier s'il y a une bande de fréquence dans l'amont disponible qui peut prendre en charge la modulation en quadrature 16. Si cette analyse n'est pas effectuée correctement, les performances risquent d'être encore réduites ou une panne complète en amont peut se produire. Le schéma de modulation en amont peut être modifié par la création d'un profil de modulation en amont qui utilise la modulation 16-QAM, puis par son application à un port en amont. Un exemple suit.
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 Cisco pour plus d'informations sur les commandes cable modulation-profile et cable upstream 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é en amont et la congestion en amont est éliminée. L'aspect négatif de cette ligne de conduite est que les utilisateurs de modems 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.
Remarque : les mesures présentées dans cette section n'améliorent pas de manière significative les performances d'un système déjà non encombré.
Le canal aval a beaucoup plus de bande passante à partager qu'un canal amont individuel, de sorte que le canal aval n'est généralement pas aussi sujet à l'encombrement que le canal amont. Cependant, un plus grand nombre d'utilisateurs partagent généralement un canal en aval que n'importe quel canal en amont. Par conséquent, si le canal en aval devient encombré, tous les utilisateurs connectés au segment en aval voient leurs performances réduites.
Le tableau suivant indique la bande passante descendante totale disponible associée aux quatre schémas de modulation descendante possibles disponibles dans les systèmes DOCSIS.
Méthode De Modulation En Aval | Bande passante disponible en aval |
---|---|
DOCSIS 64-QAM Amérique du Nord | 27 Mbit/s |
DOCSIS 256-QAM Amérique du Nord | 38 Mbit/s |
64-QAM Euro DOCSIS | 38 Mbit/s |
256-QAM Euro DOCSIS | 54 Mbit/s |
La majorité des systèmes câblés DOCSIS déploient actuellement le 64-QAM North American DOCSIS et disposent donc de 27 Mbits/s par canal en aval.
L'utilisation du canal en aval peut être déterminée en émettant 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 nord-américaine 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 cette sortie à noter est la bande passante de l'interface indiquée par le paramètre BW. Dans le logiciel Cisco IOS versions 12.1(8)EC et ultérieures, 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 versions 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-second> ou sinon elle reste à la valeur par défaut de 27000 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 de 255 où 0/255 signifie qu'aucun trafic ne circule en aval à 255/255, ce qui signifie que les données circulent en aval au débit maximum possible (dans ce cas à 27000 Kbits/s). Si ce paramètre est exécuté de manière cohérente à plus de 75 % environ pendant la période d'utilisation maximale (par exemple, supérieure à 191/255), les utilisateurs finaux commencent à bénéficier d'un accès Internet plus lent et d'une latence plus élevée.
Le troisième composant à noter est le débit de sortie, qui montre le débit descendant moyen en bits par seconde. Si ce nombre dépasse constamment environ 75 % de la bande passante disponible en aval pendant la période d'utilisation maximale, les utilisateurs finaux commencent à bénéficier d'un accès Internet plus lent et d'une latence plus élevée.
Par défaut, ces statistiques sont calculées sur une moyenne mobile de cinq minutes. (Référez-vous à Comprendre la définition des bits par seconde (bits/s) à partir du résultat de la commande show interfaces pour plus de détails sur la façon dont la moyenne est calculée.) La période sur laquelle cette moyenne est calculée peut être réduite à aussi peu que 30 secondes en émettant 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 discutés dans cette section.
L'utilisation des canaux 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 aux heures les plus chargées de la journée plutôt qu'aux heures d'utilisation réduite.
Voici quelques moyens de désengorger le réseau en aval :
Réduction du nombre de modems câble par canal aval - Si trop de modems câble sont connectés à un canal aval particulier ou si les utilisateurs d’un canal aval particulier sont des utilisateurs importants de bande passante en aval, la meilleure solution consiste à déplacer certains utilisateurs sur le canal aval encombré vers un autre canal aval. Pour ce faire, on divise généralement un groupe de noeuds de fibre en aval associés à l'aval en deux groupes distincts et on attribue à 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 en 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, les performances risquent d'être encore réduites ou une panne complète en aval peut se produire. Le schéma de modulation en aval peut être modifié en émettant la commande d'interface de câble 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 Cisco pour plus d'informations sur la commande cable aval modulation.
Réduction du débit descendant autorisé par modem câble - En réduisant le débit de transmission descendant 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 le sens descendant et la congestion descendante est réduite. L'aspect négatif de cette ligne de conduite est que les utilisateurs de modems câble sont limités à une classe de service plus lente. Référez-vous à Création de fichiers de configuration DOCSIS 1.0 à l'aide de Cisco DOCSIS Configurator.
Remarque : les mesures présentées dans cette section n'améliorent pas de manière significative les performances d'un système déjà non encombré.
Dans certains cas, les problèmes de performances peuvent ne pas être dus à des problèmes sur le câblage ou le CMTS, mais peuvent être liés à une congestion ou à des problèmes dans le réseau de liaison que le CMTS utilise pour se connecter à Internet, ou dans certaines parties d’Internet lui-même.
Le moyen le plus simple de déterminer si l’encombrement du réseau de liaison est un problème consiste à connecter une station de travail au même segment de réseau que le CMTS et à essayer de parcourir les mêmes sites Web que ceux que les utilisateurs finaux derrière les modems câble tentent d’atteindre. Si les performances sont toujours faibles, il existe un problème de performances dans 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 à des modems câble, concentrez vos 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, la source du problème n'est pas le CMTS. Au lieu de cela, le goulot d'étranglement ou le problème de performance ailleurs. Afin de déterminer où se situe 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 l'Internet public.
En cas de niveau excessif de bruit ou d’entrée dans un système câblé, 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 la dégradation des performances et du débit, certains des principaux indicateurs de problèmes de bruit ou de radiofréquence (RF) sont les suivants :
Les modems-câble se déconnectent sporadiquement ou restent bloqués à l’état init(r1) ou init(r2).
Un SNR estimé faible tel que vu dans la sortie d'un show controller cable X/Y upstream Z Z, où le cable X/Y est l'interface de câble observée et Z est le port 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 CMTS de Cisco est capable de détecter de manière cohérente les signaux QPSK en amont à des niveaux SNR bien pires. Cependant, tous les fournisseurs de services câblés doivent s'efforcer de répondre aux exigences CNR DOCSIS de leur système. Un exemple de sortie show controller cable X/Y upstream Z 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 valeur estimée du SNR est de 28,628 dB. Ceci est approprié pour le fonctionnement en amont de QPSK. Notez que la valeur du SNR donnée dans le résultat de cette commande n'est qu'une estimation et ne remplace pas une valeur du 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 Cisco pour plus d'informations sur la commande show controllers cable upstream spectre.
Nombre croissant rapidement d'erreurs FEC (Corr Forward Error Correction) et Uncorr FEC dans le résultat d'une commande show cable hop. Les erreurs FEC Corr indiquent des données corrompues par le bruit en amont mais qui ont pu être récupérées. Les erreurs FEC d'incohérence indiquent que les données ont été corrompues par le bruit en amont et n'ont pas pu être récupérées, ce qui a entraîné une perte de données et un ralentissement des performances. Un exemple de sortie de la commande show cable hop est montré 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 du 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é d'incrémentation des erreurs FEC 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 le résultat d'une commande show cable flap-list. Les statistiques de battement les plus pertinentes aux problèmes de RF ou de bruit possibles sont la colonne Miss, qui indique les demandes de télémétrie manquées, et la colonne P-Adj, qui indique des niveaux de puissance en amont variant rapidement. Un exemple de sortie de la commande show cable flap-list est montré 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 un "*" ou un "!—" dans la sortie d'une commande show cable modem ou show cable flap-list. Un "*" indique un modem câble dont les niveaux de puissance en amont varient rapidement. Cela indique une mauvaise connexion au câblage, un amplificateur de chemin inverse défectueux ou une atténuation du câblage changeant rapidement en raison de la température ou d'autres effets environnementaux. Le point d'exclamation (!—) indique qu'un modem câble a atteint son niveau de puissance maximum en amont. Cela indique une atténuation excessive entre le modem câble et le CMTS, ou une mauvaise connexion entre le modem câble et le câblage. Un exemple de sortie de la commande show cable modem est montré 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. Cela a pour conséquence que le modem ne peut pas transmettre au niveau correct. Par conséquent, les transmissions en amont de ce modem ne sont pas entendues aussi clairement que les transmissions d'autres modems. Le modem câble avec l'adresse MAC 009c.96d7.3831 présente une puissance de sortie variant rapidement en raison de l'atténuation variable du système câblé. Consultez le 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 d'informations 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 Cisco uBR7200 à la tête de réseau du câble.
Dans certains cas, un CMTS Cisco peut devenir surchargé en raison d'une configuration non optimale, de l'utilisation excessive de certaines fonctions de gestion ou d'un nombre très élevé de paquets acheminés par le CMTS.
La meilleure façon de déterminer l'utilisation CPU d'un CMTS Cisco est d'exécuter la commande show process cpu. L'utilisation actuelle du CPU est indiquée sur la première ligne du résultat de la commande.
Dans les lignes de sortie indiquées sous la première ligne, chaque processus exécuté sur le CMTS est représenté avec la partie du CPU utilisée par ce processus. Cette section de la sortie de show process cpu est utile pour déterminer si un processus ou une fonction particulière 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 actuelle du processeur sur le CMTS est de 45 %/21 %. Cela signifie que l'utilisation totale du processeur correspond à 45 % de la capacité du système. En outre, 21 % du processeur est utilisé pour traiter les interruptions. 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 du processeur pendant cinq minutes est systématiquement supérieure à 80 % pendant la période d'utilisation maximale du système, les utilisateurs finaux peuvent commencer à bénéficier de performances plus lentes et d'une latence accrue. Si l'utilisation du processeur pendant cinq minutes est constamment supérieure à 95 % pendant la période d'utilisation maximale, prenez des mesures urgentes pour vous assurer que le CMTS reste dans un état stable.
Les stratégies courantes pour réduire 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 processeur liée au trafic. Assurez-vous que toutes ces étapes sont effectuées conjointement.
S'assurer que les stations d'administration SNMP (Simple Network Management Protocol) ne sont pas trop agressives lors de l'interrogation du CMTS. Cela entraîne une utilisation élevée du CPU dans le processus IP SNMP.
Ne pas exécuter la commande show tech plusieurs fois de suite. Cela entraîne une utilisation artificiellement élevée du CPU dans le processus d'exécution virtuel.
Vérification 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.
Dans de nombreux cas, la lenteur d’accès à un réseau câblé est due à un problème dans l’équipement d’abonné de l’utilisateur final. Si un seul utilisateur ou une poignée d'entre eux connaît un débit lent et que le reste de la population d'utilisateurs ne rencontre aucun problème, cela indique clairement qu'il peut exister un problème unique dans l'environnement de cet utilisateur.
CPE sous tension ou surchargé : si les utilisateurs finaux qui se plaignent de difficultés utilisent un équipement CPE obsolète ou un équipement qui n'est pas suffisamment 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. Si tel est le cas, la seule solution est que l'utilisateur final mette à niveau son équipement d'équipement d'abonné.
Pare-feu ou logiciel de mesure des performances : si l'utilisateur exécute un pare-feu, un logiciel de mesure des performances du réseau ou un 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, ces types de logiciels peuvent 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 obtiennent une adresse IP, un masque réseau, une passerelle par défaut et des serveurs DNS auprès de leur équipement CPE par le biais du protocole DHCP (Dynamic Host Configuration Protocol). Assurez-vous que les périphériques CPE de tout utilisateur final rencontrant des problèmes sont configurés pour utiliser DHCP afin d'acquérir tous ces paramètres.
Si un utilisateur final prétend ne présenter aucun des problèmes répertoriés ci-dessus, vérifiez que l'utilisateur final ne dépasse pas son taux de téléchargement ou de chargement maximum, conformément aux sections ci-dessus.
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 des systèmes câblés DOCSIS sont le résultat direct d’une planification et d’une maintenance incorrectes. 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 par câble résolvent rapidement tout problème de performance ou d'encombrement dans leur système avant que les problèmes ne deviennent suffisamment importants pour que les utilisateurs finaux soient affectés de façon notable, et, par conséquent, envisagent un autre moyen d'accès à large bande.