Monitoreo y solución de problemas

Propósito

Muestra estadísticas en tiempo real sobre el tráfico que pasa por todas las interfaces del enrutador o conmutador.

Acción

Para mostrar estadísticas en tiempo real sobre el tráfico que pasa por todas las interfaces del enrutador o conmutador:

Significado

La salida de ejemplo muestra datos de tráfico para interfaces activas y la cantidad que cada campo ha cambiado desde que se inició el comando o desde que se borraron los contadores con la C clave. En este ejemplo, el monitor interface comando se ha estado ejecutando durante 15 segundos desde que se emitió el comando o desde la última vez que los contadores volvieron a cero.

Propósito

Muestra estadísticas en tiempo real sobre el tráfico que pasa a través de una interfaz en el enrutador o conmutador.

Acción

Para mostrar el tráfico que pasa a través de una interfaz en el enrutador o conmutador, utilice el siguiente comando del modo operativo de la CLI de Junos OS:

Significado

La salida de ejemplo muestra los paquetes de entrada y salida para una interfaz SONET determinada (so-0/0/1). La información puede incluir errores comunes de interfaz, como alarmas SONET/SDH y T3, loopbacks detectados y aumentos en los errores de trama. Para obtener más información, consulte Lista de comprobación para el seguimiento de condiciones de error.

Para controlar el resultado del comando mientras se está ejecutando, utilice las teclas que se muestran en Tabla 1.

Consulte el Explorador de CLI para obtener más información sobre el uso de condiciones de coincidencia con el monitor traffic comando.

Problema

Solución

Puede aplicar una asignación de programador al paquete multivínculo y a sus vínculos constituyentes. Aunque puede aplicar varios componentes de CoS con la asignación del programador, configure solo los que sean necesarios. Le recomendamos que mantenga la configuración de los enlaces constituyentes simple para evitar retrasos innecesarios en la transmisión.

Tabla 5 muestra los componentes de CoS que se aplicarán en un paquete multivínculo y sus vínculos constituyentes.

Problema

Solución

Para reducir la fluctuación y la latencia, haga lo siguiente:

1. Asegúrese de que ha configurado una velocidad de conformación en cada enlace constituyente.

2. Asegúrese de que no ha configurado una velocidad de conformación en la interfaz de servicios de vínculo.

3. Asegúrese de que el valor de la velocidad de conformación configurada sea igual al ancho de banda de la interfaz física.

4. Si las velocidades de conformación están configuradas correctamente y la fluctuación persiste, comuníquese con el Centro de asistencia técnica de Juniper Networks (JTAC).

Problema

Solución

Cuando LFI está habilitado, los paquetes de datos (no LFI) se encapsulan con un encabezado MLPPP y se fragmentan en paquetes de un tamaño especificado. Los paquetes de voz sensibles al retardo (LFI) están encapsulados en PPP e intercalados entre fragmentos de paquetes de datos. Las colas y el equilibrio de carga se realizan de manera diferente para los paquetes LFI y no LFI.

Para comprobar que LFI se realiza correctamente, determine que los paquetes estén fragmentados y encapsulados según lo configurado. Después de saber si un paquete se trata como un paquete LFI o un paquete que no es LFI, puede confirmar si el equilibrio de carga se realiza correctamente.

Solution Scenario: supongamos que dos dispositivos de Juniper Networks, R0 y R1, están conectados por un paquete lsq-0/0/0.0 multivínculo que agrega dos vínculos se-1/0/0 serie y se-1/0/1. En R0 y R1, MLPPP y LFI se habilitan en la interfaz de servicios de vínculo y el umbral de fragmentación se establece en 128 bytes.

En este ejemplo, usamos un generador de paquetes para generar flujos de voz y datos. Puede utilizar la función de captura de paquetes para capturar y analizar los paquetes en la interfaz entrante.

Los dos flujos de datos siguientes se enviaron en el paquete multivínculo:

• 100 paquetes de datos de 200 bytes (mayores que el umbral de fragmentación)

• 500 paquetes de datos de 60 bytes (más pequeños que el umbral de fragmentación)

Las dos secuencias de voz siguientes se enviaron en el paquete multivínculo:

• 100 paquetes de voz de 200 bytes desde el puerto fuente 100

• 300 paquetes de voz de 200 bytes desde el puerto fuente 200

Para confirmar que la LFI y el equilibrio de carga se realizan correctamente:

1. Compruebe la fragmentación de paquetes. Desde el modo operativo, escriba el show interfaces lsq-0/0/0 comando para comprobar que los paquetes grandes están fragmentados correctamente.

   Meaning: el resultado muestra un resumen de los paquetes que transitan por el dispositivo en el paquete multivínculo. Compruebe la siguiente información en el paquete multivínculo:

   • El número total de paquetes en tránsito = 1000

   • El número total de fragmentos en tránsito=1100

   • El número de paquetes de datos fragmentados =100

   El número total de paquetes enviados (600 + 400) en el paquete multivínculo coincide con el número de paquetes en tránsito (1000), lo que indica que no se descartó ningún paquete.

   El número de fragmentos en tránsito supera en 100 el número de paquetes en tránsito, lo que indica que 100 paquetes de datos grandes se fragmentaron correctamente.

   Corrective Action: si los paquetes no están fragmentados correctamente, compruebe la configuración del umbral de fragmentación. Los paquetes menores que el umbral de fragmentación especificado no se fragmentan.

2. Verifique la encapsulación del paquete. Para averiguar si un paquete se trata como un paquete LFI o no LFI, determine su tipo de encapsulación. Los paquetes LFI están encapsulados PPP y los paquetes que no son LFI se encapsulan con PPP y MLPPP. Las encapsulaciones PPP y MLPPP tienen diferentes sobrecargas, lo que resulta en paquetes de diferentes tamaños. Puede comparar tamaños de paquetes para determinar el tipo de encapsulación.

   Un pequeño paquete de datos no fragmentado contiene un encabezado PPP y un solo encabezado MLPPP. En un paquete de datos fragmentado de gran tamaño, el primer fragmento contiene un encabezado PPP y un encabezado MLPPP, pero los fragmentos consecutivos contienen solo un encabezado MLPPP.

   Las encapsulaciones PPP y MLPPP agregan el siguiente número de bytes a un paquete:

   • La encapsulación PPP agrega 7 bytes:

     4 bytes de encabezado + 2 bytes de secuencia de comprobación de tramas (FCS) + 1 byte que está inactivo o contiene una marca

   • La encapsulación MLPPP agrega entre 6 y 8 bytes:

     4 bytes de encabezado PPP+2 a 4 bytes de encabezado multivínculo

   Figura 1 muestra la sobrecarga agregada a los encabezados PPP y MLPPP.

   Figura 1: Encabezados PPP y MLPPP

   Para los paquetes CRTP, la sobrecarga de encapsulación y el tamaño del paquete son incluso menores que para un paquete LFI. Para obtener más información, consulte Ejemplo: Configuración del protocolo de transporte comprimido en tiempo real.

   Tabla 6 muestra la sobrecarga de encapsulación de un paquete de datos y un paquete de voz de 70 bytes cada uno. Después de la encapsulación, el tamaño del paquete de datos es mayor que el tamaño del paquete de voz.

   Tabla 6: Sobrecarga de encapsulación PPP y MLPPP

   Tipo de paquete	Encapsulación	Tamaño inicial del paquete	Sobrecarga de encapsulación	Tamaño del paquete después de la encapsulación
   Paquete de voz (LFI)	PPP	70 bytes	4 + 2 + 1 = 7 bytes	77 bytes
   Fragmento de datos (no LFI) con secuencia corta	MLPPP	70 bytes	4 + 2 + 1 + 4 + 2 = 13 bytes	83 bytes
   Fragmento de datos (no LFI) con secuencia larga	MLPPP	70 bytes	4 + 2 + 1 + 4 + 4 = 15 bytes	85 bytes

   Desde el modo operativo, escriba el show interfaces queue comando para mostrar el tamaño del paquete transmitido en cada cola. Divida el número de bytes transmitidos por el número de paquetes para obtener el tamaño de los paquetes y determinar el tipo de encapsulación.

3. Verifique el equilibrio de carga. Desde el modo operativo, introduzca el show interfaces queue comando en el paquete multivínculo y sus enlaces constituyentes para confirmar si el equilibrio de carga se realiza en consecuencia en los paquetes.

   Meaning: el resultado de estos comandos muestra los paquetes transmitidos y en cola en cada cola de la interfaz de servicios de vínculo y sus vínculos constituyentes. Tabla 7 muestra un resumen de estos valores. (Dado que el número de paquetes transmitidos es igual al número de paquetes en cola en todos los vínculos, esta tabla muestra sólo los paquetes en cola).

   Tabla 7: Número de paquetes transmitidos en una cola

   Paquetes en cola	Paquete lsq-0/0/0.0	Enlace constituyente se-1/0/0	Enlace constituyente se-1/0/1	Explicación
   Paquetes en Q0	600	350	350	El número total de paquetes que transitan por los vínculos constituyentes (350+350 = 700) superó el número de paquetes en cola (600) en el paquete multivínculo.
   Paquetes en Q2	400	100	300	El número total de paquetes que transitan por los vínculos constituyentes es igual al número de paquetes del paquete.
   Paquetes en Q3	0	19	18	Los paquetes que transitan Q3 de los enlaces constituyentes son para mensajes keepalive intercambiados entre enlaces constituyentes. Por lo tanto, no se contaron paquetes en Q3 del paquete.

   En el paquete multivínculo, compruebe lo siguiente:

   • El número de paquetes en cola coincide con el número transmitido. Si los números coinciden, no se descartó ningún paquete. Si se ponían en cola más paquetes de los que se transmitían, los paquetes se descartaban porque el búfer era demasiado pequeño. El tamaño del búfer en los vínculos constituyentes controla la congestión en la etapa de salida. Para corregir este problema, aumente el tamaño del búfer en los vínculos constituyentes.

   • El número de paquetes que transitan Q0 (600) coincide con el número de paquetes de datos grandes y pequeños recibidos (100+500) en el paquete multivínculo. Si los números coinciden, todos los paquetes de datos transitaron correctamente Q0.

   • El número de paquetes que transitan Q2 en el paquete multivínculo (400) coincide con el número de paquetes de voz recibidos en el paquete multivínculo. Si los números coinciden, todos los paquetes LFI de voz transitaron correctamente Q2.

   En los vínculos constituyentes, compruebe lo siguiente:

   • El número total de paquetes que transitan Q0 (350+350) coincide con el número de paquetes de datos y fragmentos de datos (500+200). Si los números coinciden, todos los paquetes de datos después de la fragmentación transitaron correctamente Q0 de los enlaces constituyentes.

     Los paquetes transitaron por ambos enlaces constituyentes, lo que indica que el equilibrio de carga se realizó correctamente en paquetes que no eran LFI.

   • El número total de paquetes que transitan Q2 (300+100) en los enlaces constituyentes coincide con el número de paquetes de voz recibidos (400) en el paquete multivínculo. Si los números coinciden, todos los paquetes LFI de voz transitaron correctamente Q2.

     Paquetes LFI desde el puerto 100 de origen transitados se-1/0/0y paquetes LFI desde el puerto 200 de origen transitados se-1/0/1. Por lo tanto, todos los paquetes LFI (Q2) se cifraron en función del puerto de origen y transitaron correctamente ambos enlaces constituyentes.

   Corrective Action: si los paquetes transitaron solo un vínculo, siga estos pasos para resolver el problema:

   1. Determine si el vínculo físico está up (operativo) o down (no disponible). Un vínculo no disponible indica un problema con el PIM, el puerto de interfaz o la conexión física (errores de capa de enlace). Si el vínculo está operativo, vaya al paso siguiente.

   2. Compruebe que los clasificadores estén definidos correctamente para los paquetes que no son LFI. Asegúrese de que los paquetes que no sean LFI no estén configurados para ponerse en cola en Q2. Todos los paquetes en cola para Q2 se tratan como paquetes LFI.

   3. Compruebe que al menos uno de los siguientes valores es diferente en los paquetes LFI: dirección de origen, dirección de destino, protocolo IP, puerto de origen o puerto de destino. Si se configuran los mismos valores para todos los paquetes LFI, todos los paquetes se cifran al mismo flujo y transitan por el mismo vínculo.

4. Utilice los resultados para verificar el equilibrio de carga.

Problema

Solución

Si el dispositivo de terceros no tiene la misma compatibilidad con FRF.12 que el dispositivo de Juniper Networks o admite FRF.12 de otra manera, la interfaz del dispositivo de Juniper Networks en el PVC podría descartar un paquete fragmentado que contenga encabezados FRF.12 y contarlo como un "descarte vigilado".

Como solución alternativa, configure paquetes multivínculo en ambos pares y configure umbrales de fragmentación en los paquetes multivínculo.

Problema

• Description
• Entorno
• Síntomas

Solución

Use el show security policies checksum comando para mostrar el valor de suma de comprobación de la directiva de seguridad y use el request security policies resync comando para sincronizar la configuración de las directivas de seguridad en el motor de enrutamiento y el motor de reenvío de paquetes, si las directivas de seguridad no están sincronizadas.

Problema

Solución

Para corregir estos errores, haga lo siguiente:

1. Revise los datos de configuración.

2. Abra el archivo /var/log/nsd_chk_only. Este archivo se sobrescribe cada vez que se realiza una comprobación de confirmación y contiene información detallada sobre el error.

Problema

Solución

1. Comandos operativos show : ejecute los comandos operativos para las políticas de seguridad y compruebe que la información que se muestra en el resultado es coherente con lo que esperaba. De lo contrario, la configuración debe cambiarse adecuadamente.

2. Traceoptions: defina el comando en la configuración de traceoptions la política. Los indicadores bajo esta jerarquía se pueden seleccionar según el análisis del usuario de la salida del show comando. Si no puede determinar qué indicador usar, la opción all de indicador se puede usar para capturar todos los registros de seguimiento.

También puede configurar un nombre de archivo opcional para capturar los registros.

Si especificó un nombre de archivo en las opciones de seguimiento, puede buscar el archivo de registro en /var/log/<filename> para determinar si se ha notificado algún error en el archivo. (Si no especificó un nombre de archivo, el nombre de archivo predeterminado es eventual). Los mensajes de error indican el lugar del error y la razón apropiada.

Después de configurar las opciones de seguimiento, debe volver a confirmar el cambio de configuración que provocó el comportamiento incorrecto del sistema.

Problema

Solución

Problema

Solución

Utilice los mensajes de error para comprender los problemas relacionados con el chasisd.

Cuando se inicia ISSU, se envía una solicitud al chasis para comprobar si hay algún problema relacionado con el ISSU desde la perspectiva del chasis. Si hay un problema, se crea un mensaje de registro.

Problema

Solución

Cualquier error encontrado durante una ISSU da como resultado la creación de mensajes de registro e ISSU sigue funcionando sin afectar al tráfico. Si es necesario revertir a versiones anteriores, el evento se registra o el ISSU se detiene, para no crear versiones no coincidentes en ambos nodos del clúster de chasis. Tabla 8 Proporciona algunas de las condiciones de error comunes y sus soluciones. Los mensajes de ejemplo que se usan en el Tabla 8 provienen del dispositivo SRX1500 y también son aplicables a todos los firewalls de la serie SRX compatibles.

error: [Oct  6 12:30:16]: Reboot secondary node failed (error-code: 4.1)

       error: [Oct  6 12:30:16]: ISSU Aborted! Backup node maybe in inconsistent state, Please restore backup node
       [Oct  6 12:30:16]: ISSU aborted. But, both nodes are in ISSU window.
       Please do the following:
       1. Rollback the node with the newer image using rollback command
          Note: use the 'node' option in the rollback command
          otherwise, images on both nodes will be rolled back
       2. Make sure that both nodes (will) have the same image
       3. Ensure the node with older image is primary for all RGs
       4. Abort ISSU on both nodes
       5. Reboot the rolled back node

[Oct  3 14:00:46]: timeout waiting for secondary node node1 to sync(error-code: 6.1)
        Chassis control process started, pid 36707 

       error: [Oct  3 14:00:46]: ISSU Aborted! Backup node has been upgraded, Please restore backup node 
       [Oct  3 14:00:46]: ISSU aborted. But, both nodes are in ISSU window. 
       Please do the following: 
      1. Rollback the node with the newer image using rollback command 
          Note: use the 'node' option in the rollback command 
          otherwise, images on both nodes will be rolled back 
      2. Make sure that both nodes (will) have the same image 
      3. Ensure the node with older image is primary for all RGs 
      4. Abort ISSU on both nodes 
      5. Reboot the rolled back node  

[Aug 27 15:28:17]: Secondary node0 ready for failover.
[Aug 27 15:28:17]: Failing over all redundancy-groups to node0
ISSU: Preparing for Switchover
error: remote rg1 priority zero, abort failover.
[Aug 27 15:28:17]: failover all RGs to node node0 failed (error-code: 7.1)
error: [Aug 27 15:28:17]: ISSU Aborted!
[Aug 27 15:28:17]: ISSU aborted. But, both nodes are in ISSU window.
Please do the following:
1. Rollback the node with the newer image using rollback command
    Note: use the 'node' option in the rollback command
           otherwise, images on both nodes will be rolled back
2. Make sure that both nodes (will) have the same image
3. Ensure the node with older image is primary for all RGs
4. Abort ISSU on both nodes
5. Reboot the rolled back node
{primary:node1}

Reboot failure on     Before the reboot of primary node, devices will be out of ISSU setup and no primary node error messages will be displayed.
Primary node

Problema

Solución

Utilice los siguientes mensajes de error para comprender los problemas relacionados con la compatibilidad:

Problema

Solución

Las comprobaciones de validación fallan si la imagen no está presente o si el archivo de imagen está dañado. Los siguientes mensajes de error se muestran cuando las comprobaciones de validación iniciales fallan cuando la imagen no está presente y se anula el ISSU:

Cuando la imagen no está presente

Cuando el archivo de imagen está dañado

Si el archivo de imagen está dañado, se muestra el siguiente resultado:

El nodo principal valida la configuración del dispositivo para garantizar que se pueda confirmar con la nueva versión del software. Si algo sale mal, la ISSU se anula y se muestran mensajes de error.

Problema

Solución

Utilice los siguientes mensajes de error para comprender los problemas relacionados con la instalación:

ISSU descarga la imagen de instalación como se especifica en el comando ISSU como argumento. El archivo de imagen puede ser un archivo local o ubicado en un sitio remoto. Si el archivo no existe o el sitio remoto es inaccesible, se informa de un error.

Problema

Solución

Utilice los siguientes mensajes de error para comprender el problema:

Problema

Solución

Use los siguientes mensajes de error para comprender los problemas relacionados con ksyncd:

ISSU comprueba si hay errores de ksyncd en el nodo secundario (nodo 1) y muestra el mensaje de error si hay algún problema y anula la actualización.