Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Convenzioni

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

Esempio di rete

Configurazioni

Verifica

Risoluzione dei problemi

Procedura di risoluzione dei problemi

Comandi per la risoluzione dei problemi

Informazioni correlate

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

New York Hub Router

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.

Cisco 3640 Raleigh

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