VoIP sobre Frame Relay con calidad de servicio (fragmentación, diseño de tráfico y prioridad LLQ / IP RTP)

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.

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.

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)

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

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

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

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

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


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


  class class-default
  fair-queue


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

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

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

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

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

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

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

frame-relay cir 64000
 frame-relay bc 640

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

frame-relay be 0
 frame-relay mincir 64000

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

service-policy output VOICE-POLICY

!--- Enables LLQ on the PVC.

frame-relay fragment 80

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

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

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

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

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

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