Este ejemplo de configuración estudia una VoIP con Protocolo punto a punto (PPP) en una configuración de línea alquilada con ancho de banda bajo. 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.
Nota: Es importante tener en cuenta que en la siguiente configuración, los dos routers están conectados adosados sobre una línea arrendada. Sin embargo, en la mayoría de las topologías, los routers activados por voz pueden existir en cualquier lugar. Usualmente, los routers de voz utilizan conectividad LAN con otros routers conectados a la WAN (en otras palabras, una línea PPP alquilada). Es importante porque si su router de voz no está conectado directamente vía PPP a una línea arrendada, todos los comandos de configuración WAN deben ser configurados en los routers conectados a la WAN, y no en los routers de voz, como muestran las siguientes configuraciones.
No hay requisitos específicos para este documento.
Las configuraciones presentadas en este documento se probaron con este equipo:
Dos Cisco 3640 con el IOS® de Cisco versión 12.2.6a (IP Plus)
La prioridad RTP de IP fue introducida en la versión 12.0(5)T del Cisco IOS.
Se presentó el LLQ en la versión 12.0(7)T del IOS de Cisco.
LFI se presentó en la Versión 11.3 del IOS de Cisco.
Las versiones de Cisco IOS posteriores a 12.0.5T contienen mejoras significativas en el rendimiento para cRTP.
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
Esta sección proporciona pautas de diseño para configurar VoIP sobre líneas arrendadas PPP (con énfasis en links de baja velocidad). 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 anteriores, deben seguirse varias directrices importantes:
Pauta | Descripción |
---|---|
Prioridad estricta para tráfico de voz (prioridad IP RTP o LLQ) | Método para proporcionar prioridad estricta al tráfico de voz. |
Fragmentación y entrelazado de link (LFI) | Puede ser un requerimiento obligatorio para links de baja velocidad. |
Compresión RTP | No se requiere para proporcionar una buena calidad de voz, pero reduce el consumo de ancho de banda de la llamada. El consejo general con respecto a la compresión RTP es aplicarla después de tener una configuración en funcionamiento con buena calidad de voz (simplifica la resolución de problemas). |
Control de admisión de la llamada (CAC) | No se trata en este documento. CAC se utiliza para controlar la cantidad de llamadas que pueden establecerse por el link. Por ejemplo, si el link WAN entre los dos gateways tiene el ancho de banda para transportar solamente dos llamadas VoIP, admitir una tercera llamada puede afectar la calidad de voz de las tres llamadas. Para obtener más información, consulte: Control de admisión de llamadas VoIP. |
En resumen, para el link PPP de baja velocidad con router/gateways como único origen de tráfico de voz, son obligatorias dos funciones:
Prioridad estricta para el tráfico de voz
A partir de Cisco IOS Software Release 12.2, hay dos métodos principales para proporcionar prioridad estricta para el tráfico de voz:
Prioridad IP RTP (también denominada PQ/WFQ: Cola de prioridad / Cola equilibrada ponderada )
Cola de baja latencia (también denominada PQ/CBWFQ: Cola de prioridad/ Cola equilibrada ponderada basada en clase).
La prioridad IP RTP crea una cola de prioridad estricta 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 son negociados dinámicamente entre dispositivos extremos o gateways, todos los productos de VoIP de Cisco utilizan el mismo rango de puerto UDP (16384-32767). Una vez que el router reconoce el tráfico VoIP, lo pone en la cola de prioridad estricta. Cuando la cola de prioridad está vacía, las otras colas se procesan según Weighted Fair Queuing (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 cola de prioridad (PQ) cuando hay ancho de banda disponible en la cola predeterminada (WFQ), pero controla estrictamente el contenido de la cola de prioridad cuando hay congestión en la interfaz.
LLQ es una función que proporciona una PQ estricta a Class-Based Weighted Fair Queuing (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 configura la PQ, especifica en Kbps la cantidad máxima de ancho de banda disponible para la 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 suprime para evitar que la función legacy priority-group deje de alimentar las colas de menor prioridad.
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 en su red real y sus necesidades verdaderas.
Esta tabla resume las principales diferencias entre LLQ e IP RTP Priority y proporciona algunas pautas sobre cuándo utilizar cada método.
Cola de baja latencia (LLQ) | Prioridad IP RTP |
---|---|
Coincidencia del tráfico de voz según:
|
Coincidencia del tráfico de voz según:
|
Pautas
|
Para obtener más información sobre la correlación y las diferencias de los métodos de colocación en cola, consulte Descripción General de la Administración de Congestión.
Siga estas instrucciones 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 !-- Now, create the access-list to match the class-map access-group: maui-voip-sj(config)#access-list 102 permit udp any any range 16384 32776 !-- 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 pueden utilizar 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 other non-voice traffic does NOT uses 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, you can mark !-- incoming traffic by applying an inbound service policy on an inbound !-- interface. This procedure is out of the scope of this doc. 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 grupos de acceso:
Comienzo con la Versión 12.1.2.T del IOS de Cisco, para LLQ se implementa la funcionalidad de Prioridad IP RTP. Esta función hace coincidir los contenidos de las clases de prioridad en los puertos UDP configurados y está sujeta a la limitación de servir sólo a los puertos pares del 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 aplicar la operación LLQ de salida.
class-map voice match ip precedence 5
or
class-map voice match ip dscp ef
Nota: A partir de la versión 12.2.2T del IOS, los pares de marcado VoIP pueden marcar los paquetes portadores y de señalización de voz antes de la operación LLQ. Esto permite una forma escalable de marcado e identificación de paquetes VoIP a través de valores de código DSCP para LLQ.
Realice un mapa de clase para la señalización de VoIP y defina un criterio de coincidencia (opcional).
Estos comandos explican cómo 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, SIP, MGCP o Skinny (protocolo propietario utilizado por Cisco Call Manager). El ejemplo anterior presupone H.323 Fast Connect. Esta lista sirve como referencia para los puertos que utilizan los canales de señalización/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 = TCP 1719
Skinny = TCP 2000-2002 (CM Encore)
ICCP = TCP 8001-8002 (CM Encore)
MGCP = UDP 2427, TCP 2428 (CM Encore)
SIP= UDP 5060, TCP 5060 (configurable)
Cree un mapa de políticas y asocie 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. Estos comandos explican cómo 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 priority !-- Queue (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 Weighted Fair Queue
Nota: Aunque es posible poner en cola varios tipos de tráfico en tiempo real a la PQ, Cisco recomienda que se le dirija solamente el tráfico de voz. El tráfico en tiempo real, como el vídeo, podría introducir variaciones en la demora (la PQ es una cola FIFO - Primero en entrar primero en salir - primero en salir). 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 al 75 por ciento del ancho de banda del link. De lo contrario, la política de servicio no puede ser asignada al link (para ver los mensajes de error, asegúrese de que la consola de registro esté habilitada para el acceso a la consola y de que el monitor de terminal esté habilitado para el acceso a Telnet).
Nota: Al configurar VoIP en un link de 64 Kbps para admitir dos llamadas de voz, es común asignar más del 75% (48 Kbps) del ancho de banda del link a la PQ. En estos casos, puede utilizar el comando max-reserved-bandwidth 80 para aumentar el ancho de banda disponible al 80 por ciento (51 Kbps).
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.
Habilitar LLQ: Aplicar el mapa de políticas a la interfaz WAN saliente
Estos comandos explican cómo completar esta tarea:
maui-voip-sj(config)#interface multilink 1 maui-voip-sj(config-if)#service-policy output VOICE-POLICY !-- In this scenario (MLPPP LFI), the service policy is applied to !-- the Multilink interface.
Para configurar la prioridad IP RTP, utilice estas pautas:
Router(config-if)#ip rtp priority starting-rtp-port-#port-#-rangebandwidth
Comando | Descripción |
---|---|
starting-rtp-port-number |
Límite inferior del puerto UPD. El número de puerto menor al cual se envían los paquetes. Para VOIP, configure este valor en 16384. |
port-number-range |
El rango de puertos de destino UDP. Un número, que se agrega al start-rtp-port-number, genera el número de puerto UDP más alto. Para VOIP, configure este valor en 16383 (32767 - 16384 = 16383). |
bandwidth |
Máximo de ancho de banda permitido (kbps) en la cola de prioridad. Configure este número de acuerdo con el número de llamadas simultáneas que admite el sistema. |
Configuración de ejemplo:
interface Multilink1 !--- Some output omitted bandwidth 64 ip address 172.22.130.2 255.255.255.252 ip tcp header-compression fair-queue no cdp enable ppp multilink ppp multilink fragment-delay 10 ppp multilink interleave multilink-group 1 ip rtp header-compression iphc-format ip rtp priority 16384 16383 45
Mientras que 1500 bytes es un tamaño normal para paquetes de datos, un paquete VoIP típico (que transporta tramas de voz G.729) puede pesar alrededor de 66 bytes (20 bytes de carga útil de voz, 6 bytes de encabezado de capa 2, 20 bytes de encabezado RTP & UDP y 20 bytes de encabezado IP).
Ahora, imagine un link de línea arrendada de 56Kbps en el que coincidan la voz y el tráfico de datos. Si un paquete de voz está listo para ser serializado en el momento en que se comienza a transmitir un paquete de datos sobre el link, estaremos en presencia de un problema. El paquete de voz sensible al retardo debe esperar 214 mseg antes de ser transmitido (toma 214 mseg serializar un paquete de 1500 bytes sobre un link de 56Kbps).
Como puede verse, los grandes paquetes de datos puede retrasar desfavorablemente la entrega de los paquetes de voz pequeños y así disminuir la calidad de voz. La fragmentación de estos paquetes de datos grandes en paquetes más pequeños y el entrelazado de paquetes de voz entre los fragmentos reduce la fluctuación y el retraso. La función de fragmentación y entrelazado del link (LFI) del IOS de Cisco cumple los requisitos de entrega en tiempo real de VoIP. Esta imagen ilustra el funcionamiento de LFI:
Como se muestra en la Tabla 1, la cantidad de retraso en la serialización (el tiempo real que transcurre para ubicar los bits en una interfaz) introducido en links WAN de baja velocidad puede ser significativo, considerando que el retraso unidireccional de extremo a extremo de destino no tendría que exceder los 150 ms. (La recomendación ITU-T G.114 especifica un máximo de 150 ms unidireccional de extremo a extremo.)
Tabla 1. Retraso de serialización para varios tamaños de trama en links de baja velocidad Retraso de serialización = tamaño de trama (bits)/ancho de banda de link (bps)1 Byte | 64 bytes | 128 bytes | 256 bytes | 512 bytes | 1024 bytes | 1500 bytes | |
---|---|---|---|---|---|---|---|
56 kbps | 143 us | 9 ms | 18 m | 36 ms | 72 ms | 144 ms | 214 m |
64 kbps | 125 us | 8 ms | 16 ms | 32 m | 64 ms | 126 ms | 187 m |
128 kbps | 62.5 us | 4 ms | 8 ms | 16 ms | 32 m | 64 ms | 93 m |
256 kbps | 31 us | 2 ms | 4 ms | 8 ms | 16 ms | 32 m | 46 m |
512 kbps | 15.5 us | 1 ms | 2 ms | 4 ms | 8 ms | 16 ms | 32 m |
768 kbps | 10 us | 640 us | 1.28 ms | 2.56 ms | 5.12 ms | 10.24 ms | 15 ms |
1536 kbps | 5 us | 320 us | 640 us | 1.28 ms | 2.56 ms | 5.12 ms | 7.5 ms |
Nota: Para las aplicaciones de voz, la demora de serialización recomendada (por salto) es de 10 ms y no debe superar los 20 ms.
El tamaño del fragmento del enlace se puede configurar en milisegundos (mseg) con el comando ppp multilink fragment-delay. LFI requiere que los ppp multilink se configure en la interfaz con ppp multilink interleave activado. Para obtener más información sobre la configuración de LFI, consulte la sección de este documento.
Nota: En los casos en que tiene más de una conexión T1 media dedicada (768 Kbps), no necesita una función de fragmentación. (Sin embargo, todavía necesita un mecanismo de QoS, como LLQ o Prioridad de IP RTP). La mitad de T1 ofrece suficiente ancho de banda como para permitir el ingreso y la salida de los paquetes de voz de la cola sin problemas de retraso. Además, quizás no necesite Compresión para el protocolo de tiempo real (cRTP), el cual ayuda a conservar el ancho de banda al comprimir los encabezados RTP IP, en caso de media T1.
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 puede ahorrar tiempo de resolución de problemas al aislar potenciales inconvenientes de cRTP.
Basada en RFC 2508, la función de compresión de encabezado RTP comprime el encabezado IP/UDP/RTP de 40 bytes a 2 o 4 bytes, reduciendo así el consumo innecesario de ancho de banda. Es un esquema de compresión salto a salto; por lo tanto, cRTP debe configurarse en ambos extremos del link (a menos que la opción pasiva esté configurada). Para configurar cRTP, utilice este comando en el nivel de interfaz:
Router(config-if)#ip rtp header-compression [passive]
Dado que el proceso de compresión puede ser intensivo para la CPU, la compresión del encabezado de RTP se implementa en el fast switching y en los trayectos de CEF switching como en la versión 12.0.(7)T de IOS. Algunas veces estas implementaciones se rompen y luego la única manera de funcionar será procesada conmutada. Cisco sólo recomienda utilizar cRTP con links de menos de 768 Kbps, a menos que el router esté ejecutando a una velocidad baja de utilización de CPU Supervise la utilización de la CPU del router y desactive cRTP si supera el 75%.
Nota: Cuando configura el comando ip rtp header-compression, el router agrega el comando ip tcp header-compression a la configuración de forma predeterminada. Esto se utiliza para comprimir los paquetes TCP/IP de los encabezados. La compresión del encabezado es particularmente útil en redes con un gran porcentaje de paquetes pequeños, como aquellos que soportan muchas conexiones Telnet. La técnica de compresión del encabezado TCP, descrita completamente en RFC 1144, se soporta en las líneas seriales usando encapsulación HDLC o PPP.
Para comprimir los encabezados TCP sin habilitar cRTP, utilice este comando:
Router(config-if)#ip tcp header-compression [passive]
Para más información: Protocolo Compressed Real-time Transport
Utilice codificadores/descodificadores de baja velocidad de bits (códec) en los tramos de llamadas VoIP; Se recomienda G.729 (8 Kbps). (Este es el códec predeterminado en los pares de marcado VoIP). Para configurar diferentes códecs, utilice el comando router(config-dial-peer)#codec bajo el dial-peer de voip deseado.
Aunque la multifrecuencia de tono dual (DTMF) normalmente se transporta con precisión cuando se utilizan codecs de voz de alta velocidad de bits tales como G.711, los codecs de baja velocidad de bits (tales como G.729 y G.723.1) están altamente optimizados para 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 soluciona este problema de distorsión DTMF mediante el transporte de los tonos DTMF “fuera de la banda” o separados de la secuencia de voz codificada. Si se utilizan códecs de baja velocidad de bits (G.729, G.723), active relé dtmf en el dial-peer VoIP.
Una conversación típica puede contener entre un 35% y un 50% de silencio. Al utilizar la Detección de actividad de voz (VAD), se eliminan los paquetes de silencio. Para la planificación del ancho de banda de VoIP, supongamos que VAD reduce el ancho de banda en un 35%. VAD está configurado de forma predeterminado en pares de marcado VoIP. Para habilitar o deshabilitar VAD, utilice los comandos router(config-dial-peer)#vad y router(config-dial-peer)# no vad bajo los pares de marcado voip deseados.
maui-voip-sj (Cisco 3640) |
---|
version 12.2service timestamps debug datetime msec !-- < Some output omitted > ! hostname maui-voip-sj ! ip subnet-zero ! no ip domain-lookup ! !-- 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 priority !-- queue is assigned to "voice-traffic" class with (based on ACL in !-- class voice) with max bandwidth = 45 Kbps. policy-map VOICE-POLICY class voice-traffic priority 48 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, but rather 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. ! call rsvp-sync ! !-- Note that MLPPP is strictly an LFI mechanism. It does not !-- bundle multiple serial interfaces to the same virtual interface as !-- the name stands (This bundling is done for data and NOT recommended !-- for voice). The end result may manifest itself as jitter and no audio. interface Multilink1 ip address 172.22.130.1 255.255.255.252 ip tcp header-compression iphc-format service-policy output VOICE-POLICY !-- LLQ is an outbound operation and applied to the outbound WAN !-- interface. no cdp enable ppp multilink ppp multilink fragment-delay 10 !-- The configured value of 10 sets the fragment size such that !-- all fragments have a 10 ms maximum serialization delay. ppp multilink interleave multilink-group 1 ip rtp header-compression iphc-format ! interface Ethernet0/0 ip address 172.22.113.3 255.255.255.0 no keepalive half-duplex ! interface Serial0/0 bandwidth 128 !-- the bandwidth command needs to be set correctly for the !-- right fragment size to be calculated. no ip address encapsulation ppp clockrate 128000 ppp multilink multilink-group 1 !-- This command links the multilink interface to the physical !-- serial interface. ! router eigrp 69 network 172.22.0.0 auto-summary no eigrp log-neighbor-changes ! !-- 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 is used to match VoIP signaling protocol. In this !-- case, H.323 V2 with fast start feature is used. 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 ! voice-port 1/0/1 ! voice-port 1/1/0 ! voice-port 1/1/1 ! dial-peer cor custom ! dial-peer voice 1 pots destination-pattern 5000 port 1/0/0 ! dial-peer voice 2 voip destination-pattern 6000 session target ipv4:172.22.130.2 |
maui-voip-austin (Cisco 3640) |
---|
version 12.2 service timestamps debug datetime msec ! hostname maui-voip-austin ! boot system flash slot1:c3640-is-mz.122-6a.bin ! 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 48 class class-default fair-queue ! interface Multilink1 bandwidth 128 ip address 172.22.130.2 255.255.255.252 ip tcp header-compression iphc-format service-policy output voice-policy no cdp enable ppp multilink ppp multilink fragment-delay 10 ppp multilink interleave multilink-group 1 ip rtp header-compression iphc-format !-- Configure cRTP after you have a working configuration. !-- This helps isolate potential cRTP issues. ! Interface Ethernet0/0 ip address 172.22.112.3 255.255.255.0 no keepalive half-duplex ! interface Serial0/0 bandwidth 128 no ip address encapsulation ppp no ip mroute-cache ppp multilink multilink-group 1 ! router eigrp 69 network 172.22.0.0 auto-summary no eigrp log-neighbor-changes ! 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 ! voice-port 1/0/1 ! voice-port 1/1/0 ! voice-port 1/1/1 ! dial-peer cor custom ! dial-peer voice 1 pots destination-pattern 6000 port 1/0/0 ! dial-peer voice 2 voip destination-pattern 5000 session target ipv4:172.22.130.1 |
Antes de intentar cualquier comando debug, consulte Información Importante sobre Comandos Debug. Para obtener más información sobre los comandos enumerados aquí, vea la sección Salida show y debug de este documento.
Comandos de interfaz:
show interface [serial | multilink]: utilice este comando para verificar el estado de la interfaz serial. Asegúrese de que la interfaz serial y multilink esté activa y abierta.
Comandos LFI:
show ppp multilink — Este comando muestra información sobre los agrupamientos de PPP de enlaces múltiples.
debug ppp multilink fragments—Este comando de depuración muestra información acerca de fragmentos individuales de enlaces múltiples y eventos de entrelazado. Este resultado del comando también identifica el número de secuencia del paquete y los tamaños del fragmento.
Comandos de Prioridad LLQ/IP RTP:
show policy-map interface multilink interface# —Este comando es muy útil para ver la operación LLQ y para ver cualquier caída 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 —Este comando muestra información sobre la configuración de policy-map.
show queue interface-type interface-number —Este comando enumera la configuración de cola justa y las estadísticas para una interfaz en particular.
Prioridad de depuración: este comando de depuración muestra los eventos de colocación en cola de prioridad y muestra si se produce la caída en esta cola. También consulte Solución de Problemas de Caídas de Salida con Cola Prioritaria.
show class-map class_name —Este comando muestra información sobre la configuración de class-map.
show call active voice: este comando es útil para verificar si hay paquetes perdidos en el nivel DSP.
Otros comandos/referencias
show ip rtp header-compression: Este comando muestra las estadísticas de compresión del encabezado RTP.
Solución de problemas y depuración de aspectos básicos de llamadas VoIP
Problemas conocidos:
CSCds43465: "LLQ, Policer, Shaper Debe Tomar Comentarios de Compresión CRTP" Para ver las Notas de la Versión, consulte Bug ToolKit (sólo clientes registrados).
Pautas:
Estos son algunos pasos básicos para la resolución de problemas, una vez que el link ppp está activo y en ejecución (MLPPP, fragmentación, entrelazado):
show call active voice: utilícelo para verificar los paquetes perdidos en el nivel DSP.
show interface: utilícelo para comprobar la línea serial general o los problemas de la interfaz. Las interrupciones en la interfaz todavía no significan que exista un problema, pero es preferible eliminar el paquete de la cola de baja prioridad antes de que llegue a la cola de la interfaz.
show policy-map interface: Utilícelo para verificar las caídas de LLQ y la configuración de cola. No debe informar de ninguna caída que viole la política.
show ip rtp header-compression: utilícelo para verificar los problemas específicos de cRTP.
!----------------------------------------------- !----------------------------------------------- !---- To capture sections of this output, the LLQ PQ bandwidth !---- was lowered and large data traffic was placed !---- on the link to force some packets drops. !----------------------------------------------- !----------------------------------------------- !---- Packet Drop Verification (During an Active Call) !--- Assuming your ppp link is up and running, the first step of voice !--- quality problems verification is to check for lost packets !--- at the DSP. Note: Use the show call active voice command !--- NOT show call active voice brief maui-voip-austin#show call active voice Total call-legs: 2 !--- Indicates that the connection is established and both legs exist GENERIC: SetupTime=155218260 ms Index=1 PeerAddress=5000 PeerSubAddress= PeerId=2 PeerIfIndex=13 LogicalIfIndex=0 ConnectTime=155218364 CallDuration=00:00:27 CallState=4 !--- indicates that it is the active call !--- (#define D_callActiveCallState_active 4). CallOrigin=2 ChargedUnits=0 InfoType=2 TransmitPackets=365 TransmitBytes=7300 ReceivePackets=229 ReceiveBytes=4580 VOIP: !--- For this call, this was the terminating gateway. !--- At this gateway, the call started at the VoIP leg. ConnectionId[0x18872BEB 0x1A8911CC 0x808CBE60 0x6D946FC6] IncomingConnectionId[0x18872BEB 0x1A8911CC 0x808CBE60 0x6D946FC6] RemoteIPAddress=172.22.130.1 !--- Indicates from which IP address the RTP stream is originating. RemoteUDPPort=18778 RemoteSignallingIPAddress=172.22.130.1 !--- Indicates from which IP address signaling messages are coming. RemoteSignallingPort=11010 RemoteMediaIPAddress=172.22.130.1 RemoteMediaPort=18778 RoundTripDelay=50 ms SelectedQoS=best-effort tx_DtmfRelay=inband-voice FastConnect=TRUE Separate H245 Connection=FALSE H245 Tunneling=FALSE SessionProtocol=cisco SessionTarget= OnTimeRvPlayout=4570 GapFillWithSilence=20 ms GapFillWithPrediction=1840 ms GapFillWithInterpolation=0 ms GapFillWithRedundancy=0 ms HiWaterPlayoutDelay=70 ms LoWaterPlayoutDelay=51 ms ReceiveDelay=51 ms LostPackets=90 EarlyPackets=1 LatePackets=0 !--- Indicates the precense of jitter, lost packets, or !--- corrupted packets. VAD = enabled CoderTypeRate=g729r8 CodecBytes=20 GENERIC: SetupTime=155218260 ms Index=2 PeerAddress=6000 PeerSubAddress= PeerId=1 PeerIfIndex=12 LogicalIfIndex=6 ConnectTime=155218364 CallDuration=00:00:34 CallState=4 CallOrigin=1 ChargedUnits=0 InfoType=2 TransmitPackets=229 TransmitBytes=4580 ReceivePackets=365 ReceiveBytes=7300 TELE: ConnectionId=[0x18872BEB 0x1A8911CC 0x808CBE60 0x6D946FC6] IncomingConnectionId=[0x18872BEB 0x1A8911CC 0x808CBE60 0x6D946FC6] TxDuration=35360 ms VoiceTxDuration=730 ms FaxTxDuration=0 ms CoderTypeRate=g729r8 NoiseLevel=-46 ACOMLevel=2 OutSignalLevel=-58 InSignalLevel=-42 InfoActivity=2 ERLLevel=7 SessionTarget= ImgPages=0Total call-legs: 2 !---------------------------------------------------------- !--- Interface Verification !--- Make sure you see this: !--- LCP Open, multilink Open: Link control protocol (LCP) open statement !--- indicates that the connection is establish. !--- Open:IPCP. Indicates that IP traffic can be transmitted via the PPP link. maui-voip-sj#show interface multilink 1 Multilink1 is up, line protocol is up Hardware is multilink group interface Internet address is 172.22.130.1/30 MTU 1500 bytes, BW 128 Kbit, DLY 100000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation PPP, loopback not set Keepalive set (10 sec) DTR is pulsed for 2 seconds on reset LCP Open, multilink Open Open: IPCP Last input 00:00:01, output never, output hang never Last clearing of "show interface" counters 00:25:20 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 91 Queueing strategy: weighted fair Output queue: 0/1000/64/37/383 (size/max total/threshold/drops/interleaves) Conversations 0/3/32 (active/max active/max total) Reserved Conversations 1/1 (allocated/max allocated) Available Bandwidth 38 kilobits/sec 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 8217 packets input, 967680 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 13091 packets output, 1254194 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions ---------------------------------------------------------------- !-- Note: There are no drops at the interface level. !-- All traffic that is dropped due to policing, is !-- dropped before it gets to the interface queue. maui-voip-austin#show interface serial 0/0Serial0/0 is up, line protocol is up Hardware is QUICC Serial MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec, reliability 255/255, txload 49/255, rxload 47/255 Encapsulation PPP, loopback not set Keepalive set (10 sec) LCP Open, multilink Open Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters 00:22:08 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: weighted fair [suspended, using FIFO] FIFO output queue 0/40, 0 drops 5 minute input rate 24000 bits/sec, 20 packets/sec 5 minute output rate 25000 bits/sec, 20 packets/sec 4851 packets input, 668983 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 4586 packets output, 657902 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up !----------------------------------- !--- LLQ Verification maui-voip-austin#show policy-map int multilink 1 Multilink1 Service-policy output: voice-policy Class-map: voice-signaling (match-all) !--- This is the class for the voice signaling traffic. 10 packets, 744 bytes 5 minute offered rate 0 BPS, drop rate 0 BPS Match: access-group 103 Weighted Fair Queueing Output Queue: Conversation 42 Bandwidth 8 (kbps) Max Threshold 64 (packets) (pkts matched/bytes matched) 10/744 (depth/total drops/no-buffer drops) 0/0/0 Class-map: voice-traffic (match-all) !--- This is PQ class for the voice traffic. 458 packets, 32064 bytes 5 minute offered rate 0 BPS, drop rate 0 BPS Match: access-group 102 Weighted Fair Queueing Strict Priority Output Queue: Conversation 40 Bandwidth 15 (kbps) Burst 375 (Bytes) !--- Notice that the PQ bandwidth was lowered to force packet drops. (pkts matched/bytes matched) 458/29647 (total drops/bytes drops) 91/5890 !--- Some packets were dropped. In a well designed link, !--- there should be no (or few) drops of the PQ class. Class-map: class-default (match-any) 814 packets, 731341 bytes 5 minute offered rate 27000 BPS, drop rate 0 BPSMatch: any Weighted Fair Queueing Flow Based Fair Queueing Maximum Number of Hashed Queues 32 (total queued/total drops/no-buffer drops) 0/0/0 !--------------------------------------------- !--- Verify the class-map configuration 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 !--- Verify the access-lists of the class-maps maui-voip-austin#show access-lists Extended IP access list 102 permit udp any any range 16384 32767 (34947 matches) Extended IP access list 103 permit tcp any eq 1720 any (187 matches) permit tcp any any eq 1720 (86 matches) !--- Verify the policy-pap 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 50 (kbps) Burst 1250 (Bytes) Class class-default Weighted Fair Queueing Flow based Fair Queueing Max Threshold 64 (packets) --------------------------- !--- Debug priority command provides immediate feedback in case !--- of VoIP packet drops. !--- The output below shows the error message when VoIP packets !--- are being dropped from the strict priority queue. maui-voip-sj#debug priority priority output queueing debugging is on maui-voip-sj# Mar 17 19:47:09.947: WFQ: dropping a packet from the priority queue 0 Mar 17 19:47:09.967: WFQ: dropping a packet from the priority queue 0 Mar 17 19:47:09.987: WFQ: dropping a packet from the priority queue 0 ------------------------------------------------------------------- !--- Link Fragmentation and Interleaving (LFI) Verification maui-voip-sj#show ppp multilink !--- Verify the fragmentation size and multilink Multilink1, bundle name is maui-voip-austin Bundle up for 00:08:04 0 lost fragments, 0 reordered, 0 unassigned 0 discarded, 0 lost received, 1/255 load 0x6D received sequence, 0x6E sent sequence Member links: 1 active, 0 inactive (max not set, min not set) Serial0/0, since 00:08:09, last rcvd seq 00006C 160 weight !--- Notice the fragmentation size is 160 Bytes. The link is configured with a !--- bandwidth of 128 kbps and a serialization delay of 10 msec. !--- Fragment Size (in bits) = bandwidth * serialization delay. !--- Note: There are 8 bits in one byte. ------------------------------------------------------- !--- Link Fragmentation and Interleaving (LFI) Verification !--- Testing Multilink PPP Link LFI !--- This output displays fragmentation and interleaving information !--- when the the 128kbps PPP link is loaded with big data and VoIP packets. maui-voip-sj#debug ppp multilink fragments Multilink fragments debugging is on 1w3d: Se0/0 MLP: O frag 800004CF size 160 1w3d: Se0/0 MLP: O frag 000004D0 size 160 1w3d: Se0/0 MLP: I ppp IP (0021) size 64 direct 1w3d: Mu1 MLP: Packet interleaved from queue 40 1w3d: Se0/0 MLP: O ppp IP (0021) size 64 1w3d: Se0/0 MLP: I ppp IP (0021) size 64 direct 1w3d: Se0/0 MLP: O frag 400004D1 size 106 1w3d: Se0/0 MLP: O ppp IP (0021) size 64 1w3d: Se0/0 MLP: I ppp IP (0021) size 64 direct 1w3d: Se0/0 MLP: O ppp IP (0021) size 64 direct 1w3d: Se0/0 MLP: I frag 800004E0 size 160 direct 1w3d: Se0/0 MLP: I frag 000004E1 size 160 direct 1w3d: Se0/0 MLP: I ppp IP (0021) size 64 direct ------------------------------------------------------------------- !--- Sample output of show ip rtp header-compression command maui-voip-sj#show ip tcp header-compression TCP/IP header compression statistics: Interface Multilink1: Rcvd: 10 total, 6 compressed, 0 errors 0 dropped, 0 buffer copies, 0 buffer failures Sent: 10 total, 7 compressed, 230 bytes saved, 99 bytes sent 3.32 efficiency improvement factor Connect: 16 rx slots, 16 tx slots, 2 long searches, 1 misses 0 collisions, 0 negative cache hits 90% hit ratio, five minute miss rate 0 misses/sec, 0 max ---------------------------------------------------------------------- !--- This command displays information of the voip dial-peers command. maui-voip-sj#show dial-peer voice 2 VoiceOverIpPeer2 information type = voice, tag = 2, destination-pattern = `6000', 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-tMarget = `ipv4:172.22.130.2', technology prefix: ip precedence = 0, UDP checksum = disabled, session-protocol = cisco, req-qos = best-effort, acc-qos = best-effort, 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 = 283, Charged Units = 0, Successful Calls = 1, Failed Calls = 0, Accepted Calls = 1, Refused Calls = 0, Last Disconnect Cause is "10 ", Last Disconnect Text is "normal call clearing.", Last Setup Time = 93793451. ------------------------------------------------------------------------- !---The CPU utilization of the router should not exceed the 50-60 percent !--- during any five-minute interval. maui-voip-austin#show processes cpu CPU utilization for five seconds: 12%/8%; one minute: 11%; five minutes: 9% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 148 310794 0 0.00% 0.00% 0.00% 0 Load Meter 2 76 23 3304 0.81% 0.07% 0.01% 0 Exec |