Verwenden von Junos Snapshot Administrator in Python (JSNAPy) in Ansible Playbooks
Führen Sie JSNAPy-Tests als Teil eines Ansible-Playbooks durch, um Snapshots der Laufzeitumgebung von Junos-Geräten zu erfassen und zu prüfen.
Mit Junos® Snapshot Administrator in Python (JSNAPy) können Sie Snapshots der Laufzeitumgebung Ihrer Junos-Geräte erfassen und prüfen. Sie können die Konfiguration und den Betriebsstatus eines Geräts erfassen und überprüfen sowie Änderungen an einem Gerät überprüfen. Juniper Networks stellt ein Ansible-Modul bereit, mit dem Sie JSNAPy-Tests für Junos-Geräte als Teil eines Ansible-Playbooks ausführen können. Tabelle 1 gibt einen Überblick über das verfügbare Modul.
| Inhaltsgruppe |
Modulname |
|---|---|
|
|
Sie müssen Junos Snapshot Administrator in Python auf dem Ansible-Steuerungsknoten installieren, um das juniper.device.jsnapy Modul verwenden zu können. Installationsanweisungen und Informationen zum Erstellen von JSNAPy-Konfigurations- und Testdateien finden Sie in der Dokumentation zu Junos Snapshot Administrator in Python.
In den folgenden Abschnitten wird die Verwendung des Moduls juniper.device.jsnapy in Ansible-Playbooks erläutert.
Modulübersicht
Das juniper.device.jsnapy Modul ermöglicht es Ihnen, JSNAPy-Funktionen aus einem Ansible-Playbook heraus auszuführen, einschließlich:
-
Erfassen und Speichern eines Snapshots der Laufzeitumgebung
-
Vergleich zweier Snapshots
-
Einen Schnappschuss aufnehmen und sofort auswerten
Das Modul erfordert die Angabe des action Arguments und entweder des config_file Oder-Arguments test_files . Das action Argument gibt die auszuführende JSNAPy-Aktion an. Tabelle 2 enthält einen Überblick über die gültigen action Werte und die entsprechenden JSNAPy-Befehle.
| action Wert |
Beschreibung |
Äquivalenter JSNAPy-Befehl |
|---|---|---|
|
|
Vergleichen Sie zwei vorhandene Momentaufnahmen basierend auf den angegebenen Testfällen, oder vergleichen Sie die Momentaufnahmen Knoten für Knoten, wenn keine Testfälle bereitgestellt werden. |
|
|
|
Erstellen Sie Snapshots für die Befehle oder RPCs, die in den Testdateien angegeben sind, nachdem Sie Änderungen an den angegebenen Geräten vorgenommen haben. |
|
|
|
Erstellen Sie Snapshots für die in den Testdateien angegebenen Befehle oder RPCs, bevor Sie Änderungen an den angegebenen Geräten vornehmen. |
|
|
|
Erstellen Sie Snapshots der in den Testdateien angegebenen Befehle oder RPCs, und werten Sie die Snapshots sofort anhand vordefinierter Kriterien in den Testfällen aus. |
|
Wenn Sie JSNAPy in der Befehlszeile ausführen, führt JSNAPy die angeforderte Aktion auf den Hosts aus, die im Abschnitt der hosts Konfigurationsdatei angegeben sind. Im Gegensatz dazu führt das Ansible-Modul die angeforderte Aktion auf den Hosts aus, die im Ansible-Playbook angegeben sind. Daher kann das Modul entweder auf eine Konfigurationsdatei verweisen und den hosts Abschnitt ignorieren, oder es kann direkt auf eine oder mehrere Testdateien verweisen.
Daher benötigt das juniper.device.jsnapy Modul zusätzlich zum action Argument entweder das config_file Argument oder das test_files Argument, um die JSNAPy-Konfigurationsdatei oder die JSNAPy-Testdateien anzugeben, die für die angegebene Aktion verwendet werden sollen. Tabelle 3 beschreibt die config_file test_files und-Argumente.
| Modul-Argument |
Wert |
Zusatzinformation |
|---|---|---|
|
|
Absoluter oder relativer Dateipfad zu einer JSNAPy-Konfigurationsdatei. |
Wenn der Pfad relativ ist, sucht das Modul an den folgenden Speicherorten und in der angegebenen Reihenfolge nach der Konfigurationsdatei:
Wenn die Konfigurationsdatei mithilfe eines relativen Dateipfads auf Testdateien verweist, sucht das Modul zuerst nach den Testdateien im Playbook-Verzeichnis und dann nach den Testdateien im Standardverzeichnis |
|
|
Absoluter oder relativer Dateipfad zu einer JSNAPy-Testdatei. Dabei kann es sich um einen einzelnen Dateipfad oder eine Liste von Dateipfaden handeln. |
Für jede Testdatei, die einen relativen Pfad angibt, sucht das Modul an den folgenden Speicherorten und in der angegebenen Reihenfolge nach der Datei:
|
Die config_file Argumente und test_files können einen absoluten oder relativen Dateipfad annehmen. Wenn Sie einen relativen Dateipfad verwenden, können Sie optional das dir Argument module einschließen, um das Verzeichnis anzugeben, in dem sich die Dateien befinden. Wenn für ein config_file Argument test_files oder ein relativer Dateipfad verwendet wird, sucht das Modul zunächst im Ansible-Playbook-Verzeichnis nach der Datei, auch wenn das dir Argument vorhanden ist. Wenn die Datei nicht im Playbook-Verzeichnis vorhanden ist, prüft das Modul im dir Argumentverzeichnis, sofern es angegeben ist, oder im Verzeichnis /etc/jsnapy/testfiles , wenn das dir Argument weggelassen wird. Das Playbook generiert eine Fehlermeldung, wenn die Datei nicht gefunden wird.
Es ist wichtig zu beachten, dass das Modul beim Einschließen des dir Parameters diese Position nur auf das angegebene config_file oder-Argument test_files überprüft. Wenn Sie also eine Konfigurationsdatei angeben, prüft dir das Modul das Verzeichnis nicht nach den Testdateien, die Sie in der Konfigurationsdatei angeben. Wenn die Konfigurationsdatei auf relative Pfade für die Testdateien verweist, sucht das Modul nur im Playbookverzeichnis und im Standardverzeichnis testfiles nach den Testdateien.
Angenommen, Sie verfügen über die folgende JSNAPy-Konfigurationsdatei jsnapy_config_base_tests.yaml, die sich im Verzeichnis ~/jsnapy/testfiles befindet und auf mehrere JSNAPy-Testdateien verweist:
user@ansible-cn:~/ansible$ cat ~/jsnapy/testfiles/jsnapy_config_base_tests.yaml tests: - system_util_baseline.yaml - verify_ldp_neighbors.yaml - verify_ospf_neighbors.yaml - verify_bgp_neighbors.yaml - test_interface_operstate.yaml
Das folgende Beispielplaybook führt die snap_pre Aktion für jede der Testdateien in der Konfigurationsdatei jsnapy_config_base_tests.yaml aus. Wenn die Konfigurationsdatei nicht im Playbook-Verzeichnis vorhanden ist, sucht das Modul nach der Datei im dir Verzeichnis, das in diesem Fall ~/jsnapy/testfiles ist. Die Konfigurationsdatei verwendet relative Pfade für die Testdateien. Daher sucht das Modul zuerst nach den Testdateien im Playbook-Verzeichnis und dann nach den Testdateien im Standardverzeichnis testfiles .
---
- name: Junos Snapshot Administrator tests
hosts: dc1a
connection: local
gather_facts: no
tasks:
- name: Take a pre-maintenance snapshot
juniper.device.jsnapy:
action: "snap_pre"
dir: "~/jsnapy/testfiles"
config_file: "jsnapy_config_base_tests.yaml"
Alternativ kann das jsnapy Modul den test_files Parameter verwenden, um die einzelnen zu verwendenden Testdateien anzugeben. Das folgende Playbook führt die gleichen Tests aus wie im vorherigen Playbook-Beispiel. In diesem Fall sucht das Modul zuerst nach den Testdateien im Playbook-Verzeichnis und dann nach den Testdateien im dir Verzeichnis.
---
- name: Junos Snapshot Administrator tests
hosts: dc1a
connection: local
gather_facts: no
tasks:
- name: Take a pre-maintenance snapshot
juniper.device.jsnapy:
action: "snap_pre"
dir: "~/jsnapy/testfiles"
test_files:
- system_util_baseline.yaml
- verify_ldp_neighbors.yaml
- verify_ospf_neighbors.yaml
- verify_bgp_neighbors.yaml
- test_interface_operstate.yaml
Ab Junos Snapshot Administrator in Python Version 1.3.0 ist der Standardspeicherort für Konfigurations- und Testdateien ~/jsnapy/testfiles. Der Standardspeicherort in einer virtuellen Umgebung oder für frühere Versionen ist jedoch /etc/jsnapy/testfiles.
Das Modul führt die angeforderte Aktion auf den im Ansible-Playbook angegebenen Hosts aus, auch wenn das Modul auf eine Konfigurationsdatei verweist, die einen hosts Abschnitt enthält. Das Modul meldet fehlgeschlagen, wenn ein Fehler auftritt und die JSNAPy-Tests nicht ausführen kann. Es wird nicht als fehlgeschlagen gemeldet, wenn einer oder mehrere der JSNAPy-Tests fehlschlagen. Um die JSNAPy-Testergebnisse zu überprüfen, registrieren Sie die Antwort des Moduls, und verwenden Sie das ansible.builtin.assert Modul, um das erwartete Ergebnis in der Antwort zu überprüfen.
Junos Snapshot Administrator in Python protokolliert Informationen zu seinen Vorgängen standardmäßig in der Datei /var/log/jsnapy/jsnapy.log . Das juniper.device.jsnapy Modul kann optional das Argument enthalten, das logfile den Pfad zu einer beschreibbaren Datei auf dem Ansible-Kontrollknoten angibt, in der Informationen für die jeweilige Aufgabe protokolliert werden. Der Ausführlichkeitsgrad und die Debugging-Optionen von Ansible bestimmen den Grad der in der Datei protokollierten Informationen. Standardmäßig werden nur Meldungen des Schweregrads WARNUNG oder höher protokolliert. Um Meldungen zu protokollieren, die gleich oder höher als der Schweregrad INFO oder der Schweregrad DEBUG sind, führen Sie das Playbook mit der -v Befehlszeilenoption or -vv aus.
Wenn Sie JSNAPy-Tests in einem Ansible-Playbook ausführen, können Sie Informationen zu fehlgeschlagenen JSNAPy-Tests speichern oder zusammenfassen. Weitere Informationen finden Sie unter Überprüfen fehlgeschlagener JSNAPy-Tests.
Erstellen und Vergleichen von Snapshots
Mit JSNAPy können Sie Snapshots der Laufzeitumgebung Ihrer Junos-Geräte vor und nach einer Änderung erfassen und die Snapshots dann vergleichen, um die erwarteten Änderungen zu überprüfen oder unerwartete Probleme zu identifizieren. Das juniper.device.jsnapy Modul ermöglicht es Ihnen, JSNAPy-Snapshots als Teil eines Ansible-Playbooks zu erstellen und zu vergleichen. Das Modul speichert jeden Snapshot für jeden Host in einer separaten Datei im standardmäßigen JSNAPy-Snapshot-Verzeichnis unter Verwendung eines vordefinierten Dateinamens. Weitere Informationen zu den Ausgabedateien finden Sie unter Grundlegendes zur Ausgabe des jsnapy-Moduls.
Um Baseline-Snapshots von einem oder mehreren Geräten zu erstellen, bevor Sie Änderungen vornehmen, legen Sie das action Argument des Moduls auf snap_prefest, und geben Sie eine Konfigurationsdatei oder eine oder mehrere Testdateien an.
Im folgenden Playbook werden PRE-Snapshots für jedes Gerät in der Ansible-Bestandsgruppe gespeichert. Die Aufgabe verweist auf die Konfigurationsdatei jsnapy_config_base_tests.yaml im Verzeichnis ~/jsnapy/testfiles und protokolliert Meldungen in der jsnapy_tests.log Datei im Playbookverzeichnis.
---
- name: Junos Snapshot Administrator tests
hosts: dc1
connection: local
gather_facts: no
tasks:
- name: Take a pre-maintenance snapshot
juniper.device.jsnapy:
action: "snap_pre"
dir: "~/jsnapy/testfiles"
config_file: "jsnapy_config_base_tests.yaml"
logfile: "jsnapy_tests.log"
Um nach dem Ausführen von Änderungen einen Snapshot von einem oder mehreren Geräten zu erstellen, legen Sie das action Argument des Moduls auf snap_postfest, und geben Sie eine Konfigurationsdatei oder eine oder mehrere Testdateien an.
Im folgenden Playbook werden POST-Snapshots für jedes Gerät in der Ansible-Bestandsgruppe gespeichert. Die Aufgabe verweist auf dieselbe jsnapy_config_base_tests.yaml-Konfigurationsdatei im Verzeichnis ~/jsnapy/testfiles und protokolliert Meldungen in der jsnapy_tests.log Datei im Playbookverzeichnis.
---
- name: Junos Snapshot Administrator tests
hosts: dc1
connection: local
gather_facts: no
tasks:
- name: Take a post-maintenance snapshot
juniper.device.jsnapy:
action: "snap_post"
dir: "~/jsnapy/testfiles"
config_file: "jsnapy_config_base_tests.yaml"
logfile: "jsnapy_tests.log"
Wenn das jsnapy Modul eine snap_pre Aktion oder eine snap_post Aktion ausführt, speichert es jeden Snapshot für jeden Host in einer separaten Datei mit automatisch generierten Dateinamen, die ein "PRE"- bzw. "POST"-Tag enthalten. Um die PRE und POST Snapshots zu vergleichen, um die Updates schnell zu überprüfen oder Probleme zu identifizieren, die sich aus den Änderungen ergeben haben könnten, legen Sie das action Argument des Moduls auf checkauf fest, und geben Sie dieselbe Konfigurationsdatei oder Testdateien an, die zum Erstellen der Snapshots verwendet wurden.
Wenn das Modul eine check Aktion ausführt, vergleicht JSNAPy die PRE - und POST-Snapshots für jeden Test auf jedem Gerät und wertet sie anhand der Kriterien aus, die tests: im Abschnitt der Testdateien definiert sind. Wenn in den Testdateien keine Testfälle definiert sind, vergleicht JSNAPy die Snapshots stattdessen Knoten für Knoten. Um die Testergebnisse zu überprüfen, registrieren Sie die Antwort des Moduls, und verwenden Sie das ansible.builtin.assert Modul, um das erwartete Ergebnis in der Antwort zu überprüfen.
Im folgenden Playbook werden die Snapshots für zuvor ausgeführte snap_pre Geräte und snap_post Aktionen für jedes Gerät in der Ansible-Bestandsgruppe verglichen. Die Ergebnisse werden anhand der Kriterien in den Testdateien ausgewertet, auf die in der Konfigurationsdatei verwiesen wird. Das Playbook registriert die Antwort des Moduls als ""test_result und verwendet das ansible.builtin.assert Modul, um zu überprüfen, ob alle Tests auf dem angegebenen Gerät bestanden wurden.
---
- name: Junos Snapshot Administrator tests
hosts: dc1
connection: local
gather_facts: no
tasks:
- name: Compare PRE and POST snapshots
juniper.device.jsnapy:
action: "check"
dir: "~/jsnapy/testfiles"
config_file: "jsnapy_config_base_tests.yaml"
logfile: "jsnapy_tests.log"
register: test_result
- name: Verify JSNAPy tests passed
ansible.builtin.assert:
that:
- "test_result.passPercentage == 100"
Wenn Sie das Playbook ausführen, erkennen die Assertionen schnell, welche Geräte die Tests nicht bestanden haben.
user@host:~$ ansible-playbook jsnapy-baseline-check.yaml
PLAY [Junos Snapshot Administrator tests] *************************************
TASK [Compare PRE and POST snapshots] *****************************************
ok: [dc1a.example.net]
ok: [dc1b.example.net]
TASK [Verify JSNAPy tests passed] *********************************************
ok: [dc1b.example.net] => {
"changed": false,
"msg": "All assertions passed"
}
fatal: [dc1a.example.net]: FAILED! => {
"assertion": "test_result.passPercentage == 100",
"changed": false,
"evaluated_to": false,
"msg": "Assertion failed"
}
to retry, use: --limit @/home/user/jsnapy-baseline-check.retry
PLAY RECAP ********************************************************************
dc1b.example.net : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
dc1a.example.net : ok=1 changed=0 unreachable=0 failed=1 skipped=0 rescued=0 ignored=0
Ausführen von Snapcheck-Vorgängen
Mit JSNAPy können Sie Snapshots für die in JSNAPy-Testdateien angegebenen Befehle oder RPCs erstellen und die Snapshots sofort anhand vordefinierter Kriterien in den Testfällen auswerten. Mit dem juniper.device.jsnapy Modul können Sie einen JSNAPy-Snapcheck-Vorgang als Teil eines Ansible-Playbooks durchführen.
Um einen Snapshot zu erstellen und ihn sofort basierend auf dem vordefinierten Satz von Kriterien im tests: Abschnitt der Testdateien auszuwerten, legen Sie das action Argument des Moduls auf snapcheckfest, und geben Sie eine Konfigurationsdatei oder eine oder mehrere Testdateien an. Um die Testergebnisse zu überprüfen, registrieren Sie die Antwort des Moduls, und verwenden Sie das ansible.builtin.assert Modul, um das erwartete Ergebnis in der Antwort zu überprüfen.
Beispielsweise speichert das folgende Playbook für jedes Gerät in der Ansible-Bestandsgruppe einen separaten Snapshot für jeden Befehl oder RPC in den Testdateien, registriert die Antwort des Moduls und verwendet das ansible.builtin.assert Modul, um zu überprüfen, ob alle in den Testdateien definierten Tests auf diesem Gerät erfolgreich waren.
---
- name: Junos Snapshot Administrator tests
hosts: dc1
connection: local
gather_facts: no
tasks:
- name: Take a snapshot and immediately evaluate it
juniper.device.jsnapy:
action: "snapcheck"
dir: "~/jsnapy/testfiles/"
test_files:
- "test_interface_status.yaml"
- "test_bgp_neighbor.yaml"
logfile: "jsnapy_tests.log"
register: test_result
- name: Verify JSNAPy tests passed
ansible.builtin.assert:
that:
- "test_result.passPercentage == 100"
Grundlegendes zur JSNAPY-Modulausgabe
Wenn das Modul eine snap_preAktion ausführt, snap_postspeichert snapcheck es juniper.device.jsnapy die Snapshots automatisch im Verzeichnis JSNAPy snapshots. Das Modul verwendet die standardmäßigen JSNAPy-Verzeichnisse, es sei denn, Sie ändern die JSNAPy-Konfigurationsdatei (jsnapy.cfg), um einen anderen Speicherort anzugeben. Das Modul erstellt eine separate Datei für jeden Befehl oder RPC, der auf jedem Gerät in der Ansible-Bestandsgruppe ausgeführt wird. In Tabelle 4 sind die Dateinamen der Momentaufnahmedateien für jeden Wert des action Arguments aufgeführt.
Ab Junos Snapshot Administrator in Python Version 1.3.0 sind die Standardverzeichnisse für die JSNAPy-Testdateien und -Snapshots ~/jsnapy/testfiles bzw. ~/jsnapy/snapshots. Die Standardverzeichnisse in einer virtuellen Umgebung oder für frühere Versionen sind jedoch /etc/jsnapy/testfiles und /etc/jsnapy/snapshots.
|
|
Ausgabedateien |
|---|---|
|
|
hostname_PRE_hash_.commandformat |
|
|
hostname_POST_hash_.commandformat |
| |
hostname_snap_temp_hash_command.format |
wo:
-
hostname—Hostname des Geräts, auf dem der Befehl oder RPC ausgeführt wird.
-
(PRE | BEITRAG | snap_temp) – Tag, der die Aktion identifiziert. Der
snapcheckVorgang verwendet dasPRETag in aktuellen Releases; in früheren Releases verwendet der Vorgang dassnap_tempTag. -
hash– Hash, der aus für Testdateien generiert wird
kwargs, die dierpcSchlüssel undkwargsenthalten.Wenn Testdateien denselben RPC verwenden, aber unterschiedliche Argumente enthalten, und die RPCs auf demselben Host ausgeführt werden, stellt der Hash in diesen Fällen eindeutige Ausgabedateinamen sicher. Wenn eine Testdatei den
commandSchlüssel definiert oder wenn eine Testdatei denrpcSchlüssel definiert, aber denkwargsSchlüssel nicht enthält, wird der Hash weggelassen. -
command– Befehl oder RPC, der auf dem verwalteten Gerät ausgeführt wird. Das Modul ersetzt Leerzeichen und Sonderzeichen im Befehls- oder RPC-Namen durch Unterstriche ( _ ).
-
format—Format der Ausgabe, z. B. xml.
Das jsnapy Modul unterscheidet die Snapshot-Dateinamen für eine bestimmte Aktion nur basierend auf Hostname und Befehl oder RPC. Wenn das Modul also Snapshots auf demselben Gerät für dieselbe Aktion mit Testdateien erstellt, die denselben Befehl oder RPC definieren, generiert das Modul Snapshots mit demselben Dateinamen, und die neue Datei überschreibt die alte Datei.
Wenn das Modul z. B. Testdateien enthält action: "snap_pre" und referenziert, die die show interfaces terse show chassis fpc und-Befehle auf Geräten dc1a.example.net und dc1b.example.net ausführen, sind die resultierenden Dateien:
user@ansible-cn:~$ ls jsnapy/snapshots dc1a.example.net_PRE_show_chassis_fpc.xml dc1a.example.net_PRE_show_interfaces_terse.xml dc1b.example.net_PRE_show_chassis_fpc.xml dc1b.example.net_PRE_show_interfaces_terse.xml
Wenn das Modul eine Testdatei enthält action: "snap_post" und referenziert, die den get-interface-information RPC mit kwargs dem Element interface_name: lo0 auf dem Gerät dc1a.example.net ausführt, lautet die resultierende Datei:
dc1a.example.net_POST_r1w59I99HXxC3u0VXXshbw==_get_interface_information.xml
Zusätzlich zum Generieren der Snapshot-Dateien kann das jsnapy Modul auch die folgenden Schlüssel in der Modulantwort zurückgeben:
-
action– JSNAPy-Aktion, die vom Modul ausgeführt wird. -
changed: Gibt an, ob sich der Status des Geräts geändert hat. Da JSNAPy nur über den Status berichtet, ist der Wert immerfalse. -
failedGibt an, ob die Playbook-Aufgabe fehlgeschlagen ist. -
msg—JSNAPy-Testergebnisse.
Überprüfen fehlgeschlagener JSNAPy-Tests
Wenn Sie JSNAPy-Tests für Junos-Geräte ausführen, können Sie schnell überprüfen, ob alle JSNAPy-Tests bestanden haben, indem Sie die Antwort des jsnapy Moduls registrieren und mit dem ansible.builtin.assert Modul überprüfen, ob der Wert passPercentage 100 ist. Wenn jedoch ein oder mehrere Tests fehlschlagen, kann es schwierig sein, die fehlgeschlagenen Tests zu identifizieren und zu extrahieren, wenn die Ausgabe umfangreich ist.
Das juniper.device.jsnapy Modul bietet die folgenden Optionen zum Anzeigen fehlgeschlagener JSNAPy-Tests:
-
jsnapycallback-Plug-in: Gibt eine Zusammenfassung der fehlgeschlagenen JSNAPy-Tests nach der Playbook-Ausgabe aus. -
dest_dirmodule-Argument – Schreibt die fehlgeschlagenen JSNAPy-Tests in Dateien im angegebenen Verzeichnis.
Mit dem jsnapy Callback-Plugin können Sie auf einfache Weise die Informationen zu fehlgeschlagenen JSNAPy-Tests extrahieren und zusammenfassen. Wenn Sie das jsnapy Callback-Plug-In aktivieren und ein Playbook ausführen, das JSNAPy-Tests enthält, fasst das Plug-In die Informationen für die fehlgeschlagenen JSNAPy-Tests nach dem Playbook PLAY RECAPzusammen.
Das jsnapy Callback-Plugin ist standardmäßig deaktiviert. Um das jsnapy Callback-Plug-In zu aktivieren, fügen Sie die callback_whitelist = jsnapy Anweisung der Ansible-Konfigurationsdatei hinzu.
[defaults] callback_whitelist = jsnapy
Wenn Sie das jsnapy Callback-Plug-In aktivieren und ein Playbook ausführen, fasst das Plug-In die fehlgeschlagenen JSNAPy-Tests in einem für Menschen lesbaren Format zusammen. Zum Beispiel:
...
PLAY RECAP ****************************************************************
qfx10002-01 : ok=3 changed=0 unreachable=0 failed=1
qfx10002-02 : ok=3 changed=0 unreachable=0 failed=1
qfx5100-01 : ok=1 changed=0 unreachable=0 failed=1
JSNAPy Results for: qfx10002-01 *******************************************
Value of 'peer-state' not 'is-equal' at '//bgp-information/bgp-peer' with {"peer-as": "64502", "peer-state": "Active", "peer-address": "198.51.100.21"}
Value of 'peer-state' not 'is-equal' at '//bgp-information/bgp-peer' with {"peer-as": "64510", "peer-state": "Idle", "peer-address": "192.168.0.1"}
Value of 'oper-status' not 'is-equal' at '//interface-information/physical-interface[normalize-space(admin-status)='up' and logical-interface/address-family/address-family-name ]' with {"oper-status": "down", "name": "et-0/0/18"}
JSNAPy Results for: qfx10002-02 *******************************************
Value of 'peer-state' not 'is-equal' at '//bgp-information/bgp-peer' with {"peer-as": "64502", "peer-state": "Active", "peer-address": "198.51.100.21"}
juniper.device Ab Version 1.0.6 unterstützt das juniper.device.jsnapy Modul auch das dest_dir Argument. Sie können das Argument für check und snapcheck Vorgänge einschließen, die dest_dir Momentaufnahmen anhand von Testkriterien auswerten. Wenn Sie einen check or-Vorgang snapcheck ausführen und das dest_dir Argument einschließen, schreibt das Modul jeden fehlgeschlagenen JSNAPy-Test für einen bestimmten Host in eine Datei im angegebenen Ausgabeverzeichnis.
Betrachten Sie zum Beispiel das folgende Playbook:
---
- name: Verify BGP
hosts: bgp_routers
connection: local
gather_facts: no
tasks:
- name: Execute snapcheck
juniper.device.jsnapy:
action: "snapcheck"
dir: "~/jsnapy/testfiles"
test_files:
- "jsnapy_test_file_bgp_states.yaml"
- "jsnapy_test_file_bgp_summary.yaml"
logfile: "{{ logfile }}"
dest_dir: "{{ playbook_dir }}/jsnapy_failed_tests"
register: snapcheck_result
Wenn Sie das Playbook ausführen, generiert das Modul eine Datei im dest_dir Verzeichnis für jeden fehlgeschlagenen Test auf dem angegebenen Host. Die folgenden Dateien wurden z. B. für fehlgeschlagene bgp_neighbor Tests und bgp_summary Tests auf den Hosts r1 und r3 generiert.
user@ansible-cn:~/ansible$ ls jsnapy_failed_tests r1_bgp_neighbor_False.text r3_bgp_neighbor_False.text r1_bgp_summary_False.text r3_bgp_summary_False.text
Beispiel: Verwenden von Ansible zum Ausführen eines JSNAPy-Snapcheck-Vorgangs
Mit dem juniper.device.jsnapy Modul können Sie JSNAPy-Tests für Junos-Geräte als Teil eines Ansible-Playbooks durchführen. In diesem Beispiel wird das jsnapy Modul verwendet, um eine snapcheck Aktion auszuführen, mit der der Betriebsstatus von Junos-Geräten überprüft wird, nachdem bestimmte Konfigurationsänderungen angewendet wurden.
- Anforderungen
- Überblick
- Konfiguration
- Ausführen des Playbooks
- Verifizierung
- Fehlerbehebung bei Ansible-Playbook-Fehlern
Anforderungen
In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:
-
Ausgeführter Ansible-Steuerungsknoten:
-
Python 3.10 oder höher
-
Ansible 2.17 oder höher mit
juniper.deviceinstallierter Sammlung -
Junos PyEZ Version 2.7.3 oder höher
-
Junos Snapshot Administrator in Python Version 1.3.7 oder höher
-
Stellen Sie vor dem Ausführen des Ansible-Playbooks sicher, dass Sie über Folgendes verfügen:
-
Junos-Geräte mit aktiviertem NETCONF über SSH und einem Benutzerkonto mit entsprechenden Berechtigungen
-
Öffentliches/privates SSH-Schlüsselpaar, das für den entsprechenden Benutzer auf dem Ansible-Kontrollknoten und dem Junos-Gerät konfiguriert ist
-
Vorhandene Ansible-Bestandsdatei mit definierten erforderlichen Hosts
Überblick
In diesem Beispiel konfiguriert das Ansible-Playbook BGP-Peering-Sitzungen auf drei Junos-Geräten und verwendet das jsnapy Modul, um zu überprüfen, ob die BGP-Sitzung für jede Nachbaradresse eingerichtet wurde. Wenn das Playbook überprüft, ob die Sitzungen auf einem Gerät eingerichtet sind, bestätigt es den Commit für die neue Konfiguration. Wenn das Playbook die Bestätigung nicht bestätigt, setzt das Junos-Gerät automatisch auf die zuvor festgelegte Konfiguration zurück. Das Ansible-Projekt definiert die Gruppen- und Hostvariablen für das Playbook unter den group_vars Verzeichnissen und host_vars bzw.
Das Playbook besteht aus zwei Stücken. Die erste Wiedergabe, Load and commit BGP configurationgeneriert und assembliert die Konfiguration, lädt die Konfiguration auf das Gerät und führt einen Commit Confirmed für sie aus. Wenn die Konfiguration aktualisiert wird, wird ein Handler benachrichtigt. Das Stück führt die folgenden Aufgaben aus:
Remove build directory |
Löscht das vorhandene Build-Verzeichnis für das angegebene Gerät, falls vorhanden. |
Create build directory |
Erstellt ein neues, leeres Buildverzeichnis für das angegebene Gerät. |
Build BGP configuration |
Verwendet das |
Assemble configuration parts |
Verwendet das In diesem Beispiel ist nur die BGP-Konfigurationsdatei vorhanden, sodass die resultierende Konfigurationsdatei mit der BGP-Konfigurationsdatei identisch ist, die in der vorherigen Aufgabe gerendert wurde. Wenn Sie später neue Aufgaben hinzufügen, um zusätzliche Konfigurationsdateien aus anderen Vorlagen zu generieren, kombiniert das |
Load and commit config, require confirmation |
Lädt die Konfiguration auf das Junos-Gerät und schreibt die Konfiguration mithilfe eines Wenn die angeforderte Konfiguration bereits auf dem Gerät vorhanden ist, wird die |
Die zweite Wiedergabe führt auf jedem Gerät einen JSNAPy-Vorgang snapcheck aus, Verify BGPindem die Tests in den JSNAPy-Testdateien verwendet werden. Wenn alle Tests bestanden wurden, bestätigt das Spiel auch den Commit. Das Stück führt die folgenden Aufgaben aus:
Execute snapcheck |
Führt einen JSNAPy-Vorgang In diesem Beispiel verweist das Playbook direkt auf JSNAPy-Testdateien, indem das |
Confirm commit |
Führt einen Commit-Check-Vorgang aus, der den vorherigen Commit-Vorgang bestätigt, vorausgesetzt, dass die Konfiguration beim ersten Playbook-Play aktualisiert wurde und alle JSNAPy-Tests bestanden wurden. Wenn das Playbook die Konfiguration aktualisiert, aber den Commit nicht bestätigt, setzt das Junos-Gerät die Konfiguration automatisch auf die zuvor festgelegte Konfiguration zurück.
Anmerkung:
Sie können den vorherigen Commit-Vorgang entweder mit einem |
Verify BGP configuration |
(Optional) Gibt explizit an, ob die JSNAPy-Tests auf dem angegebenen Gerät bestanden oder fehlgeschlagen sind. Diese Aufgabe ist nicht speziell erforderlich, lässt sich jedoch leichter identifizieren, wann und auf welchen Geräten die JSNAPy-Tests fehlschlagen. |
Konfiguration
- Definieren der Gruppenvariablen
- Definieren der Jinja2-Vorlage und der Hostvariablen
- Erstellen der JSNAPy-Testdateien
- Erstellen des Ansible-Playbooks
- Befund
Definieren der Gruppenvariablen
Schritt-für-Schritt-Anleitung
So definieren Sie die Gruppenvariablen:
-
Definieren Sie in der group_vars/all-Datei Variablen für das Build-Verzeichnis und für die Dateinamen der Konfigurations- und Protokolldateien.
build_dir: "{{ playbook_dir }}/build_conf/{{ inventory_hostname }}" junos_conf: "{{ build_dir }}/junos.conf" logfile: "junos.log"
Definieren der Jinja2-Vorlage und der Hostvariablen
Definieren der Jinja2-Vorlage
So erstellen Sie die Jinja2-Vorlage, die zum Generieren der BGP-Konfiguration verwendet wird:
Erstellen Sie eine Datei mit dem Namen bgp-template.j2 im Playbook-Verzeichnis des Projekts.
Fügen Sie der Datei die BGP-Konfigurationsvorlage hinzu.
interfaces { {% for neighbor in neighbors %} {{ neighbor.interface }} { unit 0 { description "{{ neighbor.name }}"; family inet { address {{ neighbor.local_ip }}/30; } } } {% endfor %} lo0 { unit 0 { family inet { address {{ loopback }}/32; } } } } protocols { bgp { group underlay { import bgp-in; export bgp-out; type external; local-as {{ local_asn }}; multipath multiple-as; {% for neighbor in neighbors %} neighbor {{ neighbor.peer_ip }} { peer-as {{ neighbor.asn }}; } {% endfor %} } } lldp { {% for neighbor in neighbors %} interface "{{ neighbor.interface }}"; {% endfor %} } } routing-options { router-id {{ loopback }}; forwarding-table { export bgp-ecmp; } } policy-options { policy-statement bgp-ecmp { then { load-balance per-packet; } } policy-statement bgp-in { then accept; } policy-statement bgp-out { then { next-hop self; accept; } } }
Definieren der Hostvariablen
So definieren Sie die Hostvariablen, die mit der Jinja2-Vorlage zum Generieren der BGP-Konfiguration verwendet werden:
Erstellen Sie im Verzeichnis host_vars des Projekts für jeden Host eine separate Datei mit dem Namen hostname.yaml .
Definieren Sie die Variablen für Host r1 in der Datei r1.yaml .
--- loopback: 192.168.0.1 local_asn: 64521 neighbors: - interface: ge-0/0/0 name: to-r2 asn: 64522 peer_ip: 198.51.100.2 local_ip: 198.51.100.1 peer_loopback: 192.168.0.2 - interface: ge-0/0/1 name: to-r3 asn: 64523 peer_ip: 198.51.100.6 local_ip: 198.51.100.5 peer_loopback: 192.168.0.3Definieren Sie die Variablen für den Host r2 in der Datei r2.yaml .
--- loopback: 192.168.0.2 local_asn: 64522 neighbors: - interface: ge-0/0/0 name: to-r1 asn: 64521 peer_ip: 198.51.100.1 local_ip: 198.51.100.2 peer_loopback: 192.168.0.1 - interface: ge-0/0/1 name: to-r3 asn: 64523 peer_ip: 198.51.100.10 local_ip: 198.51.100.9 peer_loopback: 192.168.0.3Definieren Sie die Variablen für Host r3 in der Datei r3.yaml .
--- loopback: 192.168.0.3 local_asn: 64523 neighbors: - interface: ge-0/0/0 name: to-r1 asn: 64521 peer_ip: 198.51.100.5 local_ip: 198.51.100.6 peer_loopback: 192.168.0.1 - interface: ge-0/0/1 name: to-r2 asn: 64522 peer_ip: 198.51.100.9 local_ip: 198.51.100.10 peer_loopback: 192.168.0.2
Erstellen der JSNAPy-Testdateien
Schritt-für-Schritt-Anleitung
Das jsnapy Modul verweist auf JSNAPy-Testdateien im Verzeichnis ~/jsnapy/testfiles . So erstellen Sie die JSNAPy-Testdateien:
Erstellen Sie die Datei jsnapy_test_file_bgp_states.yaml , die den
show bgp neighborBefehl ausführt und testet, ob der BGP-Peer Status hergestellt wird.bgp_neighbor: - command: show bgp neighbor - ignore-null: true - iterate: xpath: '//bgp-peer' id: './peer-address' tests: # Check if peers are in the established state - is-equal: peer-state, Established err: "Test Failed!! peer <{{post['peer-address']}}> state is not Established, it is <{{post['peer-states']}}>" info: "Test succeeded!! peer <{{post['peer-address']}}> state is <{{post['peer-state']}}>"Erstellen Sie die Datei jsnapy_test_file_bgp_summary.yaml , die den
show bgp summaryBefehl ausführt und bestätigt, dass die Anzahl der BGP-Downpeers 0 sein muss.bgp_summary: - command: show bgp summary - item: xpath: '/bgp-information' tests: - is-equal: down-peer-count, 0 err: "Test Failed!! down-peer-count is not equal to 0. It is equal to <{{post['down-peer-count']}}>" info: "Test succeeded!! down-peer-count is equal to <{{post['down-peer-count']}}>"
Erstellen des Ansible-Playbooks
- Definieren Sie die erste Wiedergabe, um das Gerät zu konfigurieren
- Definieren der zweiten Wiedergabe zum Ausführen von JSNAPy-Vorgängen
Definieren Sie die erste Wiedergabe, um das Gerät zu konfigurieren
So erstellen Sie die erste Wiedergabe, die die Konfiguration rendert, auf das Gerät lädt und die Konfiguration als Commit-bestätigten Vorgang festschreibt:
Fügen Sie die Textbausteine für das Playbook und die erste Wiedergabe hinzu, die die Module lokal ausführt.
--- - name: Load and commit BGP configuration hosts: bgp_routers connection: local gather_facts: no
Erstellen Sie die Aufgaben, die das vorhandene Buildverzeichnis durch ein leeres Verzeichnis ersetzen, in dem die neuen Konfigurationsdateien gespeichert werden.
tasks: - name: Remove build directory file: path: "{{ build_dir }}" state: absent - name: Create build directory file: path: "{{ build_dir }}" state: directoryErstellen Sie den Task, der die BGP-Konfiguration aus der Jinja2-Vorlagendatei und den Hostvariablen rendert und in der Datei bgp.conf im Build-Verzeichnis für diesen Host speichert.
- name: Build BGP configuration template: src: "{{ playbook_dir }}/bgp-template.j2" dest: "{{ build_dir }}/bgp.conf"Erstellen Sie einen Task, um die Konfigurationsdateien im Build-Verzeichnis in die endgültige Konfigurationsdatei junos.conf zusammenzustellen.
- name: Assemble configuration parts assemble: src: "{{ build_dir }}" dest: "{{ junos_conf }}"Erstellen Sie die Aufgabe, die die Konfiguration auf dem Gerät lädt, einen Commitvorgang ausführt, der eine Bestätigung erfordert, und den angegebenen Handler benachrichtigt, sofern die Konfiguration geändert wurde.
- name: Load and commit config, require confirmation juniper.device.config: load: "merge" format: "text" src: "{{ junos_conf }}" confirm: 5 comment: "config by Ansible" logfile: "{{ logfile }}" register: config_result # Notify handler, only if configuration changes. notify: - Waiting for BGP peers to establish connectionsErstellen Sie einen Handler, der die Ausführung des Playbooks anhält, wenn die Gerätekonfiguration aktualisiert wird. Legen Sie die Pausenzeit auf einen für Ihre Umgebung geeigneten Wert fest.
handlers: - name: Waiting for BGP peers to establish connections pause: seconds=60
Definieren der zweiten Wiedergabe zum Ausführen von JSNAPy-Vorgängen
So erstellen Sie die zweite Wiedergabe, die einen JSNAPy-Snapcheck-Vorgang ausführt und die festgeschriebene Konfiguration bestätigt, vorausgesetzt, die Konfiguration hat sich geändert und die JSNAPy-Tests bestanden:
Fügen Sie den Textbaustein für das zweite Spiel hinzu, das die Module lokal ausführt.
- name: Verify BGP hosts: bgp_routers connection: local gather_facts: no
Erstellen Sie eine Aufgabe zum Ausführen eines JSNAPy-Snapcheck-Vorgangs basierend auf den Tests in den angegebenen JSNAPy-Testdateien, und registrieren Sie die Antwort des Moduls.
tasks: - name: Execute snapcheck juniper.device.jsnapy: action: "snapcheck" dir: "~/jsnapy/testfiles" test_files: - "jsnapy_test_file_bgp_states.yaml" - "jsnapy_test_file_bgp_summary.yaml" logfile: "{{ logfile }}" register: snapcheck_resultErstellen Sie die Aufgabe, um den Commit zu bestätigen, vorausgesetzt, dass die angegebenen Bedingungen erfüllt sind.
# Confirm commit only if configuration changed and JSNAPy tests pass - name: Confirm commit juniper.device.config: check: true commit: false diff: false logfile: "{{ logfile }}" when: - config_result.changed - "snapcheck_result.passPercentage == 100"(Optional) Erstellen Sie eine Aufgabe, die das
ansible.builtin.assertModul verwendet, um zu bestätigen, dass die JSNAPy-Tests bestanden wurden.- name: Verify BGP configuration ansible.builtin.assert: that: - "snapcheck_result.passPercentage == 100" msg: "JSNAPy test on {{ inventory_hostname }} failed"
Befund
Überprüfen Sie auf dem Ansible-Steuerungsknoten das fertige Playbook. Wenn das Playbook nicht den gewünschten Code anzeigt, wiederholen Sie die Anweisungen in diesem Abschnitt, um das Playbook zu korrigieren.
---
- name: Load and commit BGP configuration
hosts: bgp_routers
connection: local
gather_facts: no
tasks:
- name: Remove build directory
file:
path: "{{ build_dir }}"
state: absent
- name: Create build directory
file:
path: "{{ build_dir }}"
state: directory
- name: Build BGP configuration
template:
src: "{{ playbook_dir }}/bgp-template.j2"
dest: "{{ build_dir }}/bgp.conf"
- name: Assemble configuration parts
assemble:
src: "{{ build_dir }}"
dest: "{{ junos_conf }}"
- name: Load and commit config, require confirmation
juniper.device.config:
load: "merge"
format: "text"
src: "{{ junos_conf }}"
confirm: 5
comment: "config by Ansible"
logfile: "{{ logfile }}"
register: config_result
# Notify handler, only if configuration changes.
notify:
- Waiting for BGP peers to establish connections
handlers:
- name: Waiting for BGP peers to establish connections
pause: seconds=60
- name: Verify BGP
hosts: bgp_routers
connection: local
gather_facts: no
tasks:
- name: Execute snapcheck
juniper.device.jsnapy:
action: "snapcheck"
dir: "~/jsnapy/testfiles"
test_files:
- "jsnapy_test_file_bgp_states.yaml"
- "jsnapy_test_file_bgp_summary.yaml"
logfile: "{{ logfile }}"
register: snapcheck_result
# Confirm commit only if configuration changed and JSNAPy tests pass
- name: Confirm commit
juniper.device.config:
check: true
commit: false
diff: false
logfile: "{{ logfile }}"
when:
- config_result.changed
- "snapcheck_result.passPercentage == 100"
- name: Verify BGP configuration
ansible.builtin.assert:
that:
- "snapcheck_result.passPercentage == 100"
msg: "JSNAPy test on {{ inventory_hostname }} failed"
Ausführen des Playbooks
So führen Sie das Playbook aus:
-
Geben Sie den
ansible-playbookBefehl auf dem Steuerungsknoten ein, und geben Sie den Playbookpfad und alle gewünschten Optionen an.user@ansible-cn:~/ansible$ ansible-playbook ansible-pb-bgp-configuration.yaml PLAY [Load and commit BGP configuration] ************************************* TASK [Remove build directory] ************************************************ changed: [r1] changed: [r2] changed: [r3] TASK [Create build directory] ************************************************ changed: [r1] changed: [r2] changed: [r3] TASK [Build BGP configuration] *********************************************** changed: [r2] changed: [r1] changed: [r3] TASK [Assemble configuration parts] ****************************************** changed: [r3] changed: [r2] changed: [r1] TASK [Load and commit config, require confirmation] ************************** changed: [r2] changed: [r1] changed: [r3] RUNNING HANDLER [Waiting for BGP peers to establish connections] ************* Pausing for 60 seconds (ctrl+C then 'C' = continue early, ctrl+C then 'A' = abort) ok: [r3]
PLAY [Verify BGP] ************************************************************ TASK [Execute snapcheck] ***************************************************** ok: [r2] ok: [r1] ok: [r3] TASK [Confirm commit] ******************************************************** ok: [r2] ok: [r1] ok: [r3] TASK [Verify BGP configuration] ********************************************** ok: [r1] => { "changed": false, "msg": "All assertions passed" } ok: [r2] => { "changed": false, "msg": "All assertions passed" } ok: [r3] => { "changed": false, "msg": "All assertions passed" } PLAY RECAP ******************************************************************* r1 : ok=8 changed=5 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 r2 : ok=8 changed=5 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 r3 : ok=9 changed=5 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
Verifizierung
Überprüfen der BGP-Nachbarn
Zweck
Stellen Sie sicher, dass die BGP-Sitzung für jede Nachbaradresse eingerichtet ist.
Die JSNAPy-Testdateien testen, ob die BGP-Sitzung für jede Nachbaradresse eingerichtet ist und dass es keine Down-Peers gibt. Mit der Verify BGP configuration Aufgabenausgabe können Sie schnell überprüfen, ob das jeweilige Gerät alle JSNAPy-Tests bestanden hat. Wenn JSNAPy passPercentage gleich 100 Prozent ist, wird die Aufgabe in die Aufgabenausgabe aufgenommen "msg": "All assertions passed" .
Aktion
Überprüfen Sie die Verify BGP configuration Aufgabenausgabe, und stellen Sie sicher, dass jedes Gerät die All assertions passed Meldung zurückgibt.
TASK [Verify BGP configuration] **********************************************
ok: [r1] => {
"changed": false,
"msg": "All assertions passed"
}
ok: [r2] => {
"changed": false,
"msg": "All assertions passed"
}
ok: [r3] => {
"changed": false,
"msg": "All assertions passed"
}
Bedeutung
Die All assertions passed Meldung zeigt an, dass die BGP-Sitzungen auf den Geräten erfolgreich eingerichtet wurden.
Fehlerbehebung bei Ansible-Playbook-Fehlern
- Beheben von Konfigurationsfehlern
- Fehlerbehebung bei fehlgeschlagenen JSNAPy-Tests
- Fehlerbehebung bei fehlgeschlagenen Commit-Bestätigungen
Beheben von Konfigurationsfehlern
Problem
Das Ansible-Playbook generiert einen ConfigLoadError Fehler, der angibt, dass die Konfiguration aufgrund eines Syntaxfehlers nicht auf das Gerät geladen werden konnte.
fatal: [r1]: FAILED! => {"changed": false, "msg": "Failure loading the configuraton: ConfigLoadError(severity: error, bad_element: protocol, message: error: syntax error\nerror: error recovery ignores input until this point)"}
Lösung
Das Playbook rendert die Junos OS Konfiguration mithilfe der Jinja2-Vorlage und der Hostvariablen, die für dieses Gerät im Verzeichnis host_vars definiert sind. Das Playbook generiert einen Syntaxfehler, wenn die Jinja2-Vorlage eine ungültige Konfiguration erzeugt. Um diesen Fehler zu beheben, aktualisieren Sie die Jinja2-Vorlage, um das Element zu korrigieren, das durch den bad_element Schlüssel in der Fehlermeldung identifiziert wird.
Fehlerbehebung bei fehlgeschlagenen JSNAPy-Tests
Problem
Die Verify BGP configuration Taskausgabe gibt an, dass die Assertion fehlgeschlagen ist, da JSNAPy passPercentage nicht gleich 100 Prozent war.
TASK [Verify BGP configuration] *************************************************************
fatal: [r1]: FAILED! => {
"assertion": "snapcheck_result.passPercentage == 100",
"changed": false,
"evaluated_to": false,
"msg": "JSNAPy test on r1 failed"
}
Die Assertion schlägt fehl, wenn das Gerät die BGP-Sitzung mit seinem Nachbarn nicht eingerichtet hat oder die Sitzung ausfällt. Wenn die Assertion fehlschlägt und die Konfiguration für dieses Gerät bei der ersten Wiedergabe aktualisiert wurde, bestätigt das Playbook den Commit für die neue Konfiguration auf dem Gerät nicht, und das Gerät setzt die Konfiguration auf die zuvor festgeschriebene Konfiguration zurück.
Lösung
Die JSNAPy-Tests schlagen möglicherweise fehl, wenn der Vorgang snapcheck ausgeführt wird, bevor die Peers die Sitzung einrichten können, oder weil die BGP-Nachbarn nicht ordnungsgemäß konfiguriert sind. Wenn die Playbookausgabe angibt, dass die Konfiguration erfolgreich geladen und auf dem Gerät festgeschrieben wurde, versuchen Sie, das Pausenintervall des Handlers auf einen für Ihre Umgebung geeigneten Wert zu erhöhen, und führen Sie das Playbook erneut aus.
handlers:
- name: Waiting for BGP peers to establish connections
pause: seconds=75
Wenn die Tests immer noch fehlschlagen, stellen Sie sicher, dass die Jinja2-Vorlage und die Hostvariablen für jedes Gerät die richtigen Daten enthalten und dass die resultierende Konfiguration für jedes Gerät korrekt ist.
Fehlerbehebung bei fehlgeschlagenen Commit-Bestätigungen
Problem
Die Konfiguration wurde auf einem oder mehreren Geräten nicht bestätigt.
TASK [Confirm commit] *********************************************************************** skipping: [r2] skipping: [r2] skipping: [r3]
Lösung
Das Playbook bestätigt die Konfiguration nur, wenn sie geändert wurde und die JSNAPy-Tests erfolgreich waren. Wenn die Load and commit config, require confirmation Aufgabenausgabe angibt, dass sich die Konfiguration nicht geändert hat, führt das Playbook die Aufgabe nicht aus, um den Commit zu bestätigen. Wenn sich die Konfiguration geändert, aber nicht bestätigt wurde, sind die JSNAPy-Tests fehlgeschlagen. Die JSNAPy-Tests schlagen möglicherweise fehl, wenn die BGP-Nachbarn nicht ordnungsgemäß konfiguriert sind oder wenn das Playbook nicht genügend Zeit zwischen den Wiedergaben für die Geräte bereitstellt, um die BGP-Sitzung einzurichten. Weitere Informationen finden Sie unter Fehlerbehebung bei fehlgeschlagenen JSNAPy-Tests.