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.
No hay requisitos específicos para este documento.
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.
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
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
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))
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 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.
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:
|
Coincidencia del tráfico de voz según:
|
Pautas:
|
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.
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.
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.
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.
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.
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) .
Utilice este procedimiento para configurar LLQ:
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 ?
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)
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.
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.
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
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.
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.
Este documento utiliza la configuración de red que se muestra en este diagrama:
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 |
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.
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.
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.
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.
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.
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.