Laden von Konfigurationsdateien
Das Laden von Konfigurationsdateien auf dem Gerät ist hilfreich, um Teile von Konfigurationsdateien zu laden, die auf vielen Geräten innerhalb eines Netzwerks gemeinsam sein können.
Beispiele für das Laden einer Konfiguration aus einer Datei oder dem Terminal
Sie können eine Datei mit Konfigurationsdaten für ein Gerät von Juniper Networks erstellen, die Datei auf das lokale Gerät kopieren und die Datei dann in die CLI laden. Nachdem Sie die Datei geladen haben, können Sie sie festschreiben, um die Konfiguration auf dem Gerät zu aktivieren, oder Sie können die Konfiguration interaktiv über die CLI bearbeiten und die Konfiguration zu einem späteren Zeitpunkt bestätigen.
Sie können auch eine Konfiguration erstellen, während Sie am Terminal tippen, und dann die Konfiguration laden. Das Laden einer Konfiguration aus dem Terminal ist nützlich, wenn Sie vorhandene Teile der Konfiguration ausschneiden und an anderer Stelle in der Konfiguration einfügen.
Um eine vorhandene Konfigurationsdatei zu laden, die sich auf dem Gerät befindet, verwenden Sie den load Befehl configuration mode:
[edit] user@host# load (factory-default | merge | override | patch | replace | set | update) filename <relative> <json>
Um eine Konfiguration aus dem Terminal zu laden, verwenden Sie die folgende Version des load Befehls configuration mode. Drücken Sie Strg-d, um die Eingabe zu beenden.
[edit] user@host# load (factory-default | merge | override | patch | replace | set | update) terminal <relative> <json>
Um eine gesamte Konfiguration zu ersetzen, geben Sie die override Option auf einer beliebigen Ebene der Hierarchie an. Bei einem load override Vorgang wird die aktuelle Kandidatenkonfiguration vollständig durch die Datei ersetzt, die Sie laden. Wenn Sie also eine vollständige Konfiguration gespeichert haben, verwenden Sie diese Option.
Bei einem override Vorgang wird die aktuelle Kandidatenkonfiguration verworfen und die Konfiguration oder filename die Konfiguration, die Sie im Terminal eingeben, geladen. Wenn Sie die override Option verwenden und die Konfiguration bestätigen, analysieren alle Systemprozesse die Konfiguration erneut.
Um Teile einer Konfiguration zu ersetzen, geben Sie die replace Option an. Der load replace Vorgang sucht nach replace: Tags, die Sie der geladenen Datei hinzugefügt haben. Der Vorgang ersetzt dann diese Teile der Kandidatenkonfiguration durch das, was nach dem Tag angegeben wird. Dies ist nützlich, wenn Sie mehr Kontrolle darüber haben möchten, was genau geändert wird. Damit dieser Vorgang funktioniert, müssen Sie Tags in die Datei oder Konfiguration aufnehmen replace: , die Sie im Terminal eingeben. Die Software sucht nach den replace: Tags, löscht ggf. die vorhandenen gleichnamigen Anweisungen und ersetzt sie durch die eingehende Konfiguration. Wenn keine gleichnamige Anweisung vorhanden ist, fügt der replace Vorgang der Konfiguration die mit dem replace: Tag markierten Anweisungen hinzu.
Wenn Sie in einem override Oder-Vorgang merge eine Datei angeben oder Text eingeben, der Tags enthält replace: , werden die replace: Tags ignoriert. In diesem Szenario hat der override Vorgang "oder" merge Vorrang und wird ausgeführt.
Wenn Sie einen replace Vorgang ausführen und die von Ihnen angegebene Datei keine Tags enthält replace: , wird der replace Vorgang als Vorgang merge ausgeführt. Der replace Vorgang wird auch als Vorgang merge ausgeführt, wenn der eingegebene Text keine Tags enthält replace: . Diese Informationen können nützlich sein, wenn Sie automatisierte Skripts ausführen und nicht im Voraus wissen können, ob die Skripts einen replace Vorgang oder einen merge Vorgang ausführen müssen. Die Skripts können den replace Vorgang verwenden, um beide Fälle abzudecken.
Bei load merge diesem Vorgang wird die Konfiguration aus der gespeicherten Datei oder dem Terminal mit der vorhandenen Kandidatenkonfiguration zusammengeführt. Diese Informationen sind nützlich, wenn Sie neue Konfigurationsabschnitte hinzufügen. Angenommen, Sie fügen der [edit protocols] Hierarchieebene eine BGP-Konfiguration hinzu, für die es zuvor keine BGP-Konfiguration gab. Sie können den load merge Vorgang verwenden, um die eingehende Konfiguration mit der vorhandenen Kandidatenkonfiguration zu kombinieren. Wenn die vorhandene Konfiguration und die eingehende Konfiguration widersprüchliche Anweisungen enthalten, überschreiben die Anweisungen in der eingehenden Konfiguration die Anweisungen in der vorhandenen Konfiguration.
Um nur die Teile der Konfiguration zu ersetzen, die sich geändert haben, geben Sie die update Option auf einer beliebigen Ebene der Hierarchie an. Der load update Vorgang vergleicht die Kandidatenkonfiguration und die neuen Konfigurationsdaten. Dieser Vorgang ändert nur die Teile der Kandidatenkonfiguration, die sich von der neuen Konfiguration unterscheiden. Sie würden diesen Vorgang z. B. verwenden, wenn eine BGP-Konfiguration vorhanden ist und die Datei, die Sie laden, diese in irgendeiner Weise ändert.
Die mergeOptionen , overrideund update unterstützen das Laden von Konfigurationsdaten im JSON-Format (JavaScript Object Notation). Wenn Sie Konfigurationsdaten laden, die das JSON-Format verwenden, müssen Sie die json Option im Befehl angeben. Informationen zum Laden von JSON-Konfigurationsdaten, die ungeordnete Listeneinträge enthalten, d. h. Listeneinträge, bei denen der Listenschlüssel nicht unbedingt das erste Element im Listeneintrag ist, finden Sie unter Laden von JSON-Konfigurationsdaten mit ungeordneten Listeneinträgen.
Um einen Teil der Konfiguration mit einer Patch-Datei zu ändern, geben Sie die patch Option an. Der load patch Vorgang lädt eine Datei oder Terminaleingabe, die Konfigurationsänderungen enthält. Zuerst geben Sie auf einem Gerät, auf dem die Konfigurationsänderungen bereits vorgenommen wurden, den show | compare Befehl ein, um die Unterschiede zwischen zwei Konfigurationen auszugeben. Dann können Sie die Unterschiede auf ein anderes Gerät laden. Der Vorteil des load patch Befehls besteht darin, dass Sie keine Snippets aus verschiedenen Hierarchieebenen in eine Textdatei kopieren müssen, bevor Sie sie auf das Zielgerät laden. Dies kann eine nützliche Zeitersparnis sein, wenn Sie mehrere Geräte mit denselben Optionen konfigurieren. Angenommen, Sie konfigurieren eine Routing-Richtlinie auf Router1 und möchten die Richtlinienkonfiguration auf Router2, Router3 und Router4 replizieren. Sie können die load patch Operation verwenden.
In diesem Beispiel führen Sie zuerst den show | compare Befehl aus.
Beispiel:
user@router1# show | compare rollback 3
[edit protocols ospf]
+ export default-static;
- export static-default
[edit policy-options]
+ policy-statement default-static {
+ from protocol static;
+ then accept;
+ }In Fortsetzung dieses Beispiels kopieren Sie die Ausgabe des show | compare Befehls in die Zwischenablage und stellen sicher, dass die Hierarchieebenen enthalten sind. Auf router2, router3 und router4 geben Sie die Ausgabe ein load patch terminal und fügen sie ein. Drücken Sie dann die Eingabetaste und dann Strg-d, um den Vorgang zu beenden. Wenn die Patch-Eingabe unterschiedliche Werte für eine vorhandene Anweisung angibt, überschreibt die Patch-Eingabe die vorhandene Anweisung.
Wenn Sie die mergeOption , replace, setoder update verwenden möchten, ohne die vollständige Hierarchieebene anzugeben, geben Sie die relative Option an. Mit dieser Option wird die eingehende Konfiguration relativ zu Ihrem aktuellen Bearbeitungspunkt in der Konfigurationshierarchie geladen.
Beispiel:
[edit system]
user@host# show static-host-mapping
bob sysid 987.654.321ab
[edit system]
user@host# load replace terminal relative
[Type ^D at a new line to end input]
replace: static-host-mapping {
bob sysid 0123.456.789bc;
}
load complete
[edit system]
user@host# show static-host-mapping
bob sysid 0123.456.789bc;
Um eine Konfiguration zu laden, die Konfigurationsmodusbefehle enthält set , geben Sie die set Option an. Diese Option führt die Konfigurationsanweisungen Zeile für Zeile aus, wie sie in einer Datei oder von einem Terminal aus gespeichert sind. Die Anweisungen können beliebige Konfigurationsmodusbefehle enthalten, z. B set. , edit, exitund top.
Um eine Konfigurationsdatei von einem anderen Netzwerksystem auf den lokalen Router zu kopieren, können Sie die SSH- und Telnet-Dienstprogramme verwenden, wie im CLI-Explorerbeschrieben.
Wenn Sie in einer Common Criteria-Umgebung arbeiten, werden Systemprotokollmeldungen immer dann erstellt, wenn ein secret Attribut geändert wird (z. B. Kennwortänderungen oder Änderungen am gemeinsamen geheimen RADIUS-Schlüssel). Diese Änderungen werden während der folgenden Konfigurationsladevorgänge protokolliert:
load merge load replace load override load update
Funktionsweise der Zeichenkodierung auf Geräten von Juniper Networks
Die Konfigurationsdaten des Junos OS und die Ausgabe von Betriebsbefehlen können Nicht-ASCII-Zeichen enthalten, die außerhalb des 7-Bit-ASCII-Zeichensatzes liegen. Bei der Anzeige von Betriebs- oder Konfigurationsdaten in bestimmten Formaten oder innerhalb eines bestimmten Sitzungstyps maskiert und kodiert die Software diese Zeichen. Die Software maskiert oder codiert die Zeichen mit der entsprechenden UTF-8-Dezimalzeichenreferenz.
Die CLI versucht, alle Nicht-ASCII-Zeichen in Konfigurationsdaten anzuzeigen, die im Text-, Set- oder JSON-Format erzeugt werden. Die CLI versucht auch, diese Zeichen in der Befehlsausgabe anzuzeigen, die im Textformat erzeugt wird. In den Ausnahmefällen zeigt die CLI stattdessen den UTF-8-Dezimalzeichenverweis an. (Ausnahmefälle sind Konfigurationsdaten im XML-Format und Befehlsausgabe im XML- oder JSON-Format.) In NETCONF- und Junos-XML-Protokollsitzungen wird ein ähnliches Ergebnis angezeigt, wenn Sie Konfigurationsdaten oder Befehlsausgaben anfordern, die Nicht-ASCII-Zeichen enthalten. In diesem Fall gibt der Server den entsprechenden UTF-8-Dezimalzeichenverweis für diese Zeichen für alle Formate zurück.
Angenommen, das folgende Benutzerkonto, das den lateinischen Kleinbuchstaben n mit einer Tilde (ñ) enthält, ist auf dem Gerät konfiguriert.
[edit] user@host# set system login user mariap class super-user uid 2007 full-name "Maria Peña"
Wenn Sie die resultierende Konfiguration im Textformat anzeigen, gibt die CLI das entsprechende Zeichen aus.
[edit] user@host# show system login user mariap full-name "Maria Peña"; uid 2007; class super-user;
Wenn Sie die resultierende Konfiguration im XML-Format in der CLI anzeigen, wird das Zeichen ñ der entsprechenden UTF-8-Dezimalzeichenreferenz ñzugeordnet. Das gleiche Ergebnis tritt auf, wenn Sie die Konfiguration in einem beliebigen Format in einer NETCONF- oder Junos XML-Protokollsitzung anzeigen.
[edit]
user@host# show system login user mariap | display xml
<rpc-reply xmlns:junos="http://xml.juniper.net/junos/17.2R1/junos">
<configuration junos:changed-seconds="1494033077" junos:changed-localtime="2017-05-05 18:11:17 PDT">
<system>
<login>
<user>
<name>mariap</name>
<full-name>Maria Peña</full-name>
<uid>2007</uid>
<class>super-user</class>
</user>
</login>
</system>
</configuration>
<cli>
<banner>[edit]</banner>
</cli>
</rpc-reply>
Wenn Sie Konfigurationsdaten auf ein Gerät laden, können Sie Nicht-ASCII-Zeichen mit den entsprechenden UTF-8-Dezimalzeichenreferenzen laden.
Informationen zum Angeben von Anweisungen und Bezeichnern
Dieses Thema enthält Details zu CLI-Containeranweisungen und Leaf-Anweisungen, damit Sie wissen, wie Sie diese beim Erstellen von ASCII-Konfigurationsdateien angeben müssen. In diesem Thema wird auch beschrieben, wie die CLI eine Typüberprüfung durchführt, um zu überprüfen, ob die eingegebenen Daten das richtige Format haben.
Angeben von Anweisungen
Anweisungen werden auf zwei Arten angezeigt, entweder mit geschweiften Klammern ({ }) oder ohne:
-
Anweisungsname und -bezeichner, wobei eine oder mehrere Anweisungen auf niedrigerer Ebene in geschweifte Klammern eingeschlossen sind:
statement-name1 identifier-name { statement-name2; additional-statements; } -
Anweisungsname, Bezeichner und ein einzelner Bezeichner:
statement-name identifier-name1 identifier-name2;
Das statement-name ist der Name der Anweisung. Das identifier-name ist ein Name oder eine andere Zeichenfolge, die eine Instanz einer Anweisung eindeutig identifiziert. Sie verwenden einen Bezeichner, wenn eine Anweisung mehr als einmal in einer Konfiguration angegeben werden kann.
Wenn Sie eine Anweisung angeben, müssen Sie je nach Anweisungshierarchie einen Anweisungsnamen, einen Bezeichnernamen oder beides angeben.
Sie geben Bezeichner auf eine der folgenden Arten an:
-
identifier-name– Das identifier-name ist ein Schlüsselwort, das zur eindeutigen Identifizierung einer Anweisung verwendet wird, wenn eine Anweisung mehr als einmal in einer Anweisung angegeben werden kann.
-
identifier-name value– Das identifier-name ist ein Schlüsselwort und das value ist eine erforderliche Optionsvariable.
-
identifier-name [value1 value2 value3
...]—Das identifier-name ist ein Schlüsselwort, das mehrere Werte akzeptiert. Die eckigen Klammern sind erforderlich, wenn Sie eine Gruppe von Werten angeben. Sie sind jedoch optional, wenn Sie nur einen Wert angeben.
Die folgenden Beispiele veranschaulichen, wie Anweisungen und Bezeichner in der Konfiguration angegeben werden:
protocol { # Top-level statement (statement-name).
ospf { # Statement under "protocol" (statement-name).
area 0.0.0.0 { # OSPF area "0.0.0.0" (statement-name identifier-name),
interface so-0/0/0 { # which contains an interface named "so-0/0/0."
hello-interval 25; # Identifier and value (identifier-name value).
priority 2; # Identifier and value (identifier-name value).
disable; # Flag identifier (identifier-name).
}
interface so-0/0/1; # Another instance of "interface," named so-0/0/1,
} # this instance contains no data, so no braces
} # are displayed.
}
policy-options { # Top-level statement (statement-name).
term term1 { # Statement under "policy-options"
# (statement-name value).
from { # Statement under "term" (statement-name).
route-filter 10.0.0.0/8 orlonger reject; # One identifier ("route-filter") with
route-filter 127.0.0.0/8 orlonger reject; # multiple values.
route-filter 128.0.0.0/16 orlonger reject;
route-filter 149.20.64.0/24 orlonger reject;
route-filter 172.16.0.0/12 orlonger reject;
route-filter 191.255.0.0/16 orlonger reject;
}
then { # Statement under "term" (statement-name).
next term; # Identifier (identifier-name).
}
}
}
Wenn Sie eine ASCII-Konfigurationsdatei erstellen, geben Sie Anweisungen und Bezeichner an. Jede Anweisung hat einen bevorzugten Stil, und die CLI verwendet diesen Stil, wenn die Konfiguration als Reaktion auf einen Konfigurationsmodusbefehl show angezeigt wird. Sie können Anweisungen und Bezeichner auf eine der folgenden Arten angeben:
-
Anweisung gefolgt von Bezeichnern:
statement-name identifier-name [...] identifier-name value [...];
-
Anweisung gefolgt von Bezeichnern in geschweiften Klammern:
statement-name { identifier-name; [...] identifier-name value; [...] } -
Bei einigen sich wiederholenden Bezeichnern können Sie einen Satz geschweifter Klammern für alle Anweisungen verwenden:
statement-name { identifier-name value1; identifier-name value2; }
Durchführen der CLI-Typüberprüfung
Wenn Sie Bezeichner und Werte angeben, führt die CLI eine Typüberprüfung durch, um sicherzustellen, dass die eingegebenen Daten das richtige Format aufweisen. Für eine Anweisung, in der Sie beispielsweise eine IP-Adresse angeben müssen, erfordert die CLI, dass Sie eine Adresse in einem gültigen Format eingeben. Andernfalls gibt eine Fehlermeldung an, was Sie eingeben müssen. listet die Datentypen auf, die von der CLI überprüft werden. Im Folgenden finden Sie Eingabetypen für die CLI-Konfiguration:
|
Datentyp |
Format |
Beispiele |
|---|---|---|
|
Name der physischen Schnittstelle (wird in der [ |
|
Correct: Incorrect: |
|
Vollständiger Schnittstellenname |
|
Correct: Incorrect: |
|
Vollständiger oder abgekürzter Schnittstellenname (wird an anderen Stellen als der [ |
|
Correct: |
|
IP-Adresse |
|
Correct: Sample translations:
|
|
IP-Adresse (Zielpräfix) und Präfixlänge |
|
Correct: Sample translations:
|
|
Adresse der Internationalen Organisation für Normung (ISO) |
|
Correct: Sample translations:
|
|
OSPF-Bereichskennung (ID) |
|
Correct: Sample translations:
|
Informationen zum Laden einer Konfiguration aus einer Datei
In den folgenden Beispielen wird das Laden einer Konfiguration aus einer Datei veranschaulicht.
Hochladen einer Konfigurationsdatei
Sie können eine Konfigurationsdatei auf Ihrem lokalen System erstellen, die Datei auf das Gerät kopieren und die Datei dann in die CLI laden. Nachdem Sie die Konfigurationsdatei geladen haben, können Sie sie bestätigen, um die Konfiguration auf dem Gerät zu aktivieren. Sie können die Konfiguration auch interaktiv über die CLI bearbeiten und zu einem späteren Zeitpunkt bestätigen.
So laden Sie eine Konfigurationsdatei von Ihrem lokalen System hoch:
Um die Ergebnisse der Konfigurationsschritte anzuzeigen, bevor Sie die Konfiguration bestätigen, geben Sie den show Befehl an der Benutzeraufforderung ein.
Um diese Änderungen in die aktive Konfiguration zu übernehmen, geben Sie den commit Befehl an der Benutzeraufforderung ein. Sie können die Konfiguration auch interaktiv über die CLI bearbeiten und zu einem späteren Zeitpunkt bestätigen.
Laden von JSON-Konfigurationsdaten mit ungeordneten Listeneinträgen
Das Junos-Schema definiert bestimmte Konfigurationsobjekte als Listen. In JSON-Konfigurationsdaten wird eine Listeninstanz als Name/Array-Paar codiert, und die Arrayelemente sind JSON-Objekte. Im Allgemeinen ist die Reihenfolge der Elemente in einem JSON-codierten Listeneintrag willkürlich, da JSON-Objekte grundsätzlich ungeordnete Sammlungen von Elementen sind. Das Junos-Schema erfordert jedoch, dass Listenschlüssel vor allen anderen gleichgeordneten Schlüsseln in einem Listeneintrag stehen und in der vom Schema angegebenen Reihenfolge angezeigt werden.
Das Objekt auf der [edit system login] Hierarchieebene ist z. B. eine Liste, userwobei name der Listenschlüssel ist, der jeden Benutzer eindeutig identifiziert.
list user {
key name;
description "Username";
uses login-user-object;
}In den folgenden Beispielkonfigurationsdaten ist der Listenschlüssel (name) das erste Element für jeden Benutzer. Wenn Sie JSON-Konfigurationsdaten laden, erfordern Junos-Geräte standardmäßig, dass die Listenschlüssel allen anderen gleichgeordneten Schlüsseln innerhalb eines Listeneintrags vorangestellt sind und in der durch das Schema angegebenen Reihenfolge angezeigt werden.
{
"configuration" : {
"system" : {
"login" : {
"user" : [
{
"name" : "operator",
"class" : "operator",
"uid" : 3001
},
{
"name" : "security-admin",
"class" : "super-user",
"uid" : 3002
}
]
}
}
}
}Junos-Geräte bieten zwei Optionen zum Laden von JSON-Konfigurationsdaten, die ungeordnete Listeneinträge enthalten, d. h. Listeneinträge, bei denen der Listenschlüssel nicht unbedingt das erste Element ist.
-
Verwenden Sie den
request system convert-json-configurationBefehl operational mode, um JSON-Konfigurationsdaten mit geordneten Listeneinträgen zu erzeugen, bevor Sie die Daten auf das Gerät laden. -
Konfigurieren Sie die
reorder-list-keysAnweisung auf Hierarchieebene[edit system configuration input format json]. Nachdem Sie die Anweisung konfiguriert haben, können Sie JSON-Konfigurationsdaten mit ungeordneten Listeneinträgen laden, und das Gerät ordnet die Listenschlüssel neu an, wie es das Junos-Schema während des Ladevorgangs erfordert.
Wenn Sie die reorder-list-keys Anweisung konfigurieren, kann das Analysieren der Konfiguration durch den Ladevorgang erheblich länger dauern, abhängig von der Größe der Konfiguration und der Anzahl der Listen. Für große Konfigurationen oder Konfigurationen mit vielen Listen empfehlen wir daher, den request system convert-json-configuration Befehl anstelle der reorder-list-keys Anweisung zu verwenden.
Angenommen, die user-data.json Datei enthält die folgende JSON-Konfiguration. Wenn Sie versuchten, die Konfiguration zu laden, gab das Gerät einen Ladefehler aus, da admin2 der Listenschlüssel name nicht das erste Element in diesem Listeneintrag ist.
user@host> file show /var/tmp/user-data.json
{
"configuration" : {
"system" : {
"login" : {
"user" : [
{
"name" : "admin1",
"class" : "super-user",
"uid" : 3003
},
{
"class" : "super-user",
"name" : "admin2",
"uid" : 3004
}
]
}
}
}
}Wenn Sie den request system convert-json-configuration Befehl mit der vorherigen Datei als Eingabe verwenden, generiert der Befehl die angegebene Ausgabedatei mit JSON-Konfigurationsdaten, die das Junos-Gerät während des Ladevorgangs analysieren kann.
user@host> request system convert-json-configuration /var/tmp/user-data.json output-filename user-data-ordered.json
user@host> file show user-data-ordered.json
{
"configuration":{
"system":{
"login":{
"user":[
{
"name":"admin1",
"class":"super-user",
"uid":3003
},
{
"name":"admin2",
"class":"super-user",
"uid":3004
}
]
}
}
}
}Alternativ können Sie die reorder-list-keys Konfigurationsanweisung konfigurieren.
user@host# set system configuration input format json reorder-list-keys user@host# commit
Nachdem Sie die Anweisung konfiguriert haben, können Sie die ursprüngliche JSON-Konfigurationsdatei mit ungeordneten Listeneinträgen laden, und das Gerät verarbeitet die Listeneinträge, wenn es die Konfiguration analysiert.
user@host# load merge json /var/tmp/user-data.json load complete