Sur cette page
Spécification de la facilité et de la gravité des messages à inclure dans le journal
Diriger les messages des journaux système vers un fichier journal
Diriger les messages des journaux système vers un terminal utilisateur
Diriger les messages des journaux système vers une machine distante ou l’autre moteur de routage
Diriger les messages du journal système vers une machine distante
Ajout d’une chaîne de texte aux messages du journal système dirigés vers une destination distante
Installations par défaut pour les messages de journal système dirigés vers une destination distante
Autres installations pour les messages de journal du système dirigés vers une destination distante
Diriger les messages des journaux système vers une destination distante
Spécification de la facilité et de la gravité des messages à inclure dans le journal
Chaque message de journal système appartient à une installation, qui regroupe des messages qui sont générés par la même source (par exemple, un processus logiciel) ou qui concernent une condition ou une activité similaire (comme les tentatives d’authentification). Chaque message est également préassigné un niveau de gravité, ce qui indique la gravité de l’événement déclencheur sur les fonctions de la plate-forme de routage.
Lorsque vous configurez la journalisation pour une installation et une destination, vous spécifiez un niveau de gravité pour chaque installation. Les messages de l’établissement évalués à ce niveau ou supérieur sont enregistrés à la destination suivante :
[edit system syslog] (console | file filename | host destination | user username) { facility severity ; }
Pour plus d’informations sur les destinations, reportez-vous à la section Diriger les messages du journal système vers un terminal utilisateur et diriger les messages du journal système vers la console.
Pour consigner les messages appartenant à plusieurs installations à une destination particulière, spécifiez chaque installation et la gravité associée sous la forme d’une déclaration distincte dans l’ensemble d’instructions pour la destination.
Tableau 1 répertorie les installations de journalisation du système Junos OS que vous pouvez spécifier dans les déclarations de configuration au niveau de la [edit system syslog]
hiérarchie.
Site |
Type d’événement ou d’erreur |
---|---|
|
Tout (messages provenant de toutes les installations) |
|
Tentatives d’authentification et d’autorisation |
|
Modifications apportées à la configuration de Junos OS |
|
La configuration spécifiée n’est pas valide sur le type de routeur |
|
Actions effectuées ou erreurs rencontrées par les processus système |
|
Événements liés à la capture dynamique des flux |
|
Inclure la priorité et l’installation dans les messages de journal du système |
|
Actions effectuées ou erreurs rencontrées par les applications externes locales |
|
Actions de filtrage des paquets effectuées par un filtre de pare-feu |
|
Actions effectuées ou erreurs rencontrées par le processus FTP |
|
Commandes émises à l’invite de l’interface de ligne de commande (CLI) Junos OS ou par une application cliente telle qu’un protocole XML Junos ou un client XML NETCONF |
|
Actions exécutées ou erreurs rencontrées par le noyau Junos OS |
|
Actions effectuées ou erreurs rencontrées par les processus du Protocole de temps réseau |
|
Actions effectuées ou erreurs rencontrées par le moteur de transfert de paquets |
|
Événements ou erreurs liés à la sécurité |
|
Actions effectuées ou erreurs rencontrées par les processus d’espace utilisateur |
Tableau 2 répertorie les niveaux de gravité que vous pouvez spécifier dans les déclarations de configuration au niveau de la [edit system syslog]
hiérarchie. Les niveaux sont dans emergency
info
l’ordre de la plus grande sévérité (plus grand effet sur le fonctionnement) à plus faible.
Contrairement aux autres niveaux de gravité, ce niveau désactive la none
journalisation d’une installation au lieu d’indiquer la gravité de l’impact d’un événement déclencheur sur les fonctions de routage. Pour plus d’informations, voir Désactiver la journalisation du système d’une installation.
Valeur |
Niveau de gravité |
Description |
---|---|---|
S/O |
|
Désactive la journalisation de l’installation associée à une destination |
0 |
|
Panique du système ou autre condition qui provoque l’arrêt du fonctionnement du routeur |
1 |
|
Conditions nécessitant une correction immédiate, telles qu’une base de données système corrompue |
2 |
|
Conditions critiques, telles que des erreurs difficiles |
3 |
|
Conditions d’erreur qui ont généralement des conséquences moins graves que les erreurs au niveau de l’urgence, de l’alerte et des niveaux critiques |
4 |
|
Conditions qui justifient une surveillance |
5 |
|
Conditions qui ne sont pas des erreurs, mais qui peuvent justifier un traitement spécial |
6 |
|
Événements ou conditions d’intérêt non-terroristes |
7 |
|
Inclut tous les niveaux de gravité |
Diriger les messages des journaux système vers un fichier journal
Pour diriger les messages du journal système vers un fichier du /var/log répertoire du moteur de routage local, incluez l’instruction file
au niveau de la [edit system syslog]
hiérarchie :
[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; } }
Pour obtenir la liste des installations et des niveaux de gravité, voir Spécification de l’installation et de la gravité des messages à inclure dans le journal.
Pour éviter que les fichiers journaux ne deviennent trop volumineux, l’utilitaire de journalisation du système Junos OS écrit par défaut des messages dans une séquence de fichiers d’une taille définie. En incluant l’instruction archive
, vous pouvez configurer le nombre de fichiers, leur taille maximale et qui peut les lire, soit pour tous les fichiers journaux, soit pour un certain fichier journal. Pour plus d’informations, voir Spécification de la taille du fichier journal, du nombre et des propriétés d’archivage.
Pour plus d’informations sur les déclarations suivantes, consultez les sections indiquées :
explicit-priority
— Voir inclure des informations de priorité dans les messages de journal systèmematch
— Voir Utiliser des chaînes et des expressions régulières pour affiner l’ensemble de messages enregistrésstructured-data
— Voir les messages de journalisation au format de données structurées
Diriger les messages des journaux système vers un terminal utilisateur
Pour diriger les messages de journalisation système vers la session terminale d’un ou plusieurs utilisateurs spécifiques (ou tous les utilisateurs) lorsqu’ils sont connectés au moteur de routage local, incluez l’énoncé user
au niveau de la [edit system syslog]
hiérarchie :
[edit system syslog] user (username | *) { facility severity; match "regular-expression"; }
Spécifiez un ou plusieurs noms d’utilisateur Junos OS, en séparant plusieurs valeurs par des espaces, ou utilisez l’astérisque (*
) pour indiquer tous les utilisateurs connectés au moteur de routage local.
Pour obtenir la liste des installations de journalisation et des niveaux de gravité, reportez-vous à la section Spécification de l’installation et de la gravité des messages à inclure dans le journal. Pour plus d’informations sur l’instruction match
, voir Utilisation de chaînes et d’expressions régulières pour affiner l’ensemble de messages enregistrés.
Diriger les messages du journal système vers la console
Pour diriger les messages des journaux système vers la console du moteur de routage local, incluez l’énoncé console
au niveau de la [edit system syslog]
hiérarchie :
[edit system syslog] console { facility severity; }
Pour obtenir la liste des installations de journalisation et des niveaux de gravité, reportez-vous à la section Spécification de l’installation et de la gravité des messages à inclure dans le journal.
Diriger les messages des journaux système vers une machine distante ou l’autre moteur de routage
Pour diriger les messages de journalisation système vers une machine distante ou vers l’autre moteur de routage du routeur, incluez l’énoncé host
au niveau de la [edit system syslog]
hiérarchie :
[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;
Pour diriger les messages de journalisation système vers une machine distante, incluez l’instruction host
hostname permettant de spécifier l’adresse IP version 4 (IPv4), l’adresse IP version 6 (IPv6) ou le nom d’hôte complet de la machine distante. La machine distante doit exécuter l’utilitaire standard syslogd
. Nous ne recommandons pas de diriger les messages vers un autre routeur Juniper Networks. Dans chaque message de journal système dirigé vers la machine distante, le nom d’hôte du moteur de routage local apparaît après l’horodatage pour indiquer qu’il est la source du message.
Pour diriger les messages du journal système vers l’autre moteur de routage sur un routeur avec deux moteurs de routage installés et opérationnels, incluez l’instruction host other-routing-engine
. L’instruction n’est pas automatiquement réciproque, vous devez donc l’inclure dans chaque configuration du moteur de routage si vous voulez que les moteurs de routage redirigent les messages les uns vers les autres. Dans chaque message dirigé vers l’autre moteur de routage, la chaîne re0
ou re1
apparaît après l’horodatage pour indiquer la source du message.
Pour enregistrer les informations sur l’installation et le niveau de gravité dans chaque message, incluez l’instruction explicit-priority
. Pour plus d’informations, voir Inclure des informations de priorité dans les messages de journal système.
Pour plus d’informations sur l’instruction match
, voir Utilisation de chaînes et d’expressions régulières pour affiner l’ensemble de messages enregistrés.
Lorsque vous dirigez des messages vers des machines distantes, vous pouvez inclure l’instruction source-address
pour spécifier l’adresse IP du routeur qui est signalée dans les messages comme leur source. Dans chaque host
instruction, incluez l’instruction facility-override
permettant d’affecter une autre facilité et l’instruction log-prefix
pour ajouter une chaîne à chaque message. Vous pouvez inclure l’instruction permettant de structured-data
transférer des messages de journal système structurés vers un serveur de journaux système distant dans le format de message de journal du système IETF .
Diriger les messages du journal système vers une machine distante
Pour diriger les messages de journalisation système vers une machine distante, incluez l’instruction host
au niveau de la [edit system syslog]
hiérarchie :
[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;
Pour diriger les messages de journalisation système vers une machine distante, incluez l’instruction host hostname
permettant de spécifier l’adresse IP version 4 (IPv4) de la machine distante ou le nom d’hôte complet. La machine distante doit exécuter l’utilitaire standard syslogd
. Nous ne recommandons pas de diriger les messages vers un autre commutateur Juniper Networks. Dans chaque message de journal système dirigé vers la machine distante, le nom d’hôte du moteur de routage local apparaît après l’horodatage pour indiquer qu’il est la source du message.
Pour obtenir la liste des installations de journalisation et des niveaux de gravité à configurer dans l’instruction host
, voir Spécification de l’installation et de la gravité des messages à inclure dans le journal.
Pour enregistrer les informations sur l’installation et le niveau de gravité dans chaque message, incluez l’instruction explicit-priority
. Pour plus d’informations, voir Inclure des informations de priorité dans les messages de journal système.
Pour plus d’informations sur l’instruction match
, voir Utilisation de chaînes et d’expressions régulières pour affiner l’ensemble de messages enregistrés.
Lorsque vous dirigez des messages vers des machines distantes, vous pouvez inclure l’instruction source-address
pour spécifier l’adresse IP du commutateur qui est signalée dans les messages comme leur source. Dans chaque host
instruction, vous pouvez également inclure l’instruction facility-override
pour affecter une autre installation et l’instruction log-prefix
pour ajouter une chaîne à chaque message.
Spécification d’une autre adresse source pour les messages du journal système dirigés vers une destination distante
Pour spécifier le routeur source à signaler dans les messages de journalisation du système lorsque les messages sont dirigés vers une machine distante, incluez l’instruction source-address
au niveau de la [edit system syslog]
hiérarchie :
[edit system syslog] source-address source-address;
source-address
est une adresse IPv4 ou IPv6 valide configurée sur l’une des interfaces du routeur. L’adresse est signalée dans les messages adressés à toutes les machines distantes spécifiées dans host hostname
les instructions au niveau de la [edit system syslog]
hiérarchie, mais pas dans les messages dirigés vers l’autre moteur de routage.
Ajout d’une chaîne de texte aux messages du journal système dirigés vers une destination distante
Pour ajouter une chaîne de texte à chaque message de journal système dirigé vers une machine distante ou un autre moteur de routage, incluez l’instruction log-prefix
au niveau de la [edit system syslog host]
hiérarchie :
[edit system syslog host (hostname | other-routing-engine)] facility severity; log-prefix string;
La chaîne peut contenir n’importe quel caractère alphanumérique ou spécial, à l’exception du signe égal ( = ) et du côlon ( : ). Il ne peut pas non plus inclure le caractère d’espace ; ne joignent pas la chaîne entre guillemets (« ») pour tenter d’y inclure des espaces.
L’utilitaire de journalisation du système Junos OS ajoute automatiquement un point deux points et un espace à la chaîne spécifiée lorsque les messages du journal système sont écrits dans le journal. La chaîne est insérée après l’identifiant du moteur de routage qui a généré le message.
L’exemple suivant montre comment ajouter la chaîne M120 à tous les messages pour indiquer que le routeur est un routeur M120 et diriger les messages vers la machine distante hardware-logger.mycompany.com :
[edit system syslog] host hardware-logger.mycompany.com { any info; log-prefix M120; }
Lorsque ces instructions de configuration sont incluses sur un routeur M120 appelé origin1, un message dans le système se connectant hardware-logger.mycompany.com ressemble à ce qui suit :
Mar 9 17:33:23 origin1 M120: mgd[477]: UI_CMDLINE_READ_LINE: user ‘root’, command ‘run show version’
Modification du nom de l’installation alternative pour les messages de journal du système dirigés vers une destination distante
Certaines installations affectées à des messages connectés sur le routeur ou le commutateur local ont des noms spécifiques à Junos OS (voir Installations de journalisation du système Junos OS). Dans la configuration recommandée, une machine distante désignée au niveau de la [edit system syslog host hostname]
hiérarchie n’est pas un routeur ou un commutateur Juniper Networks, de sorte que son utilitaire syslogd ne peut pas interpréter les noms spécifiques à Junos OS. Pour permettre à l’utilitaire syslogd standard de gérer les messages provenant de ces installations lorsque les messages sont dirigés vers une machine distante, un nom d’installation standard localX
est utilisé à la place du nom de l’installation spécifique à Junos OS.
Les installations par défaut des messages du journal système dirigés vers une destination distante répertorient le nom de l’installation alternative par défaut à côté du nom de l’installation spécifique à Junos OS pour qui elle est utilisée.
L’utilitaire syslogd d’une machine distante gère tous les messages appartenant à une installation de la même manière, quelle que soit la source du message (routeur ou commutateur Juniper Networks ou machine distante elle-même). Par exemple, les déclarations suivantes dans la configuration du routeur appelées local-router
messages directs de l’installation authorization
à la machine distante monitor.mycompany.com :
[edit system syslog] host monitor.mycompany.com { authorization info; }
L’installation alternative par défaut pour l’installation locale authorization
est également authorization
. Si l’utilitaire syslogd activé monitor
est configuré pour écrire des messages appartenant à l’installation authorization
dans le fichier /var/log/auth-attempts, alors le fichier contient les messages générés lorsque les utilisateurs se connectent et local-router
les messages générés lorsque les utilisateurs se connectent à monitor
. Bien que le nom de la machine source apparaît dans chaque message de journal système, le mélange de messages provenant de plusieurs machines peut rendre plus difficile l’analyse du contenu du auth-attempts
fichier.
Pour simplifier la séparation des messages de chaque source, vous pouvez attribuer une autre fonction à tous les messages générés lorsqu’ils sont dirigés vers local-router
monitor
. Vous pouvez ensuite configurer l’utilitaire syslogd pour monitor
écrire des messages avec l’autre fonctionnalité vers un autre fichier à partir des messages générés sur monitor
lui-même.
Pour modifier l’installation utilisée pour tous les messages dirigés vers une machine distante, incluez l’énoncé facility-override
au niveau de la [edit system syslog host hostname]
hiérarchie :
[edit system syslog host hostname] facility severity; facility-override facility;
En général, il est logique de spécifier une autre installation qui n’est pas déjà utilisée sur la machine distante, comme l’une des localX
installations. Sur la machine distante, vous devez également configurer l’utilitaire syslogd pour gérer les messages de la manière souhaitée.
Facilities for the Facility-Override Statement répertorie les installations que vous pouvez spécifier dans l’énoncé facility-override
.
Nous ne recommandons pas d’inclure l’énoncé facility-override
au niveau de la [edit system syslog host other-routing-engine]
hiérarchie. Il n’est pas nécessaire d’utiliser d’autres noms d’installation pour diriger les messages vers l’autre moteur de routage, car son utilitaire de journalisation du système Junos OS peut interpréter les noms spécifiques à Junos OS.
L’exemple suivant montre comment consigner tous les messages générés sur le routeur local au niveau d’erreur ou supérieur à l’installation locale0 sur la machine distante appelée monitor.mycompany.com :
[edit system syslog] host monitor.mycompany.com { any error; facility-override local0; }
L’exemple suivant montre comment configurer des routeurs situés en Californie et des routeurs situés à New York pour envoyer des messages à une seule machine distante appelée central-logger.mycompany.com. Les messages de Californie sont assignés à un autre établissement local0 et les messages de New York sont assignés à un autre établissement local2.
Configurez les routeurs californiens pour agréger les messages dans l’installation locale0 :
[edit system syslog] host central-logger.mycompany.com { change-log info; facility-override local0; }
Configurez les routeurs new-yorkais pour agréger les messages dans l’installation local2 :
[edit system syslog] host central-logger.mycompany.com { change-log info; facility-override local2; }
Sur l’enregistreur central, vous pouvez ensuite configurer l’utilitaire de journalisation du système pour écrire des messages de l’installation local0 vers le fichier change-log et les messages de l’installation local2 vers le fichier new-york-config.
Installations par défaut pour les messages de journal système dirigés vers une destination distante
Tableau 3 répertorie le nom de l’autre installation par défaut à côté du nom de l’installation spécifique à Junos OS pour laquelle il est utilisé. Pour les installations qui ne sont pas répertoriées, le nom alternatif par défaut est le même que le nom de l’installation locale.
Installation locale spécifique à Junos OS |
Installation par défaut lorsqu’elle est dirigée vers une destination distante |
---|---|
journal des modifications |
local6 |
journal des conflits |
local5 |
dfc |
local1 |
pare-feu |
local3 |
commandes interactives |
local7 |
Pfe |
local4 |
Autres installations pour les messages de journal du système dirigés vers une destination distante
Tableau 4 répertorie les installations que vous pouvez spécifier dans l’énoncé facility-override
.
Site |
Description |
---|---|
|
Tentatives d’authentification et d’autorisation |
|
Actions effectuées ou erreurs rencontrées par les processus système |
|
Actions effectuées ou erreurs rencontrées par le processus FTP |
|
Actions exécutées ou erreurs rencontrées par le noyau Junos OS |
|
Installation locale numéro 0 |
|
Installation locale numéro 1 |
|
Installation locale numéro 2 |
|
Installation locale numéro 3 |
|
Installation locale numéro 4 |
|
Installation locale numéro 5 |
|
Installation locale numéro 6 |
|
Installation locale numéro 7 |
|
Actions effectuées ou erreurs rencontrées par les processus d’espace utilisateur |
Nous ne recommandons pas d’inclure l’énoncé facility-override
au niveau de la [edit system syslog host other-routing-engine]
hiérarchie. Il n’est pas nécessaire d’utiliser d’autres noms d’installation pour diriger les messages vers l’autre moteur de routage, car son utilitaire de journalisation du système Junos OS peut interpréter les noms spécifiques à Junos OS.
Exemples: Attribution d’une autre installation aux messages du journal système dirigés vers une destination distante
Consignez tous les messages générés sur la plate-forme de routage locale au niveau d’erreur ou supérieur à l’installation local0
sur la machine distante appelée monitor.mycompany.com
:
[edit system syslog] host monitor.mycompany.com { any error; facility-override local0; }
Configurez les plates-formes de routage situées en Californie et les plates-formes de routage situées à New York pour envoyer des messages à une seule machine distante appelée central-logger.mycompany.com. Les messages de Californie se voient attribuer un autre établissement local0 et les messages de New York sont assignés à un autre établissement local2.
Configurez les plates-formes de routage californiennes pour agréger les messages dans l’installation
local0
:[edit system syslog] host central-logger.mycompany.com { change-log info; facility-override local0; }
Configurez des plates-formes de routage new-yorkaises pour agréger les messages dans l’installation
local2
:[edit system syslog] host central-logger.mycompany.com { change-log info; facility-override local2; }
Sur central-logger,
vous pouvez ensuite configurer l’utilitaire de journalisation du système pour écrire des messages de l’installation local0
au fichier california-config et les messages de l’installation local2
au fichier new-york-config.
Diriger les messages vers une destination distante à partir de la matrice de routage basée sur le routeur TX Matrix
Vous pouvez configurer une matrice de routage composée d’un routeur TX Matrix et de routeurs T640 pour diriger les messages de journalisation du système vers une machine distante ou l’autre moteur de routage sur chaque routeur, comme sur un système à châssis unique. Incluez l’énoncé host
au niveau hiérarchique [edit system syslog]
sur le routeur 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;
Le routeur TX Matrix dirige les messages vers une machine distante ou un autre moteur de routage de la même manière qu’un système à châssis unique, et les déclarations facultatives (explicit-priority
, facility-override
, log-prefix
, match
et source-address
) ont également le même effet que sur un système à châssis unique.
Pour que le routeur TX Matrix inclue des informations de priorité lorsqu’il dirige les messages provenant d’un routeur T640 vers la destination distante, vous devez également inclure l’instruction explicit-priority
au niveau de la [edit system syslog host scc-master]
hiérarchie.
L’instruction other-routing-engine
n’interagit pas avec le transfert des messages des routeurs T640 vers le routeur TX Matrix. Par exemple, si vous incluez l’instruction dans la configuration du moteur de routage dans l’emplacement 0 (re0
), le moteur de re0
routage de chaque routeur T640 envoie des messages au re1
moteur de routage sur sa plate-forme uniquement. Il n’envoie pas de messages directement au moteur de re1
routage du routeur TX Matrix.
Étant donné que la configuration du routeur TX Matrix s’applique aux routeurs T640, tout routeur T640 doté d’interfaces pour un accès direct à Internet dirige également des messages vers la machine distante. Les conséquences sont les suivantes :
Si les routeurs T640 sont configurés pour transmettre des messages au routeur TX Matrix (comme dans la configuration par défaut), la machine distante reçoit deux copies de certains messages : l’un directement depuis le routeur T640 et l’autre depuis le routeur TX Matrix. Les messages qui sont dupliqués dépendent si les gravités sont les mêmes pour la journalisation locale et pour les messages transférés. Pour plus d’informations, voir Configuration du transfert de messages vers le routeur TX Matrix.
Si l’instruction
source-address
est configurée au niveau de la[edit system syslog]
hiérarchie, tous les routeurs de la matrice de routage signalent la même adresse source dans les messages adressés à la machine distante. C’est approprié, car la matrice de routage fonctionne comme un routeur unique.Si l’instruction
log-prefix
est incluse, les messages de tous les routeurs de la matrice de routage comprennent la même chaîne de texte. Vous ne pouvez pas utiliser la chaîne pour distinguer les routeurs de la matrice de routage.
Diriger des messages vers une destination distante à partir de la matrice de routage basée sur un routeur TX Matrix Plus
Du point de vue de l’interface utilisateur, la matrice de routage apparaît comme un routeur unique. Le routeur TX Matrix Plus (également appelé châssis de structure de commutation SFC) contrôle tous les routeurs T1600 ou T4000 également appelés châssis ine-card LCC) dans la matrice de routage.
Vous pouvez configurer une matrice de routage composée d’un routeur TX Matrix Plus avec des LC T1600 ou T4000 connectés pour diriger les messages de journalisation du système vers une machine distante ou l’autre moteur de routage sur chaque routeur de routage, comme sur un système à châssis unique. Incluez l’énoncé host
au niveau de la [edit system syslog]
hiérarchie sur le 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;
Le routeur TX Matrix Plus dirige les messages vers une machine distante ou un autre moteur de routage de la même manière qu’un système à châssis unique, et les déclarations facultatives (explicit-priority
, facility-override
, log-prefix
, match
et source-address
) ont également le même effet que sur un système à châssis unique.
Pour que le routeur TX Matrix Plus inclue des informations de priorité lorsqu’il dirige des messages provenant d’un LCC T1600 ou T4000 connecté vers la destination distante, vous devez également inclure l’instruction explicit-priority
au niveau de la [edit system syslog host sfc0-master]
hiérarchie.
L’instruction other-routing-engine
n’interagit pas avec le transfert de messages des LC T1600 ou T4000 connectés vers le SFC. Par exemple, si vous incluez l’instruction dans la configuration du moteur de routage dans l’emplacement 0 (re0
), le moteur de re0
routage sur chaque T1600 ou T4000 connecté LCC envoie des messages au moteur de re1
routage sur son routeur uniquement. Il n’envoie pas de messages directement au moteur de re1
routage du SFC.
Étant donné que la configuration du SFC s’applique aux LC T1600 ou T4000 connectés, toute LCC qui dispose d’interfaces pour un accès direct à Internet dirige également les messages vers la machine distante. Les conséquences sont les suivantes :
Si les LPC sont configurés pour transmettre des messages au SFC (comme dans la configuration par défaut), la machine distante reçoit deux copies de certains messages : l’un directement depuis le T1600 ou le T4000 LCC et l’autre depuis le SFC. Les messages qui sont dupliqués dépendent si les gravités sont les mêmes pour la journalisation locale et pour les messages transférés. Pour plus d’informations, voir Configuration du transfert de messages vers le routeur TX Matrix Plus.
Si l’instruction
source-address
est configurée au niveau de la[edit system syslog]
hiérarchie, tous les routeurs de la matrice de routage signalent la même adresse source dans les messages adressés à la machine distante. C’est approprié, car la matrice de routage fonctionne comme un routeur de routage unique.Si l’instruction
log-prefix
est incluse, les messages de tous les routeurs de la matrice de routage comprennent la même chaîne de texte. Vous ne pouvez pas utiliser la chaîne pour distinguer les routeurs de la matrice de routage.