- play_arrow Descripción general
- play_arrow Características de operación, administración y administración
- play_arrow OAM de Ethernet y administración de fallos de conectividad para enrutadores
- Introducción a la administración de errores de conectividad (CFM) de OAM
- Configurar la administración de errores de conectividad (CFM)
- Perfil de acción de CFM
- Interfaz de administración local Ethernet
- Soporte CFM para paquetes encapsulados CCC
- Configurar ISSU unificada para 802.1ag CFM
- Monitoreo CFM entre dispositivos CE y PE
- Configurar mensajes de comprobación de continuidad
- Ejemplo: Configurar Ethernet CFM en interfaces físicas
- Ejemplo: Configurar Ethernet CFM en conexiones de puente
- Ejemplo: Configurar Ethernet CFM a través de VPLS
- play_arrow Administración de fallos de vínculo para enrutadores
- play_arrow Administración de fallos de vínculo OAM Ethernet para conmutadores
- play_arrow Administración de errores de conectividad OAM Ethernet para conmutadores
- play_arrow Retardo de trama Ethernet
- Mediciones de retardo de trama Ethernet en conmutadores
- Configurar interfaces MEP en conmutadores para que admitan mediciones de retardo de trama Ethernet (procedimiento de CLI)
- Configuración de mediciones de retardo de trama Ethernet unidireccional en conmutadores (procedimiento de CLI)
- Configurar un perfil de iterador en un conmutador (procedimiento de CLI)
- Activar una sesión de medición de retardo de trama Ethernet en un conmutador
- Configuración de mediciones de retardo de trama Ethernet bidireccional en conmutadores (procedimiento de CLI)
- play_arrow Oam del servicio Ethernet (ITU-ty.1731) para enrutadores
- Visión general de OAM del servicio Ethernet ITU-T Y.1731
- Configurar sesiones de medición de retardo de trama Ethernet
- Configuración de interfaces MEP para admitir mediciones de retardo de trama Ethernet
- Configurar la medición de pérdida de tramas Ethernet
- Configurar un perfil de iterador
- Configurar mediciones de pérdida sintética Ethernet
- Indicación de alarma Ethernet
- Modo de transmisión en línea
-
- play_arrow Supervisión de red mediante SNMP
- Descripción general de la arquitectura SNMP y las MIB SNMP
- Descripción de la implementación de SNMP en Junos OS
- Configurar SNMP en Junos OS
- Configurar opciones en dispositivos administrados para un mejor tiempo de respuesta SNMP
- MIB de utilidad específica para empresas para mejorar la cobertura SNMP
- Optimice la configuración del sistema de administración de red para obtener los mejores resultados
- Interfaces para aceptar solicitudes SNMP
- Configurar SNMP para instancias de enrutamiento
- Configurar operaciones remotas SNMP
- Capturas SNMP
- Capturas SNMP compatibles con Junos OS
- Rastrear actividad SNMP
- Privilegios de acceso para un grupo SNMP
- Configurar ID de motor local en SNMPv3
- Configurar SNMPv3
- Configurar el tipo de autenticación SNMPv3 y el tipo de cifrado
- Capturas SNMPv3
- SNMPv3 informa
- Comunidades SNMP
- Vistas MIB
- MIB SNMP compatibles con Junos OS y Junos OS Evolved
- Preguntas frecuentes sobre SNMP de Junos OS
- play_arrow Monitoreo remoto de red (RMON) con alarmas y eventos SNMP
- play_arrow Opciones de contabilidad
- play_arrow Opciones de monitoreo
- play_arrow Alarmas de interfaz
- play_arrow Monitoreo de IP
- play_arrow Tecnología de monitoreo de sFlow
- play_arrow Muestreo adaptable para enrutadores y conmutadores
- play_arrow Software de diagnóstico del acelerador de flujo de paquetes
-
- play_arrow Supervisión de características de seguridad comunes
- play_arrow Gestión del rendimiento
- play_arrow Imitación de puerto
- play_arrow Duplicación de puertos y analizadores
- Duplicación de puertos y analizadores
- Configuración de analizadores y duplicación de puertos
- Configuración de instancias de creación de reflejo de puertos
- Configuración de la duplicación de puertos en interfaces físicas
- Configuración de la creación de reflejo de puertos en interfaces lógicas
- Configuración de la duplicación de puertos para varios destinos
- Configuración de la duplicación de puertos para destinos remotos
- Configuración del análisis local y remoto de creación de reflejo de puertos
- Duplicación de puerto 1:N a múltiples destinos en conmutadores
- Ejemplo: Configurar la creación de reflejo de puertos con familia cualquiera y un filtro de firewall
- Supervisión de la duplicación de puertos
- Configurar la duplicación de paquetes con encabezados de capa 2 para el tráfico reenviado de capa 3
- Solución de problemas de duplicación de puertos
-
- play_arrow Administración de red y solución de problemas
- Comprimir los registros de solución de problemas de /var/logs para enviarlos al soporte técnico de Juniper Networks
- Monitoreo y solución de problemas
- Solución de problemas del rendimiento del sistema con la metodología de monitoreo de recursos
- Configuración de las opciones de depuración y rastreo de rutas de datos
- Uso de MPLS para diagnosticar LSP, VPN y circuitos de capa 2
- Uso de la captura de paquetes para analizar el tráfico de red
- Descripción general de On-Box Packet Sniffer
- Solución de problemas de dispositivos de seguridad
- play_arrow Instrucciones de configuración y comandos operativos
EN ESTA PÁGINA
Especifique la utilidad y la gravedad de los mensajes que se incluirán en el registro
Dirija los mensajes de registro del sistema a un archivo de registro
Dirigir mensajes de registro del sistema a un terminal de usuario
Dirija los mensajes de registro del sistema a un equipo remoto o a otro motor de enrutamiento
Agregar una cadena de texto a los mensajes de registro del sistema dirigidos a un destino remoto
Funciones predeterminadas para los mensajes de registro del sistema dirigidos a un destino remoto
Facilidades alternativas para mensajes de registro del sistema dirigidos a un destino remoto
Dirija los mensajes de registro del sistema a un destino remoto
Especifique la utilidad y la gravedad de los mensajes que se incluirán en el registro
Cada mensaje de registro del sistema pertenece a una instalación, que agrupa mensajes generados por la misma fuente (como un proceso de software) o que se refieren a una condición o actividad similar (como intentos de autenticación). A cada mensaje también se le asigna previamente un nivel de gravedad, que indica la gravedad con la que el evento desencadenante afecta a las funciones de la plataforma de enrutamiento.
Cuando se configura el registro para una instalación y un destino, se especifica un nivel de gravedad para cada instalación. Los mensajes de la instalación que están clasificados en ese nivel y superior se registran en el siguiente destino:
[edit system syslog] (console | file filename | host destination | user username) { facility severity ; }
Para obtener más información acerca de los destinos, consulte Dirigir mensajes de registro del sistema a un terminal de usuario y Dirigir mensajes de registro del sistema a la consola.
Para registrar mensajes que pertenecen a más de una instalación en un destino determinado, especifique cada instalación y la gravedad asociada como una instrucción independiente dentro del conjunto de instrucciones para el destino.
Tabla 1 enumera los recursos de registro del sistema de Junos OS que puede especificar en las instrucciones de configuración en el nivel jerárquico [edit system syslog]
.
Facilidad | Tipo de evento o error |
---|---|
| Todos (mensajes de todas las instalaciones) |
| Intentos de autenticación y autorización |
| Cambios en la configuración de Junos OS |
| La configuración especificada no es válida en el tipo de enrutador |
| Acciones realizadas o errores encontrados por los procesos del sistema |
| Eventos relacionados con la captura dinámica de flujo |
| Incluir prioridad y facilidad en los mensajes de registro del sistema |
| Acciones realizadas o errores encontrados por las aplicaciones externas locales |
| Acciones de filtrado de paquetes realizadas por un filtro de firewall |
| Acciones realizadas o errores encontrados por el proceso FTP |
| Comandos emitidos en el símbolo del sistema de la interfaz de línea de comandos (CLI) de Junos OS o por una aplicación cliente, como un protocolo XML de Junos o un cliente XML de NETCONF |
| Acciones realizadas o errores encontrados por el kernel de Junos OS |
| Acciones realizadas o errores encontrados por los procesos del protocolo de tiempo de red |
| Acciones realizadas o errores encontrados por el motor de reenvío de paquetes |
| Acciones realizadas o errores encontrados por los procesos del espacio de usuario |
Tabla 2 enumera los niveles de gravedad que puede especificar en las instrucciones de configuración en el nivel jerárquico [edit system syslog]
. Los niveles a través info
están emergency
en orden de mayor gravedad (mayor efecto sobre el funcionamiento) a más bajo.
A diferencia de los otros niveles de gravedad, el nivel deshabilita el registro de una instalación en lugar de indicar la gravedad con la none
que un evento desencadenante afecta a las funciones de enrutamiento. Para obtener más información, consulte Deshabilitar el registro del sistema de una instalación.
valor | Nivel de gravedad | Description |
---|---|---|
NA |
| Deshabilita el registro de la instalación asociada a un destino |
0 |
| Fallo del sistema u otra condición que hace que el enrutador deje de funcionar |
1 |
| Condiciones que requieren corrección inmediata, como una base de datos del sistema dañada |
2 |
| Condiciones críticas, como errores graves |
3 |
| Condiciones de error que generalmente tienen consecuencias menos graves que los errores en los niveles de emergencia, alerta y críticos |
4 |
| Condiciones que justifican el monitoreo |
5 |
| Condiciones que no son errores, pero que pueden justificar un tratamiento especial |
6 |
| Eventos o condiciones de no error de interés |
7 |
| Incluye todos los niveles de gravedad |
Dirija los mensajes de registro del sistema a un archivo de registro
Para dirigir los mensajes de registro del sistema a un archivo del directorio del /var/log motor de enrutamiento local, incluya la file
instrucción en el [edit system syslog]
nivel de jerarquía:
[edit system syslog] file filename { facility severity; archive <archive-sites (ftp-url <password password>)> <files number> <size size> <start-time "YYYY-MM-DD.hh:mm"> <transfer-interval minutes> <world-readable | no-world-readable>; explicit-priority; match "regular-expression"; structured-data { brief; } }
Para obtener la lista de instalaciones y niveles de gravedad, consulte Especificación de la facilidad y la gravedad de los mensajes que se incluirán en el registro.
Para evitar que los archivos de registro crezcan demasiado, la utilidad de registro del sistema de Junos OS escribe mensajes de forma predeterminada en una secuencia de archivos de un tamaño definido. Al incluir la archive
instrucción, puede configurar el número de archivos, su tamaño máximo y quién puede leerlos, ya sea para todos los archivos de registro o para un archivo de registro determinado. Para obtener más información, consulte Especificación del tamaño, número y propiedades de archivado del archivo de registro.
Para obtener información acerca de las siguientes instrucciones, consulte las secciones indicadas:
explicit-priority
—Consulte Inclusión de información de prioridad en los mensajes de registro del sistemamatch
: consulte Uso de cadenas y expresiones regulares para refinar el conjunto de mensajes registradosstructured-data
—Consulte Registro de mensajes en formato de datos estructurados
Dirigir mensajes de registro del sistema a un terminal de usuario
Para dirigir los mensajes de registro del sistema a la sesión de terminal de uno o más usuarios específicos (o todos los usuarios) cuando inician sesión en el motor de enrutamiento local, incluya la user
instrucción en el [edit system syslog]
nivel de jerarquía:
Especifique uno o más nombres de usuario de Junos OS, separando varios valores con espacios, o utilice el asterisco (*
) para indicar todos los usuarios que han iniciado sesión en el motor de enrutamiento local.
Para obtener la lista de los recursos de registro y los niveles de gravedad, consulte Especificación de la utilidad y la gravedad de los mensajes que se incluirán en el registro. Para obtener información acerca de la match
instrucción, vea Usar cadenas y expresiones regulares para refinar el conjunto de mensajes registrados.
Dirija los mensajes de registro del sistema a la consola
Para dirigir los mensajes de registro del sistema a la consola del motor de enrutamiento local, incluya la console
instrucción en el [edit system syslog]
nivel de jerarquía:
[edit system syslog] console { facility severity; }
Para obtener la lista de los recursos de registro y los niveles de gravedad, consulte Especificación de la utilidad y la gravedad de los mensajes que se incluirán en el registro.
Dirija los mensajes de registro del sistema a un equipo remoto o a otro motor de enrutamiento
Para dirigir los mensajes de registro del sistema a un equipo remoto o al otro motor de enrutamiento, incluya la host
instrucción en el nivel de [edit system syslog]
jerarquía:
[edit system syslog] host (hostname | other-routing-engine) { facility severity; explicit-priority; facility-override facility; log-prefix string; match "regular-expression"; source-address source-address; structured-data { brief; } } source-address source-address;
Para dirigir los mensajes de registro del sistema a un equipo remoto, incluya la instrucción para especificar la dirección IP versión 4 (IPv4), la dirección IP versión 6 (IPv6) o el host
hostname nombre de host completo. El equipo remoto debe ejecutar la utilidad estándar syslogd
. No recomendamos dirigir los mensajes a otro dispositivo de Juniper Networks. En cada mensaje de registro del sistema dirigido al equipo remoto, el nombre de host del motor de enrutamiento local aparece después de la marca de tiempo para indicar que es el origen del mensaje.
Para dirigir los mensajes de registro del sistema al otro motor de enrutamiento en un dispositivo con dos motores de enrutamiento instalados y operativos, incluya la host other-routing-engine
instrucción. La instrucción no es automáticamente recíproca, por lo que debe incluirla en cada configuración de motor de enrutamiento si desea que los motores de enrutamiento dirijan mensajes entre sí. En cada mensaje dirigido al otro motor de enrutamiento, la cadena re0
o re1
aparece después de la marca de tiempo para indicar el origen del mensaje.
Para obtener la lista de los recursos de registro y los niveles de gravedad que se deben configurar en la host
instrucción, consulte Especificación de la facilidad y la gravedad de los mensajes que se incluirán en el registro.
Para registrar información sobre el nivel de instalación y gravedad en cada mensaje, incluya la explicit-priority
instrucción. Para obtener más información, consulte Inclusión de información de prioridad en los mensajes de registro del sistema.
Para obtener información acerca de la match
instrucción, vea Usar cadenas y expresiones regulares para refinar el conjunto de mensajes registrados.
Al dirigir mensajes a equipos remotos, puede incluir la source-address
instrucción para especificar la dirección IP del dispositivo que se informa en los mensajes como su origen. En cada host
instrucción, incluya la facility-override
instrucción para asignar una función alternativa y la log-prefix
instrucción para agregar una cadena a cada mensaje. Puede incluir la structured-data
instrucción para habilitar el reenvío de mensajes de registro del sistema estructurados a un servidor de registro del sistema remoto en el formato de mensaje de registro del sistema IETF .
Especificar una dirección de origen alternativa para los mensajes de registro del sistema dirigidos a un destino remoto
Para especificar el enrutador de origen que se notificará en los mensajes de registro del sistema cuando los mensajes se dirijan a un equipo remoto, incluya la source-address
instrucción en el nivel de [edit system syslog]
jerarquía:
[edit system syslog] source-address source-address;
source-address
es una dirección IPv4 o IPv6 válida configurada en una de las interfaces del enrutador. La dirección se indica en los mensajes dirigidos a todos los equipos remotos especificados en host hostname
instrucciones en el nivel de [edit system syslog]
jerarquía, pero no en mensajes dirigidos al otro motor de enrutamiento.
Agregar una cadena de texto a los mensajes de registro del sistema dirigidos a un destino remoto
Para agregar una cadena de texto a cada mensaje de registro del sistema dirigido a un equipo remoto o al otro motor de enrutamiento, incluya la log-prefix
instrucción en el nivel de [edit system syslog host]
jerarquía:
[edit system syslog host (hostname | other-routing-engine)] facility severity; log-prefix string;
La cadena puede contener cualquier carácter alfanumérico o especial, excepto el signo igual ( = ) y los dos puntos ( : ). Tampoco puede incluir el carácter espacial; No escriba la cadena entre comillas (" ") en un intento de incluir espacios en ella.
La utilidad de registro del sistema de Junos OS anexa automáticamente dos puntos y un espacio a la cadena especificada cuando se escriben los mensajes de registro del sistema en el registro. La cadena se inserta después del identificador del motor de enrutamiento que generó el mensaje.
En el ejemplo siguiente se muestra cómo agregar la cadena M120 a todos los mensajes para indicar que el enrutador es un enrutador M120 y dirigir los mensajes al equipo remoto hardware-logger.mycompany.com:
[edit system syslog] host hardware-logger.mycompany.com { any info; log-prefix M120; }
Cuando estas instrucciones de configuración se incluyen en un enrutador M120 denominado origin1, aparece un mensaje en el hardware-logger.mycompany.com de inicio de sesión del sistema similar al siguiente:
Mar 9 17:33:23 origin1 M120: mgd[477]: UI_CMDLINE_READ_LINE: user ‘root’, command ‘run show version’
Cambiar el nombre alternativo de la instalación para los mensajes de registro del sistema dirigidos a un destino remoto
Algunas funciones asignadas a los mensajes registrados en el enrutador o conmutador local tienen nombres específicos de Junos OS (consulte Funciones de registro del sistema de Junos OS). En la configuración recomendada, un equipo remoto designado en el nivel de [edit system syslog host hostname]
jerarquía no es un enrutador o conmutador de Juniper Networks, por lo que su utilidad syslogd no puede interpretar los nombres específicos de Junos OS. Para habilitar la utilidad syslogd estándar para gestionar los mensajes de estas instalaciones cuando los mensajes se dirigen a un equipo remoto, se utiliza un nombre de instalación estándar localX
en lugar del nombre de instalación específico de Junos OS.
Funciones predeterminadas para mensajes de registro del sistema dirigidos a un destino remoto muestra el nombre de instalación alternativo predeterminado junto al nombre de instalación específico de Junos OS para el que se utiliza.
La utilidad syslogd en una máquina remota maneja todos los mensajes que pertenecen a una instalación de la misma manera, independientemente de la fuente del mensaje (el enrutador o conmutador de Juniper Networks o la propia máquina remota). Por ejemplo, las siguientes instrucciones en la configuración del enrutador llamadas local-router
mensajes directos desde la authorization
instalación a la máquina remota monitor.mycompany.com:
[edit system syslog] host monitor.mycompany.com { authorization info; }
La instalación alternativa predeterminada para la instalación local authorization
también authorization
es . Si la utilidad syslogd activado monitor
está configurada para escribir mensajes pertenecientes a la authorization
instalación en el archivo /var/log/auth-attempts, el archivo contiene los mensajes generados cuando los usuarios inician sesión y local-router
los mensajes generados cuando los usuarios inician sesión en monitor
. Aunque el nombre del equipo de origen aparece en cada mensaje de registro del sistema, la mezcla de mensajes de varios equipos puede dificultar el análisis del contenido del auth-attempts
archivo.
Para facilitar la separación de los mensajes de cada origen, puede asignar una función alternativa a todos los mensajes generados el local-router
cuando se dirigen a monitor
. A continuación, puede configurar la utilidad syslogd para monitor
escribir mensajes con la instalación alternativa en un archivo diferente de los mensajes generados en monitor
sí mismo.
Para cambiar la función utilizada para todos los mensajes dirigidos a un equipo remoto, incluya la facility-override
instrucción en el nivel de [edit system syslog host hostname]
jerarquía:
[edit system syslog host hostname] facility severity; facility-override facility;
En general, tiene sentido especificar una instalación alternativa que aún no esté en uso en la máquina remota, como una de las localX
instalaciones. En el equipo remoto, también debe configurar la utilidad syslogd para manejar los mensajes de la manera deseada.
Facilidades para la instrucción facility-override enumera las instalaciones que puede especificar en la facility-override
instrucción.
No se recomienda incluir la facility-override
instrucción en el nivel jerárquico [edit system syslog host other-routing-engine]
. No es necesario utilizar nombres de instalaciones alternativos al dirigir mensajes al otro motor de enrutamiento, ya que su utilidad de registro del sistema Junos OS puede interpretar los nombres específicos de Junos OS.
En el ejemplo siguiente se muestra cómo registrar todos los mensajes generados en el enrutador local en el nivel de error o superior en la función local0 en el equipo remoto llamado monitor.mycompany.com:
[edit system syslog] host monitor.mycompany.com { any error; facility-override local0; }
En el ejemplo siguiente se muestra cómo configurar enrutadores ubicados en California y enrutadores ubicados en Nueva York para enviar mensajes a un único equipo remoto denominado central-logger.mycompany.com. Los mensajes de California se asignan a la instalación alternativa local0 y los mensajes de Nueva York se asignan a la instalación alternativa local2.
Configure los enrutadores de California para agregar mensajes en la instalación local0:
content_copy zoom_out_map[edit system syslog] host central-logger.mycompany.com { change-log info; facility-override local0; }
Configure los enrutadores de Nueva York para agregar mensajes en la instalación local2:
content_copy zoom_out_map[edit system syslog] host central-logger.mycompany.com { change-log info; facility-override local2; }
En el registrador central, puede configurar la utilidad de registro del sistema para escribir mensajes desde la instalación local0 en el archivo change-log y los mensajes desde la instalación local2 en el archivo new-york-config.
Funciones predeterminadas para los mensajes de registro del sistema dirigidos a un destino remoto
Tabla 3 muestra el nombre de instalación alternativo predeterminado junto al nombre de instalación específico de Junos OS para el que se utiliza. Para las instalaciones que no aparecen en la lista, el nombre alternativo predeterminado es el mismo que el nombre de la instalación local.
Instalación local específica de Junos OS | Función predeterminada cuando se dirige a un destino remoto |
---|---|
registro de cambios | local6 |
registro de conflictos | local5 |
dfc | local1 |
cortafuegos | local3 |
comandos interactivos | local7 |
PFE | local4 |
Facilidades alternativas para mensajes de registro del sistema dirigidos a un destino remoto
Tabla 4 enumera las funciones que puede especificar en la facility-override
instrucción.
Facilidad | Description |
---|---|
| Intentos de autenticación y autorización |
| Acciones realizadas o errores encontrados por los procesos del sistema |
| Acciones realizadas o errores encontrados por el proceso FTP |
| Acciones realizadas o errores encontrados por el kernel de Junos OS |
| Instalación local número 0 |
| Instalación local número 1 |
| Instalación local número 2 |
| Instalación local número 3 |
| Instalación local número 4 |
| Instalación local número 5 |
| Instalación local número 6 |
| Instalación local número 7 |
| Acciones realizadas o errores encontrados por los procesos del espacio de usuario |
No se recomienda incluir la facility-override
instrucción en el nivel jerárquico [edit system syslog host other-routing-engine]
. No es necesario utilizar nombres de instalaciones alternativos al dirigir mensajes al otro motor de enrutamiento, ya que su utilidad de registro del sistema Junos OS puede interpretar los nombres específicos de Junos OS.
Ejemplos: Asignar una función alternativa al sistema Mensajes de registro dirigidos a un destino remoto
Registre todos los mensajes generados en la plataforma de enrutamiento local en el nivel de error o superior a la local0
instalación en la máquina remota llamada monitor.mycompany.com
:
[edit system syslog] host monitor.mycompany.com { any error; facility-override local0; }
Configure plataformas de enrutamiento ubicadas en California y plataformas de enrutamiento ubicadas en Nueva York para enviar mensajes a una única máquina remota llamada central-logger.mycompany.com. A los mensajes de California se les asigna la instalación alternativa local0 y los mensajes de Nueva York se asignan a la instalación alternativa local2.
Configure las plataformas de enrutamiento de California para agregar mensajes en la
local0
instalación:content_copy zoom_out_map[edit system syslog] host central-logger.mycompany.com { change-log info; facility-override local0; }
Configure las plataformas de enrutamiento de Nueva York para agregar mensajes en la
local2
instalación:content_copy zoom_out_map[edit system syslog] host central-logger.mycompany.com { change-log info; facility-override local2; }
A central-logger,
continuación, puede configurar la utilidad de registro del sistema para escribir mensajes desde la local0
instalación en el archivo california-config y los mensajes de la local2
instalación en el archivo new-york-config.
Mensajes directos a un destino remoto desde la matriz de enrutamiento basada en el enrutador de matriz de transmisión
Puede configurar una matriz de enrutamiento compuesta por un enrutador de matriz de transmisión y enrutadores T640 para dirigir los mensajes de registro del sistema a una máquina remota o al otro motor de enrutamiento en cada enrutador, al igual que en un sistema de chasis único. Incluya la host
instrucción en el nivel de [edit system syslog]
jerarquía en el enrutador TX Matrix:
[edit system syslog] host (hostname | other-routing-engine) { facility severity; explicit-priority; facility-override facility; log-prefix string; match "regular-expression"; } source-address source-address;
El enrutador TX Matrix dirige los mensajes a una máquina remota u otro motor de enrutamiento de la misma manera que un sistema de chasis único, y las instrucciones opcionales (explicit-priority
, facility-override
, log-prefix
, match
, y source-address
) también tienen el mismo efecto que en un sistema de chasis único.
Para que el enrutador de matriz de transmisión incluya información de prioridad cuando dirige mensajes que se originaron en un enrutador T640 al destino remoto, también debe incluir la explicit-priority
instrucción en el nivel de [edit system syslog host scc-master]
jerarquía.
La other-routing-engine
instrucción no interactúa con el reenvío de mensajes desde los enrutadores T640 al enrutador TX Matrix. Por ejemplo, si incluye la instrucción en la configuración del motor de enrutamiento en la ranura 0 (re0
), el motor de re0
enrutamiento de cada enrutador T640 envía mensajes únicamente al motor de re1
enrutamiento de su plataforma. Tampoco envía mensajes directamente al motor de re1
enrutamiento en el enrutador TX Matrix.
Debido a que la configuración en el enrutador TX Matrix se aplica a los enrutadores T640, cualquier enrutador T640 que tenga interfaces para acceso directo a Internet también dirige mensajes a la máquina remota. Las consecuencias incluyen las siguientes:
Si los enrutadores T640 están configurados para reenviar mensajes al enrutador TX Matrix (como en la configuración predeterminada), la máquina remota recibe dos copias de algunos mensajes: uno directamente desde el enrutador T640 y el otro desde el enrutador TX Matrix. Los mensajes que se duplican dependen de si la gravedad es la misma para el registro local y para los mensajes reenviados. Para obtener más información, consulte Configuración del reenvío de mensajes al enrutador TX Matrix.
Si la
source-address
instrucción está configurada en el nivel de[edit system syslog]
jerarquía, todos los enrutadores de la matriz de enrutamiento notifican la misma dirección de origen en los mensajes dirigidos al equipo remoto. Esto es apropiado, porque la matriz de enrutamiento funciona como un único enrutador.Si se incluye la
log-prefix
instrucción, los mensajes de todos los enrutadores de la matriz de enrutamiento incluyen la misma cadena de texto. No puede utilizar la cadena para distinguir entre los enrutadores de la matriz de enrutamiento.
Mensajes directos a un destino remoto desde la matriz de enrutamiento basada en un enrutador TX Matrix Plus
Desde la perspectiva de la interfaz de usuario, la matriz de enrutamiento aparece como un único enrutador. El enrutador TX Matrix Plus (también llamado SFC de chasis de estructura de conmutación) controla todos los enrutadores T1600 o T4000, también llamados LCC de chasis de tarjeta ine) en la matriz de enrutamiento.
Puede configurar una matriz de enrutamiento compuesta por un enrutador TX Matrix Plus con LCC T1600 o T4000 conectadas para dirigir los mensajes de registro del sistema a una máquina remota o al otro motor de enrutamiento en cada enrutador de enrutamiento, al igual que en un sistema de chasis único. Incluya la host
instrucción en el nivel jerárquico [edit system syslog]
en el SFC:
[edit system syslog] host (hostname | other-routing-engine) { facility severity; explicit-priority; facility-override facility; log-prefix string; match "regular-expression"; } source-address source-address;
El enrutador TX Matrix Plus dirige los mensajes a una máquina remota o al otro motor de enrutamiento de la misma manera que un sistema de chasis único, y las instrucciones opcionales (explicit-priority
, facility-override
, match
log-prefix
, , y source-address
) también tienen el mismo efecto que en un sistema de chasis único.
Para que el enrutador TX Matrix Plus incluya información de prioridad cuando dirige mensajes que se originaron en una LCC T1600 o T4000 conectada al destino remoto, también debe incluir la explicit-priority
instrucción en el nivel de [edit system syslog host sfc0-master]
jerarquía.
La other-routing-engine
instrucción no interactúa con el reenvío de mensajes desde las LCC T1600 o T4000 conectadas al SFC. Por ejemplo, si incluye la instrucción en la configuración del motor de enrutamiento en la ranura 0 (re0
), el re0
motor de enrutamiento de cada LCC T1600 o T4000 conectada envía mensajes únicamente al motor de re1
enrutamiento de su enrutador. Tampoco envía mensajes directamente al motor de re1
enrutamiento en el SFC.
Dado que la configuración del SFC se aplica a las LCC T1600 o T4000 conectadas, cualquier LCC que tenga interfaces para el acceso directo a Internet también dirige los mensajes a la máquina remota. Las consecuencias incluyen las siguientes:
Si las LCC están configuradas para reenviar mensajes al SFC (como en la configuración predeterminada), el equipo remoto recibe dos copias de algunos mensajes: uno directamente desde la LCC T1600 o T4000 y el otro desde el SFC. Los mensajes que se duplican dependen de si la gravedad es la misma para el registro local y para los mensajes reenviados. Para obtener más información, consulte Configuración del reenvío de mensajes al enrutador TX Matrix Plus.
Si la
source-address
instrucción está configurada en el nivel de[edit system syslog]
jerarquía, todos los enrutadores de la matriz de enrutamiento notifican la misma dirección de origen en los mensajes dirigidos al equipo remoto. Esto es apropiado, ya que la matriz de enrutamiento funciona como un único enrutador de enrutamiento.Si se incluye la
log-prefix
instrucción, los mensajes de todos los enrutadores de la matriz de enrutamiento incluyen la misma cadena de texto. No puede utilizar la cadena para distinguir entre los enrutadores de la matriz de enrutamiento.