Sur cette page
Spécifiez l’installation et la gravité des messages à inclure dans le journal
Diriger les messages du journal système vers un fichier journal
Diriger les messages du journal système vers un terminal utilisateur
Diriger les messages du journal système vers une machine distante ou l’autre moteur de routage
Ajout d’une chaîne de texte aux messages du journal système dirigés vers une destination distante
Fonctions par défaut pour les messages du journal système dirigés vers une destination distante
Autres fonctions pour les messages du journal système dirigés vers une destination distante
Diriger les messages du journal système vers une destination distante
Spécifiez l’installation et la gravité des messages à inclure dans le journal
Chaque message du journal système appartient à une fonctionnalité, qui regroupe les messages qui sont générés par la même source (tel qu’un processus logiciel) ou qui concernent une condition ou une activité similaire (telle que les tentatives d’authentification). Un niveau de gravité est également attribué à chaque message, qui indique la gravité de l’impact de l’événement déclencheur sur les fonctions de la plate-forme de routage.
Lorsque vous configurez la journalisation d’une ressource et d’une destination, vous spécifiez un niveau de gravité pour chaque installation. Les messages de l’installation qui sont classés à ce niveau et à un niveau supérieur sont consigné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 aux sections 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 ressources vers une destination particulière, spécifiez chaque ressource et la gravité associée sous la forme d’une instruction distincte dans l’ensemble d’instructions de la destination.
Tableau 1 répertorie les fonctions de journalisation système de Junos OS que vous pouvez spécifier dans les instructions de configuration au niveau hiérarchique [edit system syslog]
.
Installation |
Type d’événement ou d’erreur |
---|---|
|
Tous (messages de tous les établissements) |
|
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 du système |
|
Événements liés à la capture de flux dynamique |
|
Inclure la priorité et la facilité dans les messages du journal système |
|
Actions effectuées ou erreurs rencontrées par les applications externes locales |
|
Actions de filtrage de 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) de Junos OS ou par une application cliente telle qu’un protocole Junos XML ou un client XML NETCONF |
|
Actions effectuées ou erreurs rencontrées par le noyau Junos OS |
|
Actions effectuées ou erreurs rencontrées par les processus Network Time Protocol |
|
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 de l’espace utilisateur |
Tableau 2 Répertorie les niveaux de gravité que vous pouvez spécifier dans les instructions de configuration au niveau de la [edit system syslog]
hiérarchie. Les niveaux de jusqu’à la plus grande gravité (effet le emergency
plus important sur le fonctionnement) à la plus info
faible.
Contrairement aux autres niveaux de gravité, le niveau désactive la journalisation d’une ressource au lieu d’indiquer la none
gravité de l’impact d’un événement déclencheur sur les fonctions de routage. Pour plus d’informations, reportez-vous à la section Désactivation de la journalisation système d’une installation.
Valeur |
Niveau de gravité |
Description |
---|---|---|
N/A |
|
Désactive la journalisation de la ressource associée vers une destination |
0 |
|
Panique du système ou autre condition provoquant l’arrêt du routeur de fonctionner |
1 |
|
Conditions nécessitant une correction immédiate, comme une base de données système corrompue |
2 |
|
Conditions critiques, telles que les erreurs matérielles |
3 |
|
Des conditions d’erreur qui ont généralement des conséquences moins graves que les erreurs aux niveaux d’urgence, d’alerte et critique |
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 de non-erreur d’intérêt |
7 |
|
Comprend tous les niveaux de gravité |
Diriger les messages du journal système vers un fichier journal
Pour diriger les messages du journal système vers un fichier dans le /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é, reportez-vous à la section 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 système Junos OS écrit par défaut les 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, reportez-vous à la section Spécification de la taille, du nombre et des propriétés d’archivage du fichier journal.
Pour plus d’informations sur les déclarations suivantes, reportez-vous aux sections indiquées :
explicit-priority
: reportez-vous à la section Inclusion d’informations de priorité dans les messages du journal systèmematch
: voir Utilisation de chaînes et d’expressions régulières pour affiner l’ensemble des messages consignésstructured-data
: reportez-vous à la section Consignation des messages au format de données structurées
Diriger les messages du journal système vers un terminal utilisateur
Pour diriger les messages du journal système vers la session de terminal d’un ou de plusieurs utilisateurs spécifiques (ou de tous les utilisateurs) lorsqu’ils sont connectés au moteur de routage local, incluez l’instruction au user
niveau hiérarchique [edit system syslog]
:
[edit system syslog] user (username | *) { facility severity; match "regular-expression"; }
Spécifiez un ou plusieurs noms d’utilisateur Junos OS, en séparant les 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 fonctionnalités de journalisation et des niveaux de gravité, reportez-vous à la section Spécification de la fonction et de la gravité des messages à inclure dans le journal. Pour plus d’informations sur l’instruction, consultez Utilisation de chaînes et d’expressions régulières pour affiner l’ensemblematch
des messages consignés.
Diriger les messages du journal système vers la console
Pour diriger les messages du journal système vers la console du moteur de routage local, incluez l’instruction console
au niveau de la [edit system syslog]
hiérarchie :
[edit system syslog] console { facility severity; }
Pour obtenir la liste des fonctionnalités de journalisation et des niveaux de gravité, reportez-vous à la section Spécification de la fonction et de la gravité des messages à inclure dans le journal.
Diriger les messages du journal système vers une machine distante ou l’autre moteur de routage
Pour diriger les messages du journal système vers une machine distante ou vers l’autre moteur de routage, 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; structured-data { brief; } } source-address source-address;
Pour diriger les messages du journal système vers une machine distante, incluez l’instruction spécifiant l’adresse IP version 4 (IPv4), l’adresse host
hostname 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 vous déconseillons de diriger les messages vers un autre équipement Juniper Networks. Dans chaque message du journal système adressé à la machine distante, le nom d’hôte du moteur de routage local apparaît après l’horodatage pour indiquer qu’il s’agit de la source du message.
Pour diriger les messages du journal système vers l’autre moteur de routage sur un périphérique sur lequel deux moteurs de routage sont installés et opérationnels, incluez l’instruction host other-routing-engine
. L’instruction n’étant pas automatiquement réciproque, vous devez l’inclure dans chaque configuration du moteur de routage si vous souhaitez que les moteurs de routage s’adressent les messages les uns aux 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 obtenir la liste des fonctionnalités de journalisation et des niveaux de gravité à configurer sous l’instruction host
, reportez-vous à la section Spécification de la fonction et de la gravité des messages à inclure dans le journal.
Pour enregistrer des informations sur l’installation et le niveau de gravité dans chaque message, incluez l’instruction explicit-priority
. Pour plus d’informations, reportez-vous à la section Inclusion d’informations de priorité dans les messages du journal système.
Pour plus d’informations sur l’instruction, consultez Utilisation de chaînes et d’expressions régulières pour affiner l’ensemblematch
des messages consignés.
Lorsque vous dirigez des messages vers des machines distantes, vous pouvez inclure l’instruction pour spécifier l’adresse source-address
IP du périphérique signalé dans les messages comme source. Dans chaque instruction, incluez l’instruction d’affectation d’une autre fonctionnalité et l’instruction log-prefix
d’ajout d’une facility-override
chaîne à chaque host
message. Vous pouvez inclure l’instruction permettant d’activer structured-data
le transfert de messages de journal système structurés à un serveur de journal système distant au format de message de journal système IETF .
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 du journal 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 indiquée dans les messages destinés à toutes les machines distantes spécifiées dans les instructions au niveau de la hiérarchie, mais pas dans host hostname
les [edit system syslog]
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 vers l’autre moteur de routage, incluez l’instruction au log-prefix
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 des deux-points ( : ). Il ne peut pas non plus inclure le caractère d’espace ; Ne placez pas la chaîne entre guillemets ( » « ) dans le but d’y inclure des espaces.
L’utilitaire de journalisation système Junos OS ajoute automatiquement 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’identificateur 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 la hardware-logger.mycompany.com de journal système ressemble à ce qui suit :
Mar 9 17:33:23 origin1 M120: mgd[477]: UI_CMDLINE_READ_LINE: user ‘root’, command ‘run show version’
Modification de l’autre nom de l’installation pour les messages de journal système dirigés vers une destination distante
Certaines fonctions affectées aux messages consignés sur le routeur ou le commutateur local ont des noms spécifiques à Junos OS (voir Fonctions de journalisation du système Junos OS). Dans la configuration recommandée, une machine distante désignée au niveau hiérarchique 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 à [edit system syslog host hostname]
Junos OS. Pour permettre à l’utilitaire syslogd standard de gérer les messages de ces fonctions lorsque les messages sont dirigés vers une machine distante, un nom de ressource standard localX
est utilisé à la place du nom de ressource spécifique à Junos OS.
Fonctions par défaut pour les messages du journal système dirigés vers une destination distante répertorie le nom de la fonction alternative par défaut en regard du nom de la ressource spécifique à Junos OS pour laquelle 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 leur source (routeur ou commutateur Juniper Networks ou machine distante elle-même). Par exemple, les instructions 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’autre fonctionnalité par défaut de l’installation locale authorization
est également authorization
. Si l’utilitaire syslogd on monitor
est configuré pour écrire des messages appartenant à la fonctionnalité dans le fichier , le fichier /var/log/auth-attemptscontient les messages générés lorsque les authorization
utilisateurs se connectent à et les messages générés lorsque les utilisateurs se connectent à local-router
monitor
. Bien que le nom de la machine source apparaisse dans chaque message du journal système, le mélange de messages provenant de plusieurs machines peut rendre plus difficile l’analyse auth-attempts
du contenu du fichier.
Pour faciliter la séparation des messages de chaque source, vous pouvez affecter une autre fonction à tous les messages générés le local-router
lorsqu’ils sont dirigés vers monitor
. Vous pouvez ensuite configurer l’utilitaire syslogd pour monitor
qu’il écrive des messages avec la fonction alternative vers un fichier différent des messages générés sur monitor
lui-même.
Pour modifier la fonction utilisée pour tous les messages dirigés vers une machine distante, incluez l’instruction 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 judicieux de spécifier une autre fonction qui n’est pas déjà utilisée sur la machine distante, telle que l’une des localX
installations. Sur l’ordinateur distant, vous devez également configurer l’utilitaire syslogd pour qu’il gère 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’instruction facility-override
.
Nous vous déconseillons d’inclure l’instruction 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 de ressources pour diriger des 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 à la fonction local0 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 dans l’État de New York pour envoyer des messages à une seule machine distante appelée central-logger.mycompany.com. Les messages en provenance de Californie sont affectés à l’installation alternative local0 et les messages en provenance de New York sont affectés à l’installation alternative local2.
Configurez les routeurs californiens pour agréger les messages dans l’installation local0 :
[edit system syslog] host central-logger.mycompany.com { change-log info; facility-override local0; }
Configurez les routeurs New York 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 système pour qu’il écrive des messages de la fonction local0 dans le fichier et les messages de la fonction local2 dans le fichier change-lognew-york-config.
Fonctions par défaut pour les messages du journal système dirigés vers une destination distante
Tableau 3 répertorie le nom de la fonction alternative par défaut en regard du nom de la fonction 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’il est dirigé vers la destination distante |
---|---|
journal des modifications |
local6 |
journal des conflits |
local5 |
Le DFC |
local1 |
Pare-feu |
local3 |
commandes-interactives |
local7 |
Pfe |
local4 |
Autres fonctions pour les messages du journal système dirigés vers une destination distante
Tableau 4 Répertorie les fonctions que vous pouvez spécifier dans l’instruction facility-override
.
Installation |
Description |
---|---|
|
Tentatives d’authentification et d’autorisation |
|
Actions effectuées ou erreurs rencontrées par les processus du système |
|
Actions effectuées ou erreurs rencontrées par le processus FTP |
|
Actions effectuées ou erreurs rencontrées par le noyau Junos OS |
|
Numéro d’installation locale 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 de l’espace utilisateur |
Nous vous déconseillons d’inclure l’instruction 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 de ressources pour diriger des 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: Affectation d’une autre fonction aux messages du journal système dirigés vers une destination distante
Enregistrez 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 en provenance de Californie se voient attribuer la ressource alternative local0 et les messages de New York sont affectés à la ressource alternative 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 les plates-formes de routage de New York pour agréger les messages dans l’installation
local2
:[edit system syslog] host central-logger.mycompany.com { change-log info; facility-override local2; }
Vous central-logger,
pouvez ensuite configurer l’utilitaire de journalisation système pour qu’il écrive des messages de l’installation dans le fichier et les messages de l’installation local0
local2
dans le fichier california-confignew-york-config.
Messages directs vers une destination distante à partir de la matrice de routage basée sur le routeur de la matrice TX
Vous pouvez configurer une matrice de routage composée d’un routeur TX Matrix et de routeurs T640 pour diriger les messages de journalisation 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’instruction host
au niveau de la [edit system syslog]
hiérarchie 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 l’autre moteur de routage de la même manière qu’un système à châssis unique, et les instructions facultatives (explicit-priority
, , log-prefix
match
, facility-override
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 des 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 de 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 re0
moteur de routage de chaque routeur T640 envoie des messages au re1
moteur de routage sur sa plate-forme uniquement. Il n’envoie pas non plus de messages directement au re1
moteur de routage sur le routeur TX Matrix.
Étant donné que la configuration sur le routeur TX Matrix s’applique aux routeurs T640, tout routeur T640 doté d’interfaces d’accès direct à Internet dirige également les messages vers la machine distante. Les conséquences sont les suivantes :
Si les routeurs T640 sont configurés pour transférer des messages au routeur TX Matrix (comme dans la configuration par défaut), la machine distante reçoit deux copies de certains messages : l’une directement à partir du routeur T640 et l’autre à partir du routeur TX Matrix. Les messages dupliqués varient selon que les niveaux de gravité sont les mêmes pour la journalisation locale et pour les messages transférés. Pour plus d’informations, reportez-vous à la section Configuration du transfert de messages vers le routeur TX Matrix.
Si l’instruction
source-address
est configurée au niveau de la hiérarchie, tous les routeurs de la matrice de routage signalent la même adresse source dans les messages dirigés vers la[edit system syslog]
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 incluent la même chaîne de texte. Vous ne pouvez pas utiliser la chaîne pour distinguer les routeurs dans la matrice de routage.
Messages directs 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é châssis de carte ine LCC) dans la matrice de routage.
Vous pouvez configurer une matrice de routage composée d’un routeur TX Matrix Plus avec des LCC T1600 ou T4000 connectés pour diriger les messages de journalisation 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’instruction 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 l’autre moteur de routage de la même manière qu’un système à châssis unique, et les instructions facultatives (explicit-priority
, , , match
facility-override
log-prefix
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 message des LCC 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 re0
moteur de routage de chaque LCC T1600 ou T4000 connecté envoie des messages au re1
moteur de routage sur son routeur uniquement. Il n’envoie pas non plus de messages directement au re1
moteur de routage sur le SFC.
Étant donné que la configuration sur le SFC s’applique aux LCC T1600 ou T4000 connectés, tout LCC disposant d’interfaces d’accès direct à Internet dirige également les messages vers la machine distante. Les conséquences sont les suivantes :
Si les LCC sont configurés pour transférer des messages au SFC (comme dans la configuration par défaut), la machine distante reçoit deux copies de certains messages : l’un directement à partir du T1600 ou T4000 LCC et l’autre à partir du SFC. Les messages dupliqués varient selon que les niveaux de gravité sont les mêmes pour la journalisation locale et pour les messages transférés. Pour plus d’informations, reportez-vous à la section Configuration du transfert de messages vers le routeur TX Matrix Plus.
Si l’instruction
source-address
est configurée au niveau de la hiérarchie, tous les routeurs de la matrice de routage signalent la même adresse source dans les messages dirigés vers la[edit system syslog]
machine distante. Ceci 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 incluent la même chaîne de texte. Vous ne pouvez pas utiliser la chaîne pour distinguer les routeurs dans la matrice de routage.