Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

Convenciones

Configuración del Modelado y Priorización del Tráfico para un VoIP sobre Frame Relay

Diagrama de la red

Configuraciones

Verificación

Troubleshoot

Procedimiento de Troubleshooting

Comandos para resolución de problemas

Información Relacionada

Introducción

Este documento trata sobre el modelado del tráfico y la priorización para una red de voz sobre IP (VoIP) sobre Frame Relay con topología radial y hub. La configuración del hub es tal que hay dos circuitos virtuales permanentes (PVC), uno para cada radio remoto, y tanto los datos como la voz se envían a través de los mismos PVC. Es importante tener en cuenta que la priorización y fragmentación que se describe en este documento se aplica no sólo a este escenario, sino también a un escenario en el que se puede tener un PVC con voz y datos y otro con sólo datos. Los PVC de datos deben tener forma de tráfico al igual que los PVC de voz y datos. Esto se debe al hecho de que cuando se comparte un único conducto físico, en este caso en el hub, el retraso de serialización afecta a todos los datos.

En la siguiente topología, Nueva York representa el router central del hub. Raleigh y San José representan routers remotos conectados al hub a través de una red Frame Relay. Hay dos PVC que se conectan al router de Nueva York. En este caso, Nueva York nunca debería enviar más de 64 kbps a Raleigh y, de la misma manera, nunca debería enviar más de 192 kbps a San José porque esto excede la Velocidad de información comprometida (CIR) configurada en la clase de asignación Frame Relay.

En la topología mostrada en este documento, los routers con configuraciones VoIP están conectados directamente a una nube Frame Relay. Sin embargo, en algunas topologías, los routers habilitados para voz pueden existir en cualquier lugar de la red, con la excepción del Cisco AS5300. Para obtener más información al respecto, consulte la nota proporcionada. Los routers de voz se pueden conectar a través de la conectividad LAN a otros routers conectados a la WAN. Esto es importante de tener en cuenta porque si los routers de voz no están conectados directamente a un servicio Frame Relay, todos los comandos de configuración de conectividad WAN se configuran en aquellos routers que están conectados a la WAN, y no en los routers de voz.

Nota: Los routers Cisco AS5300 con interfaces seriales de alta velocidad no están diseñados para soportar la conexión de datos a una WAN. Debe utilizar los Cisco AS5300 como routers LAN intermedios con la funcionalidad principal para procesar las llamadas de voz. Necesita routers dedicados para actuar como conexiones directas a la WAN.

Prerequisites

Requirements

Antes de intentar esta configuración, asegúrese de cumplir estos requisitos previos:

- Comprensión y configuración básicas del modelado del tráfico de Frame Relay (FRTS)

- Comprensión y configuración básicas de VoIP

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

- Tres routers Cisco 3640 con Cisco IOS® Software Release 12.3(5) Enterprise Plus

- Cuatro teléfonos analógicos conectados a puertos de estación de intercambio remoto (FXS) en radios

- Un PBX conectado a un controlador T1 en el router hub

Los spokes también pueden ser una plataforma Cisco 2600 o 1750. El hub puede ser una plataforma Cisco 2600 o 3600 en el caso de la voz digital, pero también puede ser una plataforma Cisco 1750 si sólo existe voz analógica en el hub. Todas las configuraciones y el modelado del tráfico se aplican también a otras plataformas.

Nota: Aunque este documento no se limita a software específico, algunos de los comandos que se utilizan aquí no están disponibles con todas las versiones de Cisco IOS Software. Por ejemplo, el comando frame-relay fragment se soporta con IP Plus pero no con una imagen IP.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Configuración del Modelado y Priorización del Tráfico para un VoIP sobre Frame Relay

Cuando se ejecuta VoIP sobre Frame Relay, es importante que el tráfico enviado a través de la trama permanezca en un nivel inferior o igual al CIR de Frame Relay. El router no envía tráfico que exceda el CIR cuando se configura con Frame Relay Traffic Shaping (FRTS) como se muestra. Si configura el router para que se ejecute a una velocidad mayor que la CIR , puede experimentar problemas de calidad de voz, y la calidad de voz no está garantizada cuando ejecuta PVC por encima de la CIR garantizada.

Nota: Es posible configurar el modelado adaptable para permitir que un router reduzca la velocidad de transmisión a un valor especificado si se reciben paquetes de Frame Relay con el conjunto de bits de notificación explícita de congestión (BECN). Sin embargo, se le notifica que las velocidades de tráfico no deben exceder el CIR del servicio Frame Relay cuando se transmiten los paquetes de voz. Esto es para asegurar la calidad y entrega adecuadas cuando se envían paquetes de voz en tiempo real a través de la red. La configuración en la que se excede el CIR sólo se recomienda para los PVC de datos que no transportan tráfico de voz.

Nota: Además, antes de poder configurar el router para que utilice VoIP, es mejor que comprenda las funciones de calidad de servicio (QoS) del software Cisco IOS. Para obtener más información sobre las funciones de QoS, consulte Colocación en Cola, Modelado de tráfico y Filtrado y Fragmentación para voz.

Nota: Use la Command Lookup Tool (sólo clientes registrados) para obtener más información sobre los comandos utilizados en este documento.

Diagrama de la red

Este documento utiliza la configuración de red que se muestra en el diagrama aquí:

Configuraciones

En este documento, se utilizan estas configuraciones:

- Router hub de Nueva York

- Cisco 3640 Raleigh

Router hub de Nueva York

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

El comando ip qos dscp se introdujo en la versión 12.2(2)T del IOS para reemplazar el comando ip precedence (dial-peer).

El comando frame-relay ip rtp priority reserva una cola de prioridad estricta para un conjunto de flujos de paquetes de protocolo en tiempo real (RTP) que pertenece a un rango de puertos de destino de protocolo de datagramas de usuario (UDP).

Nota: Debido a que el comando frame-relay ip rtp priority da prioridad absoluta sobre otro tráfico, utilice este comando con cuidado. En caso de congestión, si el tráfico excede el ancho de banda configurado, se descarta todo el tráfico excedente.

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

Verificación

Esta sección proporciona información que puede utilizar para confirmar que su configuración funciona correctamente.

La herramienta Output Interpreter (sólo para clientes registrados) permite utilizar algunos comandos “show” y ver un análisis del resultado de estos comandos.

- show frame-relay fragment —Muestra información sobre la fragmentación de Frame Relay que se produce en el router de Cisco.

- show traffic-shape queue : muestra información sobre los elementos en cola en el nivel de identificador de conexión de enlace de datos (DLCI) del circuito virtual (VC). Este comando se utiliza para verificar el funcionamiento de la prioridad IP RTP sobre Frame Relay. Cuando el link está congestionado, los flujos de voz se identifican con un peso de cero. Esto indica que el flujo de voz está utilizando la cola de prioridad. Consulte el ejemplo de salida proporcionado.

- show frame-relay pvc [dlci#]—Muestra información como parámetros de modelado de tráfico, valores de fragmentación y paquetes perdidos. Refiérase al ejemplo de salida proporcionado aquí y también consulte Guía Integral para Configurar y Resolver Problemas de Frame Relay para obtener más información.

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

Troubleshoot

En esta sección encontrará información que puede utilizar para solucionar problemas de configuración.

Procedimiento de Troubleshooting

Aquí encontrará información e instrucciones para la resolución de problemas relevantes para esta configuración:

1. Solucione los problemas de Frame Relay y QoS implementados para voz y asegúrese de su funcionamiento correcto.

2. Continúe con la resolución de problemas de fallas de llamadas de voz según sea necesario.

Nota: Para obtener información más detallada sobre la solución de problemas, consulte VoIP sobre Frame Relay con QoS (fragmentación, modelado de tráfico, prioridad LLQ / IP RTP).

Comandos para resolución de problemas

La herramienta Output Interpreter Tool (clientes registrados solamente) (OIT) soporta ciertos comandos show. Utilice la OIT para ver un análisis del resultado del comando show.

Nota: Consulte Información Importante sobre Comandos Debug antes de utilizar los comandos debug.

- debug priority : muestra los eventos de cola de prioridad (PQ) y muestra si se produce una caída en esta cola. Para obtener más información, consulte ppSolución de problemas de caídas de salidas con cola prioritaria.

- debug frame-relay fragment —Muestra el evento o los mensajes de error relacionados con la fragmentación de Frame Relay. Este comando sólo se habilita en el nivel de PVC en la interfaz seleccionada.

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

Información Relacionada

- Comandos show para el modelado de tráfico de retransmisión de tramas

- Prioridad IP RTP de Frame Relay

- Configuración y resolución de problemas del Frame Relay

- Modelado del tráfico de retransmisión de tramas para VoIP y VoFR

- Soporte de tecnología de voz

- Soporte de Productos de Voice and Unified Communications

- Troubleshooting de Cisco IP Telephony

- Soporte Técnico y Documentación - Cisco Systems