Sommario

Introduzione

Operazioni preliminari

Prerequisiti

Componenti usati

Determinazione accurata dei livelli di prestazioni raggiunti

Misurazione delle parti corrette del sistema

Determinazione della frequenza di download e caricamento

Motivi potenziali per prestazioni insoddisfacenti

Prestazioni limitate dal file di configurazione DOCSIS

Utilizzo di un metodo non ottimale per la limitazione della velocità

Congestione canale upstream

Congestione del canale downstream

Rete backhaul o congestione Internet

Disturbo ed errori nell'impianto cablato

Utilizzo CPU elevato nel CMTS

Apparecchiature CPE con o senza alimentazione

Conclusioni

Informazioni correlate

Introduzione

In un sistema DOCSIS (Data-over-Cable Service Interface Specifications), sono presenti diversi problemi che possono influire sulle prestazioni e sulla velocità dei modem via cavo. Questo documento cerca di affrontare le principali cause della lentezza del throughput dal punto di vista di un provider di servizi via cavo.

In questo documento viene innanzitutto illustrato come determinare con precisione quali livelli di throughput un utente finale sta raggiungendo e come verificare che le prestazioni misurate siano quelle della rete via cavo, anziché quelle di Internet in senso lato.

La sezione successiva esamina le cause potenziali più comuni della lentezza delle prestazioni e le soluzioni suggerite. Tali questioni comprendono:

- Le prestazioni sono limitate dai limiti nel file di configurazione DOCSIS.

- Prestazioni di download instabili o incostanti causate dall'utilizzo di uno schema di limitazione della velocità non ottimale nel sistema di terminazione del modem via cavo (CMTS).

- Congestione del canale upstream e downstream.

- Rete backhaul o congestione Internet.

- Rumore o errori sull'impianto di cablaggio.

- Apparecchiature CPE (end-premises equipment) sotto alimentazione.

Ognuna di queste caratteristiche, singolarmente o in combinazione, può influire sul throughput e sulle prestazioni di una rete cablata.

In questo documento non viene descritta la risoluzione dei problemi di perdita completa di connettività sulla rete via cavo o sui modem via cavo che non sono in linea. Per questo tipo di problemi, fare riferimento a Risoluzione dei problemi dei modem cablati uBR non in linea.

Operazioni preliminari

Prerequisiti

Non sono previsti prerequisiti specifici per questo documento.

Componenti usati

Le informazioni fornite in questo documento si basano sulle versioni software e hardware riportate di seguito.

- Software Cisco IOS® versione 12.1(9)EC per i CMTS uBR7200 e uBR7100.

- la suite di prodotti CMTS Cisco uBR7100, uBR7200 e uBR7200VXR.

- Le informazioni di questo documento sono rilevanti per tutte le altre versioni attualmente disponibili del software Cisco IOS basato su DOCSIS 1.0 per le apparecchiature CMTS con marchio Cisco.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Determinazione accurata dei livelli di prestazioni raggiunti

Misurazione delle parti corrette del sistema

Esistono diversi modi per misurare la velocità e le prestazioni di un sistema, tuttavia è importante capire esattamente quali parti del sistema vengono testate. Si consideri il diagramma riportato di seguito.

Figura 1 (per visualizzare il diagramma in formato video, fare clic qui).

In questo diagramma sono presenti diversi componenti:

- La rete Hybrid Fiber Coax tra l'utente finale e il CMTS.

- Il segmento della rete CMTS locale in cui il CMTS si connette alla rete del provider di servizi via cavo.

- La rete interna del provider del servizio via cavo.

- Internet pubblica.

Quando si esegue una prova di velocità tra due punti, viene misurata la velocità di tutti i componenti di rete tra i due punti.

Ad esempio, se si esegue un test di velocità tra il CPE e il server 3, connesso a Internet tramite una linea ISDN a 128 Kbps, le velocità non saranno mai superiori a 128 Kbps, anche se la larghezza di banda disponibile sul segmento di cavo è superiore a 128 Kbps.

Il modo più accurato per misurare le prestazioni del segmento di cavo è eseguire un test di velocità tra il CPE e il server 1, che è collegato allo stesso segmento di rete del CMTS. Questo accade perché l'unico dato del percorso da trasferire è il segmento del cavo coassiale. I dati devono inoltre viaggiare attraverso il segmento della rete CMTS locale, ma si presume che questo segmento abbia una larghezza di banda elevata (FastEthernet o superiore) e non abbia un elevato livello di congestione.

Se per qualche motivo non è possibile connettere alcun server al segmento della rete CMTS locale, il modo più accurato per verificare le prestazioni del segmento del cavo consiste nell'eseguire un test di velocità tra il CPE e il server 2. Si tratta di una misurazione accurata, a condizione che vi siano collegamenti sufficientemente veloci e non congestionati all'interno della rete interna del provider di servizi via cavo tra il CMTS e il CPE.

Il modo più impreciso per determinare le prestazioni del segmento del cavo è eseguire un test della velocità tra il CPE e un server su Internet. Ciò è dovuto al fatto che potrebbero esserci collegamenti congestionati nell'Internet pubblica tra il CPE e il server, o potrebbero esserci collegamenti a velocità molto bassa nel percorso tra il CPE e il server su Internet.

Determinazione della frequenza di download e caricamento

È molto importante essere in grado di ottenere una misurazione oggettiva dei livelli esatti di velocità di caricamento e scaricamento prima di trarre conclusioni sull'eventuale presenza di problemi di prestazioni in un sistema DOCSIS.

Il modo più semplice per determinare la velocità di caricamento e download consiste nel caricare o scaricare un file di grandi dimensioni tramite FTP o HTTP tra un dispositivo CPE collegato a un modem via cavo e un server dietro il CMTS. La maggior parte dei client FTP e HTTP è in grado di visualizzare la velocità alla quale si verifica un download o un caricamento durante il trasferimento o una volta completato il trasferimento. La velocità di trasferimento rilevata come risultato dell'operazione FTP o HTTP è in genere circa il 90% della velocità effettiva totale raggiunta. Infatti, la velocità di trasferimento FTP o HTTP visualizzata non tiene conto dell'ulteriore sovraccarico IP e DOCSIS che deve spostarsi tra il dispositivo CPE e il CMTS.

Esistono metodi più accurati per misurare il throughput, ad esempio utilizzando apparecchiature di test dedicate di terze parti, come Smartbit Netcom o un generatore di pacchetti IXIA, tuttavia questi sistemi non sono sempre facilmente disponibili o facilmente collegabili a una rete via cavo di produzione. Se i test del throughput vengono eseguiti in un ambiente lab, l'utilizzo di un dispositivo dedicato consente di visualizzare molte più informazioni rispetto al semplice test di download FTP o HTTP.

Nota: il test di caricamento e download basato su FTP o HTTP è affidabile solo per velocità di test di circa 3 Mbps o meno. A velocità più elevate, la potenza di elaborazione del dispositivo CPE, del server o delle schede di interfaccia di rete (NIC, Network Interface Card) può diventare un fattore limitante nel test. Per verificare velocità superiori a circa 3 Mbps, utilizzare apparecchiature dedicate per il test del throughput dei dati.

Nell'esempio seguente viene eseguito un semplice test di download e caricamento FTP tra una periferica CPE collegata a un modem via cavo e un server FTP sulla rete del provider di servizi via cavo. Il modem via cavo ha scaricato un file di configurazione DOCSIS che consente una velocità di download fino a 256 Kbps e una velocità di caricamento fino a 64 Kbps. In questo test è stato inserito un file da 3 MB sul server FTP all'indirizzo IP 172.17.110.132. L'utente del dispositivo CPE dispone di un nome utente e di una password per accedere al server FTP e scaricare il file dal server FTP, quindi caricarlo nuovamente sul server FTP. Per eseguire il trasferimento viene utilizzata l'utilità FTP della riga di comando. Questa utilità è disponibile praticamente in tutte le versioni di Microsoft Windows e UNIX.

Un test simile viene eseguito impostando un server Web HTTP nella rete del provider di servizi ed eseguendo un download HTTP.

Figura 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.

Durante il trasferimento FTP, è possibile monitorare l'avanzamento del test sul CMTS utilizzando il comando show interface cable X/Y sid Z counters, in cui il cavo X/Y è l'interfaccia del cavo a cui il modem sottoposto a test è collegato e Z è il numero ID servizio (SID) del modem sottoposto a test. Questo comando mostra quanti byte vengono trasferiti da o verso un particolare modem via cavo. Ad esempio, se il CPE da testare si trova dietro un modem via cavo con indirizzo MAC 0001.9659.4461.

Individuare innanzitutto il numero SID del modem da testare utilizzando il comando show cable modem. In questo caso, il SID del modem via cavo è 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

Durante il download o il caricamento, azzerare tutti i contatori dei pacchetti sul CMTS utilizzando il comando clear counters. Quando i contatori vengono azzerati, avviare un cronometro o un timer.

uBR7246-VXR# clear counters

!--- Reset packet counter to zero.

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

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

Dopo che il cronometro o l'ora legge esattamente un minuto, eseguire il comando show interface cable X/Y sid Z counters. È consigliabile digitare il comando per primo e quindi premere Invio esattamente quando il timer indica un minuto. Il test può essere eseguito su un periodo più lungo o più breve. Più lungo è il periodo di prova, più accurato sarà il risultato, ma assicurati che il download o il caricamento non finisca prima che il timer del cronometro raggiunga il tempo specificato, altrimenti la misurazione non sarà accurata.

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#

In questo caso è in corso il test della velocità di download. L'output del comando show interface cable X/Y sid Z counter indica che in un periodo di un minuto, il modem via cavo scarica 1.921.488 byte. La conversione di 1.921.488 byte in bit rivela:

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

Quindi, per trovare la velocità di download in bit al secondo, dividere questo numero totale di bit scaricati per il tempo necessario per scaricarli in secondi.

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

La velocità di download indicata in questo esempio è di circa 256 Kbps, che corrisponde alla velocità di download consentita per il modem via cavo sottoposto a test.

Per esaminare la velocità di caricamento con il comando show interface cable X/Y sid Z counters, è necessario usare la colonna Ingettets per determinare il numero di byte inviati nella direzione a monte dal modem via cavo.

Per ulteriori informazioni sul comando show interface cable sid counters, consultare la guida di riferimento dei comandi di Cisco Broadband Cable.

Motivi potenziali per prestazioni insoddisfacenti

Prestazioni limitate dal file di configurazione DOCSIS

La prima informazione da raccogliere per risolvere i problemi di prestazioni lente del modem via cavo è la classe di limiti di velocità di trasmissione del servizio prescritta per il modem via cavo. Quando un modem via cavo è in linea, scarica un file di configurazione DOCSIS contenente i limiti operativi per il modem via cavo, incluse le velocità massime di caricamento e download. In circostanze normali, il modem via cavo non può superare queste velocità.

Inizialmente è necessario identificare l'indirizzo MAC di un modem via cavo che presenta problemi. Utilizzo di un modem con indirizzo MAC 0050.7366.2223 che presenta problemi di velocità di trasmissione lenta,. per conoscere la classe del profilo del servizio utilizzata dal modem via cavo, eseguire il comando show cable modem <mac-address>, come mostrato nell'esempio che segue.

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

In questo esempio, il modem via cavo ha un profilo QoS (Quality of Service) di 5. Per verificare le velocità a valle e a monte di questo profilo QoS, usare il comando show cable qos profile-number, dove profile-number è il profilo QoS desiderato.

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

Qui mostra che il profilo QoS 5 corrisponde a un servizio che fornisce 256 Kbps in downstream e 64 Kbps in upstream. Tutti i CPE collegati ai modem via cavo che utilizzano il profilo QoS 5 non possono superare questi limiti. Le impostazioni del profilo QoS sono determinate dal contenuto dei file di configurazione DOCSIS scaricati dai modem via cavo dal server TFTP del sistema di provisioning, quindi il profilo QoS 5 nel sistema potrebbe non essere uguale al profilo QoS 5 nell'esempio mostrato sopra.

Se le prestazioni di download e caricamento di un utente finale sono correlate ai limiti indicati nel profilo QoS, si ottengono la classe di servizi e i livelli di velocità effettiva per cui il modem via cavo è stato predisposto e configurato. L'unico modo per aumentare la velocità di caricamento e download è modificare il file di configurazione DOCSIS scaricato dal modem via cavo in modo che abbia limiti di velocità più elevati. Per istruzioni dettagliate su come creare o modificare un file di configurazione DOCSIS, vedere il documento Building DOCSIS 1.0 Configuration Files Using Cisco DOCSIS Configurator.

Utilizzo di un metodo non ottimale per la limitazione della velocità

Quando un utente finale sta tentando di scaricare dati da Internet a una velocità superiore a quella consentita dal file di configurazione DOCSIS del modem via cavo, il CMTS deve limitare la velocità del traffico inviato a tale utente per garantire che non utilizzi una quantità di larghezza di banda superiore a quella consentita.

Analogamente, quando un utente finale tenta di caricare o inviare dati a Internet a una velocità superiore a quella consentita dal file di configurazione DOCSIS, il modem via cavo stesso deve impedire al traffico in eccesso di viaggiare attraverso il segmento di cavo fino al CMTS. Se per qualche motivo il modem via cavo non riesce a eseguire correttamente la limitazione della velocità a monte, il CMTS impedisce esplicitamente al modem via cavo di trasmettere una velocità superiore a quella consentita. Questo comportamento nel CMTS garantisce che anche un modem via cavo con caratteristiche "hackerate" non sia in grado di sovvertire i limiti di velocità assegnati al provider di servizi.

Lo schema di limitazione della velocità predefinito utilizzato dal CMTS monitora la velocità del traffico da o verso ciascun modem via cavo su un periodo di un secondo. Se il modem via cavo invia o riceve più traffico della propria quota al secondo in meno di un secondo, il CMTS non consente il flusso di traffico verso il modem via cavo per il resto del secondo.

Ad esempio, si prenda un modem via cavo con un profilo QoS che consenta una velocità di download di 512 Kbps. Se il modem via cavo scarica 512 kilobyte (64 kilobyte) entro la prima metà di un secondo, per la metà successiva del secondo, il modem via cavo non potrà scaricare nulla. Questo tipo di comportamento di limitazione della velocità può avere l'effetto di uno schema di download frammentato che sembra interrompersi e iniziare ogni secondo o due.

Il miglior schema di limitazione della velocità a valle da utilizzare è l'algoritmo di limitazione della velocità del token bucket con traffic shaping. Questo schema di limitazione della velocità è stato ottimizzato per consentire un'esplorazione del Web fluida a una velocità costante, garantendo allo stesso tempo che agli utenti finali non sia consentito superare la velocità di download prescritta, come specificato nel file di configurazione DOCSIS.

Questo schema funziona per misurare la velocità con cui un modem via cavo scarica o carica i dati ogni volta che un pacchetto viene inviato da o verso il modem via cavo. Se l'invio o la ricezione del pacchetto in questione causa il superamento da parte del modem delle velocità di trasferimento consentite, il pacchetto viene memorizzato nel buffer o memorizzato nella cache nella memoria CMTS finché il CMTS non è in grado di inviarlo senza superare il limite della larghezza di banda a valle.

Nota: se la velocità del traffico a valle supera costantemente la velocità a valle consentita per il modem via cavo, i pacchetti vengono infine scartati.

Utilizzando questo metodo più uniforme di limitazione e shaping della velocità, la maggior parte delle applicazioni Internet basate su TCP, quali l'esplorazione Web HTTP e i trasferimenti di file FTP, funzionano in modo più agevole ed efficiente rispetto allo schema di limitazione della velocità predefinito.

Lo schema token-bucket rate-limiting-with-traffic-shaping può essere abilitato sul percorso a valle su un'interfaccia via cavo eseguendo il seguente comando di configurazione dell'interfaccia:

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

Nota: si consiglia di abilitare il token bucket shaping nel CMTS dell'utente. Questo comando è supportato a partire dal software Cisco IOS versione 12.0(5)T1 e 12.1(1)EC1.

Il token-bucket con schema di traffic shaping può essere applicato anche alle porte a monte, ma poiché spetta ai modem via cavo limitare la velocità a monte, lo schema di limitazione della velocità a monte applicato al CMTS non avrà alcun impatto sulle prestazioni del sistema.

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

Per ulteriori informazioni sui comandi downstream rate-limit e upstream rate-limit, consultare la Cisco Broadband Cable Command Reference Guide.

Gli utenti possono verificare la gravità della limitazione del traffico del CMTS a un particolare modem via cavo utilizzando il comando show interface cable X/Y sid <Z>, dove cable X/Y è l'interfaccia a cui è connesso il modem via cavo e Z è il numero SID del modem rilevato. Questo comando visualizza il numero di volte in cui il CMTS ha scartato un pacchetto downstream o ha rifiutato di consentire un pacchetto upstream perché il modem superava i limiti di velocità consentiti. Se non si specifica alcun valore per Z, vengono visualizzate le informazioni del contatore per tutti i modem via cavo collegati al cavo di interfaccia X/Y.

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

Il campo Ratelimit DSPktDrop visualizza il numero di volte in cui il CMTS ha scartato pacchetti destinati al modem via cavo per il tentativo di superamento della velocità effettiva di downstream consentita.

Il campo Ratelimit BWReqDrop mostra quante volte il CMTS ha rifiutato a un modem via cavo di inviare un pacchetto nel percorso a monte a causa del tentativo del modem di superare la velocità di trasmissione upstream consentita. Nella maggior parte dei casi, questo contatore deve sempre rimanere uguale a 0. Se sale significativamente al di sopra di zero, è possibile che il modem via cavo osservato non stia eseguendo correttamente la limitazione della velocità a monte.

Nota: i valori visualizzati dal comando show interface cable X/Y sid Z counters possono essere azzerati usando il comando clear counters, come mostrato nell'esempio che segue.

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

Per ulteriori informazioni sul comando show interface cable sid counters, consultare la guida di riferimento dei comandi di Cisco Broadband Cable.

Congestione canale upstream

Il canale a monte è normalmente la risorsa più preziosa in un sistema di cavi. Attualmente, la maggior parte dei provider di servizi via cavo utilizza una larghezza del canale di 1,6 MHz e una modulazione QPSK (Quadrature Phase Shift Keying) nel percorso a monte. Ciò equivale a circa 2,5 Mbps di larghezza di banda upstream totale disponibile per tutti gli utenti connessi a un canale upstream. È importante garantire che il canale a monte non venga sovrautilizzato o congestionato, altrimenti tutti gli utenti del segmento a monte subiranno prestazioni insoddisfacenti.

L'utilizzo a monte per una particolare porta a monte può essere ottenuto eseguendo il comando CMTS show interface cable X/Y upstream <Z>, dove cable X/Y è il numero dell'interfaccia a valle e Z è il numero della porta a monte. Se Z viene omesso, verranno visualizzate le informazioni relative a tutti gli upstream sul cavo di interfaccia X/Y. Per ulteriori informazioni sul comando show interface cable upstream, consultare la guida di riferimento dei comandi di Cisco Broadband Cable.

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

Sulla porta a monte illustrata nell'esempio, l'utilizzo a monte è attualmente del 18% e vi sono 359 modem connessi a questo upstream.

Se l'utilizzo del canale a monte è costantemente superiore al 75% durante i tempi di picco, gli utenti finali iniziano a soffrire di problemi quali latenza, tempi di "ping" più lenti e un'esperienza Internet generalmente più lenta. Se l'utilizzo del canale upstream è costantemente al di sopra del 90% durante i tempi di picco, gli utenti finali sperimentano un livello di servizio estremamente basso perché gran parte dei dati upstream dell'utente finale dovrà essere ritardata o eliminata.

L'utilizzo del canale upstream cambia durante il giorno, poiché diversi utenti hanno la possibilità di utilizzare il modem via cavo, pertanto è importante monitorare l'utilizzo upstream durante gli orari più attivi del giorno piuttosto che in periodi di basso utilizzo.

I modi per ridurre la congestione a monte includono:

- Riduzione del numero di modem via cavo per upstream: se vi sono troppi modem via cavo connessi a un particolare upstream, o se gli utenti di un particolare upstream sono utenti con uso intensivo della larghezza di banda upstream, la soluzione migliore è spostare alcuni utenti della porta upstream congestionata in una porta upstream sottoutilizzata o in una porta upstream completamente nuova. Questo avviene in genere spostando un nodo fibra da un gruppo di combinazione a monte a un altro o dividendo un gruppo di combinazione a monte in due gruppi di combinazione separati. Per ulteriori informazioni, vedere Qual è il numero massimo di utenti per CMTS.

- Aumento della larghezza del canale a monte - Questo comporta un'analisi rigorosa e completa dello spettro a monte per trovare una banda sufficientemente ampia con le caratteristiche del rapporto segnale/rumore (SNR) adeguate per supportare l'aumento della larghezza del canale. La larghezza del canale a monte non deve essere modificata senza un'attenta pianificazione, in quanto questa modifica potrebbe influire su altri servizi nel sistema di cavi dell'utente. La larghezza del canale a monte può essere modificata utilizzando il cavo di comando dell'interfaccia del cavo a monte Z channel-width <new-channel-width> dove Z è il numero della porta a monte e la nuova larghezza del canale è una delle seguenti: 200000, 400000, 800000, 1600000 (impostazione predefinita) o 3200000. Di seguito è riportato un esempio.

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

Per ulteriori informazioni sul comando show interface cable upstream, consultare la guida di riferimento dei comandi di Cisco Broadband Cable.

- Cambiare lo schema di modulazione digitale a monte in 16-Quadrature Amplitude Modulation (QAM) - Ancora una volta, questo richiede un'analisi rigorosa e completa dello spettro a monte per verificare se esiste una banda di frequenza disponibile a monte che può supportare la modulazione 16-QAM. Se l'analisi non viene eseguita correttamente, vi è il rischio che le prestazioni diminuiscano ulteriormente o che si verifichi un'interruzione completa a monte. Lo schema di modulazione a monte può essere modificato creando un profilo di modulazione a monte che utilizza la modulazione 16-QAM e quindi applicandolo a una porta a monte. Segue un esempio.

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

Per ulteriori informazioni sui comandi cable modulation-profile e cable upstream-profile, consultare la Cisco Broadband Cable Command Reference Guide. Vedere anche Configurazione dei profili di modulazione del cavo sui sistemi di terminazione del modem via cavo di Cisco.

- Riduzione della velocità di trasmissione upstream consentita per modem via cavo - Riducendo la velocità massima di trasmissione upstream nei file di configurazione DOCSIS appropriati, gli utenti del modem via cavo non sono in grado di trasmettere a una velocità altrettanto elevata nella direzione upstream e viene eliminata la congestione upstream. L'aspetto negativo di questo comportamento è che gli utenti di modem via cavo sono limitati a una classe di servizio più lenta. Vedere Creazione di file di configurazione DOCSIS 1.0 con Cisco DOCSIS Configurator.

Nota: le misure discusse in questa sezione non aumentano in modo significativo le prestazioni di un sistema già non congestionato.

Congestione del canale downstream

Il canale a valle ha molto più larghezza di banda da condividere di un singolo canale a monte, quindi il canale a valle non è solitamente soggetto a congestione come il canale a monte. Tuttavia, un numero maggiore di utenti in genere condivide un canale a valle rispetto a qualsiasi singolo canale a monte, quindi se il canale a valle diventa congestionato, tutti gli utenti connessi al segmento a valle sperimentano prestazioni ridotte.

La tabella seguente mostra la larghezza di banda a valle totale disponibile associata ai quattro possibili schemi di modulazione a valle disponibili nei sistemi DOCSIS.

Schema di modulazione a valle

Larghezza di banda downstream disponibile

DOCSIS 64-QAM per il Nord America

27 Mbps

DOCSIS 256-QAM per il Nord America

38 Mbps

Euro DOCSIS 64-QAM

38 Mbps

Euro DOCSIS 256-QAM

54 Mbps

La maggior parte dei sistemi di cavi DOCSIS implementa attualmente il protocollo DOCSIS per il Nord America a 64 QAM e quindi ha a disposizione 27 Mbps per canale downstream.

L'utilizzo del canale downstream può essere determinato usando il comando show interface cable X/Y, dove cable X/Y è l'interfaccia del cavo osservata. La velocità di output visualizzata in bit al secondo deve essere confrontata con la larghezza di banda a valle disponibile, come indicato nella tabella precedente.

Nell'esempio seguente viene analizzata un'interfaccia che utilizza DOCSIS per il Nord America e la modulazione digitale 64-QAM.

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

Il primo componente di questo output da notare è la larghezza di banda dell'interfaccia indicata dal parametro BW. Nel software Cisco IOS versione 12.1(8)EC e successive, questo valore viene regolato automaticamente in base allo schema di modulazione a valle e alla versione di DOCSIS utilizzata. Nelle versioni precedenti al software Cisco IOS versione 12.1(8)EC, questo valore deve essere configurato manualmente con il comando di interfaccia via cavo <larghezza di banda-in-kilo-bit-al-secondo>, altrimenti rimane sul valore predefinito di 27000 Kbps.

Il secondo componente da notare è il carico di trasmissione indicato dal parametro txload. Questo parametro fornisce una metrica su 255 dove 0/255 significa che non viene effettuato il flusso del traffico nella direzione a valle fino a 255/255, ovvero i dati vengono trasferiti nella direzione a valle alla velocità massima possibile (in questo caso a 27000 Kbps). Se questo parametro viene eseguito in modo costante a un valore superiore a circa il 75% durante il tempo di massimo utilizzo (ad esempio, superiore a 191/255), gli utenti finali inizieranno a sperimentare un accesso a Internet più lento e una latenza maggiore.

Il terzo componente da notare è la velocità di output, che mostra la velocità di throughput a valle media in bit al secondo. Se questo numero supera costantemente circa il 75% della larghezza di banda a valle disponibile durante i tempi di picco di utilizzo, gli utenti finali inizieranno a sperimentare un accesso a Internet più lento e una latenza più elevata.

Per impostazione predefinita, queste statistiche vengono calcolate su una media mobile di cinque minuti. Per ulteriori informazioni sul modo in cui viene calcolata la media, fare riferimento a Descrizione della definizione dei bit al secondo (bit/sec) dall'output del comando show interfaces. Il periodo durante il quale viene calcolata questa media può essere ridotto a soli 30 secondi usando il comando di interfaccia del cavo load-interval 30. Se si riduce questo periodo a 30 secondi, si calcola un valore più accurato e aggiornato per ciascuno dei parametri discussi in questa sezione.

L'utilizzo del canale downstream cambia durante il giorno, poiché diversi utenti hanno l'opportunità di utilizzare il modem via cavo, pertanto è importante monitorare l'utilizzo downstream durante gli orari più attivi del giorno piuttosto che nei periodi di basso utilizzo.

I modi per ridurre la congestione a valle includono:

- Riduzione del numero di modem via cavo per downstream: se vi sono troppi modem via cavo collegati a un particolare downstream, o se gli utenti di un particolare downstream sono utenti assidui della larghezza di banda, la soluzione migliore è spostare alcuni utenti del canale a valle congestionato su un altro canale a valle. Ciò avviene in genere suddividendo un gruppo di nodi in fibra a valle associati al flusso a valle in due gruppi separati e assegnando ciascuno dei nuovi gruppi a canali a valle separati. Fare riferimento alla sezione Qual è il numero massimo di utenti per CMTS.

- Modifica dello schema di modulazione digitale a valle a 256-QAM - Questa azione richiede un'analisi rigorosa e completa dello spettro a valle per verificare se il sistema può supportare un segnale 256-QAM. Se l'analisi non viene eseguita correttamente, vi è il rischio che le prestazioni diminuiscano ulteriormente o che si verifichi un'interruzione completa a valle. Lo schema di modulazione a valle può essere modificato usando il comando interface come mostrato di seguito.

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

Per ulteriori informazioni sul comando cable downstream modulation, consultare la Cisco Broadband Cable Command Reference Guide.

- Riduzione del throughput a valle consentito per modem via cavo - Riducendo la velocità massima di trasmissione a valle nei file di configurazione DOCSIS appropriati, gli utenti dei modem via cavo non sono in grado di scaricare a una velocità così elevata nella direzione a valle e viene eliminata la congestione a valle. L'aspetto negativo di questo comportamento è che gli utenti di modem via cavo sono limitati a una classe di servizio più lenta. Fare riferimento alla sezione Creazione di file di configurazione di DOCSIS 1.0 con Cisco DOCSIS Configurator.

Nota: le misure discusse in questa sezione non aumentano in modo significativo le prestazioni di un sistema già non congestionato.

Rete backhaul o congestione Internet

In alcuni casi, i problemi di prestazioni possono non essere causati da problemi dell'impianto cablato o del CMTS, ma possono essere dovuti a congestione o a problemi della rete backhaul utilizzata dal CMTS per connettersi a Internet o a parti di Internet.

Il modo più semplice per determinare se la congestione della rete backhaul è un problema è connettere una workstation allo stesso segmento di rete del CMTS e cercare di esplorare gli stessi siti Web a cui gli utenti finali che usano i modem via cavo stanno cercando di accedere. Se le prestazioni sono ancora lente, esiste un problema di prestazioni nella rete non correlato al CMTS o al segmento del cavo. Se le prestazioni del segmento di rete CMTS locale sono notevolmente migliori rispetto a quelle degli utenti connessi ai modem via cavo, concentrare gli sforzi sul segmento CMTS e sul segmento del cavo.

Figura 3

Nella rete sopra indicata, se il server 1, connesso allo stesso segmento di rete del CMTS, sta ottenendo prestazioni lente durante l'esplorazione di Internet, allora la causa del problema non è il CMTS. Invece, il collo di bottiglia o il problema di prestazioni da qualche altra parte. Per determinare la causa del problema, vengono eseguiti test delle prestazioni tra il server 1 e diversi altri server della rete del provider di servizi Internet (ISP) e la rete Internet pubblica.

Disturbo ed errori nell'impianto cablato

Se in un sistema via cavo vi è una quantità eccessiva di rumore o ingresso, i pacchetti tra i modem via cavo e il CMTS possono essere danneggiati e persi. Ciò può causare un significativo peggioramento delle prestazioni.

Oltre a una riduzione delle prestazioni e del throughput, alcuni dei principali indicatori di rumore o radiofrequenza (RF) includono:

- Modem cablati che si disconnettono sporadicamente o si bloccano negli stati init(r1) o init(r2).

- Valore SNR stimato basso come mostrato nell'output di un cavo show controller X/Y a monte Z, dove cavo X/Y è l'interfaccia del cavo osservata e Z è la porta a monte osservata. La specifica DOCSIS richiede un rapporto vettore/rumore (CNR) di almeno 25 dB per tutti i segnali a monte. Ciò equivale a un SNR di circa 29 dB. Il Cisco CMTS è in grado di rilevare in modo coerente i segnali a monte QPSK a livelli SNR molto peggiori, tuttavia tutti i provider di servizi via cavo devono cercare di soddisfare i requisiti DOCSIS CNR nel proprio sistema. Di seguito è riportato un esempio di output Z a monte del cavo del controller X/Y.

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

Nell'esempio sopra riportato, il valore SNR stimato è 28,628 dB. Questa opzione è adeguata per il funzionamento upstream di QPSK. Si noti che la cifra SNR fornita nell'output di questo comando è solo una stima e non può sostituire una cifra SNR derivata da un analizzatore di spettro o da un'altra apparecchiatura di prova appropriata. Vedere la Cisco Broadband Cable Command Reference Guide per ulteriori informazioni sul comando show controller cable upstream spectrum.

- Un numero in rapido aumento di errori FEC (Corr Forward Error Correction) e Uncorr FEC nell'output di un comando show cable hop. Corr FEC errors indica dati danneggiati da disturbi a monte ma recuperabili. Gli errori FEC di errore indicano dati danneggiati da rumori a monte e che non è stato possibile ripristinarli, con conseguente perdita di dati e riduzione delle prestazioni. Di seguito è riportato un output di esempio del comando show cable hop.

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

Nell'esempio di cui sopra, ciascuna porta a monte attiva sul cavo 3/0 sembra aver subito una perdita di pacchetto a causa del rumore. La porta a monte 0 sembra essere la meno interessata e la porta a monte 2 sembra essere la più colpita. Il fattore importante da notare è la velocità con cui gli errori FEC aumentano anziché il numero totale di errori. Per ulteriori informazioni sul comando show cable hop, consultare la guida di riferimento dei comandi di Cisco Broadband Cable.

- Un numero elevato di eventi "flap" nell'output di un comando show cable flap-list. Le statistiche di flap più rilevanti per possibili problemi di RF o di rumore sono la colonna Miss, che indica le richieste di range mancanti, e la colonna P-Adj, che indica i livelli di potenza a monte che variano rapidamente. Di seguito è riportato un esempio di output del comando show cable flap-list.

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

- Modem cablati che visualizzano un "* "o un "!—" nell'output di un comando show cable modem o show cable flap-list. Un "*" indica un modem via cavo che sta cambiando rapidamente i livelli di potenza a monte. Ciò è indicativo di una scarsa connessione all'impianto cablato, di un amplificatore a percorso inverso difettoso o di una rapida variazione dell'attenuazione dell'impianto cablato a causa della temperatura o di altri effetti ambientali. Un "!—" indica un modem via cavo che ha raggiunto il livello massimo di potenza in upstream. Ciò indica che l'attenuazione tra il modem via cavo e il CMTS è eccessiva o che la connessione tra il modem via cavo e l'impianto è insufficiente. Di seguito è riportato un output di esempio del comando show cable modem.

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

Nell'esempio precedente, il modem via cavo con indirizzo MAC 005a.73f6.2213 sta trasmettendo alla sua potenza massima in uscita. In questo modo il modem non è in grado di trasmettere al livello corretto. Di conseguenza, le trasmissioni a monte di questo modem non vengono ascoltate con la stessa chiarezza delle trasmissioni da altri modem. Il modem via cavo con indirizzo MAC 009c.96d7.3831 ha una potenza di uscita che varia rapidamente a causa della diversa attenuazione del sistema. Per ulteriori informazioni sul modem show cable e i comandi show cable flap-list, consultare la guida di riferimento dei comandi di Cisco Broadband Cable.

Nota: per ulteriori informazioni sull'identificazione e la risoluzione dei problemi di rumore RF, vedere Determinazione dei problemi di RF o di configurazione sul CMTS e Collegamento del router Cisco serie uBR7200 all'headend via cavo.

Utilizzo CPU elevato nel CMTS

In alcune circostanze un Cisco CMTS può sovraccaricare il sistema a causa di una configurazione non ottimale, di un uso eccessivo di alcune funzioni di gestione o di un numero molto elevato di pacchetti instradati dal CMTS.

Il modo migliore per determinare l'utilizzo della CPU da parte di un Cisco CMTS è eseguire il comando show process cpu. L'utilizzo corrente della CPU è indicato nella prima riga dell'output del comando.

Nelle righe di output mostrate sotto la prima riga, viene mostrato ciascun processo in esecuzione sul CMTS insieme alla parte di CPU utilizzata da quel processo. Questa sezione dell'output show process cpu è utile per determinare se un particolare processo o funzione è la causa dell'elevata CPU CMTS.

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

Nell'esempio precedente, il carico della CPU corrente sul CMTS è del 45%/21%. Ciò significa che l'utilizzo totale della CPU è al 45% della capacità del sistema. Inoltre, il 21% della CPU viene utilizzato per servire gli interrupt. Questa seconda cifra in genere equivale alla parte della CPU utilizzata per instradare i pacchetti e instradare il traffico di switch attraverso il CMTS.

Se l'utilizzo della CPU nei cinque minuti è costantemente superiore all'80% durante il tempo di picco del sistema, gli utenti finali potrebbero iniziare a sperimentare prestazioni più lente e una maggiore latenza. Se l'utilizzo della CPU nei cinque minuti è costantemente superiore al 95% durante il tempo di picco, adottare misure urgenti per garantire che il CMTS rimanga stabile.

Le strategie comuni per ridurre l'utilizzo elevato della CPU nel CMTS includono:

- Aggiornamento al software Cisco IOS versione 12.1(9)EC o successive, attivazione del comando di configurazione globale ip cef e verifica che sulle interfacce del CMTS non sia configurato il comando no ip route-cache. In questo modo, l'utilizzo della CPU correlata al traffico viene in genere ridotto del 10-15%. Accertarsi che tutte queste operazioni vengano eseguite congiuntamente.

- Accertarsi che le stazioni di gestione SNMP (Simple Network Management Protocol) non siano troppo aggressive per il polling del CMTS. Ciò comporta un utilizzo elevato della CPU nel processo SNMP IP.

- Il comando show tech non viene eseguito più volte in successione. Ciò determina un utilizzo artificialmente elevato della CPU nel processo Virtual Exec.

- Accertarsi che non siano in esecuzione comandi di debug sul CMTS.

Per ulteriori informazioni sull'utilizzo elevato della CPU sui router Cisco, tra cui i prodotti Cisco CMTS, consultare il documento sulla risoluzione dei problemi di utilizzo elevato della CPU sui router Cisco.

Apparecchiature CPE con o senza alimentazione

In molti casi, la causa della lentezza di accesso a una rete via cavo è un problema nelle apparecchiature CPE dell'utente finale. Se solo uno o pochi utenti riscontrano un throughput lento e il resto della popolazione di utenti non incontra alcun problema, ciò indica chiaramente che potrebbe esserci un problema unico nell'ambiente di quell'utente.

- CPE sottoalimentato o sovraccarico: se gli utenti finali che si lamentano delle difficoltà utilizzano apparecchiature CPE obsolete o apparecchiature che potrebbero non essere sufficientemente potenti per eseguire il sistema operativo o il software di accesso a Internet prescelto, l'utente finale avrà difficoltà. L'unica risoluzione in questo caso è che l'utente finale deve aggiornare le proprie apparecchiature CPE.

- Firewall o software di misurazione delle prestazioni: se l'utente finale utilizza un firewall, un sistema di misurazione delle prestazioni della rete o un altro software simile, per risolvere il problema è consigliabile disattivare il software e verificare se influisce sulle prestazioni. Spesso questo tipo di software può avere un impatto negativo sulle prestazioni.

- Impostazioni TCP/IP non configurate correttamente: la maggior parte dei provider di servizi richiede che gli utenti finali acquisiscano un indirizzo IP, una maschera di rete, un gateway predefinito e i server DNS tramite il protocollo DHCP (Dynamic Host Configuration Protocol). Verificare che gli utenti finali che riscontrano problemi dispongano di dispositivi CPE configurati per l'utilizzo di DHCP per acquisire tutti questi parametri.

Se un utente finale dichiara di non avere nessuno dei problemi elencati in precedenza, confermare che l'utente finale non superi la velocità massima di download o caricamento indicata nelle sezioni precedenti.

Conclusioni

Una rete cablata DOCSIS è un sistema sofisticato che richiede un'adeguata pianificazione e manutenzione. La maggior parte dei problemi di prestazioni nei sistemi di cavi DOCSIS è il risultato diretto della mancata esecuzione di attività di pianificazione e manutenzione appropriate. Nell'attuale mercato dell'accesso a Internet, in cui esistono diverse alternative per l'accesso a Internet a banda larga, è importante che i fornitori di servizi via cavo affrontino rapidamente qualsiasi problema di prestazioni o congestione nel loro sistema prima che i problemi diventino sufficientemente significativi da interessare in modo significativo gli utenti finali e, di conseguenza, prendere in considerazione un mezzo alternativo di accesso a banda larga.

Informazioni correlate

- Risoluzione dei problemi relativi ai modem cablati uBR non in linea

- Determinazione dei problemi di RF o di configurazione sul CMTS

- Connessione del router Cisco serie uBR7200 all'headend via cavo

- Risoluzione dei problemi relativi all'utilizzo elevato della CPU nei router Cisco

- Documentazione e supporto tecnico – Cisco Systems