Kapitel 1. Einführung

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com

Willkommen in der Welt der automatisierten Junos-Verwaltung! Seit ihrer Einführung in den späten 1990er Jahren hat sich die Benutzeroberfläche (UI) der Junos-Software von ihren Mitbewerbern abgehoben, indem sie es Netzwerkbetreibern leicht gemacht hat, ihre Geräte über die Befehlszeilenschnittstelle (CLI) zu verwalten. Darüber hinaus ist Juniper führend im Bereich der Netzwerkautomatisierung und hat bereits in der ersten Junos-Version eine API bereitgestellt und in Junos 4.1 die erste externe API geliefert.

Doch die Zeiten haben sich geändert. In dem Maße, in dem Betreiber ihre Netzwerke automatisieren wollen, gewinnen andere Managementschnittstellen immer mehr an Bedeutung. Juniper hat mit diesem Trend Schritt gehalten und ist bestrebt, ein Branchenführer zu sein, indem es die Automatisierung mit seinen Geräten ermöglicht.

In diesem Kapitel wird der Grundstein für den Rest des Buches gelegt, indem die Vorteile der Automatisierung besprochen, einige Hintergrundinformationen über die Funktionsweise des Junos-Managementsystems gegeben und einige grundlegende Informationen über das Buch gegeben werden.

Vorteile der Automatisierung

Netzwerkautomatisierung hat sich in den letzten Jahren zu einem heißen Thema entwickelt, und das aus gutem Grund: Die Vorteile der Automatisierung sind groß, sowohl für ein Unternehmen als auch für die Personen, die sein Netzwerk betreiben.

Da du dieses Buch liest, kennst du wahrscheinlich schon zumindest einige der Vorteile der Automatisierung. Wir stellen jedoch fest, dass du jedes Mal, wenn du dir die Möglichkeiten der Automatisierung ansiehst, vielleicht einen neuen Weg findest, sie zu nutzen, der über den hinausgeht, den du geplant hast. Sehen wir uns einige allgemeine Vorteile an.

Automatisierung spart Zeit

Einer der grundlegendsten Vorteile der Automatisierung ist, dass sie Zeit spart. Viele von uns haben sich wiederholende Aufgaben, die wir erledigen müssen. Eine Methode, diese sich wiederholenden Aufgaben zu vereinfachen, ist die Automatisierung.

Angenommen, du hast eine Standardmethode für die Fehlersuche bei fehlgeschlagenen Border Gateway Protocol (BGP) Sitzungen. Zuerst überprüfst du die show interfaces Ausgabe für die Schnittstelle , die mit dem Peer verbunden ist. Danach pingst du den Peer an. Dann siehst du dir die show bgp neighborAusgabe für den Peer an. Schließlich suchst du nach Protokollfehlern, die sich auf den Peer oder seine Schnittstelle beziehen.

Es ist durchaus akzeptabel, eine Liste mit den entsprechenden Befehlen zu führen und sie jedes Mal auszuführen, wenn du eine fehlgeschlagene BGP-Sitzung beheben musst. Du kannst jedoch Zeit sparen, indem du sie auf ein Automatisierungsskript reduzierst, das die entsprechenden Befehle ausführt.

Du kannst sogar noch mehr Zeit sparen, wenn du das Skript die Befehlsausgabe für dich interpretieren lässt. Was willst du zum Beispiel wirklich aus der Ausgabe von show interfaces wissen? Wahrscheinlich willst du sehen, ob die Schnittstelle aktiviert oder deaktiviert ist. Wahrscheinlich willst du auch nach ungewöhnlichen Statistiken suchen (z. B. eine sehr hohe Datenrate oder eine hohe Fehlerrate). Je nachdem, was du hier siehst, kennst du vielleicht schon den Grund für den Ausfall der Sitzung. (Wenn die Verbindung unterbrochen ist, ist es nicht nötig, weiter zu suchen: Kein Datenverkehr erreicht die Gegenstelle.) Wenn du das Skript nach offensichtlichen Hinweisen wie diesem suchen lässt, kannst du vielleicht ein Skript schreiben, das dir einfach sagt, warum die BGP-Sitzung ausgefallen ist, wenn es offensichtlich ist. (Diese automatisierte Analyse kann eine große Hilfe sein, wenn du um 4 Uhr morgens einen Anruf erhältst, um ein Netzwerkproblem zu beheben.)

Aber warum hier aufhören? Warum solltest du das Skript überhaupt ausführen müssen? Warum lässt du dein Gerät das Skript nicht automatisch für dich ausführen, wenn eine Peering-Sitzung ausfällt und länger als fünf Minuten ausfällt? Junos verfügt über die Automatisierungshaken, um diese Art der ereignisgesteuerten Skriptausführung zu ermöglichen.

Eine der wichtigsten Möglichkeiten, durch Automatisierung Zeit zu sparen, ist natürlich die Vereinfachung des sich wiederholenden Bereitstellungsprozesses, der oft auf die Verwendung von Standardvorlagen hinausläuft. Mehr dazu erfahren Sie unter "Automatisierung verhindert Copy/Paste-Fehler".

Automatisierung vermeidet menschliche Fehler

Der alternative Titel für diesen Abschnitt sollte lauten: "Automatisierung verhindert Telefonanrufe um 4 Uhr morgens". Wie viele Notfälle wurden schon dadurch verursacht, dass jemand bei einer Änderung einen Tippfehler oder eine einfache Auslassung gemacht hat?

Nehmen wir zum Beispiel an, dass dein Netzwerkkern Multiprotocol Label Switching (MPLS) verwendet, um den Verkehr weiterzuleiten. Nehmen wir weiter an, dass MPLS erforderlich ist, weil du eine große Anzahl von Anwendungen hast (z. B. virtuelle private Netzwerke [VPNs]), die MPLS benötigen, um korrekt zu funktionieren. Stell dir nun vor, jemand richtet neue Netzwerkverbindungen zwischen Core- und Kanten-Routern ein, vergisst aber, die MPLS-Verarbeitung für diese Schnittstellen auf dem Core-Router zu aktivieren. In diesem Fall ist ein Netzwerkausfall vorprogrammiert! Sobald die anderen Pfade zwischen den Core- und Edge-Routern ausfallen, kann der MPLS-Verkehr nicht mehr über diese neuen Verbindungen fließen.

Wäre es nicht toll, wenn du jemanden daran hindern könntest, dies zu tun, indem du das Netzwerk so programmierst, dass es die erwarteten Konfigurationen kennt und Auslassungen wie diese erkennt? Auch hier hat Junos die Automatisierungshaken, um diesen Schutz zu ermöglichen.

Automatisierung spart Speicher

Wir alle haben wahrscheinlich komplizierte Aufgaben, die wir nur ab und zu ausführen müssen. Es kommt nicht selten vor, dass ich die Frage eines Kollegen beantworte, indem ich mich am Kopf kratze und sage: "Ich erinnere mich, dass ich den Befehl dafür nachgeschlagen habe. Gib mir nur eine Minute, um ihn zu finden."

Es ist sicherlich richtig, dass nicht jeder Befehl auf Automatisierung reduziert werden sollte. Aber Dinge, die besonders kritisch sind und typischerweise in zeitkritischen Situationen benötigt werden, sind gute Kandidaten für die Automatisierung. Ebenso sind Dinge, die besonders kompliziert sind, ebenfalls Kandidaten für die Automatisierung.

Automatisierung verhindert Copy/Paste-Fehler

Eine Reihe von gängigen Netzwerkmanagementaufgaben lassen sich auf eine Vorlage mit Variablen reduzieren, die ausgefüllt werden müssen. Das vielleicht paradigmatischste Beispiel dafür ist die Netzwerkbereitstellung (obwohl das gleiche Konzept auch in anderen Kontexten, z. B. bei der Fehlersuche, Anwendung finden kann).

Bei der Netzwerkbereitstellung werden häufig Vorlagen verwendet: eine Vorlage für die Basiskonfiguration des Geräts, eine Vorlage für interne Verbindungen, eine Vorlage für Transit- oder Peer-Verbindungen und mehrere Vorlagen für verschiedene Arten von Kundenverbindungen. Diese Templates haben in der Regel nur sehr wenige Variablen, die ein Betreiber ändern muss, um sie zu verwenden. Es kann jedoch leicht passieren, dass jemand versehentlich eine wichtige Zeile auslässt, vergisst, eine der Variablen zu ändern, oder eine der Variablen auf einen ungültigen Wert setzt. Und selbst wenn der/die Nutzer/in beim Erstellen der Konfiguration aus der Vorlage keine Fehler macht, kann es vorkommen, dass beim Kopieren und Einfügen eines großen Konfigurationsblocks oder eines großen Befehlssatzes ein Fehler auftritt.

Hinweis

Wir werden mehr über die Bereitstellung von Templates sprechen, wenn wir in Kapitel 5 über Commit-Skripte sprechen. Commit-Skripte sind eine Möglichkeit, eine Vorlage einfach anzuwenden. Commit-Skripte bieten sogar eine optionale Möglichkeit, die Größe der Junos-Konfigurationsdatei zu reduzieren, indem Junos standardmäßig die Template-Parameter anzeigt (statt ihrer vollständigen Erweiterung).

In diesem Fall kann die Automatisierung sowohl Zeit sparen als auch die Zahl der unbeabsichtigten Fehler verringern. Wenn der Bereitstellungsprozess auf ein einfaches Skript reduziert wird, das die Werte für die wenigen Variablen in einer Vorlage abfragt, kann das Skript sicherstellen, dass die gesamte Konfiguration angewendet wird. Das Skript kann sogar die notwendigen Fragen stellen, um die richtige Vorlage auszuwählen. Außerdem kann das Skript überprüfen, ob die vom Nutzer angegebenen Werte sinnvoll sind.

Es ist sogar möglich, die Informationen, die ein Benutzer eingeben muss, noch weiter zu reduzieren, indem das Skript die Informationen von vornherein sammelt. Nehmen wir an, die Kundendaten werden alle in einer SQL-Datenbank gespeichert. Auf Eingabeaufforderung des Benutzers kann das Skript die Datenbank abfragen, um die richtigen Werte für alle Variablen zu ermitteln und sie dem Benutzer zur Überprüfung vorzulegen. Dadurch wird die Möglichkeit von unbeabsichtigten Fehlern weiter reduziert.

Von dort ist es nur noch ein kleiner Schritt zur vollständigen Automatisierung des Prozesses. Wenn ein neuer Kunde in die Datenbank aufgenommen wird, kann ein automatisierter Prozess die Änderungen im Netzwerk automatisch aktivieren.

Es wird wahrscheinlich nicht möglich sein, die Möglichkeit, dass jemand an irgendeiner Stelle des Prozesses falsche Informationen eingibt , vollständig auszuschließen. Die Automatisierung kann jedoch die Anzahl der Stellen reduzieren, an denen falsche Informationen eingegeben werden können. Und sie kann die Konsistenz zwischen den verschiedenen Systemen, die Informationen über das Netzwerk verwalten, fördern, indem sie sicherstellt, dass überall die gleichen Informationen verwendet werden (unabhängig davon, ob diese Informationen richtig oder falsch sind).

Automatisierung ermöglicht neue Dienstleistungen

Die Automatisierung kann neue Dienstleistungen ermöglichen, die von Menschen nicht effizient durchgeführt werden könnten. In diesem Zusammenhang kann ein "Dienst" entweder extern oder intern sein.

SDN ist ein gutes Beispiel für einen externen Dienst, der durch Automatisierung ermöglicht wird. Stell dir vor, ein Netzwerkbetreiber möchte seinen Verkehrsfluss alle fünf Minuten auf der Grundlage einer komplexen Reihe von Algorithmen optimieren, aber er möchte die Neuberechnung schneller durchführen, wenn bestimmte Ereignisse eintreten. Dies ist die Art von komplexem Netzwerkdienst, der Automatisierung erfordert, um ihn effektiv umzusetzen.

Ein Beispiel für einen internen Dienst, der durch Automatisierung ermöglicht wird, ist ein automatisierter Fehlerbehebungsdienst. Stell dir vor, ein Netzwerkbetreiber implementiert einen automatisierten Fehlerbehebungsdienst, der Netzwerkereignisse überwacht, die auf einen Netzwerkfehler hindeuten könnten. Das Automatisierungstool reagiert dann auf diese Ereignisse gemäß einer festgelegten Fehlerbehebungsvorlage. Wenn es ein Problem findet, das es automatisch beheben kann, tut es das. Andernfalls sendet es seine Ergebnisse an das Trouble-Ticket-System des Netzbetreibers. Diese Ausgabe sollte alle Informationen enthalten, die für die weitere Fehlersuche notwendig sind. Dadurch kann die Zeit, die Netzwerktechniker/innen mit dem Sammeln grundlegender Informationen und dem Ausprobieren "einfacher" Lösungen verbringen, reduziert werden. Außerdem können falsche Fehler unterdrückt werden, so dass die Netzwerktechniker weniger Zeit damit verbringen, auf falsche Warnungen zu reagieren, und schneller mit der Bearbeitung der echten Probleme beginnen können. Und schließlich kann sie die Zeit bis zur Lösung von Netzwerkproblemen verkürzen.

Interna des Verwaltungssystems

Es ist hilfreich, ein gutes Verständnis dafür zu haben, wie "Verwaltungsdaten" normalerweise durch das Junos-System fließen. Einige Beispiele für die Arten von Verwaltungsdaten, die durch ein System fließen können, sind Konfigurationsinformationen, Betriebsbefehle und Statistiken. Ein gutes Verständnis des Flusses der Verwaltungsdaten hilft dir, die Unterschiede zwischen den verschiedenen Methoden für den Zugriff auf diese Daten zu erkennen.

Wenn du dir den Fluss der Verwaltungsdaten ansiehst, wirst du sehen, dass der Management-Daemon (MGD) ein zentraler Knotenpunkt der Aktivitäten ist. Die meisten Verwaltungsdaten fließen durch den MGD. Die Junos-Software akzeptiert Management-Verbindungen über verschiedene Mechanismen, aber die meisten werden schließlich zu Junoscript- oder NETCONF-Sitzungen, die sich mit MGD verbinden. MGD verfügt über drei primäre Mechanismen für die Interaktion mit den Daemons: einen Management-Socket (über den er operative Befehlsanforderungen und -antworten weiterleitet), die gemeinsame Konfigurationsdatenbank und Unix-Signale.

Zugriff auf das Managementsystem

Beginnen wir mit den Möglichkeiten, wie auf das Verwaltungssystem zugreifen kann. Hier führen alle Wege zu MGD.

Alle CLI-Sitzungen rufen eine Binärdatei auf (die zufälligerweise cli heißt), die ein Junoscript-Client ist. Das CLI-Binary öffnet eine Junoscript-Sitzung mit MGD und tauscht mit MGD Informationen im XML-Format aus.

Es ist auch möglich, dass ein Benutzer über eine NETCONF- oder Junoscript-Sitzung mit der Junos-Software interagiert. Diese Sitzungen stellen ebenfalls eine Verbindung zu MGD her.

Außerdem kann ein Benutzer über die REST API mit der Junos-Software interagieren. Wie im Abschnitt "Interner Aufbau" beschrieben , werden diese Sitzungen durch einige zusätzliche Leitungen geleitet, erreichen aber schließlich MGD.

Schließlich ist es möglich, dass ein Benutzer mit der Junos-Software über PyEZ interagiert oder dass Op-, Commit- oder Event-Skripte Remote Procedure Calls (RPCs) starten. In all diesen Fällen wird eine Junoscript- oder NETCONF-Sitzung verwendet, um sich mit der Software zu verbinden. Auch diese Junoscript- oder NETCONF-Sitzungen werden alle mit MGD beendet.

Abbildung 1-1 veranschaulicht, wie diese verschiedenen Verbindungsmechanismen letztendlich alle in Sitzungen enden, die mit MGD verbunden sind.

This figure illustrates the way various management connections end up as sessions connected to MGD. CLI connections and REST API connections become Junoscript connections to MGD. PyEZ, op, commit, and event scripts can launch RPCs by opening Junoscript or NETCONF sessions to MGD. Finally, a user can directly open a NETCONF or Junoscript connection to MGD.
Abbildung 1-1. Verschiedene Managementverbindungen, die mit dem MGD verbunden sind

Operativer Befehlsfluss

Die Einsatzbefehle erreichen den MGD über eine der gerade beschriebenen Verbindungsmethoden. Wenn MGD die Betriebsbefehle empfängt, kann er sie entweder selbst erfüllen, sie an andere Daemons weitergeben, die die Anforderungen erfüllen, oder andere Tools aufrufen, um die Anforderungen zu erfüllen.

Der RPC-Befehl get-authorization-information (, der dem CLI-Befehl show cli authorization entspricht) ist ein prototypisches Beispiel für die Art von Anfrage, die MGD selbst erfüllt. Mit diesem Befehl fragt der Benutzer nach Informationen über seine Berechtigungsstufe. Diese Informationen speichert MGD für jede Sitzung, und es ist für MGD ein Leichtes, diese Anfrage selbst zu erfüllen. (Ein weiteres prototypisches Beispiel in dieser Kategorie ist der get-configurationRPC oder der show configuration CLI Befehl. Auch hier werden Informationen abgefragt, die MGD intern verwaltet).

Zwei klassische Beispiele für die Arten von Betriebsbefehlen, die an einen Daemon weitergegeben werden, sind der get-route-informationRPC (entspricht dem show route CLI-Befehl) und der clear-bgp-neighbor RPC (entspricht dem clear bgp neighborCLI Befehl). In beiden Fällen ist der Routing-Protokoll-Daemon (RPD) der Daemon, der diese Anforderung erfüllt. Er ist der Dämon, der die Informationen über die Routing-Tabelle (auch bekannt als Routing Information Base oder RIB) verwaltet; daher ist er der Dämon, der eine Anfrage nach Routeninformationen autorisiert beantworten kann. Ebenso ist der RPD der Dämon, der die BGP-Nachbarschaftsbeziehungen verwaltet; daher ist er der Dämon, der eine Anfrage zum Zurücksetzen einer dieser Beziehungen bearbeitet. In diesen Fällen dient der MGD als Zwei-Wege-Pipe, indem er die Anfrage des Benutzers an den RPD weiterleitet und die Antwort des RPD an den Benutzer. Abbildung 1-2 veranschaulicht diesen Datenfluss. Um diese Kommunikation zu unterstützen, unterhält MGD einen Management-Socket mit den meisten Daemons. Betriebliche Anfragen und Antworten fließen über diesen Management-Socket.

In einigen Fällen ruft der MGD Tools auf, um Anfragen zu erfüllen. Ein Beispiel ist der Junos-Upgrade-Prozess, der eine komplexere Handhabung als ein normaler CLI-Befehl erfordert. MGD ruft ein externes Tool auf, um einen Teil des Upgrades durchzuführen. Ein weiteres Beispiel sind die op- und commit-Skripte, die über mit dem Dienstprogramm CSCRIPT ausgeführt werden. Dieser Prozess ist für den Benutzer transparent und wird hier nur der Vollständigkeit halber erwähnt.

Hinweis

Wie Abbildung 1-2 zeigt, müssen einige Anfragen den ganzen Weg bis zur Packet Forwarding Engine (PFE) gehen, um erfüllt zu werden. Die Schnittstellenstatistik ist ein Beispiel für diese Art von Anfrage. Um Schnittstellenstatistiken zu sammeln, ruft der MGD ifinfo auf, das den Kernel abfragt. Der Kernel muss oft eine PFE abfragen, um diese Statistiken zu erhalten. Auf diese Weise haben die Betriebsbefehle manchmal wichtige Auswirkungen auf das System.

This figure illustrates the way that MGD handles requests satisfied by a daemon or external process. MGD passes the request to the daemon or external process. When the daemon or process responds, MGD passes the response to the client.
Abbildung 1-2. Datenfluss zwischen einem Benutzer und einem Daemon

Konfiguration Datenfluss

Wenn du Konfigurationsänderungen festlegst, werden die neuen Konfigurationsdaten in einer gemeinsamen Datenbank gespeichert, auf die alle Daemons zugreifen können. Wenn sich diese Konfigurationsdatenbank ändert, verwendet MGD Unix-Signale, um den entsprechenden Daemons zu signalisieren, dass sie die neue Konfiguration erneut einlesen sollen. Nachdem sie die Konfiguration gelesen haben, aktivieren die Daemons ihren Inhalt. Wenn die neue Konfiguration Änderungen in der Forwarding Plane erfordert, werden diese Daten an die PFEs weitergegeben. Dieser Prozess ist in Abbildung 1-3 dargestellt.

This figure illustrates the way committed configuration data is disseminated to daemons. First, MGD places the data in a shared database. Then, MGD signals the daemons. Finally, the daemons read the data from the shared database and activate it.
Abbildung 1-3. Fluss der Konfigurationsdaten

Konfigurationsdatenbanken und das Commit-Modell

Der Rest dieses Buches setzt einige Kenntnisse über die Konfigurationsdatenbanken und das Commit-Modell voraus. Obwohl es sich hierbei um grundlegende Informationen handelt, ist es wichtig, dass du diese Konzepte wiederholst, um die Teile des Buches zu verstehen, in denen darauf verwiesen wird.

Konfigurationsdatenbanken

Jedes Junos-System hat mindestens zwei Konfigurationsdatenbanken: die bestätigte Konfiguration und die Kandidatenkonfiguration. Wie die Namen schon andeuten, ist die bestätigte Konfiguration die derzeit aktive Konfiguration, während die Kandidatenkonfiguration die Kopie der Konfiguration ist, die ein Benutzer gerade bearbeitet. Wie in Abbildung 1-5 dargestellt, wird die Candidate-Konfiguration zur Commited-Konfiguration und eine Kopie der neuen Commited-Konfiguration zur Candidate-Konfiguration, wenn ein Benutzer die Konfiguration festschreibt. Die Junos-Software speichert eine Kopie jeder vorhergehenden bestätigten Konfiguration, falls du in der Zukunft auf sie zurückgreifen musst. (Du kannst diese gespeicherten Konfigurationen als die rollbackKonfigurationen referenzieren.)

This figure shows the way the configuration databases are changed during a commit operation. The candidate configuration becomes the committed configuration. The software makes a copy of the new committed configuration and uses it as the candidate configuration.
Abbildung 1-5. Eine Kandidatenkonfiguration wird zur verbindlichen Konfiguration

Beachte hier die genaue Formulierung: Die neue Kandidatenkonfiguration ist eine Kopie der neuen übertragenen Konfiguration. In manchen Fällen (insbesondere, wenn ein Commit-Skript die Konfiguration als Teil eines Commits ändert) stimmt die neue übertragene Konfiguration möglicherweise nicht mit der Kandidatenkonfiguration überein, wenn der Benutzer den Commit auslöst.

Die gemeinsame Datenbank für die Kandidatenkonfiguration

Wenn ein Benutzer den Befehl configureeingibt, beginnt er standardmäßig mit der Bearbeitung der gemeinsamen Kandidatenkonfigurationsdatenbank. Wie in Abbildung 1-6 dargestellt, bearbeiten alle Benutzer dieselbe Konfigurationsdatenbank. Dieses Verhalten lässt die Möglichkeit offen, dass mehrere Nutzer/innen unbeabsichtigt miteinander interagieren können, wenn sie die Konfiguration gleichzeitig bearbeiten. Alle Änderungen, die in einer Sitzung vorgenommen werden, wirken sich auf alle anderen Konfigurationssitzungen aus, die die gemeinsame Datenbank verwenden. Und jedes Mal, wenn ein Nutzer die gemeinsame Datenbank festschreibt, schreibt er alle Änderungen in der gemeinsamen Datenbank fest, unabhängig davon, wer die Änderungen vorgenommen hat.

Es kann sehr gefährlich sein, Änderungen in der gemeinsamen Datenbank zu bestätigen, während mehrere Benutzer die Datenbank bearbeiten. Angenommen, user1 konfiguriert eine BGP-Sitzung, während user2 die IP-Adresse ändert, die einer Kundenschnittstelle zugewiesen ist. Stell dir vor, dass user1 eine neue BGP-Sitzung erstellt, aber noch keine Importrichtlinie zugewiesen hat, wenn user2 seine Arbeit abschließt und die Konfiguration festschreibt. Abbildung 1-7veranschaulicht, was passiert.

This figure shows multiple users editing the single shared candidate configuration database. Their changes impact the shared data in this configuration database.
Abbildung 1-6. Mehrere Benutzer bearbeiten die gemeinsame Kandidatenkonfigurationsdatenbank
This figure shows two users editing the single shared candidate configuration database. User 2 commits part of the changes User 1 is entering.
Abbildung 1-7. Commit einer unvollständigen gemeinsamen Kandidatenkonfigurationsdatenbank

Die übertragene Konfiguration enthält nun eine BGP-Sitzung ohne Importrichtlinie. Angesichts der möglichen Probleme, die das verursachen kann, würden viele Dienstanbieter dies als Fehler betrachten.

Und es kann sogar noch schlimmer sein. Man kann sich leicht ein Szenario vorstellen, in dem ein Nutzer einen Ausfall verursacht, indem er eine von einem anderen Nutzer hinzugefügte Teilkonfiguration eingibt.

Um diese Situationen zu erkennen, warnt dich Junos, wenn du eine Konfigurationssitzung mit der gemeinsamen Datenbank betrittst, während andere Benutzer diese Datenbank bearbeiten:

user1@r0> configure
Entering configuration mode
Users currently editing the configuration:
  user2 terminal p0 (pid 38905) on since 2015-04-25 07:27:27 PDT 1
      [edit protocols bgp] 2
  user1 terminal p1 (pid 38903) on since 2015-04-25 07:28:18 PDT, idle 00:28:09
      [edit interfaces ge-0/0/0]
The configuration has been changed but not committed 3

[edit]
user1@r0#
1

Diese Zeile zeigt eine Benutzersitzung an, die die Konfiguration bearbeitet. Sie enthält Informationen über die Benutzersitzung, z. B. das Terminal, das die Benutzersitzung verwendet, die Uhrzeit, zu der der Benutzer mit der Bearbeitung der Konfiguration begonnen hat, und die Zeit, die die Sitzung im Leerlauf war.

In diesem Fall gibt es zwei andere Benutzersitzungen, die die Konfiguration bearbeiten; daher gibt es zwei Einträge, einen für jede Sitzung. Wie du sehen kannst, zeigt der zweite Eintrag, dass user1 bereits die Konfiguration bearbeitet. Das könnte user1 an eine Konfigurationssitzung erinnern, die sie vergessen hat!

2

Diese Zeile zeigt die Konfigurationshierarchie an, die ein Benutzer bearbeitet. Diese Informationen geben Aufschluss über den Bereich der Konfiguration, den der Benutzer ändert. Die Junos CLI ist jedoch so flexibel, dass ein Benutzer wirklich jederzeit einen beliebigen Teil der Konfiguration bearbeiten kann. (Zumindest kann er den Befehl edit verwenden, um zu einem neuen Teil der Konfiguration zu wechseln, nachdem diese Meldung angezeigt wurde.) Es ist also ratsam, diesen Informationen gegenüber etwas skeptisch zu sein, da sie nur einen Schnappschuss der Informationen zu einem bestimmten Zeitpunkt darstellen.

3

Dieser Text wird immer dann angezeigt, wenn die gemeinsame Kandidatenkonfigurationsdatenbank Änderungen enthält, die noch nicht bestätigt wurden. Er kann auch angezeigt werden, wenn keine anderen Benutzer die gemeinsame Datenbank bearbeiten. Dieser Text warnt den Benutzer, dass es weitere Änderungen geben kann, die er aktiviert, wenn er die Kandidatenkonfiguration festschreibt. Ein Benutzer kann show | compare eingeben, um die Änderungen anzuzeigen, die an der Kandidatenkonfiguration vorgenommen wurden.

Wenn du Änderungen an der gemeinsamen Kandidatenkonfigurationsdatenbank vornimmst und versuchst, das Programm zu verlassen, ohne sie zu bestätigen, wird dich die Software darauf hinweisen und dich bitten, deine Absichten zu bestätigen:

[edit]
user@r0# exit
The configuration has been changed but not committed
Exit with uncommitted changes? [yes,no] (yes)

Es gibt Zeiten, in denen es wünschenswert ist, die gemeinsame Datenbank mit den Änderungen zu verlassen, aber diese Aktion birgt auch potenzielle Gefahren. Jeder Benutzer könnte diese Änderungen versehentlich vor dir festschreiben, oder ein anderer Benutzer könnte deine Änderungen ändern oder löschen. Diese Gefahren sind einer der Gründe für die Warnung in the CLI.

Andere Modi zur Bearbeitung der Konfiguration

Neben der Bearbeitung der gemeinsamen Kandidatenkonfigurationsdatenbank gibt es mindestens zwei weitere Möglichkeiten, die Konfiguration zu bearbeiten: Du kannst die gemeinsame Kandidatenkonfigurationsdatenbank im exklusiven Modus bearbeiten, oder du kannst eine private Kandidatenkonfiguration bearbeiten.

Exklusiver Konfigurationsmodus

Wenn du configure exclusive eingibst, stellt die Software sicher, dass du die einzige Person bist, die Änderungen an der gemeinsamen Konfigurationsdatenbank vornimmt. Außerdem stellt sie sicher, dass niemand anderes zuvor unbestätigte Änderungen an der gemeinsamen Datenbank vorgenommen hat. Und schließlich lässt sie dich die Änderungen an der gemeinsamen Konfigurationsdatenbank nur speichern, wenn du sie bestätigst.

Hinweis

Dieses Verhalten macht den exklusiven Konfigurationsmodus sehr nützlich für automatisierte Skripte. Es stellt sicher, dass sie nicht auf unerwartete Weise mit anderen Konfigurationssitzungen interagieren. Konfigurationssitzungen, die NETCONF verwenden, können ein ähnliches Verhalten mit dem Remote Procedure Call lock-configuration erreichen. NETCONF wird in "Interna des Managementsystems" behandelt und RPCs werden in Kapitel 2 besprochen.

Wenn du versuchst, den exklusiven Konfigurationsmodus aufzurufen, während jemand anderes die gemeinsame Kandidatenkonfigurationsdatenbank bearbeitet, wird ein Fehler angezeigt:

user1@r0> configure exclusive
error: configuration database locked by:
  user2 terminal p0 (pid 38905) on since 2015-04-25 08:34:03 PDT, idle 00:04:20
      exclusive [edit]

user1@r0>

Ebenso wird eine Fehlermeldung angezeigt, wenn du versuchst, den exklusiven Konfigurationsmodus aufzurufen, während sich noch nicht bestätigte Änderungen in der gemeinsamen Konfigurationsdatenbank befinden:

user@r0> configure exclusive
error: configuration database modified

user@r0>

Wenn du den exklusiven Konfigurationsmodus aufrufst, wird die Software dich warnen, dass du beim Beenden keine unbestätigten Änderungen in der gemeinsamen Konfigurationsdatenbank speichern kannst. Wenn du versuchst, den Modus mit unbestätigten Änderungen zu verlassen, wirst du aufgefordert, zu bestätigen, dass du diese Änderungen verwerfen willst:

user@r0> configure exclusive
warning: uncommitted changes will be discarded on exit
Entering configuration mode

[edit]
user@r0# set system host-name r1

[edit]
user@r0# exit
The configuration has been changed but not committed
warning: Auto rollback on exiting 'configure exclusive'
Discard uncommitted changes? [yes,no] (yes)

Privater Konfigurationsmodus

Eine weitere Option für , um unbeabsichtigte Interaktionen zwischen Konfigurationssitzungen zu kontrollieren, ist die Arbeit an privaten Kopien der Datenbank der Kandidatenkonfiguration(Abbildung 1-8). Diese Option hat einige der gleichen Einschränkungen wie die Arbeit an einer exklusiven Kopie der Kandidatenkonfiguration, außer dass sie die gleichzeitige Bearbeitung der Konfiguration erlaubt. Sobald du deine Änderungen bestätigst, werden sie auf die bestätigte Konfiguration angewendet. Ähnlich wie bei Revisionskontrollsystemen (wie SVN oder CVS) kann die Junos-Software nicht widersprüchliche Änderungen aus mehreren gleichzeitigen Sitzungen zusammenführen; die Software kann jedoch keine widersprüchlichen Änderungen zusammenführen.

This figure shows multiple users editing private candidate configuration databases. Each user's changes go into his own database. Each user can commit the changes from her database separately.
Abbildung 1-8. Mehrere Benutzer bearbeiten private Konfigurationsdatenbanken

Wenn du configure private eingibst, erstellt die Junos-Software eine neue, private Kopie der festgelegten Gerätekonfiguration. Deine Änderungen werden in diese private Kopie der Konfiguration übernommen. Die Junos-Software stellt sicher, dass niemand anderes zuvor unbestätigte Änderungen an der gemeinsam genutzten Kandidatenkonfigurationsdatenbank vorgenommen hat. (Es ist in Ordnung, wenn andere Personen Änderungen an anderen privaten Datenbanken vornehmen.) Außerdem kannst du die Änderungen in der privaten Konfigurationsdatenbank nur speichern, wenn du sie bestätigst.

Hinweis

Dieses Verhalten macht den privaten Konfigurationsmodus für Automatisierungsskripte nützlich. Er stellt sicher, dass eine automatisierte Sitzung keine Änderungen aus einer anderen Konfigurationssitzung übernimmt. Und anders als im exklusiven Konfigurationsmodus können im privaten Konfigurationsmodus mehrere Skripte gleichzeitig an Änderungen arbeiten, die sich nicht überschneiden.

Im Vergleich zum exklusiven Konfigurationsmodus gibt es einige andere Fehlermöglichkeiten zu beachten. Zum Beispiel kann das Skript Konflikte mit seinen Änderungen wahrscheinlich nicht automatisch auflösen. Und obwohl mehrere Skripte gleichzeitig Änderungen an ihren eigenen Konfigurationsdatenbanken vornehmen können, ist ein separater Commit erforderlich, um die Änderungen aus jeder privaten Konfigurationsdatenbank zu aktivieren, und die eigentlichen Commits erfolgen weiterhin seriell.

Konfigurationssitzungen, die NETCONF verwenden, können mit der Option private für den open-configuration RPC ein äquivalentes Verhalten erhalten:

<open-configuration>
    <private/>
</open-configuration>

Dieses Beispiel bietet eine Vorschau auf die XML-Syntax, die Junos für RPCs verwendet. Weitere Informationen zu RPCs und dieser XML-Syntax findest du in Kapitel 2.

Wenn ein anderer Benutzer eine widersprüchliche Änderung festlegt, bevor du deine Änderungen festlegst, erhältst du möglicherweise eine Warnung, wenn du deine Änderungen festlegst. Hier versuchen zwei Benutzer, dieselben Schnittstellen zu konfigurieren. Der zweite Benutzer erhält diese Ausgabe:

[edit]
user2@r0# set interfaces ge-0/0/0 description "description #2"

[edit]
user2@r0# set interfaces ge-0/0/1.0 family inet address 192.168.1.1/24

[edit]
user2@r0# commit
[edit interfaces ge-0/0/0 description]
  'description "description #1"'
    warning: statement exists (discarding old value, replacing with 'description
#2') 1
[edit interfaces ge-0/0/1]
  'unit 0'
    warning: statement already exists 2
[edit interfaces ge-0/0/1 unit 0 family]
  'inet'
    warning: statement already exists

[edit]
user2@r0#
1

Diese Warnung zeigt an, dass es einen Konflikt für ein Element gibt, das nur einen Wert haben kann. Eine Schnittstelle kann nur eine Beschreibung haben. Hier lautet die aktuelle Beschreibung description #1. Die Warnung zeigt an, dass die Junos-Software diese Beschreibung durch die neue Beschreibung (description #2) ersetzen wird, wenn user2mit dem Übergabevorgang fortfährt.

2

Diese Warnung zeigt an, dass es einen Konflikt für einen Teil der Konfigurationshierarchie gibt, der möglicherweise zusammengeführt werden kann. Diese Warnung zeigt an, dass die Junos-Software versuchen wird, die Änderungen von user2an dieser Konfigurationshierarchie mit anderen Änderungen zusammenzuführen, die ein anderer Benutzer bereits an derselben Konfigurationshierarchie vorgenommen hat.

Wenn du eine solche Warnung erhältst, fährt die Junos-Software nicht mit dem Commit-Vorgang fort. (Dies wird durch das Fehlen der Meldung commit complete in der CLI, des Elements <commit-success/> in der Junoscript-Ausgabe oder des Elements <ok/> in der NETCONF-Ausgabe angezeigt.) In dieser Situation hast du zwei Möglichkeiten, mit der Übertragung fortzufahren.

Zunächst kannst du mit den Befehl update verwenden, um die Änderungen der aktuellen Konfiguration in deiner privaten Datenbank zusammenzuführen. Die Software überschreibt deine Änderungen in der Regel nicht, sondern berechnet die Konfiguration, die sich aus dem Zusammenführen deiner Änderungen mit der aktuellen Konfiguration ergibt, und installiert sie dann in deiner privaten Datenbank. (Vielleicht ist es hilfreich, sich dies als Analogie zu git rebase vorzustellen.) Die Ergebnisse dieser Zusammenführung kannst du in deiner privaten Konfigurationsdatenbank einsehen.

Sobald du deine private Datenbank aktualisiert hast, kannst du die Änderungen festschreiben, ohne eine weitere Warnung zu erhalten (es sei denn, ein anderer Benutzer nimmt zwischen der Aktualisierung deiner Datenbank und dem Festschreiben der Änderungen weitere widersprüchliche Änderungen vor).

Die andere Sache, die du tun kannst, wenn du eine solche Warnung erhältst, ist, einfach den Befehl commit erneut auszuführen. Dadurch versucht die Junos-Software, deine Änderungen in die übergebene Konfiguration einzubinden. Im Allgemeinen wird ein zweiter commit Befehl nicht empfohlen, da du die endgültige Konfiguration, die sich aus diesen Änderungen ergibt, nicht genau vorhersagen kannst. Wenn du jedoch die Konsequenzen bedenkst, kannst du diese Funktion nutzen.

Tipp

Du kannst den exklusiven und den privaten Konfigurationsmodus mischen. In diesem Fall kannst du eine private Konfigurationsdatenbank öffnen, während ein anderer Benutzer eine exklusive Sperre für die Konfigurationsdatenbank besitzt. Allerdings kannst du Änderungen an deiner privaten Datenbank nicht festschreiben, während ein anderer Benutzer eine exklusive Sperre für die Konfigurationsdatenbank hat. Stattdessen erhältst du eine Fehlermeldung. Du musst warten, bis der Benutzer die exklusive Sperre aufhebt und kannst dann mit der Übertragung fortfahren.

Der Commit-Prozess

Wenn du den Befehl commitausführst, folgt die Junos-Software einem sorgfältig abgestimmten Prozess, um sicherzustellen, dass das Gerät am Ende eine brauchbare Konfiguration hat.

Hinweis

In diesem Prozess beschreiben wir ein System mit redundanten Routing Engines (REs). Tatsächlich beschreiben wir ein System mit mehr als zwei REs, da dieses System den kompliziertesten Commit-Prozess durchläuft. Um diesen Prozess für ein System mit weniger REs zu vereinfachen (sogar für ein System mit nur einer RE), lässt du einfach die Schritte weg, die für die anderen REs gelten.

Die Schritte sind wie folgt:

  1. Die Master-RE führt ihre Commit-Checks durch. Dies kann Folgendes beinhalten:

    • Überprüfung der Konsistenz der Daten. (Wenn sich zum Beispiel eine BGP-Gruppe auf eine Richtlinie bezieht, sollte diese Richtlinie definiert sein).

    • Ausführen von Commit-Skripten. (Commit-Skripte können Warnungen oder Fehler zurückgeben, die in diesem Stadium abgefangen werden).

    • Das Ausführen von Daemons in einem speziellen Modus, der eine tiefer gehende Analyse der Kandidatenkonfiguration durchführt.

  2. Die Master-RE gibt die Konfiguration an die anderen REs weiter und bittet diese, ihre Übergabeprüfungen durchzuführen.

  3. Die anderen REs aktivieren die neue Konfiguration.

  4. Die Master-RE aktiviert die neue Konfiguration.

Wenn bei irgendeinem Schritt des Prozesses ein Fehler entdeckt wird, wird der Commit-Prozess abgebrochen und die Software kehrt zur vorherigen aktiven Konfiguration zurück.

Dieser Prozess setzt einen Vertrag mit dem Benutzer durch: Junos nimmt sich die Zeit, die es braucht, um die Konfiguration gründlich zu überprüfen, und stellt im Gegenzug sicher, dass die Junos-Softwarekomponenten die Konfiguration am Ende des Prozesses analysieren können. Im Grunde genommen opferst du Zeit, um Zuverlässigkeit zu erhalten.

Validierung der Konfiguration

Die Validierung der Konfiguration erfolgt in mehreren Stufen.

Wenn du Konfigurationsanweisungen eingibst, prüft der Management-Daemon, ob jede Anweisung syntaktisch korrekt ist. (Mit "syntaktischer Korrektheit" ist gemeint, dass jeder Befehl richtig geformt ist und einen gültigen Konfigurationsblock bildet.) Wenn er ein Problem feststellt, lehnt er die Konfigurationsanweisung normalerweise ab.

Außerdem führt MGD einige semantischePrüfungen durch, während du die Konfiguration änderst. (Mit "semantischer Korrektheit" ist hier der Zustand gemeint, in dem die gesamte Konfiguration kohärent und verständlich ist.) Wenn er ein Problem feststellt, fügt er normalerweise einen Kommentar zur Konfiguration hinzu, um dich auf das Problem hinzuweisen. In diesem Beispiel verweist die BGP-Konfiguration auf eine Exportrichtlinie, aber die Richtlinie, auf die sie verweist, ist nicht in der Konfiguration enthalten:

[edit]
user@r0# show protocols bgp export
export does_not_exist; ## 'does_not_exist' is not defined

Sobald du die Konfiguration bestätigst, führt MGD erneut semantische Prüfungen durch, die jedoch entweder zu einem Fehler oder einer Warnung führen. Wenn du zum Beispiel versuchst, die Konfiguration zu bestätigen, während die BGP-Exportrichtlinie noch undefiniert ist, siehst du diese Ausgabe:

[edit]
user@r0# commit
error: Policy error: Policy does_not_exist referenced but not defined
[edit protocols bgp]
  'export'
    BGP: export list not applied
error: configuration check-out failed

Wenn die semantischen Prüfungen von MGD erfolgreich sind, wendet MGD alle Commit-Skripte an, die in der Kandidatenkonfiguration aufgeführt sind. Die Commit-Skripte können Warnungen oder Fehler zurückgeben. Warnungen werden dem Benutzer angezeigt, haben aber keinen Einfluss auf den Übergabeprozess. Fehler werden dem Benutzer angezeigt und brechen den Übergabevorgang ab. (Weitere Informationen zu Commit-Skripten findest du in Kapitel 5).

Wenn die Commit-Skripte keine Fehler zurückgeben, ruft MGD die verschiedenen Daemons auf, die an den Änderungen interessiert sind, und bittet sie zu überprüfen, ob die Konfiguration semantisch korrekt ist. Diese Daemons können Warnungen oder Fehler zurückgeben. Beides wird dem Benutzer angezeigt, aber nur bei Fehlern wird der Commit-Prozess abgebrochen.

Tipp

Verwende den Befehl commit check , um die Ergebnisse dieser Überprüfungen zu sehen, ohne die Konfiguration tatsächlich zu übertragen.

Aktivieren der Konfiguration

Wenn die RE die neue Konfiguration aktiviert, wird sie mit anderen Daten zusammengeführt (z. B. mit den Standardeinstellungen der Plattform und vorübergehenden Änderungen aus Commit-Skripten). Die neue Konfiguration wird dann atomar zur neuen "aktiven" Konfiguration.

Tipp

Du kannst die Plattformvorgaben für eine bestimmte Plattform sehen, indem du den folgenden Befehl ausführst:

show configuration groups junos-defaults

Diese Konfigurationsanweisungen werden wie jede andere Konfigurationsgruppe angewendet. Das bedeutet, dass sie durch die Benutzerkonfiguration außer Kraft gesetzt werden können. (Anders ausgedrückt: Konfigurationsgruppen werden "hinter" der vom Benutzer eingegebenen Konfiguration angewendet, was bedeutet, dass die vom Benutzer eingegebene Konfiguration widersprüchliche Teile der Standardkonfiguration verdecken kann). Das ist eine schicke und langatmige Art zu sagen, dass sich die Standardkonfigurationsanweisungen genau so verhalten, wie du es von Standardkonfigurationsanweisungen erwartest.

Signalisierungsdämonen

Sobald die Konfiguration festgeschrieben ist, nimmt MGD alle erforderlichen Änderungen vor (z. B. das Hinzufügen oder Löschen von Benutzerkonten oder andere Änderungen, für die MGD verantwortlich ist) und signalisiert anderen Daemons, die neue Konfiguration zu lesen und die Konfigurationsänderungen zu aktivieren, für die sie jeweils verantwortlich sind. Da die Junos-Software die Änderungen, die ein Benutzer vorgenommen hat, nachverfolgt, muss sie nur den Daemons signalisieren, die sich für die Teile der Konfiguration interessieren, die sich geändert haben. Abhängig von der genauen Änderung kann MGD daher mehr oder weniger Daemons anweisen, die Konfiguration erneut zu lesen. Das bedeutet, dass das Gerät je nach Inhalt der Änderung mehr oder weniger Arbeit für jede Konfigurationsänderung leisten kann.

Hinweis

Dieses Verhalten wird umso wichtiger, je größer die Konfiguration ist. Der Routing Protocol Daemon (RPD) braucht zum Beispiel viel weniger Zeit, um eine Konfiguration mit nur einer Routing-Instanz und 10 statischen Routen zu lesen, als eine Konfiguration mit 1.000 Routing-Instanzen und 400.000 statischen Routen. Wenn du die Art deiner Commit-Leistung kennst, kannst du intelligente Strategien für den Umgang mit Konfigurations-Commits entwickeln.

Du kannst dieses Verhalten sehen, indem du die Direktive | display detail an das Ende des commitBefehls anfügst. Dies bewirkt, dass die CLI die Details zu den Aktivitäten anzeigt, die MGD durchführt, um die Konfiguration zu aktivieren. Du solltest unter anderem sehen, welche Daemons MGD benachrichtigt, um die Konfiguration neu zu lesen.

In seltenen Fällen kann es vorkommen, dass ein Fehler in der Logik auftritt, der dazu führt, dass MGD einen Daemon nicht signalisiert. (Juniper sieht solche Fehler nicht gerne, aber sie können gelegentlich auftreten.) In solchen Fällen kannst du den Befehl commit full verwenden, um MGD zu veranlassen, alle Aktionen auszuführen, um die gesamte Konfiguration zu übernehmen, ohne zu berücksichtigen, was sich geändert hat. Wenn du das tust, tut MGD so, als ob sich die gesamte Konfiguration geändert hätte, und alle Daemons werden aufgefordert, ihre Konfiguration neu zu lesen.

Erstellen der zusammengeführten Konfigurationsansicht

Abbildung 1-9 zeigt unter , wie Konfigurationsdaten, einschließlich transienter Commit-Skript-Änderungen und Plattformvorgaben, in einer "zusammengeführten Ansicht" zusammengefasst werden, die die Daemons zur Aktivierung der neuen Konfiguration verwenden können.

This figure shows how configuration data is merged together. Transient commit script changes take precedence over the static configuration. The static configuration takes precedence over configuration groups (including the platform defaults). This configuration data is merged together into a "merged view", which is what the daemons read when they activate the configuration.
Abbildung 1-9. Die Kombination von Konfigurationsinformationen aus verschiedenen Quellen

In der Regel werden die Konfigurationsdaten mit diesem Vorrang angewendet:

  1. Vorübergehende Änderungen aus Commit-Skripten

  2. Die übertragene Konfiguration (beachte, dass dies alle dauerhaften Änderungen beinhaltet, die durch ein Commit-Skript vorgenommen wurden)

  3. Konfiguration, die von Konfigurationsgruppen angewendet wird (einschließlich der Standardeinstellungen der Plattform)

Hinweis

In Kapitel 5 findest du weitere Informationen zu Commit-Skripten, einschließlich des Unterschieds zwischen vorübergehenden und dauerhaften Konfigurationsänderungen. Für den Moment reicht es aus, wenn du verstehst, dass Commit-Skripte verschiedene Arten von Änderungen erzeugen können, die mit unterschiedlicher Priorität angewendet werden.

Um genauer zu sein, werden transiente Änderungen aus Commit-Skripten, der Commit-Konfiguration und den Konfigurationsgruppen in der statischen Konfiguration zusammengeführt. Nachdem die Daten aus diesen verschiedenen Quellen zusammengeführt wurden, ist diese "zusammengeführte" Ansicht der Konfiguration (du kannst sie als "Post-Inheritance"-Konfiguration bezeichnen) das, was die verschiedenen Daemons lesen, wenn sie eine neue Konfiguration aktivieren.

Hinweis

Konfigurationsgruppen werden nur auf die Konfiguration in der statischen Konfigurationsdatenbank angewendet. Sie werden nicht auf vorübergehende Änderungen durch Commit-Skripte angewandt.

Informationen zum Buch

Netzwerkautomatisierung findet an der interessanten Schnittstelle zwischen Programmierung und Netzwerktechnik statt. Es gibt sicherlich gute Programmierer, die auch hervorragende Ingenieure sind (oder umgekehrt), aber wir müssen ehrlich zu uns selbst sein und erkennen, dass diese wenigen Leute wahrscheinlich in einen ziemlich kleinen Raum passen.

Viel häufiger kommt es vor, dass ein Netzwerktechniker beschließt, etwas zu programmieren, oder dass ein Programmierer damit beauftragt wird, seine Fähigkeiten bei der Netzwerkautomatisierung einzusetzen. Das geschieht aus verschiedenen Gründen. Vielleicht bittet ein Unternehmen einen Netzwerkingenieur, neue Dienste einzuführen, die eine Automatisierung erfordern, wie z. B. SDN. Oder ein Netzwerkingenieur beschließt einfach, dass er seine Aufgaben automatisieren möchte, um Zeit zu sparen. Oder ein Unternehmen stellt einen Programmierer ein, um die Netzwerkautomatisierung zu implementieren. Wie auch immer, es kann leicht passieren, dass du dich außerhalb deiner Komfortzone wiederfindest, wenn du gebeten wirst, deine bereits vorhandenen Fähigkeiten mit neuen zu kombinieren, um etwas zu tun, das wirklich kompliziert erscheint, wie z.B. Netzwerkautomatisierung.

Unser Ziel ist es, dir das Erlernen dieser neuen Fähigkeiten zu erleichtern. Wenn du mit der Bedienung von Junos-Geräten sehr vertraut bist, geben wir dir die Informationen, die du brauchst, um diese Fähigkeiten bei der Netzwerkautomatisierung einzusetzen. Netzwerkautomatisierung muss nicht kompliziert sein. Mit der REST-API (die wir in Kapitel 3 beschreiben) kannst du sogar im Handumdrehen grundlegende Netzwerkautomatisierung durchführen. Für andere, fortgeschrittenere Themen musst du vielleicht externe Quellen zu Rate ziehen, um die verwendeten Programmiersprachen zu verstehen. In diesem Buch werden wir viel mit Python arbeiten. Wenn du dich mit Python nicht auskennst, solltest du vielleicht ein anderes Buch zu Rate ziehen, das Python behandelt, z. B. Learning Python von Mark Lutz (O'Reilly).

Wenn du mit der Programmierung sehr vertraut bist, helfen wir dir, deine Fähigkeiten auf Junos anzuwenden. Wir beschreiben die Methoden, die du zur Automatisierung mit Junos verwenden kannst, sowie einige der Tools, Bibliotheken und Protokolle, die diese Methoden unterstützen. Die Grundlagen von Junos werden wir jedoch nicht im Detail behandeln. Um sicherzugehen, dass du über die nötigen Hintergrundinformationen verfügst, haben wir einige der Grundlagen in diesem Kapitel behandelt. Wenn du weitere Informationen über Junos benötigst, solltest du eine der anderen verfügbaren Referenzen zu Rate ziehen. Das Buch Day One: Junos Tips, Techniques, and Templates 2011, herausgegeben von Jonathan Looney et al. (Juniper Networks Books), enthält beispielsweise Informationen, die dir helfen können, dich mit der Junos-Software vertraut zu machen.

Ein Ratschlag ist, das Gute nicht für das Perfekte zu opfern. Es gibt viele Möglichkeiten der Automatisierung, und es gibt viele Wege, wie ein Netzwerk von der Automatisierung profitieren kann. Wir möchten dich ermutigen, dich für etwas zu entscheiden und es zu nutzen, um die Dinge für dich einfacher zu machen. Wenn du neu in der Programmierung bist, bietet dir die REST-API vielleicht einen einfachen Weg, mit der Automatisierung zu beginnen, ohne viel mehr als ein Shell-Skript zu benötigen. Wenn du mit der Programmierung vertraut, aber neu in der Junos-Software bist, ist die PyEZ-Bibliothek vielleicht der einfachste Einstieg.

Ein weiterer Ratschlag ist, unvoreingenommen zu sein. Es gibt eine ganze Reihe von Werkzeugen. Das gibt dir die Flexibilität, die du brauchst, um das richtige Werkzeug für die richtige Aufgabe zu wählen. Es ist leicht, einen Tunnelblick zu bekommen und zu versuchen, alles auf die gleiche Weise zu lösen. Es gibt jedoch in der Regel keine "Einheitslösung", wenn es um Automatisierung geht. Ein Commit-Skript kann die richtige Antwort für ein Problem sein, während ein PyEZ-Skript die richtige Lösung für ein anderes Problem sein kann. Deshalb ist es am besten, sich mit allen Werkzeugen vertraut zu machen und sie dort einzusetzen, wo sie am besten geeignet sind.

Außerdem solltest du dich daran erinnern, dass Tools miteinander kombiniert werden können. Du könntest zum Beispiel PyEZ verwenden, um eine Konfiguration zu verteilen, und ein Commit-Skript verwenden, um diese Konfiguration zu erweitern. Auf diese Weise können die beiden Werkzeuge zusammenarbeiten, um die gewünschte Konfiguration zu erstellen.

Wir hoffen, dass du im weiteren Verlauf des Buches erfährst, wie du durch die Automatisierung deines Netzwerks mit der Junos-Software Zeit sparen, die Effizienz steigern, die Genauigkeit erhöhen und dir das Leben erleichtern kannst.

Get Junos-Verwaltung automatisieren now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial