Auf dieser Seite
Systemprotokollmeldungen direkt an ein Benutzerterminal senden
Direkte Systemprotokollmeldungen an einen entfernten Computer oder eine andere Routing-Engine
Hinzufügen einer Textzeichenfolge zu Systemprotokollmeldungen, die an ein Remoteziel gerichtet sind
Standardfunktionen für Systemprotokollmeldungen, die an ein entferntes Ziel gerichtet sind
Alternative Funktionen für Systemprotokollmeldungen, die an ein entferntes Ziel gerichtet sind
Direktnachrichten an ein entferntes Ziel von der Routing-Matrix basierend auf dem TX-Matrix-Router
Systemprotokollmeldungen an ein entferntes Ziel weiterleiten
Geben Sie die Möglichkeit und den Schweregrad der Meldungen an, die in das Protokoll aufgenommen werden sollen
Jede Systemprotokollmeldung gehört zu einer Einrichtung, in der Meldungen zusammengefasst sind, die entweder von derselben Quelle generiert werden (z. B. ein Softwareprozess) oder sich auf eine ähnliche Bedingung oder Aktivität beziehen (z. B. Authentifizierungsversuche). Jeder Nachricht ist außerdem ein Schweregradzugewiesen, der angibt, wie stark sich das auslösende Ereignis auf die Funktionen der Routing-Plattform auswirkt.
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 Stufe oder höher eingestuft sind, werden an folgendem Ziel protokolliert:
[edit system syslog] (console | file filename | host destination | user username) { facility severity ; }
Weitere Informationen zu den Zielen finden Sie unter Weiterleiten von Systemprotokollmeldungen an ein Benutzerterminalund Weiterleiten von Systemprotokollmeldungen an die Konsole.
Um Meldungen, die zu mehr als einer Einrichtung gehören, an einem bestimmten Ziel zu protokollieren, geben Sie jede Einrichtung und den zugehörigen Schweregrad als separate Anweisung innerhalb des Anweisungssatzes für das Ziel an.
Tabelle 1 Listet die Junos OS-Systemprotokollierungsfunktionen auf, die Sie in Konfigurationsanweisungen auf Hierarchieebene [edit system syslog]
angeben können.
Leichtigkeit |
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 |
|
Ausgeführte Aktionen oder Fehler von Systemprozessen |
|
Ereignisse im Zusammenhang mit der dynamischen Datenstromerfassung |
|
Priorität und Funktion in Systemprotokollmeldungen aufnehmen |
|
Ausgeführte Aktionen oder Fehler, die von den lokalen externen Anwendungen aufgetreten sind |
|
Paketfilteraktionen, die von einem Firewallfilter ausgeführt werden |
|
Ausgeführte Aktionen oder Fehler des FTP-Prozesses |
|
Befehle, die an der Eingabeaufforderung der Junos OS-Befehlszeilenschnittstelle (CLI) oder von einer Clientanwendung wie einem Junos XML-Protokoll oder einem NETCONF-XML-Client ausgegeben werden |
|
Vom Junos OS-Kernel ausgeführte Aktionen oder Fehler |
|
Ausgeführte Aktionen oder Fehler, die bei den Network Time Protocol-Prozessen aufgetreten sind |
|
Von der Paketweiterleitungs-Engine ausgeführte Aktionen oder Fehler |
|
Ausgeführte Aktionen oder Fehler, die bei User-Space-Prozessen aufgetreten sind |
Tabelle 2 Listet die Schweregrade auf, die Sie in Konfigurationsanweisungen auf Hierarchieebene [edit system syslog]
angeben können. Die Stufen von emergency
bis info
sind in der Reihenfolge vom höchsten Schweregrad (größte Auswirkung auf die Funktion) bis zum niedrigsten.
Im Gegensatz zu den anderen Schweregraden deaktiviert die none
Stufe die Protokollierung einer Einrichtung, anstatt anzugeben, wie stark ein auslösendes Ereignis die Routing-Funktionen beeinträchtigt. Weitere Informationen finden Sie unter Deaktivieren der Systemprotokollierung einer Einrichtung.
Wert |
Schweregrad |
Beschreibung |
---|---|---|
N/A |
|
Deaktiviert die Protokollierung der zugeordneten Einrichtung an einem Ziel |
0 |
|
Systempanik oder andere Zustände, die dazu führen, dass der Router nicht mehr funktioniert |
1 |
|
Bedingungen, die eine sofortige Korrektur erfordern, z. B. eine beschädigte Systemdatenbank |
2 |
|
Kritische Bedingungen, wie z. B. schwerwiegende Fehler |
3 |
|
Fehlerzustände, die in der Regel weniger schwerwiegende Folgen haben als Fehler auf Notfall-, Alarm- und kritischer Ebene |
4 |
|
Bedingungen, die eine Überwachung rechtfertigen |
5 |
|
Bedingungen, bei denen es sich nicht um Fehler handelt, die jedoch eine besondere Behandlung rechtfertigen können |
6 |
|
Relevante Ereignisse oder fehlerfreie Bedingungen |
7 |
|
Umfasst alle Schweregrade |
Systemprotokollmeldungen in eine Protokolldatei leiten
Um Systemprotokollmeldungen an eine Datei im /var/log Verzeichnis der lokalen Routing-Engine zu leiten, fügen Sie die file
Anweisung auf Hierarchieebene [edit system syslog]
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 Schweregrade finden Sie unter Angeben der Einrichtung und des Schweregrads von Meldungen, die in das Protokoll aufgenommen werden sollen.
Um zu verhindern, dass Protokolldateien zu groß werden, schreibt das Junos OS-Systemprotokollierungsdienstprogramm Meldungen standardmäßig in eine Reihe von Dateien mit einer definierten Größe. Durch Einfügen der archive
Anweisung können Sie die Anzahl der Dateien, ihre maximale Größe und die Personen, die sie lesen können, entweder für alle Protokolldateien oder für eine bestimmte Protokolldatei konfigurieren. Weitere Informationen finden Sie unter Angeben von Größe, Anzahl und Archivierungseigenschaften der Protokolldatei.
Weitere Informationen zu den folgenden Anweisungen finden Sie in den angegebenen Abschnitten:
explicit-priority
—Siehe Einbinden von Prioritätsinformationen in Systemprotokollmeldungenmatch
– Siehe Verwenden von Zeichenfolgen und regulären Ausdrücken zum Verfeinern des Satzes protokollierter Nachrichtenstructured-data
—Siehe Protokollieren von Meldungen im Format mit strukturierten Daten
Systemprotokollmeldungen direkt an ein Benutzerterminal senden
Um Systemprotokollmeldungen an die Terminalsitzung eines oder mehrerer bestimmter Benutzer (oder aller Benutzer) zu leiten, wenn diese bei der lokalen Routing-Engine angemeldet sind, fügen Sie die user
Anweisung auf Hierarchieebene [edit system syslog]
ein:
[edit system syslog] user (username | *) { facility severity; match "regular-expression"; }
Geben Sie einen oder mehrere Junos OS-Benutzernamen an, trennen Sie mehrere Werte durch Leerzeichen, oder verwenden Sie das Sternchen (*
), um alle Benutzer anzugeben, die bei der lokalen Routing-Engine angemeldet sind.
Eine Liste der Protokollierungsfunktionen und Schweregrade finden Sie unter Angeben der Einrichtung und des Schweregrads von Meldungen, die in das Protokoll aufgenommen werden sollen. Weitere Informationen zur match
Anweisung finden Sie unter Verwenden von Zeichenfolgen und regulären Ausdrücken, um den Satz protokollierter Nachrichten zu verfeinern.
Systemprotokollmeldungen direkt an die Konsole senden
Um Systemprotokollmeldungen an die Konsole der lokalen Routing-Engine zu leiten, fügen Sie die console
Anweisung auf Hierarchieebene [edit system syslog]
ein:
[edit system syslog] console { facility severity; }
Eine Liste der Protokollierungsfunktionen und Schweregrade finden Sie unter Angeben der Einrichtung und des Schweregrads von Meldungen, die in das Protokoll aufgenommen werden sollen.
Direkte Systemprotokollmeldungen an einen entfernten Computer oder eine andere Routing-Engine
Um Systemprotokollmeldungen an einen entfernten Computer oder an die andere Routing-Engine weiterzuleiten, 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 Systemprotokollmeldungen an einen Remotecomputer weiterzuleiten, fügen Sie die host
hostname Anweisung ein, die IP-Adresse des Remotecomputers der IPv4-Adresse (IP Version 4), die Adresse der IP-Version 6 (IPv6) oder den vollständig qualifizierten Hostnamen des Remote-Computers anzugeben. Auf dem Remote-Computer muss das Standarddienstprogramm syslogd
ausgeführt werden. Es wird davon abgeraten, Nachrichten an ein anderes Gerät von Juniper Networks weiterzuleiten. In jeder Systemprotokollnachricht, die an den Remotecomputer gerichtet ist, wird der Hostname der lokalen Routing-Engine nach dem Zeitstempel angezeigt, um anzugeben, dass es sich um die Quelle der Nachricht handelt.
Fügen Sie die host other-routing-engine
Anweisung ein, um Systemprotokollmeldungen an die andere Routing-Engine auf einem Gerät mit zwei installierten und betriebsbereiten Routing-Modulen weiterzuleiten. Die Anweisung ist nicht automatisch reziprok, daher müssen Sie sie in jede Routing-Engine-Konfiguration aufnehmen, wenn Sie möchten, dass die Routing-Engines Nachrichten aneinander weiterleiten. In jeder Nachricht, die an die andere Routing-Engine gerichtet ist, wird die Zeichenfolge re0
oder re1
nach dem Zeitstempel angezeigt, um die Quelle für die Nachricht anzugeben.
Eine Liste der Protokollierungsfunktionen und Schweregrade, die im Rahmen der host
Anweisung konfiguriert werden müssen, finden Sie unter Angeben der Einrichtung und des Schweregrads von Meldungen, die in das Protokoll aufgenommen werden sollen.
Um Informationen zur Einrichtung und zum Schweregrad in jeder Nachricht aufzuzeichnen, fügen Sie die explicit-priority
Anweisung ein. Weitere Informationen finden Sie unter Einschließen von Prioritätsinformationen in Systemprotokollmeldungen.
Weitere Informationen zur match
Anweisung finden Sie unter Verwenden von Zeichenfolgen und regulären Ausdrücken, um den Satz protokollierter Nachrichten zu verfeinern.
Wenn Sie Nachrichten an Remotecomputer weiterleiten, können Sie die source-address
Anweisung einschließen, um die IP-Adresse des Geräts anzugeben, das in den Nachrichten als Quelle gemeldet wird. Fügen Sie in jede host
Anweisung die Anweisung ein, um facility-override
eine alternative Funktion zuzuweisen, und die Anweisung, um log-prefix
jeder Nachricht eine Zeichenfolge hinzuzufügen. Sie können die structured-data
Anweisung einschließen, um die Weiterleitung strukturierter Systemprotokollmeldungen an einen Remote-Systemprotokollserver im IETF-Systemprotokollmeldungsformat zu aktivieren.
Angeben einer alternativen Quelladresse für Systemprotokollmeldungen, die an ein Remoteziel gerichtet sind
Um den Quellrouter anzugeben, der in Systemprotokollmeldungen gemeldet werden soll, wenn die Nachrichten an einen Remotecomputer weitergeleitet 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 gemeldet, die an alle Remotecomputer gerichtet sind, die in Anweisungen auf host hostname
der [edit system syslog]
Hierarchieebene angegeben sind, jedoch nicht in Nachrichten, die an das andere Routingmodul gerichtet sind.
Hinzufügen einer Textzeichenfolge zu Systemprotokollmeldungen, die an ein Remoteziel gerichtet sind
Um jeder Systemprotokollmeldung, die an einen Remotecomputer oder an die andere Routing-Engine gerichtet ist, 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 beliebige alphanumerische Zeichen oder Sonderzeichen mit Ausnahme des Gleichheitszeichens ( = ) und des Doppelpunkts ( : ) enthalten. Es darf auch das Leerzeichen nicht enthalten. Schließen Sie die Zeichenfolge nicht in Anführungszeichen (" ") ein, um Leerzeichen einzufügen.
Das Dienstprogramm für die Systemprotokollierung von Junos OS fügt automatisch einen Doppelpunkt und ein Leerzeichen an die angegebene Zeichenfolge an, wenn die Systemprotokollmeldungen in das Protokoll geschrieben werden. Die Zeichenfolge wird nach dem Bezeichner für das Routingmodul eingefügt, das die Nachricht generiert hat.
Das folgende Beispiel zeigt, wie die Zeichenfolge M120 zu allen Nachrichten hinzugefügt wird, um anzugeben, dass es sich bei dem Router um einen M120-Router handelt, und die Nachrichten an den Remotecomputer hardware-logger.mycompany.com weitergeleitet werden:
[edit system syslog] host hardware-logger.mycompany.com { any info; log-prefix M120; }
Wenn diese Konfigurationsanweisungen auf einem M120-Router mit dem Namen 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 entferntes Ziel gerichtet sind
Einige Einrichtungen, die Nachrichten zugewiesen sind, die auf dem lokalen Router oder Switch protokolliert werden, haben Junos OS-spezifische Namen (siehe Junos OS-Systemprotokollierungsfunktionen). In der empfohlenen Konfiguration ist ein auf Hierarchieebene [edit system syslog host hostname]
festgelegter Remote-Computer kein Router oder Switch von Juniper Networks, sodass das Dienstprogramm syslogd die für das Junos-Betriebssystem spezifischen Namen nicht interpretieren kann. Damit das standardmäßige Dienstprogramm syslogd Nachrichten von diesen Einrichtungen verarbeiten kann, wenn Nachrichten an einen Remotecomputer weitergeleitet werden, wird ein standardmäßiger localX
Einrichtungsname anstelle des Junos-betriebssystemspezifischen Einrichtungsnamens verwendet.
Standardfunktionen für Systemprotokollmeldungen, die an ein Remoteziel gerichtet sind Listet den alternativen Standardnamen der Einrichtung neben dem Namen der für das Junos-Betriebssystem spezifischen Einrichtung auf, für die sie verwendet wird.
Das Dienstprogramm syslogd auf einem Remote-Computer verarbeitet alle Meldungen, die zu einer Einrichtung gehören, auf die gleiche Weise, unabhängig von der Quelle der Nachricht (dem Router oder Switch von Juniper Networks oder dem Remote-Computer selbst). Beispielsweise monitor.mycompany.comdie folgenden Anweisungen in der Konfiguration des Routers, die als Direktnachrichten von der authorization
Einrichtung an den Remote-Computer bezeichnet local-router
werden:
[edit system syslog] host monitor.mycompany.com { authorization info; }
Die standardmäßige alternative Einrichtung für die lokale authorization
Einrichtung ist ebenfalls authorization
. Wenn das Dienstprogramm syslogd on monitor
so konfiguriert ist, dass Meldungen, die zur authorization
Einrichtung gehören, in die Datei /var/log/auth-attemptsgeschrieben werden, enthält die Datei die Meldungen, die bei der Anmeldung local-router
von Benutzern generiert werden, und die Meldungen, die generiert werden, wenn Benutzer sich monitor
bei anmelden. Obwohl der Name des Quellcomputers in jeder Systemprotokollmeldung angezeigt wird, kann die Vermischung von Nachrichten von mehreren Computern die Analyse des auth-attempts
Inhalts der Datei erschweren.
Um die Trennung der Nachrichten von den einzelnen Quellen zu erleichtern, können Sie allen Nachrichten, die am generiert local-router
werden, wenn sie an monitor
gesendet werden, eine alternative Funktion zuweisen. Sie können dann das Dienstprogramm syslogd so monitor
konfigurieren, dass Nachrichten mit der alternativen Funktion in eine andere Datei geschrieben werden als die für monitor
sich selbst generierten Nachrichten.
Um die Funktion zu ändern, die für alle Nachrichten verwendet wird, die an einen entfernten Computer gerichtet sind, 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 Remotecomputer verwendet wird, z. B. eine der localX
Einrichtungen. Auf dem Remotecomputer müssen Sie auch das Dienstprogramm syslogd so konfigurieren, dass die Nachrichten in der gewünschten Weise verarbeitet werden.
Einrichtungen für die facility-override-Anweisung listet die Einrichtungen auf, die Sie in der facility-override
Anweisung angeben können.
Es wird nicht empfohlen, die facility-override
Anweisung auf Hierarchieebene [edit system syslog host other-routing-engine]
einzuschließen. Es ist nicht erforderlich, alternative Einrichtungsnamen zu verwenden, wenn Nachrichten an die andere Routing-Engine weitergeleitet werden, da das Junos OS-Systemprotokollierungsdienstprogramm die Junos OS-spezifischen Namen interpretieren kann.
Das folgende Beispiel zeigt, wie alle Meldungen, die auf dem lokalen Router mit der Fehlerstufe oder höher generiert werden, in der local0-Funktion auf dem Remotecomputer mit dem Namen monitor.mycompany.com protokolliert werden:
[edit system syslog] host monitor.mycompany.com { any error; facility-override local0; }
Das folgende Beispiel zeigt, wie Router in Kalifornien und Router in New York so konfiguriert werden, dass Nachrichten an einen einzelnen Remotecomputer mit dem Namen central-logger.mycompany.com gesendet werden. Die Meldungen aus Kalifornien werden der alternativen Einrichtung local0 und die Meldungen aus New York der alternativen Einrichtung local2 zugewiesen.
Konfigurieren Sie kalifornische Router so, dass Nachrichten in der local0-Einrichtung aggregiert werden:
[edit system syslog] host central-logger.mycompany.com { change-log info; facility-override local0; }
Konfigurieren Sie New Yorker Router so, dass Nachrichten in der lokalen2 Einrichtung aggregiert werden:
[edit system syslog] host central-logger.mycompany.com { change-log info; facility-override local2; }
Auf central-logger können Sie dann das Systemprotokollierungsprogramm so konfigurieren, dass Nachrichten von der local0-Einrichtung in die Datei change-log und die Meldungen von der local2-Einrichtung in die Datei new-york-configgeschrieben werden.
Standardfunktionen für Systemprotokollmeldungen, die an ein entferntes Ziel gerichtet sind
Tabelle 3 listet den alternativen Standardnamen der Einrichtung neben dem Namen der für das Junos-Betriebssystem spezifischen Einrichtung auf, für die 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 |
Standardfunktion, wenn sie an ein entferntes Ziel weitergeleitet wird |
---|---|
Änderungsprotokoll |
local6 |
conflict-log (Konflikt-Logbuch) |
local5 |
Dfc |
local1 |
Firewall |
local3 |
interaktive-befehle |
local7 |
PFE |
local4 |
Alternative Funktionen für Systemprotokollmeldungen, die an ein entferntes Ziel gerichtet sind
Tabelle 4 Listet die Einrichtungen auf, die Sie in der facility-override
Anweisung angeben können.
Leichtigkeit |
Beschreibung |
---|---|
|
Authentifizierungs- und Autorisierungsversuche |
|
Ausgeführte Aktionen oder Fehler von Systemprozessen |
|
Ausgeführte Aktionen oder Fehler des FTP-Prozesses |
|
Vom Junos OS-Kernel ausgeführte Aktionen oder Fehler |
|
Lokale Einrichtung Nummer 0 |
|
Lokale Einrichtung Nummer 1 |
|
Lokale Einrichtung Nummer 2 |
|
Lokale Einrichtung Nummer 3 |
|
Lokale Einrichtung Nummer 4 |
|
Lokale Einrichtung Nummer 5 |
|
Lokale Einrichtung Nummer 6 |
|
Lokale Einrichtung Nummer 7 |
|
Ausgeführte Aktionen oder Fehler, die bei User-Space-Prozessen aufgetreten sind |
Es wird nicht empfohlen, die facility-override
Anweisung auf Hierarchieebene [edit system syslog host other-routing-engine]
einzuschließen. Es ist nicht erforderlich, alternative Einrichtungsnamen zu verwenden, wenn Nachrichten an die andere Routing-Engine weitergeleitet werden, da das Junos OS-Systemprotokollierungsdienstprogramm die Junos OS-spezifischen Namen interpretieren kann.
Beispiele: Zuweisen einer alternativen Einrichtung zu Systemprotokollmeldungen, die an ein entferntes Ziel gerichtet sind
Protokollieren Sie alle Meldungen, die auf der lokalen Routing-Plattform mit der Fehlerstufe oder höher generiert werden, in der local0
Einrichtung auf dem Remote-Computer mit dem Namen 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 so, dass Nachrichten an einen einzelnen Remotecomputer namens central-logger.mycompany.com gesendet werden. Den Nachrichten aus Kalifornien wird die alternative Einrichtung local0 und den Nachrichten aus New York die alternative Einrichtung local2 zugewiesen.
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 Yorker Routing-Plattformen, um Nachrichten in der
local2
Einrichtung zu aggregieren:[edit system syslog] host central-logger.mycompany.com { change-log info; facility-override local2; }
Auf central-logger,
können Sie dann das Systemprotokollierungsprogramm so konfigurieren, dass Nachrichten von der local0
Einrichtung in die Datei california-config und die Nachrichten von der local2
Einrichtung in die Datei new-york-configgeschrieben werden.
Direktnachrichten an ein entferntes Ziel von der Routing-Matrix basierend auf dem TX-Matrix-Router
Sie können eine Routing-Matrix, die aus einem TX-Matrix-Router und T640-Routern besteht, so konfigurieren, dass Systemprotokollierungsmeldungen an einen Remotecomputer oder die andere Routing-Engine auf jedem Router weitergeleitet werden, genau wie bei einem System mit einem einzigen Chassis. Fügen Sie die host
Anweisung auf der [edit system syslog]
Hierarchieebene auf dem TX-Matrix-Router 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 auf die gleiche Weise wie ein Single-Chassis-System an einen entfernten Computer oder die andere Routing-Engine weiter, und die optionalen Anweisungen (explicit-priority
, facility-override
, log-prefix
, match
und source-address
) haben ebenfalls die gleiche Wirkung wie bei einem Single-Chassis-System.
Damit der TX-Matrix-Router Prioritätsinformationen einschließt, wenn er Nachrichten, die von einem T640-Router stammen, an das Remote-Ziel weiterleitet, müssen Sie die explicit-priority
Anweisung auch auf Hierarchieebene [edit system syslog host scc-master]
einschließen.
Die other-routing-engine
Anweisung interagiert nicht mit der Nachrichtenweiterleitung von den T640-Routern an den TX-Matrix-Router. Wenn Sie die Anweisung beispielsweise in die Konfiguration für die Routing-Engine in Steckplatz 0 (re0
) aufnehmen, sendet die re0
Routing-Engine auf jedem T640-Router Nachrichten nur an die re1
Routing-Engine auf seiner Plattform. Es sendet auch keine Nachrichten direkt an die re1
Routing-Engine auf dem TX Matrix-Router.
Da die Konfiguration auf dem TX Matrix-Router für die T640-Router gilt, leitet jeder T640-Router, der über Schnittstellen für den direkten Zugriff auf das Internet verfügt, auch Nachrichten an den Remote-Computer weiter. Die Konsequenzen sind unter anderem:
Wenn die T640-Router so konfiguriert sind, dass Nachrichten an den TX-Matrix-Router weitergeleitet werden (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 die Schweregrade für die lokale Protokollierung und für weitergeleitete Nachrichten gleich sind. 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 Remote-Computer gerichtet sind. Dies ist angemessen, da die Routing-Matrix als ein einzelner Router fungiert.Wenn die
log-prefix
Anweisung enthalten ist, enthalten die Nachrichten von allen Routern in der Routing-Matrix dieselbe Textzeichenfolge. Sie können die Zeichenfolge nicht verwenden, um zwischen den Routern in der Routing-Matrix zu unterscheiden.
Direktnachrichten an ein entferntes Ziel aus der Routing-Matrix basierend auf einem TX Matrix Plus-Router
Aus der Perspektive der Benutzeroberfläche erscheint die Routing-Matrix als ein einzelner Router. Der TX Matrix Plus-Router (auch Switch-Fabric-Chassis-SFC genannt) steuert alle T1600- oder T4000-Router, auch Ine-Card-Chassis-LCC genannt) in der Routing-Matrix.
Sie können eine Routing-Matrix, die aus einem TX Matrix Plus-Router mit angeschlossenen T1600- oder T4000-LCCs besteht, so konfigurieren, dass Systemprotokollierungsmeldungen an einen Remote-Computer oder die andere Routing-Engine auf jedem Routing-Router weitergeleitet werden, genau wie bei einem System mit einem einzigen Chassis. Fügen Sie die host
Anweisung auf der [edit system syslog]
Hierarchieebene des 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 auf die gleiche Weise wie ein Single-Chassis-System an einen Remote-Computer oder die andere Routing-Engine weiter, und die optionalen Anweisungen (explicit-priority
, facility-override
, , log-prefix
und match
source-address
) haben ebenfalls die gleiche Wirkung wie bei einem Single-Chassis-System.
Damit der TX Matrix Plus-Router Prioritätsinformationen einschließt, wenn er Nachrichten, die von einem angeschlossenen T1600- oder T4000-LCC stammen, an das Remote-Ziel weiterleitet, müssen Sie die explicit-priority
Anweisung auch auf Hierarchieebene [edit system syslog host sfc0-master]
einfügen.
Die other-routing-engine
Anweisung interagiert nicht mit der Nachrichtenweiterleitung 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 (re0
) aufnehmen, sendet die Routing-Engine auf jedem angeschlossenen re0
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 auf der SFC.
Da die Konfiguration auf der SFC für die angeschlossenen T1600 oder T4000 LCCs gilt, leitet jeder LCC, der über Schnittstellen für den direkten Zugriff auf das Internet verfügt, auch Nachrichten an die entfernte Maschine weiter. Die Konsequenzen sind unter anderem:
Wenn die LCCs so konfiguriert sind, dass sie Nachrichten an den SFC weiterleiten (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 die Schweregrade für die lokale Protokollierung und für weitergeleitete Nachrichten gleich sind. 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 Remote-Computer gerichtet sind. Dies ist sinnvoll, da die Routingmatrix 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 die Zeichenfolge nicht verwenden, um zwischen den Routern in der Routing-Matrix zu unterscheiden.