Auf dieser Seite
Verbessern der Commit-Zeit bei der Verwendung von Konfigurationsgruppen
Beispiel: Konfigurieren von Anweisungen mit Konfigurationsgruppen
Beispiel: Schnittstellenkonfiguration mithilfe von Konfigurationsgruppen
Beispiel: Konfigurieren von Peer Entities mithilfe von Konfigurationsgruppen
Beispiel: Einrichten regionaler Konfigurationen mithilfe von Konfigurationsgruppen
Beispiel: Konfigurieren von Wildcard-Konfigurationsgruppennamen
Beispiel: Bezug auf die voreingestellte Aussage aus der Standardgruppe
Beispiel: Anzeigen von Standardeinstellungen, die auf die Konfiguration angewendet wurden
Verwendung der Bedingungen zur Anwendung von Konfigurationsgruppen
Beispiel: Konfigurationsbedingungen für die Anwendung von Konfigurationsgruppen
Schnelle Konfiguration von Geräten mithilfe von Konfigurationsgruppen
Konfigurationsgruppen werden verwendet, um allgemeine Elemente zu konfigurieren und anzuwenden, die innerhalb der gleichen Konfiguration wieder verwendet werden.
Grundlegende Informationen zu Konfigurationsgruppen
Dieses Thema bietet einen Überblick über Konfigurationsgruppen und das Vererbungsmodell im Junos OS CLI.
Konfigurationsgruppen – Überblick
Konfigurationsgruppen ermöglichen Ihnen das Erstellen einer Gruppe mit Konfigurationserklärungen und die Vererbung der Anweisungen dieser Gruppe im Rest der Konfiguration. Dieselbe Gruppe kann auf verschiedene Abschnitte der Konfiguration angewendet werden, und unterschiedliche Abschnitte der Konfigurationserklärungen einer Gruppe können an verschiedenen Orten in der Konfiguration übernommen werden.
Konfigurationsgruppen ermöglichen das Erstellen kleinerer, logisch erstellter Konfigurationsdateien, wodurch die Konfiguration und Wartung von Konfigurationsgeräten Juniper Networks wird. Beispielsweise können Sie Anweisungen, die an vielen Stellen in der Konfiguration wiederholt werden, beispielsweise bei der Konfiguration von Schnittstellen, gruppieren und dabei Updates auf nur die Gruppe beschränken.
Sie können auch Wildcards in einer Konfigurationsgruppe verwenden, um zu ermöglichen, dass Konfigurationsdaten von einem Objekt übernommen werden, das einem Wildcard-Ausdruck entspricht.
Der Mechanismus für die Konfigurationsgruppen ist von den an anderen Stellen in der Konfiguration verwendeten Gruppen voneinander getrennt, z. B. BGP Gruppen. Konfigurationsgruppen bieten einen allgemeinen Mechanismus, der für die gesamte Konfiguration verwendet werden kann, aber nur dem Junos OS CLI. Die einzelnen Softwareprozesse, die die von der Konfiguration durchgeführten Aktionen ausführen, erhalten das erweiterte Formular der Konfiguration. sind sie nicht mit Konfigurationsgruppen bekannt.
Vererbungsmodell
Konfigurationsgruppen verwenden eine echte Vererbung, zu der eine dynamische, laufende Beziehung zwischen der Quelle der Konfigurationsdaten und dem Ziel dieser Daten gehört. Die in der Konfigurationsgruppe geänderten Datenwerte werden automatisch vom Ziel übernommen. Das Ziel muss keine übernommenen Informationen enthalten. Die erbten Werte können im Ziel jedoch ohne Auswirkungen auf die Quelle, von der sie übernommen wurden, überschreiben.
Dieses Vererbungsmodell ermöglicht ihnen, nur die instanzspezifischen Informationen anzuzeigen, ohne die übernommenen Details anzuzeigen. Eine Befehlspipe im Konfigurationsmodus ermöglicht die Anzeige der übernommenen Daten.
Konfiguration von Konfigurationsgruppen
Damit Bereiche der Konfiguration Konfigurationserklärungen erbn, müssen Sie die Anweisungen zunächst einer Konfigurationsgruppe zuweisen und diese Gruppe dann auf die Ebenen in der Konfigurationshierarchie anwenden, die die Anweisungen erfordern.
Für Bereiche Ihrer Konfiguration, die Konfigurationserklärungen übernehmen:
Konfigurieren Sie Anweisungen in einer Konfigurationsgruppe. Um Konfigurationsgruppen und Vererbung zu konfigurieren, können Sie die Gruppenaussage auf der Hierarchieebene [bearbeiten] mit einteilen:
[edit] groups {group-name{configuration-data; } }Wenden Sie diese Gruppe auf die Ebenen in der Konfigurationshierarchie an, die die Anweisungen erfordern.
Fügen Sie
apply-groups [ group-names ]die Anweisung überall in der Konfiguration ein, in der die Konfigurationsaus anweisungen in einer Konfigurationsgruppe benötigt werden.
Erstellen einer Konfigurationsgruppe
Mit Junos OS CLI können Sie erneut nutzbare Gruppen mit Konfigurationserklärungen erstellen. Sie können diese Gruppen auf verschiedene Abschnitte der Konfiguration anwenden, in denen dieselben Konfigurationserklärungen mehrmals wiederholt werden.
Konfigurationsgruppen ermöglichen das Erstellen kleinerer, logisch erstellter Konfigurationsdateien, wodurch die Konfiguration und Wartung von Gerätekonfigurationen vereinfacht wird. Beispielsweise können Sie Anweisungen, die an vielen Stellen in der Konfiguration wiederholt werden, beispielsweise beim Konfigurieren von Schnittstellen, gruppieren und dabei Updates auf nur die Gruppe beschränken.
Wenn Sie die Gruppe in den verschiedenen Abschnitten der Konfiguration anwenden, erbt dieser Teil der Konfiguration die in dieser Gruppe konfigurierten Anweisungen. Konfigurationsgruppen befolgen die Vererbungsregel, bei der die dynamische, laufende Beziehung zwischen der Quelle der Konfigurationsdaten und dem Ziel dieser Daten festgelegt wird. Wenn Sie die Datenwerte in der Konfigurationsgruppe ändern, werden die Änderungen automatisch im übernommenen Ziel angezeigt.
Sie können bei Bedarf die Werte in der Zielkonfiguration überschreiben, was sich nicht auf die Quelle in der Gruppe auswirken würde.
Dieses Vererbungsmodell ermöglicht ihnen, nur die instanzspezifischen Informationen anzuzeigen, ohne die übernommenen Details anzuzeigen. Eine Befehlspipe im Konfigurationsmodus ermöglicht die Anzeige der übernommenen Daten. Sie können beispielsweise alle Ihre Schnittstellen für den ge-0/0/1 Wert MTU 1500 konfigurieren. Hierzu erstellen Sie eine Gruppe mit dem Wert MTU 1500:
[edit groups group-1]
lab@vSRX3-05# show
interfaces {
ge-0/0/1 {
unit 0 {
family inet {
mtu 1500;
}
}
}
}Anschließend 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 übernommene 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 Wert MTU Schnittstellen in verschiedenen Konfigurationsteilen konfigurieren möchten, können Sie die Gruppenauszug mithilfe der Option ge-0/0/1 "Anwendungsgruppen" anwenden. Wenn Sie dies manuell tun und später die Netzwerkschnittstelle MTU, müssen Sie möglicherweise jede Schnittstelle manuell ändern. Wenn Sie eine Konfigurationsgruppe verwendet hätten, könnten Sie einfach die Gruppenkonfiguration ändern und alle zugehörigen Schnittstellen würden automatisch aktualisiert.
Sie können auch Wildcards in einer Konfigurationsgruppe verwenden, um zu ermöglichen, dass Konfigurationsdaten von einem Objekt übernommen werden, das einem Wildcard-Ausdruck entspricht. Zum Beispiel:
[edit groups group-1]
lab@vSRX3-05# show
interfaces {
ge-* {
unit 0 {
family inet {
mtu 1500;
}
}
}
}Siehe auch
Anwenden einer Konfigurationsgruppe
Um zu einer Juniper Networks Gerätekonfiguration zu führen, die die Anweisungen einer Konfigurationsgruppe übernehmen, fügen Sie die Anweisung apply-groups hinzu:
apply-groups [ group-names ];
Wenn Sie mehr als einen Gruppennamen angeben, listen Sie sie in der Reihenfolge der Vererbungspriorität auf. Die Konfigurationsdaten in der ersten Gruppe haben in den nachfolgenden Gruppen Priorität vor den Daten.
Bei Routern, die mehrere Routingmodule unterstützen, können Sie Namen re0 und re1 Gruppennamen angeben. Die in der Gruppe angegebene Konfiguration wird nur angewendet, wenn sich der aktuelle Routing-Engine in Slot 0 befindet. Gleichermaßen wird die in der Gruppe angegebene Konfiguration nur angewendet, wenn der aktuelle Routing-Engine re0re1 sich in Steckplatz 1 befindet. Daher können beide Routing-Engines dieselbe Konfigurationsdatei verwenden, von denen jede nur die Konfigurationseinstellungen verwendet, die für sie gelten. Jede oder gruppe enthält mindestens die Konfiguration für den Hostnamen und re0 die re1 Verwaltungsschnittstelle ( fxp0 ). Wenn jede Routing-Engine eine andere Verwaltungsschnittstelle verwendet, sollte die Gruppe auch die Konfiguration für den Backup-Router und statische Routen enthalten.
Sie können auf jeder spezifischen Ebene der Konfigurationshierarchie nur eine apply-groups Anweisung enthalten. Die Anweisung auf einer bestimmten Hierarchieebene listet die Konfigurationsgruppen auf, die der Liste mit Konfigurationsgruppen mit apply-groups Anweisungen hinzugefügt werden sollen.
Werte, die auf der spezifischen Hierarchieebene angegeben sind, setzen Wert aus, die aus der Konfigurationsgruppe übernommen wurden.
In verschachtelten Anweisungen aufgeführte Gruppen nehmen in äußeren Anweisungen Priorität vor apply-groups Gruppen. Im folgenden Beispiel erbt der BGP Konfigurationsdaten zuerst aus der Gruppe, dann von 10.0.0.1one Gruppen und twothree . Konfigurationsdaten in Gruppe one setzen Daten in anderen Gruppen außer Kraft. Daten aus Einer ten Gruppe werden nur verwendet, wenn eine Anweisung nicht in einer 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 ];
}
}
}
}
Wenn Sie eine für die Root-Ebene definierte Gruppe konfigurieren ( d. a. im logischen Standardsystem), können Sie diese Gruppe nicht erfolgreich auf ein nicht abwehrfreies logisches System in der Hierarchieebene [edit logical-systems logical-system-name] anwenden. Obwohl der Router das Commit akzeptiert, wenn Sie die Gruppe anwenden, tritt die Konfigurationsgruppe nicht im logischen System wirksam zum Tragen. Sie können stattdessen eine weitere Konfigurationsgruppe auf der Root-Ebene erstellen und diese im logischen System anwenden. Alternativ können Sie die ursprüngliche Gruppe so ändern, dass sie sowohl die Standard- als auch die logische Systemhierarchieebene ohne Ausfallkonfiguration umfasst.
Beispiel: Erstellen und Anwenden von Konfigurationsgruppen
In diesem Beispiel, das die Erstellung und Anwendung von Konfigurationsgruppen zeigt, wird die SNMP-Konfiguration zwischen der Gruppe und der basic normalen Konfigurationshierarchie unterteilt.
Es gibt mehrere Vorteile, die systemspezifische Konfiguration (SNMP-Kontakt) in eine Konfigurationsgruppe zu platzieren und sie somit von der normalen Konfigurationshierarchie zu trennen. Sie können die beiden Abschnitte (mithilfe des Befehls) ersetzen, ohne Daten von der anderen zu load replace verwerfen.
Das Festlegen eines Kontakts für ein bestimmtes Feld ist nun möglich, da die Gruppendaten für die routerspezifischen Daten verborgen bleiben.
[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;
}
}
Siehe auch
Deaktivieren der Vererbung einer Konfigurationsgruppe
Um die Vererbung einer Konfigurationsgruppe auf einer beliebigen Ebene außer der obersten Hierarchieebene zu deaktivieren, fügen Sie die Anweisung apply-groups-except hinzu:
apply-groups-except [ group-names ];
Diese Anweisung ist nützlich, wenn Sie die Anweisung auf einer bestimmten Hierarchieebene verwenden, aber auch die aus der Konfigurationsgruppe übernommenen Werte für einen bestimmten apply-group Parameter außer Kraft setzen möchten.
Beispiel: Deaktivierung der Vererbung der Schnittstelle so-1/1/0
Im folgenden Beispiel wird die apply-groups Anweisung global auf Schnittstellenebene angewendet. Die apply-groups-except Anweisung wird auch an der Schnittstelle so-1/1/0 angewendet, sodass die Standardwerte für die hold-time Anweisungen verwendet link-mode werden.
[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 Einigen Verwirrungen bezüglich der vom Router verwendeten tatsächlichen Werte führen, da Konfigurationsdaten von Konfigurationsgruppen übernommen werden können. Um die vom Router verwendeten werte anzeigen zu können, verwenden Sie den Befehl nach der Pipe display inheritance (|) in einem show Befehl. Dieser Befehl zeigt die übernommenen Anweisungen auf der Ebene, auf der sie übernommen wurden, sowie die Gruppe, von der sie übernommen wurden, an.
[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;
}
}
Verwenden Sie den Befehl nach der Pipe in einem Befehl, um die erweiterte Konfiguration (die Konfiguration einschließlich der übernommenen Anweisungen) ohne die ## Zeilen exceptshow anzuzeigen:
[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 entfernt ## mit. Möglicherweise können Sie auch die Daten zu Kennwörtern und anderen wichtigen Daten, wo sie ## verwendet werden, nicht anzeigen. Um alle Konfigurationsdetails mit allen Informationen ohne die damit markierten Kommentare anzuzeigen, verwenden Sie ## die Option mit dem no-commentsdisplay inheritance Befehl:
[edit]
user@host# show | display inheritance no-comments
snmp {
location "West of Nowhere";
contact "My Engineering Group";
community BasicAccess {
authorization read-only;
}
}
Siehe auch
Verwenden der Konfigurationsgruppe junos defaults
Junos OS und Junos OS bieten eine verborgene und unveränderliche Konfigurationsgruppe namens "Evolved", die automatisch auf die Konfiguration Ihres junos-defaults Routers angewendet wird. Die junos-defaults Gruppe enthält vorkonfigurierte Anweisungen, die vordefinierte Werte für allgemeine Anwendungen enthalten. Einige der Anweisungen müssen zum Erzielen referenziert werden, z. B. Anwendungsdefinitionen (z. B. FTP- oder Telnet-Einstellungen). Andere Anweisungen werden automatisch angewendet, z. B. Terminaleinstellungen.
Viele in der Konfigurationsgruppe enthaltene junos-defaults Kennungen beginnen mit dem junos- Namen. Da Kennungen, die mit dem Namen beginnen, für die Verwendung durch Juniper Networks reserviert werden, können Sie unter diesem Namen keine junos- Konfigurationsobjekte definieren.
Sie können in junos-defaults einer Anweisung keinen Namen einer Konfigurationsgruppe apply-groups angeben.
Wenn Sie den vollständigen Satz verfügbarer voreingestellter Anweisungen aus der Junos Standardgruppe anzeigen möchten, geben Sie den Befehl zum Konfigurationsmodus auf der obersten Ebene show groups junos-defaults der Konfiguration aus. Im folgenden Beispiel wird eine partielle 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 die in der Gruppe verfügbaren Anweisungen zu referenzdaten zu machen, geben Sie die ausgewählte Erklärung junos-defaults junos- default-name auf der entsprechenden Hierarchieebene an.
Wildcards mit Konfigurationsgruppen verwenden
Sie können Wildcards verwenden, um Namen zu identifizieren und eine Aussage zu zulassen, um Daten für verschiedene Anweisungen zu liefern. Beispiel: Die Gruppierung der Anweisungskonfiguration über alle SONET/SDH-Schnittstellen oder das Dead Interval für OSPF über alle ATM-Schnittstellen (Asynchronous Transfer Mode) vereinfacht Konfigurationsdateien und vereinfacht deren sonet-options Wartung.
Die Verwendung von Wildcards in normalen Konfigurationsdaten erfolgt im Ähnlichen wie bei herkömmlichen UNIX Shell-Wildcards. In diesem Format können Sie die folgenden Metacharacter verwenden:
Sternchen (
*) – Treffer beliebiger Zeichen.Fragezeichen (
?)– Treffer beliebiges einzelnes Zeichen.Offene Halterung (
[) – Führt eine Zeichenklasse ein.Halterung schließen (
]) – Gibt das Ende einer Zeichenklasse an. Wenn die Halterung fehlt, entspricht die offene Halterung einer[Zeichenklasse, anstatt eine Zeichenklasse einzuführen.Eine Zeichenklasse entspricht einer der Zeichen zwischen den quadratischen Klammern. Innerhalb einer Konfigurationsgruppe muss ein Schnittstellenname, der eine Zeichenklasse enthält, in Anführungszeichen eingeschlossen sein.
Bindestrich (
-) – Gibt eine Reihe von Zeichen an.Exclamation Point ( ) – Die Zeichenklasse kann durch einen Exclamationspunkt zum ersten Zeichen der
!Zeichenklasse ergänzt werden. Um eine enge Klammer ( ) in eine Zeichenklasse ein klammern zu lassen, machen Sie sie zum ersten aufgeführten]Zeichen (nach der!, wenn auch nicht). Fügen Sie ein Minus-Vorzeichen bei, und machen Sie es zum ersten oder letzten Zeichen.
Wenn in der Hierarchie ein Identifikatorname verwendet wird, kann er nur beginnen, wenn Sie eine Wildcard-Anweisung definieren. In diesem Fall muss die Platzhalter-Anweisung das Schließen groups<> haben.
Wildcarding in Konfigurationsgruppen folgt denselben Regeln, hat aber eine besondere Bedeutung, wenn es in der <> Hierarchie verwendet groups wird. In der Hierarchie muss jeder Begriff, der ein Wildcard-Muster verwendet, in Winkelklammern < und > um ihn von anderen Wildcards in der Konfigurationsdatei zu groups unterscheiden.
[edit]
groups {
sonet-default {
interfaces {
<so-*> {
sonet-options {
payload-scrambler;
rfc-2615;
}
}
}
}
}
Wildcard-Ausdrücke übereinstimmen (und geben Konfigurationsdaten für) vorhandene Anweisungen in der Konfiguration an, die nur ihrem Ausdruck übereinstimmen. Im vorherigen Beispiel gibt der Ausdruck seine Anweisung an eine Schnittstelle weiter, <so-*>sonet-options die dem Ausdruck so-* entspricht.
Im folgenden Beispiel wird gezeigt, 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 Den Winkelklammern können Sie normale Wildcarding ohne Modifikation bestehen. Bei einem Abgleich in der Konfiguration, unabhängig davon, ob dies mit oder ohne Platzhalter erfolgt, wird das erste Element in der Verwendeten Konfiguration angezeigt. Im folgenden Beispiel werden Daten von Wildcard-BGP in der Reihenfolge übernommen, in der die Gruppen aufgeführt sind. Der Einstellungswert durch <*a*> Overrides der Präferenz in, genau wie der Wert aus dem Wert von <*b*>p<*c*><*d*> . Datenwerte einer dieser Gruppen setzen die Datenwerte von außer abcd Kraft.
[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; } } }
Verbessern der Commit-Zeit bei der Verwendung von Konfigurationsgruppen
Konfigurationsgruppen werden für die Anwendung von Konfigurationen in anderen Hierarchien verwendet, ohne die Konfigurationsdaten neu zu eingeben. Einige Konfigurationsgruppen spezifizieren jedes Konfigurationsdetail. Andere Konfigurationsgruppen verwenden Wildcards zum Konfigurieren von Datenbereichen, ohne die einzelnen Konfigurationszeilendetails zu beschreiben. Einige Konfigurationen haben einen Vererbungspfad, der eine lange Reihe von Konfigurationen umfasst, die angewendet werden müssen.
Wenn eine Konfiguration mit Konfigurationsgruppen engagiert wird, wird im Commit-Vorgang alle Konfigurationsdaten der Gruppe erweitert und in den Arbeitsspeicher gelesen, um die Konfigurationen wie vorgesehen anzuwenden. Die Commit-Leistung kann sich bei der Anwendung vieler Konfigurationsgruppen negativ auswirken, insbesondere wenn die Konfigurationsgruppen umfassend Wildcards verwenden.
Wenn Ihr System viele Konfigurationsgruppen verwendet, die Platzhalter verwenden, können Sie die Anweisung auf der Hierarchieebene konfigurieren, um die persist-groups-inheritance[edit system commit] Commit-Time-Leistung zu verbessern.
Mithilfe dieser Option kann das System den Vererbungspfad für jede Konfigurationsgruppe innerhalb der Datenbank anstelle des Prozessspeichers erstellen. Dies kann die Commit-Time-Leistung verbessern. Es kann jedoch auch die Datenbankgröße erhöhen.
Beispiel: Konfigurieren von Anweisungen mit Konfigurationsgruppen
Wenn anweisungssätze in Konfigurationsgruppen vorhanden sind, werden alle Werte übernommen. 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 ]; }
Bei Sätze, die nicht in Klammern angezeigt werden, werden auch alle Werte übernommen. 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: Schnittstellenkonfiguration mithilfe von Konfigurationsgruppen
Sie können Konfigurationsgruppen verwenden, um die gemeinsamen Schnittstellenmedienparameter von den schnittstellenspezifischen Adressierungsinformationen 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 einheitlichen IP-Adresse für die Verwaltungsschnittstelle mithilfe von Konfigurationsgruppen
Bei Routern mit mehreren Routing-Engines wird Routing-Engine Konfiguration mit einer separaten IP-Adresse für die Verwaltungsschnittstelle ( fxp0 ) konfiguriert. Für den Zugriff auf die Routing-Engine Müssen Sie wissen, Routing-Engine aktiv sind und die entsprechende IP-Adresse verwenden.
Optional können Sie für einen einheitlichen Zugriff auf die primäre Routing-Engine eine zusätzliche IP-Adresse konfigurieren und diese Adresse für die Verwaltungsschnittstelle verwenden, unabhängig davon, Routing-Engine aktiv ist. Diese zusätzliche IP-Adresse ist nur in der Verwaltungsschnittstelle der primären Routing-Engine. Während des Switchover wird die Adresse zur neuen primären Routing-Engine.
Im folgenden Beispiel ist die Adresse für beide Routingmodule konfiguriert und 10.17.40.131 enthält eine master-only Anweisung. Bei dieser Konfiguration ist 10.17.40.131 die Adresse nur auf dem primären Netzwerk Routing-Engine. Die Adresse bleibt konsistent, unabhängig davon, Routing-Engine aktiv ist. Die 10.17.40.132 Adresse wird der Adresse zugewiesen fxp0re0 und 10.17.40.133fxp0re1 der .
[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 mit doppelten Routing-Engines verfügbar. In einer Routingmatrix, die aus dem TX Matrix-Router besteht, ist diese Funktion nur für das Switchkartengehäuse (SCC) anwendbar. In einer Routingmatrix, die aus einem TX Matrix Plus-Router besteht, ist diese Funktion nur auf das Switch-Fabric-Chassis (SFC) anwendbar.
Wenn Sie dieselbe IP-Adresse für eine Verwaltungsschnittstelle oder interne Schnittstelle wie beispielsweise eine externe physische Schnittstelle konfigurieren, wenn
fxp0ge-0/0/1Graceful Routing-Engine Switchover (GRES) aktiviert ist, zeigt der CLI eine entsprechende Commit-Fehlermeldung an, die identische Adressen an privaten und öffentlichen Schnittstellen gefunden haben. In solchen Fällen müssen Sie den beiden Schnittstellen, die adressenvielfältig sind, eindeutige IP-Adressen zuweisen.Die für den TX Matrix Plus-Router verwendete Management-Ethernet-Schnittstelle T1600 Router in einer Routingmatrix und Paketübertragungs-Router PTX-Serie
em0ist. Junos OS erstellt automatisch die Management-Ethernet-Schnittstelle desem0Routers.
Beispiel: Konfigurieren von Peer Entities mithilfe von Konfigurationsgruppen
In diesem Beispiel erstellen wir eine Gruppe, die Konfigurationsdaten enthält, die mit einem anderen some-isp Internetdienstanbieter verbunden sind. Anschließend können Anweisungen an jedem beliebigen Punkt eingefügt werden, damit jeder Standort in der Konfigurationshierarchie apply-group diese Daten übernehmen kann.
[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: Einrichten regionaler Konfigurationen mithilfe von Konfigurationsgruppen
In diesem Beispiel werden in eine Gruppe Konfigurationsdaten aus dem gesamten Unternehmen gefüllt, 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 Wildcard-Konfigurationsgruppennamen
Wildcards sind Konfigurationsgruppennamen, die Sonderzeichen zum Erstellen eines Musters verwenden, das auf mehrere Anweisungen angewendet werden kann. Wildcards sind nützlich, um eine Gruppe von Konfigurationsoptionen in viele verschiedene Konfigurationsgruppen zu kopieren. Es ist wichtig, den Wildcard-Namen korrekt zu konfigurieren, um sicherzustellen, dass die Optionen für die Wildcard-Konfiguration in die entsprechenden Konfigurationsgruppen kopiert werden.
In diesem Beispiel konfigurieren Sie in der Anweisung unterschiedliche Werte für die Und <*-major><*-minor> Wildcard-Gruppen. label-switched-path Das Sternchen ( ) stellt einen Abschnitt des Platzhalternamens dar, der einer * beliebigen Zeichenkette entspricht. Beispielsweise werden die verfügbaren Konfigurationsoptionen an eine andere Konfigurationsgruppe mit label-switched-path <*-major>label-switched-path metro-major ihrem Namen label-switched-path-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: Bezug auf die voreingestellte Aussage aus der Standardgruppe
Im folgenden Beispiel ist eine voreingestellte Anweisung aus der Standardgruppe vorhanden, die für FTP in einer zustands behafteten 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 eine voreingestellte Standardauszug aus der Standardgruppe zu verweisen, fügen Sie die junos-default-name Anweisung auf der entsprechenden Hierarchieebene bei. Um beispielsweise auf die Standardauszug für FTP in einer zustandsreichen Firewall zu verweisen, schließen Sie die Anweisung junos-ftp auf der [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 Standardeinstellungen, die auf die Konfiguration angewendet wurden
Geben Sie den Befehl aus, um die Standardeinstellungen auf die Gerätekonfiguration show | display inheritance defaults anzeigen zu können. Um z. B. die übernommenen Standardeinstellungen auf der [edit system ports] Hierarchieebene anzeigen zu können:
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 vorhandene Standard anweisungen nicht verwenden, können Sie Ihre eigenen Konfigurationsgruppen manuell erstellen.
Verwenden Sie die Option mit dem Befehl, um die vollständigen Konfigurationsinformationen, mit den alle mit markierten Kommentaren ##no-comments markierten Kommentare anzeigen zu display inheritance können.
Einrichten Routing-Engine Konfigurationsgruppen
In einem Router mit zwei Routing-Engines sollte beide Routingmodule eine Konfiguration gemeinsam verwenden. Dadurch wird sichergestellt, dass Routing-Engine Konfigurationen identisch sind. Erstellen Sie innerhalb dieser Konfiguration Routing-Engine Benutzergruppen (eine für jede Routing-Engine. Innerhalb dieser Gruppen geben Sie die Routing-Engine-spezifischen Parameter an.
Weitere Informationen über die Initiale Konfiguration für redundante Routing-Engine Systeme und die Re0-Gruppe finden Sie im Junos OS Für hohe Verfügbarkeit.
Verwendung der Bedingungen zur Anwendung von Konfigurationsgruppen
Sie können die Anweisung auf Hierarchieebene verwenden, um Bedingungen zu definieren, unter denen eine when[edit groups group-name] Konfigurationsgruppe angewendet werden soll.
Sie können eine Gruppe konfigurieren, die auf basis der Gehäuseart, des Modells oder Routing-Engine, des Virtual Chassis-Mitglieds, des Clusterknotens sowie des Start- und optionalen Endzeitpunkts bzw. -datums angewendet werden soll.
Sie könnten die Anweisung beispielsweise verwenden, um eine generische Konfigurationsgruppe für jeden Knotentyp zu erstellen und dann die Konfiguration basierend auf bestimmten Knoteneigenschaften, wie Gehäuse oder when Modell, anzuwenden.
Beispiel: Konfigurationsbedingungen für die Anwendung von Konfigurationsgruppen
In diesem Beispiel wird gezeigt, wie Sie Bedingungen konfigurieren, unter denen eine bestimmte Konfigurationsgruppe angewendet wird.
Anforderungen
Bevor Sie dieses Beispiel konfigurieren, ist keine besondere Konfiguration über die Gerätein initialisierung hinaus erforderlich. Beachten Sie jedoch, dass dieses Beispiel mithilfe eines auf einem anderen Gerät konfigurierten und MX240 wurde.
Überblick
Sie können Ihre Gruppenkonfigurationsdaten in der Hierarchieebene konfigurieren und dann anhand der Anweisung die Gruppe anhand der folgenden Bedingungen [edit groups group-name]when zuweisen: Gehäusetyp, Modell, Routing-Engine, Virtual Chassis-Mitglied, Clusterknoten und Start- und optionale Endzeit oder -datum.
Wenn Sie in einer einzigen Konfigurationsgruppe mehrere Bedingungen angeben, müssen alle Bedingungen erfüllt sein, bevor die Konfigurationsgruppe angewendet wird.
Sie können die Startzeit oder die Dauer der Anwendung der Konfigurationsgruppe angeben. Wenn nur die Startzeit angegeben ist, wird die Konfigurationsgruppe zu der angegebenen Zeit angewendet und bleibt in Kraft, bis die Zeit geändert wird. Wenn die Endzeit angegeben wird, wird die angewandte Konfigurationsgruppe an jedem Tag gestartet und zu den angegebenen Zeiten beendet.
In diesem Beispiel werden die Bedingungen in einer Konfigurationsgruppe so definiert, dass diese Gruppe nur dann angewendet wird, test1 wenn alle der folgenden Bedingungen erfüllt sind: Der Router ist ein Modell MX240-Router mit Gehäusetyp LCC0, mit einem Routing-Engine, das als RE0 verwendet wird, ist Mitglied0 des Virtual Chassis auf Node0, und die Konfigurationsgruppe wird jeden Tag nur von 9:00 Uhr bis 17:00 Uhr in kraft sein.
Konfiguration
CLI-Konfiguration
Um dieses Beispiel schnell konfigurieren zu können, kopieren Sie die folgenden Befehle, fügen Sie diese in eine Textdatei ein, entfernen Sie alle Zeilenbrüche, ändern Sie alle Details, die zur Übereinstimmung mit der Netzwerkkonfiguration erforderlich sind, und kopieren Sie die Befehle, und fügen Sie die Befehle CLI der Hierarchieebene [edit] 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 die Bedingungen für die test1 Konfigurationsgruppe:
Konfigurieren Sie den Zustand, der das Modell und den MX240 identifiziert.
[edit groups test1 when] user@host#
set model mx240Festlegen des Zustands, der den Gehäusetyp als LCC0 identifiziert.
[edit groups test1 when] user@host#
set chassis lcc0Sie können den Zustand festlegen, der den Routing-Engine als
RE0.[edit groups test1 when] user@host#
set routing-engine re0Festlegen von Bedingungen zur Identifizierung des Virtual
member0Chassis.[edit groups test1 when] user@host#
set member member0Sie den Zustand festlegen, der den Cluster
node0identifiziert.[edit groups test1 when] user@host#
set node node0Festlegen der Bedingungen, die für die Gruppe nur zwischen 9:00 und 17:00 Uhr täglich gelten.
[edit groups test1 when] user@host#
set time 9 to 5Anmerkung:Die Syntax zur Angabe der Zeit ist:
time <start-time> [to <end-time>]im Zeitformat yyyy-mm-dd.hh:mm, hh:mm oder hhh.Commit für die Konfiguration.
user@host#
commit
Ergebnisse
Bestätigen Sie Ihre Konfiguration im Konfigurationsmodus, indem Sie den Befehl show groups test1 eingeben. Wenn in der Ausgabe nicht die beabsichtigte Konfiguration 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
Überprüfung der Gruppenererbung mit bedingten Daten
Zweck
Überprüfen Sie, ob bedingte Daten einer Konfigurationsgruppe übernommen wurden.
Aktion
Die show | display inheritance Betriebsbefehle können mit den Daten zur when Anzeige der bedingten Vererbung ausgegeben werden. In diesem Beispiel können Sie einen der folgenden Befehle ausführen, um zu ermitteln, dass bedingte Daten übernommen 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