Auf dieser Seite
Leiten von Systemprotokollmeldungen an einen Remote-Computer oder eine andere Routing-Engine
Leiten von Systemprotokollmeldungen an einen Remote-Computer
Hinzufügen einer Textzeichenfolge zu Systemprotokollmeldungen, die an ein Remoteziel gerichtet sind
Standardeinstellungen für Systemprotokollmeldungen, die an ein Remote-Ziel gerichtet werden
Alternative Einrichtungen für Systemprotokollmeldungen, die an ein Remote-Ziel gerichtet werden
Leiten von Nachrichten an ein Remote-Ziel aus der Routing-Matrix basierend auf dem TX Matrix-Router
Leiten von Systemprotokollmeldungen an ein Remote-Ziel
Festlegen der Möglichkeit und des Schweregrads von Nachrichten, die in das Protokoll aufgenommen werden sollen
Jede Systemprotokollnachricht gehört zu einer Einrichtung, die Nachrichten gruppiert, die entweder von derselben Quelle (z. B. einem Softwareprozess) generiert werden oder eine ähnliche Bedingung oder Aktivität betreffen (z. B. Authentifizierungsversuche). Jeder Nachricht wird außerdem ein Schweregrad zugewiesen, der angibt, wie ernst das auslösende Ereignis die Routing-Plattformfunktionen beeinflusst.
Wenn Sie die Protokollierung für eine Einrichtung und ein Ziel konfigurieren, geben Sie für jede Einrichtung einen Schweregrad an. Nachrichten von der Einrichtung, die auf dieser Ebene und höher bewertet werden, werden an das folgende Ziel protokolliert:
[edit system syslog] (console | file filename | host destination | user username) { facility severity ; }
Weitere Informationen zu den Zielen finden Sie unter Leiten von Systemprotokollmeldungen an ein Benutzerterminal und Leiten von Systemprotokollmeldungen an die Konsole.
Um Meldungen zu mehreren Einrichtungen an einem bestimmten Ziel zu protokollieren, geben Sie jede Einrichtung und den zugehörigen Schweregrad als separate Anweisung innerhalb der Anweisungen für das Ziel an.
Tabelle 1 listet die Junos OS-Systemprotokollierungsfunktionen auf, die Sie in Konfigurationsanweisungen auf [edit system syslog]
Hierarchieebene angeben können.
Anlage |
Art des Ereignisses oder Fehlers |
---|---|
|
Alle (Nachrichten von allen Einrichtungen) |
|
Authentifizierungs- und Autorisierungsversuche |
|
Änderungen an der Junos OS-Konfiguration |
|
Die angegebene Konfiguration ist für den Routertyp ungültig |
|
Durchgeführte Aktionen oder Fehler bei Systemprozessen |
|
Ereignisse im Zusammenhang mit dynamischer Datenstromerfassung |
|
Berücksichtigen Sie Priorität und Einrichtung in Systemprotokollmeldungen |
|
Durchgeführte Aktionen oder Fehler, auf die die lokalen externen Anwendungen stoßen |
|
Paketfilterungsaktionen, die von einem Firewall-Filter durchgeführt werden |
|
Ausgeführte Aktionen oder Fehler beim FTP-Prozess |
|
Befehle, die an der Befehlszeilenschnittstelle (CLI)-Eingabeaufforderung von Junos OS oder von einer Clientanwendung wie einem Junos XML-Protokoll oder einem NETCONF XML-Client ausgegeben werden |
|
Durchgeführte Aktionen oder Fehler, auf die der Junos OS-Kernel stößt |
|
Durchgeführte Aktionen oder Fehler bei den Prozessen des Network Time Protocol |
|
Durchgeführte Aktionen oder Fehler bei der Packet Forwarding Engine |
|
Sicherheitsrelevante Ereignisse oder Fehler |
|
Durchgeführte Aktionen oder Fehler bei Prozessen im Benutzerbereich |
Tabelle 2 listet die Schweregraden auf, die Sie in Konfigurationsanweisungen auf [edit system syslog]
Hierarchieebene angeben können. Die Werte von emergency
durch info
sind in der Reihenfolge von höchster Schweregrad (größter Einfluss auf die Funktion) bis zum niedrigsten.
Im Gegensatz zu den anderen Schweregraden deaktiviert die Ebene die none
Protokollierung einer Einrichtung, anstatt anzuzeigen, wie ernst ein auslösendes Ereignis Routing-Funktionen beeinflusst. Weitere Informationen finden Sie unter Deaktivieren der Systemprotokollierung einer Einrichtung.
Wert |
Schweregrad |
Beschreibung |
---|---|---|
- |
|
Deaktiviert die Protokollierung der zugehörigen Einrichtung an einem Ziel |
0 |
|
Systempanik oder ein anderer Zustand, der dazu führt, dass der Router nicht mehr funktioniert |
1 |
|
Bedingungen, die sofortige Korrektur erfordern, wie z. B. eine beschädigte Systemdatenbank |
2 |
|
Kritische Bedingungen, wie z. B. harte Fehler |
3 |
|
Fehlerzustände, die im Allgemeinen weniger schwerwiegende Folgen haben als Fehler auf der Notfall-, Alarm- und kritischen Ebene |
4 |
|
Bedingungen, die eine Überwachung rechtfertigen |
5 |
|
Bedingungen, die keine Fehler sind, aber eine besondere Handhabung rechtfertigen können |
6 |
|
Ereignisse oder Nicht-Terrorbedingungen von Interesse |
7 |
|
Umfasst alle Schweregraden |
Leiten von Systemprotokollmeldungen in eine Protokolldatei
Um Systemprotokollnachrichten an eine Datei im Verzeichnis der /var/log lokalen Routing-Engine zu leiten, fügen Sie die file
Anweisung auf [edit system syslog]
Hierarchieebene ein:
[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; } }
Eine Liste der Einrichtungen und Schweregraden finden Sie unter Festlegen der Einrichtung und des Schweregrads von Meldungen, die in das Protokoll einbezogen werden sollen.
Um zu verhindern, dass Protokolldateien zu groß werden, schreibt das Junos OS-Dienstprogramm für die Systemprotokollierung standardmäßig Meldungen in eine Abfolge von Dateien einer definierten Größe. Indem Sie die archive
Anweisung angeben, können Sie die Anzahl der Dateien und ihre maximale Größe konfigurieren, und wer sie lesen kann, entweder für alle Protokolldateien oder für eine bestimmte Protokolldatei. Weitere Informationen finden Sie unter Festlegen von Größe, Anzahl und Archivierungseigenschaften der Protokolldatei.
Informationen zu den folgenden Aussagen finden Sie in den angegebenen Abschnitten:
explicit-priority
— Siehe Auch Prioritätsinformationen in Systemprotokollmeldungenmatch
— Siehe Verwenden von Zeichenfolgen und regulären Ausdrücken zum Verfeinern der Gruppe der protokollierten Nachrichtenstructured-data
— Siehe Protokollierung von Nachrichten im Format strukturierte Daten
Leiten von Systemprotokollmeldungen an ein Benutzerterminal
Um Systemprotokollnachrichten an die Terminalsitzung eines oder mehrerer spezifischer Benutzer (oder aller Benutzer) zu leiten, wenn diese bei der lokalen Routing-Engine angemeldet sind, fügen Sie die user
Anweisung auf [edit system syslog]
Hierarchieebene ein:
[edit system syslog] user (username | *) { facility severity; match "regular-expression"; }
Geben Sie einen oder mehrere Junos OS-Benutzernamen an, indem Sie mehrere Werte durch Leerzeichen trennen, oder verwenden Sie das Sternchen (*
), um alle Benutzer anzugeben, die bei der lokalen Routing-Engine angemeldet sind.
Eine Liste der Protokollierungsfunktionen und Schweregradstufen finden Sie unter Festlegen der Einrichtung und des Schweregrads von Nachrichten, die in das Protokoll einbezogen werden sollen. Informationen zur match
Anweisung finden Sie unter Verwenden von Zeichenfolgen und regulären Ausdrücken zum Verfeinern der Gruppe der protokollierten Nachrichten.
Leiten von Systemprotokollmeldungen an die Konsole
Um Systemprotokollmeldungen an die Konsole der lokalen Routing-Engine zu leiten, fügen Sie die console
Anweisung auf [edit system syslog]
Hierarchieebene ein:
[edit system syslog] console { facility severity; }
Eine Liste der Protokollierungsfunktionen und Schweregradstufen finden Sie unter Festlegen der Einrichtung und des Schweregrads von Nachrichten, die in das Protokoll einbezogen werden sollen.
Leiten von Systemprotokollmeldungen an einen Remote-Computer oder eine andere Routing-Engine
Um Systemprotokollmeldungen an einen Remotecomputer oder an die andere Routing-Engine auf dem Router zu leiten, fügen Sie die host
Anweisung auf Hierarchieebene [edit system syslog]
ein:
[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;
Um Systemprotokollnachrichten an einen Remotecomputer zu leiten, fügen Sie die Anweisung ein, um die host
hostname IP-Version 4 (IPv4)-Adresse des Remotecomputers, die IP-Version 6 (IPv6)-Adresse oder den voll qualifizierten Hostnamen anzugeben. Auf dem Remote-Computer muss das Standard-Dienstprogramm syslogd
ausgeführt werden. Wir empfehlen nicht, Nachrichten an einen anderen Router von Juniper Networks zu leiten. In jeder an den Remote-Computer gerichteten Systemprotokollnachricht wird nach dem Zeitstempel der Hostname der lokalen Routing-Engine angezeigt, um anzugeben, dass es sich um die Quelle für die Nachricht handelt.
Um Systemprotokollnachrichten an die andere Routing-Engine auf einem Router mit zwei installierten und betriebsbereiten Routing-Engines zu leiten, fügen Sie die Anweisung ein host other-routing-engine
. Die Anweisung ist nicht automatisch wechselseitig, daher müssen Sie sie in jede Routing-Engine-Konfiguration aufnehmen, wenn die Routing-Engines Nachrichten aneinander weiterleiten sollen. In jeder an die andere Routing-Engine gerichteten Nachricht wird die Zeichenfolge re0
oder re1
nach dem Zeitstempel angezeigt, um die Quelle für die Nachricht anzugeben.
Fügen Sie die explicit-priority
Anweisung hinzu, um Informationen zu Einrichtung und Schweregrad in jeder Nachricht aufzuzeichnen. Weitere Informationen finden Sie unter Prioritätsinformationen in Systemprotokollmeldungen.
Informationen zur match
Anweisung finden Sie unter Verwenden von Zeichenfolgen und regulären Ausdrücken zum Verfeinern der Gruppe der protokollierten Nachrichten.
Wenn Sie Nachrichten an Remote-Maschinen leiten, können Sie die source-address
Anweisung angeben, um die IP-Adresse des Routers anzugeben, der in den Nachrichten als Quelle gemeldet wird. Fügen Sie in jeder host
Anweisung die facility-override
Anweisung zum Zuweisen einer alternativen Einrichtung ein, und die log-prefix
Anweisung, um jeder Nachricht eine Zeichenfolge hinzuzufügen. Sie können die structured-data
Anweisung einschließen, um die Weiterleitung strukturierter Systemprotokollmeldungen an einen entfernten Systemprotokollserver im IETF-Systemprotokollmeldungsformat zu ermöglichen.
Leiten von Systemprotokollmeldungen an einen Remote-Computer
Um Systemprotokollmeldungen an einen Remotecomputer zu leiten, fügen Sie die host
Anweisung auf [edit system syslog]
Hierarchieebene ein:
[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;
Um Systemprotokollnachrichten an einen Remote-Computer zu leiten, fügen Sie die host hostname
Anweisung ein, um die IP-Version 4 (IPv4)-Adresse des Remotecomputers oder den voll qualifizierten Hostnamen anzugeben. Auf dem Remote-Computer muss das Standard-Dienstprogramm syslogd
ausgeführt werden. Wir empfehlen nicht, Nachrichten an einen anderen Switch von Juniper Networks zu leiten. In jeder an den Remote-Computer gerichteten Systemprotokollnachricht wird nach dem Zeitstempel der Hostname der lokalen Routing-Engine angezeigt, um anzugeben, dass es sich um die Quelle für die Nachricht handelt.
Eine Liste der Protokollierungsfunktionen und Schweregradstufen, die unter der host
Anweisung konfiguriert werden sollen, finden Sie unter Festlegen der Einrichtung und des Schweregrads von Nachrichten, die in das Protokoll einbezogen werden sollen.
Fügen Sie die explicit-priority
Anweisung hinzu, um Informationen zu Einrichtung und Schweregrad in jeder Nachricht aufzuzeichnen. Weitere Informationen finden Sie unter Prioritätsinformationen in Systemprotokollmeldungen.
Informationen zur match
Anweisung finden Sie unter Verwenden von Zeichenfolgen und regulären Ausdrücken zum Verfeinern der Gruppe der protokollierten Nachrichten.
Wenn Sie Nachrichten an Remotecomputer leiten, können Sie die source-address
Anweisung angeben, um die IP-Adresse des Switches anzugeben, der in den Nachrichten als Quelle gemeldet wird. In jede host
Anweisung können Sie auch die facility-override
Anweisung zum Zuweisen einer alternativen Funktion und die log-prefix
Anweisung zum Hinzufügen einer Zeichenfolge zu jeder Nachricht hinzufügen.
Angeben einer alternativen Quelladresse für Systemprotokollmeldungen, die an ein Remoteziel gerichtet werden
Um den Quellrouter anzugeben, der in Systemprotokollmeldungen gemeldet werden soll, wenn die Nachrichten an einen Remotecomputer geleitet werden, fügen Sie die source-address
Anweisung auf Hierarchieebene [edit system syslog]
ein:
[edit system syslog] source-address source-address;
source-address
ist eine gültige IPv4- oder IPv6-Adresse , die auf einer der Routerschnittstellen konfiguriert ist. Die Adresse wird in den Nachrichten an alle Remote-Maschinen gemeldet, die [edit system syslog]
in host hostname
Anweisungen auf Hierarchieebene angegeben sind, nicht aber in Nachrichten, die an die andere Routing-Engine geleitet werden.
Hinzufügen einer Textzeichenfolge zu Systemprotokollmeldungen, die an ein Remoteziel gerichtet sind
Um jede Systemprotokollnachricht, die an einen Remotecomputer oder an die andere Routing-Engine gerichtet wird, eine Textzeichenfolge hinzuzufügen, fügen Sie die log-prefix
Anweisung auf Hierarchieebene [edit system syslog host]
ein:
[edit system syslog host (hostname | other-routing-engine)] facility severity; log-prefix string;
Die Zeichenfolge kann jedes alphanumerische oder Sonderzeichen mit Ausnahme des Gleichheitszeichens ( = ) und des Doppelpunkts ( : ) enthalten. Es kann auch das Leerzeichen nicht enthalten; schließen Sie die Zeichenfolge nicht in Anführungszeichen ("") ein, um Leerzeichen einzuschließen.
Das Junos OS-Systemprotokollierungsprogramm fügt automatisch einen Doppelpunkt und ein Leerzeichen an die angegebene Zeichenfolge an, wenn die Systemprotokollnachrichten in das Protokoll geschrieben werden. Die Zeichenfolge wird nach dem Bezeichner für die Routing-Engine eingefügt, die die Nachricht generiert hat.
Das folgende Beispiel zeigt, wie Sie die Zeichenfolgen-M120 allen Nachrichten hinzufügen, um anzugeben, dass es sich bei dem Router um einen M120-Router handelt, und die Nachrichten an den Remote-Computer hardware-logger.mycompany.com leiten:
[edit system syslog] host hardware-logger.mycompany.com { any info; log-prefix M120; }
Wenn diese Konfigurationsanweisungen auf einem M120-Router namens origin1 enthalten sind, sieht eine Meldung im Systemprotokoll auf hardware-logger.mycompany.com wie folgt aus:
Mar 9 17:33:23 origin1 M120: mgd[477]: UI_CMDLINE_READ_LINE: user ‘root’, command ‘run show version’
Ändern des alternativen Einrichtungsnamens für Systemprotokollmeldungen, die an ein Remoteziel gerichtet sind
Einige Einrichtungen, die Nachrichten zugewiesen sind, die am lokalen Router oder Switch protokolliert werden, haben Junos OS-spezifische Namen (siehe Junos OS Systemprotokollierungseinrichtungen). In der empfohlenen Konfiguration handelt es sich bei einer auf [edit system syslog host hostname]
Hierarchieebene angegebenen Remote-Maschine nicht um einen Router oder Switch von Juniper Networks, sodass sein syslogd-Dienstprogramm die Junos OS-spezifischen Namen nicht interpretieren kann. Damit das Standard-Syslogd-Dienstprogramm Nachrichten von diesen Einrichtungen verarbeitet, wenn Nachrichten an einen Remote-Computer geleitet werden, wird anstelle des Junos OS-spezifischen Einrichtungsnamens ein Standardeinrichtungsname localX
verwendet.
Standardeinstellungen für Systemprotokollmeldungen, die an ein Remoteziel gerichtet werden, listet neben dem Junos OS-spezifischen Facility-Namen den Standardalternativennamen auf, für den er verwendet wird.
Das Dienstprogramm syslogd auf einem Remote-Computer verarbeitet alle Nachrichten, die zu einer Einrichtung gehören, auf dieselbe Weise, unabhängig von der Quelle der Nachricht (der Router oder Switch von Juniper Networks oder die Remote-Maschine selbst). Die folgenden Anweisungen in der Konfiguration des Routers, die als Direkte Nachrichten von der Einrichtung an den authorization
Remote-Computer bezeichnet local-router
werden, monitor.mycompany.com beispielsweise:
[edit system syslog] host monitor.mycompany.com { authorization info; }
Die Standardalternative für die lokale authorization
Einrichtung ist auch authorization
. Wenn das Dienstprogramm syslogd für monitor
das Schreiben von Nachrichten konfiguriert ist, die zur authorization
Einrichtung gehören, in die Datei /var/log/auth-attempts, enthält die Datei die Nachrichten, die beim Anmelden local-router
von Benutzern generiert werden, und die Nachrichten, die beim Anmelden monitor
von Benutzern bei . Obwohl der Name des Quellcomputers in jeder Systemprotokollnachricht erscheint, kann das Mischen von Nachrichten von mehreren Maschinen die Analyse des Inhalts der auth-attempts
Datei erschweren.
Um die Nachrichten von jeder Quelle zu trennen, können Sie allen Nachrichten, die generiert werden local-router
, an monitor
eine andere Option zuweisen. Sie können dann das Dienstprogramm monitor
syslogd so konfigurieren, dass Nachrichten mit der alternativen Einrichtung zu einer anderen Datei geschrieben werden als nachrichten, die auf monitor
sich selbst generiert werden.
Um die Funktion zu ändern, die für alle Nachrichten verwendet wird, die an einen Remote-Computer weitergeleitet werden, fügen Sie die facility-override
Anweisung auf Hierarchieebene [edit system syslog host hostname]
ein:
[edit system syslog host hostname] facility severity; facility-override facility;
Im Allgemeinen ist es sinnvoll, eine alternative Einrichtung anzugeben, die noch nicht auf dem Remote-Computer verwendet wird, z. B. eine der localX
Einrichtungen. Auf dem Remote-Computer müssen Sie auch das Dienstprogramm syslogd konfigurieren, um die Nachrichten in der gewünschten Weise zu behandeln.
Die Einrichtungen für die Facility-Override Statement listet die Einrichtungen auf, die Sie in der facility-override
Anweisung angeben können.
Wir empfehlen nicht, die facility-override
Anweisung auf [edit system syslog host other-routing-engine]
Hierarchieebene einzuordnen. Beim Leiten von Nachrichten an die andere Routing-Engine ist es nicht notwendig, alternative Gerätenamen zu verwenden, da das Junos OS-Systemprotokollierungsprogramm die Junos OS-spezifischen Namen interpretieren kann.
Das folgende Beispiel zeigt, wie alle nachrichten, die auf dem lokalen Router generiert werden, auf der Fehlerebene oder höher an die local0-Einrichtung auf dem Remote-Computer namens monitor.mycompany.com protokolliert werden:
[edit system syslog] host monitor.mycompany.com { any error; facility-override local0; }
Das folgende Beispiel zeigt, wie Sie Router in Kalifornien und Router in New York konfigurieren, um Nachrichten an einen einzelnen Remote-Computer namens central-logger.mycompany.com zu senden. Die Nachrichten aus Kalifornien werden alternative Facility local0 und die Nachrichten aus New York der Alternative Facility local 2 zugewiesen.
Konfigurieren Sie kalifornische Router, um Nachrichten in der lokalen0-Einrichtung zu aggregieren:
[edit system syslog] host central-logger.mycompany.com { change-log info; facility-override local0; }
Konfigurieren Sie New York-Router, um Nachrichten in der lokalen2-Einrichtung zu aggregieren:
[edit system syslog] host central-logger.mycompany.com { change-log info; facility-override local2; }
Auf dem Central-Logger können Sie dann das Dienstprogramm zur Systemprotokollierung konfigurieren, um Nachrichten von der lokalen0-Einrichtung in die Datei change-log und die Nachrichten von der lokalen2-Einrichtung in die Datei new-york-configzu schreiben.
Standardeinstellungen für Systemprotokollmeldungen, die an ein Remote-Ziel gerichtet werden
Tabelle 3 listet den Standardalternativen Facility-Namen neben dem Junos OS-spezifischen Facility-Namen auf, für den er verwendet wird. Für Einrichtungen, die nicht aufgeführt sind, ist der alternative Standardname derselbe wie der Name der lokalen Einrichtung.
Junos OS –Spezifische lokale Einrichtung |
Standardeinrichtung, wenn sie an ein Remote-Ziel geleitet wird |
---|---|
Änderungsprotokoll |
local6 |
Konfliktprotokoll |
local5 |
Dfc |
local1 |
Firewall |
local3 |
interaktive Befehle |
local7 |
Pfe |
local4 |
Alternative Einrichtungen für Systemprotokollmeldungen, die an ein Remote-Ziel gerichtet werden
Tabelle 4 listet die Einrichtungen auf, die Sie in der facility-override
Anweisung angeben können.
Anlage |
Beschreibung |
---|---|
|
Authentifizierungs- und Autorisierungsversuche |
|
Durchgeführte Aktionen oder Fehler bei Systemprozessen |
|
Ausgeführte Aktionen oder Fehler beim FTP-Prozess |
|
Durchgeführte Aktionen oder Fehler, auf die der Junos OS-Kernel stößt |
|
Lokale Einrichtung Nummer 0 |
|
Lokale Einrichtung Nr. 1 |
|
Lokale Einrichtung Nr. 2 |
|
Lokale Einrichtung Nr. 3 |
|
Lokale Einrichtung Nr. 4 |
|
Lokale Einrichtung Nr. 5 |
|
Lokale Einrichtung Nr. 6 |
|
Lokale Einrichtung Nr. 7 |
|
Durchgeführte Aktionen oder Fehler bei Prozessen im Benutzerbereich |
Wir empfehlen nicht, die facility-override
Anweisung auf [edit system syslog host other-routing-engine]
Hierarchieebene einzuordnen. Beim Leiten von Nachrichten an die andere Routing-Engine ist es nicht notwendig, alternative Gerätenamen zu verwenden, da das Junos OS-Systemprotokollierungsprogramm die Junos OS-spezifischen Namen interpretieren kann.
Beispiele: Zuweisen einer alternativen Einrichtung zu Systemprotokollmeldungen, die an ein Remote-Ziel gerichtet sind
Protokollieren Sie alle Nachrichten, die auf der lokalen Routing-Plattform generiert werden, auf der Fehlerebene oder höher, an die local0
Einrichtung auf dem Remote-Computer namens monitor.mycompany.com
:
[edit system syslog] host monitor.mycompany.com { any error; facility-override local0; }
Konfigurieren Sie Routing-Plattformen in Kalifornien und Routing-Plattformen in New York, um Nachrichten an einen einzigen Remote-Computer namens central-logger.mycompany.com zu senden. Den Nachrichten aus Kalifornien werden alternative Facility local0 und die Nachrichten aus New York alternative Facility local zugewiesen2.
Konfigurieren Sie kalifornische Routing-Plattformen, um Nachrichten in der
local0
Einrichtung zu aggregieren:[edit system syslog] host central-logger.mycompany.com { change-log info; facility-override local0; }
Konfigurieren Sie New York Routing-Plattformen, um Nachrichten in der
local2
Einrichtung zu aggregieren:[edit system syslog] host central-logger.mycompany.com { change-log info; facility-override local2; }
Anschließend central-logger,
können Sie das Dienstprogramm zur Systemprotokollierung so konfigurieren, dass Nachrichten von der local0
Einrichtung in die Datei california-config und nachrichten von der local2
Einrichtung in die Datei new-york-configgeschrieben werden.
Leiten von Nachrichten an ein Remote-Ziel aus der Routing-Matrix basierend auf dem TX Matrix-Router
Sie können eine Routing-Matrix konfigurieren, die aus einem TX-Matrix-Router und T640-Routern besteht, um Systemprotokollierungsmeldungen an einen Remote-Computer oder die andere Routing-Engine auf jedem Router zu leiten, genau wie in einem Single-Chassis-System. Fügen Sie die host
Anweisung auf der [edit system syslog]
Hierarchieebene des TX Matrix-Routers ein:
[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;
Der TX Matrix-Router leitet Nachrichten an einen Remote-Computer oder die andere Routing-Engine auf die gleiche Weise wie ein Single-Chassis-System, und die optionalen Anweisungen (explicit-priority
, facility-override
, log-prefix
, match
und source-address
) haben auch den gleichen Effekt wie auf ein Single-Chassis-System.
Damit der TX Matrix-Router Prioritätsinformationen enthält, wenn er Nachrichten, die von einem T640-Router stammen, an das Remote-Ziel leitet, müssen Sie die explicit-priority
Anweisung auch auf [edit system syslog host scc-master]
Hierarchieebene einschließen.
Die other-routing-engine
Anweisung interagiert nicht mit der Weiterleitung von Nachrichten von den T640-Routern zum TX Matrix-Router. Wenn Sie die Anweisung beispielsweise in die Konfiguration für die Routing-Engine in Steckplatz 0 () () aufnehmen,re0
sendet die re0
Routing-Engine an jedem T640-Router nur Nachrichten an die re1
Routing-Engine auf ihrer Plattform. Es sendet auch keine Nachrichten direkt an die re1
Routing-Engine des TX Matrix-Routers.
Da die Konfiguration des TX Matrix-Routers für die T640-Router gilt, leitet jeder T640-Router, der Schnittstellen für den direkten Internetzugriff hat, auch Nachrichten an den Remote-Computer. Die Folgen sind:
Wenn die T640-Router so konfiguriert sind, dass sie Nachrichten an den TX Matrix-Router weiterleiten (wie in der Standardkonfiguration), empfängt der Remote-Computer zwei Kopien einiger Nachrichten: eine direkt vom T640-Router und die andere vom TX Matrix-Router. Welche Nachrichten dupliziert werden, hängt davon ab, ob der Schweregrad für die lokale Protokollierung und für weitergeleitete Nachrichten gleich ist. Weitere Informationen finden Sie unter Konfigurieren der Nachrichtenweiterleitung an den TX-Matrix-Router.
Wenn die
source-address
Anweisung auf Hierarchieebene[edit system syslog]
konfiguriert ist, melden alle Router in der Routingmatrix dieselbe Quelladresse in Nachrichten, die an den Remotecomputer weitergeleitet werden. Dies ist angemessen, da die Routing-Matrix wie ein einzelner Router funktioniert.Wenn die
log-prefix
Anweisung enthalten ist, enthalten die Nachrichten von allen Routern in der Routing-Matrix dieselbe Textzeichenfolge. Sie können den String nicht verwenden, um zwischen den Routern in der Routing-Matrix zu unterscheiden.
Leiten von Nachrichten über die Routing-Matrix basierend auf einem TX Matrix Plus-Router an ein Remote-Ziel
Aus Sicht der Benutzeroberfläche wird die Routing-Matrix als einzelner Router angezeigt. Der TX Matrix Plus-Router (auch Switch-Fabric-Chassis SFC genannt) steuert alle T1600- oder T4000-Router, die auch als Ine-Card-Chassis LCC bezeichnet werden) in der Routing-Matrix.
Sie können eine Routing-Matrix konfigurieren, die aus einem TX Matrix Plus-Router mit angeschlossenen T1600- oder T4000-LCCs besteht, um Systemprotokollierungsmeldungen an einen Remote-Computer oder die andere Routing-Engine auf jedem Routing-Router zu leiten, genau wie in einem Single-Chassis-System. Fügen Sie die host
Anweisung auf der [edit system syslog]
Hierarchieebene der SFC ein:
[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;
Der TX Matrix Plus-Router leitet Nachrichten an einen Remote-Computer oder die andere Routing-Engine auf die gleiche Weise wie ein Single-Chassis-System, und die optionalen Anweisungen (explicit-priority
, facility-override
, log-prefix
, match
und source-address
) haben auch den gleichen Effekt wie auf ein Single-Chassis-System.
Damit der TX Matrix Plus-Router Prioritätsinformationen enthält, wenn er Nachrichten von einem angeschlossenen T1600- oder T4000-LCC an das Remote-Ziel leitet, müssen Sie die explicit-priority
Anweisung auch auf [edit system syslog host sfc0-master]
Hierarchieebene einschließen.
Die other-routing-engine
Anweisung interagiert nicht mit der Weiterleitung von Nachrichten von den angeschlossenen T1600- oder T4000-LCCs an die SFC. Wenn Sie die Anweisung beispielsweise in die Konfiguration für die Routing-Engine in Steckplatz 0 () () aufnehmen,re0
sendet die re0
Routing-Engine an jedem angeschlossenen T1600 oder T4000 LCC Nachrichten nur an die re1
Routing-Engine auf ihrem Router. Es sendet auch keine Nachrichten direkt an die re1
Routing-Engine in der SFC.
Da die Konfiguration auf der SFC für die angeschlossenen LCCs T1600 oder T4000 gilt, leitet jede LCC, die Schnittstellen für den direkten Zugriff auf das Internet hat, auch Nachrichten an den Remote-Computer. Die Folgen sind:
Wenn die LCCs so konfiguriert sind, dass nachrichten an die SFC weitergeleitet werden (wie in der Standardkonfiguration), empfängt der Remote-Computer zwei Kopien einiger Nachrichten: eine direkt vom T1600 oder T4000 LCC und die andere von der SFC. Welche Nachrichten dupliziert werden, hängt davon ab, ob der Schweregrad für die lokale Protokollierung und für weitergeleitete Nachrichten gleich ist. Weitere Informationen finden Sie unter Konfigurieren der Nachrichtenweiterleitung an den TX Matrix Plus-Router.
Wenn die
source-address
Anweisung auf Hierarchieebene[edit system syslog]
konfiguriert ist, melden alle Router in der Routingmatrix dieselbe Quelladresse in Nachrichten, die an den Remotecomputer weitergeleitet werden. Dies ist angemessen, da die Routing-Matrix als einzelner Routing-Router fungiert.Wenn die
log-prefix
Anweisung enthalten ist, enthalten die Nachrichten von allen Routern in der Routing-Matrix dieselbe Textzeichenfolge. Sie können den String nicht verwenden, um zwischen den Routern in der Routing-Matrix zu unterscheiden.