Sommario

Introduzione

Operazioni preliminari

Convenzioni

Prerequisiti

Componenti usati

Shaping e accodamento

Cisco serie 7200, 3600, 2600

Cisco serie 7500

Scelta della posizione in cui applicare un criterio di servizio

Problemi noti

Note sulla configurazione

Informazioni correlate

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 7500

Cisco 7200, 3600, 2600 e altre piattaforme non VIP

Meccanismi di modellazione supportati

DTS (Distributed Traffic Shaping)

Frame Relay Traffic Shaping (Frame Relay TS)

Comando di configurazione

comando shape in una mappa dei criteri

traffic shaping frame-relay su un'interfaccia principale, comandi di configurazione map-class per specificare i parametri di shaping

Richiede Distributed Cisco Express Forwarding (dCEF)

Sì (verificare con il comando show cef linecard)

No

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.

Configurazione di esempio di CBWFQ su Cisco serie 7200, 3600, 2600

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.

Configurazione di esempio di DTS con un criterio gerarchico

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.

Cisco serie 7500

Cisco serie 7200, 2600/3600 e altre piattaforme

Interfaccia principale

Configurare un criterio dei servizi sull'interfaccia principale

Supportato solo se il Servizi terminal Frame Relay non è abilitato e i meccanismi di coda si applicano a una singola pipe di interfaccia.

Sottointerfaccia

Configurare un servicepolicy sull'interfaccia secondaria.

Configurare un criterio del servizio all'interno di una classe mappa Frame Relay e abilitare le code per VC con il comando frame-relay traffic-shaping. È possibile applicare la classe map alla sottointerfaccia.

Livello VC

Configurare una policy di servizio in una classe mappa Frame Relay e abilitare le code per VC con il comando frame-relay traffic-shaping. È possibile applicare la classe map al VC.

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