[PYTHON] Ich habe versucht, PyEZ und JSNAPy zu verwenden. Teil 4: Automatisieren Sie die ISP-Einrichtung mit PyEZ und JSNAPy

Ich habe versucht, PyEZ und JSNAPy zu verwenden. Dies ist die letzte Folge von. Dieses Mal werde ich den Inhalt der Automatisierung der eBGP-Peering-Einstellungsarbeit vorstellen, die in der ISP-Backbone-Arbeit mit PyEZ und JSNAPy üblich ist.

Ich habe versucht, PyEZ und JSNAPy zu verwenden. Teil 1: Übersicht Ich habe versucht, PyEZ und JSNAPy zu verwenden. Teil 2: Ich habe versucht, PyEZ zu verwenden Ich habe versucht, PyEZ und JSNAPy zu verwenden. Teil 3: Ich habe versucht, JSNAPy zu verwenden Ich habe versucht, PyEZ und JSNAPy zu verwenden. Teil 4: Automatisieren der ISP-Einstellungsarbeit mit PyEZ und JSNAPy (Imakoko)

Was ist in der letzten Folge zu tun?

Ich werde versuchen, die BGP-Peering-Arbeit zu automatisieren, die eine der Aufgaben ist, die häufig im ISP-Backbone auftreten.

BGP Peering ist eine eBGP-Verbindungsoperation zum Verbinden der Router der Organisation, der die AS-Nummer gehört. Durch Eingabe der eBGP-Einstellungen, während die Router in einem bestimmten Rechenzentrum direkt miteinander verbunden sind, werden Routeninformationen und Datenverkehr ausgetauscht.

Der Ablauf der BGP-Peering-Arbeit ist wie folgt.

1. Verhandlungen zwischen Organisationen / Anordnung der Verkabelung vor Ort
2. Kabelverkabelung
3. Schnittstelleneinstellungen
4. Bestätigung der Kommunikation
5. Eingabe der eBGP-Einstellungen
6. Bestätigung der Streckenwerbung
7. Überprüfen Sie den Verkehrsübergangsstatus

Dieses Mal werden wir die logischen Einstellungsarbeitsschritte 3 bis 6 automatisieren. Anstatt den gesamten Prozess plötzlich vollständig zu automatisieren, gingen wir davon aus, dass die Einstellungs- / Bestätigungsarbeiten bis kurz vor der Automatisierung des Commits durchgeführt wurden und ob das Commit ausgeführt werden konnte oder nicht, halbautomatisiert wurde, indem wir es dem Urteil des Bedieners überließen.

Automatisierte Systemkonfiguration

Dies ist ein Systemkonfigurationsabbild.

Hier geht es darum, die Schnittstelleneinstellungen und eBGP-Einstellungen in den JUNOS-Router "Firefly 1" einzugeben, der nicht über die PyEZ-Bibliothek und die JSNAPy-Bibliothek eingerichtet wurde.

In diesem System erstellt der Worker die folgende "Szenariodatei" als Alternative zum Arbeitsablaufhandbuch und zur Routerkonfiguration, die der Worker traditionell erstellt hat. Durch Laden dieser Szenariodatei in das Szenarioausführungsprogramm kann der Prozess der Routereinstellung und der Überprüfung des Netzwerkzustands gemäß dem vom Bediener beabsichtigten Verfahren fortgesetzt werden. In diesem System kann der Mitarbeiter nur arbeiten, indem er diese Szenariodatei erstellt, ohne zuvor das herkömmliche Verfahrenshandbuch und die Routerkonfiguration zu erstellen. Ziel ist es daher, die Belastung für den Mitarbeiter und den Prüfer zu verringern.

Szenariodatei

purpus:  |
Diese Arbeit wird von ABC Co., Ltd. durchgeführt.(AS65002)Und der Router betrieben von
Der Zweck besteht darin, einen privaten Peer an Basis A aufzubauen.
Der Routenaustausch wird Route für Route empfangen/Wird gesendet und hängt von der Arbeit ab
Die Auswirkungen des Netzwerks werden als gering angenommen.
operator: Taiji Tsuchiya
operation_date: 20161115
hosts:
  management_ipaddress: 192.168.34.16
  hostname: firefly1
  model: firefly-perimeter
  username: user1
  password: password1
scenario:
  - test_hostname
  - test_model
  - test_interface:
      interface_name: ge-0/0/2
      interface_status: up
  - set_add_interface:
      interface_name: ge-0/0/2
      interface_address_ipv4: 192.168.35.1
      interface_subnet_ipv4: 30
      interface_description: AS65002_peer
  - test_interface:
      interface_name: ge-0/0/2
      interface_status: up
  - set_add_bgp_neighbor:
      interface_name: ge-0/0/2
      neighbor_asnum: 65002
      neighbor_address_ipv4: 192.168.35.2
      neighbor_description: AS65002_peer
  - test_bgp_neighbor:
      neighbor_address_ipv4: 192.168.35.2
      neighbor_status: Established
  - set_add_bgp_policy_external:
      external_policy_name: AS65002_export
      advertised_route_address_ipv4: 10.10.10.0
      advertised_route_subnet_ipv4: 24
      interface_name: ge-0/0/2
      neighbor_address_ipv4: 192.168.35.2
  - sleep_10sec
  - test_bgp_received_route:
      neighbor_address_ipv4: 192.168.35.2
      received_route_address_ipv4: 10.10.30.0
      received_route_subnet_ipv4: 24
  - test_bgp_advertised_route:
      neighbor_address_ipv4: 192.168.35.2
      advertised_route_address_ipv4: 10.10.10.0
      advertised_route_subnet_ipv4: 24

Wenn Sie sich die obige Szenariodatei ansehen, fällt es Ihnen möglicherweise auf den ersten Blick schwer, sie zu lesen, da sie voller englischer Wörter ist. Die Szenariodatei besteht aus einer Kombination des bei der Arbeit am Router erforderlichen "Prozedurnamens" und der dafür erforderlichen "Parameter". .. Die Prozedur, die mit "set _..." beginnt, zeigt die Router-Einstellungsarbeit an, und die Prozedur, die mit "test _..." beginnt, zeigt die Router-Bestätigungsarbeit an.

Wenn Sie die Szenariodatei genau lesen, können Sie sich vorstellen, welche Art von Verfahren Sie realisieren möchten. Und ich denke, Sie können den Eindruck gewinnen, dass es viel einfacher ist, als die Routerkonfiguration vorzubereiten.

Als Entwurfskonzept dieses Systems gilt: "Es ist besser, die Informationen wie eine Szenariodatei bis zum Äußersten zu vereinfachen, als ein Arbeitsablaufhandbuch mit normalem Japanisch für die Punkte, die der Ersteller / Prüfer überprüfen sollte Wir implementieren ein solches System mit der Idee, dass es möglich sein könnte, unsere Aufmerksamkeit auf die Inspektion zu konzentrieren (da es keine unnötigen Bestätigungselemente gibt).

Zu diesem Zeitpunkt habe ich über "Der Worker erstellt in diesem System keine Routerkonfiguration" gesprochen, aber Sie haben sich möglicherweise gefragt, "wie Sie eine Eingabekonfiguration erstellen?". In diesem System enthält die Routerkonfiguration die folgenden Vorlagendateien für mehrere Muster im System im Voraus und generiert automatisch die Routerkonfiguration, indem auf die Vorlagendatei verwiesen wird, die jeder aufzurufenden Prozedur entspricht. Ist implementiert.

Vorlagendatei_Für die Konfiguration von BGP-Nachbarn

protocols {
    bgp {
        family inet {
            unicast;
        }
        group {{ interface_name }} {
            type external;
            neighbor {{ neighbor_address_ipv4 }} {
                description {{ neighbor_description }};
                peer-as {{ neighbor_asnum }};
            }
        }
    }
}

Die Routerkonfigurationsdatei wird automatisch generiert, indem die aus der Szenariodatei extrahierten Parameter (YAML-Format) mit der obigen Vorlagendatei (Jinja2-Format) abgeglichen werden. Durch Extrahieren der Parameter aus der Szenariodatei und Generieren der Routerkonfiguration für jede Prozedur kann der Bediener die Probleme der herkömmlichen Vorerstellungsarbeit der Routerkonfiguration sparen.

Vorlagenparameter(Aus der Szenariodatei extrahiert)

- set_add_bgp_neighbor:
      interface_name: ge-0/0/2
      neighbor_asnum: 65002
      neighbor_address_ipv4: 192.168.35.2
      neighbor_description: AS65002_peer

Automatisch generierte Router-Konfigurationsdatei

protocols {
    bgp {
        family inet {
            unicast;
        }
        group ge-0/0/2 {
            type external;
            neighbor 192.168.35.2 {
                description AS65002_peer;
                peer-as 65002;
            }
        }
    }
}

Wenn Sie dem obigen Ablauf folgen und die Router-Einstellungsprozedur und die Router-Bestätigungsprozedur ausführen, die aus der Szenariodatei der Reihe nach extrahiert und generiert wurden, kann die Arbeit in der vom Arbeiter beabsichtigten Reihenfolge fortgesetzt werden. ..

Ergebnis der Programmausführung

Das endgültige Automatisierungsprogramm wird auf GitHub veröffentlicht. https://github.com/taijiji/scenarioJUNOS

Wenn Sie das Programm mit firefly1 (Schnittstelleneinstellung nicht implementiert, eBGP-Einstellung nicht implementiert) und firely2 (Schnittstelleneinstellung abgeschlossen, eBGP-Einstellung abgeschlossen) ausführen, ist der Vorgang wie folgt. Der linke Bildschirm zeigt das Automatisierungssystem, der obere rechte zeigt den firefly1-Router und der untere rechte zeigt den firefly2-Router.

Grüne Buchstaben kennzeichnen "den Teil, in dem die Normalität bestätigt wird", rote Buchstaben kennzeichnen "den Teil, in dem die Abnormalität bestätigt wird" und schwarze Buchstaben kennzeichnen "den Teil, in dem der Bediener eine Entscheidung treffen möchte".

Das Ausführungsergebnis des Programms wird wie folgt angezeigt.

↓ Ich wage es, NG hier zur Demonstration zu veröffentlichen. Das Einrichten einer BGP-Sitzung dauert mehrere zehn Sekunden. Sie müssen also schlafen und warten, bis Sie eingerichtet sind.

Es mag ärgerlich sein, viele Zeichen anzuzeigen, aber während der eigentlichen Arbeit müssen Sie sich nur auf die "gelben Zeichen" und "roten Zeichen" konzentrieren, die zu Anomalien führen können, und die grünen Zeichen sind konzentriert. Es besteht keine Notwendigkeit zur Bestätigung. Dies wird die Belastung des Arbeitnehmers erheblich verringern. Die Arbeiter können dann mit all ihren Nerven daran arbeiten, gefährliche Anomalien zu erkennen, auf die sie sich am meisten konzentrieren sollten.

Zusammenfassung

Dieses Mal konnten wir ein automatisiertes System basierend auf einer Szenariodatei erstellen, die das herkömmliche Arbeitsablaufhandbuch vereinfacht. Mit PyEZ und JSNAPy konnte ich dieses System in etwa zwei Wochen tatsächlicher Arbeit erstellen, ohne in einer großen Wand hängen zu bleiben. (Etwa die Hälfte davon war die Zeit zum Laden des Dokuments.)

PyEZ ist eine sehr kollaborative Bibliothek, und die Dokumentation ist gut organisiert, sodass fast keine Verstopfungen auftraten. (Wenn ich es wage, es zu geben, bin ich nur durchquert, ohne zu wissen, dass der für NETCONF über SSH verwendete Port TCP830 ist.)

JSNAPy war beim Erstellen von Testwerkzeugen sehr hilfreich. Die Möglichkeit, dieses System ohne reguläre Ausdrücke zu implementieren, hat mir geholfen, es schnell zu implementieren. Da das Tool selbst jedoch neu ist, wurde die Dokumentation noch nicht erstellt, und ich war mehrmals süchtig danach. Insbesondere war es schwierig, die Mittel zum Spezifizieren des xpath und zum Erhalten der Testergebnisse zu verstehen, und ich hatte oft das Gefühl, dass "ich solche Testergebnisse erhalten möchte, aber wie kann ich die Testdatei schreiben?" Eigentlich gibt es keine Möglichkeit, also habe ich oft die denkbaren Testbedingungen aufgeschrieben, ausgeführt und diejenigen übernommen, die bei der Betrachtung der Ergebnisse gut funktionierten. Ich stelle mir vor, dass mit zunehmender Anzahl von Beispieltestdateien in der Zukunft die Anzahl der Abhängigkeiten hier abnehmen wird. Es gibt einige Dinge, die wir nicht tun konnten, um eine Testdatei in kürzerer Zeit zu erstellen. Zum Beispiel, wie man das Ergebnis erhält, wenn test_ping oder test_traceroute fehlschlägt, Ein wenig komplizierte Bestätigungselemente wie "Bedingte Anweisung zur Bestätigung, dass eine andere als die Zielroute nicht empfangen / gesendet wird (doppelte Ablehnung)" und "Bestätigung, dass BGP nicht funktioniert" wurden noch nicht implementiert. Ich tat.

In Bezug auf das Demoprogramm, das ich dieses Mal erstellt habe, konnte ich, obwohl es aus Zeitmangel nicht vollständig implementiert wurde, die ideale Form der Netzwerkarbeit für die nächste Generation mit einem konkreten Bild durch die Demo vermitteln. Ich bin froh.

Die Probleme bei der Einführung dieses Systems sind "ob Betreiber und Prüfer diese Szenariodatei im YAML-Format akzeptieren" und "ob derselbe Mechanismus als herstellerkompatibles Tool auf den Routern anderer Unternehmen bereitgestellt werden kann". Es sind noch einige Probleme offen. In diesem Bereich halte ich es für gut, wenn wir das System schrittweise an die Anforderungen des Betriebsstandorts anpassen und das System tatsächlich einführen könnten.