Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Convenzioni

Applicazione dell'accodamento alle interfacce con diverse larghezze di banda

CBWFQ e LLQ sulle interfacce dialer

LLQ e CBWFQ con MLPPP distribuito

CBWFQ e LLQ con PPPoA e MLPPPoA

Informazioni correlate

Introduzione

Il comando service-policy in genere applica una mappa dei criteri configurata con i comandi della CLI QoS modulare (MQC) a un'interfaccia principale, a una sottointerfaccia o a un circuito virtuale. È inoltre possibile applicare questo comando a un'interfaccia modello virtuale, a un'interfaccia a connessione multipla e a un'interfaccia di connessione configurata con incapsulamento PPP (Point-to-Point Protocol) e MLPPP (Multilink PPP). Tali interfacce danno luogo a un'interfaccia di accesso virtuale, dove avviene funzionalmente una coda. Questo documento offre un unico riferimento per la comprensione delle configurazioni consigliate e degli avvertimenti correlati per applicare CBWFQ (Class-Based Weighted Fair Queuing) e LLQ (Low Latency Queuing) alle interfacce del bundle e alle interfacce dialer MLPPP.

Prerequisiti

Requisiti

Non sono previsti prerequisiti specifici per questo documento.

Componenti usati

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

Convenzioni

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

Applicazione dell'accodamento alle interfacce con diverse larghezze di banda

La RFC 1990 definisce il protocollo PPP a connessione multipla, che combina una o più interfacce fisiche in un'interfaccia "bundle" virtuale. La larghezza di banda dell'interfaccia del bundle è uguale alla somma della larghezza di banda dei collegamenti dei componenti. Pertanto, l'interfaccia del bundle ha un valore massimo della larghezza di banda che varia in un momento istantaneo.

In origine, i comandi bandwidth e priority supportavano solo un valore kbps assoluto. Se si applica un criterio di servizio con CBWFQ e LLQ a un'interfaccia bundle e la prima interfaccia attiva non supporta il valore kbps assoluto, il controllo dell'ammissione del criterio di servizio non è riuscito. Il router ha rimosso i criteri del servizio e ha stampato messaggi di errore simili a questo output:

May 18 17:32:34.766 MEST: CBWFQ: Not enough available bandwidth for all

classes Available 48 (kbps) Needed 96 (kbps)

May 18 17:32:34.766 MEST: CBWFQ: Removing service policy on Dialer100

A partire dal software Cisco IOS® versione 12.2T, il router tenta ora di riapplicare la policy quando rileva che un'interfaccia aggiuntiva (ad esempio un secondo canale B BRI) è stata aggiunta al bundle. Un approccio superiore consiste nel configurare i comandi priority e bandwidth come percentuale della larghezza di banda disponibile. L'uso di un valore percentuale configura il router per assegnare una quantità relativa di larghezza di banda da regolare quando il bundle contiene uno o più collegamenti membri. Il software Cisco IOS versione 12.2(2)T ha introdotto il supporto per il comando priority percent sui router Cisco serie 7500 e su altre piattaforme. Per ulteriori informazioni, fare riferimento a Accodamento a bassa latenza con supporto percentuale di priorità.

CBWFQ e LLQ sulle interfacce dialer

Il routing DDR (Dial-on-demand routing) può essere configurato in due modi:

- DDR legacy: applica i parametri dial e protocol direttamente all'interfaccia fisica.

- Profili dialer - Applica dinamicamente i parametri dial e protocol a un'interfaccia dialer, che a sua volta si collega alle interfacce fisiche. Un'interfaccia dialer, ad esempio, include una o più stringhe di composizione per raggiungere un sito remoto, il tipo di autenticazione PPP e MLPPP.

Il DDR legacy originariamente supportato per le code FIFO (First In, First Out) solo quando un'interfaccia seriale o ISDN è stata configurata con MLPPP. Questa restrizione si applicava anche quando le due estremità della connessione non negoziavano il protocollo MLPPP e usavano l'interfaccia fisica come interfaccia non-bundle che eseguiva l'incapsulamento PPP. Il tradizionale WFQ (Weighted Fair Queuing) tramite il comando fair-queue è ora supportato.

Se si sceglie di configurare i profili di connessione remota, sia l'interfaccia di connessione che le interfacce fisiche sottostanti supportano il comando service-policy. Se si applica una policy all'interfaccia fisica, usare il comando show policy-map interface serial o il comando show policy-map interface bri 0/0:1 (e bri0/0:2) per confermare la configurazione. Il canale D, identificato in IOS come BRI0/0, supporta la segnalazione e non il traffico di dati. Se si applica un criterio all'interfaccia della connessione telefonica, usare il comando show queueing interface dial <0-255> per confermare la configurazione.

Le versioni 12.2(4) e 12.2(4)T del software Cisco IOS introducono il supporto per le policy di servizio basate sulle code sulle interfacce di accesso virtuale create da un'interfaccia di connessione configurata con MLPPP. Nelle versioni precedenti, i parametri dei criteri di servizio non vengono copiati sull'interfaccia di accesso virtuale duplicata, dove viene effettivamente eseguita la coda. Questo output mostra i seguenti sintomi:

Router#show policy interface dialer1

Dialer1

Service-policy output: foo

Class-map: class-default (match-any)

0 packets, 0 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: any

Weighted Fair Queueing

Flow Based Fair Queueing

Maximum Number of Hashed Queues 256

(total queued/total drops/no-buffer drops) 0/0/0

Router#show policy interface virtual-access 2

Router#

Nota: si consiglia di usare il software Cisco IOS versione 12.2(8) e 12.2(8)T per evitare l'ID bug Cisco CSCdu87408, che risolve i ricaricamenti del router come un raro effetto collaterale di questa configurazione.

In questa configurazione di esempio viene mostrato come applicare CBWFQ e LLQ a un'interfaccia dialer. Questa configurazione consente di:

- Utilizza un'interfaccia dialer per applicare in modo dinamico i parametri di protocollo della connessione alle interfacce ISDN BRI. L'interfaccia dialer è detta "associata" alle interfacce ISDN BRI.

- Inserisce due interfacce ISDN BRI in un bundle con connessione multipla.

- Utilizza il carico soglia di carico del dialer [in uscita] | in entrata | any] per determinare quando il router deve attivare altri B-channel e aumentare la larghezza di banda dell'interfaccia del pacchetto.

- Crea un'interfaccia di accesso virtuale con il comando ppp multilink.

- Applica una policy di servizio con CBWFQ e LLQ all'interfaccia di accesso virtuale tramite l'interfaccia di connessione.

Esempio di configurazione

access-list 101 permit udp any any range 16384 32767

access-list 101 permit tcp any any eq 1720

!

access-list 102 permit tcp any any eq 23

!

class-map voice

match access-group 101

!--- Traffic that matches ACL 101 is classified as class voice.

class-map data

match access-group 102

!--- Traffic that matches ACL 102 is classified as class data.

policy-map mlppp

class voice

priority percent 50

class data

bandwidth percent 25

class class-default

fair-queue

!

interface BRI2/1

no ip address

encapsulation ppp

dialer pool-member 1

!--- Member of dialer pool 1.

isdn switch-type basic-net3

no cdp enable

ppp authentication chap

!

interface BRI2/2

no ip address

encapsulation ppp

dialer pool-member 1

!--- Member of dialer pool 1.

isdn switch-type basic-net3

no cdp enable

ppp authentication chap

!

interface Dialer2

ip unnumbered Loopback0

encapsulation ppp

dialer pool 1

dialer load-threshold 1 either

!--- Load level (in either direction) for !--- traffic at which additional connections !--- are added to the MPPP bundle !--- load level values that range from 1 (unloaded) !--- to 255 (fully loaded).

dialer string 6113

dialer string 6114

dialer-group 1

ppp authentication chap

ppp multilink

!--- Allow MLPPP for the four BRI channels.

service-policy output mlppp

!--- Apply the service policy to the dialer interface.

LLQ e CBWFQ con MLPPP distribuito

Cisco serie 7500 utilizza un'architettura distribuita che assicura un elevato throughput dei pacchetti spostando le decisioni di inoltro dal Route Switch Processor (RSP) ai Versatile Interface Processor (VIP). Questa architettura consente inoltre l'implementazione di servizi IP avanzati su larga scala, ad esempio QoS, distribuendo il carico di elaborazione tra più processori indipendenti dei VIP.

Basata sull'hardware di interfaccia, Cisco serie 7500 supporta due forme di QoS:

QoS

Modalità di abilitazione

Dove supportato

Dove elaborato

Basato su RSP

Automaticamente su processori di interfaccia legacy.

Processori di interfaccia legacy. Non può più essere abilitato nei VIP.

CPU RSP

Basato su VIP (distribuito)

Automaticamente, quando sono configurati questi due comandi:

- Il comando ip cef distributed in modalità di configurazione globale.

- Il comando ip route-cache distributed in modalità di configurazione interfaccia.

VIP

CPU VIP

I meccanismi QoS basati su VIP applicati tramite la CLI QoS modulare (MQC) sono introdotti nei seguenti tre software Cisco IOS:

- Software Cisco IOS versione 12.0(XE), che è diventato software Cisco IOS versione 12.1(E)

- Software Cisco IOS release 12.0(9)S

- Software Cisco IOS versione 12.1(5)T, che è diventato software Cisco IOS versione 12.2 mainline e software Cisco IOS versione 12.2T

La funzionalità MLPPP distribuita consente di combinare la larghezza di banda di più interfacce T1/E1 su un VIP in un'interfaccia bundle. Per ulteriori informazioni, fare riferimento al protocollo point-to-point Multilink distribuito per i router Cisco serie 7500. Il software Cisco IOS versione 12.2(13)T introduce il supporto per MLPPP (dMLPPP) distribuiti su schede di porta non canalizzate, quali PA-4T+ e PA-8T.

Nel software Cisco IOS versione 12.2(8)T è stato introdotto il supporto per LLQ e CBWFQ distribuiti sulle interfacce del bundle dMLPPP su adattatori di porte canalizzate quali PA-MC-xT1/E1 e PA-MC-xT3/E3. Come la versione non distribuita di questa funzionalità, dMLPPP utilizza un'interfaccia a connessione multipla per creare un'interfaccia di accesso virtuale in cui viene eseguita funzionalmente la coda. Fare riferimento alle informazioni nuove e modificate per il software Cisco IOS versione 12.2T. Quando si applica l'accodamento distribuito con dMLPPP, si consiglia il software Cisco IOS versione 12.2(10)T o successive per evitare l'ID bug Cisco CSCdw47678.

Solo CBWFQ e LLQ applicati con il comando service-policy sono supportati con dMLPPP/dLFI. Le funzionalità di accodamento legacy, ad esempio l'accodamento equo con il comando fair-queue, l'accodamento di priorità con il comando priority-group e l'accodamento personalizzato con il comando queue-list, non sono supportate.

FlexWAN per Cisco serie 7600 supporta dLLQ su interfacce non bundle. Non supporta dLLQ sulle interfacce del bundle MLPPP. Questo supporto è disponibile per il software Cisco IOS versione 12.2S.

La configurazione di esempio riportata di seguito applica dLLQ su un'interfaccia con connessione multipla.

Configurazione di esempio di dLLQ su un'interfaccia del bundle MLPPP

Interface

!

access-list 100 permit udp any any range 16384 32000

access-list 100 permit tcp any any eq 1720

access-list 101 permit tcp any any eq 80

access-list 102 permit tcp any any eq 23

!

class-map voip

match access-group 100

class-map data1

match access-group 101

class-map data2

match access-group 102

!

policy-map llq-policy

class voip

bandwidth 40

class data1

bandwidth 15

class data2

bandwidth 15

class class-default

fair-queue

!

policy-map set-policy

class voip

bandwidth 40

class data1

bandwidth 15

class data2

bandwidth 15

class class-default

fair-queue

!

interface Serial5/0/0:0

no ip address

encapsulation ppp

keepalive 10

ppp chap hostname G2

ppp multilink

multilink-group 2

!

interface Serial5/1/0:0

no ip address

encapsulation ppp

keepalive 10

ppp chap hostname G2

ppp multilink

multilink-group 2

!

interface Multilink2

ip address 106.0.0.2 255.0.0.0

ppp multilink

service-policy output llq-policy

service-policy input set-policy

multilink-group 2

LFI (Link fragmentation and interleaving): aggiungere i comandi ppp multilink fragment-delay e ppp multilink interleave a un modello virtuale di interfaccia configurato con MLPPP e un criterio del servizio. Questa configurazione riduce il ritardo sui collegamenti più lenti suddividendo i datagrammi di grandi dimensioni e interlasciando i pacchetti di traffico a basso ritardo con i pacchetti più piccoli risultanti dal datagramma frammentato. Per ulteriori informazioni, consultare il documento sulla configurazione della frammentazione e dell'interfoliazione dei collegamenti per Frame Relay e circuiti virtuali ATM.

Il software Cisco IOS versione 12.2(8)T ha introdotto il supporto per linee seriali sovraccanalizzate LFI (Distributed LFI) sui Cisco serie 7500 con VIP. Questa funzione è disponibile anche sugli switch Catalyst serie 6500 e sui router Cisco serie 7600. Per informazioni sulle versioni che supportano dLFI, fare riferimento allo strumento Feature Navigator (solo utenti registrati) e alle note sulla versione per i rispettivi prodotti. Per ulteriori informazioni su questa funzione, fare riferimento a Frammentazione di collegamenti distribuiti e interfoliazione su linee affittate.

FlexWAN per Cisco serie 7600 con software Cisco IOS versione Training 12.1E non supporta dLFI.

Dopo aver configurato il ritardo massimo del frammento con il comando ppp multilink fragment-delay <msec>, la funzione dLFI calcola le dimensioni effettive del frammento sulle interfacce seriali canalizzate usando questa formula (dove la larghezza di banda è in kbps):

fragment size = bandwidth x fragment-delay  / 8

Inoltre, le dimensioni del frammento vengono calcolate in base al collegamento del membro con la quantità di larghezza di banda più piccola. Ad esempio, in una configurazione con collegamenti membri di 64 k e 128 k, le dimensioni del frammento vengono calcolate in base al collegamento 64 k.

CBWFQ e LLQ con PPPoA e MLPPPoA

Il software Cisco IOS versione 12.2(8) ha introdotto il supporto per le code per-VC sui circuiti virtuali ATM configurati con incapsulamento PPP over ATM (PPPoA) generico. In queste sottosezioni vengono forniti esempi di configurazione di contrassegno basato su classi, policy e accodamento.

1. Contrassegno basato su classi

Il comando service-policy può essere associato all'interfaccia Virtual-template o al PVC ATM per il contrassegno basato su classi.

In questo esempio viene definita la mappa di classe PEER2PEER, viene creata la mappa dei criteri MARK_PEER2PEER e viene configurato il valore predefinito dscp per la classe PEER2PEER; quindi la policy-servizio viene associata al modello virtuale o al PVC ATM.

Router(config)#class-map PEER2PEER

Router(config-cmap)#match access-group 100

Router(config-cmap)#exit

Router(config)#policy-map MARK_PEER2PEER

Router(config-pmap)#class PEER2PEER

Router(config-pmap-c)#set dscp default

Router(config-pmap-c)#end

Attaching Service-policy to Virtual Template

Router(config-subif)#int atm1/0.1 point-to-point

Router(config-subif)#ip address 10.10.10.1 255.255.255.0

Router(config-subif)#pvc 1/50

Router(config-if-atm-vc)#encapsulation aal5mux ppp virtual-Template 1

Router(config)#interface Virtual-Template1

Router(config-if)#ip address negotiated

Router(config-if)#service-policy output MARK_PEER2PEER

Attaching Service-policy to ATM pvc

Router(config)#int atm1/0.1 point-to-point

Router(config-subif)#ip address 10.10.10.1 255.255.255.0

Router(config-subif)#pvc 1/50

Router(config-if-atm-vc)#service-policy output MARK_PEER2PEER

2. Sorveglianza basata su classi:

Il comando service-policy può essere associato all'interfaccia Virtual-template o al PVC ATM per il Policing basato su classi.

Router(config)#policy-map POLICE_PEER2PEER

Router(config-pmap)#class PEER2PEERRouter(config-pmap-c)#police 8000 conform-action transmit exceed-action drop

Attaching Service-policy to Virtual Template

Router(config-subif)#int atm1/0.2 multipoint

Router(config-subif)#no ip address

Router(config-subif)#pvc 1/100

Router(config-if-atm-vc)#encapsulation aal5mux ppp virtual-Template 2

Router(config)#interface Virtual-Template2

Router(config-if)#ip address negotiated

Router(config-if)#service-policy output POLICE_PEER2PEER

Attaching Service-policy to ATM pvc

Router(config)#int atm1/0.2 multipoint

Router(config-subif)#no ip address

Router(config-subif)#pvc 1/100

Router(config-if-atm-vc)#service-policy output POLICE_PEER2PEER

3. Accodamento basato su classi:

Per l'accodamento basato su classi, ovvero larghezza di banda, forma, priorità e rilevamento casuale, il comando service-policy può essere associato al modello virtuale o al PVC ATM.

Router(config)#policy-map QUEUE_PEER2PEER

Router(config-pmap)#class PEER2PEER

Router(config-pmap-c)#bandwidth 768

Attaching Service-policy to Virtual Template

Router(config-subif)#int atm1/0

Router(config-subif)#no atm ilmi-keepalive

Router(config-subif)#pvc 1/150

Router(config-if-atm-vc)#encapsulation aal5mux ppp virtual-Template 3

Router(config)#interface Virtual-Template3

Router(config-if)#ip address negotiated

Router(config-if)#service-policy output QUEUE_PEER2PEER

Attaching Service-policy to ATM pvc

Router(config)#int atm1/0

Router(config-subif)#no atm ilmi-keepalive

Router(config-subif)#pvc 1/150

Router(config-if-atm-vc)#service-policy output QUEUE_PEER2PEER

Nota: quando si utilizza una combinazione di contrassegno basato su classi o di policy basato su classi e di accodamento basato su classi, l'ordine delle operazioni è il seguente:

1. Il comando service-policy configurato sull'interfaccia Virtual-Template contrassegna o regola i pacchetti.

2. Il comando service-policy sul PVC ATM accoda i pacchetti.

Fare riferimento a questo esempio:

policy-map MARK_PEER2PEER

class PEER2PEER

set dscp default

!

interface ATM0/0

no ip address

no atm ilmi-keepalive

pvc 1/100

encapsulation aal5mux ppp Virtual-Template1

service-policy output QUEUE_PEER2PEER

!

interface Virtual-Template1

ip address negotiate

service-policy output MARK_PEER2PEER

Se si esegue una versione precedente del software Cisco IOS, è possibile configurare ATM VC con incapsulamento MLPPPoA e applicare un criterio dei servizi basato sull'accodamento all'interfaccia del modello virtuale. Per ulteriori informazioni, fare riferimento a Link Fragmentation and Interleaving per Frame Relay e circuiti virtuali ATM e alla panoramica dei meccanismi di efficienza del collegamento.

Il software Cisco IOS versione 12.2(4)T3 introduce una versione distribuita di questa funzione per Cisco serie 7500. Per ulteriori informazioni su questa funzione, fare riferimento a Frammentazione e interfoliazione di collegamenti distribuiti per ATM e Frame Relay.

Informazioni correlate

- CBWFQ (Weighted Fair Queuing) per VC basato su classi di VC su router Cisco 7200, 3600 e 2600

- Accodamento a bassa latenza

- Supporto tecnologia QoS

- Documentazione e supporto tecnico – Cisco Systems