Esempio di configurazione dell'offload QoS di ASR 9000

Introduzione

Questo documento descrive come configurare la funzione QoS (Quality of Service) Offload sulla piattaforma Cisco serie 9000 Aggregated Services Router (ASR9K). Vengono inoltre descritti lo scopo, l'applicazione e i limiti della funzionalità.

Requisiti

Prima di provare la configurazione, verificare che il sistema soddisfi i seguenti requisiti:

• È necessario installare e attivare una o entrambe le seguenti Buste di installazione pacchetti satellite (PIE) per lo specifico hardware satellitare:
  
  
  • asr9k-asr9000v-nV-px.pie-5.1.1
    
    
  • asr9k-asr901-nV-px.pie-5.1.2
    
    
• Il satellite deve disporre di software aggiornato e di dispositivi programmabili sul campo (FPD).

Componenti usati

Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:

• Cisco IOS^® XR versione 5.1.1 su ASR9K per ASR-9000v.
  
  
• Cisco IOS XR versione 5.1.2 su ASR9K per ASR-901.

Nota: al momento la funzione QoS Offload sull'ASR-903 non è ufficialmente supportata.

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

Panoramica dell'offload QoS

Il collegamento tra lo chassis (ICL) tra il satellite e l'ASR9K (generalmente 10 Gbps) può essere facilmente saturato dalle interfacce di accesso sul satellite stesso. La funzione QoS Offload fornisce funzionalità QoS nell'hardware del satellite in uso (in contrapposizione all'host ASR9K) al fine di prevenire la perdita di dati critici sull'ICL in tempi di congestione.

La funzione QoS Offload è stata introdotta per proteggere il traffico sull'ICL dalla congestione in direzione dalla porta di accesso satellitare all'ASR9K, come indicato dalle frecce rosse tratteggiate nell'immagine successiva. Questo concetto aiuta a comprendere alcuni dei limiti e aiuta quando si progetta l'implementazione QoS.

Processi critici per l'offload QoS

In questa sezione vengono descritti i due processi critici utilizzati per l'offload QoS.

Processo Interface Control Plane Extender (icpe_cpm)

Il processo Interface Control Plane Extender (ICPE) gestisce il protocollo SDAC (Satellite Discovery and Control), che fornisce il canale di comunicazione tra l'host ASR9K e il satellite.

Processo QoS Policy-Manager (qos_ma)

Il processo di gestione dei criteri QoS esegue le azioni seguenti:

• Verifica e archivia le mappe classi e le mappe criteri in un database su Route Switch Processor (RSP).
  
  
• Gestisce un database dell'interfaccia satellite per i mapping dei criteri del servizio.
  
  
• Raccoglie periodicamente le statistiche QoS dalle caselle satellitari per le policy dei servizi scaricate.
  
  
• Viene eseguito su tutti i nodi in cui esistono interfacce del piano di controllo, per includere sia RSP che schede di linea (LC).

Configurazione

Utilizzare questa sezione per configurare la funzione QoS Offload su ASR9K.

Configurazione QoS Offload

Questo diagramma serve come rappresentazione visiva del percorso in cui è installato il criterio del servizio:

Satellite Access Interface

Di seguito è riportato un esempio di configurazione sull'interfaccia di accesso via satellite:

interface GigabitEthernet200/0/0/1
 service-policy output NQoSOff_Out  
 service-policy input NQoSOff_In 
 nv
  service-policy input ACCESS 

Nota: l'output NQoSOff_Out dei criteri di servizio indica il traffico di offload non QoS trasmesso dall'interfaccia ICL di ASR9K all'interfaccia di accesso satellitare (1), mentre l'input NQoSOff_In indica il traffico non QoS ricevuto sull'ASR9K dall'interfaccia di accesso satellitare (1). Inoltre, l'input ACCESS di service-policy indica il traffico QoS offload ricevuto sull'interfaccia di accesso satellitare dal PC (2).

Interfaccia ICL

Di seguito è riportato un esempio di configurazione sull'interfaccia ICL:

interface TenGigE0/0/0/1
service-policy output NOT_SUPPORTED
service-policy input NOT_SUPPORTED 
nv
  satellite-fabric-link network
   redundancy
    iccp-group 1
   !
   satellite 200
    service-policy output ICL_OFFLOAD
    remote-ports GigabitEthernet 0/0/1-2

Nota: l'output e l'input dei criteri di servizio NON è_SUPPORTED per questa interfaccia. Fare riferimento alla sezione successiva e progettare con attenzione. Inoltre, l'output ICL_OFFLOAD del criterio del servizio indica il traffico di offload QoS inviato dall'ICL del satellite all'ASR9K (3).

Sovrascrittura ICL

I criteri del servizio QoS non sono supportati direttamente sulle interfacce ICL (offload non QoS). Pertanto, è necessario fare attenzione a non sovrascrivere le interfacce ICL satellitari. In questa sezione vengono illustrati due metodi per impedire l'oversubscription di ICL. Il primo metodo limita il numero di interfacce di accesso per ciascun ICL in modo da impedire la congestione. Il secondo metodo applica gli shaper a ciascuna interfaccia di accesso in modo che la somma di tutti gli shaper non superi la larghezza di banda dell'ICL.

Limita le interfacce di accesso per ciascun ICL

Per supportare quindici connessioni a 1 Gbps su un satellite (per un potenziale di traffico a 15 Gbps) senza perdite di pacchetti durante la congestione, è necessario configurare due collegamenti ICL a 10 Gbps distinti. Mappare le prime dieci interfacce di accesso satellitare da 1 Gbps a una connessione ICL da 10 Gbps e le successive cinque interfacce di accesso satellitare da 1 Gbps alla seconda connessione ICL da 10 Gbps. Altre combinazioni sono possibili finché il numero di interfacce di accesso mappate a ciascun ICL da 10 Gbps non supera dieci.

Di seguito è riportato un esempio di configurazione:

interface TenGigE0/0/0/1
description ICL_LINK_1_FOR_SAT100
nv
 satellite-fabric-link network
  satellite 100
  remote-ports GigabitEthernet 0/0/0-9
!
interface TenGigE0/0/0/2
description ICL_LINK_2_FOR_SAT100
nv
 satellite-fabric-link network
  satellite 100
  remote-ports GigabitEthernet 0/0/10-14

Applicazione di shaper sulle interfacce di accesso

Il secondo metodo usato per prevenire l'oversubscription è quello di applicare uno shaper direttamente a ciascuna interfaccia di accesso via satellite (ad esempio, GigE100/0/0/9) in modo da impedire la trasmissione di più velocità di linea attraverso l'ICL al satellite. Ad esempio, con un singolo ICL da 10 Gbps, se uno shaper da 500 Mbps viene applicato a venti interfacce satellitari Gigabit Ethernet, non sarà mai programmato un attraversamento dell'ICL di oltre 10 Gbps (500 Mb x 20).

Di seguito è riportato un esempio di configurazione:

interface TenGigE0/0/0/1
 nv
  satellite-fabric-link network
   satellite 100
   remote-ports GigabitEthernet 0/0/0-19
!
interface GigE100/0/0/0 (For all Gi100/0/0/0-19)
 service-policy output 500MBPS_SHAPE

Nota: la funzionalità MQC (Full Modular QoS CLI) viene fornita per offload non QoS su interfacce di accesso satellitare che sono entità virtuali sull'host ASR9K.

Protezione del traffico Control-Plane su ICL

In questa sezione viene illustrato un esempio di configurazione che protegge il traffico control plane della rete ricevuto su un'interfaccia di accesso satellitare mentre attraversa l'ICL. Ecco come è possibile ottenere questo risultato:

Satellite Access Interface Config:
class-map match-any routing
 match precedence 6

policy-map Protect_NCP
 class routing
  set qos-group 4
 !
 class class-default
  set qos-group 0

interface Gi100/0/0/1
 description Satellite Access Interface
 service-policy input Protect_NCP
 
ICL Interface Config:
class-map match-any qos-group-4
 match qos-group 4

policy-map ICL-Policy
 class qos-group-4
  bandwidth remaining percent 5
 !
 class class-default
  bandwidth remaining percent 90

interface TenGigE0/0/0/1
description Satellite ICL
nv
  satellite-fabric-link network
   redundancy
    iccp-group 1
   !
   satellite 100
    service-policy output ICL-Policy

Nell'esempio di configurazione precedente, la mappa dei criteri 'Protect_NCP' abbinerà tutti i pacchetti con IP Precedence pari a 6 e li raggrupperà nel gruppo QoS interno 4. Quindi, una volta che l'ICL inizia a funzionare verso l'host ASR9K, sarà protetto tramite la prenotazione configurata della larghezza di banda nella class-map per il gruppo QoS 4.

Promemoria: un gruppo QoS non è un contrassegno effettivo sul ToS-byte del pacchetto, bensì un contrassegno interno che ha solo un significato locale per il satellite e l'host ASR9K.

IMPORTANTE! Quando si utilizza QoS Offload, è possibile definire solo i gruppi QoS 1, 2, 4 e 5. I gruppi QoS 3, 6 e 7 sono riservati alle funzionalità sottostanti, specifiche del satellite nV e non devono mai essere utilizzati. Il gruppo QoS 0 è riservato al traffico predefinito della classe.

Limitazioni dell'offload QoS

 In questa sezione vengono descritti i limiti della funzione QoS Offload.

Restrizioni di posizionamento dei criteri dei servizi

L'offload QoS viene implementato per offrire funzionalità QoS dalla direzione della porta di accesso satellitare verso l'host ASR9K. Si applicano le seguenti restrizioni di posizionamento:

• Impossibile inserire una regola del servizio QoS direttamente su un'interfaccia ICL ASR9K per offload o non offload.
  
  
• Le policy dei servizi in uscita (output) sono supportate solo per l'offload QoS sulle interfacce ICL satellitari con interfaccia host attiva.
  
  
• Le policy dei servizi in entrata (input) sono supportate solo per l'offload QoS sulle interfacce o sui bundle delle porte di accesso via satellite per il traffico ricevuto direttamente sull'interfaccia o sul bundle di accesso via satellite. Nel caso di un bundle, il criterio QoS viene installato su ciascun membro per ogni collegamento.
  
  
• Impossibile applicare criteri del servizio scaricati a una sottointerfaccia.

Funzionalità QoS Offload supportate

Le funzionalità di offload QoS supportate sono documentate nella sezione Support Platform-Specific Information for QoS Offload della guida alla configurazione della qualità del servizio modulare del router Cisco ASR serie 9000 Aggregation Services Router, versione 5.1.x.

Nota: al momento non è supportato il protocollo SNMP (Simple Network Management Protocol) per le statistiche di offload QoS.

Limitazioni dell'offload non QoS sulle interfacce di accesso satellitare

In questa sezione vengono descritti i limiti dell'offload non QoS sulle interfacce di accesso satellitare.

Restrizioni di posizionamento dei criteri dei servizi

Le seguenti restrizioni relative alla posizione dei criteri dei servizi si applicano all'offload non QoS sulle interfacce di accesso satellitare:

• Le policy sui servizi in entrata e in uscita possono essere applicate con la configurazione effettiva delle porte di accesso (non con la NV). Questi criteri non vengono scaricati e i pacchetti vengono accodati prima di essere messi in rete da ASR9K al satellite.
  
  
• Impossibile posizionare un criterio di servizio QoS direttamente su un'interfaccia ICL ASR9K per offload o non offload.

Limitazioni della topologia dei criteri di servizio

Per le topologie hub e spoke, sono supportati criteri QoS a tre livelli (padre, padre e figlio). Per le nuove topologie Ring e Layer 2 (L2) Fabric, sono supportate solo le policy QoS a doppio livello.

Verifica

Per verificare che la configurazione di offload QoS funzioni correttamente, consultare questa sezione.

Lo strumento Output Interpreter (solo utenti registrati) supporta alcuni comandi show. Usare lo strumento Output Interpreter per visualizzare un'analisi dell'output del comando show.

 

Installazione criterio offload QoS su satellite

Immettere il comando show qos status interface con l'opzione nv satellite per determinare se è stato installato correttamente nell'hardware satellite per i criteri QoS scaricati. Se lo stato nell'output del comando è Attivo, l'installazione del criterio QoS scaricato ha esito positivo. Se lo stato nell'output è Inattivo, si è verificato un errore di qualche tipo.

In caso di guasto, spesso si verifica un problema con il collegamento ICL effettivo oppure il criterio QoS che tenta di eseguire l'offload è supportato nella versione corrente del software IOS XR in esecuzione sull'host ASR9K, ma potrebbe non essere supportato sul satellite in uso. Per ulteriori informazioni, fare riferimento alla sezione Funzionalità di offload QoS supportate di questo documento.

Se lo stato nell'output del comando mostra uno stato In corso, indica che la connessione satellite è stata persa. In questo stato intermedio tra attivo e inattivo, il criterio QoS non è stato scaricato correttamente.

Di seguito sono riportati due output di esempio che mostrano un offload riuscito e un offload non riuscito:

OUTPUT:
RP/0/RSP0/CPU0:ASR9001#show qos status interface gig 0/0/0/0 nv satellite 100
Wed Apr 16 23:50:46.575 UTC
GigabitEthernet0/0/0/0 direction input: Service Policy not installed
GigabitEthernet0/0/0/0  Satellite: 100 output: test-1
     Last Operation Attempted :  ADD
     Status                   :  ACTIVE

OUTPUT:
RP/0/RSP0/CPU0:ASR9001#show qos status interface gig 0/0/0/0 nv satellite 100
Wed Apr 16 23:51:34.272 UTC
GigabitEthernet0/0/0/0 direction input: Service Policy not installed
GigabitEthernet0/0/0/0  Satellite: 100 output: test-2
     Last Operation Attempted :  ADD
     Status                   :  INACTIVE
     Failure description   :Apply Servicepolicy: Handle Add Request  AddSP
      test-2 CliParserWrapper:
Remove shape action under class-default first.

Statistiche QoS dei criteri QoS scaricati sull'interfaccia di accesso satellitare

Immettere questi comandi per visualizzare o cancellare le statistiche di una mappa dei criteri QoS applicata all'interfaccia di accesso remoto via satellite:

• show policy-map interface Gi100/0/0/9 input nv
  
  
• clear qos counters interface Gi100/0/0/9 input nv

Statistiche QoS dei criteri QoS scaricati sull'interfaccia ICL satellitare

Immettere questi comandi per visualizzare o cancellare le statistiche di una mappa dei criteri QoS applicata sull'interfaccia ICL del satellite remoto:

• show policy-map interface Ten0/0/0/1 output nv satellite-fabric-link 100
  
  
• clear qos counters interface Ten0/0/0/1 input nv satellite-fabric-link 100

Nota: le statistiche QoS vengono aggiornate ogni trenta secondi sull'host ASR9K.

Risoluzione dei problemi

Immettere questi comandi per raccogliere le informazioni di debug quando si tenta di risolvere i problemi relativi alla funzionalità QoS Offload o quando si apre una richiesta di servizio TAC (Cisco Technical Assistance Center):

• show policymgr process trace [all|intermittent|critical]
  
  
• show tech qos
  
  
• show policy-lib trace [all|critical|intermittent]
  
  
• show policy-lib trace client <nome-client> percorso <loc>
  
  
• mostra traccia app-obj
  
  
• show app-obj db <nome_db> jid <jid> percorso <loc>
  
  
• mostra traccia qos-ma

Nota: <db_name> è class_map_qos_db o policy_map_qos_db.

Difetti noti

Per informazioni sui difetti noti relativi alle informazioni fornite in questo documento, rimuovere l'ID bug Cisco CSCuj87492 - opzione service-policy nell'interfaccia non statica nv. Questo problema è stato generato per rimuovere l'opzione nv dalle interfacce non satellitari.