Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

Convenciones

Pautas de diseño de QoS para VoIP over Frame Relay

Prioridad estricta para tráfico de voz (LLQ o prioridad IP RTP)

FRTS para voz

Fragmentación (FRF.12)

‘Reducción del ancho de banda’

Configurar

LLQ

Prioridad IP RTP

Modelado del tráfico para voz

Fragmentación (FRF.12)

Diagrama de la red

Configuraciones

Verificación y resolución de problemas

Comandos de prioridad LLQ / IP RTP

Comandos de fragmentación

Frame Relay / Comandos de interfaz

Problemas conocidos

Ejemplo de resultado de los comandos show y debug

Información Relacionada

Introducción

Este documento muestra voz sobre "IP" (VoIP) sobre una configuración de muestra de red Frame Relay con Calidad de Servicio (QoS). Este documento comprende información técnica previa sobre las funciones configuradas, pautas de diseño y estrategias básicas de verificación y resolución de problemas.

Es importante tener en cuenta que la configuración en este documento tiene dos routers de voz que están conectados a la red Frame Relay. Sin embargo, en muchas topologías, los routers habilitados para voz pueden existir en cualquier lugar. Normalmente, los routers de voz utilizan conectividad LAN a otros routers que están conectados a la WAN. Esto es importante porque si los routers de voz no están conectados directamente a la red Frame Relay, todos los comandos de configuración WAN deben configurarse en los routers conectados a la WAN, y no en los routers de voz, como se muestra en las configuraciones de este documento.

Prerequisites

Requirements

No hay requisitos específicos para este documento.

Componentes Utilizados

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

- Router Cisco 3640 con software Cisco IOS® versión 12.2.6a (Enterprise Plus)

- Router Cisco 2621 con software Cisco IOS versión 12.2.6a (Enterprise Plus)

- Cola de latencia baja (LLQ) en los circuitos virtuales permanentes (PVC) de Frame Relay. Esto se introduce en la versión 12.1.2(2)T del software del IOS de Cisco.

- Prioridad de protocolo de transporte en tiempo real (RTP) IP de Frame Relay que se introduce en la versión 12.0(7)T del software del IOS de Cisco.

- Fragmentación de Frame Relay Forum (FRF).12 introducida en Cisco IOS Software Release 12.0(4)T.

- Las versiones del software Cisco IOS posteriores a 12.0.5T contienen mejoras significativas en el rendimiento para RTP comprimido (cRTP).

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

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Pautas de diseño de QoS para VoIP over Frame Relay

Existen dos requisitos básicos para una buena calidad de voz:

- Mínimo retardo de extremo a extremo y prevención de fluctuación (variación de retardo).

- Requisitos de ancho de banda de link optimizados y diseñados adecuadamente.

Para garantizar los requisitos antes mencionados, utilice estas directrices:

- Prioridad estricta para LLQ de tráfico de voz o Prioridad IP RTP

- Modelado del tráfico de retransmisión de tramas (FRTS) para voz

- Fragmentación FRF.12

- ‘Reducción del ancho de banda’

Prioridad estricta para tráfico de voz (LLQ o prioridad IP RTP)

Hay dos métodos principales para proporcionar una prioridad estricta para el tráfico de voz:

- Prioridad IP RTP (también denominada Cola prioritaria/Colocación en cola equilibrada ponderada [PQ/WFQ])

- LLQ (también se lo llama PQ / Class Based Weighted Fair Queuing (PQ/CBWFQ))

Prioridad IP RTP

La prioridad RTP IP de Frame Relay crea una cola de prioridad estricta en un PVC de Frame Relay para un conjunto de flujos de paquetes RTP que pertenecen a un rango de puertos de destino de protocolo de datagramas de usuario (UDP). Mientras que los puertos reales utilizados se negocian dinámicamente entre dispositivos finales o gateways, todos los productos VoIP de Cisco utilizan el mismo rango de puertos UDP (16384 a 32767). Una vez que el router reconoce el tráfico VoIP, lo coloca en la cola de prioridad (PQ) estricta. Cuando la PQ está vacía, las otras colas se procesan según la WFQ estándar. La prioridad IP RTP no se activa hasta que exista congestión en la interfaz. Esta imagen ilustra el funcionamiento de IP RTP Priority:

Nota: La prioridad IP RTP permite reventar la PQ cuando hay ancho de banda disponible en la cola predeterminada (WFQ). Sin embargo, controla estrictamente el contenido PQ cuando hay congestión en la interfaz.

LLQ

LLQ es una función que proporciona un estricto PQ a CBWFQ. LLQ habilita una única cola prioritaria estricta dentro de CBWFQ a nivel de clase. Con LLQ, los datos sensibles al retardo (en la PQ) se quitan de la cola y se envían primero. En VoIP con implementación de LLQ, el tráfico de voz se ubica en la cola prioritaria estricta.

La PQ es controlada para garantizar que las colas justas no se saturen de ancho de banda. Cuando configure la PQ, especifique en Kbps, la cantidad máxima de ancho de banda disponible para esa PQ. Cuando la interfaz se encuentra congestionada, se mantiene PQ hasta que la carga alcanza el valor configurado en Kbps en la sentencia de prioridad. El exceso de tráfico se rechaza para evitar que la función legacy priority-group de Cisco deje de alimentar las colas de menor prioridad.

Nota: Con LLQ para Frame Relay, las colas se configuran por PVC. Cada PVC tiene una cola prioritaria y una cantidad de colas justas asignadas.

Este método es más complejo y flexible que prioridad IP RTP. La elección entre los métodos debe basarse en los patrones de tráfico de su red real y sus necesidades.

LLQ vs. prioridad RTP IP

Esta tabla resume las principales diferencias entre LLQ e IP RTP Priority y proporciona pautas sobre cuándo utilizar cada método.

LLQ

Prioridad IP RTP

Coincidencia del tráfico de voz según:

- Listas de acceso. Por ejemplo, el rango de los puertos UDP, direcciones de los hosts, campos de Tipo de servicio (ToS) de encabezado IP [como la precedencia IP, el Punto de código de servicios diferenciados (DSCP)].

- Rango de puerto IP RTP.

- Campos de IP ToS: Precedencia IP o DSCP.

- Protocolos e interfaces de entrada.

- Todos los criterios de concordancia válidos usados en CBWFQ.

Ventajas:

- Más flexibilidad sobre cómo se compara y dirige el tráfico al PQ estricto y CBWFQ.

- Puede configurar clases adicionales para garantizar el ancho de banda para otro tipo de tráfico como el video y la señalización VoIP.

Desventajas:
Configuración compleja.

Coincidencia del tráfico de voz según:

- Basado en el rango de puerto RTP/UDP: 16384-32767

Ventajas:
Configuración simple Desventajas:

- Tráfico (Señalización VoIP) del Protocolo de control de tiempo real (RTCP) servido en cola WFQ.
Nota: El protocolo RTP utiliza RTCP para controlar la entrega de paquetes RTP. Mientras que los puertos RTP utilizan números pares, los puertos RTCP utilizan números impares en el rango de 16384-32767. La prioridad IP RTP coloca puertos RTP en la PQ, mientras que los puertos RTCP se atienden en la WFQ predeterminada.

- Sirve al tráfico VoIP en la PQ. Sin embargo, cualquier otro tráfico que necesite un tratamiento preferencial y garantía de ancho de banda se atiende en WFQ. Mientras WFQ puede diferenciar flujos con pesos (basados en la precedencia IP), no puede asegurar una garantía de ancho de banda para ningún flujo.

Pautas:

- La elección entre ellos debe basarse en los patrones de tráfico de su red real y en sus necesidades reales.

- Si necesita proporcionar una prioridad estricta al tráfico de voz y se puede tratar otro tráfico como un solo tipo (datos), la prioridad IP RTP realiza un buen trabajo para su red con una configuración sencilla.

- Si planea dar prioridad al tráfico de voz en función de otros criterios que no sean los puertos UDP. Por ejemplo, Comportamiento por salto (PHB) de Servicios diferenciados (DiffServ) y LLQ.

FRTS para voz

FRTS proporciona parámetros que son útiles para administrar la congestión del tráfico de red. FRTS elimina los cuellos de botella en redes de Frame Relay con conexiones de alta velocidad con el sitio central y conexiones de velocidad baja con las páginas web de las sucursales. Puede configurar los valores de límite de velocidad de forma tal que se limite la velocidad a la que se envía información desde el circuito virtual (VC) en el sitio central.

Estas definiciones están relacionadas con FRTS:

- Velocidad de información comprometida (CIR)—La velocidad (en bits por segundo) que garantiza el proveedor de Frame Relay para la transferencia de datos. Los valores CIR son establecidos por el proveedor de servicios de retransmisión de tramas y configurados por el usuario en el router.

Nota: La velocidad de acceso de puerto/interfaz puede ser mayor que CIR. La tasa se promedia a lo largo de un período de tiempo de intervalo de medición de velocidad comprometida (Tc).

- Ráfaga comprometida (Bc): número máximo de bits que la red de Frame Relay se compromete a transferir a través de un Tc. Tc = Bc / CIR.

- Ráfaga excesiva (Be): número máximo de bits no comprometidos que el switch de Frame Relay intenta transferir más allá de la CIR sobre la Tc.

- Intervalo de medición de velocidad comprometida (Tc): intervalo de tiempo sobre el que se transmiten los bits Bc o (Bc+ Be). Tc se calcula como Tc = Bc / CIR. El valor Tc no se configura directamente en los routers Cisco. Se calcula luego de configurar los valores Bc y CIR. El Tc no puede exceder los 125 ms.

- Notificación de congestión explícita (BECN): bit en el encabezado de trama de Frame Relay que indica congestión en la red. Cuando un switch Frame Relay reconoce la congestión, configura el bit BECN en las tramas destinadas al router de origen e indica al router que reduzca la velocidad de transmisión.

La configuración de FRTS para el tráfico de voz es diferente de la del modelado de tráfico sólo para datos. Al configurar FRTS para la calidad de voz, se hacen concesiones con los parámetros del tráfico de datos. Para obtener más información sobre estas restricciones, consulte la sección Fragmentación (FRF.12) de este documento.

Fragmentación (FRF.12)

Un gran desafío en la integración de voz y datos es controlar el retardo máximo unidireccional de extremo a extremo para el tráfico sensible al tiempo, como el de voz. Para una buena calidad de voz, este retraso debe ser inferior a 150 ms. Una parte importante de este retraso es el retraso de serialización en la interfaz. Cisco recomienda que sea de 10 ms y que no exceda de 20 ms. El retraso de serialización es el tiempo real que transcurre cuando ubican los bits en una interfaz.

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

Por ejemplo, un paquete de 1500 bytes tarda 214 ms en abandonar el router en un link de 56 Kbps. Si se envía un paquete de datos en tiempo no real de 1500 bytes, los paquetes de datos en tiempo real (voz) se ponen en cola hasta que se transmite el paquete de datos de gran tamaño. Este retraso es inaceptable para el tráfico de voz. Si los paquetes de datos que no son en tiempo real son fragmentados en tramas más pequeñas, éstos son entrelazados con tramas (de voz) en tiempo real. De este modo, tanto la trama de datos como la de voz pueden mantenerse juntas en links de baja velocidad sin generar demasiado retardo al tráfico de voz en tiempo real.

Para obtener más información sobre la fragmentación, consulte Fragmentación de Frame Relay para voz.

Nota: En los casos en que tiene una conexión T1 media dedicada (768 kbps), probablemente no necesite una función de fragmentación. Sin embargo, aún necesita un mecanismo de QoS (IP RTP Priority o LLQ, en este caso). La T1 media o las velocidades mayores proporcionan un ancho de banda suficiente que permite que los paquetes de voz entren en la cola o salgan de ella en el rango recomendado de retraso de serialización (10 ms, no más de 20 ms). Además, probablemente no necesite cRTP, que ayuda a ahorrar ancho de banda al comprimir los encabezados RTP IP, en el caso de un T1 completo.

‘Reducción del ancho de banda’

cRTP

Basada en RFC 2508 , la función cRTP comprime el encabezado del paquete IP/UDP/RTP de 40 bytes a 2 o 4 bytes. Esto reduce el consumo de ancho de banda innecesario. Es un esquema de compresión salto a salto. Por lo tanto, cRTP se debe configurar en ambos extremos del link, a menos que se configure la opción pasiva.

Nota: cRTP no es necesario para garantizar una buena calidad de voz. Es una función que reduce el consumo del ancho de banda. Configure cRTP una vez que se hayan cumplido con las demás condiciones y la calidad de voz sea satisfactoria. Este procedimiento ahorra tiempo de resolución de problemas porque aísla posibles problemas de cRTP.

Supervise el uso de la CPU del router. Desactive cRTP si supera el 75%. A velocidades de link más altas, el ahorro de ancho de banda de cRTP podría verse potencialmente superado por la carga adicional de la CPU. Cisco solo recomienda utilizar cRTP con links inferiores a 768 Kbps, a menos que el router se ejecute a una tasa de utilización de CPU baja.

Nota: A falta de un estándar, se desarrolló cRTP para Frame Relay en la encapsulación propiedad de Cisco. Por lo tanto, no funciona con la encapsulación del Equipo de tareas de ingeniería de Internet (IETF) de Frame Relay. Recientemente, se finalizó FRF.20 para hacer posible la compresión de encabezado RTP en la encapsulación IETF. Sin embargo, desde la fecha de la última actualización de este documento (mayo de 2002), no se admite FRF.20.

Para obtener más información, consulte el Protocolo de transporte en tiempo real comprimido.

Selección de codificador/decodificador (códec)

Utilice códecs de baja velocidad de bits en los tramos de llamadas de VoIP. G.729 (8 Kbps) es el códec predeterminado para el par de marcado VoIP.

Nota: Aunque la multifrecuencia de tono dual (DTMF) suele transportarse con precisión cuando se utilizan códecs de voz de alta velocidad de bits (como G.711), los códecs de baja velocidad de bits (como G.729 y G.723.1) están altamente optimizados para los patrones de voz y tienden a distorsionar los tonos DTMF. Este enfoque puede ocasionar problemas de acceso a los sistemas de respuesta de voz interactiva (IVR). El comando dtmf relay resuelve el problema de la distorsión de DTMF. Transporta tonos DTMF fuera de banda o separados del flujo de voz codificado. Si utiliza códecs de baja velocidad de bits (G.729, G.723), active el comando dtmf relay bajo el dial-peer VoIP.

Detección de actividad de voz (VAD) habilitada

Una conversación típica podría contener entre un 35% y un 50% de silencio. Los paquetes de silencio se eliminan cuando se utiliza VAD. Para la planificación del ancho de banda de VoIP, suponga que VAD reduce el ancho de banda en un 35%. VAD está configurado de forma predeterminado en pares de marcado VoIP.

Configurar

En esta sección encontrará la información para configurar las funciones descritas en este documento.

Nota: Para encontrar información adicional sobre los comandos usados en este documento, utilice la Command Lookup Tool (sólo clientes registrados) .

LLQ

Utilice este procedimiento para configurar LLQ:

1. Cree una correspondencia de clase para el tráfico VoIP y defina el criterio de concordancia.

Estos comandos explican cómo completar esta tarea:

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.

Estas listas de acceso también se utilizan para hacer coincidir el tráfico de voz con el 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.

Estos son otros métodos coincidentes que se pueden utilizar en lugar de los comandos access-group:

- Con Cisco IOS Software Release 12.1.2.T y versiones posteriores, la funcionalidad IP RTP Priority se implementa para LLQ. Esta función coincide con el contenido de la clase de prioridad que observa los puertos UDP configurados. Está sujeto a la limitación de servir solamente a los puertos pares en la PQ.

class-map voice

match ip rtp 16384 16383

- Estos dos métodos funcionan bajo la suposición de que los paquetes VoIP se marcan en los hosts de origen o coinciden y se marcan en el router antes de que se aplique la operación LLQ saliente:

class-map voice

match ip precedence 5

O

class-map voice

match ip dscp ef

Nota: En Cisco IOS Software Release 12.2.2T y posteriores, los pares de marcado VoIP pueden marcar los paquetes de portador de voz y señalización antes de la operación LLQ. Esto permite una forma escalable de marcar y hacer coincidir los paquetes VoIP a través de los valores de código DSCP para LLQ. Para más información consulte Clasificación de señalización de VoIP y medios con DSCP para QoS.

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

2. Cree un mapa de clase para la señalización VoIP y defina un criterio de coincidencia (opcional).

Utilice estos comandos para completar esta tarea:

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: Las llamadas VoIP se pueden establecer mediante H.323, protocolo de inicio de sesión (SIP), protocolo de control de gateway de medios (MGCP) o protocolo de control de llamadas Skinny (SCCP), protocolo propietario que utiliza Cisco Call Manager. En el ejemplo anterior se asume H.323 Fast Connect. Esta lista sirve como referencia para los puertos que utilizan los canales de señalización y control VoIP:

- H.323/H.225 = TCP 1720

- H.323/H.245 = TCP 11xxx (Conexión estándar)

- H.323/H.245 = TCP 1720 (Conexión rápida)

- H.323/H.225 RAS = UDP 1718 (To GateKeeper)

- SCCP = TCP 2000-2002 (núcleo de CM)

- ICCP = TCP 8001-8002 (CM Encore)

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

- SIP= UDP 5060, TCP 5060 (configurable)

3. Cree un mapa de política y asócielo a los mapas de clase de VoIP.

El propósito del policy map es definir cómo se comparten o asignan los recursos de link a las diferentes clases de mapa. Utilice estos comandos para completar esta tarea:

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: Aunque es posible poner en cola varios tipos de tráfico en tiempo real en la PQ, Cisco recomienda que se dirija solamente el tráfico de voz a ella. El tráfico en tiempo real, como el vídeo, introduce potencialmente variaciones en el retardo (la cola PQ es una cola primero en entrar primero en salir (FIFO)). El tráfico de voz requiere que la demora sea invariable para evitar la fluctuación.

Nota: La suma de los valores para las sentencias priority y bandwidth debe ser menor o igual a minCIR para el PVC. De lo contrario, el comando service-policy no se puede asignar al link. minCIR es la mitad de CIR de forma predeterminada. Para ver los mensajes de error, asegúrese de que el comando logging console esté habilitado para el acceso a la consola y el comando terminal monitor esté habilitado para el acceso Telnet.

Para obtener más información acerca de los comandos de ancho de banda y de prioridad, vea Comparación de los comandos de ancho de banda y de prioridad de una política de servicios de QoS.

4. Para habilitar LLQ, implemente el mapa de política en la interfaz WAN de salida.

Utilice estos comandos para habilitar 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.

Prioridad IP RTP

Si no utiliza LLQ, utilice estas pautas:

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

port-range  bandwidth

- starting-rtp-port—El número del puerto de inicio UDP. El número de puerto menor al cual se envían los paquetes. Para VOIP, configure este valor en 16384.

- port-range—El rango de puertos de destino UDP. El número, agregado al start-rtp-port, arroja el número de puerto UDP más alto. Para VOIP, configure este valor en 16383.

- bandwidth: ancho de banda máximo permitido en kbps para la cola de prioridad. Establezca este número en función del número de llamadas simultáneas, agregando el ancho de banda de cada llamada por llamada que admite el sistema.

Configuración de ejemplo:

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

Modelado del tráfico para voz

Utilice estas pautas cuando configure el modelado de tráfico para voz:

- No exceda la CIR del PVC.

- Desactive el modelado adaptable de Frame Relay.

- Configure el valor Bc como bajo para que el Tc (intervalo de formación) sea de 10 ms (Tc = Bc/CIR). Configure el valor Bc para forzar el valor Tc deseado.

- Configure el valor de Be en 0.

Para obtener más información sobre estas pautas, refiérase a Modelado del Tráfico de Frame Relay para VoIP y VoFR.

Nota: Algunos clientes utilizan PVC separados para datos y voz. Si tiene dos PVC separados y desea reventar en el PVC de datos mientras permanece en CIR o por debajo para el PVC de voz, la calidad de voz todavía sufre ya que estos PVC utilizan la misma interfaz física. En estos casos, el proveedor de Frame Relay, así como el router, necesitan priorizar el PVC de voz. Esto último se puede realizar mediante cola prioritaria de interfaz PVC (PIPQ) disponible a partir de la versión 12.1(1)T del software del IOS de Cisco.

Fragmentación (FRF.12)

Active la fragmentación para links de velocidad baja (menos de 768 kbps). Configure el tamaño del fragmento para que los paquetes de voz no estén fragmentados y no experimenten un retraso de serialización superior a 20 ms. Establezca el tamaño de fragmentación en función de la velocidad de puerto más baja entre los routers. Por ejemplo, si hay una topología de Frame Relay de eje de conexión y radio donde el hub tiene una velocidad T1 y los routers remotos tienen velocidades de puerto de 64 K, el tamaño de fragmentación debe configurarse para la velocidad de 64 K en ambos routers. Cualquier otro PVC que comparta la misma interfaz física necesita configurar la fragmentación al tamaño utilizado por el PVC de voz. Utilice este gráfico para determinar los valores de tamaño de fragmentación.

Velocidad más baja del link en el trayecto.

Tamaño de fragmentación recomendada (para Serialización 10 ms)

56 Kbps

70 bytes

64 Kbps

80 bytes

128 Kbps

160 bytes

256 Kbps

320 bytes

512 Kbps

640 bytes

768 Kbps

1000 bytes

1536 Kbps

1600 bytes

Configuración de ejemplo:

map-class frame-relay VoIPovFR

!--- Some output is omitted.

frame-relay fragment 80

Nota: Para 1536 Kbps, técnicamente no se necesita fragmentación. Sin embargo, la fragmentación es necesaria para habilitar el sistema de cola FIFO dual para garantizar la calidad de voz. Un tamaño de fragmento de 1600 bytes habilita el FIFO dual. Sin embargo, dado que 1600 bytes es superior a la unidad de transmisión máxima (MTU) típica de la interfaz serial, los paquetes de datos grandes no se fragmentan.

Diagrama de la red

Este documento utiliza la configuración de red que se muestra en este diagrama:

Configuraciones

Este documento usa las configuraciones detalladas aquí:

- maui-voip-sj (Cisco 3640)

- maui-voip-austin (Cisco 3640)

maui-voip-sj (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

maui-voip-austin (Cisco 3640)

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

Verificación y resolución de problemas

En esta sección encontrará información que le permitirá confirmar que su configuración funcione correctamente.

La herramienta Output Interpreter Tool (solo para clientes registrados) soporta ciertos comandos show. Esto le permitirá ver un análisis del resultado del comando show.

Comandos de prioridad LLQ / IP RTP

Estos comandos show y debug le ayudan a verificar sus configuraciones de prioridad de LLQ e IP RTP.

- show policy-map interface serial interface# —Este comando es útil para ver la operación LLQ y cualquier pérdida en la PQ. Para obtener más información sobre los diversos campos de este comando, consulte Cómo funcionan los contadores de paquetes en los resultados del comando show policy-map interface.

- show policy-map policy_map_name—Muestra información sobre la configuración del mapa de políticas.

- show queue interface-type interface-number—Enumera la configuración de colas justas y las estadísticas para una interfaz en particular.

- debug priority—Muestra eventos PQ y señala si ocurren interrupciones en esta cola. Para obtener más información, consulte ppSolución de problemas de caídas de salidas con cola prioritaria.

- show class-map class_name—Muestra información sobre la configuración de mapa de clases.

- show call active voice: verifica la pérdida de paquetes en el nivel DSP.

- show frame-relay ip rtp header-compression—Muestra las estadísticas de compresión del encabezado RTP.

Comandos de fragmentación

Utilice estos comandos debug y show para verificar y resolver problemas de configuraciones de fragmentación.

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

- debug frame-relay fragment: muestra los mensajes de evento o error relacionados con la fragmentación de Frame Relay. Sólo se activa en el nivel de PVC en la interfaz seleccionada.

Frame Relay / Comandos de interfaz

Utilice estos comandos show para verificar y resolver problemas de las configuraciones de Frame Relay/Interface.

- show traffic-shape queue interface —Muestra información sobre los elementos en cola en el nivel de identificador de conexión de link de datos de VC (DLCI). Se utiliza para verificar el funcionamiento de IP RTP Priority over 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 utiliza la PQ. Vea aquí el ejemplo de salida.

- show traffic-shape — Muestra información como los valores configurados de Tc, Bc, Be y CIR. Vea el ejemplo de salida.

- show frame-relay pvc dlci-# —Muestra información como parámetros de modelado de tráfico, valores de fragmentación y paquetes perdidos. Vea el ejemplo de salida. Consulte también Solución de problemas de Frame Relay.

Problemas conocidos

Se identificó un error de funcionamiento con LLQ por VC donde la PQ estaba regulada de manera estricta, incluso cuando no existe una congestión en la interfaz. Ese error se ha corregido y ahora los paquetes de voz no conformes se descartan sólo si se produce una congestión en el VC. Esto hace que el comportamiento de LLQ por VC sea el mismo que otras interfaces que utilizan LLQ. Este comportamiento se cambió con Cisco IOS Software Release 12.2(3) y posteriores.

Ejemplo de resultado de los comandos show y debug

Este es el ejemplo de resultado del comando show y debug utilizado para la verificación y solución de problemas.

!--- 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.

Información Relacionada

- Cola de tiempo de latencia bajo para Frame Relay

- Clasificación de señalización y medios de VoIP con DSCP para QoS

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

- Prioridad IP RTP de Frame Relay

- Configuración de Frame Relay y diseño del tráfico de Frame Relay

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

- Mejora de almacenamiento en cola para voz sobre Frame Relay

- Soporte de tecnología de voz

- Soporte para productos de comunicaciones IP y por voz

- Troubleshooting de Cisco IP Telephony

- Soporte Técnico - Cisco Systems