Resolución de problemas de línea serial

Introducción

Este capítulo presenta información general de Troubleshooting y una explicación de las herramientas y técnicas para resolver problemas de las conexiones en serie. El capítulo incluye las secciones siguientes:

• Resolución de problemas mediante el comando show interfaces serial

• Uso del Comando show controllers

• ‘Uso de los comandos de depuración’

• Uso de pruebas ping extendidas

• Resolución de problemas de temporización

• Ajuste de Búfers

• Pruebas de línea serial especiales

• Información detallada sobre el comando show interfaces serial

• Resolución de problemas de T1

• Resolución de problemas de E1

Prerequisites

Requirements

Los lectores de este documento deben conocer las siguientes definiciones.

• DTE = equipo terminal de datos

• CD = Detección de portadora

• CSU = unidad de servicio de canal

• DSU = unidad de servicio digital

• SCTE = transmisión de reloj serial externa

• DCE = equipo de terminación de circuitos de datos

• CTS = clear-to-send

• DSR = preparado para el conjunto de datos

• SAP = Protocolo de publicidad de servicio

• IPX = Intercambio de paquetes entre redes

• FDDI = Interfaz de datos distribuidos por fibra

• ESF = Formato de supertrama extendido

• B8ZS = sustitución binaria de ocho ceros

• LBO = Line Build

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

La información que se presenta en este documento se originó a partir de dispositivos dentro de un ambiente de laboratorio específico. All of the devices used in this document started with a cleared (default) configuration. Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener un comando antes de ejecutarlo.

Convenciones

Para obtener más información sobre las convenciones del documento, consulte Convenciones de Consejos Técnicos de Cisco.

Resolución de problemas mediante el comando show interfaces serial

La salida del comando EXEC show interfaces serial muestra información específica para las interfaces seriales. La figura 15-1 muestra el resultado del comando show interfaces serial EXEC para una interfaz serial High-Level Data Link Control (HDLC).

Esta sección describe cómo utilizar el comando show interfaces serial para diagnosticar problemas de conectividad de línea serial en un entorno de red de área extensa (WAN). En las secciones siguientes se describen algunos de los campos importantes del resultado del comando.

Otros campos mostrados en la pantalla se describen detalladamente en la sección "Información detallada sobre el comando show interfaces serial", más adelante en este capítulo.

Líneas de serie: show interfaces serial Status Line Condiciones

Puede identificar cinco posibles estados de problema en la línea de estado de la interfaz de la pantalla show interfaces serial (consulte la figura 15-1):

• La serie x está inactiva, el protocolo de línea está inactivo

• La serie x está activa, el protocolo de línea está inactivo

• La serie x está activa, el protocolo de línea está activo (con loop)

• La serie x está activa, el protocolo de línea está inactivo (desactivado)

• La serie x está administrativamente inactiva, el protocolo de línea está inactivo

Figura 15-1 Salida del Comando show interface serial HDLC

Tabla 15-1: Líneas de serie: show interfaces serial Status Line Condiciones - Esta tabla muestra las condiciones de estado de la interfaz, los posibles problemas asociados con las condiciones y las soluciones a esos problemas.

Condición del estado de la línea	Posible problema	Solución
El serial x está activo, el protocolo de línea está activo		Esta es la condición de estado de línea adecuada. No se requiere acción
La serie x está inactiva, el protocolo de línea está inactivo (modo DTE)	Normalmente indica que el router no detecta una señal de CD (es decir, que el CD no está activo). Problema de la empresa telefónica: la línea está inactiva o la línea no está conectada a la CSU/DSU Cableado defectuoso o incorrecto Fallo de hardware (CSU/DSU)	Compruebe las luces de la CSU/DSU para ver si el CD está activo o inserte una casilla de salida en la línea para comprobar la señal del CD. Compruebe que está utilizando el cable y la interfaz adecuados (consulte la documentación de instalación del hardware). Inserte una casilla de selección y verifique todos los leads de control. Póngase en contacto con su línea arrendada u otro servicio de operadora para ver si hay algún problema. Intercambie piezas defectuosas. Si sospecha un hardware de router defectuoso, cambie la línea serial a otro puerto. Si se activa la conexión, la interfaz conectada previamente tiene un problema.
La serie x está activa, el protocolo de línea está inactivo (modo DTE)	El router local o remoto está mal configurado El router remoto no envía señales de mantenimiento Línea arrendada u otro servicio de operador: línea ruidosa, o switch mal configurado o fallido Problema de temporización en el cable (SCTE no establecido en CSU/DSU) Fallo en la CSU/DSU local o remota CSU/DSU local o remoto fallido Fallo de hardware del router (local o remoto)	Coloque el módem, la CSU o la DSU en el modo de loopback local y utilice el comando show interfaces serial para ver si se activa el protocolo de línea. Si se activa el protocolo de línea, el problema probable es un problema de compañía telefónica o un router remoto fallido. Si el problema parece estar en el extremo remoto, repita el Paso 1 en el módem remoto, la CSU o la DSU. Verifique todo el cableado. Asegúrese de que el cable esté conectado a la interfaz correcta, a la CSU/DSU correcta y al punto de terminación de red de la compañía telefónica correcto. Utilice el comando EXEC show controllers para determinar qué cable está conectado a qué interfaz. Habilite el comando EXEC debug serial interface. Precaución: Debido a que se asigna una alta prioridad a la salida de depuración en el proceso de la CPU, puede hacer que el sistema quede inutilizable. Por esta razón, sólo use los comandos de depuración para resolver problemas específicos o durante sesiones de resolución de problemas con el equipo de soporte técnico de Cisco. Es más, es mejor utilizar los comandos de depuración durante los períodos en que hay poco tráfico en la red y menos usuarios. El debugging durante estos períodos disminuye la posibilidad de que la sobrecarga por el mayor procesamiento del comando debug afecte al uso del sistema. Si el protocolo de línea no aparece en el modo de loopback local y si la salida del comando debug serial interface EXEC muestra que el contador de keepalive no está aumentando, es probable que se produzca un problema de hardware del router. Intercambie el hardware de la interfaz del router. Si aparece el protocolo de línea y aumenta el contador de keepalive, el problema no se encuentra en el router local. Solucione los problemas de la línea serial tal y como se describe en las secciones "Resolución de problemas de temporización" y "Pruebas de loopback de CSU y DSU", más adelante en este capítulo. Si sospecha un hardware de router defectuoso, cambie la línea serial a un puerto sin utilizar. Si se activa la conexión, la interfaz conectada previamente tiene un problema.
La serie x está activa, el protocolo de línea está inactivo (modo DCE)	Falta el comando de configuración de la interfaz clockrate El dispositivo DTE no admite o no está configurado para el modo SCTE CSU o DSU remoto fallido Cable fallido o incorrecto Falla de hardware del router	Agregue el comando de configuración de la interfaz clockrate en la interfaz serial. Sintaxis: Descripción de la sintaxis de bps de velocidad de reloj: bps-Velocidad de reloj deseada en bits por segundo: 1200, 2400, 4800, 9600, 19200, 38400, 56000, 64000, 72000, 125000, 1488 000, 250000, 50000, 800000, 1000000, 1300000, 20000000, 4000000 o 8 000000. Establezca el dispositivo DTE en el modo SCTE si es posible. Si su CSU/DSU no admite SCTE, es posible que tenga que desactivar SCTE en la interfaz del router de Cisco. Consulte la sección "Invertir el reloj de transmisión" más adelante en este capítulo. Verifique que se esté utilizando el cable correcto. Si el protocolo de línea sigue sin funcionar, existe un posible fallo de hardware o problema de cableado. Inserte una caja de escape y observe los clientes potenciales. Sustituya las piezas defectuosas según sea necesario.
La serie x está activa, el protocolo de línea está activo (con loop)	Existe un loop en el circuito. El número de secuencia en el paquete keepalive cambia a un número aleatorio cuando se detecta inicialmente un loop. Si se devuelve el mismo número aleatorio sobre el link, existe un loop.	Utilice el comando EXEC privilegiado show running-config para buscar cualquier entrada de comando de configuración de interfaz de loopback. Si encuentra una entrada del comando de configuración de la interfaz loopback, utilice el comando de configuración de la interfaz no loopback para quitar el loop. Si no encuentra el comando de configuración de la interfaz loopback, examine la CSU/DSU para ver si están configurados en el modo de loopback manual. Si lo están, inhabilite el loopback manual. Reinicie la CSU o la DSU e inspeccione el estado de la línea. Si aparece el protocolo de línea, no se necesita otra acción. Si la CSU o DSU no está configurada en el modo de loopback manual, comuníquese con la línea arrendada u otro servicio de portadora para obtener asistencia para la resolución de problemas de línea.
La serie x está activa, el protocolo de línea está inactivo (desactivado)	Alta tasa de error debido al problema de servicio de la compañía telefónica problema de hardware CSU o DSU Hardware de router incorrecto (interfaz)	Solucione los problemas de la línea con un analizador en serie y una caja de escape. Busque la alternancia de señales CTS y DSR. Bucle CSU/DSU (loop DTE). Si el problema continúa, es probable que haya un problema de hardware. Si el problema no continúa, es probable que haya un problema en la compañía telefónica. Intercambie hardware defectuoso según sea necesario (CSU, DSU, switch, router local o remoto).
La serie x está administrativamente inactiva, el protocolo de línea está inactivo	La configuración del router incluye el comando de configuración de la interfaz shutdown Dirección IP duplicada	Verifique la configuración del router para el comando shutdown. Utilice el comando de configuración de la interfaz no shutdown para quitar el comando shutdown. Verifique que no haya direcciones IP idénticas usando el comando EXEC privilegiado show running-config o el comando EXEC show interfaces. Si hay direcciones duplicadas, resuelva el conflicto cambiando una de las direcciones IP.

Líneas de serie: Aumento de las caídas de salida en el link serial

Las caídas de salida aparecen en el resultado del comando show interfaces serial (consulte la figura 15-1) cuando el sistema intenta entregar un paquete a un búfer de transmisión pero no hay búfers disponibles.

Síntoma: Un número creciente de caídas de salida en el link serial.

Tabla 15-2 Líneas de Serie: Aumentar las caídas de salida en el link serial - Esta tabla describe el posible problema que puede causar este síntoma y sugiere soluciones.

Posible problema

Solución

La velocidad de entrada a la interfaz serial excede el ancho de banda disponible en el link serial

Minimizar el tráfico de broadcast periódico (como las actualizaciones de SAP y de routing) mediante listas de acceso o por otros medios. Por ejemplo, para aumentar el retraso entre las actualizaciones de SAP, utilice el comando de configuración de interfaz ipx sap-interval. Aumente el tamaño de la cola de retención de salida en pequeños incrementos (por ejemplo, 25 por ciento), usando el comando de configuración de la interfaz hold-queue out. En las interfaces afectadas, apague fast switching para los protocolos más utilizados. Por ejemplo, para desactivar IP fast switching, ingrese el comando de configuración de interfaz no ip route-cache. Para obtener la sintaxis de comandos para otros protocolos, consulte las guías de configuración y las referencias de comandos de Cisco IOS. Implemente la colocación en cola de prioridad en links seriales más lentos mediante la configuración de listas de prioridad. Para obtener información sobre la configuración de listas de prioridades, vea las guías de configuración y las referencias de comandos de Cisco IOS. Nota: Las caídas de salida son aceptables en determinadas condiciones. Por ejemplo, si se sabe que un link está sobreutilizado (sin ninguna manera de remediar la situación), a menudo es preferible descartar paquetes que retenerlos. Esto se aplica a los protocolos que admiten el control de flujo y pueden retransmitir datos (como TCP/IP y Novell IPX). Sin embargo, algunos protocolos, como DECnet y el transporte de área local, son sensibles a los paquetes perdidos y admiten la retransmisión de manera deficiente, si es que la tienen.

Líneas de serie: Aumento de las caídas de entrada en el link serial

Las caídas de entrada aparecen en la salida del comando EXEC serie show interfaces (consulte la figura 15-1) cuando todavía se procesan demasiados paquetes de esa interfaz en el sistema.

Síntoma: Un número creciente de caídas de entrada en el link serial.

Tabla 15-3: Líneas de serie: Aumentar las caídas de entrada en el link serial - Esta tabla describe el posible problema que puede causar este síntoma y sugiere soluciones.

Posible problema

Solución

La velocidad de entrada excede la capacidad del router o las colas de entrada exceden el tamaño de las colas de salida

Nota: Los problemas de caída de entrada se observan normalmente cuando el tráfico se enruta entre interfaces más rápidas (como Ethernet, Token Ring y FDDI) e interfaces seriales. Cuando el tráfico es ligero, no hay problema. A medida que aumentan las tasas de tráfico, empiezan a producirse copias de seguridad. Los routers descartan paquetes durante estos períodos de congestión. Aumente el tamaño de la cola de salida en las interfaces de destino comunes para la interfaz que está descartando paquetes. Utilice el comando de configuración de interfaz hold-queue out. Aumente estas colas en pequeños incrementos (por ejemplo, el 25%) hasta que ya no vea caídas en el resultado show interfaces. El límite de cola de retención de salida predeterminado es 100 paquetes. Reduzca el tamaño de la cola de entrada, usando el comando hold-queue en la configuración de la interfaz, para obligar a las caídas de entrada a convertirse en caídas de salida. Las caídas de salida tienen menos impacto en el rendimiento del router que las caídas de entrada. La cola de retención de entrada predeterminada es de 75 paquetes.

Líneas de serie: Aumento de los errores de entrada en exceso del 1% del tráfico de interfaz total

Si aparecen errores de entrada en la salida show interfaces serial (consulte la figura 15-1), hay varias fuentes posibles de esos errores. Las fuentes más probables se resumen en la tabla 15-4.

Nota: Cualquier valor de error de entrada para errores de verificación por redundancia cíclica (CRC), errores de entramado o abortos por encima del uno por ciento del tráfico de interfaz total sugiere algún tipo de problema de link que se debe aislar y reparar.

Síntoma: Un número creciente de errores de entrada que supera el uno por ciento del tráfico de interfaz total.

Tabla 15-4: Líneas de serie: Aumento de los errores de entrada en exceso del 1% del tráfico de interfaz total

Posible problema

Solución

Los siguientes problemas pueden dar lugar a este síntoma: Equipo de la compañía telefónica defectuoso Línea serial ruidosa Configuración de temporización incorrecta (no se ha establecido SCTE) Cable o cable incorrectos demasiado tiempo Cable o conexión incorrectos CSU o DSU incorrectos Hardware de router incorrecto Conversor de datos u otro dispositivo que se utiliza entre el router y la DSU

Nota: Cisco recomienda encarecidamente no utilizar convertidores de datos cuando conecte un router a una red WAN o serial. Utilice un analizador en serie para aislar el origen de los errores de entrada. Si detecta errores, es probable que haya un problema de hardware o una discordancia de reloj en un dispositivo externo al router. Utilice las pruebas de loopback y ping para aislar el origen específico del problema. Para obtener más información, vea las secciones "Uso del comando trace" y "Pruebas de loopback de CSU y DSU", más adelante en este capítulo. Busque patrones. Por ejemplo, si se producen errores en un intervalo uniforme, podrían estar relacionados con una función periódica como el envío de actualizaciones de ruteo.

Líneas de serie: Resolución de problemas de errores de entrada de línea serial

Tabla 15-5: Esta tabla describe los diversos tipos de errores de entrada mostrados por el comando show interfaces serial (consulte la figura 15-1), posibles problemas que pueden estar causando los errores y las soluciones a esos problemas.

Tipo de error de entrada (Nombre de campo)	Posible problema	Solución
Errores CRC (CRC)	Los errores CRC se producen cuando el cálculo CRC no pasa, lo que indica que los datos están dañados por una de las siguientes razones: Línea serial ruidosa El cable serial es demasiado largo o el cable de la CSU/DSU al router no está protegido El modo SCTE no está habilitado en la DSU El reloj de línea CSU está configurado incorrectamente Un problema de densidad en el link T1 (especificación de entramado o codificación incorrecta)	Asegúrese de que la línea está lo suficientemente limpia para los requisitos de transmisión. Escuche el cable si es necesario. Asegúrese de que el cable se encuentra dentro de la longitud recomendada: no más de 50 pies (15,24 metros) o 25 pies (7,62 metros) para el enlace T1. Asegúrese de que todos los dispositivos estén correctamente configurados para un reloj de línea común. Establezca SCTE en la DSU local y remota. Si su CSU/DSU no admite SCTE, consulte la sección "Invertir el reloj de transmisión" más adelante en este capítulo. Asegúrese de que la CSU/DSU local y remota esté configurada para el mismo esquema de entramado y codificación que el utilizado por la línea arrendada u otro servicio de portadora (por ejemplo, ESF/B8ZS). Póngase en contacto con su línea arrendada u otro servicio de operador y pídale que realice pruebas de integridad en la línea.
Errores de entramado (trama)	Un error de entramado ocurre cuando un paquete no termina en un límite de bytes de 8 bits por una de las siguientes razones: Línea serial ruidosa Cable mal diseñado; el cable serial es demasiado largo; el cable de la CSU o DSU al router no está protegido El modo SCTE no está habilitado en la DSU; el reloj de línea de la CSU está configurado incorrectamente; uno de los relojes está configurado para la temporización local Un problema de densidad en el link T1 (especificación de entramado o codificación incorrecta)	Asegúrese de que la línea está lo suficientemente limpia para los requisitos de transmisión. Escuche el cable si es necesario. Asegúrese de que está utilizando el cable correcto. Asegúrese de que el cable se encuentra dentro de la longitud recomendada: no más de 50 pies (15,24 metros) o 25 pies (7,62 metros) para el enlace T1. Asegúrese de que todos los dispositivos estén correctamente configurados para utilizar un reloj de línea común. Establezca SCTE en la DSU local y remota. Si su CSU/DSU no admite SCTE, consulte la sección "Invertir el reloj de transmisión" más adelante en este capítulo. Asegúrese de que la CSU/DSU local y remota esté configurada para el mismo esquema de entramado y codificación que el utilizado por la línea arrendada u otro servicio de portadora (por ejemplo, ESF/B8ZS). Póngase en contacto con su línea arrendada u otro servicio de operador y pídale que realice pruebas de integridad en la línea.
Transmisión interrumpida (abort)	Los abortos indican una secuencia ilegal de un bit (más de siete seguidos). Los siguientes son posibles motivos para esta aparición: El modo SCTE no está habilitado en la DSU El reloj de línea CSU está configurado incorrectamente El cable serial es demasiado largo o el cable de la CSU o DSU al router no está protegido Un problema de densidad en el link T1 (especificación de entramado o codificación incorrecta) El paquete finalizado en medio de una causa típica de transmisión es un reinicio de la interfaz o un error de entramado Problema de hardware: circuito defectuoso, CSU/DSU defectuosa o interfaz de envío incorrecta en el router remoto	Asegúrese de que todos los dispositivos estén correctamente configurados para utilizar un reloj de línea común. Establezca SCTE en la DSU local y remota. Si su CSU/DSU no admite SCTE, consulte la sección "Invertir el reloj de transmisión" más adelante en este capítulo. Escuche el cable si es necesario. Asegúrese de que el cable esté dentro de la longitud recomendada: no más de 50 pies (15,24 metros) o 25 pies (7,62 metros) para el enlace T1. Asegúrese de que todas las conexiones son correctas. Verifique el hardware en ambos extremos del link. Intercambie el equipo defectuoso según sea necesario. Disminuya las tasas de datos y compruebe si los abortos disminuyen. Utilice las pruebas de loopback locales y remotas para determinar dónde se producen los abortos. Consulte la sección "Pruebas de línea serial especiales" más adelante en este capítulo. Póngase en contacto con su línea arrendada u otro servicio de operador y pídale que realice pruebas de integridad en la línea.

Líneas de serie: Aumento de los Reinicios de la Interfaz en el Link Serial

Los reinicios de la interfaz que aparecen en la salida del comando EXEC show interfaces serial (consulte la figura 15-1) son el resultado de paquetes "keep-alive" perdidos.

Síntoma: Un número creciente de interfaces se restablece en el link serial.

Tabla 15-6: Esta tabla describe los posibles problemas que pueden causar este síntoma y sugiere soluciones.

Posible problema

Solución

Los siguientes problemas pueden dar lugar a este síntoma: Congestión en el link (normalmente asociada a caídas de salida) Línea incorrecta que provoca transiciones de CD Posible problema de hardware en la CSU, la DSU o el switch

Cuando se reinician las interfaces, examine otros campos del resultado del comando show interfaces serial para determinar el origen del problema. Suponiendo que se está registrando un aumento en los reinicios de la interfaz, examine los siguientes campos: Si hay un alto número de caídas de salida en el resultado show interfaces serial, consulte la sección "Líneas de Serie: Aumentar las caídas de salida en el link serial", anteriormente en este capítulo. Verifique el campo transiciones de portadora en la pantalla show interfaces serial. Si las transiciones de la portadora son altas mientras se registran los reinicios de la interfaz, es probable que el problema sea un mal link o una mala CSU o DSU. Póngase en contacto con su línea arrendada o servicio de transportista e intercambie el equipo defectuoso según sea necesario. Examine el campo de errores de entrada en la pantalla show interfaces serial. Si los errores de entrada son altos mientras que los reinicios de la interfaz están aumentando, el problema probablemente sea un mal link o una mala CSU/DSU. Póngase en contacto con su línea arrendada u otro servicio de transportista e intercambie el equipo defectuoso según sea necesario.

Líneas de serie: El aumento de las transiciones de operadores cuenta en el link serial

Las transiciones de portadora aparecen en la salida del comando show interfaces serial EXEC siempre que se produce una interrupción en la señal de portadora (como un reinicio de la interfaz en el extremo remoto de un link).

Síntoma: Un número cada vez mayor de transiciones de operador cuentan con el link serial.

La tabla 15-7 describe los posibles problemas que pueden causar este síntoma y sugiere soluciones.

Tabla 15-7: Líneas de serie: El aumento de las transiciones de operadores cuenta en el link serial

Posible problema	Solución
Los siguientes problemas pueden dar lugar a este síntoma: Interrupciones de línea debido a una fuente externa (como separación física del cableado, alarmas T1 rojas o amarillas, o alumbramiento que impacta en algún lugar de la red) Hardware de router, DSU o switch defectuoso	Verifique el hardware en ambos extremos del link. Conecte una caja de escape o un analizador en serie y realice una prueba para determinar el origen de los problemas. Si un analizador o una caja de escape no puede identificar ningún problema externo, verifique el hardware del router. Intercambie el equipo defectuoso según sea necesario.

Uso del comando show controllers

El comando EXEC show controllers es otra herramienta de diagnóstico importante para la resolución de problemas de líneas seriales. La sintaxis de los comandos varía en función de la plataforma:

• Para las interfaces seriales en los Cisco 7000 Series Routers, utilice el comando EXEC show controllers cbus.

• Para los productos de acceso de Cisco, utilice el comando show controllers EXEC.

• Para AGS, CGS y MGS, utilice el comando EXEC show controllers mci.

La figura 15-2 muestra el resultado del comando show controllers cbus EXEC. Este comando se utiliza en los Cisco 7000 Series Routers con la tarjeta Fast Serial Interface Processor (FSIP). Verifique el resultado del comando para asegurarse de que el cable a la unidad de servicio de canal/unidad de servicio digital (CSU/DSU) esté conectado a la interfaz adecuada. También puede comprobar la versión del microcódigo para ver si está actualizada.

Figura 15-2: Salida del Comando show controllers cbus

En productos de acceso como los servidores y routers de acceso de las series Cisco 2000, Cisco 2500, Cisco 3000 y Cisco 4000, utilice el comando show controllers EXEC. La figura 15-3 muestra el resultado del comando show controllers de la interfaz de velocidad básica (BRI) y las interfaces seriales en un servidor de acceso Cisco 2503. (Tenga en cuenta que algunos resultados no se muestran.)

La salida show controllers indica el estado de los canales de interfaz y si un cable está conectado a la interfaz. En la figura 15-3, la interfaz serial 0 tiene un cable DTE RS-232 conectado. La interfaz serial 1 no tiene cable conectado.

La Figura 15-4 muestra el resultado del comando show controllers mci. Este comando se utiliza solamente en los routers AGS, CGS y MGS. Si la interfaz eléctrica se muestra como UNKNOWN (en lugar de V.35, EIA/TIA-449 o algún otro tipo de interfaz eléctrica), es probable que el problema sea un cable conectado incorrectamente. También es posible un mal dispositivo o un problema con el cableado interno de la tarjeta. Si se desconoce la interfaz eléctrica, la pantalla correspondiente para el comando show interfaces serial EXEC mostrará que la interfaz y el protocolo de línea están inactivos.

Figura 15-3: Salida del comando show controllers

Figura 15-4: Salida del Comando show controllers mci

‘Uso de los comandos de depuración’

La salida de los diversos comandos EXEC debug privilegiados proporciona información de diagnóstico relacionada con el estado del protocolo y la actividad de la red para muchos eventos de interconexión.

Precaución: Debido a que se asigna una alta prioridad a la salida de depuración en el proceso de la CPU, puede hacer que el sistema quede inutilizable. Por esta razón, sólo use los comandos de depuración para resolver problemas específicos o durante sesiones de resolución de problemas con el equipo de soporte técnico de Cisco. Es más, es mejor utilizar los comandos de depuración durante los períodos en que hay poco tráfico en la red y menos usuarios. El debugging durante estos períodos disminuye la posibilidad de que la sobrecarga por el mayor procesamiento del comando debug afecte al uso del sistema. Cuando termine de usar un comando debug, recuerde desactivarlo con su comando no debug específico o con el comando no debug all.

Los siguientes comandos debug son útiles para la resolución de problemas seriales y de WAN. Se proporciona más información sobre la función y el resultado de cada uno de estos comandos en la publicación Debug Command Reference:

• debug serial interface - Verifica si los paquetes keepalive HDLC se están incrementando. Si no es así, es probable que haya un problema de sincronización en la tarjeta de interfaz o en la red.

• debug x25 events - Detecta eventos X.25, como la apertura y el cierre de circuitos virtuales conmutados (SVC). La información de "causa y diagnóstico" resultante se incluye con el informe de eventos.

• debug lapb: genera información sobre el procedimiento de acceso al link, equilibrado (LAPB) o nivel 2 X.25.

• debug arp - Indica si el router está enviando información o aprendiendo acerca de los routers (con paquetes ARP) en el otro lado de la nube WAN. Utilice este comando cuando algunos nodos de una red TCP/IP responden pero otros no.

• debug frame-relay lmi - Obtiene información de la Interfaz de administración local (LMI) útil para determinar si un switch de Frame Relay y un router están enviando y recibiendo paquetes LMI.

• debug frame-relay events - Determina si se producen intercambios entre un router y un switch Frame Relay.

• debug ppp negotiation - Muestra los paquetes de protocolo punto a punto (PPP) transmitidos durante el inicio de PPP, donde se negocian las opciones PPP.

• debug ppp packet - Muestra los paquetes PPP que se envían y reciben. Este comando indica el vaciado de paquetes de bajo nivel.

• debug ppp errors - Muestra errores PPP (como tramas ilegales o deformadas) relacionados con el funcionamiento y la negociación de la conexión PPP.

• debug ppp chap: muestra los intercambios de paquetes PPP Challenge Handshake Authentication Protocol (CHAP) y Password Authentication Protocol (PAP).

• debug serial packet: muestra los paquetes del servicio de datos de multidifusión conmutada (SMDS) que se envían y reciben. Esta visualización también imprime mensajes de error para indicar por qué un paquete no se envió o se recibió por error. Para SMDS, el comando vuelca el encabezado SMDS completo y algunos datos de carga útil cuando se transmite o recibe un paquete SMDS.

Uso de pruebas ping extendidas

El comando ping es una prueba útil disponible en los dispositivos de conexión entre redes de Cisco, al igual que en varios sistemas de host. En TCP/IP, esta herramienta de diagnóstico también se conoce como petición de eco del Protocolo de mensajes de control de Internet (ICMP).

Nota: El comando ping es particularmente útil cuando se registran altos niveles de errores de entrada en la visualización show interfaces serial. Vea la Figura 15-1.

Los dispositivos de conexión entre redes Cisco proporcionan un mecanismo para automatizar el envío de paquetes ping en secuencia. La figura 15-5 ilustra el menú utilizado para especificar opciones ping extendidas. Este ejemplo especifica 20 pings sucesivos. Sin embargo, al probar los componentes de la línea serial, debe especificar un número mucho mayor, como pings 1000.

Figura 15-5: Menú de especificación de ping extendido

Realización de Pruebas Ping

En general, realice las pruebas ping de línea serial de la siguiente manera:

1. Coloque la CSU o DSU en el modo de loopback local.

2. Configure el comando ping extendido para enviar diferentes patrones de datos y tamaños de paquete. La figura 15-6 y la figura 15-7 ilustran dos útiles pruebas ping, un ping de todos ceros (1500 bytes) y un ping de todos unos (1500 bytes), respectivamente.

3. Examine el resultado del comando show interfaces serial (consulte la figura 15-1) y determine si los errores de entrada han aumentado. Si los errores de entrada no han aumentado, el hardware local (DSU, cable, tarjeta de interfaz del router) probablemente esté en buenas condiciones.

   Suponiendo que la aparición de un gran número de CRC y errores de entramado haya provocado esta secuencia de prueba, es probable que se produzca un problema de temporización. Verifique la CSU o DSU para ver si hay un problema de temporización. Consulte la sección "Resolución de problemas de temporización" más adelante en este capítulo.

4. Si determina que la configuración de temporización es correcta y funciona correctamente, coloque la CSU o DSU en el modo de loopback remoto.

5. Repita la prueba ping y busque cambios en las estadísticas de errores de entrada.

6. Si aumentan los errores de entrada, hay un problema en la línea serial o en la CSU/DSU. Póngase en contacto con el proveedor de servicios WAN e intercambie la CSU o DSU. Si persisten los problemas, póngase en contacto con su representante de asistencia técnica.

Figura 15-6: Prueba de ping ALl-Zeros de 1500 bytes

Figura 15-7 Prueba de ping de 1500 bytes para todo uno

Resolución de problemas de temporización

Los conflictos de temporización en las conexiones seriales pueden conducir a una pérdida crónica del servicio de conexión o a un rendimiento degradado. Esta sección trata los aspectos importantes de los problemas de temporización: el problema de temporización causa, detecta problemas de temporización, aísla problemas de temporización y resuelve problemas de temporización.

Descripción general de temporización

La CSU/DSU deriva el reloj de datos de los datos que pasan a través de él. Para recuperar el reloj, el hardware CSU/DSU debe recibir al menos un valor de 1 bit por cada 8 bits de datos que pasan a través de él; esto se conoce como densidad. El mantenimiento de la densidad de unos permite al hardware recuperar el reloj de datos de forma fiable.

Las implementaciones de T1 más recientes suelen utilizar el entramado de formato de supertrama extendido (ESF) con codificación binaria de sustitución de ocho ceros (B8ZS). B8ZS proporciona un esquema mediante el cual se sustituye un código especial cada vez que se envían ocho ceros consecutivos a través del link serial. A continuación, este código se interpreta en el extremo remoto de la conexión. Esta técnica garantiza una densidad independiente del flujo de datos.

Las implementaciones T1 más antiguas utilizan la codificación D4, también conocida como formato de supertrama (SF) y la codificación de inversión de marca alternativa (AMI). AMI no utiliza un esquema de codificación como B8ZS. Esto restringe el tipo de datos que se pueden transmitir porque la densidad de unos no se mantiene independientemente del flujo de datos.

Otro elemento importante en las comunicaciones seriales es la temporización de terminal externo de transmisión de reloj en serie (SCTE). SCTE es el reloj que se repite desde el dispositivo de equipo de terminal de datos (DTE) (por ejemplo, un router) al dispositivo de equipo de comunicaciones de datos (DCE) (por ejemplo, la CSU/DSU).

Cuando el dispositivo DCE utiliza SCTE en lugar de su reloj interno para muestrear los datos del DTE, es mejor que pueda muestrear los datos sin errores incluso si hay un cambio de fase en el cable entre la CSU/DSU y el router. El uso de SCTE es altamente recomendado para transmisiones seriales más rápidas que 64 kbps. Si su CSU/DSU no admite SCTE, consulte la sección "Invertir el reloj de transmisión" más adelante en este capítulo.

Causas del problema de temporización

En general, los problemas de temporización en las interconexiones WAN seriales pueden atribuirse a una de las siguientes causas:

• Configuración de DSU incorrecta

• Configuración de CSU incorrecta

• Cables fuera de especificación, es decir, más de 50 pies (15,24 metros) o sin blindaje

• Conexiones ruidosas o deficientes del panel de conexión

• Varios cables conectados a la vez

Detección de problemas de temporización

Para detectar los conflictos de temporización en una interfaz serial, busque los errores de entrada de la siguiente manera:

1. Utilice el comando EXEC show interfaces serial en los routers en ambos extremos del link.

2. Examine el resultado del comando para CRC, errores de entramado y abortos.

3. Si cualquiera de estos pasos indica que hay errores que exceden un rango aproximado del 0,5% del 2,0% del tráfico en la interfaz, es probable que existan problemas de temporización en algún lugar de la WAN.

4. Aísle el origen de los conflictos de temporización como se describe en la siguiente sección, "Aislamiento de problemas de temporización".

5. Omita o repare los paneles de parches defectuosos.

Aislamiento de problemas de temporización

Después de determinar que los conflictos de temporización son la causa más probable de errores de entrada, el siguiente procedimiento le ayudará a aislar el origen de esos errores:

1. Realice una serie de pruebas de ping y loopback (tanto locales como remotas), como se describe en la sección "Pruebas de loopback de CSU y DSU", anteriormente en este capítulo.

2. Determine el final de la conexión que es el origen del problema o si el problema está en la línea. En el modo de loopback local, ejecute diferentes patrones y tamaños en las pruebas ping (por ejemplo, utilice datagramas de 1500 bytes). El uso de un único patrón y tamaño de paquete puede no forzar que se materialicen los errores, particularmente cuando un cable serial al router o CSU/DSU es el problema.

3. Utilice el comando EXEC show interfaces serial y determine si los conteos de errores de entrada están aumentando y dónde se acumulan.

Si los errores de entrada se acumulan en ambos extremos de la conexión, la temporización de la CSU es el problema más probable.

Si sólo un extremo está experimentando errores de entrada, probablemente haya un problema de temporización o cableado de DSU.

Abortos en un extremo sugiere que el otro extremo está enviando información incorrecta o que hay un problema de línea.

Nota: Consulte siempre la salida del comando show interfaces serial (consulte la Figura 15-1) y registre cualquier cambio en los recuentos de errores o observe si el conteo de errores no cambia.

Soluciones de problemas de temporización

Tabla 15-8 Líneas de Serie: Problemas y soluciones de temporización: Esta tabla describe los remedios sugeridos para los problemas de temporización, según la fuente del problema.

Posible problema	Solución
Configuración de CSU incorrecta	Determine si las CSU en ambos extremos coinciden en el origen del reloj (local o de línea). Si las CSU no están de acuerdo, configúrelas para que lo hagan. Normalmente, la línea es la fuente. Verifique la configuración de LBO en la CSU para asegurarse de que la impedancia coincida con la de la línea física. Para obtener información sobre la configuración de la CSU, consulte la documentación de hardware de la CSU.
Configuración de DSU incorrecta	Determine si las DSU en ambos extremos tienen el modo SCTE habilitado. Si SCTE no está habilitado en ambos extremos de la conexión, hágalo. Asegúrese de que se mantenga la densidad de unos. Esto requiere que la DSU utilice los mismos esquemas de entramado y codificación (por ejemplo, ESF y B8ZS) utilizados por la línea arrendada u otro servicio de portadora. Consulte a su proveedor de línea arrendada para obtener información sobre sus esquemas de entramado y codificación. Si el servicio de la portadora utiliza codificación AMI, invierta el reloj de transmisión en ambos lados del link o ejecute la DSU en el modo de material de bits. Para obtener información sobre la configuración de la DSU, consulte la documentación del hardware de la DSU.
El cable al router está fuera de especificación	Si el cable es superior a 15,24 metros, utilice un cable más corto. Si el cable no está blindado, sustitúyalo por un cable blindado.

Inversión del reloj de transmisión

Si intenta establecer conexiones seriales a velocidades superiores a 64 kbps con una CSU/DSU que no admita SCTE, es posible que tenga que invertir el reloj de transmisión en el router. La inversión del reloj de transmisión compensa los cambios de fase entre las señales de datos y de reloj.

El comando específico utilizado para invertir el reloj de transmisión varía entre las plataformas. En un Cisco 7000 Series Router, ingrese el comando invert-transmit-clock interface configuration. Para los Cisco 4000 Series Routers, utilice el comando de configuración de la interfaz dte-invert-txc.

Para asegurarse de que está utilizando la sintaxis de comandos correcta para su router, consulte la guía del usuario para su router o servidor de acceso y las guías de configuración y referencias de comandos de Cisco IOS.

Nota: En las plataformas más antiguas, invertir el reloj de transmisión puede requerir mover un puente físico.

Ajuste de Búfers

La utilización excesiva del ancho de banda (más del 70%) reduce el rendimiento general y puede provocar fallos intermitentes. Por ejemplo, las transmisiones de archivos DECnet pueden estar fallando debido a que los paquetes se descartan en algún lugar de la red.

Si la situación es lo suficientemente mala, debe aumentar el ancho de banda del link. Sin embargo, es posible que no sea necesario o práctico aumentar el ancho de banda. Una manera de resolver los problemas de exceso de utilización de la línea serial marginal es controlar cómo el router utiliza las memorias intermedias de datos.

Precaución: En general, no ajuste las memorias intermedias del sistema a menos que esté trabajando estrechamente con un representante de soporte técnico de Cisco. Puede afectar gravemente al rendimiento del hardware y de la red si ajusta incorrectamente los búfers del sistema en el router.

Utilice una de las tres opciones siguientes para controlar cómo se utilizan los búfers:

• Ajustar parámetros asociados con búferes del sistema

• Especifique el número de paquetes retenidos en colas de entrada o salida (colas de espera)

• Priorizar cómo se coloca el tráfico en cola para la transmisión (cola de salida prioritaria)

Los comandos de configuración asociados con estas opciones se describen en las guías de configuración y las referencias de comandos de Cisco IOS.

La siguiente sección se centra en la identificación de situaciones en las que es probable que se apliquen estas opciones y en la definición de cómo puede utilizar estas opciones para ayudar a resolver los problemas de conectividad y rendimiento en las interconexiones serial/WAN.

Ajuste de las memorias intermedias del sistema

Hay dos tipos de búfer generales en los routers Cisco: memorias intermedias de hardware y memorias intermedias del sistema. Los administradores del sistema solo pueden configurar directamente los búfers del sistema. Los buffers de hardware se utilizan específicamente como los buffers de recepción y transmisión asociados con cada interfaz y (en ausencia de cualquier configuración especial) son administrados dinámicamente por el propio software del sistema.

Las memorias intermedias del sistema están asociadas con la memoria principal del sistema y se asignan a bloques de memoria de diferentes tamaños. Un comando útil para determinar el estado de las memorias intermedias del sistema es el comando EXEC show buffers. La Figura 15-8 muestra el resultado del comando show buffers.

Figura 15-8 Resultado del comando show buffers

En la salida de show buffers:

• total - Identifica el número total de memorias intermedias en el conjunto, incluyendo memorias intermedias usadas y no usadas.

• permanente - Identifica el número permanente de búfers asignados en el conjunto. Estas memorias intermedias están siempre en el conjunto y no se pueden recortar.

• en lista libre - Identifica el número de búfers actualmente en el conjunto que están disponibles para su uso.

• min - Identifica el número mínimo de búfers que el Procesador de Ruta (RP) debe intentar mantener en la lista libre:

  • Se usa el parámetro min para anticipar la demanda de memoria intermedia desde los recursos compartidos en cualquier momento.

  • Si el número de memorias intermedias en la lista libre cae por debajo del valor min, el RP intenta crear más memorias intermedias para ese conjunto.

• max allowed - Identifica el número máximo de búfers permitidos en la lista libre:

  • El parámetro max allowed evita que un conjunto monopolice búfers que ya no necesita y libera esta memoria al sistema para su uso posterior.

  • Si el número de memorias intermedias en la lista libre es mayor que el valor máximo permitido, el RP debe intentar recortar las memorias intermedias del conjunto.

• resultados - Identifica el número de búfers que se han solicitado desde el conjunto. El contador de aciertos otorga un mecanismo para determinar qué conjunto debe cumplir con la mayor demanda para las memorias intermedias.

• errores - Identifica el número de veces que se ha solicitado un buffer y el RP detectó que se necesitaban búferes adicionales. (En otras palabras, el número de búfers en la lista libre ha caído por debajo del min.) El contador de errores representa la cantidad de oportunidades en que RP ha sido forzado a crear memorias intermedias adicionales.

• trims - Identifica el número de búfers que el RP ha recortado del conjunto cuando el número de búfers en la lista libre excedió el número máximo de búfers permitidos.

• creado - Identifica el número de búfers que se han creado en el conjunto. El RP crea búfers cuando la demanda de memorias intermedias ha aumentado hasta que el número de memorias intermedias en la lista libre es menor que el número mínimo de memorias intermedias y/o se produce una pérdida debido a cero memorias intermedias en la lista libre.

• fallas - Identifica el número de fallas para conceder un buffer a un solicitante incluso después de intentar crear un buffer adicional. El número de fallas representa el número de paquetes que se han descartado debido a la escasez de búfer.

• no memory - Identifica el número de fallas causadas por memoria insuficiente para crear búfers adicionales.

La salida del comando show buffers en la Figura 15-8 indica números altos en los campos trims y create para búferes grandes. Si recibe números altos en estos campos, puede aumentar el rendimiento del link serial aumentando el valor máx. libre configurado para las memorias intermedias del sistema. trims identifica el número de memorias intermedias que el RP ha recortado del conjunto cuando el número de memorias intermedias en la lista libre excedió el número de búfers máximos permitidos.

Utilice el comando de configuración global buffers max free number para aumentar el número de búfers libres del sistema. El valor que configure debe ser aproximadamente el 150 por ciento de la cifra indicada en el campo total del resultado del comando show buffers. Repita este proceso hasta que el resultado show buffers ya no indique los recortes y los búfers creados.

Si la salida del comando show buffers muestra una gran cantidad de fallas en el campo (sin memoria) (consulte la última línea de salida en la Figura 15-8), debe reducir el uso de las memorias intermedias del sistema o aumentar la cantidad de memoria compartida o principal (RAM física) en el router. Llame a su representante de soporte técnico para obtener asistencia.

Implementar límites de cola de espera

Las colas de espera son memorias intermedias utilizadas por cada interfaz del router para almacenar los paquetes salientes o entrantes. Utilice el comando de configuración de interfaz hold-queue para aumentar el número de paquetes de datos en cola antes de que el router descarte paquetes. Aumente estas colas en pequeños incrementos (por ejemplo, el 25%) hasta que ya no vea caídas en el resultado show interfaces. El límite de cola de retención de salida predeterminado es 100 paquetes.

Nota: El comando hold-queue se utiliza para paquetes conmutados por proceso y actualizaciones periódicas generadas por el router.

Utilice el comando hold-queue para evitar que se descarten los paquetes y para mejorar el rendimiento del link serial bajo las siguientes condiciones:

• Tiene una aplicación que no puede tolerar caídas y el protocolo puede tolerar retrasos más prolongados. DECnet es un ejemplo de un protocolo que cumple ambos criterios. El transporte de área local (LAT) no lo hace porque no tolera retrasos.

• La interfaz es muy lenta. El ancho de banda es un uso bajo o anticipado que probablemente exceda esporádicamente el ancho de banda disponible.

Nota: Cuando se aumenta el número especificado para una cola de retención de salida, es posible que deba aumentar el número de búfers del sistema. El valor utilizado depende del tamaño de los paquetes asociados con el tráfico anticipado para la red.

Uso de la cola prioritaria para reducir los cuellos de botella

La cola de prioridad es un mecanismo de control basado en listas que permite priorizar el tráfico de una interfaz a otra. La colocación en cola de prioridad implica dos pasos:

1. Cree una lista de prioridades por tipo de protocolo y nivel de prioridad.

2. Asigne la lista de prioridades a una interfaz específica.

Ambos pasos utilizan versiones del comando de configuración global priority-list. Además, se puede aplicar un control de tráfico adicional haciendo referencia a los comandos de configuración access-list global desde las especificaciones priority-list. Para ver ejemplos de definición de listas de prioridad y para obtener detalles sobre la sintaxis de comandos asociada a la cola de prioridad, consulte las guías de configuración y las referencias de comandos de Cisco IOS.

Nota: La cola de prioridad crea automáticamente cuatro colas de espera de distintos tamaños. Esto anula cualquier especificación de cola de espera incluida en su configuración.

Utilice la cola de prioridad para evitar que se descarten los paquetes y para mejorar el rendimiento del link serial en las siguientes condiciones:

• Cuando la interfaz es lenta, se transmiten varios tipos de tráfico y se desea mejorar el rendimiento del tráfico terminal.

• Si tiene un link serial que experimenta intermitentemente cargas muy pesadas (como transferencias de archivos que ocurren en momentos específicos), la colocación en cola de prioridad ayudará a seleccionar qué tipos de tráfico se deben descartar en periodos de tráfico alto.

En general, comience por el número predeterminado de colas al implementar colas de prioridad. Después de habilitar la cola de prioridad, monitoree las caídas de salida con el comando show interfaces serial EXEC. Si observa que las caídas de salida se producen en la cola de tráfico especificada como alta prioridad, aumente el número de paquetes que se pueden poner en cola (usando la opción de palabra clave queue-limit del comando de configuración global priority-list). Los argumentos queue-limit predeterminados son 20 paquetes para la cola de alta prioridad, 40 para media, 60 para normal y 80 para baja.

Nota: Cuando se puentea tráfico LAT de Digital Equipment Corporation (DEC), el router debe descartar muy pocos paquetes, o las sesiones LAT pueden terminar inesperadamente. Una profundidad de cola de alta prioridad de aproximadamente 100 (especificada con la palabra clave queue-limit) es un valor de trabajo típico cuando su router está descartando paquetes de salida y las líneas seriales están sujetas a una utilización de ancho de banda de aproximadamente el 50 por ciento. Si el router está descartando paquetes y está al 100% de utilización, necesita otra línea.

Otra herramienta para aliviar la congestión cuando el bridging DEC LAT es la compresión LAT. Puede implementar la compresión LAT con el comando interface configuration bridge-group group lat-compression.

Pruebas de línea serial especiales

Además de las capacidades básicas de diagnóstico disponibles en los routers, se puede utilizar una variedad de herramientas y técnicas complementarias para determinar las condiciones de los cables, equipos de conmutación, módems, hosts y hardware de interconexión remota. Para obtener más información, consulte la documentación de su CSU, DSU, analizador en serie u otro equipo.

Pruebas de Loopback de CSU y DSU

Si la salida del comando EXEC show interfaces serial indica que la línea serial está activa pero el protocolo de línea está inactivo, utilice las pruebas de loopback CSU/DSU para determinar el origen del problema. Realice primero la prueba de loop local y luego la prueba remota. La figura 15-9 ilustra la topología básica de las pruebas de loopback local y remoto de CSU/DSU.

Figura 15-9: Pruebas de Loopback Local y Remoto CSU/DSU

Nota: Estas pruebas son de naturaleza genérica y suponen el acoplamiento del sistema de conexión entre redes a una CSU o DSU. Sin embargo, las pruebas son esencialmente las mismas para la conexión a un multiplexor con funcionalidad CSU/DSU integrada. Debido a que no existe el concepto de loopback en los entornos de red conmutada por paquetes (PSN) X.25 o Frame Relay, las pruebas de loopback no se aplican a las redes X.25 y Frame Relay.

Pruebas de Loopback Local CSU y DSU para Links HDLC o PPP

A continuación se incluye un procedimiento general para realizar pruebas de loopback junto con las capacidades de diagnóstico del sistema integradas:

1. Coloque la CSU/DSU en el modo de bucle local (consulte la documentación del proveedor). En el modo de loop local, se termina el uso del reloj de línea (desde el servicio T1) y la DSU se ve obligada a utilizar el reloj local.

2. Utilice el comando EXEC show interfaces serial para determinar si el estado de línea cambia de "protocolo de línea inactiva" a "protocolo de línea activo (loop)" o si permanece inactivo.

3. Si el protocolo de línea aparece cuando la CSU o DSU está en el modo de loopback local, esto sugiere que el problema está ocurriendo en el extremo remoto de la conexión serial. Si la línea de estado no cambia de estado, existe un posible problema en el router, el cable de conexión o la CSU/DSU.

4. Si el problema parece ser local, utilice el comando EXEC debug serial interface privilegiado.

5. Saque la CSU/DSU del modo de loop local. Cuando el protocolo de línea está inactivo, la salida del comando debug serial interface indicará que los contadores de keepalive no están aumentando.

6. Vuelva a colocar la CSU/DSU en el modo de loop local. Esto debería hacer que los paquetes keepalive comiencen a aumentar. Específicamente, los valores de mineseen y yourseen keepalives aumentarán cada 10 segundos. Esta información aparecerá en el resultado debug serial interface.

   Si las señales de mantenimiento no aumentan, puede haber un problema de temporización en la tarjeta de interfaz o en la red. Para obtener información sobre cómo corregir los problemas de temporización, consulte la sección "Resolución de problemas de temporización", anteriormente en este capítulo.

   Si las señales de mantenimiento no aumentan, puede haber un problema de temporización en la tarjeta de interfaz o en la red. Para obtener información sobre cómo corregir los problemas de temporización, consulte la sección "Resolución de problemas de temporización", anteriormente en este capítulo.

7. Compruebe el router local, el hardware CSU/DSU y los cables conectados. Asegúrese de que los cables estén dentro de las longitudes recomendadas: no más de 15,24 metros o 25 pies (7,62 metros) para un link T1. Asegúrese de que los cables están conectados a los puertos adecuados. Intercambie el equipo defectuoso según sea necesario.

La figura 15-10 muestra el resultado del comando debug serial interface para una conexión serial HDLC, con señales de mantenimiento perdidas que hacen que la línea se caiga y la interfaz se reinicie.

Figura 15-10: Salida del Comando debug serial interface

Pruebas de Loopback Remoto CSU y DSU para Links HDLC o PPP

Si determina que el hardware local funciona correctamente, pero aún así encuentra problemas al intentar establecer conexiones a través del link serial, intente utilizar la prueba de loopback remoto para aislar la causa del problema.

Nota: Esta prueba de loopback remoto supone que se está utilizando la encapsulación HDLC y que la prueba de loop local anterior se realizó inmediatamente antes de esta prueba.

Se requieren los siguientes pasos para realizar pruebas de loopback:Se requieren los siguientes pasos para realizar pruebas de loopback:

1. Ponga la CSU o DSU remota en el modo de loopback remoto (consulte la documentación del proveedor).

2. Mediante el comando EXEC show interfaces serial, determine si el protocolo de línea permanece activo con la línea de estado que indica "Serial x está activo, el protocolo de línea está activo (con loop)" o si cae con la línea de estado que indica "Line Protocol is down".

3. Si el protocolo de línea permanece activo (con loop), el problema probablemente se encuentre en el extremo remoto de la conexión serial (entre la CSU/DSU remota y el router remoto). Realizar ambas pruebas, remotas y locales, en el extremo remoto para aislar la causa del problema.

4. Si el estado de la línea cambia a "line protocol is down" (el protocolo de línea está inactivo) cuando se activa el modo de loopback remoto, asegúrese de que la densidad de uno se mantenga correctamente. La CSU/DSU debe configurarse para utilizar los mismos esquemas de entramado y codificación que utiliza la línea arrendada u otro servicio de portadora (por ejemplo, ESF y B8ZS).

5. Si persisten los problemas, póngase en contacto con su administrador de red WAN o con la organización de servicios WAN.

Información detallada sobre el comando show interfaces serial

Las subsecciones siguientes tratan los parámetros del comando show interfaces serial, la descripción de sintaxis, la visualización de resultados de ejemplo y las descripciones de campos.

show interfaces serial Parameters

Para mostrar información sobre una interfaz serial, utilice el comando EXEC privilegiado show interfaces serial:

show interfaces serial [number] [accounting]
show interfaces serial [number [:channel-group] [accounting] (Cisco 4000 series)
show interfaces serial [slot | port [:channel-group]] [accounting] (Cisco 7500 series)
show interfaces serial [type slot | port-adapter | port] [serial] 
(ports on VIP cards in the Cisco 7500 series)
show interfaces serial [type slot | port-adapter | port] [:t1-channel] [accounting | crb]
(CT3IP in Cisco 7500 series)

Descripción de la Sintaxis

• number-Opcional. Número de puerto.

• accounting-Opcional. Muestra el número de paquetes de cada tipo de protocolo que se han enviado a través de la interfaz.

• :channel-group -Opcional. En la serie Cisco 4000 con un NPM o una serie Cisco 7500 con un MIP, especifica el número de grupo de canales T1 en el rango de 0 a 23, definido con el comando de configuración del controlador de grupo de canales.

• slot -Hace referencia al manual de hardware apropiado para obtener información sobre la ranura.

• port -Hace referencia al manual de hardware apropiado para la información del puerto.

• port-adapter -Hace referencia al manual de hardware apropiado para obtener información sobre la compatibilidad del adaptador de puerto.

• :t1-channel -Opcional. Para el CT3IP, el canal T1 es un número entre 1 y 28.

• Los canales T1 en el CT3IP se numeran del 1 al 28 en lugar del esquema más tradicional basado en cero (de 0 a 27) utilizado con otros productos de Cisco. Esto es para asegurar la consistencia con los esquemas de numeración de la compañía telefónica para los canales T1 dentro del equipo T3 canalizado.

• crb-Opcional. Muestra información de ruteo y puenteo de la interfaz.

Modo de comando

EXEC privilegiado

Pautas de uso

Este comando apareció primero en Cisco IOS Release 10.0 para Cisco 4000 Series. Apareció por primera vez en Cisco IOS Release 11.0 para Cisco 7000 Series, y se modificó en Cisco IOS Release 11.3 para incluir el CT3IP.

Muestra

A continuación se muestra un ejemplo de salida del comando show interfaces para una interfaz serial sincrónica:

Router# show interfaces serial
Serial 0 is up, line protocol is up
   Hardware is MCI Serial
   Internet address is 150.136.190.203, subnet mask is 255.255.255.0
   MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
   Encapsulation HDLC, loopback not set, keepalive set (10 sec)
   Last input 0:00:07, output 0:00:00, output hang never
   Output queue 0/40, 0 drops; input queue 0/75, 0 drops
   Five minute input rate 0 bits/sec, 0 packets/sec
   Five minute output rate 0 bits/sec, 0 packets/sec
       16263 packets input, 1347238 bytes, 0 no buffer
       Received 13983 broadcasts, 0 runts, 0 giants
       2 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 2 abort
1 carrier transitions 
     22146 packets output, 2383680 bytes, 0 underruns
     0 output errors, 0 collisions, 2 interface resets, 0 restarts

Descripción del campo

Tabla 15-9: show interfaces serial Field Descriptions - esta tabla describe campos significativos mostrados en el resultado.

Campo	Descripción
Serie...es {up | down}...está administrativamente inactivo	Indica si el hardware de la interfaz está actualmente activo (la detección de la portadora está presente) o si ha sido retirado por un administrador.
el protocolo de línea está {up | down}	Indica si los procesos de software que manejan el protocolo de línea consideran la línea utilizable (es decir, las señales de mantenimiento son exitosas) o si ha sido eliminada por un administrador.
el protocolo de línea está {up | down}	Indica si los procesos de software que manejan el protocolo de línea consideran la línea utilizable (es decir, las señales de mantenimiento son exitosas) o si ha sido eliminada por un administrador.
El hardware es	Especifica el tipo de hardware.
La dirección de Internet es	Especifica la dirección de Internet y la máscara de subred.
MTU (unidad de transmisión básica)	Unidad máxima de transmisión de la interfaz.
BW	Indica el valor del parámetro de ancho de banda que se ha configurado para la interfaz (en kilobits por segundo). El parámetro de ancho de banda se utiliza sólo para calcular las métricas IGRP. Si la interfaz está conectada a una línea serial con una velocidad de línea que no coincide con la predeterminada (1536 o 1544 para T1 y 56 para una línea serial sincrónica estándar), utilice el comando bandwidth para especificar la velocidad de línea correcta para esta línea serial.
DLY	Retraso de la interfaz en microsegundos.
solo	Fiabilidad de la interfaz como una fracción de 255 (255/255 es 100 por ciento de confiabilidad), calculada como un promedio exponencial a lo largo de cinco minutos.
carga	Fiabilidad de la interfaz como una fracción de 255 (255/255 es 100 por ciento de confiabilidad), calculada como un promedio exponencial a lo largo de cinco minutos.
‘Encapsulación	Método de encapsulación asignado a la interfaz.
loopback	Indica si el loopback está configurado.
keepalive	Indica si las señales de mantenimiento están configuradas.
Última entrada	Número de horas, minutos y segundos desde que una interfaz recibió correctamente el último paquete. Útil para saber cuándo falló una interfaz muerta.
Última salida	Número de horas, minutos y segundos desde que el último paquete fue transmitido con éxito por una interfaz.Número de horas, minutos y segundos desde que el último paquete fue transmitido con éxito por una interfaz.
salto de salida	Número de horas, minutos y segundos (o nunca) desde la última vez que se restableció la interfaz debido a una transmisión que tardó demasiado. Cuando el número de horas en cualquiera de los últimos campos excede de 24, se imprime el número de días y horas. Si ese campo se desborda, se imprimen asteriscos.
Cola de salida, descarta cola de entrada, descarta	Número de paquetes en colas de salida y de entrada. A cada número le sigue una barra diagonal, el tamaño máximo de la cola y el número de paquetes porque la cola está llena.
Velocidad de entrada de 5 minutos Velocidad de salida de 5 minutos	Promedio de bits y paquetes transmitidos por segundo en los últimos cinco minutos. Las velocidades de entrada y salida de cinco minutos deben utilizarse sólo como una aproximación del tráfico por segundo durante un período de cinco minutos determinado. Estas tasas son medias ponderadas exponencialmente con una constante de tiempo de cinco minutos. Un período de cuatro constantes de tiempo debe pasar antes de que el promedio esté dentro del 2% de la velocidad instantánea de un flujo uniforme de tráfico durante ese período.
entrada de paquetes	Número total de paquetes sin errores recibidos por el sistema.
bytes	Número total de bytes, incluidos los datos y la encapsulación MAC, en los paquetes sin errores recibidos por el sistema.
no buffer	Número de paquetes recibidos descartados porque no había espacio de búfer en el sistema principal. Comparar con contador ignorado. Las tormentas de difusión en las redes Ethernet y las ráfagas de ruido en las líneas seriales son a menudo responsables de la ausencia de eventos de búfer de entrada.
Recibido... difusiones	Número total de paquetes de difusión o multidifusión recibidos por la interfaz.
fragmentos minúsculos	Número de paquetes descartados porque son menores que el tamaño mínimo del paquete del medio.
gigantes	Cantidad de paquetes descartados porque exceden el tamaño máximo de paquete del medio.
errores de entrada	Número total de recuentos de no búfer, fragmentos minúsculos, gigantes, CRC, tramas, desbordamientos, ignorados y abortos. Otros errores relacionados con la entrada también pueden incrementar el recuento, por lo que esta suma puede no estar en equilibrio con los otros recuentos.
CRC	La verificación de redundancia cíclica generada por la estación de origen o el dispositivo de extremo lejano no coincide con la suma de comprobación calculada a partir de los datos recibidos. En un link serial, los CRC normalmente indican ruido, aciertos de ganancia u otros problemas de transmisión en el link de datos.
trama	Número de paquetes recibidos incorrectamente con un error CRC y un número no entero de octetos. En una línea serial, esto suele ser el resultado de ruido u otros problemas de transmisión.
desbordamiento	Cantidad de veces que el hardware del receptor serial no pudo entregar los datos recibidos a un buffer de hardware porque la velocidad de entrada excedió la capacidad del receptor para manejar los datos.
ignorado	Cantidad de paquetes recibidos ignorados por la interfaz porque el hardware de la interfaz se quedó corto en los búferes internos. Las tormentas de difusión y las ráfagas de ruido pueden hacer que aumente el recuento ignorado.
abort	Secuencia ilegal de un bit en una interfaz serial. Esto generalmente indica un problema de temporización entre la interfaz serial y el equipo de link de datos.
transiciones de portadora	Cantidad de veces que la señal de detección de la portadora de una interfaz serial ha cambiado el estado. Por ejemplo, si la función de detección de portadora de datos (DCD) se desactiva y se activa, el contador de transición de portadora se incrementará dos veces. Indica problemas de módem o línea si la portadora detecta que la línea está cambiando a menudo.
Salida de paquetes	Número total de mensajes transmitidos por el sistema.
resultado de bytes	Número total de bytes, incluidos los datos y la encapsulación MAC, transmitidos por el sistema.
infrarrojos	Cantidad de veces que el transmisor ha estado funcionando más rápido de lo que el router puede manejar. Es posible que esto nunca se informe en algunas interfaces.
errores de salida	Suma de todos los errores que impidieron la transmisión final de datagramas fuera de la interfaz que se examina. Tenga en cuenta que esto puede no estar en equilibrio con la suma de los errores de salida enumerados porque algunos datagramas pueden tener más de un error y otros pueden tener errores que no caen en ninguna de las categorías específicamente tabuladas.
colisiones	Número de mensajes retransmitidos debido a una colisión Ethernet. Esto suele ser el resultado de una LAN sobreextendida (es decir, un cable Ethernet o transceiver demasiado largo, más de dos repetidores entre estaciones o demasiados transceptores de varios puertos en cascada). Algunas colisiones son normales. Sin embargo, si la tasa de colisión alcanza aproximadamente el 4% o el 5%, debe considerar verificar que no haya ningún equipo defectuoso en el segmento y/o mover algunas estaciones existentes a un nuevo segmento. Un paquete que colisiona se cuenta sólo una vez en los paquetes de salida.
interface resets	Cantidad de veces que una interfaz se ha restablecido completamente. Esto puede ocurrir si los paquetes en cola para la transmisión no se enviaron dentro de varios segundos. En una línea serial, esto puede ser causado por un módem que no funciona correctamente y que no suministra la señal del reloj de transmisión, o por un problema de cable. Si el sistema observa que el portador detecta la línea de una interfaz serial pero el protocolo de línea está inactivo, reinicia periódicamente la interfaz en un esfuerzo por reiniciarla. Los reinicios de la interfaz también pueden ocurrir cuando una interfaz posee loopback o está apagada.
reinicios	Cantidad de veces que se reinició el controlador debido a errores.
indicaciones de alarma, alarmas remotas, LOF RX, LOS	Número de alarmas CSU/DSU y número de casos de pérdida de trama de recepción y pérdida de señal de recepción.
BER inactivo, NELR inactivo, FELR inactivo	Estado de los contadores G.703-E1 para la alarma de tasa de error de bits (BER), el mando a distancia de bucle de extremo cercano (NELR) y el mando a distancia de bucle de extremo lejano (FELR). Tenga en cuenta que no puede establecer NELR ni FELR.

Resolución de problemas T1

En esta sección se describen las técnicas y procedimientos para solucionar problemas de circuitos T1 para clientes de acceso telefónico.

Resolución de problemas mediante el comando show controller t1

Este comando muestra el estado del controlador que es específico del hardware del controlador. La información mostrada es generalmente útil para las tareas de diagnóstico realizadas únicamente por el personal de soporte técnico.

El NMP (Procesador de administración de red) o MIP (Procesador de interfaz multicanal) pueden consultar los adaptadores de puerto para determinar su estado actual. Ejecute un comando show controller t1 para mostrar estadísticas sobre el link T1.

Si especifica una ranura y un número de puerto, se mostrarán estadísticas para cada período de 15 minutos. El comando show controller t1 EXEC proporciona información para resolver problemas lógicos de capa física y de capa de link de datos. Esta sección describe cómo resolver problemas lógicamente usando el comando show controller t1.

La mayoría de los errores de T1 son causados por líneas mal configuradas. Asegúrese de que la codificación de línea, la alineación de tramas y el origen del reloj están configurados de acuerdo con lo que el proveedor de servicios recomienda.

show controller t1 Condiciones

El controlador T1 puede estar en uno de los tres estados siguientes.

• Bajo rendimiento administrativo

• Down (inactivo)

• En funcionamiento

¿Está el controlador T1 administrativamente inactivo?

El controlador se encuentra administrativamente inactivo cuando se ha apagado manualmente. Debe reiniciar el controlador para corregir este error.

1. Introduzca el modo de activación.

   maui-nas-03>en
   Password: 
   maui-nas-03#

2. Ingrese al modo de configuración global.

   maui-nas-03#configure terminal
   Enter configuration commands, one per line. End with CNTL/Z.
   maui-nas-03(config)#

3. Ingrese al modo de configuración del controlador.

   maui-nas-03(config)#controller t1 0
   maui-nas-03(config-controlle)#

4. Reinicie el controlador.

   maui-nas-03(config-controlle)#shutdown
   maui-nas-03(config-controlle)#no shutdown
   

¿Está la línea arriba?

Si el controlador T1 y la línea no están activos, verifique si uno de los siguientes mensajes aparece en el resultado show controller t1 EXEC:

• El receptor tiene una pérdida de trama

• El receptor tiene una pérdida de señal

Si el receptor T1 tiene pérdida de trama:

Siga estos pasos si el receptor T1 tiene pérdida de trama:

1. Verifique si el formato de entramado configurado en el puerto coincide con el formato de entramado de la línea. Puede verificar el formato de entramado del controlador desde la configuración en ejecución o el resultado del comando show controller t1.

   Para cambiar el formato de entramado, utilice el {SF de entramado | ESF} en el modo de configuración del controlador como se muestra a continuación:

   maui-nas-03#configure terminal
   

   Ingrese los comandos de configuración, uno por línea. Finalizar con CNTL/Z.

   maui-nas-03(config)#controller t1 0
   maui-nas-03(config-controlle)#framing esf
   

2. Intente con el otro formato de entramado para ver si se borra la alarma.

3. Cambie la configuración de creación de línea utilizando la longitud de cable {long | short} .

La generación de línea (LBO) compensa la pérdida de decibelios en función de la distancia del dispositivo al primer repetidor del circuito. Una distancia más larga del dispositivo al repetidor requiere que se aumente la potencia de la señal del circuito para compensar la pérdida a esa distancia.

Consulte a su proveedor de servicios y a la Referencia de Comandos de Cisco IOS™ para obtener más información sobre la configuración de buildout.

Si esto no soluciona el problema, vaya a la sección "Si el receptor T1 tiene pérdida de señal" que aparece a continuación.

Si el receptor T1 tiene pérdida de señal:

Siga estos pasos si el receptor T1 tiene pérdida de señal:

1. Asegúrese de que el cable entre el puerto de interfaz y el equipo del proveedor de servicios T1 (o equipo terminal T1) esté conectado correctamente. Compruebe si el cable está conectado a los puertos correctos. Si es necesario, corrija las conexiones de cable.

2. Compruebe la integridad del cable. Busque interrupciones u otras anormalidades físicas en el cable. Asegúrese de que las clavijas están configuradas correctamente. Si es necesario, sustituya el cable.

3. Compruebe los conectores del cable. Una inversión de los pares de transmisión y recepción o un par de recepción abierto puede causar errores. Establezca el par de recepción en las líneas 1 y 2. Establezca el par de transmisión en las líneas 4 y 5.

   Los pines de una toma RJ-45 se numeran del 1 al 8. El pin 1 es el pin más a la izquierda cuando se mira el conector con los pines metálicos que se encuentran frente a usted. Consulte la siguiente figura.

   Figura 15-10: Cable RJ-45

   

4. Intente utilizar un cable transpuesto.

Ejecute el comando show controller t1 EXEC después de cada paso para verificar si el controlador muestra algún error.

Verifique si la línea está en modo loopback desde el resultado show controller t1. Una línea debe estar en modo loopback solamente para fines de prueba.

Para desactivar el loopback, utilice el comando no loopback en el modo de configuración del controlador como se muestra a continuación:

maui-nas-03(config-controlle)#no loopback

Si el controlador muestra cualquier alarma:

Verifique el resultado del comando show controller para ver si hay alarmas mostradas por el controlador.

Ahora debatiremos varias alarmas y el procedimiento necesario para corregirlas.

Señal de indicación de alarma de recepción (RX) (azul):

Una señal de indicación de alarma recibida (AIS) significa que se produce una alarma en la línea ascendente del equipo conectado al puerto.

1. Verifique si el formato de entramado configurado en el puerto coincide con el formato de entramado de la línea. Si no es así, cambie el formato de entramado en el controlador para que coincida con el de la línea.

2. Póngase en contacto con su proveedor de servicios para comprobar si hay errores de configuración en la compañía telefónica.

Indicación De Alarma Remota (RAI) De Recepción (Rx) (Amarilla):

Una RAI recibida significa que el equipo de extremo lejano tiene un problema con la señal que recibe de su equipo ascendente.

1. Introduzca un cable externo de loopback en el puerto. Para crear un conector de loopback, consulte la sección "Creación de un conector de loopback", más adelante en el capítulo.

2. Compruebe si hay alarmas. Si no ve ninguna alarma, entonces es probable que el hardware local esté en buenas condiciones. En ese caso:

   1. Inspeccione el cableado Consulte la sección "Si el receptor T1 tiene pérdida de señal" para obtener más información.

   2. Controle las configuraciones del extremo remoto y verifique que coincidan con las configuraciones de su puerto.

   3. Si el problema continúa, contacte a su proveedor de servicio.

3. Elimine el conector de loopback y vuelva a conectar su línea T1.

4. Inspeccione el cableado Consulte la sección "Si el receptor T1 tiene pérdida de señal" para obtener más información.

5. Apague y encienda el router.

6. Conecte la línea T1 a un puerto diferente. Configure el puerto con los mismos parámetros que el de la línea. Si el problema no persiste, la falla se encuentra en el puerto uno:

   1. Vuelva a conectar la línea T1 al puerto original.

   2. Vaya a la sección "Resolución de problemas de eventos de error de T1".

      Si el problema persiste, entonces:

7. Realice una prueba de loop de hardware como se describe en la sección "Realización de la prueba de loopback de hardware".

8. Reemplace la tarjeta de controlador T1

9. Vaya a la sección "Resolución de problemas de eventos de error de T1".

Alarma remota de envío del transmisor (rojo):

Se declara una alarma roja cuando la CSU no puede sincronizarse con el patrón de entramado en la línea T1.

1. Verifique si el formato de entramado configurado en el puerto coincide con el formato de entramado de la línea. Si no cambia el formato de entramado en el controlador para que coincida con el de la línea.

2. Controle las configuraciones del extremo remoto y verifique que coincidan con las configuraciones de su puerto.

3. Contacte a su proveedor de servicios.

Indicación De Alarma Remota (RAI) De Transmisión (Tx) (Amarilla):

Una RAI transmitida en la interfaz indica que la interfaz tiene un problema con la señal que recibe del equipo de extremo lejano.

1. Controle las configuraciones del extremo remoto y verifique que coincidan con las configuraciones de su puerto.

2. Una RAI de transmisión debe ir acompañada de otra alarma que indique la naturaleza del problema que el puerto/tarjeta T1 está teniendo con la señal del equipo de extremo lejano.

Solucione los problemas de esa condición para resolver el RAI de transmisión.

AIS de transmisión (Tx) (Azul):

Siga estos pasos para corregir el AIS de transmisión (Tx) (azul).

1. Verifique si el formato de entramado configurado en el puerto coincide con el formato de entramado de la línea. Si no es así, corrija la discordancia.

2. Apague y encienda el router.

3. Conecte la línea T1 a un puerto diferente. Configure el puerto con los mismos parámetros que el de la línea.

4. Realice una prueba de loop de hardware como se describe en la sección "Realización de la prueba de loopback de hardware".

5. Reemplace la tarjeta de controlador T1

6. Vaya a la sección "Resolución de problemas de eventos de error de T1".

Resolución de problemas de eventos de error T1

El comando show controller t1 EXEC proporciona mensajes de error que se pueden utilizar para resolver problemas. Ahora hablaremos de varios mensajes de error y cómo corregir los errores.

Para ver si los contadores de errores aumentan, ejecute el comando show controller t1 repetidamente. Observe los valores de los contadores para el intervalo actual

Consulte a su proveedor de servicios para obtener información sobre la configuración de la codificación de líneas y la alineación de tramas. Una buena regla general es utilizar la codificación de línea B8ZS con entramado ESF y codificación de línea AMI con entramado SF.

El contador de segundos deslizantes aumenta:

La presencia de deslizamientos en una línea T1 indica un problema de temporización. El proveedor T1 (Telco) proporcionará la temporización a la que se debe sincronizar el equipo de las instalaciones del cliente (CPE).

1. Verifique que el origen del reloj se deriva de la red. Esto se puede comprobar buscando que el origen del reloj sea Line Primary (Línea principal).

   Nota: Si hay varias T1 en un servidor de acceso, sólo una puede ser la principal, mientras que las otras T1 derivan el reloj del primario. En ese caso, verifique que la línea T1 designada como fuente de reloj principal esté configurada correctamente.

2. Configure el origen de reloj T1 correctamente desde el modo de configuración del controlador.

   maui-nas-03(config-controlle)#clock source line primary
   

El contador de pérdida de segundos de trama está aumentando:

Siga estos pasos cuando aumente el contador de segundos de pérdida de tramas.

1. Verifique si el formato de entramado configurado en el puerto coincide con el formato de entramado de la línea. Puede verificar esto buscando el entramado es {ESF|SF} en el resultado show controller t1.

2. Para cambiar el formato de entramado, utilice el entramado {SF | ESF} en el modo de configuración del controlador como se muestra a continuación:

   maui-nas-03(config-controlle)#framing esf
   

3. Cambie el diseño de línea utilizando la longitud de cable {long | short}.

Consulte a su proveedor de servicios y a la Referencia de Comandos de Cisco IOS™ para obtener más información sobre la configuración de buildout.

Las violaciones de código de línea aumentan:

Siga estos pasos cuando aumenten las violaciones de código de línea.

1. Verifique si la codificación de línea configurada en el puerto coincide con el formato de trama de la línea. Puede verificar esto buscando que el código de línea sea {B8ZS|AMI} en el resultado show controller t1.

2. Para cambiar la codificación de línea, utilice el comando linecode {ami | b8zs} en el modo de configuración del controlador como se muestra a continuación:

   maui-nas-03(config-controlle)#linecode b8zs
   

3. Cambie el diseño de línea utilizando la longitud de cable {long | short}.

Consulte a su proveedor de servicios y a la Referencia de Comandos de Cisco IOS® para obtener más información sobre la configuración de buildout.

Verificación de que el Tipo de Switch ISDN y el Grupo PRI están Configurados Correctamente

Utilice el comando show running-config para ver si el tipo de switch ISDN y los intervalos de tiempo del grupo PRI están configurados correctamente. Póngase en contacto con su proveedor de servicios para obtener los valores correctos.

Para cambiar el tipo de switch ISDN y el grupo PRI:

maui-nas-03#configure terminal
maui-nas-03(config)#isdn switch-type primary-5ess
maui-nas-03(config)#controller t1 0
maui-nas-03(config-controlle)#pri-group timeslots 1-24

Verificación del canal de señalización

Si los contadores de errores no aumentan pero el problema persiste, verifique que el canal de señalización esté activo y configurado correctamente.

1. Ejecute el comando show interface serial x:23, donde x debe ser reemplazado por el número de interfaz.

2. Verifique si la interfaz está activa. Si la interfaz no está encendida, use el comando no shutdown para encenderla.

   maui-nas-03#config terminal
   Enter configuration commands, one per line.  End with CNTL/Z.
   maui-nas-03(config)#interface serial 0:23
   maui-nas-03(config-if)#no shutdown
   

3. Asegúrese de que la encapsulación sea PPP. Si la interfaz no está utilizando PPP, utilice el comando encapsulation ppp en el modo de configuración de la interfaz para corregirlo.

   maui-nas-03(config-if)#encapsulation ppp
   

4. Verifique si el loopback está configurado. El loopback solo debe configurarse para realizar pruebas. Utilice el comando no loopback para quitar loops de retorno.

   maui-nas-03(config-if)#no loopback
   

5. Apague y encienda el router.

6. Si el problema persiste, póngase en contacto con su proveedor de servicios o con el TAC de Cisco

Resolución de problemas de PRI

Siempre que se solucione un problema de PRI, debe comprobar si el T1 se está ejecutando correctamente en ambos extremos. Si se han resuelto los problemas de Capa 1, como se ha descrito anteriormente, tenga en cuenta los problemas de Capa 2 y Capa 3.

Resolución de problemas mediante el comando show isdn status

El comando show isdn status se utiliza para mostrar una instantánea de todas las interfaces ISDN. Muestra el estado de las capas 1, 2 y 3.

1. Verifique que la Capa 1 esté activa.

   El estado de la Capa 1 siempre debe indicar ACTIVE a menos que T1 esté inactivo. Si show isdn status indica que la Capa 1 está DESACTIVADA, entonces hay un problema con la conectividad física en la línea T1. Consulte la sección "¿Está el T1 Controller T1 inactivo?"

   También verifique que T1 no esté administrativamente inactivo. Utilice el comando no shutdown para activar el controlador T1.

2. Compruebe si el estado de la capa 2 es MULTIPLE_FRAME_ESTABLISHED

El estado de Capa 2 deseado es Multiple_Frame_Estabed, que indica que estamos intercambiando tramas de Capa 2 y que hemos terminado la inicialización de Capa 2.

Si la Capa 2 no es Multiple_Frame_Estabed , utilice el comando EXEC show controller t1 para diagnosticar el problema. Refiérase a la sección Troubleshooting con el Comando show controller t1 de este capítulo.

Dado que show isdn status es una instantánea del estado actual, es posible que la capa 2 esté rebotando hacia arriba y hacia abajo a pesar de indicar Mulitple_Frame_Estabed. Utilice debug isdn q921 para verificar que la capa 2 esté estable.

El comando debug isdn q921 muestra los procedimientos de acceso de capa de link de datos (capa 2) que se están llevando a cabo en el router en el canal D.

Asegúrese de que está configurado para ver los mensajes de depuración mediante el comando logging console o terminal monitor según sea necesario.

Nota: En un entorno de producción, verifique que el registro de la consola esté inhabilitado. Ingrese el comando show logging. Si se habilita el registro, el servidor de acceso puede congelarse intermitentemente en cuanto el puerto de la consola se sobrecargue con mensajes de registro. Ingrese el comando no logging console.

Nota: Si debug isdn q921 está activado y no recibe ninguna salida de debug, realice una llamada o restablezca el controlador para obtener resultados de debug.

1. Verifique que la Capa 2 esté estable.

   Debe observar los resultados de depuración para los mensajes que indican que el servicio no está rebotando hacia arriba y hacia abajo. Si ve los siguientes tipos de salidas debug, la línea no es estable.

   Mar 20 10:06:07.882: %ISDN-6-LAYER2DOWN: Layer 2 for Interface Se0:23, TEI 0 
   changed to down
   Mar 20 10:06:09.882: %LINK-3-UPDOWN: Interface Serial0:23, changed state to down
   Mar 20 10:06:21.274: %DSX1-6-CLOCK_CHANGE: Controller 0  clock is now selected 
   as clock source
   Mar 20 10:06:21.702: %ISDN-6-LAYER2UP: Layer 2 for Interface Se0:23, TEI 0 changed 
   to up
   Mar 20 10:06:22.494: %CONTROLLER-5-UPDOWN: Controller T1 0, changed state to up
   Mar 20 10:06:24.494: %LINK-3-UPDOWN: Interface Serial0:23, changed state to up
   
   

   Si la Capa 2 no parece ser estable, consulte "Resolución de problemas de eventos de error T1", anteriormente en este capítulo.

2. Verifique que sólo esté viendo mensajes SAPI en ambos lados de transmisión (TX) y recepción (RX).

   Mar 20 10:06:52.505: ISDN Se0:23: TX ->  RRf sapi = 0  tei = 0  nr = 0
   Mar 20 10:06:52.505: ISDN Se0:23: RX <-  RRf sapi = 0  tei = 0  nr = 0
   Mar 20 10:07:22.505: ISDN Se0:23: TX ->  RRp sapi = 0  tei = 0 nr = 0 
   Mar 20 10:07:22.509: ISDN Se0:23: RX <-  RRp sapi = 0  tei = 0 nr = 0 
   Mar 20 10:07:22.509: ISDN Se0:23: TX ->  RRf sapi = 0  tei = 0  nr = 0
   Mar 20 10:07:22.509: ISDN Se0:23: RX <-  RRf sapi = 0  tei = 0  nr = 0

3. Verifique que no esté viendo mensajes SABME, lo que indica que la Capa 2 está intentando reinicializarse. Esto se suele ver cuando se transmiten solicitudes de sondeo (RRp) y no se obtiene una respuesta del switch (RRf) o viceversa. A continuación se muestra un ejemplo de mensajes SABME.

   Mar 20 10:06:21.702: ISDN Se0:23: RX <-  SABMEp sapi = 0  tei = 0
   Mar 20 10:06:22.494: ISDN Se0:23: TX ->  SABMEp sapi = 0  tei = 0

   Si está viendo mensajes SABME, utilice el comando show running-config para ver si el tipo de switch ISDN y los intervalos de tiempo del grupo PRI están configurados correctamente. Póngase en contacto con su proveedor de servicios para obtener los valores correctos.

   Para cambiar el tipo de switch ISDN y el grupo PRI:

   maui-nas-03#configure terminal
   maui-nas-03(config)#isdn switch-type primary-5ess
   maui-nas-03(config)#controller t1 0
   maui-nas-03(config-controlle)#pri-group timeslots 1-24
   

4. Verifique que el canal D esté activo usando el comando show interfaces serial x:23.

   Si el canal D no está activo, utilice el comando no shutdown para activarlo:

   maui-nas-03(config)#interface serial 0:23
   maui-nas-03(config-if)#no shutdown
   

5. Verifique si la encapsulación es PPP. Si no es así, utilice el comando encapsulation ppp para establecer el encripción.

   maui-nas-03(config-if)#encapsulation ppp
   

6. Verifique si la interfaz está en modo loopback. Para el funcionamiento normal, la interfaz no debe estar en modo loopback.

   maui-nas-03(config-if)#no loopback
   

7. Apague y encienda el router.

8. Si el problema persiste, póngase en contacto con su proveedor de servicios o con el TAC de Cisco.

Ejecución de la Prueba de Hardware Loopback Plug

La prueba Hardware Loopback Plug se puede utilizar para probar si el router tiene algún fallo. Si un router supera una prueba de loop cerrado del conector de hardware, el problema reside en otro lugar de la línea.

Crear un conector de loopback:

Siga estos pasos para crear un conector de loopback.

1. Utilice cortadores de cables para cortar un cable RJ-45 o RJ-48 en funcionamiento de modo que haya cinco pulgadas de cable y el conector esté conectado a él.

2. Pele los cables.

3. Apriete los cables de los pines 1 y 4.

4. Apriete los cables de los pines 2 y 5.

Los pines de una toma RJ-45/48 se numeran del 1 al 8. El pin 1 es el pin más a la izquierda cuando se ve el conector con los pines metálicos que se encuentran frente a usted.

Realización de la prueba de loopback Plug

Siga estos pasos para realizar la prueba de loopback Plug.

1. Inserte el conector en el puerto T1 en cuestión.

2. Guarde la configuración del router mediante el comando write memory.

   maui-nas-03#write memory
   Building configuration...
   [OK]

3. Establezca la encapsulación en HDLC

   maui-nas-03#config terminal
   Enter configuration commands, one per line.  End with CNTL/Z.
   maui-nas-03(config)#interface serial 0
   maui-nas-03(config-if)#enc
   maui-nas-03(config-if)#encapsulation HDLC 
   maui-nas-03(config-if)#^Z
   

4. Utilice el comando show running-config para ver si la interfaz tiene una dirección IP.

   Si la interfaz no tiene una dirección IP, obtenga una dirección única y asígnela a la interfaz con una máscara de subred de 255.255.255.0.

   maui-nas-03(config)#ip address 172.22.53.1 255.255.255.0
   

5. Borre los contadores de interfaces con el comando clear counters.

   maui-nas-03#clear counters
   Clear "show interfaces" counters on all interfaces [confirm]
   maui-nas-03#

6. Realice la prueba de ping extendido tal como se describe en la sección "Uso de pruebas ping extendidas" de este capítulo.

Resolución de problemas E1

En esta sección se describen las técnicas y procedimientos para solucionar problemas de circuitos E1 para clientes de acceso telefónico.

Resolución de problemas mediante el comando show controller e1

Este comando muestra el estado del controlador que es específico del hardware del controlador. La información mostrada es generalmente útil para las tareas de diagnóstico realizadas únicamente por el personal de soporte técnico.

El NMP o MIP pueden consultar los adaptadores de puerto para determinar su estado actual. Ejecute un comando show controller e1 para mostrar las estadísticas sobre el link E1. Si especifica una ranura y un número de puerto, se mostrarán las estadísticas de cada período de 15 minutos.

El comando EXEC show controller e1 proporciona información para resolver problemas lógicos de capa física y capa de link de datos. Esta sección describe cómo resolver lógicamente problemas usando el comando show controller e1.

La mayoría de los errores de E1 son causados por líneas mal configuradas. Asegúrese de que la codificación de línea, la alineación de tramas, la fuente de reloj y la terminación de línea (equilibrada o no) se configuran de acuerdo con lo que el proveedor de servicios recomienda.

show controller e1 Condiciones

El controlador E1 puede estar en uno de los tres estados siguientes.

• Bajo rendimiento administrativo

• Down (inactivo)

• En funcionamiento

¿Está el controlador E1 administrativamente inactivo?

El controlador se encuentra administrativamente inactivo cuando se ha apagado manualmente. Debe reiniciar el controlador para corregir este error.

1. Introduzca el modo de activación.

   maui-nas-03>enable
   Password: 
   maui-nas-03#

2. Ingrese al modo de configuración global.

   maui-nas-03#configure terminal
   Enter configuration commands, one per line.  End with CNTL/Z.
   maui-nas-03(config)#

3. Ingrese al modo de configuración del controlador.

   maui-nas-03(config)#controller e1 0
   maui-nas-03(config-controlle)#

4. Reinicie el controlador.

   maui-nas-03(config-controlle)#shutdown
   maui-nas-03(config-controlle)#no shutdown
   

¿Está la línea arriba?

Si la línea E1 no está activa, verifique que la configuración de línea sea correcta y que coincida con la configuración del extremo remoto.

1. Verifique la alineación de tramas de la línea y el extremo remoto. Para las líneas E1, la trama es CRC4 o noCRC4

2. Compruebe la codificación de línea de la línea y el extremo remoto. La codificación de línea es AMI o HDB3.

3. Compruebe si la terminación de línea está configurada para estar equilibrada o no (75-ohm o 120-ohm).

Consulte a su proveedor de servicios para obtener más información sobre la configuración correcta. Realice los cambios que sean necesarios en los dispositivos finales locales o remotos.

Si el controlador E1 y la línea no están activos, verifique si uno de los siguientes mensajes aparece en el resultado show controller e1 EXEC:

• El receptor tiene una pérdida de trama

• El receptor tiene una pérdida de señal

Si el receptor E1 tiene pérdida de trama:

Siga estos pasos si el receptor E1 tiene pérdida de trama.

1. Verifique si el formato de entramado configurado en el puerto coincide con el formato de entramado de la línea. Puede verificar el formato de entramado del controlador desde la configuración en ejecución o la salida del comando show controller e1.

   Para cambiar el formato de entramado, utilice el entramado {CRC4 | no CRC4} en el modo de configuración del controlador como se muestra a continuación:

   maui-nas-03#configure terminal 
   Enter configuration commands, one per line.  End with CNTL/Z.
   maui-nas-03(config)#controller E1 0
   maui-nas-03(config-controlle)#framing CRC4
   

2. Intente con el otro formato de entramado para ver si se borra la alarma.

   Si esto no soluciona el problema, vaya a la sección "Si el receptor E1 tiene pérdida de señal" que aparece a continuación.

3. Verifique el formato de entramado en el extremo remoto.

4. Compruebe la codificación de línea en el extremo remoto.

Si el receptor E1 tiene pérdida de señal:

Siga estos pasos si el receptor E1 tiene pérdida de señal

1. Asegúrese de que el cable entre el puerto de interfaz y el equipo del proveedor de servicios E1 (o equipo terminal E1) esté conectado correctamente. Compruebe si el cable está conectado a los puertos correctos. Si es necesario, corrija las conexiones de cable.

2. Compruebe la integridad del cable. Busque interrupciones u otras anormalidades físicas en el cable. Asegúrese de que las clavijas están configuradas correctamente. Si es necesario, sustituya el cable.

3. Compruebe los conectores del cable. Una inversión de los pares de transmisión y recepción o un par de recepción abierto puede causar errores. Establezca el par de recepción en las líneas 1 y 2. Establezca el par de transmisión en las líneas 4 y 5.

   Los pines de una toma RJ-48 se numeran del 1 al 8. El pin 1 es el pin más a la izquierda cuando se mira el conector con los pines metálicos que se encuentran frente a usted. Consulte la siguiente figura para obtener más información.

   Figura 15-11: Cable RJ-45

   

4. Intente utilizar un cable transpuesto.

5. Verifique si hay errores de bloqueo de extremo lejano. Si es así, el problema existe con el cliente potencial de recepción en el extremo local. Póngase en contacto con el TAC para obtener más ayuda.

Ejecute el comando show controller e1 EXEC después de cada paso para verificar si el controlador muestra algún error.

Si la línea está en modo de bucle invertido:

Verifique si la línea está en modo loopback desde el resultado show controller e1. Una línea debe estar en modo loopback solamente para fines de prueba.

Para desactivar el loopback, utilice el comando no loopback en el modo de configuración del controlador como se muestra a continuación:

maui-nas-03(config-controlle)#no loopback

Si el controlador muestra cualquier alarma:

Verifique el resultado del comando show controller para ver si hay alarmas mostradas por el controlador.

Ahora debatiremos varias alarmas y el procedimiento necesario para corregirlas.

El Receptor (Rx) Tiene Alarma Remota:

Una alarma remota recibida significa que se produce una alarma en la línea ascendente del equipo conectado al puerto.

1. Verifique si el formato de entramado configurado en el puerto coincide con el formato de entramado de la línea. Si no es así, cambie el formato de entramado en el controlador para que coincida con el de la línea.

2. Compruebe la configuración de la codificación de línea en el equipo de extremo remoto. Contacte a su proveedor de servicio para obtener la configuración correcta. Corrija cualquier error de configuración según sea necesario.

3. Introduzca un cable externo de loopback en el puerto. Para crear un conector de loopback, consulte la sección "Realización de la prueba de bucles de loopback de hardware", anteriormente en el capítulo.

4. Compruebe si hay alarmas. Si no ve ninguna alarma, entonces es probable que el hardware local esté en buenas condiciones. En ese caso:

   1. Inspeccione el cableado Consulte la sección "Si el receptor E1 tiene pérdida de señal" para obtener más información.

   2. Controle las configuraciones del extremo remoto y verifique que coincidan con las configuraciones de su puerto.

   3. Si el problema continúa, contacte a su proveedor de servicio.

5. Retire el conector de loopback y vuelva a conectar la línea E1.

6. Inspeccione el cableado Consulte la sección "Si el receptor E1 tiene pérdida de señal" para obtener más información.

7. Apague y encienda el router.

8. Conecte la línea E1 con un puerto diferente. Configure el puerto con los mismos parámetros que el de la línea. Si el problema no persiste, la falla se encuentra en el puerto uno:

   1. Vuelva a conectar la línea E1 con el puerto original.

   2. Vaya a la sección "Resolución de problemas de eventos de error de E1".

      Si el problema persiste, entonces:

9. Realice una prueba de loop de hardware como se describe en la sección "Realización de la prueba de loopback de hardware"

10. Reemplace la tarjeta de controlador E1.

11. Vaya a la sección "Resolución de problemas de eventos de error de E1".

Alarma remota de envío del transmisor (rojo):

Se declara una alarma roja cuando la CSU no puede sincronizarse con el patrón de entramado en la línea E1.

1. Verifique si el formato de entramado configurado en el puerto coincide con el formato de entramado de la línea. Si no cambia el formato de entramado en el controlador para que coincida con el de la línea.

2. Controle las configuraciones del extremo remoto y verifique que coincidan con las configuraciones de su puerto.

3. Introduzca un cable externo de loopback en el puerto. Para crear un conector de loopback, consulte la sección "Realización de la prueba de bucles de loopback de hardware", anteriormente en el capítulo.

4. Compruebe si hay alarmas. Si no ve ninguna alarma, entonces es probable que el hardware local esté en buenas condiciones. En ese caso:

   1. Inspeccione el cableado Consulte la sección "Si el receptor E1 tiene pérdida de señal" para obtener más información.

   2. Si el problema continúa, contacte a su proveedor de servicio.

5. Conecte la línea E1 con un puerto diferente. Configure el puerto con los mismos parámetros que el de la línea. Si el problema no persiste, la falla se encuentra en el puerto uno.

   1. Vuelva a conectar la línea E1 con el puerto original.

   2. Vaya a la sección "Resolución de problemas de eventos de error de E1".

      Si el problema persiste, entonces:

6. Realice una prueba de loop de hardware como se describe en la sección "Realización de la prueba de loopback de hardware".

7. Reemplace la tarjeta de controlador E1.

8. Vaya a la sección "Resolución de problemas de eventos de error de E1".

9. Contacte a su proveedor de servicios.

Resolución de problemas de eventos de error E1

El comando show controller e1 EXEC proporciona mensajes de error que se pueden utilizar para resolver problemas. Ahora hablaremos de varios mensajes de error y cómo corregir los errores.

Para ver si los contadores de errores aumentan, ejecute el comando show controller e1 repetidamente. Observe los valores de los contadores para el intervalo actual Consulte a su proveedor de servicios para obtener información sobre la configuración de la codificación de líneas y la alineación de tramas.

El contador de segundos deslizantes aumenta:

La presencia de deslizamientos en las líneas E1 indica un problema de temporización. El proveedor E1 (Telco) proporcionará la temporización a la que se debe sincronizar el equipo de las instalaciones del cliente (CPE).

1. Verifique que el origen del reloj se deriva de la red. Esto se puede comprobar buscando que el origen del reloj sea Line Primary (Línea principal).

   Nota: Si hay varios E1s en un servidor de acceso, sólo uno puede ser el primario, mientras que el otro E1s deriva el reloj del primario. En ese caso, verifique que la línea E1 designada como fuente de reloj principal esté configurada correctamente.

2. Configure el origen de reloj E1 correctamente desde el modo de configuración del controlador.

   maui-nas-03(config-controlle)#clock source line primary
   

El contador de pérdida de segundos de trama está aumentando:

Siga estos pasos cuando aumente el contador de segundos de pérdida de trama:

1. Verifique si el formato de entramado configurado en el puerto coincide con el formato de entramado de la línea. Puede verificar esto buscando que el entramado sea {CRC4|no CRC4} en el resultado show controller e1.

2. Para cambiar el formato de entramado, utilice el entramado {CRC4 | no CRC4} en el modo de configuración del controlador como se muestra a continuación:

   maui-nas-03(config-controlle)#framing crc4
   

Las violaciones de código de línea aumentan:

Siga estos pasos cuando aumenten las violaciones del código de línea.

1. Verifique si la codificación de línea configurada en el puerto coincide con el formato de trama de la línea. Puede verificar esto si busca que el código de línea sea {AMI/HDB3} en la salida show controller e1.

2. Para cambiar la codificación de línea, utilice el código de línea {ami | hdb3} en el modo de configuración del controlador como se muestra a continuación:

   maui-nas-03(config-controlle)#linecode ami
   

Verificación de que el Tipo de Switch ISDN y el Grupo PRI están Configurados Correctamente

Utilice el comando show running-config para verificar si el tipo de switch ISDN y los intervalos de tiempo del grupo PRI están configurados correctamente. Póngase en contacto con su proveedor de servicios para obtener los valores correctos.

Para cambiar el tipo de switch ISDN y el grupo PRI:

maui-nas-03#configure terminal
maui-nas-03(config)#isdn switch-type primary-net5
maui-nas-03(config)#controller e1 0
maui-nas-03(config-controlle)#pri-group timeslots 1-31

Verificación del canal de señalización

Si los contadores de errores no aumentan pero el problema persiste, verifique que el canal de señalización esté activo y configurado correctamente.

1. Ejecute el comando show interface serial x:15, donde x debe ser reemplazado por el número de interfaz.

2. Verifique si la interfaz está activa. Si la interfaz no está encendida, use el comando no shutdown para encenderla.

   maui-nas-03#config terminal
   Enter configuration commands, one per line.  End with CNTL/Z.
   maui-nas-03(config)#interface serial 0:15
   maui-nas-03(config-if)#no shutdown
   

3. Asegúrese de que la encapsulación sea PPP. Si la interfaz no está utilizando PPP, utilice el comando encapsulation ppp en el modo de configuración de la interfaz para corregirlo.

   maui-nas-03(config-if)#encapsulation ppp
   

4. Verifique si el loopback está configurado. El loopback solo debe configurarse para realizar pruebas. Utilice el comando no loopback para quitar loops de retorno.

   maui-nas-03(config-if)#no loopback
   

5. Apague y encienda el router.

6. Si el problema persiste, póngase en contacto con su proveedor de servicios o con el TAC de Cisco.

Resolución de problemas de PRI

Al solucionar problemas de una PRI, debe determinar si la E1 se está ejecutando de forma limpia en ambos extremos. Si los problemas de la Capa 1 se han resuelto como se describe anteriormente, tenga en cuenta los problemas de la Capa 2 y la Capa 3.

Resolución de problemas mediante el comando show isdn status

El comando show isdn status se utiliza para mostrar una instantánea de todas las interfaces ISDN. Muestra el estado de las capas 1, 2 y 3.

1. Verifique que la Capa 1 esté activa.

   El estado de la Capa 1 siempre debe indicar ACTIVE a menos que el E1 esté inactivo.

   Si show isdn status indica que la Capa 1 está DESACTIVADA, entonces hay un problema con la conectividad física en la línea E1. Consulte la sección "¿Está el controlador E1 administrativamente inactivo?"

   También verifique que E1 no esté administrativamente inactivo. Utilice el comando no shutdown para activar el controlador E1.

2. Verifique si el estado de la Capa 2 es MULTIPLE_FRAME_ESTABLISHED.

El estado de Capa 2 deseado es Multiple_Frame_Estabed, que indica que el protocolo de inicio entre el switch ISDN y el dispositivo final se ha establecido y estamos intercambiando tramas de Capa 2.

Si la Capa 2 no es Multiple_Frame_Estabed, utilice el comando EXEC show controller e1 para diagnosticar el problema. Consulte la sección "Resolución de problemas mediante el comando show controller e1" en este capítulo y la sección "Resolución de problemas de eventos de error E1".

Debido a que show isdn status es una instantánea del estado actual, es posible que la Capa 2 esté rebotando hacia arriba y hacia abajo a pesar de indicar Mulitple_Frame_Estabed. Utilice el comando debug isdn q921 para verificar que la capa 2 esté estable.

Uso de debug q921

El comando debug isdn q921 muestra los procedimientos de acceso de capa de link de datos (Capa 2) que se están llevando a cabo en el router en el canal D.

Asegúrese de que está configurado para ver los mensajes debug mediante el comando logging console o terminal monitor según sea necesario.

Nota: En un entorno de producción, verifique que el registro de la consola esté inhabilitado. Ingrese el comando show logging. Si se habilita el registro, el servidor de acceso puede congelarse intermitentemente en cuanto el puerto de la consola se sobrecargue con mensajes de registro. Ingrese el comando no logging console.

Nota: Si debug isdn q921 está activado y no recibe ninguna salida de debug, realice una llamada o restablezca el controlador para obtener resultados de debug.

1. Verifique que la Capa 2 esté estable. Debe observar los resultados de depuración para los mensajes que indican que el servicio no está rebotando hacia arriba y hacia abajo. Si ve los siguientes tipos de salidas debug, la línea no es estable.

   Mar 20 10:06:07.882: %ISDN-6-LAYER2DOWN: Layer 2 for Interface Se0:15, TEI 0 
   changed to down
   Mar 20 10:06:09.882: %LINK-3-UPDOWN: Interface Serial0:15, changed state to down
   Mar 20 10:06:21.274: %DSX1-6-CLOCK_CHANGE: Controller 0  clock is now selected 
   as clock source
   Mar 20 10:06:21.702: %ISDN-6-LAYER2UP: Layer 2 for Interface Se0:15, TEI 0 
   changed to up
   Mar 20 10:06:22.494: %CONTROLLER-5-UPDOWN: Controller E1 0, changed state to up
   Mar 20 10:06:24.494: %LINK-3-UPDOWN: Interface Serial0:15, changed state to up
   
   

   Si la Capa 2 no parece ser estable, consulte "Resolución de problemas de eventos de error E1", anteriormente en este capítulo.

2. Verifique que sólo esté viendo mensajes SAPI en ambos lados de transmisión (TX) y recepción (RX).

   Mar 20 10:06:52.505: ISDN Se0:15: TX ->  RRf sapi = 0  tei = 0  nr = 0
   Mar 20 10:06:52.505: ISDN Se0:15: RX <-  RRf sapi = 0  tei = 0  nr = 0
   Mar 20 10:07:22.505: ISDN Se0:15: TX ->  RRp sapi = 0  tei = 0 nr = 0
   Mar 20 10:07:22.509: ISDN Se0:15: RX <-  RRp sapi = 0  tei = 0 nr = 0
   Mar 20 10:07:22.509: ISDN Se0:15: TX ->  RRf sapi = 0  tei = 0  nr = 0
   Mar 20 10:07:22.509: ISDN Se0:15: RX <-  RRf sapi = 0  tei = 0  nr = 0

3. Verifique que no esté viendo mensajes SABME, lo que indica que la Capa 2 está intentando reinicializarse. Esto se suele ver cuando se transmiten solicitudes de sondeo (RRp) y no se obtiene una respuesta del switch (RRf) o viceversa. A continuación se muestra un ejemplo de mensajes SABME. Deberíamos obtener una respuesta del switch ISDN para nuestros mensajes SABME (trama UA recibida).

   Mar 20 10:06:21.702: ISDN Se0:15: RX <-  SABMEp sapi = 0  tei = 0
   Mar 20 10:06:22.494: ISDN Se0:15: TX ->  SABMEp sapi = 0  tei = 0

   Si está viendo mensajes SABME, utilice el comando show running-config para verificar si el tipo de switch ISDN y los intervalos de tiempo del grupo PRI están configurados correctamente. Póngase en contacto con su proveedor de servicios para obtener los valores correctos.

   Para cambiar el tipo de switch ISDN y el grupo PRI:

   maui-nas-03#configure terminal
   maui-nas-03(config)#isdn switch-type primary-net5
   maui-nas-03(config)#controller e1 0
   maui-nas-03(config-controlle)#pri-group timeslots 1-31
   

4. Verifique que el canal D esté activo usando el comando show interfaces serial x:15.

   Si el canal D no está activo, utilice el comando no shutdown para activarlo:

   maui-nas-03(config)#interface serial 0:15
   maui-nas-03(config-if)#no shutdown
   

5. Verifique si la encapsulación es PPP. Si no utiliza el comando encapsulation ppp para establecer la encapsulación.

   maui-nas-03(config-if)#encapsulation ppp
   

6. Verifique si la interfaz está en modo loopback. Para el funcionamiento normal, la interfaz no debe estar en modo loopback.

   maui-nas-03(config-if)#no loopback
   

7. Apague y encienda el router.

8. Si el problema persiste, póngase en contacto con su proveedor de servicios o con el TAC de Cisco.

Información Relacionada

• Soporte Técnico - Cisco Systems

Historial de revisiones