VoIP over Frame Relay con qualità del servizio (frammentazione, Traffic Shaping, priorità LLQ / IP RTP)

Introduzione

In questo documento viene mostrato un esempio di configurazione VoIP (Voice over IP) su una rete Frame Relay con QoS (Quality of Service). Questo documento include informazioni tecniche di base sulle funzionalità configurate, linee guida di progettazione e strategie di verifica e risoluzione dei problemi di base.

È importante notare che la configurazione di questo documento ha due router voce connessi alla rete Frame Relay. In molte topologie, tuttavia, i router abilitati per la voce possono esistere ovunque. In genere, i router voce utilizzano la connettività LAN ad altri router connessi alla WAN. Questa operazione è importante perché se i router voce non sono connessi direttamente alla rete Frame Relay, tutti i comandi di configurazione WAN devono essere configurati sui router connessi alla WAN e non sui router voce, come mostrato nelle configurazioni di questo documento.

Prerequisiti

Requisiti

Nessun requisito specifico previsto per questo documento.

Componenti usati

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

• Router Cisco 3640 con software Cisco IOS® versione 12.2.6a (Enterprise Plus)

• Cisco 2621 Router con software Cisco IOS versione 12.2.6a (Enterprise Plus)

• LLQ (Low-Latency Queueing) su PVC (Permanent Virtual Circuit) Frame Relay. Questa funzionalità è stata introdotta nel software Cisco IOS versione 12.1(2)T.

• Priorità Frame Relay IP Real-Time Transport Protocol (RTP) introdotta nel software Cisco IOS versione 12.0(7)T.

• Frammentazione Frame Relay Forum (FRF).12 introdotta nel software Cisco IOS versione 12.0(4)T.

• Il software Cisco IOS versioni successive alla 12.0.5T contengono miglioramenti significativi delle prestazioni per il RTP compresso (cRTP).

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

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

Linee guida di progettazione QoS per VoIP su Frame Relay

Esistono due requisiti di base per una buona qualità vocale:

• Ritardo minimo end-to-end e riduzione dell'effetto jitter (variazione del ritardo).

• Requisiti di larghezza di banda del collegamento ottimizzati e progettati correttamente.

Per garantire i requisiti sopra indicati, attenersi alle seguenti linee guida:

• Priorità rigorosa per la priorità LLQ o IP RTP del traffico voce

• Frame Relay Traffic Shaping (FRTS) per voce

• Frammentazione FRF.12

• Riduzione della larghezza di banda

Priorità rigorosa per traffico voce (priorità LLQ o IP RTP)

Esistono due metodi principali per assegnare una priorità assoluta al traffico vocale:

• Priorità IP RTP (chiamata anche coda di priorità / PQ (Weighted Fair Queuing))

• LLQ (denominato anche PQ / Class Based Weighted Fair Queuing (PQ/CBWFQ))

Priorità IP RTP

La priorità Frame Relay IP RTP crea una coda di priorità rigida su un PVC Frame Relay per un set di flussi di pacchetti RTP che appartengono a un intervallo di porte di destinazione UDP (User Datagram Protocol). Mentre le porte effettivamente utilizzate vengono negoziate in modo dinamico tra dispositivi finali o gateway, tutti i prodotti Cisco VoIP utilizzano lo stesso intervallo di porte UDP (da 16384 a 32767). Una volta riconosciuto il traffico VoIP, il router lo posiziona nel PQ rigoroso. Quando la coda PQ è vuota, le altre code vengono elaborate in base alla coda WFQ standard. La priorità IP RTP non diventa attiva finché l'interfaccia non è congestionata. Nell'immagine viene mostrato come funzionare la priorità IP RTP:

Nota: la priorità IP RTP consente la frammentazione del PQ quando è disponibile larghezza di banda nella coda predefinita (WFQ). Tuttavia, esegue una policy rigorosa sul contenuto di PQ in caso di congestione sull'interfaccia.

LLQ

LLQ è una funzione che fornisce un PQ rigoroso a CBWFQ. LLQ consente un singolo PQ rigoroso all'interno di CBWFQ a livello di classe. Con LLQ, i dati sensibili al ritardo (nel PQ) vengono rimossi dalla coda e inviati per primi. In un VoIP con implementazione LLQ, il traffico vocale viene posizionato nel PQ rigoroso.

Il PQ è controllato per garantire che le code eque non siano affamate di larghezza di banda. Quando si configura la PQ, è necessario specificare, in Kbps, la quantità massima di larghezza di banda disponibile per la PQ. Quando l'interfaccia è congestionata, il PQ viene servito finché il carico non raggiunge il valore Kbps configurato nell'istruzione priority. Il traffico in eccesso viene quindi scartato per evitare il problema con la funzionalità legacy di gruppo di priorità di Cisco, che prevede la riduzione della quantità di dati dei PQ inferiori.

Nota: con LLQ per Frame Relay, le code vengono impostate per PVC. Ogni PVC ha un PQ e un numero assegnato di code eque.

Questo metodo è più complesso e flessibile della priorità IP RTP. La scelta tra i metodi deve essere basata sugli schemi di traffico nella rete reale e sulle tue esigenze.

Priorità LLQ e IP RTP

La tabella riepiloga le principali differenze tra la priorità LLQ e la priorità IP RTP e fornisce le linee guida per l'utilizzo di ciascun metodo.

FRTS per la voce

Il servizio FRTS fornisce parametri utili per gestire la congestione del traffico di rete. FRTS elimina i colli di bottiglia nelle reti Frame Relay con connessioni ad alta velocità al sito centrale e connessioni a bassa velocità ai siti di filiale. È possibile configurare i valori di imposizione della velocità in modo da limitare la velocità di invio dei dati dal circuito virtuale (VC) nel sito centrale.

Queste definizioni sono correlate alle FRTS:

• CIR (Committed Information Rate): velocità (bit al secondo) garantita dal provider Frame Relay per il trasferimento dei dati. I valori CIR vengono impostati dal provider di servizi Frame Relay e configurati dall'utente sul router.

  Nota: la velocità di accesso alla porta o all'interfaccia può essere superiore a CIR. Il tasso viene calcolato come media in un periodo di tempo Tc (Committed Rate Measurement Interval).

• Committed Burst (Bc) - Numero massimo di bit che la rete Frame Relay può trasferire su un Tc. Tc = Bc / CIR

• Excess Burst (Be) - Numero massimo di bit non vincolati che lo switch Frame Relay tenta di trasferire oltre il CIR sul Tc.

• Committed Rate Measurement Interval (Tc) - Intervallo di tempo durante il quale vengono trasmessi i bit Bc o (Bc+ Be). Tc viene calcolato come Tc = Bc / CIR. Il valore Tc non è configurato direttamente sui router Cisco. Viene calcolato dopo la configurazione dei valori Bc e CIR. Il valore Tc non può superare 125 ms.

• BECN (Backward Explicit Congestion Notification) - Bit nell'intestazione del frame Frame Relay che indica la congestione nella rete. Quando uno switch Frame Relay riconosce la congestione, imposta il bit BECN sui frame destinati al router di origine e indica al router di ridurre la velocità di trasmissione.

La configurazione di FRTS per il traffico vocale è diversa da quella del traffic shaping dei soli dati. Quando si configura FRTS per la qualità della voce, i parametri del traffico dati vengono compromessi. Per ulteriori informazioni su queste restrizioni, vedere la sezione Frammentazione (FRF.12) in questo documento.

Frammentazione (FRF.12)

Una grande sfida per l'integrazione dei dati vocali consiste nel controllare il massimo ritardo unidirezionale end-to-end per il traffico sensibile al tempo, come quello vocale. Per una buona qualità della voce, questo ritardo deve essere inferiore a 150 ms. Una parte importante di questo ritardo è il ritardo di serializzazione sull'interfaccia. Cisco consiglia un valore di 10 ms e non superiore a 20 ms. Il ritardo di serializzazione è il tempo necessario per posizionare realmente i bit su un'interfaccia.

Serialization Delay = frame size (bits) / link bandwidth (bps)

Ad esempio, un pacchetto da 1500 byte impiega 214 ms per uscire dal router su un collegamento a 56 Kbps. Se si invia un pacchetto di dati non in tempo reale di 1500 byte, i pacchetti di dati in tempo reale (voce) vengono accodati fino a quando non viene trasmesso il pacchetto di dati di grandi dimensioni. Questo ritardo è inaccettabile per il traffico vocale. Se i pacchetti di dati non in tempo reale vengono frammentati in frame più piccoli, vengono interlacciati ai frame (voce) in tempo reale. In questo modo, sia i frame voce che dati possono essere trasportati insieme su collegamenti a bassa velocità senza causare un ritardo eccessivo al traffico vocale in tempo reale.

Per ulteriori informazioni sulla frammentazione, fare riferimento a Frammentazione Frame Relay per voce.

Nota: nei casi in cui si dispone di una connessione half T1 dedicata (768 kbps), probabilmente non è necessaria una funzione di frammentazione. Tuttavia, è ancora necessario un meccanismo QoS (in questo caso IP RTP Priority o LLQ). Le velocità half-T1 o superiori offrono una larghezza di banda sufficiente per consentire ai pacchetti voce di entrare e uscire dalla coda entro l'intervallo di ritardo di serializzazione consigliato (10 ms, non più tardi di 20 ms). Inoltre, in caso di T1 completo, probabilmente non è necessario il protocollo cRTP, che consente di risparmiare larghezza di banda comprimendo le intestazioni IP RTP.

Riduzione della larghezza di banda

cRTP

Basata sulla RFC 2508 , la funzione cRTP comprime l'intestazione del pacchetto IP/UDP/RTP da 40 byte a 2 o 4 byte. Ciò riduce il consumo di larghezza di banda non necessario. È uno schema di compressione hop-by-hop. Pertanto, cRTP deve essere configurato su entrambe le estremità del collegamento, a meno che non sia configurata l'opzione passiva.

Nota: il protocollo cRTP non è richiesto per garantire una buona qualità della voce. È una funzione che riduce il consumo di larghezza di banda. Configurare cRTP dopo che tutte le altre condizioni sono state soddisfatte e la qualità della voce è buona. Questa procedura consente di risparmiare tempo nella risoluzione dei problemi, in quanto isola potenziali problemi cRTP.

Monitorare l'utilizzo della CPU del router. Disabilitare cRTP se è superiore al 75%. Con velocità di collegamento più elevate, il risparmio di larghezza di banda del cRTP potrebbe essere potenzialmente superato dal carico aggiuntivo della CPU. Cisco consiglia di utilizzare il protocollo cRTP solo con collegamenti inferiori a 768 Kbps, a meno che il router non abbia una bassa percentuale di utilizzo della CPU.

Nota: in assenza di uno standard, il protocollo cRTP per Frame Relay è stato sviluppato sull'incapsulamento proprietario di Cisco. Pertanto, non funziona con l'incapsulamento IETF (Internet Engineering Task Force) di Frame Relay. Recentemente, FRF.20 è stato finalizzato per rendere possibile la compressione dell'intestazione RTP sull'incapsulamento IETF. Tuttavia, a partire dall'ultimo aggiornamento di questo documento (maggio 2002), FRF.20 non è supportato.

Per ulteriori informazioni, consultare il documento sul protocollo Compressed Real-time Transport Protocol.

Selezione Coder/Decoder (Codec)

Utilizzare codec a bassa velocità di trasmissione sulle gambe di chiamata VoIP. G.729 (8 Kbps) è il codec predefinito per il dial-peer VoIP.

Nota: Sebbene il DTMF (Dual Tone Multifrequency) venga solitamente trasportato con precisione quando si utilizzano codec voce ad alto bit-rate (come G.711), i codec a basso bit-rate (come G.729 e G.723.1) sono altamente ottimizzati per i modelli di voce e tendono a distorcere i toni DTMF. Questo approccio può causare problemi di accesso ai sistemi IVR (Interactive Voice Response). Il comando dtmf relay risolve il problema della distorsione DTMF. Trasporta i toni DTMF fuori banda o separati dal flusso vocale codificato. Se si utilizzano codec a bassa velocità di trasmissione (G.729, G.723), attivare il comando dtmf relay nel dial-peer VoIP.

Abilita rilevamento attività voce (VAD)

Una conversazione tipica potrebbe potenzialmente contenere dal 35 al 50% di silenzio. I pacchetti silenziosi vengono eliminati quando si utilizza VAD. Per la pianificazione della larghezza di banda VoIP, si supponga che il VAD riduca la larghezza di banda del 35%. Il protocollo VAD è configurato per impostazione predefinita nei dial-peer VoIP.

Configurazione

In questa sezione vengono presentate le informazioni necessarie per configurare le funzionalità descritte più avanti nel documento.

Nota: per ulteriori informazioni sui comandi menzionati in questo documento, usare lo strumento di ricerca dei comandi (solo utenti registrati).

LLQ

Utilizzare questa procedura per configurare LLQ:

1. Creare una mappa di classe per il traffico VoIP e definire i criteri di corrispondenza.

   Questi comandi spiegano come completare questa attività:

   maui-voip-sj(config)#class-map ?
          WORD 		class-map name
          match-all 	Logical-AND all matching statements under this classmap
          match-any 	Logical-OR all matching statements under this classmap
   maui-voip-sj(config)#class-map match-all voice-traffic 
   
   !--- Choose a descriptive class_name. 
   
   
   maui-voip-sj(config-cmap)#match ?
     access-group         Access group
     any                  Any packets
     class-map            Class map
     cos                  IEEE 802.1Q/ISL class of service/user priority values
     destination-address  Destination address
     input-interface      Select an input interface to match
     ip                   IP specific values
     mpls                 Multi Protocol Label Switching specific values
     not                  Negate this match result
     protocol             Protocol
     qos-group            Qos-group
     source-address       Source address
   
   !--- In this example the access-group matching !--- option is used for its flexibility (it uses an access-list).
   
   
   maui-voip-sj(config-cmap)#match access-group ?
     <1-2699>  Access list index
     name      Named Access List
   maui-voip-sj(config-cmap)#match access-group 102 
   
   
   !--- Create the access-list to match the class-map access-group:
   
   
   maui-voip-sj(config)#access-list 102 permit udp any any range 16384 32767
   
   !--- The safest and easiest way is to match with UDP port range 16384-32767. !--- This is the port range Cisco IOS H.323 products utilize to transmit !--- VoIP packets.
   
   

   Questi elenchi degli accessi vengono usati anche per abbinare il traffico vocale al comando match access-group:

   access-list 102 permit udp any any precedence critical
   
   !--- This list filters traffic based on the IP packet TOS: Precedence field. !--- Note: Ensure that the other non-voice traffic does not use the !--- same precedence value.
   
   
   access-list 102 permit udp any any dscp ef
   
   !--- In order for this list to work, ensure that VoIP packets are tagged !--- with the dscp ef code before they exit on the LLQ WAN interface. !--- For more information on DSCP, refer to !--- Implementing Quality of Service Policies with DSCP. !--- Note: If endpoints are not trusted on their packet marking, !--- mark incoming traffic by applying an inbound service policy on an !--- inbound interface. This procedure is out of the scope !--- of this document. 
   
   
   access-list 102 permit udp host 192.10.1.1 host 192.20.1.1
   
   !--- This access-list can be used in cases where the VoIP !--- devices cannot do precedence or DSCP marking and you !--- cannot determine the VoIP UDP port range.
    

   Di seguito sono riportati altri metodi corrispondenti che è possibile utilizzare al posto dei comandi access-group:

   • Con il software Cisco IOS versione 12.1.2.T e successive, la funzionalità di priorità IP RTP è implementata per LLQ. Questa funzionalità corrisponde al contenuto della classe di priorità che controlla le porte UDP configurate. È soggetta alla limitazione di servire solo porte pari nel PQ.

     class-map voice
       match ip rtp 16384 16383
     

   • Questi due metodi funzionano presupponendo che i pacchetti VoIP siano contrassegnati sugli host di origine o corrispondano e siano contrassegnati sul router prima di applicare l'operazione LLQ in uscita:

     class-map voice 
        match ip precedence 5
     

     O

     class-map voice
        match ip dscp ef
     

     Nota: nel software Cisco IOS versione 12.2.2T e successive, i dial-peer VoIP possono contrassegnare i pacchetti di segnalazione e invio vocale prima dell'operazione LLQ. Ciò consente un modo scalabile di contrassegnare e abbinare i pacchetti VoIP attraverso i valori del codice DSCP per LLQ. Per ulteriori informazioni, fare riferimento a Classificazione della segnalazione e dei supporti VoIP con DSCP per la QoS.

     Router(config-dial-peer)#ip qos dscp ?
     

2. Creare una mappa di classe per la segnalazione VoIP e definire i criteri di corrispondenza (facoltativo).

   Utilizzare i seguenti comandi per completare questa attività:

   class-map voice-signaling
     match access-group 103
   !
   access-list 103 permit tcp any eq 1720 any
   access-list 103 permit tcp any any eq 1720
   

   Nota: le chiamate VoIP possono essere stabilite usando il protocollo H.323, il protocollo SIP (Session Initiation Protocol), MGCP (Media Gateway Control Protocol) o SCCP (Skinny Call Control Protocol) - protocollo proprietario usato da Cisco Call Manager. L'esempio precedente presuppone una connessione rapida H.323. L'elenco seguente funge da riferimento per le porte utilizzate dai canali di segnalazione e controllo VoIP:

   • H.323/H.225 = TCP 1720

   • H.323/H.245 = TCP 11xxx (connessione standard)

   • H.323/H.245 = TCP 1720 (Fast Connect)

   • H.323/H.225 RAS = UDP 1718 (To Gate Keeper)

   • SCCP = TCP 2000-2002 (CM Encore)

   • ICCP = TCP 8001-8002 (CM Encore)

   • MGCP = UDP 2427, TCP 2428 (CM Encore)

   • SIP= UDP 5060, TCP 5060 (configurabile)

3. Creare una mappa criteri e associarla alle mappe classi VoIP.

   Lo scopo della mappa dei criteri è quello di definire la modalità di condivisione o assegnazione delle risorse di collegamento alle diverse classi di mappe. Utilizzare i seguenti comandi per completare questa attività:

   maui-voip-sj(config)#policy-map VOICE-POLICY
   
   !--- Choose a descriptive policy_map_name.
   
   
   maui-voip-sj(config-pmap)#class voice-traffic
   maui-voip-sj(config-pmap-c)#priority ?
    <8-2000000>  Kilo Bits per second
   
   !--- Configure the voice-traffic class to the strict PQ !--- (priority command) and assign the bandwidth.
   
   
   maui-voip-sj(config-pmap)#class voice-signaling
   maui-voip-sj(config-pmap-c)#bandwidth 8
   
   !--- Assign 8 Kbps to the voice-signaling class.
   
   
   maui-voip-sj(config-pmap)#class class-default
   maui-voip-sj(config-pmap-c)#fair-queue 
   
   !--- The remaining data traffic is treated as WFQ.
   
   

   Nota: anche se è possibile accodare vari tipi di traffico in tempo reale al PQ, Cisco consiglia di indirizzare solo il traffico vocale al PQ. Il traffico in tempo reale, ad esempio i video, può introdurre variazioni di ritardo (la coda PQ è una coda FIFO (First In First Out)). Il traffico vocale richiede che il ritardo non sia variabile per evitare lo jitter.

   Nota: la somma dei valori delle istruzioni priority e bandwidth deve essere minore o uguale a minCIR per il PVC. In caso contrario, il comando service-policy non può essere assegnato al collegamento. Il valore di minCIR è la metà di CIR per impostazione predefinita. Per visualizzare i messaggi di errore, verificare che il comando logging console sia abilitato per l'accesso alla console e che il comando terminal monitor sia abilitato per l'accesso Telnet.

   Per ulteriori informazioni sui comandi larghezza di banda e priorità, fare riferimento a Confronto tra i comandi larghezza di banda e priorità di un criterio di servizio QoS.

4. Abilitare LLQ applicando la mappa dei criteri all'interfaccia WAN in uscita.

   Utilizzare i seguenti comandi per abilitare LLQ:

   maui-voip-sj(config)#map-class frame-relay VoIPovFR
   maui-voip-sj(config-if)#service-policy output VOICE-POLICY
   
   !--- The service-policy is applied to the PVC !--- indirectly by configuring !--- it under the map-class associated to the PVC.
   
   

Priorità IP RTP

Se non si utilizza LLQ, attenersi alle seguenti linee guida:

Router(config-map-class)#frame-relay ip rtp priority starting-rtp-port  
port-range  bandwidth 

• Starting-rtp-port: il numero di porta UDP iniziale. Il numero di porta più basso a cui vengono inviati i pacchetti. Per VoIP, impostare questo valore su 16384.

• port-range: l'intervallo di porte di destinazione UDP. Il numero, aggiunto alla porta rtp iniziale, restituisce il numero di porta UDP più alto. Per VoIP, impostare questo valore su 16383.

• larghezza di banda: larghezza di banda massima consentita in kbps per la coda di priorità. Imposta questo numero in base al numero di chiamate simultanee, aggiungendo la larghezza di banda di ogni chiamata supportata dal sistema.

Configurazione di esempio:

map-class frame-relay VoIPovFR  frame-relay cir 64000
 frame-relay BC 600
 no frame-relay adaptive-shaping
 frame-relay fair-queue
 frame-relay fragment 80
 frame-relay ip rtp priority 16384 16383 45

Traffic Shaping per la voce

Per configurare il traffic shaping per la voce, attenersi alle seguenti linee guida:

• non superare il CIR del PVC.

• Disabilita il shaping adattivo Frame Relay.

• Impostare il valore Bc su Basso in modo che Tc (intervallo di shaping) sia 10 ms (Tc = Bc/CIR). Configurate il valore Bc per forzare il valore Tc desiderato.

• Impostare il valore Be su 0.

Per ulteriori informazioni su queste linee guida, fare riferimento a Frame Relay Traffic Shaping per VoIP e VoFR.

Nota: alcuni clienti utilizzano PVC separati per dati e voce. Se si dispone di due PVC distinti e si desidera che il PVC dati venga frammentato mentre ci si trova al livello CIR o al di sotto di tale livello per il PVC voce, la qualità della voce ne risente ancora poiché questi PVC utilizzano la stessa interfaccia fisica. In questi casi, il provider Frame Relay e il router devono assegnare la priorità al PVC voce. Per quest'ultima operazione, è possibile usare il protocollo PVC Interface Priority Queueing (PIPQ) disponibile nel software Cisco IOS versione 12.1(1)T.

Frammentazione (FRF.12)

Attiva frammentazione per collegamenti a bassa velocità (inferiori a 768 kbps). Impostare le dimensioni del frammento in modo che i pacchetti voce non vengano frammentati e non si verifichi un ritardo di serializzazione superiore a 20 ms. Impostare le dimensioni della frammentazione in base alla velocità della porta più bassa tra i router. Ad esempio, se esiste una topologia Frame Relay hub e spoke in cui l'hub ha una velocità T1 e i router remoti hanno velocità di porta 64 K, è necessario impostare le dimensioni della frammentazione per la velocità 64 K su entrambi i router. Tutti gli altri PVC che condividono la stessa interfaccia fisica devono configurare la frammentazione sulle dimensioni utilizzate dal PVC voce. Utilizzare questo grafico per determinare i valori delle dimensioni della frammentazione.

Configurazione di esempio:

map-class frame-relay VoIPovFR 

!--- Some output is omitted.

 frame-relay fragment 80

Nota: per una velocità di 1536 Kbps, non è tecnicamente necessaria alcuna frammentazione. Tuttavia, la frammentazione è necessaria per consentire al sistema di coda doppio FIFO di garantire la qualità della voce. Una dimensione del frammento di 1600 byte permette di usare il doppio FIFO. Tuttavia, poiché i 1600 byte sono superiori alla MTU (Maximum Transmission Unit) dell'interfaccia seriale, i pacchetti di dati di grandi dimensioni non vengono frammentati.

Esempio di rete

Nel documento viene usata l'impostazione di rete mostrata nel diagramma:

Configurazioni

Questo documento utilizza le configurazioni mostrate di seguito:

• maui-voip-sj (Cisco 3640)

• maui-voip-austin (Cisco 3640)

version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname maui-voip-sj
!
logging buffered 10000 debugging
enable secret 5 $1$MYS3$TZ6bwrhWB25b2cVpEVgBo1
!
ip subnet-zero
!

!--- Definition of the voice signaling and traffic class maps. !--- "voice-traffic" class uses access-list 102 for its matching criteria. !--- "voice-signaling" class uses access-list 103 for its matching criteria.

class-map match-all voice-signaling
 match access-group 103
class-map match-all voice-traffic
  match access-group 102
!

!--- The policy map defines how the link resources are assigned !--- to the different map classes. In this configuration, strict PQ !--- is assigned to the voice-traffic class !--- with a maximum bandwidth of 45 Kbps.
 

policy-map VOICE-POLICY
  class voice-traffic
  priority 45
  class voice-signaling
  bandwidth 8


!--- Assigns a queue for voice-signaling traffic that ensures 8 Kbps. !--- Note that this is optional and has nothing to do with good voice !--- quality. Instead, it is a way to secure signaling.


  class class-default
  fair-queue


!--- The class-default class is used to classify traffic that does !--- not fall into one of the defined classes. !--- The fair-queue command associates the default class WFQ queueing.

!
interface Ethernet0/0
  ip address 172.22.113.3 255.255.255.0
  half-duplex
!
interface Serial0/0
 bandwidth 128
 no ip address
 encapsulation frame-relay
 no fair-queue
frame-relay traffic-shaping
 frame-relay ip rtp header-compression

!--- Turns on traffic shaping and cRTP. If traffic-shaping is not !--- enabled, then map-class does not start and FRF.12 and LLQ does !--- not work.

!
interface Serial0/0.1 point-to-point
 bandwidth 128
 ip address 192.168.10.2 255.255.255.252
 frame-relay interface-dlci 300
  class VOIPovFR

!--- This command links the subinterface to a VoIPovFR map-class. !--- See the map-class frame-relay VoIPovFR command here: !--- Note: The word VoIPovFR is selected by the user. !

ip classless
ip route 172.22.112.0 255.255.255.0 192.168.10.1
!
map-class frame-relay VOIPovFR
 no frame-relay adaptive-shaping

!--- Disable Frame Relay BECNS. Note also that Be equals 0 by default.

frame-relay cir 64000
 frame-relay bc 640

!--- Tc = BC/CIR. In this case Tc is forced to its minimal !--- configurable value of 10 ms.

frame-relay be 0
 frame-relay mincir 64000

!--- Although adaptive shaping is disabled, make CIR equal minCIR !--- as a double safety. By default minCIR is half of CIR.

service-policy output VOICE-POLICY

!--- Enables LLQ on the PVC.

frame-relay fragment 80

!--- Turns on FRF.12 fragmentation and sets the fragment size equal to 80 bytes. !--- This value is based on the port speed of the slowest path link. !--- This command also enables dual-FIFO.

!
access-list 102 permit udp any any range 16384  32767
access-list 103 permit tcp any eq 1720 any
access-list 103 permit tcp any any eq 1720
!

!--- access-list 102 matches VoIP traffic !--- based on the UDP port range. !--- Both odd and even ports are put into the PQ. !--- access-list 103 matches VoIP signaling protocol. In this !--- case, H.323 V2 is uesd with the fast start feature.

!
voice-port 1/0/0
!
dial-peer voice 1 pots
 destination-pattern 5000
 port 1/0/0
!
dial-peer voice 2 voip
 destination-pattern 6000
 session target ipv4:192.168.10.1
 dtmf-relay cisco-rtp
 ip precedence 5

version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname maui-voip-austin
!
boot system flash slot1:c3640-is-mz.122-6a.bin
logging buffered 1000000 debugging
!
ip subnet-zero
!
class-map match-all voice-signaling
match access-group 103
class-map match-all voice-traffic
  match access-group 102
!
policy-map voice-policy
  class voice-signaling
   bandwidth 8
  class voice-traffic
    priority 45
  class class-default
   fair-queue
!
interface Ethernet0/0
 ip address 172.22.112.3 255.255.255.0
 no keepalive
 half-duplex
!
interface Serial0/0
 bandwidth 64
 no ip address
 encapsulation frame-relay
 no ip mroute-cache 
 no fair-queue
 frame-relay traffic-shaping
 frame-relay ip rtp header-compression
!
interface Serial0/0.1 point-to-point
 bandwidth 64
 ip address 192.168.10.1 255.255.255.252
 frame-relay interface-dlci 400
  class VOIPovFR
!
ip classless
ip route 172.22.113.0 255.255.255.0 192.168.10.2
!
map-class frame-relay VOIPovFR
no frame-relay adaptive-shaping
 frame-relay cir 64000
 frame-relay bc 640
 frame-relay be 0
 frame-relay mincir 64000
 service-policy output voice-policy
 frame-relay fragment 80
access-list 102 permit udp any any range 16384 32767
access-list 103 permit tcp any eq 1720 any
access-list 103 permit tcp any any eq 1720
!
voice-port 1/0/0
!
dial-peer voice 1 pots
 destination-pattern 6000
 port 1/0/0
!
dial-peer voice 2 voip
 destination-pattern 5000
 session target ipv4:192.168.10.2
 dtmf-relay cisco-rtp
 ip precedence 5

Verifica e risoluzione dei problemi

Le informazioni contenute in questa sezione permettono di verificare che la configurazione funzioni correttamente.

Alcuni comandi show sono supportati dallo strumento Output Interpreter (solo utenti registrati). Ciò consente di visualizzare un'analisi dell'output del comando show.

Comandi di priorità LLQ / IP RTP

I comandi show e debug permettono di verificare le configurazioni delle priorità LLQ e IP RTP.

• show policy-map interface serial interface# - Questo comando è utile per visualizzare l'operazione LLQ e le eventuali cadute nel PQ. Per ulteriori informazioni sui vari campi di questo comando, consultare il documento sulla descrizione dei contatori di pacchetti in show policy-map interface Output.

• show policy-map policy_map_name: visualizza le informazioni sulla configurazione della mappa dei criteri.

• show queue interface-type interface-number: elenca la configurazione e le statistiche di coda corrette per una particolare interfaccia.

• debug priority: visualizza gli eventi PQ e indica se si verifica l'eliminazione in questa coda. Per ulteriori informazioni, consultare il documento sulla risoluzione dei problemi relativi alle perdite di output con l'accodamento delle priorità.

• show class-map class_name: visualizza le informazioni sulla configurazione della mappa delle classi.

• show call active voice: verifica la presenza di pacchetti persi a livello di DSP.

• show frame-relay ip rtp header-compression: visualizza le statistiche di compressione dell'intestazione RTP.

Comandi di frammentazione

Utilizzare questi comandi debug e show per verificare e risolvere i problemi relativi alle configurazioni di frammentazione.

• show frame-relay fragment: visualizza le informazioni sulla frammentazione Frame Relay che si verifica nel router Cisco.

• debug frame-relay fragment: visualizza gli eventi o i messaggi di errore relativi alla frammentazione di Frame Relay. È abilitato solo a livello di PVC sull'interfaccia selezionata.

Comandi Frame Relay / Interface

Utilizzare questi comandi show per verificare e risolvere i problemi relativi alle configurazioni Frame Relay/Interface.

• show traffic-shape queue interface: restituisce informazioni sugli elementi in coda a livello di DLCI (Data-Link Connection Identifier) di VC. Utilizzato per verificare il funzionamento della priorità IP RTP su Frame Relay. Quando il collegamento è congestionato, i flussi vocali vengono identificati con un peso pari a zero. Ciò indica che il flusso vocale utilizza PQ. Vedere l'output di esempio qui.

• show traffic-shape: visualizza informazioni quali Tc, Bc, Be e i valori configurati CIR. Vedere l'output di esempio.

• show frame-relay pvc dlci-# : visualizza informazioni quali parametri di traffic shaping, valori di frammentazione e pacchetti ignorati. Vedere l'output di esempio. Fare riferimento anche alla sezione Risoluzione dei problemi di Frame Relay.

Problemi noti

È stato identificato un bug con per VC LLQ in cui il PQ era controllato severamente anche in assenza di congestione sull'interfaccia. Il bug è stato risolto e i pacchetti voce non conformi vengono scartati solo in caso di congestione della rete VC. In questo modo, il comportamento di LLQ per VC è identico a quello di altre interfacce che utilizzano LLQ. Questo comportamento è stato modificato con il software Cisco IOS versione 12.2(3) e successive.

Output di esempio del comando show e debug

In questo esempio viene usato l'output del comando show e debug per la verifica e la risoluzione dei problemi.

!--- To capture sections of this output, the LLQ PQ bandwidth !--- is lowered and large data traffic is placed !--- on the link to force packets drops. !--- Priority queue bandwidth is lowered to 10 Kbps to force drops from the PQ. !--- Note: To reset counters, use the clear counters command. 


maui-voip-sj#show policy-map inter ser 0/0.1
  Serial0/0.1: DLCI 300 -

  Service-policy output: VOICE-POLICY

Class-map: voice-traffic (match-all)
         26831 packets, 1737712 bytes
         5 minute offered rate 3000 bps, drop rate 2000 bps
         Match: access-group 102
         Weighted Fair Queueing
         Strict Priority
         Output Queue: Conversation 24
         Bandwidth 10 (kbps) Burst 250 (Bytes)
         (pkts matched/bytes matched) 26311/1704020
         (total drops/bytes drops) 439/28964

   Class-map: voice-signaling (match-all)
         80 packets, 6239 bytes
         5 minute offered rate 0 bps, drop rate 0 bps
         Match: access-group 103
         Weighted Fair Queueing
         Output Queue: Conversation 25
         Bandwidth 8 (kbps) Max Threshold 64 (packets)
         (pkts matched/bytes matched) 62/4897
         (depth/total drops/no-buffer drops) 0/0/0
    
   Class-map: class-default (match-any)
         14633 packets, 6174492 bytes
         5 minute offered rate 10000 bps, drop rate 0 bps
         Match: any
         Weighted Fair Queueing
         Flow Based Fair Queueing
         Maximum Number of Hashed Queues 16
         (total queued/total drops/no-buffer drops) 0/0/0

      

!--- These commands are useful to verify the LLQ configuration.
 
      
maui-voip-austin#show policy-map voice-policy
  Policy Map voice-policy
   Class voice-signaling
        Weighted Fair Queueing
           Bandwidth 8 (kbps) Max Threshold 64 (packets)
   Class voice-traffic
        Weighted Fair Queueing
         Strict Priority
             Bandwidth 45 (kbps) Burst 1125 (Bytes)
   Class class-default
        Weighted Fair Queueing
           Flow based Fair Queueing Max Threshold 64 (packets)

maui-voip-austin#show class-map
 Class Map match-all voice-signaling (id 2)
         Match access-group  103
 Class Map match-any class-default (id 0)
         Match any
 Class Map match-all voice-traffic (id 3)
         Match access-group 102


!--- Frame Relay verification command output.


maui-voip-sj#show frame-relay fragment
interface         dlci  frag-type    frag-size  in-frag    out-frag   dropped-frag
Serial0/0.1       300   end-to-end      80         4          4          0

maui-voip-sj#show frame-relay pvc 300

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

DLCI = 300, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1

 input pkts 7 output pkts 7 in bytes 926
         out bytes 918 dropped pkts 0 in FECN pkts 0
         in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
         in DE pkts 0 out DE pkts 0
         out bcast pkts 2 out bcast bytes 598
         pvc create time 1w2d, last time pvc status changed 1w2d
      service policy VOICE-POLICY

 Service-policy output: VOICE-POLICY

 Class-map: voice-traffic (match-all)
         0 packets, 0 bytes
         5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group 102
         Weighted Fair Queueing
      Strict Priority
         Output Queue: Conversation 24
         Bandwidth 45 (kbps) Burst 250 (Bytes)
         (pkts matched/bytes matched) 0/0
         (total drops/bytes drops) 0/0

 Class-map: voice-signaling (match-all)
         0 packets, 0 bytes
         5 minute offered rate 0 bps, drop rate 0 bps
         Match: access-group 103
         Weighted Fair Queueing
         Output Queue: Conversation 25
         Bandwidth 8 (kbps) Max Threshold 64 (packets)
         (pkts matched/bytes matched) 0/0
         (depth/total drops/no-buffer drops) 0/0/0

 Class-map: class-default (match-any)
         7 packets, 918 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 16
         (total queued/total drops/no-buffer drops) 0/0/0


 Output queue size 0/max total 600/drops 0
 fragment type end-to-end fragment size 80
 cir 64000 bc 640 be 0 limit 80 interval 10
 mincir 64000 byte increment 80 BECN response no
 frags 13 bytes 962 frags delayed 8 bytes delayed 642
 
 shaping inactive
 traffic shaping drops 0


!--- In this Frame Relay verification command !--- output, the PQ bandwidth is lowered and heavy traffic !--- is placed on the interface to force drops. 

maui-voip-sj#show frame-relay pvc 300

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

DLCI = 300, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1

 input pkts 483 output pkts 445 in bytes 122731
         out bytes 136833 dropped pkts 0 in FECN pkts 0
         in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
         in DE pkts 0 out DE pkts 0
         out bcast pkts 4 out bcast bytes 1196
         pvc create time 1w2d, last time pvc status changed 1w2d
         service policy VOICE-POLICY

 Service-policy output: VOICE-POLICY

 Class-map: voice-traffic (match-all)
         352 packets, 22900 bytes
         5 minute offered rate 2000 bps, drop rate 2000 bps
         Match: access-group 102
         Weighted Fair Queueing
         Strict Priority
         Output Queue: Conversation 24
         Bandwidth 10 (kbps) Burst 250 (Bytes)
         (pkts matched/bytes matched) 352/22900
         (total drops/bytes drops) 169/11188

 Class-map: voice-signaling (match-all)
         7 packets, 789 bytes
         5 minute offered rate 0 bps, drop rate 0 bps
         Match: access-group 103
         Weighted Fair Queueing
         Output Queue: Conversation 25
         Bandwidth 8 (kbps) Max Threshold 64 (packets)
         (pkts matched/bytes matched) 7/789
         (depth/total drops/no-buffer drops) 0/0/0

 Class-map: class-default (match-any)
         79 packets, 102996 bytes
         5 minute offered rate 4000 bps, drop rate 0 bps
         Match: any
         Weighted Fair Queueing
         Flow Based Fair Queueing
         Maximum Number of Hashed Queues 16
         (total queued/total drops/no-buffer drops) 5/0/0
         Output queue size 5/max total 600/drops 169
         fragment type end-to-end fragment size 80
         cir 64000 bc 640 be 0 limit 80 interval 10
         mincir 64000 byte increment 80 BECN response no
         frags 2158 bytes 178145 frags delayed 1968 bytes delayed 166021

 shaping active
         traffic shaping drops 169


!--- Notice that the Tc interval equals 10 ms, !--- CIR equals 64000 BPS, and BC equals 640. 

     
maui-voip-sj#show traffic-shape
Interface  Se0/0.1
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
300           64000     80     640       0          10        80         -



!--- This output is captured on an isolated lab enviroment where !--- the routers are configured with IP RTP Priority instead of LLQ.
 

maui-voip-austin#show frame-relay PVC 100

PVC Statistics for interface Serial0/1 (Frame Relay DTE)

DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/1.1

  input pkts 336           output pkts 474          in bytes 61713
  out bytes 78960          dropped pkts 0           in FECN pkts 0
  in BECN pkts 0           out FECN pkts 0          out BECN pkts 0
  in DE pkts 0             out DE pkts 0
  out bcast pkts 0         out bcast bytes 0         
  PVC create time 1w0d, last time PVC status changed 1w0d
 Current fair queue configuration:   
   Discard      Dynamic       Reserved
   threshold    queue count   queue count
   64            16              2
 Output queue size 0/max total 600/drops 0 
  fragment type end-to-end        fragment size 80
  cir 64000     BC   640      be 0     limit 125    interval 10
  mincir 32000    byte increment 125   BECN response no
  frags 1091      bytes 82880     frags delayed 671      bytes delayed 56000
  shaping inactive
  traffic shaping drops 0
  ip rtp priority parameters 16384 32767 45000


!--- This command displays information of the VoIP dial-peers.
 
      
maui-voip-austin#show dial-peer voice 2
VoiceOverIpPeer2
        information type = voice,
        tag = 2, destination-pattern = `5000',
        answer-address = `', preference=0,
        group = 2, Admin state is up, Operation state is up,
        incoming called-number = `', connections/maximum = 0/unlimited,
        application associated: 
     type = voip, session-target = `ipv4:192.168.10.2',  
        technology prefix:
     ip precedence = 5, UDP checksum = disabled,
         session-protocol = cisco, req-qos = best-effort, 
         acc-qos = best-effort, 
     dtmf-relay = cisco-rtp, 
        fax-rate = voice,   payload size =  20 bytes
     codec = g729r8,    payload size =  20 bytes,
        Expect factor = 10, Icpif = 30,signaling-type = cas,
     VAD = enabled, Poor QOV Trap = disabled, 
        Connect Time = 165830, Charged Units = 0,
        Successful Calls = 30, Failed Calls = 0,
        Accepted Calls = 30, Refused Calls = 0,
        Last Disconnect Cause is "10",
        Last Disconnect Text is "normal call clearing.",
        Last Setup Time = 69134010.

Informazioni correlate

• Accodamento a bassa latenza per Frame Relay
• Classificazione della segnalazione e dei supporti VoIP con DSCP per QoS
• Mostra comandi per Frame Relay Traffic Shaping
• Priorità Frame Relay IP RTP
• Configurazione di Frame Relay e Frame Relay Traffic Shaping
• Configurazione e risoluzione dei problemi di Frame Relay
• Miglioramenti coda Voice over Frame Relay
• Supporto alla tecnologia vocale
• Supporto dei prodotti per le comunicazioni voce e IP
• Risoluzione dei problemi di Cisco IP Telephony
• Supporto tecnico – Cisco Systems