Risoluzione dei problemi di prestazioni del throughput DOCSIS RPD

Introduzione

In questo documento viene descritto come risolvere i problemi di prestazioni di Cisco Remote PHY Device (RPD).

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• RPD
• Cisco Converged Broadband Router (cBR)-8
• Specifica dell'interfaccia di servizio Data Over Cable (DOCSis)

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

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.

Premesse

Lo scenario preso in considerazione in questo articolo riguarda un RPD fornito da Cisco cBR-8 come CCAP (Converged Cable Access Platform). Il protocollo PTP (Precision Time Protocol) viene utilizzato per sincronizzare un orologio primario esterno con i protocolli cBR-8 e RPD che agiscono come secondari. Per ulteriori informazioni sulla progettazione di PTP in questo ambiente, consultare Suggerimenti per la progettazione di PTP per reti R-PHY.

Questo non è un elenco esaustivo di passaggi per risolvere i problemi di prestazioni con RPD, anche se è un buon inizio per isolare il problema.

Risoluzione dei problemi

Se durante l'installazione di RPD si riscontra un peggioramento delle prestazioni e si desidera eseguire una risoluzione iniziale dei problemi, non è chiaro da dove iniziare.

In questa sezione vengono descritti alcuni problemi comuni che possono essere la possibile causa dei problemi di prestazioni degli RPD.

Messaggi MAP in ritardo

Una condizione di messaggio MAP (Latest upstream bandwidth allocation map) si verifica quando un modem riceve un messaggio MAP in un determinato momento, dopo che gli intervalli di tempo descritti nel messaggio si sono già verificati.  Il modem non è in grado di utilizzare questo messaggio MAP, quindi non è in grado di inviare traffico sulle concessioni assegnate.

Alcune MAPPE in ritardo possono causare una riduzione delle velocità del traffico a monte, nonché delle velocità del traffico TCP a valle ridotte quando gli ACK a monte sono in ritardo. Se il numero di MAP in ritardo è sufficiente, i modem non saranno in grado di eseguire la manutenzione della stazione e di passare alla modalità offline.

Un altro sintomo può essere la perdita di pacchetti quando si esegue un ping tra il file docsis <MAC_ADDR> da cBR-8 e un modem collegato a un RPD.

Con Remote PHY (R-PHY), il cBR-8 invia messaggi MAP ai modem in un tunnel dell'interfaccia PHY esterna downstream (DEPI) e all'RPD in un tunnel dell'interfaccia PHY esterna upstream (UEPI). Questi messaggi hanno un contrassegno QoS (Quality of Service) più elevato con un valore DSCP (Differentiated Services Code Point) pari a 46 (inoltro espresso - EF).

Se un messaggio MAP destinato all'RPD viene eliminato nel CIN, l'RPD non è in grado di utilizzare questi minislot e li conta come "non mappati". Se il messaggio MAP arriva in ritardo all'RPD, inizialmente conta i minislot come non mappati, quindi dopo aver ricevuto il MAP in ritardo, incrementa il conteggio dei minislot in ritardo.

Anche le mappe precoci sono possibili, ma generalmente si verificano solo quando l'orologio PTP è spento in cBR-8 o RPD.

Sovrapposizione di MAPPE può verificarsi quando i messaggi MAP vengono fuori sequenza ma con una frequenza di appena 2 ms, questo non è in genere un problema. Il numero effettivo di minislot in un messaggio MAP si basa sulla configurazione del minislot per ciascun canale upstream. Se un upstream utilizza due tick per minislot (popolare per SC-QAM a 6,4 MHz), un MAP da 2 ms ha 160 minislot.

Per verificare se sul RPD si ricevono messaggi MAP in ritardo, eseguire questi comandi per accedere alla console RPD. Quindi, eseguire il comando show upstream map counter <porta rf> <canale> più volte e verificare se il contatore "minislot scartati (mappe in ritardo)" aumenta:

cbr8# ssh <RPD_IP_ADDR> -l admin
R-PHY>enable
R-PHY#show upstream map counter 0 0
Map Processor Counters
==============================================
Mapped minislots                  :     553309
Discarded minislots (chan disable):          0
Discarded minislots (overlap maps):          0
Discarded minislots (early maps)  :          0
Discarded minislots (late maps)   :          0 <= check if the counter increases
Unmapped minislots                :          0
Last mapped minislot              :   21900956

Nota: ogni volta che si esegue il comando show upstream map counter, tutti i contatori vengono reimpostati su 0 ma sull'ultimo minislot mappato

Suggerimento: da RPD versione 6.x, è possibile eseguire il comando show tech-support, che raccoglie più occorrenze di show upstream map counter e altri comandi, pertanto utile per il confronto dei contatori.

Se si esegue il software RPD versione 5.x o precedente, è possibile eseguire il comando show tech con lo script disponibile qui: Capture show tech on rpd o limited command on both RPD, supervisor.

La pagina collegata contiene istruzioni su come installare lo script e gli esempi di utilizzo, al termine dei quali è possibile trovare il file Script-Readme.tar disponibile per il download. Questo file contiene lo script sh_tech_rpd.tcl e il file sh_tech_rpd-README.txt con le istruzioni e gli esempi di utilizzo.

Lo script dispone di un'opzione (-c) per raccogliere un ulteriore set di comandi elencati in un file di testo, vengono accettati sia i comandi da emettere sull'RPD stesso che sul supervisore cBR-8 (tutte le procedure spiegate nel collegamento precedentemente menzionato e nel file Leggimi).

Questa funzione utilizza questo script, in modo interessante, anche nelle versioni RPD che includono il comando show tech-support.

Causa potenziale 1. Ritardo CIN, latenza, jitter

Il CIN (Converged Interconnect Network) che collega il core CCAP e gli RPD può introdurre ritardi che devono essere considerati nel timer di anticipo MAP. In caso di modifica del CIN, ad esempio se è stato aggiunto un altro router, è possibile che sia stato introdotto un ritardo superiore.

Il timer di avanzamento MAP viene utilizzato da CCAP per impedire la visualizzazione di messaggi MAP in ritardo. Questo timer è basato su microsecondi (μs) e può essere configurato in modo statico dall'operatore per ogni interfaccia di cavo o calcolato in modo dinamico dal cBR-8.

Il valore dinamico è la somma del tempo in downstream interleaf (680 μs con SC-QAM con 256-QAM), del ritardo di elaborazione MAP del modem (600 μs), del ritardo di rete interno CCAP (300 μs), del valore di sicurezza avanzato MAP (1000 μs per impostazione predefinita) e dell'offset di tempo massimo del modem (in base al modem più distante).

Con R-PHY, il ritardo interno CCAP è ora sostituito da un ritardo di rete, che per impostazione predefinita è di 500 μs. In considerazione del progetto CIN, questo valore può essere maggiore del parametro di default e può variare nel tempo.

I valori di avanzamento MAP per un upstream possono essere visualizzati con questo comando:

cbr8#show controllers upstream-Cable 2/0/5 us-channel 0 cdm-ump
<output omitted>
nom_map_adv_usecs 2899, max_map_adv_usecs 4080 mtn_map_adv 8080
map_adv_alg 1 dyn_map_adv_safety 1000 max_plant_delay 1800
cm_map_proc 600 intlv_delay 680 network_delay 500 max_tmoff 119
<output omitted>

MAPadvance = map_adv_safety (1000) + cm_map_proc (600) + intlv_delay (680) + network_delay (500) + max_tmoff (119) = 2899 μs.

Se la distanza tra cBR-8 e RPD combinati con i ritardi dei dispositivi CIN supera il valore predefinito del ritardo di rete di 500 μs, è possibile che vengano visualizzati messaggi MAP in ritardo.

Quando questo rappresenta un problema, esistono due metodi per gestire il parametro predefinito del ritardo di rete ed entrambi sono impostati per RPD su cBR-8:

• Configurare staticamente il ritardo.
• Impostare cBR-8 per misurare e regolare il ritardo periodicamente.

Il ritardo di rete può essere configurato in modo statico per RPD sul cBR-8 come mostrato di seguito:

cbr8#conf t
cbr8(config)#cable rpd <name>
cbr8(config-rpd)#core-interface <interface_name>
cbr8(config-rpd-core)#network-delay static <CIN_delay_in_us>

Per il ritardo dinamico della rete, cBR-8 si basa su una funzione di misurazione della latenza chiamata DLM (DEPI Latency Measurement), che determina il ritardo unidirezionale nel percorso a valle.

Il cBR-8 invia un pacchetto DLM con il proprio timestamp, quindi l'RPD contrassegna il proprio timestamp sul pacchetto DLM quando ricevuto e lo inoltra nuovamente al cBR-8.

Cisco supporta l'opzione richiesta quando il RPD contrassegna il pacchetto più vicino alla sua interfaccia in entrata, non in uscita.

Il cBR-8 calcola la media degli ultimi 10 valori DLM e la utilizza come valore di ritardo di rete nel calcolo dell'anticipo MAP. I timestamp di cBR-8 e RPD si basano sugli orologi di riferimento PTP.

Avviso: se PTP è instabile, lo sono anche i valori DLM e, in ultima analisi, il timer di avanzamento MAP.

Per impostazione predefinita, DLM è disabilitato e può essere abilitato con il comando network-delay dlm<seconds>, come mostrato. Una volta abilitato, un pacchetto DLM viene inviato periodicamente all'RPD in base al valore configurato.

È possibile aggiungere anche un'opzione di sola misurazione, che misura semplicemente il ritardo CIN senza regolare il valore del ritardo di rete.

Per monitorare il ritardo CIN, si consiglia di abilitare almeno DLM nel parametro relativo alla sola misura.

cbr8#conf t
cbr8(config)#cable rpd <name>
cbr8(config-rpd)#core-interface <interface_name>
cbr8(config-rpd-core)#network-delay dlm <interval_in_seconds> [measure-only]

Usage:

cbr8#show cable rpd a0f8.496f.eee2 dlm
DEPI Latency Measurement (ticks) for a0f8.496f.eee2
  Last Average DLM:              481
  Average DLM (last 10 samples): 452
  Max DLM since system on:       2436
  Min DLM since system on:       342
  Sample #     Latency (usecs)
  x------------x------------
  0            52
  1            41
  2            48
  3            41
  4            41
  5            44
  6            40
  7            45
  8            44
  9            41

Per ulteriori informazioni su questa funzione, fare clic qui. Misurazione latenza DEPI

La sicurezza dell'avanzamento MAP può anche essere modificata manualmente nella configurazione dell'interfaccia del cavo (i valori predefiniti sono 1000 μs per il fattore di sicurezza e 18000 μs per l'avanzamento massimo della mappa):

cbr8#conf t
cbr8(config)#interface Cable1/0/0
cbr8(config-if)# cable map-advance dynamic 1000 18000

OR (if a mac-domain profile is used)

cbr8#conf t
cbr8(config)# cable profile mac-domain RPD
cbr8(config-profile-md)# cable map-advance dynamic 1000 18000

Attenzione: ritardi CIN molto brevi possono causare anche messaggi MAP in ritardo

Sono stati osservati problemi con il traffico DOCSIS a monte ignorato quando il timer di avanzamento MAP è inferiore a 2500 μs.

Alcuni modem possono impiegare più tempo per elaborare i messaggi MAP e tale ritardo può causare dei messaggi MAP in ritardo per tali modem (RPD probabilmente non mostra i conteggi MAP in ritardo se è stato in grado di ottenere il messaggio in tempo).

Un timer di avanzamento MAP basso è possibile con valori DLM molto bassi, o con un ritardo di rete manuale basso o con una configurazione di sicurezza avanzata MAP. I valori di ritardo di rete nel calcolo dell'anticipo MAP possono essere bassi fino a 30 μs (anche se la media DLM è inferiore).

Si consiglia di utilizzare l'opzione "solo misura" di DLM o aumentare il fattore di sicurezza per l'avanzamento dinamico della MAPPA fino a quando il timer dell'avanzamento della MAPPA non supera i 2500 μs.

Causa potenziale 2. Bug software

Per verificare se un bug del software causa un errore di sincronizzazione, si consiglia di aprire una richiesta di servizio in collaborazione con Cisco per esaminare ulteriormente il caso specifico.

La soluzione in caso di guasto del software consiste in genere nell'aggiornamento del software a una delle versioni che contiene la correzione. Poiché esiste una correlazione di compatibilità tra le versioni software cBR-8 e RPD, è importante scegliere la versione corretta per entrambi i dispositivi.

Per scegliere il software Cisco IOS® XE più adatto a ogni RPD, è possibile consultare le compatibilità tra le versioni software tra cBR-8 e RPD nelle guide all'installazione e all'aggiornamento PHY remote di Cisco.

In questa tabella è possibile trovare un riepilogo della compatibilità delle versioni software tra cBR-8 e RPD, con le versioni software disponibili al momento della scrittura:

Compatibilità di versione tra Cisco cBR-8 e Cisco RPD
Cisco cBR-8 versione	Versione di rilascio RPD compatibile
Cisco IOS® XE Everest 16.6.x	Cisco 1x2 RPD Software 2.x
Cisco IOS® XE Fuji 16.7.x	Cisco 1x2 RPD Software 3.x
Cisco IOS® XE Fuji 16.8.x	Software Cisco RPD 1x2 4.x
Cisco IOS® XE Fuji 16.9.x	Cisco RPD Software 1x2 5.x
Cisco IOS® XE Gibraltar 16.10.1c	Software Cisco 1x2 RPD 6.1, 6.2, 6.3
Cisco IOS® XE Gibraltar 16.10.1d	Software Cisco 1x2 RPD 6.4, 6.5, 6.7
Cisco IOS® XE Gibraltar 16.10.1f	Software Cisco 1x2 RPD 6.6, 6.7
Cisco IOS® XE Gibraltar 16.10.1g	Software Cisco RPD 1x2 7.1, 7.2, 7.3, 7.4.x, 7.5
Cisco IOS® XE Gibraltar 16.12.1	Software Cisco RPD 1x2 7.1, 7.2, 7.3, 7.4.x, 7.5
Cisco IOS® XE Gibraltar 16.12.1w	Software Cisco RPD 1x2 7.1, 7.2, 7.3, 7.4.x, 7.5
Cisco IOS® XE Gibraltar 16.12.1x	Software Cisco RPD 1x2 7.6, 7.7
Cisco IOS® XE Gibraltar 16.12.1y	Software Cisco RPD 1x2 7.8, 7.8.1, 8.2
Cisco IOS® XE Gibraltar 16.12.1z	Software Cisco 1x2 RPD 8.3, 8.4, 8.5
Cisco IOS® XE Gibraltar 17.2.1	Software Cisco 1x2 RPD 8.1, 8.2, 8.3, 8.4, 8.5

Latenza upstream

Come descritto nella sezione precedente, i lunghi ritardi CIN possono causare problemi di messaggi MAP in ritardo e possono essere risolti con l'aumento del timer del MAP. Ciò comporta a sua volta un ritardo più lungo nella concessione delle richieste, che determina un aumento della latenza a monte.

Poiché i flussi di traffico a monte costanti utilizzano richieste piggy-back, il test della velocità del traffico a monte può apparire normale e anche i flussi vocali con Unsolicited Grant Service (UGS) non subiscono alcun impatto, in quanto non sono necessarie richieste.

Tuttavia, le velocità del traffico TCP in downstream possono essere ridotte per la mancanza di ACK upstream tempestivi. Sebbene sia possibile affrontare i ritardi di elaborazione e di accodamento sul CIN, è improbabile che i segnali viaggino più velocemente su una determinata distanza.

Cisco ha sviluppato DOCSIS Predictive Scheduling (DPS) per ridurre il ritardo delle richieste-concessioni nelle applicazioni R-PHY con ritardi CIN più lunghi. DPS fornisce in modo proattivo sovvenzioni ai modem in base all'utilizzo storico, per ridurre al minimo il ritardo delle richieste di concessione.

DPS è un metodo di pianificazione pre-standard, simile al Proactive Grant Service (PGS) descritto nella recente specifica DOCSIS (LLD) a bassa latenza.  Tuttavia, DPS può essere abilitato per ogni interfaccia e viene applicato a tutti i flussi di servizi upstream più impegnativi. Poiché il protocollo PGS viene applicato al traffico come tipo di flusso del servizio, è necessario modificare il file di configurazione del modem.

DPS può essere abilitato con il comando interface: cbr8(config-if)#cable upstream dps

Sebbene sia disponibile da quando il supporto di R-PHY è stato aggiunto al cBR-8, al momento non è una funzionalità ufficialmente supportata. Tuttavia, il DPS può essere efficace per risolvere il rallentamento della velocità di trasmissione TCP in downstream associato agli ACK ritardati.

Pacchetti L2TP (Layer 2 Tunneling Protocol) fuori servizio

Sulla console RPD, digitare questo comando più volte per verificare se i contatori "SeqErr-pkts" e "SeqErr-sum-pkts" sono positivi e in aumento, il che indica che L2TP non ha ordinato pacchetti:

R-PHY# show downstream channel counter dpmi
Chan Flow_id SessionId(dec/hex)      Octs       Sum-octs   SeqErr-pkts SeqErr-sum-pkts
0    0       4390912    / 00430000   328        22770      0           1         
0    1       4390912    / 00430000   25074      1179672    0           1         
0    2       4390912    / 00430000   6022168    271459412  0           1         
0    3       4390912    / 00430000   0          0          0           0      

Causa potenziale 1. Bilanciamento del carico

In alcune condizioni particolari, come ad esempio la congestione dei collegamenti nel CIN, il bilanciamento del carico può contribuire al problema dei pacchetti ricevuti fuori servizio alla destinazione.

Se è possibile, per verificare se il bilanciamento del carico causa questo problema, è possibile provare a imporre un singolo percorso in cui è configurato il bilanciamento del carico. Se in questo modo si risolve il problema dei pacchetti non ordinati, si ha la conferma dell'attivazione e si può indagare ulteriormente la causa principale della rete.

Causa potenziale 2. Perdite di pacchetti

1. Verificare la presenza di errori e cadute maggiori sui contatori cBR-8 dell'interfaccia della scheda DPIC a cui è collegato l'RPD, utilizzando il comando show interface, come mostrato di seguito.

cbr8#sh run | s cable rpd SHELF-RPD0
cable rpd SHELF-RPD0
 description SHELF-RPD0
 identifier a0f8.496f.eee2
[…]
 core-interface Te6/1/2
[…]
cbr8#show interface Te6/1/2
TenGigabitEthernet6/1/2 is up, line protocol is up
  Hardware is CBR-DPIC-8X10G, address is cc8e.7168.a27e (bia cc8e.7168.a27e)
  Internet address is 10.27.62.1/24
  MTU 1500 bytes, BW 10000000 Kbit/sec, DLY 10 usec,
     reliability 255/255, txload 90/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full Duplex, 10000Mbps, link type is force-up, media type is SFP_PLUS_10G_SR
  output flow-control is on, input flow-control is on
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:01, output 00:00:05, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/375/0/22 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 1002000 bits/sec, 410 packets/sec
  5 minute output rate 3535163000 bits/sec, 507528 packets/sec
     88132313 packets input, 26831201592 bytes, 0 no buffer
     Received 0 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 229326 multicast, 0 pause input
     179791508347 packets output, 164674615424484 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     13896 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 pause output
     0 output buffer failures, 0 output buffers swapped out

2. Controllare sul lato RPD se ci sono errori, pacchetti ignorati e pacchetti non in ordine sulle interfacce e sui contatori a valle.

R-PHY#show interface info
eth0      Link encap:Ethernet  HWaddr A0:F8:49:6F:EE:E4
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::a2f8:49ff:fe6f:eee4/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:303 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:44034 (43.0 KiB)
          Memory:1ae2000-1ae2fff
vbh0      Link encap:Ethernet  HWaddr A0:F8:49:6F:EE:E2
          inet addr:10.7.62.7  Bcast:10.7.62.255  Mask:255.255.255.0
          inet6 addr: fe80::a2f8:49ff:fe6f:eee2/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1174200 errors:0 dropped:0 overruns:0 frame:0
          TX packets:593404 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:90888838 (86.6 MiB)  TX bytes:52749774 (50.3 MiB)
vbh1      Link encap:Ethernet  HWaddr A0:F8:49:6F:EE:E3
          inet6 addr: fe80::a2f8:49ff:fe6f:eee3/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:2438 (2.3 KiB)

R-PHY#show downstream channel counter

------------------- Packets counter in TPMI -------------------

Level     Rx-pkts    Rx-sum-pkts
Node Rcv  4673022    2108792873
Depi Pkt  1696       774495

Port Chan SessionId(dec/hex)    Rx-pkts    Rx-sum-pkts
DS_0 0    4390912    /0x00430000 49032      22125274
DS_0 1    4390913    /0x00430001 49025      22116541
[…]
US_0 0    13893632   /0x00D40000 12193      5502543
US_0 1    13893633   /0x00D40001 12193      5501739
[…]

Port      Rx-pkts    Rx-sum-pkts Drop-pkts  Drop-sum-pkts
DS_0      3095440    1396529318  0          0
US_0      49215      22207507    0          0
US_1      0          4679        0          0

------------------- Packets counter in DPMI -------------------

Field        Pkts       Sum-pkts
Dpmi Ingress 12275995   1231753344
Pkt Delete   0          0
Data Len Err 0          0

Chan Flow_id SessionId(dec/hex)      Octs       Sum-octs   SeqErr-pkts SeqErr-sum-pkts
0    0       4390912    / 0x00430000   75         130496     0           1
0    1       4390912    / 0x00430000   15657      7208826    0           1
0    2       4390912    / 0x00430000   3181212    1431951867 0           1
0    3       4390912    / 0x00430000   0          0          0           0
[…]

------------------- Packets counter in DPS -------------------

Chan Tx-packets Tx-octets  Drop-pkts  Tx-sum-pkts Tx-sum-octs Drop-sum-pkts
0    50316      3273636    0          22126173    1439340721  0
1    50311      3272896    0          22117442    1438506648  0
2    50311      3272640    0          22121500    1438772715  0
3    50309      3272640    0          22122038    1438807607  0
[…]

3. Controllare più volte i contatori a valle di InterLaken per verificare la presenza di errori e l'eventuale aumento dei contatori. A tale scopo, è necessario immettere l'interfaccia della console della scheda di linea come mostrato di seguito.

cbr8#request platform software console attach 6/0
#
# Connecting to the CLC console on 6/0.
# Enter Control-C to exit the console connection.
#
Slot-6-0>enable
Slot-6-0#
Slot-6-0#test jib4ds show ilkstat ?
  <0-3>  ILK Link (0-BaseStar0, 1-BaseStar1, 2-Cpu0, 3-Cpu1)

Slot-6-0#test jib4ds show ilkstat 0
Send Show-ilkstat IPC to CDMAN...Wait for output

Slot-6-0#
Jib4DS InterLaken Stats for BaseStar 0:
                    RX-Packets             RX-Bytes            TX-Packets             TX-Bytes
HUB Stats:         10425879607       14415939325556              75237425           8249683443
Chan    0:             4714787            360160866                109750             36594720
Chan    1:         10254597081       14397444921888                     0                    0
Chan    3:               63828             17214818                     0                    0
Chan    5:           166503829          18117169182              75127675           8213088761
PRBS  Err:                   0                    0                     0                    0
CRC32 Err:                   0                    0                     0                    0
CRC24 Err:                          0
Test-pattern-err:                   0

ILK Error log: ptr 0
Idx      Err1     Err2      Rst     Gtx0     Gtx1     Gtx2     Gtx3

Slot-6-0#

4. Prendere un modem collegato a questo RPD (solo canali DS collegati) e inviargli i pacchetti (ad esempio, ping) per verificare se i pacchetti inviati corrispondono al flusso in downstream inserito sui contatori del modulo JIB. Accertarsi che DS JIB abbia inviato tutti i pacchetti di dati DS per il frame DEPI sulla console della scheda di linea. In questo output, è possibile vedere come visualizzare il numero di sequenza del pacchetto dall'output del flusso del servizio modem. Questo numero di sequenza aumenta per ciascun pacchetto di dati inviato.

Slot-6-0#show cable modem 2cab.a40c.5ac0 service-flow verbose | i DS HW Flow
DS HW Flow Index			: 12473
Slot-6-0#test jib4ds show flow 12473
Send Show-FLOW IPC to CDMAN flow 12473 seg 6...Wait for output

Slot-6-0#
Jib4DS Show Flow: [Bufsz 4400]: HW Flow id:12473 [0x30b9] for segment 0
Valid        : TRUE
DSID         :            3 [       0x3]
Priority     :            0
Bonding Group:           62 [      0x3e]
Channel      :        65535 [    0xffff]
DS-EH        :            3 [       0x3]
Data Prof 1  :            0 [         0]
Data Prof 2  :            0 [         0]
No Sniff Enabled.

Slot-6-0#test jib4ds show dsid 3
Send Show-DSID 3 10 IPC to CDMAN...Wait for output

Slot-6-0#

Jib4DS DSID entry for DSID 3 [Bufsz 4400]:
SCC Bit         = 0x0
Sequence Number = 8

Inviare alcuni ping al modem dalla riga di comando cBR-8 in un'altra finestra:

cbr8#ping 10.0.0.3 rep 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 4/7/27 ms
cbr8#

Controllare il delta dopo la prova:

Slot-6-0#test jib4ds show dsid 3
Send Show-DSID 3 10 IPC to CDMAN...Wait for output

Slot-6-0#

Jib4DS DSID entry for DSID 3 [Bufsz 4400]:
SCC Bit         = 0x0
Sequence Number = 108

Calcolare il delta dopo il test: il contatore è a 16 bit senza segno, quindi se il contatore si aggira, il delta deve essere calcolato con questa formula:

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

Esempio:

Initial Sequence Number = 50967

Final Sequence Number = 2391

Packets sent: 1000000




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

A causa della natura delle cadute, il problema può essere nel CIN (ad esempio, colli di bottiglia, collisioni, errori CRC) che devono essere ulteriormente esaminati nella rete CIN tra cBR-8 e RPD. Se invece si osservano cali ai punti 3 e 4, si raccomanda di rivolgersi a Cisco per ulteriori indagini sul cBR-8.

Perdita PTP o sblocco periodico

Come probabilmente saprete, PTP è essenziale per le normali operazioni RPD. Pertanto, i pacchetti PTP devono avere un'alta priorità in QoS e le perdite dei pacchetti PTP non sono un buon segno.

Sulla console RPD, è possibile visualizzare le statistiche PTP e verificare che i contatori "DELAY REQUEST" e "DELAY RESPONSE" corrispondano. Se invece viene visualizzato un grande gap, può essere un indicatore di perdite PTP nella rete:

R-PHY#show ptp clock 0 statistics
 AprState    4  :
           2@0-00:06:25.877          1@0-00:06:16.234          0@0-00:03:42.629
           4@0-00:03:23.428
ClockState  5  :
           5@0-00:07:02.932          4@0-00:06:59.145          3@0-00:06:55.657
           2@0-00:06:26.657          1@0-00:06:25.834
BstPktStrm  1  :
           0@0-00:03:21.014
SetTime     1  :
  1000000000@0-00:03:24.776
StepTime    1  :
  -560112697@0-00:05:39.401
AdjustTime  44 :
          -8@0-00:52:03.776         -5@0-00:51:02.776          4@0-00:50:01.776
          -6@0-00:49:00.776         11@0-00:47:59.776          1@0-00:45:57.776
           5@0-00:44:56.776         -7@0-00:43:55.776        -22@0-00:42:54.776
streamId  msgType           rx          rxProcessed     lost        tx
0        SYNC              47479       47473           0           0
0        DELAY REQUEST     0           0               0           47473
0        P-DELAY REQUEST   0           0               0           0
0        P-DELAY RESPONSE  0           0               0           0
0        FOLLOW UP         0           0               0           0
0        DELAY RESPONSE    47473       47473           0           0
0        P-DELAY FOLLOWUP  0           0               0           0
0        ANNOUNCE          2974        2974            0           0
0        SIGNALING         34          34              0           32
0        MANAGEMENT        0           0               0           0
  TOTAL                    97960       97954           0           47505

Nota: su cBR-8, PTP ha la priorità più alta per l'orologio, il che significa che una volta configurato, viene utilizzato anche per le schede di linea RF. Pertanto, un'origine non affidabile causerebbe problemi a tutto lo chassis.

Per ulteriori informazioni sulla configurazione dell'orologio PTP e sulla risoluzione dei problemi, consultare l'articolo Suggerimenti per la progettazione di PTP per reti R-PHY.

CIN congestionato

Il CIN può essere visto come un'estensione del control plane del core CCAP, quindi se ci sono 1000 Mbps di DOCSIS e traffico video a valle per un determinato RPD, quella capacità deve essere allocata nel CIN, più una capacità aggiuntiva per il sovraccarico L2TPv3 utilizzato dai tunnel DEPI.

In caso di congestione nel CIN, alcuni pacchetti possono essere ritardati o persi.

Causa potenziale 1. QoS

Per impostazione predefinita, i pacchetti cBR-8 e RPD contrassegnano i pacchetti associati al traffico PTP e i messaggi MAP con DSCP 46 (EF).  Anche altri messaggi di controllo DOCSIS, come i descrittori di canale upstream (UCD), la richiesta della larghezza di banda del modem e la risposta dell'intervallo, utilizzano DSCP 46:

Articolo	Comportamento per hop (PHB)	Valore DSCP
DATI DOCSIS (L2TP)	Best-effort	0
PTP	EF	46
GCP	Best-effort	0
MAP/UCD (L2TP, controllo DOCSIS)	EF	46
BWR e RNG-REG	EF	46
Video	CS4	32
MDD (L2TP, controllo DOCSIS), voce	CS5	40

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

Il CIN deve riconoscere QoS in modo che questi pacchetti ad alta priorità subiscano un ritardo minimo.

La congestione che crea pacchetti scartati o lunghi ritardi della coda ha creato problemi PTP, messaggi MAP in ritardo e velocità di trasmissione ridotta. Questi tipi di problemi possono essere rilevati tramite l'osservazione delle code di interfaccia sui dispositivi cBR-8, RPD e CIN.

Se i messaggi PTP o MAP vengono scartati o ritardati, come risulta evidente dai messaggi di instabilità dell'orologio o MAP in ritardo, la capacità CIN o la progettazione QoS devono essere risolte, poiché questi vengono inviati con alta priorità.

DLM non è progettato per gestire brevi durate di jitter perché il ciclo di polling minimo è di un secondo, quindi in questo caso non è in grado di eliminare i messaggi MAP in ritardo.

Causa potenziale 2. Traffico massimo sforzo ritardato

Al momento, i contrassegni dei pacchetti DLM non sono configurabili e richiedono il massimo impegno (DSCP 0). Ci sono stati casi in cui il CIN sperimenta congestione che porta a un lungo ritardo della coda limitato al traffico di massimo sforzo.

Questa configurazione si è dimostrata in genere caratterizzata da una riduzione delle velocità del traffico TCP in downstream, poiché i ritardi CIN possono creare cali di velocità relativamente grandi dovuti alla mancata o ritardata corrispondenza degli ACK in upstream.

In questo caso, non vengono osservati messaggi MAP o problemi PTP in ritardo, in quanto questi pacchetti ad alta priorità non vengono ritardati.

Poiché i pacchetti DLM sono contrassegnati come traffico massimo, questo tipo di jitter CIN può causare picchi nei valori DLM. Se DLM viene utilizzato per regolare dinamicamente il ritardo della rete, questo jitter può causare un aumento non necessario del timer di anticipo MAP, che comporta un aumento dei ritardi a monte di richiesta-concessione.

In questo caso, si consiglia di utilizzare un valore di ritardo di rete statico. Cisco esamina anche le opzioni per abilitare i valori DSCP oltre il massimo impegno su DLM nelle versioni future. Ciò può aiutare a ridurre il ritardo di concessione delle richieste a monte, ma probabilmente non risolve i problemi di velocità effettiva TCP se gli ACK vengono ritardati attraverso il CIN.

Informazioni correlate

• Misurazione latenza DEPI
• Suggerimenti per la progettazione di PTP per reti R-PHY
• Documentazione e supporto tecnico – Cisco Systems