Auf dieser Seite
Beispiel: Deaktivieren der Vererbung einer Konfigurationsgruppe
So verbessern Sie die Commit-Zeit bei der Verwendung von Konfigurationsgruppen
Beispiel: Konfigurieren von Anweisungen mit Konfigurationsgruppen
Beispiel: Konfigurieren von Schnittstellen mithilfe von Konfigurationsgruppen
Beispiel: Konfigurationsgruppen zur Konfiguration von Peer-Entitäten verwenden
Beispiel: Verwenden von Konfigurationsgruppen zum Einrichten regionaler Konfigurationen
Beispiel: Konfigurieren von Gruppennamen für die Konfiguration von Wildcard-Konfigurationen
Beispiel: Verweisen Sie auf die voreingestellte Anweisung aus der Gruppe "Standard".
Beispiel: Anzeigen von Standardanweisungen, die auf die Konfiguration angewendet wurden
So verwenden Sie Bedingungen zum Anwenden von Konfigurationsgruppen
Beispiel: Konfigurationsbedingungen für die Anwendung von Konfigurationsgruppen
Verwenden von Konfigurationsgruppen zur schnellen Konfiguration von Geräten
Verwenden Sie Konfigurationsgruppen, um gemeinsame Elemente einzurichten und anzuwenden, die innerhalb derselben Konfiguration wiederverwendet werden.
Konfigurationsgruppen – Übersicht
Dieses Thema bietet einen Überblick über Konfigurationsgruppen und das Vererbungsmodell in der Junos OS CLI.
- Funktionsweise von Konfigurationsgruppen
- Vererbungsmodell
- Konfiguration von KonfigurationsgruppenThis is really a task topic. From here to the end, you introduce how to do something. It's not a description of how something happens but a short procedure guiding a user to configure configuration groups. I recommend breaking this out into a separate task topic and linking to it from the concept topic.
Funktionsweise von Konfigurationsgruppen
Mit Konfigurationsgruppen können Sie eine Gruppe erstellen, die Konfigurationsanweisungen enthält, und die Vererbung der Anweisungen dieser Gruppe im Rest der Konfiguration leiten. Dieselbe Gruppe kann auf verschiedene Abschnitte der Konfiguration angewendet werden. Verschiedene Abschnitte der Konfigurationsanweisungen einer Gruppe können an verschiedenen Stellen in der Konfiguration geerbt werden.
Mit Konfigurationsgruppen können Sie kleinere, logischere Konfigurationsdateien erstellen, was die Konfiguration und Wartung von Geräten von Juniper Networks erleichtert. Sie können beispielsweise Anweisungen gruppieren, die an vielen Stellen in der Konfiguration wiederholt werden, z. B. bei der Konfiguration von Schnittstellen. Indem Sie Anweisungen gruppieren, können Sie Konfigurationsupdates nur auf die Gruppe beschränken.
Sie können auch Wildcards in einer Konfigurationsgruppe verwenden. Jedes Objekt, das mit dem Wildcard-Ausdruck übereinstimmt, erbt die Gruppenkonfigurationsdaten.
Der Konfigurationsgruppenmechanismus ist getrennt von den Gruppierungsmechanismen, die anderswo in der Konfiguration verwendet werden, z. B. BGP-Gruppen. Konfigurationsgruppen stellen einen generischen Mechanismus bereit, den Sie während der gesamten Konfiguration verwenden können, die aber nur der CLI bekannt sind. Die einzelnen Softwareprozesse, die die von der Konfiguration gesteuerten Aktionen ausführen, erhalten die erweiterte Form der Konfiguration; sie haben keine Kenntnis von Konfigurationsgruppen.
Vererbungsmodell
Konfigurationsgruppen verwenden echte Vererbung, die eine dynamische, laufende Beziehung zwischen der Quelle der Konfigurationsdaten und dem Ziel dieser Daten beinhaltet. Das Ziel erbt automatisch Datenwerte, die Sie in der Konfigurationsgruppe ändern. Das Ziel muss die geerbten Informationen nicht enthalten. Die erbenten Werte können jedoch im Ziel außer Kraft gesetzt werden, ohne die Quelle, von der sie geerbt wurden, zu beeinträchtigen.
Mit diesem Vererbungsmodell können Sie nur die instanzspezifischen Informationen anzeigen, ohne die erbenten Details anzuzeigen. Über eine Befehlszeile im Konfigurationsmodus können Sie die geerbten Daten anzeigen.
Konfiguration von Konfigurationsgruppen
Für Bereiche ihrer Konfiguration, die Konfigurationsanweisungen erben sollen, müssen Sie die Anweisungen zuerst in eine Konfigurationsgruppe legen. Sie wenden diese Gruppe dann auf die Ebenen in der Konfigurationshierarchie an, für die die Anweisungen erforderlich sind.
Für Bereiche Ihrer Konfiguration, die Konfigurationsanweisungen erben möchten:
-
Konfigurieren Sie Anweisungen in einer Konfigurationsgruppe. Um Konfigurationsgruppen und Vererbung zu konfigurieren, können Sie die Groups-Anweisung auf der Hierarchieebene [bearbeiten] einschließen:
[edit] groups {group-name{configuration-data; } } -
Wenden Sie die Konfigurationsgruppe von Schritt 1 auf die Ebenen in der Konfigurationshierarchie an, für die die Anweisungen erforderlich sind.
Fügen Sie die
apply-groups [ group-names ]Anweisung überall in die Konfiguration ein, wo die in einer Konfigurationsgruppe enthaltenen Konfigurationsanweisungen benötigt werden.
Erstellen einer Konfigurationsgruppe
Über Junos OS die CLI können Sie wiederverwendbare Gruppen erstellen, die Konfigurationsanweisungen enthalten. Sie können diese Gruppen auf verschiedene Abschnitte der Konfiguration anwenden, in denen dieselben Konfigurationsanweisungen mehrmals wiederholt werden.
Wenn Sie die Gruppe in verschiedenen Abschnitten der Konfiguration anwenden, erbt dieser Teil der Konfiguration die in der Gruppe konfigurierten Anweisungen. Konfigurationsgruppen folgen der Vererbungsregel, wobei die dynamische, laufende Beziehung zwischen der Quelle der Konfigurationsdaten und dem Ziel dieser Daten festgelegt wird. Wenn Sie die Datenwerte in der Konfigurationsgruppe ändern, spiegelt das geerbte Ziel die Änderungen automatisch wider.
Sie können die Werte bei Bedarf in der Zielkonfiguration überschreiben, was sich nicht auf die Quelle in der Gruppe auswirkt.
Mit diesem Vererbungsmodell können Sie nur die instanzspezifischen Informationen anzeigen, ohne die erbenten Details anzuzeigen. Über eine Befehlszeile im Konfigurationsmodus können Sie die geerbten Daten anzeigen. Sie können beispielsweise alle Schnittstellen ge-0/0/1 für den MTU-Wert 1500 konfigurieren.
So konfigurieren Sie alle Ihre ge-0/0/1 Schnittstellen für den MTU-Wert 1500:
-
Erstellen Sie eine Gruppe mit dem MTU-Wert 1500:
[edit groups group-1] lab@vSRX3-05# show interfaces { ge-0/0/1 { unit 0 { family inet { mtu 1500; } } } } -
Als nächstes wenden Sie die Gruppe in der Schnittstellenkonfiguration an.
[edit interfaces ge-0/0/1] lab@vSRX3-05# set apply-groups group-1
-
Zeigen Sie die geerbte Konfiguration an.
[edit] lab@vSRX3-05# show interfaces ge-0/0/1 | display inheritance unit 0 { family inet { ## ## '1500' was inherited from group 'group-1' ## mtu 1500; address 5.0.0.254/24; } }
Wenn Sie den MTU-Wert für Schnittstelle ge-0/0/1 in verschiedenen Teilen der Konfiguration konfigurieren möchten, können Sie die Gruppenaussage mithilfe der apply-groups Option anwenden. Wenn Sie dies manuell tun und später die MTU erhöhen möchten, müssen Sie möglicherweise jede Schnittstelle manuell ändern. Wenn Sie eine Konfigurationsgruppe verwenden, können Sie die Gruppenkonfiguration ändern, wodurch alle zugehörigen Schnittstellen automatisch aktualisiert werden.
Sie können auch Wildcards in einer Konfigurationsgruppe verwenden, um zu erlauben, dass Konfigurationsdaten von jedem Objekt geerbt werden, das einem Wildcard-Ausdruck entspricht. Zum Beispiel:
[edit groups group-1]
lab@vSRX3-05# show
interfaces {
ge-* {
unit 0 {
family inet {
mtu 1500;
}
}
}
}So wenden Sie eine Konfigurationsgruppe an
Wenn Eine Gerätekonfiguration von Juniper Networks die Anweisungen von einer Konfigurationsgruppe erben soll, fügen Sie die apply-groups Anweisung in die Konfiguration ein.
apply-groups [ group-names ];
Wenn Sie mehr als einen Gruppennamen angeben, müssen Sie die Namen in der Reihenfolge der Vererbungspriorität auflisten. Die Konfigurationsdaten in der ersten Gruppe haben Vorrang vor den Daten in den nachfolgenden Gruppen.
Für Geräte, die mehrere Routing-Engines unterstützen, können Sie Namen und re1 Gruppennamen angebenre0. Die in der Gruppe re0 angegebene Konfiguration wird nur angewendet, wenn sich die aktuelle Routing-Engine in Steckplatz 0 befindet. Ebenso wird die in der Gruppe re1 angegebene Konfiguration nur angewendet, wenn sich die aktuelle Routing-Engine in Steckplatz 1 befindet. Daher können beide Routing-Engines dieselbe Konfigurationsdatei verwenden, die jeweils nur die Konfigurationsanweisungen verwendet, die für sie gelten. Jede re0 Gruppe re1 enthält mindestens die Konfiguration für den Hostnamen und die Verwaltungsschnittstelle (fxp0). Wenn jede Routing-Engine eine andere Verwaltungsschnittstelle verwendet, sollte die Gruppe auch die Konfiguration für den Backup-Router und die statischen Routen enthalten.
Sie können nur eine apply-groups Anweisung auf jeder bestimmten Ebene der Konfigurationshierarchie einschließen. Die apply-groups Anweisung auf einer bestimmten Hierarchieebene listet die Konfigurationsgruppen auf, die der Liste der Konfigurationsgruppen der Containing-Anweisung hinzugefügt werden sollen.
Werte, die auf der spezifischen Hierarchieebene angegeben wurden, überschreiben werte, die von der Konfigurationsgruppe geerbt wurden.
Gruppen, die in geschachtelten apply-groups Anweisungen aufgeführt sind, haben Vorrang vor Gruppen in äußeren Anweisungen. Im folgenden Beispiel erbt der BGP-Nachbarn 10.0.0.1 zuerst Konfigurationsdaten von der Gruppe one . Anschließend erbt es Konfigurationsdaten von Gruppe two und Gruppe three. Konfigurationsdaten in einer Gruppe one überschreiben Daten in einer anderen Gruppe. Daten aus der Gruppe ten werden nur verwendet, wenn eine Anweisung in keiner anderen Gruppe enthalten ist.
apply-groups [ eight nine ten ];
protocols {
apply-groups seven;
bgp {
apply-groups [ five six ];
group some-bgp-group {
apply-groups four;
neighbor 10.0.0.1 {
apply-groups [ one two three ];
}
}
}
}
Die Root-Ebene ist das logische Standardsystem. Wenn Sie eine für die Root-Ebene definierte Gruppe konfigurieren, können Sie diese Gruppe nicht erfolgreich auf ein logisches System ohne Standard unter der [edit logical-systems logical-system-name] Hierarchieebene anwenden. Obwohl das Gerät den Commit akzeptiert, wenn Sie die Gruppe anwenden, wird die Konfigurationsgruppe für das logische System ohne Standard nicht wirksam. Sie können stattdessen eine zusätzliche Konfigurationsgruppe auf der Root-Ebene erstellen und diese innerhalb des logischen Systems anwenden. Alternativ können Sie die ursprüngliche Gruppe so ändern, dass sie die Konfiguration sowohl für die Standard- als auch für nicht standardmäßige Systemhierarchieebene enthält.
Beispiel: Erstellen und Anwenden von Konfigurationsgruppen
Dieses Beispiel veranschaulicht die Erstellung und Anwendung von Konfigurationsgruppen. In diesem Beispiel wird die SNMP-Konfiguration zwischen der Gruppe basic und der normalen Konfigurationshierarchie aufgeteilt.
Sie erhalten mehrere Vorteile, indem Sie die systemspezifische Konfiguration (SNMP-Kontakt) in eine Konfigurationsgruppe eingliedern und sie so von der normalen Konfigurationshierarchie trennen:
-
Sie können einen Abschnitt ersetzen, ohne Daten von dem anderen zu verwerfen, indem Sie den
load replaceBefehl verwenden. -
Sie können einen Kontakt für ein bestimmtes Feld festlegen, da die Gruppendaten durch die gerätespezifischen Daten ausgeblendet werden.
[edit] groups { basic { # User-defined group name snmp { # This group contains some SNMP data contact "My Engineering Group"; community BasicAccess { authorization read-only; } } } } apply-groups basic; # Enable inheritance from group "basic" snmp { # Some normal (non-group) configuration location "West of Nowhere"; }
Diese Konfiguration entspricht der folgenden:
[edit]
snmp {
location "West of Nowhere";
contact "My Engineering Group";
community BasicAccess {
authorization read-only;
}
}
Beispiel: Deaktivieren der Vererbung einer Konfigurationsgruppe
Sie können die Vererbung einer Konfigurationsgruppe auf jeder Ebene außer der obersten Ebene der Hierarchie deaktivieren. Um die Vererbung zu deaktivieren, fügen Sie die apply-groups-except Anweisung in die Konfiguration ein:
apply-groups-except [ group-names ];
Diese Anweisung ist nützlich, wenn Sie die apply-group Anweisung auf einer bestimmten Hierarchieebene verwenden, aber auch die von der Konfigurationsgruppe für einen bestimmten Parameter übernommenen Werte überschreiben möchten.
Beispiel: Vererbung auf Schnittstelle so-1/1/0 deaktivieren
Im folgenden Beispiel wird die apply-groups Anweisung global auf Schnittstellenebene angewendet. Die apply-groups-except Anweisung wird auch auf die Schnittstelle so-1/1/0 angewendet, sodass sie die Standardwerte für die Anweisungen und link-mode anweisungen hold-time verwendet.
[edit]
groups { # "groups" is a top-level statement
global { # User-defined group name
interfaces {
<*> {
hold-time down 640;
link-mode full-duplex;
}
}
}
}
apply-groups global;
interfaces {
so-1/1/0 {
apply-groups-except global; # Disables inheritance from group "global"
# so-1/1/0 uses default value for “hold-time”
# and "link-mode"
}
}
Konfigurationsgruppen können zu verwirrungen hinsichtlich der tatsächlichen Werte, die vom Gerät verwendet werden, schaffen, da ein Gerät Konfigurationsdaten von Konfigurationsgruppen erben kann. Um die tatsächlichen Werte anzuzeigen, die vom Gerät verwendet werden, verwenden Sie den display inheritance Befehl nach der Pipe (|) in einem show Befehl. Dieser Befehl zeigt die geerbten Anweisungen auf der Ebene an, auf der sie geerbt werden, und der Gruppe, von der sie geerbt wurden:
[edit]
user@host# show | display inheritance
snmp {
location "West of Nowhere";
##
## 'My Engineering Group' was inherited from group 'basic'
##
contact "My Engineering Group";
##
## 'BasicAccess' was inherited from group 'basic'
##
community BasicAccess {
##
## 'read-only' was inherited from group 'basic'
##
authorization read-only;
}
}
Um die erweiterte Konfiguration (die Konfiguration, einschließlich der geerbten Anweisungen) ohne die ##-Zeilen anzuzeigen, verwenden Sie den except Befehl nach der Pipe in einem show Befehl:
[edit]
user@host# show | display inheritance | except ##
snmp {
location "West of Nowhere";
contact "My Engineering Group";
community BasicAccess {
authorization read-only;
}
}
Wenn Sie die display inheritance | except ## Option verwenden, werden alle Zeilen mit ##entfernt. Daher können Sie möglicherweise keine Informationen zu Passwörtern oder anderen wichtigen Daten anzeigen, in denen ## sie verwendet werden. Um die vollständigen Konfigurationsdetails mit allen Informationen anzuzeigen (ohne dass nur die Kommentare mit ##markiert sind), verwenden Sie die no-comments Option mit dem display inheritance Folgenden Befehl:
[edit]
user@host# show | display inheritance no-comments
snmp {
location "West of Nowhere";
contact "My Engineering Group";
community BasicAccess {
authorization read-only;
}
}
Beispiel: Verwenden der junos-defaults Konfigurationsgruppe
Junos OS stellt eine versteckte und unveränderliche Konfigurationsgruppe bereit junos-defaults , die automatisch auf die Konfiguration Ihres Geräts angewendet wird. Die junos-defaults Gruppe enthält vorkonfigurierte Anweisungen, die vordefinierte Werte für gemeinsame Anwendungen enthalten. Einige der Anweisungen müssen referenziert werden, um wirksam zu werden, z. B. Definitionen für Anwendungen (z. B. FTP- oder Telnet-Einstellungen). Andere Anweisungen werden automatisch angewendet, z. B. Terminaleinstellungen.
Viele in der junos-defaults Konfigurationsgruppe enthaltene Bezeichner beginnen mit dem Namen junos-. Da Bezeichner, die mit dem Namen junos- beginnen, für die Verwendung durch Juniper Networks reserviert sind, können Sie keine Konfigurationsobjekte mit diesem Namen definieren.
Sie können keinen Konfigurationsgruppennamen in eine apply-groups Anweisung aufnehmenjunos-defaults.
Um den vollständigen Satz der verfügbaren voreingestellten Anweisungen aus der junos-defaults Gruppe anzuzeigen, gibt Sie den show groups junos-defaults Befehl konfigurationsmodus auf der obersten Ebene der Konfiguration aus. Im folgenden Beispiel wird eine unvollständige Liste von Junos-Standardgruppen angezeigt:
user@host# show groups junos-defaults
# Make vt100 the default for the console port
system {
ports {
console type vt100;
}
}
applications {
# File Transfer Protocol
application junos-ftp {
application-protocol ftp;
protocol tcp;
destination-port 21;
}
# Trivial File Transfer Protocol
application junos-tftp {
application-protocol tftp;
protocol udp;
destination-port 69;
}
# RPC port mapper on TCP
application junos-rpc-portmap-tcp {
application-protocol rpc-portmap;
protocol tcp;
destination-port 111;
}
# RPC port mapper on UDP
}
Um von der junos-defaults Gruppe verfügbare Referenzanweisungen zu erhalten, fügen Sie die ausgewählte junos- default-name Anweisung auf der entsprechenden Hierarchieebene ein.
Beispiel: Verwenden von Wildcards mit Konfigurationsgruppen
Sie können Wildcards verwenden, um Namen zu identifizieren und einer Anweisung zu erlauben, Daten für eine Vielzahl von Anweisungen bereitzustellen.
Die Verwendung von Wildcards in normalen Konfigurationsdaten erfolgt in einem Stil, der mit dem herkömmlichen UNIX-Shell-Wildcards übereinstimmt. In diesem Stil können Sie die folgenden Metazeichen verwenden:
-
Sternchen (
*) – Entspricht jeder Zeichenfolge. -
Fragezeichen (
?) – Entspricht jedem einzelnen Zeichen. -
Offene Klammer (
[) – Führt eine Zeichenklasse ein. -
Klammer schließen (
]) – Gibt das Ende einer Zeichenklasse an. Wenn die Schließen-Klammer fehlt, entspricht die offene Klammer einer offenen Klammer[, anstatt eine Zeichenklasse einzuführen. -
Eine Zeichenklasse entspricht jedem der Zeichen zwischen den eckigen Klammern. In einer Konfigurationsgruppe müssen Sie einen Schnittstellennamen, der eine Zeichenklasse enthält, in Anführungszeichen setzen.
-
Bindestrich (
-) – Gibt einen Bereich von Zeichen an. -
Ausrufezeichen (
!): Sie können die Zeichenklasse ergänzen, indem Sie als erstes Zeichen der Zeichenklasse ein Ausrufezeichen machen. Um eine Klammer (]) in eine Zeichenklasse einzuschließen, machen Sie dies als erstes Zeichen (nach dem!, falls vorhanden). Um ein Minuszeichen einzugeben, machen Sie es als erstes oder letztes Zeichen aufgeführt.
Wenn Sie einen Bezeichner innerhalb der groups Hierarchie verwenden, starten Sie den Kennungsnamen mit etwas anderem als <. Wenn Sie jedoch eine Wildcard-Anweisung definieren, können Sie verwenden < , da die Wildcard-Anweisung eine schließende >.
Die Verwendung von Wildcards in Konfigurationsgruppen folgt den gleichen Regeln wie die Verwendung für die normale Konfiguration. Sie haben jedoch eine besondere Bedeutung, <> wenn sie in der groups Hierarchie verwendet wird. In der groups Hierarchie müssen Sie jeden Begriff in winkelige Klammern einschließen, der ein <pattern verwendet> um ihn von anderen Wildcards in der Konfigurationsdatei zu unterscheiden.
[edit]
groups {
sonet-default {
interfaces {
<so-*> {
sonet-options {
payload-scrambler;
rfc-2615;
}
}
}
}
}
Wildcard-Ausdrücke stimmen vorhandene Anweisungen in der Konfiguration ab und stellen Konfigurationsdaten bereit, die nur ihrem Ausdruck entsprechen. Im vorherigen Beispiel übergibt der Ausdruck <so-*> seine sonet-options Anweisung an eine beliebige Schnittstelle, die mit dem Ausdruck so-*übereinstimmt.
Das folgende Beispiel zeigt, wie sie eine Reihe von Schnittstellen angeben:
[edit]
groups {
gigabit-ethernet-interfaces {
interfaces {
"<ge-1/2/[5-8]>" {
description "These interfaces reserved for Customer ABC";
}
}
}
}
Mit winkeligen Klammern können Sie normale Wildcards ohne Änderungen passieren. Bei jedem Abgleich innerhalb der Konfiguration, unabhängig davon, ob sie mit oder ohne Wildcards erfolgt, wird das erste Element in der konfiguration verwendet, das übereinstimmt. Im folgenden Beispiel werden Die Daten aus den BGP-Gruppen mit Wildcards in der Reihenfolge geerbt, in der die Gruppen aufgelistet sind.
- Der Präferenzwert von überschreibt
<*a*>die Voreinstellung in<*b*>. - Der
pWert von<*c*>überschreibt den von<*d*>
Datenwerte einer dieser Gruppen überschreiben die Datenwerte von abcd:
[edit] user@host#showgroups { one { protocols { bgp { group <*a*> { preference 1; } group <*b*> { preference 2; } group <*c*> { out-delay 3; } group <*d*> { out-delay 4; } group abcd { preference 10; hold-time 10; out-delay 10; } } } } } protocols { bgp { group abcd { apply-groups one; } } } [edit] user@host#show | display inheritanceprotocols { bgp { group abcd { ## ## ’1’ was inherited from group ’one’ ## preference 1; ## ## ’10’ was inherited from group ’one’ ## hold-time 10; ## ## ’3’ was inherited from group ’one’ ## out-delay 3; } } }
So verbessern Sie die Commit-Zeit bei der Verwendung von Konfigurationsgruppen
Sie verwenden Konfigurationsgruppen, um Konfigurationen über andere Hierarchien hinweg anzuwenden, ohne Konfigurationsdaten erneut einzugeben. Sie können alle Konfigurationsdetails in einer Konfigurationsgruppe angeben. Sie können auch Wildcards in Konfigurationsgruppen verwenden, um Datenbereiche zu konfigurieren, ohne die einzelnen Konfigurationszeilen detailliert zu beschreiben. Eine weitere Möglichkeit, Konfigurationsgruppen zu verwenden, besteht darin, einen Vererbungspfad zu erstellen, der eine lange Zeichenfolge von zu anwendenden Konfigurationen enthält.
Wenn eine Konfiguration, die Konfigurationsgruppen verwendet, festgelegt wird, erweitert sich der Commit-Prozess und liest alle Konfigurationsdaten der Gruppe in den Speicher, um die Konfigurationen wie vorgesehen anzuwenden. Die Commit-Leistung kann negativ beeinflusst werden, wenn viele Konfigurationsgruppen angewendet werden, insbesondere, wenn die Konfigurationsgruppen weitgehend Wildcards verwenden.
Wenn Ihr System viele Konfigurationsgruppen verwendet, die Wildcards verwenden, können Sie die persist-groups-inheritance Anweisung auf Hierarchieebene konfigurieren, um die [edit system commit] Leistung der Commit-Zeit zu verbessern.
Mithilfe dieser Option kann das System den Vererbungspfad für jede Konfigurationsgruppe innerhalb der Datenbank und nicht im Prozessspeicher erstellen. Diese Änderung kann die Leistung der Commit-Zeit verbessern. Es kann jedoch auch die Datenbankgröße erhöhen.
Beispiel: Konfigurieren von Anweisungen mit Konfigurationsgruppen
Wenn Sätze von Anweisungen in Konfigurationsgruppen vorhanden sind, werden alle Werte geerbt. Zum Beispiel:
[edit] user@host#showgroups { basic { snmp { interface so-1/1/1.0; } } } apply-groups basic; snmp { interface so-0/0/0.0; } [edit] user@host#show | display inheritancesnmp { ## ## ’so-1/1/1.0’ was inherited from group ’basic’ ## interface [ so-0/0/0.0 so-1/1/1.0 ]; }
Für Sätze, die nicht in Klammern angezeigt werden, werden auch alle Werte vererbt. Zum Beispiel:
[edit] user@host#showgroups { worldwide { system { name-server { 10.0.0.100; 10.0.0.200; } } } } apply-groups worldwide; system { name-server { 10.0.0.1; 10.0.0.2; } } [edit] user@host#show | display inheritancesystem { name-server { ## ## ’10.0.0.100’ was inherited from group ’worldwide’ ## 10.0.0.100; ## ## ’10.0.0.200’ was inherited from group ’worldwide’ ## 10.0.0.200; 10.0.0.1; 10.0.0.2; } }
Beispiel: Konfigurieren von Schnittstellen mithilfe von Konfigurationsgruppen
Sie können Konfigurationsgruppen verwenden, um die allgemeinen Schnittstellenmedienparameter von den schnittstellenspezifischen Adressinformationen zu trennen. Im folgenden Beispiel werden Konfigurationsdaten für ATM-Schnittstellen in eine Gruppe namens atm-options.
[edit] user@host#showgroups { atm-options { interfaces { <at-*> { atm-options { vpi 0 maximum-vcs 1024; } unit <*> { encapsulation atm-snap; point-to-point; family iso; } } } } } apply-groups atm-options; interfaces { at-0/0/0 { unit 100 { vci 0.100; family inet { address 10.0.0.100/30; } } unit 200 { vci 0.200; family inet { address 10.0.0.200/30; } } } } [edit] user@host#show | display inheritanceinterfaces { at-0/0/0 { ## ## "atm-options" was inherited from group "atm-options" ## atm-options { ## ## "1024" was inherited from group "atm-options" ## vpi 0 maximum-vcs 1024; } unit 100 { ## ## "atm-snap" was inherited from group "atm-options" ## encapsulation atm-snap; ## ## "point-to-point" was inherited from group "atm-options" ## point-to-point; vci 0.100; family inet { address 10.0.0.100/30; } ## ## "iso" was inherited from group "atm-options" ## family iso; } unit 200 { ## ## "atm-snap" was inherited from group "atm-options" ## encapsulation atm-snap; ## ## "point-to-point" was inherited from group "atm-options" ## point-to-point; vci 0.200; family inet { address 10.0.0.200/30; } ## ## "iso" was inherited from group "atm-options" ## family iso; } } } [edit] user@host#show | display inheritance | except ##interfaces { at-0/0/0 { atm-options { vpi 0 maximum-vcs 1024; } unit 100 { encapsulation atm-snap; point-to-point; vci 0.100; family inet { address 10.0.0.100/30; } family iso; } unit 200 { encapsulation atm-snap; point-to-point; vci 0.200; family inet { address 10.0.0.200/30; } family iso; } } }
Siehe auch
Beispiel: Konfigurieren Einer konsistenten IP-Adresse für die Verwaltungsschnittstelle mithilfe von Konfigurationsgruppen
Auf Geräten mit mehreren Routing-Engines wird jede Routing-Engine mit einer separaten IP-Adresse für die Verwaltungsschnittstelle konfiguriert. Um auf die primäre Routing-Engine zuzugreifen, müssen Sie wissen, welche Routing-Engine aktiv ist, und die entsprechende IP-Adresse verwenden.
Eine weitere Option für einen konsistenten Zugriff auf die primäre Routing-Engine ist die Konfiguration einer zusätzlichen IP-Adresse. Diese Adresse verwenden Sie dann für die Verwaltungsschnittstelle, unabhängig davon, welche Routing-Engine aktiv ist. Diese zusätzliche IP-Adresse ist nur auf der Verwaltungsschnittstelle der primären Routing-Engine aktiv. Während des Switchovers wird die Adresse zur neuen primären Routing-Engine verschoben.
In diesem Beispiel wird die Adresse 10.17.40.131 für beide Routing-Engines konfiguriert und eine master-only Anweisung enthalten. Bei dieser Konfiguration ist die 10.17.40.131 Adresse nur in der primären Routing-Engine aktiv. Die Adresse bleibt unabhängig davon, welche Routing-Engine aktiv ist, konsistent. Die Adresse 10.17.40.132 ist on re0und 10.17.40.133fxp0 wird auf zugewiesen fxp0re1.
[edit groups re0 interfaces fxp0]
unit 0 {
family inet {
address 10.17.40.131/25 {
master-only;
}
address 10.17.40.132/25;
}
}
[edit groups re1 interfaces fxp0]
unit 0 {
family inet {
address 10.17.40.131/25 {
master-only;
}
address 10.17.40.133/25;
}
}
Diese Funktion ist auf allen Routern verfügbar, die zwei Routing-Engines enthalten. In einer Routing-Matrix, die aus dem TX-Matrix-Router besteht, ist diese Funktion nur für das Switch-Card-Chassis (SCC) anwendbar. In einer Routing-Matrix, die aus einem TX Matrix Plus-Router besteht, ist diese Funktion nur für das Switch-Fabric-Chassis (SFC) anwendbar.
-
Sie müssen eindeutigen IP-Adressen für zwei Schnittstellen zuweisen, die doppelte Adressen auf privaten und öffentlichen Schnittstellen aufweisen. Wenn graceful Routing Engine Switchover (GRES) aktiviert ist, zeigt die CLI eine entsprechende Commit-Fehlermeldung an, wenn identische Adressen gefunden werden. Dieser Fehler kann auftreten, wenn Sie dieselbe IP-Adresse für eine Verwaltungs- oder interne Schnittstelle wie
fxp0und eine externe physische Schnittstelle wiege-0/0/1. -
Die
em0Ethernet-Managementschnittstelle wird für den TX Matrix Plus-Router, T1600-Router in einer Routing-Matrix und Paketübertragungs-Router der PTX-Serie verwendet. Junos OS Erstellt automatisch die Management-Ethernet-Schnittstelle des Geräts,em0.
Beispiel: Konfigurationsgruppen zur Konfiguration von Peer-Entitäten verwenden
In diesem Beispiel wird eine Gruppe some-isp erstellt, die Konfigurationsdaten für einen anderen ISP enthält. Dann fügt es An verschiedenen Punkten Anweisungen ein apply-group , damit die Standorte in der Konfigurationshierarchie diese Daten erben können.
[edit] user@host#showgroups { some-isp { interfaces { <xe-*> { gigether-options { flow-control; } } } protocols { bgp { group <*> { neighbor <*> { remove-private; } } } pim { interface <*> { version 1; } } } } } interfaces { xe-0/0/0 { apply-groups some-isp; unit 0 { family inet { address 10.0.0.1/24; } } } } protocols { bgp { group main { neighbor 10.254.0.1 { apply-groups some-isp; } } } pim { interface xe-0/0/0.0 { apply-groups some-isp; } } } [edit] user@host#show | display inheritanceinterfaces { xe-0/0/0 { ## ## "gigether-options" was inherited from group "some-isp" ## gigether-options { ## ## "flow-control" was inherited from group "some-isp" ## flow-control; } unit 0 { family inet { address 10.0.0.1/24; } } } } protocols { bgp { group main { neighbor 10.254.0.1 { ## ## "remove-private" was inherited from group "some-isp" ## remove-private; } } } pim { interface xe-0/0/0.0 { ## ## "1" was inherited from group "some-isp" ## version 1; } } }
Beispiel: Verwenden von Konfigurationsgruppen zum Einrichten regionaler Konfigurationen
In diesem Beispiel werden eine Gruppe mit Konfigurationsdaten gefüllt, die im gesamten Unternehmen Standard sind, während eine andere Gruppe regionale Abweichungen von diesem Standard enthält:
[edit] user@host#showgroups { standard { interfaces { <t3-*> { t3-options { compatibility-mode larscom subrate 10; idle-cycle-flag ones; } } } } northwest { interfaces { <t3-*> { t3-options { long-buildout; compatibility-mode kentrox; } } } } } apply-groups standard; interfaces { t3-0/0/0 { apply-groups northwest; } } [edit] user@host#show | display inheritanceinterfaces { t3-0/0/0 { ## ## "t3-options" was inherited from group "northwest" ## t3-options { ## ## "long-buildout" was inherited from group "northwest" ## long-buildout; ## ## "kentrox" was inherited from group "northwest" ## compatibility-mode kentrox; ## ## "ones" was inherited from group "standard" ## idle-cycle-flag ones; } } }
Beispiel: Konfigurieren von Gruppennamen für die Konfiguration von Wildcard-Konfigurationen
Bei Wildcards handelt es sich um Konfigurationsgruppennamen, die Sonderzeichen verwenden, um ein Muster zu erstellen, das Sie auf mehrere Anweisungen anwenden können. Wildcards sind nützlich, um eine Reihe von Konfigurationsoptionen in viele verschiedene Konfigurationsgruppen zu kopieren. Sie müssen ihren Wildcard-Namen richtig einrichten, um sicherzustellen, dass die Konfigurationsoptionen für den Wildcard-Betrieb in die entsprechenden Konfigurationsgruppen kopiert werden.
In diesem Beispiel werden unterschiedliche Werte für die <*-major><*-minor> Wildcard-Gruppen unter der label-switched-path Anweisung konfiguriert. Das Sternchen (*) stellt einen Abschnitt des Wildcard-Namens dar, der mit jeder beliebigen Zeichenzeichenfolge übereinstimmen kann. Beispielsweise werden die unteren label-switched-path <*-major> Konfigurationsoptionen an label-switched-path metro-major und jede andere label-switched-path Konfigurationsgruppe, die in ihrem Namen enthalten ist -major , weitergegeben.
[edit] user@host#showgroups { mpls-conf { protocols { mpls { label-switched-path <*-major> { retry-timer 5; bandwidth 155m; optimize-timer 60; } label-switched-path <*-minor> { retry-timer 15; bandwidth 64k; optimize-timer 120; } } } } } apply-groups mpls-conf; protocols { mpls { label-switched-path metro-major { to 10.0.0.10; } label-switched-path remote-minor { to 10.0.0.20; } } } [edit] user@host#show | display inheritanceprotocols { mpls { label-switched-path metro-major { to 10.0.0.10; ## ## "5" was inherited from group "mpls-conf" ## retry-timer 5; ## "155m" was inherited from group "mpls-conf" ## bandwidth 155m; ## ## "60" was inherited from group "mpls-conf" ## optimize-timer 60; } label-switched-path remote-minor { to 10.0.0.20; ## ## "15" was inherited from group "mpls-conf" ## retry-timer 15; ## ## "64k" was inherited from group "mpls-conf" ## bandwidth 64k; ## ## "120" was inherited from group "mpls-conf" ## optimize-timer 120; } } }
Beispiel: Verweisen Sie auf die voreingestellte Anweisung aus der Gruppe "Standard".
Das folgende Beispiel ist eine voreingestellte Anweisung aus der Standardgruppe, die für FTP in einer zustandsbehafteten Firewall verfügbar ist:
[edit]
groups {
junos-defaults {
applications {
application junos-ftp {# Use FTP default configuration
application-protocol ftp;
protocol tcp;
destination-port 21;
}
}
}
Um auf eine voreingestellte Standardaussage aus der Standardgruppe zu verweisen, fügen Sie die junos-default-name Anweisung auf der entsprechenden Hierarchieebene ein. Wenn Sie beispielsweise auf die Standardaussage für FTP in einer zustandsbehafteten Firewall verweisen möchten, fügen Sie die junos-ftp Anweisung auf [edit services stateful-firewall rule my-rule term my-term from applications] Hierarchieebene ein:
[edit]
services {
stateful-firewall {
rule my-rule {
term my-term {
from {
applications junos-ftp; #Reference predefined statement, junos-ftp
}
}
}
}
}
Beispiel: Anzeigen von Standardanweisungen, die auf die Konfiguration angewendet wurden
Um die Standardeinstellungen anzuzeigen, die auf die Gerätekonfiguration angewendet wurden, gibt Sie den show | display inheritance defaults Befehl aus. In diesem Beispiel werden die geerbten Standardeinstellungen auf [edit system ports] Hierarchieebene angezeigt:
user@host# show system ports | display inheritance defaults
## ## 'console' was inherited from group 'junos-defaults'
## 'vt100' was inherited from group 'junos-defaults'
## console type vt100;
Wenn Sie keine vorhandenen Standardanweisungen verwenden, können Sie Ihre eigenen Konfigurationsgruppen manuell erstellen.
Verwenden Sie no-comments die Option mit dem Befehl, um die vollständigen Konfigurationsinformationen anzuzeigen, ohne kommentare, die mit ##markierten display inheritance Kommentaren auszulassen.
Einrichten von Routing-Engine-Konfigurationsgruppen
In einem Gerät mit zwei Routing-Engines sollten beide Routing-Engines eine Konfiguration gemeinsam haben. Mit dieser Einrichtung wird sichergestellt, dass beide Routing-Engine-Konfigurationen identisch sind. Erstellen Sie in dieser Konfiguration zwei Routing-Engine-Gruppen, eine für jede Routing-Engine. Innerhalb dieser Gruppen geben Sie die spezifischen Parameter der Routing-Engine an.
Weitere Informationen zur Erstkonfiguration für redundante Routing-Engine-Systeme und die re0-Gruppe finden Sie im Junos OS-Benutzerhandbuch für hohe Verfügbarkeit.
So richten Sie eine Konfigurationsgruppe für die Routing-Engine ein:
So verwenden Sie Bedingungen zum Anwenden von Konfigurationsgruppen
Sie können die when Anweisung auf Hierarchieebene [edit groups group-name] verwenden, um Bedingungen zu definieren, unter denen eine Konfigurationsgruppe angewendet werden soll.
Sie können eine Gruppe so konfigurieren, dass sie angewendet wird, basierend auf dem Typ des Gehäuses, des Modells oder der Routing-Engine, dem Virtual Chassis-Mitglied , dem Cluster-Knoten und der Start- und optionalen Endzeit des Tages oder Datums.
Sie können beispielsweise die when Anweisung verwenden, um eine generische Konfigurationsgruppe für jeden Knotentyp zu erstellen und dann die Konfiguration basierend auf bestimmten Knoteneigenschaften wie Gehäuse oder Modell anzuwenden.
Beispiel: Konfigurationsbedingungen für die Anwendung von Konfigurationsgruppen
In diesem Beispiel wird gezeigt, wie Bedingungen konfiguriert werden, unter denen eine angegebene Konfigurationsgruppe angewendet werden soll.
Anforderungen
Vor der Konfiguration dieses Beispiels ist keine spezielle Konfiguration erforderlich, die über die Geräteinitialisierung hinausgeht.
Überblick
Sie können Ihre Gruppenkonfigurationsdaten auf [edit groups group-name] Hierarchieebene konfigurieren. Sie können dann die when Anweisung verwenden, um die Gruppenkonfiguration basierend auf Bedingungen wie den folgenden anzuwenden: Gehäusetyp, Modell, Routing-Engine, Virtual Chassis-Mitglied, Cluster-Knoten, Start- und optional Endzeit des Tages oder Datums.
Wenn Sie mehrere Bedingungen in einer einzigen Konfigurationsgruppe angeben, müssen alle Bedingungen erfüllt sein, bevor die Konfigurationsgruppe angewendet wird.
Sie können die Startzeit oder die Zeitdauer für die Anzuwendenden Konfigurationsgruppe angeben. Wenn nur die Startzeit angegeben wird, wird die Konfigurationsgruppe zu dem angegebenen Zeitpunkt angewendet und bleibt in Kraft, bis der Zeitpunkt geändert wird. Wenn die Endzeit angegeben wird, wird an jedem Tag die angewendete Konfigurationsgruppe gestartet und zu den angegebenen Zeiten beendet.
In diesem Beispiel werden die Bedingungen in einer Konfigurationsgruppe festgelegt, sodass diese Gruppe nur angewendet wird, test1wenn alle folgenden Bedingungen erfüllt sind: der Router ist ein Modell MX240-Router mit Gehäusetyp LCC0, wobei eine Routing-Engine als RE0 arbeitet, Mitglied des virtuellen Chassis auf Node0 ist und die Konfigurationsgruppe nur von 9:00 Uhr bis 17:00 Uhr jeden Tag in Kraft ist.
Konfiguration
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen sie in eine Textdatei ein, entfernen alle Zeilenumbrüche, ändern alle erforderlichen Details, um mit Ihrer Netzwerkkonfiguration zu übereinstimmen, und kopieren Sie dann die Befehle und fügen sie auf Hierarchieebene in die [edit] CLI ein.
set groups test1 when model mx240set groups test1 when chassis lcc0set groups test1 when routing-engine re0set groups test1 when member member0set groups test1 when node node0set groups test1 when time 9 to 5
Verfahren
Schritt-für-Schritt-Verfahren
So konfigurieren Sie Bedingungen für die Konfigurationsgruppe test1:
Legen Sie die Bedingung fest, die den Router MX240 des Modells identifiziert.
[edit groups test1 when] user@host#
set model mx240Legen Sie die Bedingung, die den Gehäusetyp als LCC0 identifiziert, fest.
[edit groups test1 when] user@host#
set chassis lcc0Legen Sie die Bedingung fest, die die Routing-Engine identifiziert, die als
RE0.[edit groups test1 when] user@host#
set routing-engine re0Legen Sie die Bedingung fest, die das Virtual Chassis
member0identifiziert.[edit groups test1 when] user@host#
set member member0Legen Sie die Bedingung fest, die den Cluster
node0identifiziert.[edit groups test1 when] user@host#
set node node0Legen Sie die Bedingung fest, die die Gruppe nur zwischen 9:00 Uhr und 17:00 Uhr täglich anwendet.
[edit groups test1 when] user@host#
set time 9 to 5HINWEIS:Die Syntax für die Angabe der Zeit lautet:
time <start-time> [to <end-time>]im Zeitformat yyyy-mm-dd.hh:mm, hh:mm oder hh.Commit der Konfiguration.
user@host#
commit
Ergebnisse
Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie den show groups test1 Befehl eingeben. Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
user@host# show groups test1
when {
time 9 to 5;
chassis lcc0;
model mx240;
routing-engine re0;
member member0;
node node0;
}
Überprüfung
Gruppenvererbung mit bedingten Daten überprüfen
Zweck
Stellen Sie sicher, dass bedingte Daten aus einer Konfigurationsgruppe bei der Anwendung geerbt werden.
Aktion
Geben Sie den show | display inheritance Betriebsbefehl mit den when Daten aus, um die bedingte Vererbung anzuzeigen. In diesem Beispiel können Sie einen der folgenden Befehle ausstellen, um festzustellen, dass die bedingten Daten geerbt wurden:
user@host>show | display inheritance when model mx240user@host>show | display inheritance when chassis lcc0user@host>show | display inheritance when routing-engine re0user@host>show | display inheritance when member member0user@host>show | display inheritance when node node0user@host>show | display inheritance when time 9 to 5