VoIP su Frame Relay con PVC multipoint e assegnazione di priorità

Introduzione

In questo documento viene descritto il traffic shaping e la definizione di priorità per un VoIP (Voice over IP) sulla rete Frame Relay con topologia hub e spoke. La configurazione dell'hub è tale che sono presenti due circuiti virtuali permanenti (PVC), uno per ogni spoke remoto, e sia i dati che la voce vengono inviati sullo stesso PVC. È importante notare che la definizione delle priorità e la frammentazione discusse in questo documento si applicano non solo a questo scenario, ma anche a uno scenario in cui è possibile avere un PVC con voce e dati e un altro con soli dati. I PVC dati devono avere la forma del traffico proprio come i PVC voce e dati. Ciò è dovuto al fatto che quando una singola pipe fisica viene condivisa, in questo caso nell'hub, il ritardo di serializzazione influisce su tutti i dati.

Nella topologia seguente, New York rappresenta il router centrale dell'hub. Raleigh e San Jose rappresentano router remoti connessi all'hub tramite una rete Frame Relay. Ci sono due PVC che si connettono al router di New York. In questo caso, New York non dovrebbe mai inviare più di 64 kbps a Raleigh e allo stesso modo, non dovrebbe mai inviare più di 192 kbps a San Jose perché questo supera il valore CIR (Committed Information Rate) configurato sulla mapclass Frame Relay.

Nella topologia mostrata in questo documento, i router con configurazioni VoIP sono collegati direttamente a un cloud Frame Relay. In alcune topologie, tuttavia, i router abilitati per la voce possono esistere ovunque nella rete, ad eccezione di Cisco AS5300. Per ulteriori informazioni su questo argomento, fare riferimento alla nota fornita. I router vocali possono essere connessi tramite connettività LAN ad altri router connessi alla WAN. È importante notare che se i router voce non sono connessi direttamente a un servizio Frame Relay, tutti i comandi di configurazione della connettività WAN vengono configurati sui router connessi alla WAN e non sui router voce.

Nota:  I router Cisco AS5300 con interfacce seriali ad alta velocità non sono progettati per supportare la connessione dati a una WAN. È necessario usare il Cisco AS5300 come router LAN intermedi con la funzionalità principale per elaborare le chiamate vocali. Per funzionare come connessioni dirette alla WAN, sono necessari router dedicati.

Prerequisiti

Requisiti

Prima di provare la configurazione, verificare che siano soddisfatti i seguenti prerequisiti:

• Conoscenza base e configurazione di Frame Relay Traffic Shaping (FRTS)

• Conoscenza e configurazione di base di VoIP

Componenti usati

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

• Tre router Cisco 3640 con software Cisco IOS® versione 12.3(5) Enterprise Plus

• Quattro telefoni analogici collegati alle porte Foreign Exchange Station (FXS) sugli spoke

• Un PBX collegato a un controller T1 sul router hub

Gli spoke possono essere anche una piattaforma Cisco 2600 o 1750. L'hub può essere una piattaforma Cisco 2600 o 3600 nel caso della voce digitale, ma può anche essere una piattaforma Cisco 1750 se nell'hub è presente solo la voce analogica. Tutte le configurazioni e il traffic shaping devono essere applicati anche ad altre piattaforme.

Nota: anche se il presente documento non è limitato a software specifici, alcuni comandi utilizzati qui non sono disponibili con tutte le versioni del software Cisco IOS. Ad esempio, il comando frame-relay fragment è supportato con IP Plus, ma non con un'immagine IP.

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.

Configurazione di Traffic Shaping e assegnazione di priorità per un VoIP su Frame Relay

Quando si esegue il protocollo VoIP su Frame Relay, è importante che il traffico inviato sul frame rimanga a un livello inferiore o uguale al CIR Frame Relay. Quando è configurato con Frame Relay Traffic Shaping (FRTS), il router non invia traffico superiore al CIR, come mostrato. Se si configura il router per l'esecuzione a una velocità superiore a quella del CIR, è possibile che si verifichino problemi di qualità della voce e la qualità della voce non è garantita quando si eseguono PVC al di sopra del CIR garantito.

Nota: è possibile configurare l'adaptive shaping in modo che un router possa ridurre la velocità di trasmissione a un valore specificato se i pacchetti Frame Relay vengono ricevuti con il bit BECN (Explicit Congestion Notification) impostato all'indietro. Si consiglia tuttavia di non superare il valore CIR del servizio Frame Relay quando vengono trasmessi i pacchetti voce. In questo modo, sarà possibile garantire una qualità e una distribuzione adeguate quando i pacchetti voce in tempo reale verranno inviati attraverso la rete. La configurazione in cui il CIR viene superato è consigliata solo per i PVC dati che non trasmettono traffico vocale.

Nota: prima di poter configurare il router per l'utilizzo del VoIP, è consigliabile valutare attentamente le funzionalità QoS (Quality of Service) del software Cisco IOS. Per ulteriori informazioni sulle funzionalità QoS, fare riferimento a Accodamento, Traffic Shaping, Filtro e frammentazione per la voce.

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

Esempio di rete

Questo documento utilizza l'impostazione di rete mostrata nel diagramma qui:

Configurazioni

Nel documento vengono usate queste configurazioni:

• New York Hub Router

• Cisco 3640 Raleigh

Current configuration:
!
version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname newyork
!
logging buffered 50000 debugging
enable secret < password > [Choose a strong password with 
at least one capital letter, one number, and one special character.]
!
controller T1 2/0
framing esf
linecode b8zs
ds0-group 1 timeslots 1-4 type e&m-wink-start
!
!
interface Serial2/0
 no ip address
 encapsulation frame-relay
 no ip mroute-cache
 frame-relay traffic-shaping

!--- This CLI command enables traffic shaping for both PVCs.

!
interface Serial2/0.1 point-to-point
description Connection to Raleigh PVC
ip address 172.16.120.2 255.255.255.0
  frame-relay interface-dlci 100
  class class-raleigh
!
interface Serial2/0.2 point-to-point
description Connection to San Jose PVC
ip address 172.16.130.2 255.255.255.0
frame-relay interface-dlci 200
  class class-sanjose
!
ip classless
!
map-class frame-relay class-raleigh
 frame-relay cir 64000
 frame-relay bc 640
 frame-relay be 0
 frame-relay mincir 64000
 no frame-relay adaptive-shaping
 frame-relay fair-queue
 frame-relay fragment 80

!--- Recommended fragment size for 10ms delay when carrying voice !--- traffic based on the configured CIR 64000. !--- based on the configured CIR 64000 
 frame-relay ip rtp priority 16384 16383 48

!--- Two calls with g729, no CRTP, at 24 kbps/each. 
 !
map-class frame-relay class-sanjose
 frame-relay cir 192000
 frame-relay bc 1920
 frame-relay be 0
 frame-relay mincir 192000
 no frame-relay adaptive-shaping
 frame-relay fair-queue
 frame-relay fragment 240

!--- This is the recommended fragment size for 10ms delay when carrying voice traffic !--- based on the configured CIR 192000.

frame-relay ip rtp priority 16384 16383 48 

!--- Two calls with G729, no Compressed Real Time Protocol (cRTP), at 24kbpseach. 
!
!
voice-port 2/0:1
!
dial-peer cor custom
!
dial-peer voice 100 pots

!--- Calls to the Public Switched Telephone Network (PSTN). 
 destination-pattern 212.......
prefix 212
port 2/0:1
!
dial-peer voice 200 pots

!--- Calls to the corporate network-four digit extension forwarded. 
destination-pattern 567....
 port 2/0:1
!
dial-peer voice 110 voip

!--- Calls to Raleigh.

destination-pattern 919392....
session target ipv4:172.16.120.1
 ip qos dscp cs5 media
dtmf-relay h245-alphanumeric
!
dial-peer voice 210 voip    
!--- Calls to San Jose. 
destination-pattern 408527....
session target ipv4:172.16.130.1
 ip qos dscp cs5 media
dtmf-relay h245-alphanumeric
!
!
line con 0
 exec-timeout 0 0
 transport input none
line aux 0
line vty 0 4
 no login
!
end  

Il comando ip qos dscp è stato introdotto in IOS versione 12.2(2)T per sostituire il comando ip precedence (dial-peer).

Il comando frame-relay ip rtp priority riserva una coda di priorità rigida per un set di flussi di pacchetti RTP (Real-Time Protocol) che appartengono a un intervallo di porte di destinazione UDP (User Datagram Protocol).

Nota: poiché il comando frame-relay ip rtp priority assegna priorità assoluta rispetto ad altro traffico, usare questo comando con cautela. In caso di congestione, se il traffico supera la larghezza di banda configurata, tutto il traffico in eccesso viene scartato.

Current configuration:
!
version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname raleigh3640a
!

logging buffered 50000 debugging
enable secret < password > [Choose a strong password with at 
least one capital letter, one number, and one special character.]
!
no ip subnet-zero
!
!
!
!
voice-port 1/0/0
!
voice-port 1/0/1
dial-peer voice 1 pots
 destination-pattern 9193924100
port 1/0/0
!
dial-peer voice 2 voip
 destination-pattern 2126789001
  ip qos dscp cs5 media
 dtmf-relay h245-alphanumeric
 session target ipv4: 172.16.120.2 
!

interface Loopback0
 ip address 172.16.125.1 255.255.255.255
 no ip directed-broadcast
!

interface Serial2/0
 no ip address
 encapsulation frame-relay
 frame-relay traffic-shaping
!
interface Serial2/0.1 point-to-point
description Connection to New York
 ip address 172.16.120.1 255.255.255.0

 frame-relay interface-dlci 100
  class fr_class_voip  
!
!
ip classless
no ip http server
!
!
map-class frame-relay fr_class_voip
 frame-relay cir 64000
 frame-relay bc 640
 frame-relay be 0
 frame-relay mincir 64000
 no frame-relay adaptive-shaping
 frame-relay fair-queue
 frame-relay fragment  80


!--- The recommended fragment size for 10ms delay when carrying voice traffic.


!--- based on the configured CIR 64000. 

  frame-relay ip rtp priority 16384 16383 48
!
!
line con 0
 exec-timeout 0 0
 transport input none
line aux 0
line vty 0 4
 no login
!
end

Verifica

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); lo strumento permette di visualizzare un'analisi dell'output del comando show.

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

• show traffic-shape queue: visualizza le informazioni sugli elementi in coda a livello di DLCI (Data-Link Connection Identifier) del circuito virtuale (VC). Questo comando è usato 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 sta utilizzando la coda di priorità. Fare riferimento all'output di esempio fornito.

• show frame-relay pvc [dlci#]: visualizza informazioni quali parametri di traffic shaping, valori di frammentazione e pacchetti ignorati. Fare riferimento all'output di esempio fornito qui e anche alla Guida completa alla configurazione e risoluzione dei problemi di Frame Relay per ulteriori informazioni.

newyork#show frame-relay fragment

interface   dlci   frag-type   frag-size   in-frag   out-frag   dropped-frag
 
Serial1/0.1 100    end-to-end    80          16        20           0 

Serial1/0.2 200    end-to-end    240         12        10           0 

newyork#show traffic-shape  serial 2/0.1
Interface Se2/0.1

     Access    Target   Byte   Sustain   Excess   Interval    Increment    Adapt
VC   List      Rate     Limit  bits/int  bits/int (ms)        (bytes)      Active

100            64000    80     640       0         10          80          -
  

newyork#show traffic-shape queue
Traffic queued in shaping queue on Serial2/0.1 dlci 100
  Queueing strategy: weighted fair
  Queueing Stats: 0/600/64/0 (size/max total/threshold/drops)
     Conversations  0/1/16 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 16 kilobits/sec

Traffic queued in shaping queue on Serial2/0.2 dlci 200
  Queueing strategy: weighted fair
  Queueing Stats: 0/600/64/0 (size/max total/threshold/drops)
    Conversations  0/1/16 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 144 kilobits/sec

newyork#show frame-relay pvc 100

PVC Statistics for interface Serial2/0 (Frame Relay DCE)

DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial2/0.1

input pkts 1078          output pkts 1078         in bytes 157792
out bytes 172284         dropped pkts 0           in pkts dropped 0
out pkts dropped 0                out bytes dropped 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 28        out bcast bytes 8498
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:27:48, last time pvc status changed 00:27:48
Queueing strategy: weighted fair
Current fair queue configuration:
	Discard     Dynamic      Reserved
	threshold   queue count  queue count
		64          16           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  IF_CONG no
frags 2707      bytes 172284    frags delayed 2707      bytes delayed 172284
shaping inactive
traffic shaping drops 0
ip rtp priority parameters 16384 32767 48000

Risoluzione dei problemi

Le informazioni contenute in questa sezione permettono di risolvere i problemi relativi alla configurazione.

Procedura di risoluzione dei problemi

Ecco alcune informazioni e istruzioni utili per risolvere eventuali problemi con questa configurazione:

1. Risolvere i problemi relativi a Frame Relay e QoS implementati per la voce e garantire il corretto funzionamento.

2. Procedere alla risoluzione dei problemi relativi agli errori delle chiamate vocali, se necessario.

   Nota: per informazioni più dettagliate sulla risoluzione dei problemi, fare riferimento a VoIP over Frame Relay con QoS (frammentazione, traffic shaping, priorità LLQ / IP RTP).

Comandi per la risoluzione dei problemi

Lo strumento Output Interpreter (solo utenti registrati) (OIT) supporta alcuni comandi show. Usare l'OIT per visualizzare un'analisi dell'output del comando show.

Nota: consultare le informazioni importanti sui comandi di debug prima di usare i comandi di debug.

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

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

  newyork#debug priority 
  Priority output queueing debugging is on
  newyork#ping 172.16.120.1
  Type escape sequence to abort. 
  Sending 5, 100-byte ICMP Echos to 172.16.120.1, timeout is 2 seconds: 
  !!!!! 
  Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/60 ms 
  newyork# 
  *Mar  1 05:11:24.746: PQ: Serial2/0 output (Pk size/Q 104/2)
  *Mar  1 05:11:24.754: PQ: Serial2/0 output (Pk size/Q 104/2) 
  *Mar  1 05:11:24.810: PQ: Serial2/0 output (Pk size/Q 104/2)
  *Mar  1 05:11:24.818: PQ: Serial2/0 output (Pk size/Q 104/2) 
  *Mar  1 05:11:24.874: PQ: Serial2/0 output (Pk size/Q 104/2) 
  *Mar  1 05:11:24.882: PQ: Serial2/0 output (Pk size/Q 13/0) 
  
  newyork#debug frame-relay fragment interface serial 2/0 100
  This may severely impact network performance.
  You are advised to enable no logging console debug. Continue?[confirm]
  Frame Relay fragment/packet debugging is on
  Displaying fragments/packets on interface Serial2/0 dlci 100 only
  
  *Mar  1 20:58:32.838: Serial1/0.1(o): dlci 100, tx-seq-num 3645, 
  B bit set, frag_hdr 03 B1 9C 3D
  *Mar  1 20:58:32.846: Serial1/0.1(o): dlci 100, tx-seq-num 3646, 
  E bit set, frag_hdr 03 B1 5C 3E
  *Mar  1 20:58:32.890: Serial1/0.1(i): dlci 100, rx-seq-num 17, 
  exp_seq-num 17,B bit set,
  	 frag_hdr 03 B1 80 11
  *Mar  1 20:58:32.894: Serial1/0.1(i): dlci 100, rx-seq-num 18, 
  exp_seq-num 18,E bit set,
  	 frag_hdr 03 B1 40 12

Informazioni correlate

• Mostra comandi per Frame Relay Traffic Shaping
• Priorità Frame Relay IP RTP
• Configurazione e risoluzione dei problemi di Frame Relay
• Frame Relay Traffic Shaping per VoIP e VoFR
• Supporto alla tecnologia vocale
• Supporto ai prodotti voce e Unified Communications
• Risoluzione dei problemi di Cisco IP Telephony
• Documentazione e supporto tecnico – Cisco Systems