WAN : T1/E1 y T3/E3

Resolución de problemas de línea serial

18 Octubre 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


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:

  • Troubleshooting usando el comando show interfaces serial

  • Usando el comando show controllers

  • ‘Uso de los comandos de depuración’

  • Usando las pruebas Extended PING

  • Localización de averías de los problemas con EL reloj

  • Ajuste de los buffers

  • Pruebas de línea serial especial

  • Información detallada en el comando show interfaces serial

  • Localización de averías de los problemas T1

  • Localización de averías de los problemas del e1

prerrequisitos

Requisitos

Los Quien lea este documento deben estar bien informados de las definiciones siguientes.

  • DTE = equipo de terminal de datos

  • CD = detección de la portadora

  • CSU = unidad de servicio de canal

  • DSU = unidad de servicio digital

  • SCTE = transmisión del reloj en serie externa

  • DCE = equipo circuito-terminal de los datos

  • CTS = Clear To Send

  • DSR = data set ready

  • SAP = protocolo service advertising

  • IPX = Internetwork Packet Exchange

  • FDDI = Fiber Distributed Data Interface

  • ESF = Formato de tramas superframe extendido

  • B8ZS = sustitución binaria de ocho ceros

  • LBO = Line Build Out

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. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). 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.

Troubleshooting usando el comando show interfaces serial

La salida del comando show interfaces serial exec visualiza el específico de la información a las interfaces seriales. El cuadro 15-1 muestra la salida del comando show interfaces serial exec para una interfaz serial del High-Level Data Link Control (HDLC).

Esta sección describe cómo utilizar el comando show interfaces serial de diagnosticar los problemas de la conectividad de la línea serial en un entorno de Red de área ancha (WAN). Las secciones siguientes describen algunos de los campos importantes de la salida de comando.

Otros campos mostrados en la visualización se describen detalladamente en la sección “información detallada en el comando show interfaces serial,” más adelante en este capítulo.

Líneas seriales: muestre las condiciones del estado de la línea del serial de las interfaces

Usted puede identificar cinco estados de Posible problema en la línea del estado de la interfaz de la visualización serial de las interfaces de la demostración (véase el cuadro 15-1):

  • X serial está abajo, Line Protocol está abajo

  • X serial está para arriba, Line Protocol está abajo

  • X serial está para arriba, el Line Protocol está encima de (colocado)

  • X serial está para arriba, el Line Protocol está abajo de (inhabilitado)

  • X serial está administrativo abajo, Line Protocol está abajo

Cuadro salida de 15-1 del comando show interface serial del HDLC

15_1.gif

Cuadro 15-1: Líneas seriales: muestre a interfaces las condiciones del estado de la línea seriales - Esta tabla muestra a las condiciones, y las soluciones de la interfaz las condiciones de estado, los Posibles problemas asociados a esos problemas.

Condición del estado de la línea Posible problema Solución
X serial está para arriba, Line Protocol está para arriba   Esta es la condición de estado de línea adecuada. No se requiere acción
X serial está abajo, Line Protocol está abajo de (el modo DTE)
  • Indica típicamente que el router no está detectando una señal CD (es decir, el CD no es activo).
  • La problema-línea de la compañía telefónica está abajo o la línea no está conectada con el CSU/DSU
  • Defectuoso o Cableado incorrecto
  • Falla de hardware (CSU/DSU)
  1. Marque el LED en el CSU/DSU para ver si el CD es activo, o para insertar una caja de conexión en la línea para marcar para saber si hay la señal CD.
  2. Verifique que usted esté utilizando el cable adecuado y la interfaz (véase su documentación de instalación del hardware).
  3. Inserte una caja de conexión y marque todos los leads del control.
  4. Entre en contacto su línea arrendada o el otro servicio de portadora para ver si hay un problema.
  5. Intercambie las partes defectuosas.
  6. Si usted sospecha el hardware de router defectuoso, cambie la línea serial a otro puerto. Si sube la conexión, la interfaz conectada tiene previamente un problema.
X serial está para arriba, Line Protocol está abajo de (el modo DTE)
  • Se configura mal el router local o remoto
  • El Keepalives no está siendo enviado por el router remoto
  • La línea arrendada o la otra línea problema-ruidosa del servicio de portadora, o configurado mal o switch fallado
  • El problema de sincronización en el cable (SCTE no fijado en el CSU/DSU) falló local o el telecontrol CSU/DSU
  • Local fallada o telecontrol CSU/DSU
  • Falla de hardware del router (local o remoto)
  1. Ponga el módem, el CSU, o el DSU en el Local Loopback Mode y utilice el comando show interfaces serial de ver si sube el Line Protocol. Si sube el Line Protocol, un problema de la compañía telefónica o un router remoto fallado es el posible problema.
  2. Si el problema aparece estar en el extremo remoto, relance el paso 1 en el módem remoto, el CSU, o el DSU.
  3. Verifique todo el cableado. Aseegurese que el cable está asociado a la interfaz correcta, al CSU/DSU correcto, y al punto de terminación de la red de la compañía telefónica correcto. Utilice el comando show controllers exec de determinar se asocia qué cable al cual interfaz.
  4. Habilite el comando debug serial interface exec.

    precaución Precaución: Porque asignan salida de debbuging un prioritario en proceso de la CPU, puede hacer el sistema 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.

  5. Si el Line Protocol no sube en el Local Loopback Mode y si la salida del comando debug serial interface exec muestra que el contador de keepalives no está incrementando, un problema de hardware del router es probable. Hardware de la interfaz del router del intercambio.
  6. Si sube el Line Protocol y el contador de keepalives incrementa, el problema no está en el router local. Resolver problemas la línea serial según lo descrito en las secciones “localización de averías de problemas con EL reloj” y “pruebas CSU y del DSU Loopback,” más adelante en este capítulo.
  7. Si usted sospecha el hardware de router defectuoso, cambie la línea serial a un puerto sin utilizar. Si sube la conexión, la interfaz conectada tiene previamente un problema.
X serial está para arriba, Line Protocol está abajo de (el modo DCE)
  • Comando missing clockrate interface configuration
  • El dispositivo DTE no soporta ni se configura para el modo SCTE
  • Telecontrol fallado CSU o DSU
  • Fallado o Cable incorrecto
  • Falla de hardware del router
  1. Agregue el comando clockrate interface configuration en la interfaz serial. Sintaxis: descripción de la sintaxis del clock rate bps:
    • Velocidad del reloj BPS-deseada en los bits por segundo: 1200, 2400, 4800, 9600, 19200, 38400, 56000, 64000, 72000, 125000, 148000, 250000, 500000, 800000, 1000000, 1300000, 2000000, 4000000, o 8000000.
  2. Fije el dispositivo DTE al modo SCTE si es posible. Si su CSU/DSU no soporta el SCTE, usted puede tener que inhabilitar el SCTE en la interfaz del router de Cisco. Vea la sección el “invertir del reloj de transmisión,” más adelante en este capítulo.
  3. Verifique que se esté utilizando el cable correcto.
  4. Si sigue siendo el Line Protocol abajo, hay un error o un problema del cableado de hardware posible. Inserte una caja de conexión y observe los leads.
  5. Substituya las partes defectuosas cuanto sea necesario.
X serial está para arriba, el Line Protocol está encima de (colocado) Un loop existe en el circuito. El número de secuencia en el paquete de keepalive cambia a un número aleatorio cuando un loop se detecta inicialmente. Si el mismo número aleatorio se vuelve sobre el link, un loop existe.
  1. Utilice el comando show running-config privileged exec de buscar cualquier entrada del comando loopback interface configuration.
  2. Si usted encuentra una entrada del comando loopback interface configuration, utilice el comando no loopback interface configuration de quitar el loop.
  3. Si usted no encuentra el comando loopback interface configuration, examine el CSU/DSU para ver si se configuran en el Manual Loopback Mode. Si son, inhabilite el Manual Loopback.
  4. Reajuste el CSU o el DSU, y examine la línea estatus. Si sube el Line Protocol, no hay otra acción necesaria.
  5. Si el CSU o el DSU no se configura en el Manual Loopback Mode, entre en contacto la línea arrendada o el otro servicio de portadora para la línea asistencia para Troubleshooting.
X serial está para arriba, el Line Protocol está abajo de (inhabilitado)
  • Alto índice de error debido al problema del servicio de la compañía telefónica
  • Problema de hardware CSU o DSU
  • Hardware del router defectuoso (interfaz)
  1. Resolver problemas la línea con un analizador serie y una caja de conexión. Look for señales CTS que conectan y DSR.
  2. Loop 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 de la compañía telefónica.
  3. Descargue al almenaciemento auxiliar el mún hardware como sea necesario (CSU, DSU, Switch, router local o remoto).
X serial está administrativo abajo, Line Protocol está abajo
  • La configuración del router incluye el comando shutdown interface configuration
  • Dirección IP duplicada
  1. Marque la configuración del router para el comando shutdown.
  2. Utilice el comando no shutdown interface configuration de quitar el comando shutdown.
  3. Verifique que no haya IP Addresses idénticos usando el comando show running-config privileged exec o el comando show interfaces exec.
  4. Si hay direcciones duplicadas, resuelva el conflicto cambiando uno de los IP Addresses.

Líneas seriales: Caídas de resultados cada vez mayores en el link serial

Las caídas de resultados aparecen en la salida del comando show interfaces serial (véase el cuadro 15-1) cuando el sistema está intentando dar de un paquete a un buffer del transmitir pero no hay buffers disponibles.

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

Líneas del serial del cuadro 15-2: Caídas de resultados cada vez mayores en el link serial - Esta tabla delinea el Posible problema que puede causar este síntoma y sugiere las soluciones.

Posible problema Solución
La velocidad de entrada a la interfaz serial excede el ancho de banda disponible en el link serial
  1. Minimice el tráfico de broadcast periódico (tal como encaminamiento y actualizaciones de SAP) usando las Listas de acceso o por el otro medio. Por ejemplo, para aumentar el retardo entre las actualizaciones de SAP, utilice el comando ipx sap-interval interface configuration.
  2. Aumente los tamaños de la cola de retención de salida en los pequeños incrementos (por ejemplo, el 25 por ciento), usando el comando hold-queue out interface configuration.
  3. En las interfaces afectadas, dé vuelta apagado rápidamente a conmutar para los protocolos muy usados. Por ejemplo, para apagar la transferencia rápida IP, ingrese el comando no ip route-cache interface configuration. Para la sintaxis de los comandos para otros protocolos, consulte las guías y las referencias de comandos de configuración del Cisco IOS.
  4. Implemente la cola prioritaria en links seriales más lentos configurando las listas de prioridad. Para la información sobre configurar las listas de prioridad, vea las guías y las referencias de comandos de configuración del Cisco IOS.

Nota: Las caídas de resultados son aceptables bajo ciertas condiciones. Por ejemplo, si un link se sabe para ser utilizado demasiado (sin la manera de remediar la situación), es a menudo preferible caer los paquetes que sostenerlos. Esto es verdad para los protocolos que soportan el control de flujo y pueden retransmitir los datos (tales como TCP/IP y Novell IPX). Sin embargo, algunos protocolos, tales como DECNet y Local-Area Transport son sensibles a los paquetes perdidos y acomodan la retransmisión mal, si en absoluto.

Líneas seriales: Input Drops cada vez mayor en el link serial

El Input Drops aparece en la salida del comando show interfaces serial exec (véase el cuadro 15-1) cuando demasiados paquetes de esa interfaz todavía se están procesando en el sistema.

Síntoma: Un número creciente de Input Drops en el link serial.

Cuadro 15-3: Líneas seriales: Input Drops cada vez mayor en el link serial - Esta tabla delinea el Posible problema que puede causar este síntoma y sugiere las soluciones.

Posible problema Solución
La velocidad de entrada excede la capacidad del router o las colas de entrada exceden los tamaños de las colas de salida

Nota: Los problemas del Input Drop se consideran típicamente cuando el tráfico se está ruteando entre interfaces más rápidas (tales como Ethernetes, Token Ring, y FDDI) y las interfaces seriales. Cuando el tráfico es luz, no hay problema. Mientras que las relaciones del tráfico aumentan, los respaldos comienzan a ocurrir. Paquetes del descenso del Routers durante estos períodos congestionados.

  1. Aumente los tamaños de la cola de resultado en las interfaces de destino comunes para la interfaz que está cayendo los paquetes. Utilice el comando hold-queue out interface configuration. Aumente estas colas de administración del tráfico en los pequeños incrementos (por ejemplo, 25percent) hasta que usted vea no más los descensos en la salida de las interfaces de la demostración. El límite predeterminado de la cola de retención de salida es 100 paquetes.
  2. Reduzca los tamaños de cola de entrada, usando el comando hold-queue in interface configuration, de forzar el Input Drops para hacer caídas de resultados. Las caídas de resultados tienen menos impacto en el funcionamiento del router que el Input Drops. La cola de retención de entrada predeterminada es 75 paquetes.

Líneas seriales: Aumentos de error de entrada superior al un por ciento de tráfico de interfaz total

Si los errores de entrada aparecen en la demostración interconectan la salida serial (véase el cuadro 15-1), allí son varias fuentes posibles de esos errores. Las fuentes más probable se resumen en el cuadro 15-4.

Nota: Cualquier valor de error de entrada para los errores, los errores en la trama, o los abortos de la verificación por redundancia cíclica (CRC) sobre el un por ciento del tráfico de interfaz total sugiere una cierta clase de problema de link que deba ser aislada y ser reparada.

Síntoma: Un número creciente de errores de entrada superior al un por ciento de tráfico de interfaz total.

Cuadro 15-4: Líneas seriales: Aumentos de error de entrada superior al un por ciento de tráfico de interfaz total

Posible problema Solución
Los problemas siguientes pueden dar lugar a este síntoma:
  • Equipo de la compañía telefónica defectuoso
  • Línea en serie con ruidos
  • Configuración de reloj incorrecta (SCTE no fijado)
  • Cable incorrecto o cable demasiado largo
  • Mún cable o conexión
  • Mún CSU o DSU
  • Hardware del router defectuoso
  • Conversor de datos o otro dispositivo que es utilizado entre el router y el DSU

Nota: Cisco recomienda fuertemente el no usar de los Conversor de datos cuando usted está conectando a un router con WAN o una red serie.

  1. Utilice un analizador serie para aislar la fuente de los errores de entrada. Si usted detecta los errores, es probable que haya un problema de hardware o una discordancía del reloj en un dispositivo que sea externo al router.
  2. Utilice el loopback y las pruebas de ping para aislar el origen del problema específico. Para más información, vea las secciones “usando el comando trace” y las “pruebas CSU y del DSU Loopback,” más adelante en este capítulo.
  3. Busque los modelos. Por ejemplo, si los errores ocurren en un intervalo coherente, podrían ser relacionados con una función periódica tal como el envío de las actualizaciones de ruteo.

Líneas seriales: Troubleshooting Errores de Entrada de Línea Serial

Cuadro 15-5: Esta tabla describe los diversos tipos de errores de entrada visualizados por el comando show interfaces serial (véase el cuadro 15-1), los Posibles problemas que pueden causar los errores y las soluciones a esos problemas.

Tipo de error de entrada (Nombre del campo) Posible problema Solución
Errores CRC (CRC) Los errores CRC ocurren cuando lo hace el cálculo de CRC paso-no indicando que los datos están corromper-para una de las razones siguientes:
  • Línea en serie con ruidos
  • El cable serial es demasiado largo, o el cable del CSU/DSU al router no se blinda
  • No habilitan al modo SCTE en el DSU
  • El reloj de línea CSU se configura incorrectamente
  • Unos problema de densidad en el link T1 (alineación de tramas incorrecta o especificación de codificación)
  1. Asegúrese de que la línea sea bastante limpia para los requisitos de transmisión. Blinde el cable en caso necesario.
  2. Aseegure el cable está dentro del recomendado longitud-ningunos más de 50 pies (15.24 contadores) o 25 pies (7.62 contadores) para el link T1.
  3. Asegúrese de que todos los dispositivos estén configurados correctamente para un reloj de línea común. Fije el SCTE en el local y el telecontrol DSU. Si su CSU/DSU no soporta el SCTE, vea la sección el “invertir del reloj de transmisión,” más adelante en este capítulo.
  4. Asegúrese que el locales y el telecontrol CSU/DSU estén configurados para mismo enmarcar y esquema de codificación que ése usado por la línea arrendada o el otro servicio de portadora (por ejemplo, ESF/B8ZS).
  5. Entre en contacto su línea arrendada o el otro servicio de portadora y téngalo realizar las pruebas de integración en la línea.
Errores en la trama (trama) Un error en la trama ocurre cuando un paquete no termina en un límite del byte de 8 bits para una de las razones siguientes:
  • Línea en serie con ruidos
  • Incorrectamente cable diseñado; el cable serial es demasiado largo; el cable del CSU o del DSU al router no se blinda
  • No habilitan al modo SCTE en el DSU; el reloj de línea CSU se configura incorrectamente; uno de los relojes se configura para cronometrar local
  • Unos problema de densidad en el link T1 (alineación de tramas incorrecta o especificación de codificación)
  1. Asegúrese de que la línea sea bastante limpia para los requisitos de transmisión. Blinde el cable en caso necesario. Asegúrese usted están utilizando el cable correcto.
  2. Aseegure el cable está dentro del recomendado longitud-ningunos más de 50 pies (15.24 contadores) o 25 pies (7.62 contadores) para el link T1.
  3. Asegúrese de que todos los dispositivos estén configurados correctamente para utilizar un reloj de línea común. Fije el SCTE en el local y el telecontrol DSU. Si su CSU/DSU no soporta el SCTE, vea la sección el “invertir del reloj de transmisión” más adelante en este capítulo.
  4. Asegúrese que el local y el telecontrol CSU/DSU esté configurado para mismo enmarcar y esquema de codificación que ése usado por la línea arrendada o el otro servicio de portadora (por ejemplo, ESF/B8ZS).
  5. Entre en contacto su línea arrendada o el otro servicio de portadora y téngalo realizar las pruebas de integración en la línea.
Transmisión abortada (aborto) Los abortos indican una secuencia ilegal de los bits uno (más de siete en fila). Los siguientes son razones posibles de este acontecimiento:
  • No habilitan al modo SCTE en el DSU
  • El reloj de línea CSU se configura incorrectamente
  • El cable serial es demasiado largo o el cable del CSU o del DSU al router no se blinda
  • Unos problema de densidad en el link T1 (alineación de tramas incorrecta o especificación de codificación)
  • El paquete terminó en el centro de la causa transmisión-típica que era una restauración de la interfaz o un error en la trama
  • Problema-mún circuito del hardware, mún CSU/DSU, o mala interfaz de envío en el router remoto
  1. Asegúrese de que todos los dispositivos estén configurados correctamente para utilizar un reloj de línea común. Fije el SCTE en el local y el telecontrol DSU. Si su CSU/DSU no soporta el SCTE, vea la sección el “invertir del reloj de transmisión,” más adelante en este capítulo.
  2. Blinde el cable en caso necesario. Asegúrese el cable está dentro del recomendado longitud-ningunos más de 50 pies (15.24 contadores) o 25 pies (7.62 contadores) para el link T1. Asegúrese de que todas las conexiones sean buenas.
  3. Marque el hardware en los ambos extremos del link. Intercambie el equipo defectuoso según sea necesario.
  4. Las velocidades de datos inferiores y consideran si los abortos disminuyen.
  5. Utilice la pruebas de Local y Remote Loopback para determinar donde están ocurriendo los abortos. Vea la sección “pruebas de línea serial especial,” más adelante en este capítulo.
  6. Entre en contacto su línea arrendada o el otro servicio de portadora y téngalo realizar las pruebas de integración en la línea.

Líneas seriales: Reinicios graduales de interfaces en el link serial

Las restauraciones de la interfaz que aparecen en la salida del comando show interfaces serial exec (véase que el cuadro 15-1) es el resultado de los paquetes de señal de mantenimiento faltados.

Síntoma: Un número creciente de restauraciones de la interfaz en el link serial.

Cuadro 15-6: Esta tabla delinea los Posibles problemas que pueden causar este síntoma y sugiere las soluciones.

Posible problema Solución
Los problemas siguientes pueden dar lugar a este síntoma:
  • Congestión en el link (asociado típicamente a las caídas de resultados)
  • Mala línea que causa las transiciones CD
  • Problema del hardware posible en el CSU, el DSU, o el Switch
Cuando están ocurriendo las restauraciones de la interfaz, examine otros campos del salida del comando show interfaces serial para determinar la fuente del problema. Si se asume que un aumento en las restauraciones de la interfaz se está registrando, examine los campos siguientes:
  1. Si hay un número alto de caídas de resultados en la demostración interconecta la salida serial, ve las líneas seriales de la sección “: Caídas de resultados cada vez mayores en el link serial,” anterior en este capítulo.
  2. Marque las transiciones de portadora colocan en la visualización serial de las interfaces de la demostración. Si las transiciones de portadora son altas mientras que se están registrando las restauraciones de la interfaz, el problema es probable ser un mún link o un mún CSU o DSU. Entre en contacto su equipo defectuoso de la línea arrendada o del servicio de portadora y del intercambio cuanto sea necesario.
  3. Examine los errores de entrada colocan en la visualización serial de las interfaces de la demostración. Si los errores de entrada son altos mientras que las restauraciones de la interfaz están aumentando, el problema es probablemente un mún link o un mún CSU/DSU. Entre en contacto su línea arrendada o el otro equipo defectuoso del servicio de portadora y del intercambio cuanto sea necesario.

Líneas seriales: Cuenta cada vez mayor de las transiciones de portadora en el link serial

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

Síntoma: Un número creciente de cuenta de las transiciones de portadora en el link serial.

El cuadro 15-7 delinea los Posibles problemas que pueden causar este síntoma y sugiere las soluciones.

Cuadro 15-7: Líneas seriales: Cuenta cada vez mayor de las transiciones de portadora en el link serial

Posible problema Solución
Los problemas siguientes pueden dar lugar a este síntoma:
  • Línea interrupciones debido a una fuente externa (tal como separación física de cableado, alarmas rojas o amarillas T1, o relámpagos cayendo en alguna parte a lo largo de la red)
  • Switch defectuoso, DSU, o hardware de router
  1. Hardware del control en los ambos extremos del link. Asocie una caja de conexión o un analizador serie y una prueba para determinar el origen de los problemas.
  2. Si un analizador o una caja de conexión no puede identificar cualesquiera problemas externos, marque el hardware de router.
  3. Intercambie el equipo defectuoso según sea necesario.

Usando el comando show controllers

El comando show controllers exec es otra herramienta de diagnóstico importante al localizar averías las líneas seriales. La sintaxis de los comandos varía dependiendo de la plataforma:

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

  • Para los accessos a los productos de Cisco, utilice el comando show controllers exec.

  • Para el AGS, el CGS, y el MGS, utilizan el comando show controllers mci exec.

El cuadro 15-2 muestra la salida del comando show controllers cbus exec. Este comando se utiliza en los Cisco 7000 Series Router con el indicador luminoso LED amarillo de la placa muestra gravedad menor rápido del procesador de interfaz serial (FSIP). Marque la salida de comando para asegurarse que el cable a la unidad de servicio de canal/unidad de servicio digital (CSU/DSU) esté asociado a la interfaz apropiada. Usted puede también marcar la versión de microcódigo para ver si es actual.

Cuadro 15-2: salida del comando show controllers cbus

/image/gif/paws/14149/15_2.gif

En los accessos a los productos tales como el Cisco 2000, el Cisco2500, el Cisco 3000, y el Access Server y el Routers de las Cisco 4000 Series, utilizan el comando show controllers exec. El cuadro 15-3 muestra el comando show controllers hecho salir del Basic Rate Interface (BRI) y de las interfaces seriales en un Access Server del Cisco 2503. (Nota que una cierta salida no está mostrada.)

La salida de reguladores de la demostración indica el estado de los canales de interfaz y si un cable está asociado a la interfaz. En el cuadro 15-3, la interfaz serial 0 tiene un cable de DTE RS-232 asociado. La interfaz serial 1 no tiene ningún cable asociado.

El cuadro 15-4 muestra la salida del comando show controllers mci. Este comando se utiliza en el AGS, el CGS, y los routeres MGS solamente. Si la interfaz eléctrica se visualiza como DESCONOCIDO (en vez del V.35, del EIA/TIA-449, o de un cierto otro tipo de interfaz eléctrica), un cable conectado es incorrectamente el posible problema. Un mún applique o un problema con el cableado interno del indicador luminoso LED amarillo de la placa muestra gravedad menor es también posible. Si la interfaz eléctrica es desconocida, la visualización correspondiente para el comando show interfaces serial exec mostrará que la interfaz y el Line Protocol están abajo.

Cuadro 15-3: salida del comando show controllers

/image/gif/paws/14149/15_3.gif

Cuadro 15-4: salida del comando show controllers mci

/image/gif/paws/14149/15_4.gif

‘Uso de los comandos de depuración’

La salida de los diversos comandos debug privileged exec proporciona la información de diagnóstico referente al estado del protocolo y la actividad de la red para muchos acontecimientos de funcionamiento entre redes.

precaución Precaución:  Porque asignan salida de debbuging un prioritario en proceso de la CPU, puede hacer el sistema 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 comandos debug siguientes son útiles al localizar averías el serial y los problemas de WAN. Más información sobre la función y la salida de cada uno de estos comandos se proporciona en la publicación de la referencia del comando Debug:

  • la interfaz en serie del debug verifica si los paquetes de keepalive del HDLC 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.

  • los eventos del debug x25 detectan los eventos X.25, tales como la apertura y el closing de los circuitos virtuales conmutados (SVC). La “causa resultante y” la información de diagnóstico se incluye con el informe del evento.

  • haga el debug de la información X.25 del link de Proceso de Acceso a link Balanceado (LAPB) o del nivel 2 de las salidas LAPB.

  • el debug ARP indica sobre si el router está enviando la información o está aprendiendo sobre el Routers (con los paquetes ARP) en el otro lado de la nube de WAN. Utilice este comando cuando están respondiendo algunos Nodos en una red TCP/IP pero no son otros.

  • el Frame Relay LMI del debug obtiene la información de la Interfaz de administración local (LMI) útil para determinar si un switch de Frame Relay y un router son de envío y de recepción de los paquetes LMI.

  • los eventos del Frame Relay del debug determinan si los intercambios están ocurriendo entre un router y un switch de Frame Relay.

  • haga el debug de los paquetes del protocolo shows point-to-point de la negociación ppp (PPP) transmitidos durante el inicio de PPP, donde se negocia la opción PPP.

  • haga el debug de los paquetes PPP de las demostraciones del paquete ppp que son enviados y recibidos. Este comando indica el vaciado de paquetes de bajo nivel.

  • los errores ppp del debug muestran los errores de PPP (tales como ilegal o tramas mal formadas) asociados a la negociación y a la operación de la conexión PPP.

  • la grieta ppp del debug muestra los intercambios de paquetes del Challenge Handshake Authentication Protocol (CHAP) y del protocolo password authentication PPP (PAP).

  • el paquete serial del debug muestra los paquetes del Switched Multimegabit Data Service (SMDS) que son enviados y recibidos. Esta visualización también imprime los mensajes de error para indicar porqué un paquete no fue enviado ni fue recibido erróneamente. Para el S DS, el comando vacia el encabezado SMDS entero y un ciertos datos de carga útil cuando se transmite o se recibe un paquete SMDS.

Usando las pruebas Extended PING

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 determinado útil cuando los niveles elevados de errores de entrada se están registrando en la visualización serial de las interfaces de la demostración. Véase el cuadro 15-1.

Los dispositivos de conexión entre redes Cisco proporcionan un mecanismo para automatizar el envío de paquetes ping en secuencia. El cuadro 15-5 ilustra el menú usado para especificar las opciones del ping extendido. Este ejemplo especifica 20 ping sucesivos. Sin embargo, al probar los componentes en su línea serial, usted debe especificar un número mucho más grande, tal como 1000 ping.

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

/image/gif/paws/14149/15_5.gif

Ejecución de las pruebas de ping

Realice generalmente las pruebas de ping en línea serie como sigue:

  1. Ponga el CSU o el DSU en el Local Loopback Mode.

  2. Configure el comando extended ping de enviar los diversos patrones de datos y tamaños de paquetes. El cuadro 15-6 y el cuadro 15-7 ilustran dos pruebas de ping útiles, los todos ceros (1500-byte) hacen ping y el todo uno (1500-byte) hace ping, respectivamente.

  3. Examine el salida del comando show interfaces serial (véase el cuadro 15-1) y determinelo 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.

    Si se asume que esta secuencia de prueba fue indicada por el aspecto de un gran número de CRC y de errores en la trama, un problema con EL reloj es probable. Marque el CSU o el DSU por un problema de sincronización. Vea la sección “problemas con EL reloj del troubleshooting,” más adelante en este capítulo.

  4. Si usted determina que la configuración de reloj está correcta y está actuando correctamente, pone el CSU o el DSU en el Remote Loopback Mode.

  5. Relance la prueba de ping y busque los cambios en las estadísticas del error de entrada.

  6. Si los errores de entrada aumentan, hay un problema en la línea serial o en el CSU/DSU. Entre en contacto el proveedor de servicio PÁLIDO e intercambie el CSU o el DSU. Si persisten los problemas, entre en contacto su representante de soporte técnico.

Cuadro 15-6: Prueba de ping de los todos ceros 1500-Byte

/image/gif/paws/14149/15_6.gif

Cuadro prueba de ping del todo uno 1500-Byte de 15-7

/image/gif/paws/14149/15_7.gif

Localización de averías de los problemas con EL reloj

Los conflictos de temporización en las conexiones en serie pueden llevar al servicio crónico de la pérdida de conexión o al rendimiento disminuido. Esta sección discute los aspectos importantes de los problemas con EL reloj: causas del problema con EL reloj, detectando los problemas con EL reloj, aislando los problemas con EL reloj, y las Soluciones de problemas del reloj.

Descripción general de temporización

El 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 por lo menos un valor 1-bit para cada 8 bits de los datos que pasan con él; esto se conoce como unos densidad. Mantener unos densidad permite que el hardware recupere el reloj de datos confiablemente.

Más nuevas implementaciones T1 utilizan comúnmente el Formato extendido superframe (ESF) que enmarca con la codificación de la sustitución binaria de ocho ceros (B8ZS). El B8ZS proporciona un esquema por el cual un código especial sea substituido siempre que ocho ceros consecutivos se envíen a través del link serial. Este código entonces se interpreta en el extremo remoto de la conexión. Esta técnica garantiza unos densidad independiente de la secuencia de datos.

Más viejas implementaciones T1 utilizan D4-also conocido como Superframe Format (SF) el enmarcar y codificación de la Inversión alternada de marcas (AMI). El AMI no utiliza un esquema de codificación como el B8ZS. Esto restringe el tipo de datos que puedan ser transmitidos porque unos densidad no son independiente mantenida de la secuencia de datos.

Otro elemento importante en las comunicaciones seriales es Temporización de terminal de la transmisión del reloj en serie externa (SCTE). El SCTE es el reloj producido eco detrás del dispositivo del equipo de terminal de datos (DTE) (por ejemplo, un router) al dispositivo de Equipo de comunicación de datos (DCE) (por ejemplo, el CSU/DSU).

Cuando el dispositivo DCE utiliza el SCTE en vez de su reloj interno para muestrear los datos del DTE, puede mejor muestrear los datos sin el error incluso si hay un desplazamiento de fase en el cable entre el CSU/DSU y el router. Usando el SCTE se recomienda altamente para las transmisiones seriales más rápidamente de 64 kbps. Si su CSU/DSU no soporta el SCTE, vea la sección el “invertir del reloj de transmisión,” más adelante en este capítulo.

Causas del problema con EL reloj

Los problemas con EL reloj en las interconexiones del WAN serial se pueden atribuir generalmente a una de las causas siguientes:

  • Configuración incorrecta de DSU

  • Configuración incorrecta CSU

  • Cables fuera de especificación-que es, más de largo de 50 pies (15.24 contadores) o sin blindaje

  • Conexiones ruidosas o pobres del panel de conexiones

  • Varios cables conectados juntos en fila

Detección de los problemas con EL reloj

Para detectar los conflictos de temporización en una interfaz serial, busque los errores de entrada como sigue:

  1. Utilice el comando show interfaces serial exec en el Routers en los ambos extremos del link.

  2. Examine la salida de comando para el CRC, los errores en la trama, y los abortos.

  3. Si cualquiera de estos pasos indica los errores que exceden un rango aproximado del 0.5 por ciento el 2.0 por ciento de tráfico en la interfaz, los problemas con EL reloj son probables existir en alguna parte en WAN.

  4. Aísle la fuente de los conflictos de temporización de acuerdo con la sección siguiente, “aislando los problemas con EL reloj.”

  5. Desvíe o repare a cualquier panel de conexiones defectuoso.

Aislamiento de los problemas con EL reloj

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

  1. Realice una serie de pruebas de ping y de pruebas de Loopback (local y remoto), según lo descrito en la sección las “pruebas CSU y del DSU Loopback,” anterior en este capítulo.

  2. Determine el extremo de la conexión que es la fuente del problema, o si el problema está en la línea. En el Local Loopback Mode, funcione con los diversos modelos y tamaños en las pruebas de ping (por ejemplo, los datagramas del uso 1500-byte). Usando un solos modelo y tamaños de paquetes no puede forzar los errores a materializar, determinado cuando un cable serial al router o al CSU/DSU es el problema.

  3. Utilice el comando show interfaces serial exec y determinelo si las cuentas de errores de entrada están aumentando y donde están acumulando.

Si los errores de entrada están acumulando en los ambos extremos de la conexión, el cronometrar del CSU es el problema más probable.

Si solamente un extremo está experimentando los errores de entrada, hay probablemente una temporización DSU o un problema del cableado.

Los abortos en un extremo sugieren que el otro extremo esté enviando la mala información o que hay un problema de línea.

Nota: Refiera al salida del comando show interfaces serial (véase el cuadro 15-1) y registre siempre cualquier cambio en las cuentas de errores o la nota si la cuenta de errores no cambia.

Soluciones de problemas del reloj

Líneas del serial del cuadro 15-8: Problemas con EL reloj y soluciones: Esta tabla delinea los remedios sugeridos por problemas con EL reloj, sobre la base de la fuente del problema.

Posible problema Solución
Configuración incorrecta CSU
  1. Determine si los CSU en los ambos extremos están de acuerdo con la fuente de reloj (local o línea).
  2. Si los CSU no están de acuerdo, configurelos de modo que lo hagan. La línea es generalmente la fuente.
  3. Marque la configuración LBO en el CSU para asegurarse de que la impedancia hace juego el de la línea física. Para la información sobre configurar su CSU, consulte su documentación sobre hardware CSU.
Configuración incorrecta de DSU
  1. Determine si los DSU en los ambos extremos tienen el modo SCTE habilitado.
  2. Si el SCTE no se habilita en los ambos extremos de la conexión, habilitela.
  3. Aseegurese que uno densidad están mantenidas. Esto requiere que el uso DSU el mismo enmarcar y esquemas de codificación (por ejemplo, ESF y B8ZS) usados por la línea arrendada o el otro servicio de portadora. Marque con su proveedor para obtener información de la línea arrendada en su enmarcar y esquemas de codificación.
  4. Si su servicio de portadora utiliza la codificación de AMI, o invierta el reloj de transmisión a ambos lados del link o ejecute el DSU en el modo de relleno de bits. Para la información sobre configurar su DSU, consulte su documentación sobre hardware DSU.
El cable al router está fuera de especificación Si el cable es más largo de 50 pies (15.24 contadores), utilice un cable más corto. Si el cable es sin blindaje, substitúyalo por el cable blindado.

Inversión del reloj de transmisión

Si usted está intentando las conexiones en serie en mayor de 64 kbps de las velocidades con un CSU/DSU que no soporte el SCTE, usted puede tener que invertir el reloj de transmisión en el router. La inversión del reloj de transmisión compensa los desplazamientos de fase entre los datos y las señales de reloj.

El comando específico usado 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 Router, utilice el comando dte-invert-txc interface configuration.

Para asegurarse de que usted esté utilizando el sintaxis del comando correcto para su router, refiera al guía del usuario para su router o Access Server y a las guías y a las referencias de comandos de configuración del Cisco IOS.

Nota: En más viejas Plataformas, la inversión del reloj de transmisión puede requerir que usted mueve un puente físico.

Ajuste de los buffers

Excesivamente - los resultados del uso elevado del ancho de banda (sobre 70percent) en el rendimiento general reducido y pueden causar las fallas intermitentes. Por ejemplo, las transmisiones de archivo DECnet pueden ser el fallar debido a los paquetes que son caídos en alguna parte en la red.

Si la situación es bastante mala, usted debe aumentar el ancho de banda del link. Sin embargo, el aumento del ancho de banda puede no ser necesario o inmediatamente práctico. Una manera de resolver la línea serial marginal problemas del overutilization es controlar cómo el router utiliza los búferes de datos.

precaución Precaución: No ajuste generalmente los búferes del sistema a menos que usted esté trabajando de cerca con un representante de soporte técnico de Cisco. Usted puede afectar seriamente al funcionamiento de su hardware y de su red si usted ajusta incorrectamente los búferes del sistema en su router.

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

  • Ajuste los parámetros asociados a los búferes del sistema

  • Especifique el número de paquetes sostenidos en la cola de entrada o salida (las colas en espera)

  • Dé prioridad a cómo el tráfico se hace cola para la transmisión (Datos en espera de prioridad de resultado)

Describen a los comandos configuration asociados a estas opciones en las guías y las referencias de comandos de configuración del Cisco IOS.

La sección siguiente se centra en la identificación de las situaciones en las cuales estas opciones son probables aplicarse y definiendo cómo usted puede utilizar estas opciones para ayudar a resolver la Conectividad y los problemas de rendimiento en las interconexiones serial/WAN.

Ajustes del búfer del sistema

Hay dos tipos generales del buffer en los routeres Cisco: búferes de hardware y búferes del sistema. Solamente los búferes del sistema son directamente configurables por los administradores de sistema. Los búferes de hardware se utilizan específicamente como la recepción y transmiten los buffers asociados a cada interfaz y (en ausencia de cualquier configuración especial) son manejados dinámicamente por el software del sistema sí mismo.

Los búferes del sistema se asocian a la memoria de sistema principal y son bloques de memoria afectados un aparato de los diferente-tamaños. Un comando útil para determinar el estatus de sus búferes del sistema es el comando show buffers exec. El cuadro 15-8 muestra la salida del comando show buffers.

Cuadro salida del comando show buffers de 15-8

/image/gif/paws/14149/15_8.gif

En la salida de show buffers:

  • el total identifica el número total de buffers en el pool, incluyendo utilizado y los búferes sin usar.

  • la permanente identifica la cantidad permanente de memorias intermedias asignadas en el pool. Estos buffers están siempre en el pool y no se pueden quitar.

  • en la lista disponible identifica la cantidad de búfers actualmente en el pool que está disponible para el uso.

  • el minuto identifica el número mínimo de buffers que el (RP) del Route Processor deba intentar para mantener la lista disponible:

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

    • Si la cantidad de búfers en la lista disponible cae debajo del valor mínimo, el RP intenta crear más buffers para ese pool.

  • máximo permitido identifica el número máximo de buffers permitidos en la lista disponible:

    • El parámetro máximo permitido previene un pool de los buffers que monopolizan que no necesita más y libera esta memoria de nuevo al sistema para el uso adicional.

    • Si la cantidad de búfers en la lista disponible es mayor que el valor permitido máximo, el RP debe intentar cortar los buffers del pool.

  • los golpes identifican la cantidad de búfers que se han preguntado el pool. El contador de aciertos otorga un mecanismo para determinar qué conjunto debe cumplir con la mayor demanda para las memorias intermedias.

  • las faltas identifican la cantidad de veces que se ha pedido un buffer y el RP detectó que los buffers adicionales fueron requeridos. (Es decir la cantidad de búfers en la lista disponible ha caído debajo del Min.) las faltas al revés representan la cantidad de veces que el RP se ha forzado para crear los buffers adicionales.

  • los ajustes identifican la cantidad de búfers que el RP ha cortado del pool cuando la cantidad de búfers en la lista disponible excedió el número de buffers permitidos máximos.

  • creado identifica la cantidad de búfers que se ha creado en el pool. El RP crea los buffers cuando la demanda para los buffers ha aumentado hasta que la cantidad de búfers en la lista disponible sea menos que los buffers mínimos y/o una falta ocurre debido a los buffers cero en la lista disponible.

  • los incidentes identifican el número de errores conceder un buffer a un solicitante incluso después intentar crear un buffer adicional. El número de errores representa el número de paquetes que han sido caído debido a la escasez de búfer.

  • ninguna memoria identifica el número de errores hechos por la memoria insuficiente para crear los buffers adicionales.

La salida del comando show buffers en el cuadro 15-8 indica los números altos en los ajustes y los campos creados para los buffers grandes. Si usted está recibiendo los números altos en estos campos, usted puede aumentar su rendimiento del link en serie aumentando el valor libre máximo configurado para sus búferes del sistema. los ajustes identifican la cantidad de búfers que el RP ha cortado del pool cuando la cantidad de búfers en la lista disponible excedió el número de buffers permitidos máximos.

Utilice el comando buffers max free number global configuration de aumentar el número de buffers del sistema libre. El valor que usted configura debe ser el aproximadamente 150 por ciento de la figura indicada en el campo total de la salida del comando show buffers. Relance este proceso hasta que la salida de buffers de la demostración indique no más los ajustes y los buffers creados.

Si la salida del comando show buffers muestra un gran número de errores en el campo (de ninguna memoria) (véase la línea más reciente de salida en el cuadro 15-8), usted debe reducir el uso de los búferes del sistema o aumentar la cantidad de compartido o memoria principal (RAM físico) en el router. Llame su representante de soporte técnico para la ayuda.

Implementar los límites de la cola en espera

Las colas en espera son buffers usados por cada interfaz del router para salvar los paquetes entrantes o salientes. Utilice el comando hold-queue interface configuration de aumentar el número de paquetes de datos hechos cola antes de que el router caiga los paquetes. Aumente estas colas de administración del tráfico en los pequeños incrementos (por ejemplo, el 25 por ciento) hasta que usted vea no más los descensos en la salida de las interfaces de la demostración. El límite predeterminado de la cola de retención de salida es 100 paquetes.

Nota: Utilizan al comando hold-queue para los paquetes process-switched y las actualizaciones periódicas generados por el router.

Utilice el comando hold-queue de evitar que los paquetes sean caídos y de mejorar el rendimiento del link en serie bajo condiciones siguientes:

  • Usted tiene una aplicación que no pueda tolerar los descensos y el protocolo puede tolerar retardos más largos. El DECNet es un ejemplo de un protocolo que cumpla ambos criterios. El Local Area Transport (LAT) no hace porque no tolera los retardos.

  • La interfaz es muy lenta. El ancho de banda es bajo o la utilización anticipada es probable exceder esporádico el ancho de banda disponible.

Nota: Cuando usted aumenta el número especificado para una cola de retención de salida, usted puede necesitar aumentar el número de búferes del sistema. El valor usado depende de los tamaños de los paquetes asociados al tráfico anticipado para la red.

Usando la cola prioritaria para reducir los embotellamientos

La cola prioritaria es un mecanismo de control basado en listas que permite que el tráfico sea dado prioridad sobre una base de la interfaz-por-interfaz. La cola prioritaria implica dos pasos:

  1. Cree una lista de prioridad por el Tipo de protocolo y el nivel de prioridad.

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

Ambos pasos utilizan las versiones del comando priority-list global configuration. Además, el control de tráfico adicional se puede aplicar por los comandos referencing access-list global configuration de las especificaciones de la prioridad-lista. Por ejemplos de la definición de las listas de prioridad y para más información sobre la sintaxis de los comandos asociada a la cola prioritaria, refiera a las guías y a las referencias de comandos de configuración del Cisco IOS.

Nota: La cola prioritaria crea automáticamente cuatro colas en espera de los tamaños variables. Esto reemplaza cualquier especificación de la cola en espera incluida en su configuración.

Utilice la cola prioritaria para evitar que los paquetes sean caídos y para mejorar el rendimiento del link en serie bajo condiciones siguientes:

  • Cuando la interfaz es lenta, hay una variedad de tipos de tráfico que son transmitidos, y usted quiere mejorar el funcionamiento del tráfico del terminal.

  • Si usted tiene un link serial que está experimentando intermitentemente mismo la cola prioritaria de las cargas pesadas (tales como transferencias de archivos que ocurren en el tiempo específico) ayudará selecciona qué tipos de tráfico deben ser desechados en los períodos del mucho tráfico.

Comience generalmente con el número predeterminado de colas al implementar las colas de prioridad. Después de habilitar la cola prioritaria, monitoree las caídas de resultados con el comando show interfaces serial exec. Si usted le nota que las caídas de resultados están ocurriendo en la cola de tráfico ha especificado para ser prioritario, aumente el número de paquetes que puedan ser hechos cola (usando la opción de la palabra clave de límite de cola del comando priority-list global configuration). Los argumentos del límite de cola predeterminado son 20 paquetes para la cola de alta prioridad, 40 para el media, 60 para normal, y 80 para el punto bajo.

Nota: Al interligar el tráfico LAT de Digital Equipment Corporation (DEC), el router debe caer muy pocos paquetes, o las sesiones LAT pueden terminar inesperado. Una profundidad de la cola de alta prioridad de cerca de 100 (especificado con la palabra clave de límite de cola) es un valor de trabajo típico cuando su router está cayendo los paquetes de salida y las líneas seriales se sujeta al uso del ancho de banda del cerca de 50 por ciento. Si el router está cayendo los paquetes y está en la utilización de porcentaje 100, usted necesita otra línea.

Otra herramienta para aliviar la congestión al interligar el LAT de DEC es compresión LAT. Usted puede implementar la compresión LAT con la lat-compresión del grupo del bridge-group del comando interface configuration.

Pruebas de línea serial especial

Además de las capacidades de diagnóstico básicas disponibles en el Routers, una variedad de herramientas suplementarias y de técnicas se pueden utilizar para determinar las condiciones de los cables, del equipo de Switching, de los módems, de los hosts, y del hardware de interconexión remota. Para más información, consulte la documentación para su CSU, el DSU, el analizador serie, o el otro equipo.

Pruebas CSU y del DSU Loopback

Si la salida del comando show interfaces serial exec indica que la línea serial está para arriba solamente el Line Protocol está abajo, utilice las pruebas de Loopback CSU/DSU para determinar la fuente del problema. Realice el Local Loop Test primero, y entonces la prueba remota. El cuadro 15-9 ilustra la topología básica de la pruebas de Local y Remote Loopback CSU/DSU.

Cuadro 15-9: Pruebas de Local y Remote Loopback CSU/DSU

/image/gif/paws/14149/15_9.gif

Nota: Estas pruebas son genéricas en la naturaleza y asumen la conexión del sistema de interconexión en red a un CSU o a un DSU. Sin embargo, las pruebas son esencialmente lo mismo para la conexión a un multiplexor con las funciones incorporadas CSU/DSU. Porque no hay concepto de un loopback en los entornos del Packet Switched Network X.25 o del Frame Relay (PSN), las pruebas de Loopback no se aplican al X.25 y a las redes Frame Relay.

Pruebas del Local Loopback CSU y DSU para el HDLC o los links PPP

Se enumera abajo un Procedimiento general para realizar las pruebas de Loopback conjuntamente con las capacidades incorporadas del Diagnóstico de sistema:

  1. Coloque el CSU/DSU en el Local Loop Mode (refiera a su documentación del vendedor). En el Local Loop Mode, el uso del reloj de línea (del Servicio T1) se termina, y el DSU se fuerza para utilizar el reloj local.

  2. Utilice el comando show interfaces serial exec de determinar si la línea cambios de estado del el protocolo de línea está desactivado al “Line Protocol está para arriba (colocado),” o si permanece abajo.

  3. Si sube el Line Protocol cuando el CSU o el DSU está en el Local Loopback Mode, éste sugiere que el problema esté ocurriendo en el extremo remoto de la conexión en serie. Si la línea del estado no cambia el estado, hay un Posible problema en el router, el cable de conexión, o el CSU/DSU.

  4. Si el problema aparece ser local, utilice el comando debug serial interface privileged exec.

  5. Saque el CSU/DSU del Local Loop Mode. Cuando el Line Protocol está abajo, la salida del comando debug serial interface indicará que los contadores de keepalives no están incrementando.

  6. Coloque el CSU/DSU en el Local Loop Mode otra vez. Esto debe hacer los paquetes de keepalive comenzar a incrementar. Específicamente, los valores para el mineseen y los keepalives yourseenes incrementarán cada 10 segundos. Esta información aparecerá en la salida de la interfaz serial del debug.

    Si el Keepalives no incrementa, puede haber un problema de sincronización en la placa de interfaz o en la red. Para la información sobre la corrección de los problemas de sincronización, vea la sección “problemas con EL reloj del troubleshooting,” anterior en este capítulo.

    Si el Keepalives no incrementa, puede haber un problema de sincronización en la placa de interfaz o en la red. Para la información sobre la corrección de los problemas de sincronización, vea la sección “problemas con EL reloj del troubleshooting,” anterior en este capítulo.

  7. Marque el router local, el hardware CSU/DSU, y cualquier cable conectado. Asegúrese que los cables estén dentro del recomendado longitud-ningunos más de 50 pies (15.24 contadores) o 25 pies (7.62 contadores) para un link T1. Asegúrese los cables se asocian a los puertos apropiados. Intercambie el equipo defectuoso según sea necesario.

El cuadro 15-10 muestra la salida del comando debug serial interface para una conexión en serie del HDLC, con el Keepalives faltado haciendo la línea ir abajo y la interfaz reajustar.

Cuadro 15-10: salida del comando debug serial interface

/image/gif/paws/14149/15_10.gif

Pruebas del Loopback remoto CSU y DSU para el HDLC o los links PPP

Si usted determina que está funcionando el hardware local correctamente pero usted todavía encuentra los problemas al intentar establecer las conexiones sobre el link serial, intenta usar el Remote Loopback Test para aislar la causa del problema.

Nota: Este Remote Loopback Test asume que se está utilizando el encapsulado HDCL y que el Local Loop Test precedente fue realizado inmediatamente antes de esta prueba.

Para realizar pruebas con el loopback se requieren los siguientes pasos: Para realizar pruebas con el loopback se requieren los siguientes pasos:

  1. Ponga el telecontrol CSU o DSU en el Remote Loopback Mode (refiera a la documentación del vendedor).

  2. Usando el comando show interfaces serial exec, determine si el Line Protocol permanece para arriba con la línea del estado que indica que “x serial está para arriba, Line Protocol está para arriba (colocado),” o si va abajo con la línea del estado que indica el “Line Protocol está abajo.”

  3. Si permanece el Line Protocol para arriba (colocado), el problema está probablemente en el extremo remoto de la conexión en serie (entre el telecontrol CSU/DSU y el router remoto). Realizar ambas pruebas, remotas y locales, en el extremo remoto para aislar la causa del problema.

  4. Si la línea cambios de estado al el protocolo de línea está desactivado cuando se activa el Remote Loopback Mode, se aseegura que uno densidad se están manteniendo correctamente. El CSU/DSU se debe configurar para utilizar mismo enmarcar y esquemas de codificación usados por la línea arrendada o el otro servicio de portadora (por ejemplo, ESF y B8ZS).

  5. Si persisten los problemas, entre en contacto su administrador de red WAN o a la organización de servicio PÁLIDA.

Información detallada en el comando show interfaces serial

Las subdivisiones siguientes cubren los parámetros, la descripción de la sintaxis, la visualización del ejemplo de resultado, y las Descripciones del campo de comando show interfaces serial.

muestre los parámetros del serial de las interfaces

Al mostrar información sobre una interfaz serial, utilice el comando show interfaces serial privileged exec:

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

  • Número-opcional. Número del puerto.

  • Estadística-opcional. Visualiza el número de paquetes de cada Tipo de protocolo que se han enviado a través de la interfaz.

  • : canal-grupo - Opcional. En las Cisco 4000 Series con un NPM o las Cisco 7500 Series con una MIPS, especifica el número del grupo de canales T1 en el rango de 0 a 23, definido con el comando channel-group controller configuration.

  • slot - Se refiere al manual de hardware apropiado para la información del slot.

  • puerto - Se refiere al manual de hardware apropiado para la información de puerto.

  • puerto-ADAPTER - Se refiere al manual de hardware apropiado para la 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 1 a 28 bastante que el esquema basado en cero más tradicional (0 a 27) usado con los otros productos de Cisco. Éste es asegurar el estado coherente con los esquemas de numeración de la compañía telefónica para los canales T1 dentro del equipo canalizado T3.

  • CRB-opcional. Encaminamiento de la interfaz de las demostraciones e información del bridging.

Modo de comando

EXEC privilegiado

Pautas de uso

Este comando primero apareció en el Cisco IOS Release 10.0 para las Cisco 4000 Series. Primero apareció en el Cisco IOS Release 11.0 para el Cisco 7000 Series, y fue modificado en el Cisco IOS Release 11.3 para incluir el CT3IP.

Presentaciones de ejemplo

Lo que sigue es salida de muestra del comando show interfaces para una interfaz de serie sincrónico:

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

Cuadro 15-9: muestre a interfaces las Descripciones del campo seriales - esta tabla describe los campos significativos mostrados en la salida.

Campo Descripción
El serial… es {encima de | abajo}… está administrativo abajo Indica si el hardware de la interfaz está actualmente - el active (la detección de la portadora está presente) o si ha sido tomada abajo por un administrador.
el Line Protocol es {encima de | abajo} Indica si los procesos del software que dirigen el Line Protocol consideran la línea usable (es decir, el Keepalives es acertado) o si él ha sido tomado abajo por un administrador.
el Line Protocol es {encima de | abajo} Indica si los procesos del software que dirigen el Line Protocol consideran la línea usable (es decir, el Keepalives es acertado) o si él ha sido tomado abajo 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 (MTU) de la interfaz.
BW Indica el valor del parámetro de ancho de banda que se ha configurado para la interfaz (en los kilobites por segundo). El parámetro de ancho de banda se utiliza para computar las mediciones IGRP solamente. Si la interfaz se asocia a una línea serial con una velocidad de línea que no haga juego el valor por defecto (1536 o 1544 para el T1 y 56 para una línea serial síncrona estándar), utilice el comando bandwidth de especificar la velocidad de línea correcta para esta línea serial.
DLY Retardo de la interfaz en los microsegundos.
confíe Confiabilidad de la interfaz como una parte de 255 (255/255 es el 100 por ciento de confiabilidad), calculada como promedio exponencial durante cinco minutos.
carga Confiabilidad de la interfaz como una parte de 255 (255/255 es el 100 por ciento de confiabilidad), calculada como promedio exponencial durante cinco minutos.
‘Encapsulación Método de encapsulación asignado a la interfaz.
loopback Indica si el loopback está fijado.
keepalive Indica si el Keepalives está fijado.
La entrada más reciente Número de horas, de minutos, y de segundos puesto que el paquete más reciente fue recibido con éxito por una interfaz. Útil para saber cuando una interfaz muerta falló.
La salida más reciente Número de horas, de minutos, y de segundos puesto que el paquete más reciente fue transmitido con éxito por una interfaz. Número de horas, de minutos, y de segundos puesto que el paquete más reciente fue transmitido con éxito por una interfaz.
caída de la salida Número de horas, de minutos, y de segundos (o nunca) puesto que la interfaz era la restauración más reciente debido a una transmisión que duró demasiado. Cuando el número de horas en los campos más recientes uces de los excede de 24, el número de días y de horas se imprime. Si desborda ese campo, se imprimen los asteriscos.
Cola de salida, cola de entrada de los descensos, descensos Número de paquetes en las colas de administración del tráfico de entrada y salida. Cada número es seguido por una raya vertical, los tamaños máximos de la cola, y el número de paquetes porque la cola es llena.
5 tarifa de salida de minuto minuciosa de la velocidad de entrada 5 Número medio de bits y de paquetes transmitidos por segundo en los últimos cinco minutos. La velocidad de entrada y de salida del minuto cinco se debe utilizar solamente como aproximación del tráfico por segundo durante un periodo de cinco minutos dado. Estas tarifas son exponencial promedios ponderados con un constante de tiempo de cinco minutos. Un período de cuatro constantes de tiempo debe pasar antes de que la media esté dentro del 2 por ciento del índice instantáneo de una secuencia uniforme del tráfico durante ese período.
entrada de paquetes Número total de paquetes libres de errores recibidos por el sistema.
bytes Número total de bytes, incluyendo los datos y la encapsulación de MAC, en los paquetes libres de errores recibidos por el sistema.
no buffer Número de paquetes recibidos desechados porque no había espacio del búfer en el sistema principal. Comparar con contador ignorado. Las tormentas de broadcast en las redes Ethernet y las explosiones del ruido en las líneas seriales son a menudo responsables de ningunos eventos de la memoria intermedia de entrada.
… Broadcasts recibidos Número total de broadcast o de paquetes de multidifusión recibidos por la interfaz.
fragmentos minúsculos Número de paquetes se desechan que porque son más pequeños que los tamaños mínimos de paquete del media.
gigantes Número de paquetes se desechan que porque exceden los tamaños máximos de paquete del media.
errores de entrada Número total de ningún buffer, runts, gigantes, CRC, bastidor, overrun, ignorado, y cuentas del aborto. Otros errores relacionados a la entrada pueden también incrementar la cuenta, así que esta suma puede no equilibrar con el otro cuenta.
CRC La verificación por redundancia cíclica generada por la estación de origen o el dispositivo en el extremo no hace juego la suma de comprobación calculada de los datos recibidos. En un link serial, los CRC indican generalmente el ruido, los golpes del aumento, u otros problemas de transmisión en el link de datos.
trama El número de paquetes recibió incorrectamente tener error crc y un número no entero de octetos. En una línea serial, éste es generalmente el resultado del ruido o de otros problemas de transmisión.
desbordamiento La cantidad de veces el hardware de recepción en serie no podía dar los datos recibidos a un búfer de hardware porque la velocidad de entrada excedió la capacidad del receptor de manejar los datos.
ignorado Número de paquetes recibidos ignorados por la interfaz porque el hardware de la interfaz se ejecutó bajo 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 los bits uno en una interfaz serial. Esto indica generalmente un problema con EL reloj entre la interfaz serial y el equipo de link de datos.
transiciones de portadora La cantidad de veces la señal de detección de la portadora de una interfaz serial ha cambiado el estado. Por ejemplo, si el Data Carrier Detect (DCD) va abajo y sube, el contador de la transición de portadora incrementará dos veces. Indica modem o problemas de línea si la línea de la detección de la portadora está cambiando el estado a menudo.
salida de los paquetes Número total de mensajes transmitidos por el sistema.
salida de los bytes Número total de bytes, incluyendo los datos y la encapsulación de MAC, transmitidos por el sistema.
underruns La cantidad de veces que el transmisor se ha estado ejecutando más rápidamente que el router puede dirigir. Esto se puede nunca señalar sobre algunas interfaces.
errores de salida Suma de todos los errores que previnieron la transmisión final de la interfaz de los de los datagramas que era examinada. Observe que esto puede no equilibrar 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 entren en las categorías específicamente tabuladas unas de los.
colisiones El número de mensajes retransmitió debido a una colisión Ethernet. Éste es generalmente el resultado de un LAN extendido demasiado (es decir, los Ethernetes o cable transceptor demasiado de largo, más de dos repetidores entre las estaciones, o demasiados los transmisores-receptores conectados en cascada del multiport). Algunas colisiones son normales. Sin embargo, si su índice de colisiones sube al alrededor 4 por ciento o al 5 por ciento, usted debe considerar verificar que no hay equipo defectuoso en el segmento y/o la mudanza de algunas estaciones existentes a un nuevo segmento. Un paquete que choca se cuenta solamente una vez en los paquetes de salida.
restauraciones de la interfaz La cantidad de veces una interfaz se ha reajustado totalmente. Esto puede suceder si los paquetes hechos cola para la transmisión no fueron enviados dentro de varios la segunda vez. En una línea serial, esto se puede causar por un módem que funciona incorrectamente que no esté suministrando la señal del reloj de transmisión, o por un problema de cable. Si los sistemas detecta que la línea de la detección de la portadora de una interfaz serial está para arriba solamente el Line Protocol están abajo, reajusta periódicamente la interfaz en un esfuerzo para recomenzarlo. Los reinicios de la interfaz también pueden ocurrir cuando una interfaz posee loopback o está apagada.
reinicios La cantidad de veces el regulador fue recomenzada debido a los errores.
Indicaciones de alarma, alarmas remotas, rx LOF, rx LOS El número de alarmas CSU/DSU, y el número de acontecimientos de reciben la pérdida de trama y reciben la pérdida de señal.
BER inactivo, NELR inactivo, FELR inactivo El estatus del G.703-E1 contradice para la alarma del error de la velocidad bits (BER), el telecontrol del loop del final cercano (NELR), y el telecontrol del loop del otro extremo (FELR). Observe que usted no puede fijar el NELR o el FELR.

Localización de averías del T1

Esta sección describe las técnicas y los procedimientos para localizar averías los circuitos T1 para los clientes de acceso telefónico.

Troubleshooting usando el comando show controller t1

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

El NMP (procesador de administración de red) o la MIPS (procesador de interfaz multicanal) puede preguntar los adaptadores de puerto para determinar su estado actual. Publique un comando show controller t1 de visualizar las estadísticas sobre el link T1.

Si usted especifica un slot y un número del puerto, las estadísticas para el cada período de 15 minutos serán visualizadas. El comando show controller t1 exec proporciona la información para resolver problemas lógicamente los problemas de la Capa física y de la capa del 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 T1 son causados por las líneas mal configuradas. Asegúrese de que el linecoding, el enmarcar y la fuente de reloj estén configurados según lo que recomienda el proveedor de servicio.

muestre las condiciones T1 del regulador

Controlador T1 puede estar en uno de los tres estados siguientes.

  • Bajo rendimiento administrativo

  • Down (inactivo)

  • En funcionamiento

¿Es controlador T1 administrativo abajo?

El regulador está administrativo abajo de cuando se ha apagado manualmente. Usted debe recomenzar el regulador para corregir este error.

  1. Ingrese el enable mode.

    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 de controlador.

    maui-nas-03(config)#controller t1 0
    maui-nas-03(config-controlle)#
  4. Recomience el regulador.

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

¿Es la formación?

Si controlador T1 y la línea no está para arriba, marque para ver si uno de los siguientes mensajes aparece en el EXEC T1 del regulador de la demostración hecho salir:

  • El receptor tiene pérdida de trama

  • El receptor tiene pérdida de señal

Si el receptor T1 tiene pérdida de trama:

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

  1. Marque para ver si el formato de marcos configurado en el puerto hace juego el formato de marcos de la línea. Usted puede marcar el formato de marcos del regulador de la configuración corriente o de la salida del comando show controller t1.

    Para cambiar el formato de marcos utilice enmarcar {SF | Comando ESF} en el modo de configuración de controlador como se muestra abajo:

    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 el otro formato de marcos para ver si la alarma borra.

  3. Cambie configuración de formación de línea usando el cablelength {de largo | comando del cortocircuito}.

El Line Build Out (LBO) compensa la pérdida en los decibelios basados en la distancia del dispositivo al primer repetidor en el circuito. Un más de larga distancia del dispositivo al repetidor requiere que la potencia de la señal en el circuito esté impulsada para compensar la pérdida sobre esa distancia.

Consulte su proveedor de servicio y la referencia de comandos de Cisco IOS� para los detalles en las configuraciones del buildout.

Si esto no repara el problema, proceda “si el receptor T1 tiene a la sección de pérdida de señal” abajo.

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

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

  1. Aseegurese que el cable entre el puerto de la interfaz y el equipo Servicio T1 del proveedor (o el equipo de terminal T1) está conectado correctamente. Marque para ver si el cable se engancha hasta los puertos correctos. Si es necesario, corrija las conexiones de cable.

  2. Marque la integridad del cable. Busque las roturas u otras anormalidades físicas en el cable. Asegúrese de que las configuraciones del cable estén fijadas correctamente. En caso necesario, substituya el cable.

  3. Marque los conectores del cable. Una revocación de las pares de recepción y transmisión o de un par para recepción abierto puede causar los errores. Fije el par para recepción a las líneas 1 y el conjunto 2. la entidad par de transmisión a las líneas 4 y 5.

    Los contactos en un conector RJ-45 se numeran a partir de la 1 con 8. pin 1 son el pin de izquierda al mirar el conector con los contactos de metal que le hacen frente. Refiera a la figura abajo.

    Cuadro 15-10: Cable RJ-45

    /image/gif/paws/14149/h2936.gif

  4. Intento usando un cable transpuesto de consola.

Funcione con el comando show controller t1 exec después de cada paso de marcar si el regulador exhibe cualesquiera errores.

Marque para ver si la línea está en el Loopback Mode de la salida T1 del regulador de la demostración. Una línea debe estar en el Loopback Mode solamente para comprobar.

Para apagar el loopback, utilice el comando no loopback en el modo de configuración de controlador como se muestra abajo:

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

Si el regulador visualiza cualesquiera alarmas:

Marque la salida del comando show controller para ver si hay alarmas visualizadas por el regulador.

Ahora discutiremos las diversas alarmas y el procedimiento necesario corregirlos.

Reciba el Señal de indicación de alarma (AIS) (RX) (azul):

Un Señal de indicación de alarma (AIS) recibido significa que hay una alarma que ocurre en la línea contracorriente desde el equipo conectado con el puerto.

  1. Marque para ver si el formato de marcos configurado en el puerto hace juego el formato de marcos de la línea. Si no, cambie el formato de marcos en el regulador para hacer juego el de la línea.

  2. Entre en contacto su proveedor de servicio para marcar para saber si hay mis configuration dentro de la compañía telefónica.

Reciba la indicación de alarma remota (del rx) (RAI) (amarillo):

Un RAI recibido significa que el equipo en el extremo lejano tiene un problema con la señal que está recibiendo de su equipo de flujo ascendente.

  1. Introduzca un cable externo de loopback en el puerto. Para crear un Loopback Plug refiera a la sección “que crea un Loopback Plug,” más adelante en el capítulo.

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

    1. Inspeccione el cableado Vea la sección “si el receptor T1 tiene pérdida de señal” para 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 Vea la sección “si el receptor T1 tiene pérdida de señal” para más información.

  5. Apague y encienda el router.

  6. Conecte la línea T1 a un puerto diferente. Configure el puerto con las mismas configuraciones que el de la línea. Si no persiste el problema, después las mentiras del incidente con el un puerto:

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

    2. Proceden las “localizaciones de averías a la sección de los eventos de error T1”.

      Si persiste el problema, entonces:

  7. Realice una prueba de Hardware Loopback según lo descrito en la sección el “que realiza prueba del Hardware Loopback Plug.”

  8. Reemplace la tarjeta de controlador T1

  9. Proceden las “localizaciones de averías a la sección de los eventos de error T1”.

Transmisor que envía la alarma remota (roja):

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

  1. Marque para ver si el formato de marcos configurado en el puerto hace juego el formato de marcos de la línea. Si no cambie el formato de marcos en el regulador para hacer juego el de la línea.

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

  3. Entre en contacto su proveedor de servicio.

Indicación de alarma remota de Transmit(Tx) (RAI) (amarillo):

Un RAI transmitido en la interfaz indica que la interfaz tiene un problema con la señal que está recibiendo del equipo en el extremo lejano.

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

  2. Un transmitir RAI se debe acompañar por una cierta otra alarma que indique que la naturaleza del problema que el puerto T1/indicador luminoso LED amarillo de la placa muestra gravedad menor está teniendo con la señal del equipo en el extremo lejano.

Resolver problemas esa condición para resolver el transmitir RAI.

Transmit(Tx) AIS (azul):

Siga los pasos abajo para corregir el transmitir (tx) AIS (azul).

  1. Marque para ver si el formato de marcos configurado en el puerto hace juego el formato de marcos de la línea. Si no, corrija la discordancía.

  2. Apague y encienda el router.

  3. Conecte la línea T1 a un puerto diferente. Configure el puerto con las mismas configuraciones que el de la línea.

  4. Realice una prueba de Hardware Loopback según lo descrito en la sección el “que realiza prueba del Hardware Loopback Plug.”

  5. Reemplace la tarjeta de controlador T1

  6. Proceden las “localizaciones de averías a la sección de los eventos de error T1”.

Localización de averías de los eventos de error T1

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

Para ver si los contadores de errores están aumentando, ejecute el comando show controller t1 en varias ocasiones. Observe los valores de los contadores para el intervalo actual

Consulte su proveedor de servicio para las configuraciones el enmarcar y del linecoding. Una buena regla práctica es utilizar el linecoding B8ZS con Alineación en tramas ESF y la codificación de línea AMI con enmarcar del SF.

El contador de segundos con errores está aumentando:

La presencia de resbalones en una línea T1 indica un problema con EL reloj. El proveedor T1 (compañía telefónica) proporcionará cronometrar a cuál debe ser sincronizado el Customer Premises Equipment (CPE).

  1. Verifique que la fuente de reloj esté derivada de la red. Esto se puede comprobar buscando la fuente de reloj es línea primaria.

    Nota: Si hay T1s múltiple en un Access Server, sólo uno puede ser el primario, mientras que el otro T1s deriva el reloj del primario. En ese caso verifique que la línea T1 señalada como el origen de reloj principal esté configurada correctamente.

  2. Fije la fuente de reloj T1 correctamente del modo de configuración de controlador.

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

Los segundos de pérdida de alineación de trama contrarios están aumentando:

Siga los siguientes pasos cuando los segundos de pérdida de alineación de trama contrarios están aumentando.

  1. Marque para ver si el formato de marcos configurado en el puerto hace juego el formato de marcos de la línea. Usted puede marcar esto buscando el capítulo es {ESF|SF} en la salida T1 del regulador de la demostración.

  2. Para cambiar el formato de marcos utilice enmarcar {SF | Comando ESF} en el modo de configuración de controlador como se muestra abajo:

    maui-nas-03(config-controlle)#framing esf
    
  3. Cambie la línea buildout usando el cablelength {de largo | comando del cortocircuito}.

Consulte su proveedor de servicio y la referencia de comandos de Cisco IOS� para los detalles en las configuraciones del buildout.

Las violaciones del código de línea están aumentando:

Siga los siguientes pasos cuando las violaciones del código de línea están aumentando.

  1. Marque para ver si el linecoding configurado en el puerto hace juego el formato de marcos de la línea. Usted puede marcar esto buscando el Código de línea es {B8ZS|AMI} en la salida T1 del regulador de la demostración.

  2. Para cambiar el linecoding, utilice el linecode {ami | comando b8zs} en el modo de configuración de controlador como se muestra abajo:

    maui-nas-03(config-controlle)#linecode b8zs
    
  3. Cambie la línea buildout usando el cablelength {de largo | comando del cortocircuito}.

Consulte su proveedor de servicio y la referencia de comandos de Cisco IOS� para los detalles en las configuraciones del buildout.

Verificando ese tipo del switch de ISDN y PRI-grupo se configuran correctamente

Utilice el comando show running-config de ver si configuran al tipo del switch de ISDN y el pri-group timeslots correctamente. Entre en contacto su proveedor de servicio para los valores correctos.

Para cambiar el tipo del switch de ISDN y al PRI-grupo:

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 persiste el problema, verifique que el canal de señalización sea ascendente y configurado correctamente.

  1. Funcione con el comando show interface serial x:23, donde x se debe substituir por el Número de interfaz.

  2. Marque para ver si la interfaz está para arriba. 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 el PPP después utilice el comando encapsulation ppp en el modo de configuración de la interfaz de corregirlo.

    maui-nas-03(config-if)#encapsulation ppp
    
  4. Marque para ver si se fija el loopback. 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 persiste el problema, entre en contacto su proveedor de servicio o TAC de Cisco

Localización de averías de un PRI

Siempre que localice averías un PRI, usted necesite marcar para ver si el T1 se está ejecutando limpio en los ambos extremos. Si los problemas del Layer 1 se han resuelto, como se describe anteriormente, considere la capa 2 y la capa 3 problemas.

Troubleshooting usando el comando show isdn status

Utilizan al comando show isdn status de visualizar una foto de todas las interfaces de ISDN. Visualiza el estatus de las capas 1, 2 y 3.

  1. Verifique que el Layer 1 sea activo.

    El estatus del Layer 1 debe decir siempre el ACTIVE a menos que el T1 esté abajo. Si el isdn status de la demostración indica que el Layer 1 ESTÁ DESACTIVADO, después hay un problema con la conectividad física en la línea T1. Vea que la sección “es controlador T1 el T1 abajo?”

    También verifique que el T1 no esté administrativo abajo. Utilice el comando no shutdown de traer controlador T1 para arriba.

  2. Marque para ver si el estado de la capa 2 es MULTIPLE_FRAME_ESTABLISHED

El estado deseado de la capa 2 es Multiple_Frame_Established, que indica que somos tramas de la capa de intercambio 2 y hemos acabado la inicialización de la capa 2.

Si la capa 2 no es Multiple_Frame_Established, utilice el comando show controller t1 exec de diagnosticar el problema. Refiera al troubleshooting usando la sección de comando show controller t1 en este capítulo.

Puesto que el isdn status de la demostración es una foto del estado actual, es posible que la capa 2 está despidiendo hacia arriba y hacia abajo a pesar de la indicación de Mulitple_Frame_Established. Utilice el debug isdn q921 para verificar que la capa 2 es estable.

El comando debug isdn q921 visualiza la capa del link de datos (los procedimientos de acceso de la capa 2) que están ocurriendo en el router en el canal D.

Asegúrese de que le configuren para ver los mensajes del debug usando el comando logging console or terminal monitor cuanto 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 la registración, el Access Server puede congelar intermitentemente para arriba tan pronto como el puerto de la consola consiga sobrecargado con los mensajes del registro. Ingrese el comando no logging console.

Nota: Si se gira el debug isdn q921 y usted no recibe ninguna salidas de los debugs, ponga una llamada o reajuste el regulador para conseguir las salidas de los debugs.

  1. Verifique que la capa 2 sea estable.

    Usted debe observar las salidas de los debugs para los mensajes que indican que el servicio no está despidiendo hacia arriba y hacia abajo. Si usted ve los siguientes tipos de salidas de los debugs, 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 aparece ser estable, vea “localización de averías de los eventos de error T1,” anterior en este capítulo.

  2. Verifique que usted esté viendo que solamente los mensajes SAPI en transmiten (TX) y reciba los lados (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 usted no esté viendo los mensajes SABME, que indica que la capa 2 está intentando reinicializar. Esto se ve generalmente cuando estamos transmitiendo las solicitudes de consulta (RRp) y no estamos consiguiendo una respuesta del Switch (RRf) o viceversa. Abajo está el 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 usted está viendo los mensajes SABME, utilice el comando show running-config de ver si configuran al tipo del switch de ISDN y el pri-group timeslots correctamente. Entre en contacto su proveedor de servicio para los valores correctos.

    Para cambiar el tipo del switch de ISDN y al PRI-grupo:

    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é encima de usar el comando show interfaces serial x:23.

    Si el canal D no está para arriba, después comando no shutdown del uso de sacarlo a colación:

    maui-nas-03(config)#interface serial 0:23
    maui-nas-03(config-if)#no shutdown
    
  5. Marque para ver 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. Marque para ver si la interfaz está en el Loopback Mode. Para el funcionamiento normal, la interfaz no debe estar en el Loopback Mode.

    maui-nas-03(config-if)#no loopback
    
  7. Apague y encienda el router.

  8. Si persiste el problema, entre en contacto su proveedor de servicio o el TAC de Cisco.

Ejecución del prueba del Hardware Loopback Plug

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

Cree un Loopback Plug:

Siga los siguientes pasos para crear un Loopback Plug.

  1. Utilice los cortadores de cable para cortar un cable de trabajo RJ-45 o RJ-48 de modo que haya cinco pulgadas de cable y el conector se asocie a él.

  2. Pele los cables.

  3. Tuerza juntos los alambres de los contactos 1 y 4.

  4. Tuerza juntos los alambres de los contactos 2 y 5.

Los contactos en un conector RJ-45/48 se numeran a partir de la 1 con 8. pin 1 son el pin de izquierda al mirar el conector con los contactos de metal que le hacen frente.

Ejecución de la prueba del Loopback Plug

Siga los siguientes pasos para realizar la prueba del Loopback Plug.

  1. Inserte el plug en el puerto T1 en la pregunta.

  2. Salve su configuración del router usando el comando write memory.

    maui-nas-03#write memory
    Building configuration...
    [OK]
  3. Fije la encapsulación al 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 de ver si la interfaz tiene una dirección IP.

    Si la interfaz no tiene una dirección IP, obtuvo a una dirección única y la asignó 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 Extended PING según lo descrito en la sección Uso de las pruebas de ping extendido anterior en este capítulo.

Localización de averías del e1

Esta sección describe las técnicas y los procedimientos para localizar averías los circuitos del e1 para los clientes de acceso telefónico.

Troubleshooting usando el comando show controller e1

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

El NMP o la MIPS puede preguntar los adaptadores de puerto para determinar su estado actual. Publique un comando show controller e1 de visualizar las estadísticas sobre el link del e1. Si usted especifica un slot y un número del puerto, las estadísticas para cada período minucioso 15 serán visualizadas.

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

La mayoría de los errores del e1 son causados por las líneas mal configuradas. Asegúrese de que el linecoding, el enmarcar, la fuente de reloj y la terminación de línea (equilibrados o desequilibrados) estén configurados según lo que recomienda el proveedor de servicio.

muestre las condiciones del e1 del regulador

Controlador E1 puede estar en uno de los tres estados siguientes.

  • Bajo rendimiento administrativo

  • Down (inactivo)

  • En funcionamiento

¿Es controlador E1 administrativo abajo?

El regulador está administrativo abajo de cuando se ha apagado manualmente. Usted debe recomenzar el regulador para corregir este error.

  1. Ingrese el enable mode.

    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 de controlador.

    maui-nas-03(config)#controller e1 0
    maui-nas-03(config-controlle)#
  4. Recomience el regulador.

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

¿Es la formación?

Si la línea del e1 no está para arriba, marque para ver que la configuración de línea está correcta y hace juego las configuraciones del extremo remoto.

  1. Marque enmarcar de la línea y del extremo remoto. Para las líneas del e1, el enmarcar es CRC4 o noCRC4

  2. Marque el linecoding de la línea y del extremo remoto. El linecoding es AMI o HDB3.

  3. Marque para ver si la terminación de línea se fija para equilibrado o desequilibrado (75-ohm o 120-ohm).

Consulte su proveedor de servicio para más información con respecto a las configuraciones correctas. Realice cualquier cambio cuanto sea necesario a los dispositivos finales locales o remotos.

Si controlador E1 y la línea no está para arriba, marque para ver si uno de los siguientes mensajes aparece en el EXEC del e1 del regulador de la demostración hecho salir:

  • El receptor tiene pérdida de trama

  • El receptor tiene pérdida de señal

Si el receptor del e1 tiene pérdida de trama:

Siga los siguientes pasos si el receptor del e1 tiene pérdida de trama.

  1. Marque para ver si el formato de marcos configurado en el puerto hace juego el formato de marcos de la línea. Usted puede marcar el formato de marcos del regulador de la configuración corriente o de la salida del comando show controller e1.

    Para cambiar el formato de marcos, utilice el {CRC4 que enmarca | ningún comando CRC4} en el modo de configuración de controlador como se muestra abajo:

    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 el otro formato de marcos para ver si la alarma borra.

    Si esto no repara el problema, proceda “si el receptor del e1 tiene a la sección de pérdida de señal” abajo.

  3. Marque el formato de marcos en el extremo remoto.

  4. Marque el linecoding en el extremo remoto.

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

Siga los siguientes pasos si el receptor del e1 tiene pérdida de señal

  1. Aseegurese que el cable entre el puerto de la interfaz y el equipo del proveedor de servicio del e1 (o el equipo de terminal del e1) está conectado correctamente. Marque para ver si el cable se engancha hasta los puertos correctos. Si es necesario, corrija las conexiones de cable.

  2. Marque la integridad del cable. Busque las roturas u otras anormalidades físicas en el cable. Asegúrese de que las configuraciones del cable estén fijadas correctamente. En caso necesario, substituya el cable.

  3. Marque los conectores del cable. Una revocación de las pares de recepción y transmisión o de un par para recepción abierto puede causar los errores. Fije el par para recepción a las líneas 1 y el conjunto 2. la entidad par de transmisión a las líneas 4 y 5.

    Los contactos en un conector RJ-48 se numeran a partir de la 1 con 8. pin 1 son el pin de izquierda al mirar el conector con los contactos de metal que le hacen frente. Refiera a la figura siguiente para más información.

    Cuadro 15-11: Cable RJ-45

    /image/gif/paws/14149/h2936.gif

  4. Intento usando un cable transpuesto de consola.

  5. Marque para ver si hay errores del bloque de extremo lejano. Si es así el problema existe con el lead de la recepción en el extremo local. Entre en contacto TAC para más ayuda.

Funcione con el comando show controller e1 exec después de cada paso de marcar si el regulador exhibe cualesquiera errores.

Si la línea está en el Loopback Mode:

Marque para ver si la línea está en el Loopback Mode de la salida del e1 del regulador de la demostración. Una línea debe estar en el Loopback Mode solamente para comprobar.

Para apagar el loopback, utilice el comando no loopback en el modo de configuración de controlador como se muestra abajo:

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

Si el regulador visualiza cualesquiera alarmas:

Marque la salida del comando show controller para ver si hay alarmas visualizadas por el regulador.

Ahora discutiremos las diversas alarmas y el procedimiento necesario corregirlos.

El receptor (rx) tiene alarma remota:

Una alarma remota recibida significa que hay una alarma que ocurre en la línea contracorriente desde el equipo conectado con el puerto.

  1. Marque para ver si el formato de marcos configurado en el puerto hace juego el formato de marcos de la línea. Si no, cambie el formato de marcos en el regulador para hacer juego el de la línea.

  2. Marque la configuración del linecoding en el equipo del extremo remoto. Entre en contacto su proveedor de servicio para las configuraciones correctas. Corrija cualquier misconfigurations cuanto sea necesario.

  3. Introduzca un cable externo de loopback en el puerto. Para crear un Loopback Plug, vea la sección el “realizar del prueba del Hardware Loopback Plug,” anterior en el capítulo.

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

    1. Inspeccione el cableado Refiera a la sección “si el receptor del e1 tiene pérdida de señal” para 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. Quite el Loopback Plug y vuelva a conectar su línea del e1.

  6. Inspeccione el cableado Vea la sección “si el receptor del e1 tiene pérdida de señal” para más información.

  7. Apague y encienda el router.

  8. Conecte la línea del e1 con un diverso puerto. Configure el puerto con las mismas configuraciones que el de la línea. Si no persiste el problema, después las mentiras del incidente con el un puerto:

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

    2. Proceda “a la sección de los eventos de error del e1 del troubleshooting”.

      Si persiste el problema, entonces:

  9. Realice una prueba de Hardware Loopback según lo descrito en la sección el “que realiza prueba del Hardware Loopback Plug”

  10. Substituya controlador E1 el indicador luminoso LED amarillo de la placa muestra gravedad menor.

  11. Proceda “a la sección de los eventos de error del e1 del troubleshooting”.

Transmisor que envía la alarma remota (roja):

Se declara una alarma roja cuando el CSU no puede sincronizar con el patrón de alineación de tramas en la línea del e1.

  1. Marque para ver si el formato de marcos configurado en el puerto hace juego el formato de marcos de la línea. Si no cambie el formato de marcos en el regulador para hacer juego 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 Loopback Plug, vea la sección el “realizar del prueba del Hardware Loopback Plug,” anterior en el capítulo.

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

    1. Inspeccione el cableado Refiera a la sección “si el receptor del e1 tiene pérdida de señal” para más información.

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

  5. Conecte la línea del e1 con un diverso puerto. Configure el puerto con las mismas configuraciones que el de la línea. Si no persiste el problema, después el incidente miente con el un puerto.

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

    2. Proceda “a la sección de los eventos de error del e1 del troubleshooting”.

      Si persiste el problema, entonces:

  6. Realice una prueba de Hardware Loopback según lo descrito en la sección el “que realiza prueba del Hardware Loopback Plug.”

  7. Substituya controlador E1 el indicador luminoso LED amarillo de la placa muestra gravedad menor.

  8. Proceda “a la sección de los eventos de error del e1 del troubleshooting”.

  9. Entre en contacto su proveedor de servicio.

Localización de averías de los eventos de error del e1

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

Para ver si los contadores de errores están aumentando, ejecute el comando show controller e1 en varias ocasiones. Observe los valores de los contadores para el intervalo actual Consulte su proveedor de servicio para las configuraciones el enmarcar y del linecoding.

El contador de segundos con errores está aumentando:

La presencia de resbalones en las líneas del e1 indica un problema con EL reloj. El proveedor del e1 (compañía telefónica) proporcionará cronometrar a cuál debe ser sincronizado el Customer Premises Equipment (CPE).

  1. Verifique que la fuente de reloj esté derivada de la red. Esto se puede comprobar buscando la fuente de reloj es línea primaria.

    Nota: Si hay E1s múltiples en un Access Server, sólo uno puede ser el primario, mientras que los otros E1s derivan el reloj del primario. En ese caso, verifique que la línea del e1 señalada como el origen de reloj principal esté configurada correctamente.

  2. Fije la fuente de reloj del e1 correctamente del modo de configuración de controlador.

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

Los segundos de pérdida de alineación de trama contrarios están aumentando:

Siga los siguientes pasos cuando los segundos de pérdida de alineación de trama contrarios están aumentando:

  1. Marque para ver si el formato de marcos configurado en el puerto hace juego el formato de marcos de la línea. Usted puede marcar esto buscando el capítulo es {CRC4|no CRC4} en la salida del e1 del regulador de la demostración.

  2. Para cambiar el formato de marcos utilice enmarcar {CRC4 | ningún comando CRC4} en el modo de configuración de controlador como se muestra abajo:

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

Las violaciones del código de línea están aumentando:

Siga los siguientes pasos cuando las violaciones del código de línea están aumentando.

  1. Marque para ver si el linecoding configurado en el puerto hace juego el formato de marcos de la línea. Usted puede marcar esto buscando el Código de línea es {AMI/HDB3} en la salida del e1 del regulador de la demostración.

  2. Para cambiar el linecoding, utilice el linecode {ami | comando hdb3} en el modo de configuración de controlador como se muestra abajo:

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

Verificando ese tipo del switch de ISDN y PRI-grupo se configuran correctamente

Utilice el comando show running-config de marcar si configuran al tipo del switch de ISDN y el pri-group timeslots correctamente. Entre en contacto su proveedor de servicio para los valores correctos.

Para cambiar el tipo del switch de ISDN y al PRI-grupo:

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 persiste el problema, verifique que el canal de señalización sea ascendente y configurado correctamente.

  1. Funcione con el comando show interface serial x:15, donde x se debe substituir por el Número de interfaz.

  2. Marque para ver si la interfaz está para arriba. 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 el PPP, después utilice el comando encapsulation ppp en el modo de configuración de la interfaz de corregirlo.

    maui-nas-03(config-if)#encapsulation ppp
    
  4. Marque para ver si se fija el loopback. 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 persiste el problema, entre en contacto su proveedor de servicio o el TAC de Cisco.

Localización de averías de un PRI

Al localizar averías un PRI, usted necesita determinar si el e1 se está ejecutando limpio en los ambos extremos. Si los problemas del Layer 1 se han resuelto como se describe anteriormente, considere la capa 2 y la capa 3 problemas.

Troubleshooting usando el comando show isdn status

Utilizan al comando show isdn status de visualizar una foto de todas las interfaces de ISDN. Visualiza el estatus de las capas 1, 2 y 3.

  1. Verifique que el Layer 1 sea activo.

    El estatus del Layer 1 debe decir siempre el ACTIVE a menos que el e1 esté abajo.

    Si el isdn status de la demostración indica que el Layer 1 ESTÁ DESACTIVADO, después hay un problema con la conectividad física en la línea del e1. Vea que la sección “es controlador E1 administrativo abajo?”

    También verifique que el e1 no esté administrativo abajo. Utilice el comando no shutdown de traer controlador E1 para arriba.

  2. Marque para ver si el estado de la capa 2 es MULTIPLE_FRAME_ESTABLISHED.

El estado deseado de la capa 2 es Multiple_Frame_Established, que indica que el protocolo de inicio entre el switch ISDN y el dispositivo final se ha establecido y somos tramas de la capa de intercambio 2.

Si la capa 2 no es Multiple_Frame_Established, utilice el comando show controller e1 exec de diagnosticar el problema. Vea “troubleshooting usando la sección del comando show controller e1” en este capítulo y “la sección de los eventos de error del e1 del troubleshooting”.

Porque el isdn status de la demostración es una foto del estado actual, es posible que la capa 2 está despidiendo hacia arriba y hacia abajo a pesar de la indicación de Mulitple_Frame_Established. Utilice el comando debug isdn q921 para verificar que la capa 2 esté estable.

Usando el debug q921

El comando debug isdn q921 visualiza la capa del link de datos (los procedimientos de acceso de la capa 2) que están ocurriendo en el router en el canal D.

Asegúrese de que le configuren para ver los mensajes del debug usando el comando logging console or terminal monitor cuanto 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 la registración, el Access Server puede congelar intermitentemente para arriba tan pronto como el puerto de la consola consiga sobrecargado con los mensajes del registro. Ingrese el comando no logging console.

Nota: Si se gira el debug isdn q921 y usted no recibe ninguna salidas de los debugs, ponga una llamada o reajuste el regulador para conseguir las salidas de los debugs.

  1. Verifique que la capa 2 sea estable. Usted debe observar las salidas de los debugs para los mensajes que indican que el servicio no está despidiendo hacia arriba y hacia abajo. Si usted ve los siguientes tipos de salidas de los debugs, 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 aparece ser estable, vea “los eventos de error del e1 del troubleshooting,” anterior en este capítulo.

  2. Verifique que usted esté viendo que solamente los mensajes SAPI en transmiten (TX) y reciba los lados (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 usted no esté viendo los mensajes SABME, que indica que la capa 2 está intentando reinicializar. Esto se ve generalmente cuando estamos transmitiendo las solicitudes de consulta (RRp) y no estamos consiguiendo una respuesta del Switch (RRf) o viceversa. Abajo está el ejemplo de mensajes SABME. Debemos conseguir 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 usted está viendo los mensajes SABME, utilice el comando show running-config de marcar si configuran al tipo del switch de ISDN y el pri-group timeslots correctamente. Entre en contacto su proveedor de servicio para los valores correctos.

    Para cambiar el tipo del switch de ISDN y al PRI-grupo:

    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é encima de usar el comando show interfaces serial x:15.

    Si el canal D no está para arriba, después utilice el comando no shutdown de sacarlo a colación:

    maui-nas-03(config)#interface serial 0:15
    maui-nas-03(config-if)#no shutdown
    
  5. Marque para ver si la encapsulación es PPP. Si no utilice el comando encapsulation ppp de fijar la encapsulación.

    maui-nas-03(config-if)#encapsulation ppp
    
  6. Marque para ver si la interfaz está en el Loopback Mode. Para el funcionamiento normal, la interfaz no debe estar en el Loopback Mode.

    maui-nas-03(config-if)#no loopback
    
  7. Apague y encienda el router.

  8. Si persiste el problema, entre en contacto su proveedor de servicio o el TAC de Cisco.

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Información Relacionada


Document ID: 14149