Configurazione di CBWFQ sui PVC Frame Relay

Introduzione

In questo documento vengono fornite configurazioni di esempio per la configurazione di CBWFQ (Weighted Fair Queueing) basato su classi su un'interfaccia Frame Relay. CBWFQ è abilitato con il comando bandwidth, come configurato in una mappa delle policy con i comandi dell'interfaccia modulare della riga di comando Quality of Service (QoS CLI).

Operazioni preliminari

Convenzioni

Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Prerequisiti

Non sono previsti prerequisiti specifici per questo documento.

Componenti usati

A seconda della piattaforma in uso, CBWFQ è supportato sulle seguenti versioni del software Cisco IOS®:

• Cisco serie 7500 con Versatile Interface Processor (VIP) (Distributed CBWFQ) - 12.1(5)T

• Cisco serie 7200, serie 2600/3600 e altre piattaforme non serie 7500 - 12.1(2)T

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.

Shaping e accodamento

L'accodamento viene generalmente utilizzato nel contesto della modellazione, che riduce la velocità di output e quindi induce la congestione. Utilizzare CBWFQ con i seguenti meccanismi e comandi di shaping, a seconda della piattaforma in uso.

Cisco serie 7200, 3600, 2600

Cisco IOS 12.1(2)T introduce il supporto per CBWFQ sugli switch 7200, 2600/3600 e altre piattaforme non-Route Switch Processor (RSP). Per ulteriori informazioni, fare riferimento a LLQ (Low Latency Queueing) su Frame Relay. Su queste piattaforme, il CBWFQ sulle interfacce Frame Relay è sempre nel contesto di Frame Relay TS. Utilizzare il comando frame-relay traffic-shaping per abilitare Servizi terminal Frame Relay. Non è possibile utilizzare CBWFQ con GTS (Generic Traffic Shaping) e il comando shape su queste piattaforme. Di seguito viene fornita una configurazione di esempio.

 policy-map mypolicy 
  class voice 
   priority 16 
  class priority-data 
   bandwidth 16 

!--- Create a policy-map and apply the bandwidth !--- command to a class. 

! 
 int s0/0 
  encapsulation frame-relay IETF 
  load-interval 30 
  frame-relay traffic-shaping 

!--- Enable Frame Relay TS. 

! 
 interface Serial0/0.1 point-to-point 
  frame-relay interface-dlci 100 
    class frclass 

!--- Apply the map-class to the Frame Relay PVC. 

! 
 map-class frame-relay frclass 
  service-policy output mypolicy 
  frame-relay cir 64000 
  frame-relay bc 640 

!--- Apply the service policy inside the map-class.

Nota: se si abilita un criterio del servizio direttamente su un'interfaccia principale e non all'interno di un comando map-class, non sarà possibile applicare Servizi terminal Frame Relay direttamente all'interfaccia. È importante notare che i meccanismi di coda si applicano quindi a una singola coda di interfaccia di grandi dimensioni anziché a code per circuito virtuale (VC)

Nel Cisco serie 7200, dal software Cisco IOS versione 12.0(26)S e successive, non è più possibile configurare una policy del servizio di output in un comando map-class frame-relay. Al contrario, la configurazione di Cisco 7500 deve essere applicata come spiegato nella sezione seguente. È necessario configurare una mappa dei criteri gerarchica con la modellazione in un criterio padre e l'accodamento in un criterio figlio. Il criterio padre deve quindi essere associato all'interfaccia principale o secondaria. Se si tenta di configurare l'output di un criterio del servizio nel comando map-class frame-relay, verrà visualizzato il seguente messaggio di errore:

c7200(config)#map-class frame-relay
	 stef
c7200(config-map-class)#frame-relay cir
	 64000
c7200(config-map-class)#service-policy output
	 aan
Frame relay output service policy is not
	 supported

Cisco serie 7500

A partire dalla versione Cisco IOS 12.1(5)T, i criteri QoS devono essere eseguiti in modalità distribuita sull'indirizzo VIP; perché QoS basato su RSP non è più supportato. Pertanto, è necessario utilizzare il comando shape e altri comandi della CLI QoS modulare per implementare DTS per le interfacce Frame Relay sui VIP su Cisco serie 7500. DTS combina GTS e Frame Relay TS. Un esempio di configurazione è fornito in Configurazione di Distributed Traffic Shaping e versioni successive.

ip cef distributed 
 !  
 class-map 1  
   match < >  

!--- Define match-on criteria.

 class-map 2  
   match < >

!--- Define match-on criteria.

 !  
 policy-map CBWFQ  
   class 1  
     bandwidth < >  
     !-- Define value in kbps or percent.  
   class 2  
     priority < > 
 
!--- Define value in kbps or percent.

 !  
 Policy-map SHAPE  
    class class-default  
     shape average    
     service-policy CBWFQ  
 !  
 int s0/0/0  
   encapsulation frame-relay  
   ip route-cache distributed  
 !  
 int s0/0/0.1 point-to-point  
   ip address a.b.c.d  
   frame-relay interface-dlci xxx  
    class cisco  
 !  
 map-class frame-relay cisco  
   service-policy output SHAPE

Scelta della posizione in cui applicare un criterio di servizio

Quando si configura CBWFQ, è possibile utilizzare i comandi della CLI QoS modulare per creare una mappa dei criteri del traffico con più classi di traffico e una o più funzionalità QoS. Nelle versioni correnti del software Cisco IOS, le interfacce Frame Relay supportano l'applicazione di una mappa dei criteri con il comando service-policy a interfacce, sottointerfacce e VC. Ora sono supportate solo le combinazioni di criteri corrette. Nella tabella seguente viene descritto in modo specifico dove è possibile applicare un criterio QoS con il traffic shaping.

Problemi noti

Quando si configura CBWFQ su interfacce Frame Relay, tenere presente le seguenti avvertenze:

• Dopo il ricaricamento di un router, i contatori di corrispondenza pacchetti di un criterio del servizio non possono aumentare quando il criterio viene applicato all'interfaccia principale. Per risolvere il problema, verificare che i flag di classificazione WFQ (Weighted Fair Queueing) vengano copiati dall'interfaccia principale alle sottointerfacce.

• La configurazione simultanea di LLQ e Frame Relay TS a livello di interfaccia fisica non è supportata. Il router rimuove i criteri del servizio dalla configurazione in esecuzione dopo un ricaricamento del router. Il criterio del servizio deve essere associato alla classe mappa quando il servizio Servizi terminal Frame Relay è abilitato sull'interfaccia. Il tentativo di configurare questa combinazione genera il messaggio di errore CBWFQ: Non supportato su questa interfaccia.

• Quando un criterio del servizio con CBWFQ viene applicato direttamente a un'interfaccia principale Frame Relay (ad esempio, le code non per VC), il criterio può essere rimosso dopo un ricaricamento del router se le istruzioni della larghezza di banda sono configurate su una sottointerfaccia e un'interfaccia principale. Il router può segnalare messaggi di registro simili ai seguenti:

  CBWFQ: Not enough available bandwidth for all classes Available 44 (kbps) 
      Needed 1 00 (kbps)
      CBWFQ: Removing service policy on Serial1/0

  Questo problema viene risolto modificando il comportamento di CBWFQ per ignorare le notifiche quando viene modificata la larghezza di banda della sottointerfaccia, poiché CBWFQ può essere configurato all'esterno di una classe mappa Frame Relay solo al livello dell'interfaccia principale. Per risolvere il problema, rimuovere il comando bandwidth dall'interfaccia secondaria. Se si utilizza la larghezza di banda sulla sottointerfaccia per influenzare la metrica di routing, utilizzare un metodo alternativo, ad esempio cost, come in Open Shortest Path First (OSPF) o delay, come in Enhanced Interior Gateway Routing Protocol (EIGRP).

Note sulla configurazione

• Quando i comandi bandwidth e priority calcolano la quantità totale di larghezza di banda disponibile in un'entità, quando l'entità è un PVC (Permanent Virtual Circuit) Frame Relay con forma vengono richiamate le linee guida seguenti:

  • Se non è configurata una velocità minima di commit delle informazioni accettabile (minCIR), il CIR viene diviso per due.

  • Se è stato configurato un valore minCIR, nel calcolo viene utilizzata l'impostazione minCIR.

  • L'intera larghezza di banda dalla velocità di cui sopra può essere assegnata alle classi di larghezza di banda e priorità. Di conseguenza, il comando max-reserve-bandwidth non è supportato sui PVC Frame Relay, anche se è necessario assicurarsi che la quantità di larghezza di banda configurata sia sufficiente per supportare anche il sovraccarico di layer 2 (L2). Per ulteriori informazioni, consultare il documento sui byte conteggiati da IP in coda CoS ATM?.

• Evitare di impostare CIR o minCIR sulla velocità di accesso. In caso contrario, è possibile che le code di output si accumulino e causino grandi ritardi nelle classi CBWFQ. Il motivo è che la velocità della forma non tiene conto dei byte di sovraccarico dei campi flag e CRC (Cyclic Redundancy Check), quindi la definizione della forma alla velocità della linea comporta in realtà una sottoscrizione eccessiva e causerà una congestione dell'interfaccia. Non c'è motivo di modellare la velocità di accesso. Il traffico deve sempre avere una velocità pari al 95% della velocità di accesso o, più in generale, la velocità di aggregazione deve essere sempre inferiore del 95% alla velocità di accesso.

• Quando FRF.12 è configurato, le dimensioni della coda di output aumentano per contenere lo stesso numero di byte che ora sono frammentati. In altre parole, si passa da una coda di pacchetti a una coda di frammenti.

• WFQ per VC è incluso nel software Cisco IOS versione 12.0(7)T.

• CBWFQ con GTS è incluso nel software Cisco IOS versione 12.1(2)T.

Informazioni correlate

• Pagina di supporto QoS
• Supporto tecnico – Cisco Systems