Esempio di configurazione QoS di uno switch Nexus serie 7000

Introduzione

Questo documento offre un esempio di configurazione delle funzionalità QoS (Quality of Service) sugli switch Cisco Nexus serie 7000 per semplificare le procedure di classificazione e coda.

Prerequisiti

Requisiti

Prima di provare questa configurazione, accertarsi di soddisfare i seguenti requisiti:

• Conoscenze base della configurazione degli switch Nexus serie 7000

• Conoscenze base di QoS

Componenti usati

Per la stesura del documento, è stato usato uno switch Nexus serie 7000.

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.

Convenzioni

Fare riferimento a Cisco Technical Tips Conventions per ulteriori informazioni sulle convenzioni dei documenti.

Panoramica

I parametri QoS predefiniti sullo switch Nexus 7000 sono sufficienti per la maggior parte delle implementazioni. È tuttavia necessario comprendere le limitazioni e i dettagli di configurazione necessari per creare criteri personalizzati.

Per QoS sulle schede di linea Nexus serie 7000 M è necessario considerare due aspetti:

• criteri di accodamento

• Criteri QoS

L'accodamento viene eseguito nell'hardware ed è configurato con l'utilizzo dei criteri di accodamento Modular QoS CLI (MQC). I criteri QoS, utilizzati per contrassegnare o controllare il traffico, vengono usati tramite un criterio MQC nello stesso formato dei criteri QoS standard su altre piattaforme Cisco. Ad esempio, un elenco degli accessi utilizzato per classificare il traffico in una mappa di classe con una mappa di criteri corrispondente per impostare/controllare il traffico.

Al momento, i moduli della serie M eseguono le code basandosi esclusivamente sul valore CoS (Class of Service). È quindi necessario innanzitutto comprendere come viene derivato il valore CoS. Dopo aver identificato il valore CoS che entra/esce dallo switch, è possibile esaminare la configurazione di accodamento per ottenere la QoS desiderata per i diversi tipi di traffico.

Comportamento Class of Service

Per il traffico unicast indirizzato, il valore CoS viene derivato dai 3 bit più significativi del valore DSCP (Differentiated Services Code Point). Per il traffico unicast con bridging, il valore CoS viene copiato dal valore CoS ricevuto nell'intestazione 802.1q. Si noti che nei collegamenti di accesso L2 non è presente alcuna intestazione trunk. Pertanto, se il traffico viene ricevuto su una porta di accesso e sottoposto a bridging, esce dallo switch con CoS 0. Il valore DSCP non viene modificato, ma il pacchetto potrebbe non ottenere la priorità desiderata. È possibile impostare manualmente il valore CoS in una mappa dei criteri tramite qualsiasi criterio QoS che imposti manualmente il valore CoS o DSCP.

È importante capire il comportamento del multicast. Il traffico multicast indirizzato deriva il proprio valore CoS nello stesso modo del traffico unicast indirizzato. Per il traffico multicast con bridging, il comportamento dipende dallo stato L3. Se non è presente uno stato L3 per il gruppo multicast, il CoS viene derivato nello stesso modo del traffico unicast con bridging. Se è presente uno stato L3 per il gruppo multicast, il CoS viene derivato nello stesso modo del traffico unicast indirizzato. Notare che quando si abilita il protocollo PIM (Protocol Independent Multicast) in modalità sparse sull'interfaccia virtuale dello switch (SVI) per la VLAN in cui viene ricevuto il traffico, viene creata una voce S,G quando si rileva il multicast.

In sintesi, il comportamento del servizio CoS per un tipo di traffico è mostrato di seguito:

Tipo di traffico	Comportamento CoS
unicast indirizzato	copiato da 3 MSB di ToS
unicast con bridging	invariato
multicast indirizzato	copiato da 3 MSB di ToS
bridge multicast con stato L3 per gruppo	copiato da 3 MSB di ToS
bridge multicast senza stato L3 per il gruppo	invariato

Modifica del comportamento CSS sui collegamenti di accesso

Si supponga, ad esempio, di ricevere il traffico sulla porta di accesso (Eth8/1) e di crearne un bridge sulla VLAN. Per impostazione predefinita, il valore CoS del traffico unicast con bridging non viene modificato. Se il traffico arriva su una porta di accesso, viene assegnato il valore CoS predefinito 0. Nell'esempio, il traffico con priorità (DSCP 46) viene ricevuto su una porta di accesso ed esce dallo switch con il valore DSCP invariato e il valore CoS di 0. Il pacchetto non ha quindi la priorità corretta.

Nota: L'intestazione CoS viene visualizzata solo per maggiore chiarezza. E8/1 è una porta di accesso, quindi il valore CoS è 0. Il flusso del pacchetto va da sinistra a destra.

Per ovviare al problema, è possibile creare una policy QoS per impostare manualmente il valore CoS sulla porta in entrata.

Nell'esempio, solo i pacchetti con DSCP 46 hanno i valori CoS aggiornati. Se fossero necessari più valori DSCP per garantire un valore CoS corretto, nella mappa dei criteri dovrebbero essere definite ulteriori mappe di classe e azioni.

Un'opzione alternativa consiste nell'utilizzare una mappa tabella con l'azione 'copia predefinita'. La mappa-tabella consente di reimpostare il DSCP in base al valore DSCP corrente. Ad esempio, se il traffico è stato ricevuto con un valore DSCP di 40 e occorre verificare che sia stato contrassegnato con un valore DSCP di 46, è possibile utilizzare una mappa tabella con l'azione 'da 40 a 46'.

Una mappa tabella contiene anche un'azione 'copia predefinita' che imposta il valore DSCP sul valore originale. Questa procedura è simile alla creazione di una mappa dei criteri con la classificazione 'match dscp ef' e l'azione 'set dscp ef'.  Logicamente, il valore DSCP rimane invariato, ma l'azione 'set dscp' imposta implicitamente il valore CoS sul valore 3-MSB del nuovo valore DSCP.

Pertanto, se è necessario assicurarsi che il valore CoS sia sempre aggiornato al valore 3-MSB del valore DSCP, utilizzare una mappa tabella con una singola azione di 'copia predefinita'.

 

Selezione e pianificazione coda di uscita

Una volta derivato il valore CoS, è possibile modificare i mapping delle classi di accodamento globali per influire sui mapping tra costi e code. Queste mappe di classe sono globali e interessano tutti i moduli in tutti i contesti dei dispositivi virtuali (VDC) per quel particolare tipo di coda. Ad esempio, prendere in considerazione le seguenti mappe di classi di accodamento predefinite per i moduli M108 e M132 (1p7q4t):

class-map type queuing match-any 1p7q4t-out-pq1
  Description: Classifier for egress priority queue of type 1p7q4t
  match cos 5-7

class-map type queuing match-any 1p7q4t-out-q2
  Description: Classifier for egress queue 2 of type 1p7q4t

class-map type queuing match-any 1p7q4t-out-q3
  Description: Classifier for egress queue 3 of type 1p7q4t

class-map type queuing match-any 1p7q4t-out-q4
  Description: Classifier for egress queue 4 of type 1p7q4t

class-map type queuing match-any 1p7q4t-out-q5
  Description: Classifier for egress queue 5 of type 1p7q4t

class-map type queuing match-any 1p7q4t-out-q6
  Description: Classifier for egress queue 6 of type 1p7q4t

class-map type queuing match-any 1p7q4t-out-q7
  Description: Classifier for egress queue 7 of type 1p7q4t

class-map type queuing match-any 1p7q4t-out-q-default
  Description: Classifier for egress default queue of type 1p7q4t
  match cos 0-4

Per impostazione predefinita, cos 0-4 viene mappato alla coda predefinita e cos 5-7 alla coda di priorità. Questi elementi vanno di pari passo con i criteri di accodamento predefiniti per lo stesso tipo di accodamento:

policy-map type queuing default-out-policy 
  class type queuing out-pq1
    priority level 1
    queue-limit percent 16
  class type queuing out-q2
    queue-limit percent 1
  class type queuing out-q3
    queue-limit percent 1
  class type queuing out-q-default
    queue-limit percent 82
    bandwidth remaining percent 25

La coda di priorità è 'priority' con un limite di coda del 16%. La coda predefinita ha un limite di coda dell'82% con un peso rimanente della larghezza di banda predefinita. Alle altre code non utilizzate viene assegnato un limite di coda dell'1%. Si noti che q4, q5 e q6 non sono rappresentati nel criterio di accodamento predefinito e, pertanto, avranno un limite di coda e un peso della larghezza di banda ancora più piccoli programmati nell'hardware.

Creare un criterio di accodamento personalizzato

Per creare un criterio di accodamento personalizzato, attenersi alla seguente procedura:

1. Creare un criterio di accodamento personalizzato con il limite di coda e l'allocazione della larghezza di banda desiderati.
2. Modificare i mapping delle classi di accodamento globali per creare il CoS necessario per il mapping delle code.
3. Applicare il nuovo criterio di accodamento alle interfacce appropriate.

Si prenda in considerazione un esempio per i moduli M132 con un'architettura di coda 1p7q4t in cui tutti gli 8 valori CoS vengono mappati a una coda separata. L'output mostra il criterio di accodamento personalizzato insieme alle modifiche apportate alle mappe di classi di accodamento globali:

policy-map type queuing 10G_POLICY
  class type queuing 1p7q4t-out-pq1
    priority level 1
    queue-limit percent 10
  class type queuing 1p7q4t-out-q2
    queue-limit percent 10
    bandwidth remaining percent 10
  class type queuing 1p7q4t-out-q3
    queue-limit percent 5
    bandwidth remaining percent 5
  class type queuing 1p7q4t-out-q4
    queue-limit percent 5
    bandwidth remaining percent 5
  class type queuing 1p7q4t-out-q5
    queue-limit percent 10
    bandwidth remaining percent 20
  class type queuing 1p7q4t-out-q6
    queue-limit percent 5
    bandwidth remaining percent 10
  class type queuing 1p7q4t-out-q7
    queue-limit percent 5
    bandwidth remaining percent 10
  class type queuing 1p7q4t-out-q-default
    queue-limit percent 50
    bandwidth remaining percent 40

! voice
class-map type queuing match-any 1p7q4t-out-pq1
  match cos 5
! scavenger
class-map type queuing match-any 1p7q4t-out-q2
  match cos 1
! transactional
class-map type queuing match-any 1p7q4t-out-q3
  match cos 2
! call signaling
class-map type queuing match-any 1p7q4t-out-q4
  match cos 3
! video
class-map type queuing match-any 1p7q4t-out-q5
  match cos 4
! routing
class-map type queuing match-any 1p7q4t-out-q6
  match cos 6
! management
class-map type queuing match-any 1p7q4t-out-q7
  match cos 7
! best effort
class-map type queuing match-any 1p7q4t-out-q-default
  match cos 0

Il passaggio finale consiste nell'applicare il criterio di accodamento personalizzato a ciascuna interfaccia 1p7q4t:

interface Ethernet8/1
 service-policy type queuing output 10G_POLICY

Avvertenze

Il criterio di accodamento predefinito presuppone che CoS 0-4 sia mappato alla coda predefinita e CoS 5-7 alla coda di priorità. Pertanto, i limiti di coda per le code q3, q4, q5, q6 e q7 sono estremamente ridotti. È possibile immettere il comando show queuing interface per convalidare le dimensioni della coda e la larghezza di banda correnti configurate e applicate nell'hardware.

Si consideri il criterio di esempio della sezione precedente in cui ogni valore CoS è stato mappato a una coda specifica. Alla fine dell'esempio, il criterio di coda personalizzato è stato applicato a Eth8/1. Si supponga inoltre che esista un'altra interfaccia 1p7q4t (Eth6/1) a cui è stato lasciato il criterio di coda predefinito:

N7k# show queuing interface e6/1
<some output omitted>

   Configured queue-limit ratios
      queue-limit ratios:     78[1p7q4t-out-q-default] 1[1p7q4t-out-q2] 1[1p7q4t-out-q3] 
      *1[1p7q4t-out-q4] *1[1p7q4t-out-q5] *1[1p7q4t-out-q6] *1[1p7q4t-out-q7] 16[1p7q4t-out-pq1]
   * means unused queue with mandatory minimum queue-limit

   Thresholds:
     COS   Queue                      Threshold Type     Min    Max
     ______________________________________________________________
      0    1p7q4t-out-q-default           DT             100    100
      1    1p7q4t-out-q2                  DT             100    100
      2    1p7q4t-out-q3                  DT             100    100
      3    1p7q4t-out-q4                  DT             100    100
      4    1p7q4t-out-q5                  DT             100    100
      5    1p7q4t-out-pq1                 DT             100    100
      6    1p7q4t-out-q6                  DT             100    100
      7    1p7q4t-out-q7                  DT             100    100

Dall'output sopra riportato è possibile osservare che le code q2 e q3 hanno un limite di coda dell'1%, mentre q4, q5, q6 e q7 hanno *1%, che è il limite di coda minimo obbligatorio (in altre parole, significativamente inferiore all'1%). Inoltre, è possibile notare che i valori 1-4 e 6-7 di CoS utilizzano queste code molto piccole. Le dimensioni ridotte delle code determinano rapidamente l'eliminazione dell'output e possono compromettere le prestazioni della rete. Ciò risulta ulteriormente aggravato se il traffico predefinito CoS 0 viene mappato a una di queste piccole code.

In sintesi, se si crea un criterio di coda personalizzato e si modificano le mappe delle classi di coda globali, è fondamentale applicare il criterio di coda personalizzato a tutte le interfacce dello chassis che condividono lo stesso tipo di coda.

Di seguito sono elencati alcuni utili comandi di rilascio:

• show policy-map interface ex/y
• show system internal queueing stat interface ex/y

Informazioni correlate

• Cisco Nexus serie 7000 NX-OS Quality of Service Configuration Guide, versione 5.x
• Documentazione e supporto tecnico – Cisco Systems