¿Tiene una cuenta?
El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Un problema común en las redes VoIP con una conexión de interfaz digital a un proveedor de telecomunicaciones (telco) es que el circuito ISDN o de señalización asociada al canal (CAS) no se activa o permanece activo. Esos problemas pueden ser complejos porque:
¿Cómo se puede avanzar de manera eficiente y eficaz en la cuestión? Este documento describe un método de solución de problemas importante y útil, conocido como prueba de loopback, y cubre varias técnicas de prueba de loopback.
Notas:
Utilice la Command Lookup Tool (sólo clientes registrados) para obtener más información sobre los comandos utilizados en este documento.
La herramienta de interpretación de información de salida (disponible para clientes registrados únicamente) admite ciertos comandos show. Utilice la herramienta para ver una análisis de información de salida del comando show.
Consulte Información Importante sobre Comandos de Debug antes de usar un comando debug.
Las pruebas de loopback son una forma muy eficaz de aislar un T1 (o E1) que falla. La idea básica detrás de las pruebas de loopback es:
Los componentes que debe intentar eliminar, ya que son problemáticos, incluyen el VWIC (tarjeta y puerto) y la ejecución del cable (hasta SmartJack).
A menudo se hace referencia a SmartJack o participa en las llamadas del TAC en los problemas de T1/E1. Un SmartJack es un tipo de dispositivo de interfaz de red (NID) que termina el PRI/T1 desde el gateway de Cisco y que también proporciona algunas capacidades de diagnóstico.
Una capacidad muy común proporcionada por SmartJack es el loopback, donde la señal de la compañía telefónica se transmite de vuelta a la compañía telefónica.
Las empresas de telecomunicaciones consideran todo lo relacionado con el interior del SmartJack como el loop local y consideran que todos los equipos de loop locales son responsabilidad del cliente. Esta figura ilustra un SmartJack.
Esta figura proporciona una descripción general de las pruebas de loopback.
Este documento describe tres tipos de pruebas de loopback:
Consulte Pruebas de Loopback para las Líneas T1/56K para ver descripciones detalladas de las pruebas de loopback. Puede ignorar de forma segura las referencias a las CSU y a las unidades de servicio de datos (DSU) en este documento. En los gateways de voz de Cisco, las CSU y las DSU forman parte integral de los VWIC en los gateways habilitados para voz de Cisco.
Nota: El loopback de software es intrusivo y afectará al servicio.
Las pruebas de loopback de software se realizan con un conjunto de comandos de configuración del software Cisco IOS® en el gateway de Cisco. Los comandos hacen que el controlador de la tarjeta de interfaz WAN (WIC) envíe automáticamente el tráfico hacia el puerto T1/E1 de envío.
El loopback de software no requiere ningún cambio de hardware o reconfiguración, como se muestra en esta figura.
Este procedimiento describe cómo probar un loopback de software:
Este es un ejemplo de la configuración del grupo de canales en el controlador:
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#controller t1 0/0/0
Router(config-controller)#no pri-group timeslots 1-24
Router(config-controller)#channel-group 0 timeslots 1-24 speed 64
!--- This automatically creates a single Serial0:0 interface.
Router(config-controller)#loopback local
!--- The loopback local command above is only necessary for software loopbacks.
Router(config-controller)#exitRouter(config)#interface serial 0/0/0:0
Router(config-if)#encapsulation hdlc
!--- Note: All loopback testing is done with hdlc encapsulation.
Nota: Las pruebas de loopback de hardware son intrusivas y afectarán al servicio.
En un loopback duro, se utiliza un conector de loopback especial para volver a enviar el tráfico del puerto T1 al puerto T1. Esta figura ilustra la configuración para el loopback duro.
Hay dos enfoques para probar un loopback duro:
El primer enfoque, la prueba como circuito ISDN, ofrece un alcance limitado para las pruebas y la verificación.
La Capa 1 de ISDN se puede probar. Si VWIC funciona correctamente, el comando show controller t1 produce un resultado similar al que se muestra en este ejemplo:
T1 0/0/0 is up.
Applique type is Channelized T1
Cablelength is long 0db
No alarms detected.
alarm-trigger is not set
Soaking time: 3, Clearance time: 10
AIS State:Clear LOS State:Clear LOF State:Clear
Version info Firmware: 20100222, FPGA: 13, spm_count = 0
Framing is ESF, Line Code is B8ZS, Clock Source is Line.
CRC Threshold is 320. Reported from firmware is 320.
Data in current interval (24 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
La Capa 2 de ISDN se puede probar parcialmente. Si bien puede verificar que los mensajes Set Asynchronous Balancing Mode (SABME) fluyen a través de la interfaz, los otros mensajes Q.921 habituales, como RR, RRf y RRp, no se ven. En su lugar, verá este tipo de salida:
004800: *Aug 12 16:17:01.319: ISDN Se0/0/0:23 Q921: L2_EstablishDataLink:
sending SABME
004801: *Aug 12 16:17:01.319: ISDN Se0/0/0:23 Q921: User TX ->
SABMEp sapi=0 tei=0
004802: *Aug 12 16:17:01.323: ISDN Se0/0/0:23 Q921: User RX <-
BAD FRAME(0x00017F)
004803: *Aug 12 16:17:02.319: ISDN Se0/0/0:23 Q921: User TX ->
SABMEp sapi=0 tei=0
Esto se espera. Para que la interfaz ISDN funcione, un lado debe configurarse como una red de protocolo y el otro como usuario de protocolo. Sin embargo, esto no es posible ya que sólo hay una interfaz con el loopback. En consecuencia, verá que el estado de ISDN oscila entre AWAITING_ESTABLISHMENT y TEI_ASSIGNED.
ISDN Serial0/0/0:23 interface
dsl 0, interface ISDN Switchtype = primary-4ess
Layer 1 Status:
ACTIVE
Layer 2 Status:
TEI = 0, Ces = 1, SAPI = 0, State = AWAITING_ESTABLISHMENT
Layer 3 Status:
0 Active Layer 3 Call(s)
Active dsl 0 CCBs = 0
The Free Channel Mask: 0x807FFFFF
Number of L2 Discards = 0, L2 Session ID = 5
La Capa 3 de ISDN nunca aparece.
Otra limitación de este enfoque es que no funciona si T1 se configura como un T1 CAS.
Sin embargo, una ventaja de este enfoque es que no se requiere ningún cambio de configuración en el software Cisco IOS. El único procedimiento es:
Utilice el comando show controller t1 para verificar que el controlador T1 se activa y use el comando debug isdn q9 21 para verificar el flujo de mensajes Q.921. Por supuesto, la Capa 3 de ISDN no es posible.
El otro enfoque, la prueba como interfaz IP, también se conoce como "prueba como T1 de datos". Este enfoque le permite realizar pruebas de ping ICMP, lo que parece mejor porque puede verificar que el VWIC (tarjeta y puerto) es bueno hasta la Capa 3. Sin embargo, tenga en cuenta que la capa 3 es la capa 3 de interconexión de sistema abierto (OSI), no la capa 3 de ISDN.
Consejo: Este método es versátil porque funciona independientemente de si el T1 se utiliza como interfaz ISDN o como interfaz T1 CAS.
Este procedimiento describe cómo probar como una interfaz IP:
Vea el procedimiento para crear un conector de loopback para una CSU/DSU T1 en Pruebas de Loopback para Líneas T1/56K.
Esta es una imagen de un conector de loopback T1/E1:
Este es un ejemplo de la configuración del grupo de canales en el controlador:
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#controller t1 0/0/0
Router(config-controller)#no pri-group timeslots 1-24
Router(config-controller)#channel-group 0 timeslots 1-24 speed 64
!--- This automatically creates a single Serial0/0/0:0 interface.
Router(config-controller)#exit
Router(config)#interface serial 0/0/0:0
Router(config-if)#encapsulation hdlc
!--- Note: All loopback testing is done with hdlc encapsulation.
El comando show controller produce resultados similares a estos:
T1 0/0/0 is up.
Applique type is Channelized T1
Cablelength is long 0db
No alarms detected.
alarm-trigger is not set
Soaking time: 3, Clearance time: 10
AIS State:Clear LOS State:Clear LOF State:Clear
Version info Firmware: 20100222, FPGA: 13, spm_count = 0
Framing is ESF, Line Code is B8ZS, Clock Source is Line.
CRC Threshold is 320. Reported from firmware is 320.
Data in current interval (2 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
La prueba de loopback para verificar la interfaz en el nivel de Capa 3 de ISDN no es posible porque la Capa 2 de ISDN no se activa en una configuración de loopback. Por lo tanto, sólo es posible probar como una interfaz IP. Una vez que se hayan completado los pasos de configuración, realice pings ICMP:
Router(config-if)#ip address 172.53.11.1 255.255.0.0
Router(config-if)#ping 172.53.11.1
Verifique los contadores de la interfaz para verificar que el conteo de los incrementos de 'entrada de paquetes' y 'salida de paquetes'. Este es un ejemplo de salida del comando show interfaces serial slot/port:
Router#sho int ser 0/0/0:0
Serial0/0/0:0 is up, line protocol is up
Hardware is GT96K Serial
Internet address is 172.53.11.1/16
MTU 1500 bytes, BW 1536 Kbit/sec, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation HDLC, loopback not set
Keepalive set (10 sec)
Last input 00:00:04, output 00:00:04, output hang never
Last clearing of "show interface" counters 00:47:05
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/1/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 1152 kilobits/sec
5 minute input rate 1000 bits/sec, 1 packets/sec
5 minute output rate 1000 bits/sec, 1 packets/sec
20 packets input, 2723 bytes, 0 no buffer
Received 4 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
20 packets output, 2723 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 output buffer failures, 0 output buffers swapped out
1 carrier transitions
Timeslot(s) Used:1-24, SCC: 0, Transmitter delay is 0 flags
Nota: Realice un ping extendido para probar posibles condiciones inestables.
Una vez que determine que el VWIC funciona correctamente, utilice este procedimiento para probar y eliminar la ejecución del cable (a la demarcación de la compañía telefónica) como la fuente de los problemas:
Si los pings ICMP son exitosos, la prueba es exitosa, lo que indica que el cable está bien. Si hay cortes u otros daños en la ejecución del cable, verá que el controlador T1 permanece inactivo, debido a la pérdida de señal (LOS):
Router#show controller t1
T1 0/0/0 is down.
Applique type is Channelized T1
Cablelength is long 0db
Transmitter is sending remote alarm.
Receiver has loss of signal.
alarm-trigger is not set
Soaking time: 3, Clearance time: 10
AIS State:Clear LOS State:Failure LOF State:Failure
Version info Firmware: 20100222, FPGA: 13, spm_count = 0
Framing is ESF, Line Code is B8ZS, Clock Source is Line.
CRC Threshold is 320. Reported from firmware is 320.
Data in current interval (395 seconds elapsed):
25 Line Code Violations, 1 Path Code Violations
0 Slip Secs, 0 Fr Loss Secs, 1 Line Err Secs, 0 Degraded Mins
1 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 34 Unavail Secs
Total Data (last 24 hours)
25 Line Code Violations, 1 Path Code Violations,
14 Slip Secs, 0 Fr Loss Secs, 3 Line Err Secs, 1 Degraded Mins,
15 Errored Secs, 0 Bursty Err Secs, 2 Severely Err Secs, 349 Unavail Secs
Nota: Las violaciones de línea y de código de ruta que no son de cero no indican necesariamente problemas con el cable. Cuando mueve el conector de loopback del puerto VWIC al final de la ejecución del cable, se activan las violaciones del código de la línea y de la ruta. Después de mover el conector de loopback, puede aclarar esto si primero borra los contadores del controlador con el comando clear controller t1 0/0/0, luego vea si aumentan las violaciones del código de la línea y de la trayectoria.
Utilice el procedimiento descrito en Interfaz IP.
No hay diferencia entre las pruebas de loopback para T1 o E1.
Nota: Las pruebas de loopback asistidas por la compañía telefónica pueden afectar al servicio.
La compañía telefónica (también conocida como portadora, compañía telefónica, proveedor de telecomunicaciones o proveedor de servicios) es el proveedor del servicio de circuito T1/E1.
Si no puede realizar las pruebas de loopback de hardware y software o si las pruebas de loopback de hardware y software revelan que el gateway de Cisco y el cable de ejecución (a la demarcación de la compañía telefónica) funcionan correctamente, el loopback asistido por la compañía telefónica podría ser una opción.
Hay dos posibilidades:
Esta es una cifra de las dos posibilidades de loopbacks asistidos por la compañía telefónica: