Fehlerbehebung bei externen Fehlern des NSO NED

Einleitung

In diesem Dokument wird beschrieben, wie CLI- und generische NED-Ablaufverfolgungen analysiert und die Ursache externer Fehler im Cisco Crosswork NSO identifiziert werden.

Voraussetzungen

Anforderungen

• Der Aspekt der Fehlerbehebung in diesem Dokument bezieht sich auf alle derzeit unterstützten NED-Versionen (Network Element Driver) und NSO-Versionen (Cisco® Crosswork Network Service Orchestrator).
• Um Fehler bei externen NEDs zu beheben, müssen Sie NED-Ablaufverfolgungsprotokolle aktivieren und Zugriff auf diese Protokolle haben.
• Um externe NED-Fehler genau zu bewerten, sollten Sie mit dem vom NSO verwalteten Netzwerkgerät und dessen API vertraut sein.

Verwendete Komponenten

- Überbrückung NSO 6.4.3

- NED cisco-iosxr-7.64.1

Arten von externen Fehlern

Externe NED-Fehler sind ein Anzeichen für einen Kommunikationsausfall zwischen der NED und dem Gerät. Sie werden in drei grobe Kategorien unterteilt:

• Der NED erhält eine Antwort von dem Netzwerkgerät, das er nicht erwartet hat.
• Der NED erhält eine Antwort vom Netzwerkgerät, die das Yang-Modell im NED verletzt.
• Die NED erhält innerhalb der zugewiesenen Zeit keine Antwort.

Die Kategorie der unerwarteten Antworten ist bei weitem die häufigste Kategorie sind externe Fehler, die bei Ihrer NED auftreten können. Dazu gehört, dass das Gerät eine Fehlermeldung, eine Informationsmeldung oder andere Informationen zurückgibt, die nicht mit den Angaben übereinstimmen, die der NSO erwartet hat. NEDs sind für die Verarbeitung von Informationsmeldungen oder -warnungen konzipiert, die sicher ignoriert werden können. Viele NEDs verfügen über Endeinstellungen, mit denen Sie festlegen können, welche Meldungen ignoriert oder welche als externer Fehler behandelt werden sollen.

Sie können einen externen Fehler sehen, der von der NED ausgelöst wird, wenn die NED Informationen empfängt, die während eines sync-from oder compare-config Vorgangs nicht mit dem Yang-Modell übereinstimmen. Ein typisches Beispiel ist ein Yang-Modell, das einen Wert von 0 bis 8 für ein bestimmtes Leaf akzeptiert, doch in der neuesten Version dieses Betriebssystems wurde der Bereich auf 0 bis 16 erhöht. Die NED akzeptiert keinen Wert von 16, da sie sich außerhalb des modellierten Bereichs befindet. Alternativ kann der Fehler ausgelöst werden, wenn ein Leaf im Yang-Modell als obligatorisch markiert ist, aber nicht vom Gerät bereitgestellt wird, oder wenn das Gerät eine Zeichenfolge bereitstellt, wenn der NSO eine ganze Zahl erwartet.

Bei CLI- und generischen NEDs wird kein externer Fehler ausgelöst, wenn die NED eine Konfiguration erhält, die nicht im NED-Yang-Modell modelliert ist. Stattdessen wird dies als skipped line in der Ablaufverfolgungsdatei protokolliert.

Wenn eine NED schließlich nicht innerhalb der vorgegebenen Zeit die erwartete Antwort vom Gerät erhält, wird ein externer Fehler ausgelöst. Dies kann daran liegen, dass das Gerät nicht reagiert und keine Antwort gesendet hat. Es kann aber auch vorkommen, dass die NED die Antwort vom Gerät nicht erkannt hat.

NED-Ablaufverfolgungsprotokolle werden gelesen

Ablaufverfolgungsprotokolle sind die am besten verfügbaren Protokolle zur Fehlerbehebung bei externen Fehlern. 

Aktivieren von NED-Ablaufverfolgungsprotokollen

NED-Ablaufverfolgungsprotokolle werden über die CLI des NSO aktiviert.

ncs_cli -C -u admin
admin@ncs# configure
admin@ncs(config)# devices device dev-1 ned-settings [ned-id] logging level debug
admin@ncs(config)# devices device dev-1 trace raw
admin@ncs(config)# commit
admin@ncs(config)# devices device dev-1 disconnect
admin@ncs(config)# devices clear-trace
admin@ncs(config)# devices device dev-1 compare-config

Verwenden Sie für [ned-id] die die End-ID des Geräts, das Sie mit dem Befehl anvisieren.

Vorsicht: Der Befehl clear-trace löscht die Daten für alle NED-Ablaufverfolgungsprotokolle, die sich derzeit im Protokollverzeichnis befinden. Wenn Sie Ablaufverfolgungsprotokolle für dieses Gerät oder andere Geräte aufbewahren möchten, müssen Sie diese vor der Ausführung dieses Befehls archivieren. Bei den aktuellen NSO-Versionen kann ClearTrace für ein einzelnes Gerät ausgeführt werden.

Anmerkung: Falls Sie "end-settings [end-id] logging level debug" nicht finden, können Sie diesen Befehl überspringen.

Mit diesen Befehlen werden alle alten Daten aus der Ablaufverfolgungsdatei gelöscht und mit der aktuellen Konfiguration auf dem Gerät vorbereitet. An diesem Punkt reproduzieren Sie das gefundene Problem mithilfe ncs_cli des NSO-Services. Wenn der Fehler während eines Commit-Vorgangs auftritt, müssen Sie CLI-Ausgaben für commit dry-run und commit dry-run outformat native für zukünftige Referenzzwecke erfassen.

In der NED README-Datei finden Sie ein Kapitel mit der Bezeichnung "How to report NED issues and feature quiries" für detailliertere Anweisungen.

CLI und generische NEDs

NED-Ablaufverfolgungen für CLI und generische NEDs werden in unterschiedliche Phasen unterteilt, die für die Fehlerbehebung nützlich sind. Die wichtigsten Phasen für die Fehlerbehebung bei externen Fehlern sind die Phase ANZEIGEN und VORBEREITUNG.

Die SHOW-Phase wird aufgerufen, wenn der NSO Informationen vom Netzwerkgerät liest. Es ist Teil von sync-from und compare-config Betrieb. Während dieses Schritts fordert der NSO das Gerät mit einem Befehl auf, z. B. show running-config bevor er die Antwort vom Gerät liest und analysiert. Ausgehende Nachrichten, die vom NSO an das Gerät gesendet werden, werden mit angeführt, *** output während eingehende Nachrichten, die vom Gerät an den NSO gesendet werden, mit beginnen. *** input.

Anmerkung: Zu den externen Fehlern während einer SHOW-Operation gehören Werte, die unter dem aktuellen Yang-Modell nicht akzeptiert werden, sowie Timeout-Probleme.

Die PREPARE-Phase wird im Rahmen von commit Vorgängen aufgerufen. Während dieser Phase sendet der NSO Anweisungen an das Gerät. Zu Beginn der PREPARE-Phase gibt der NED eine Liste der Änderungen aus, die der NSO an der Trace-Datei vornehmen möchte. Nach dieser ersten Zusammenfassung sendet der NSO die Anweisungen an das Gerät. Bei bestimmten Geräten sendet der NSO die Befehle in Massen, während bei anderen Geräten diese Befehle einzeln gesendet werden. Dieses Verhalten kann über die entsprechenden Endeinstellungen für NEDs, die es unterstützen, geändert werden. Die NED cisco-iosxr-cli hat beispielsweise die NED-Einstellung. "write number-of-lines-to-send-in-chunk <1-1000> (default 100)"

CLI-NEDs sehen in der Regel die vom NSO gesendeten Befehle als Ausgabe, die als Eingabe zurückgegeben wird. Der Grund hierfür ist, dass der Befehl in der textbasierten Benutzeroberfläche des Geräts angezeigt wird und der NSO den gesamten Text, der in dieser Benutzeroberfläche angezeigt wird, als Eingabe betrachtet. Ein Beispiel, bei dem der NSO Befehle einzeln sendet, sieht wie folgt aus:

  *** output 1-Jan-2024::09:56:00.928 user: admin/425 thandle 7428 hostname NSO1 device test-device ***
interface GigabitEthernet 0/0/0/2.34280485 l2transport
  *** input 1-Jan-2024::09:56:00.929 user: admin/425 thandle 7428 hostname NSO1 device test-device ***
 interface GigabitEthernet 0/0/0/2.34280485 l2transport

Anmerkung: Zu den externen Fehlern während des PREPARE-Vorgangs gehören alle vom Gerät zurückgegebenen Meldungen, die nicht den Erwartungen des NSO entsprechen, wie Fehler, Warnungen oder Informationsmeldungen.

Fehlerbehebung bei externen Fehlern

Bei der Fehlerbehebung von externen Fehlern für CLI und generische NEDs: Aktivieren Sie die Ablaufverfolgung, reproduzieren Sie das Problem, und überprüfen Sie die letzte SHOW- oder PREPARE-Phase, je nachdem, welche Vorgänge den Fehler ausgelöst haben.

Wenn sich der NSO über einen bestimmten Wert beschwert, der vom Gerät bereitgestellt wird:

• Über welchen Teil der Konfiguration hat sich der NSO beschwert?
• Ist die vom Gerät gemeinsam genutzte Konfiguration für dieses Modell und diese Version des Geräts richtig?
• Kennen Sie andere Gerätemodelle oder -versionen, die diese NED verwenden und deren Eingabeanforderungen restriktiver sind?

Wenn der NSO einen externen Fehler mit Zeitüberschreitung auslöst:

• Welcher Befehl wurde vom NSO zuletzt vor dem Timeout gesendet?
• Worauf wartet der NSO, bevor er fortfahren kann?

Es ist mitunter schwierig zu bestimmen, worauf der NSO wartet. Einige NEDs mit erhöhter Ausführlichkeit drucken den Regex-Ausdruck, den sie suchen. In einigen Fällen wird die vom NSO gesuchte Nachricht in der Trace-Datei angezeigt, aber der NSO hat sie nicht erkannt und wartet weiter.

Wenn der NSO aufgrund einer unerwarteten Antwort einen externen Fehler auslöst:

• Welche spezifische Antwort hat das Gerät erhalten?
• Welcher vom NSO gesendete Befehl hat die Antwort ausgelöst?
• Basiert die erwartete Antwort auf den vom NSO gesendeten Daten?
• Könnte die Antwort vom Gerät sicher ignoriert werden, oder muss der Commit abgebrochen werden?
• Hat der NSO die richtigen Befehle in der richtigen Reihenfolge gesendet?

Häufige spezifische Probleme:

Übersetzungsproblem

Ein Übersetzungsproblem tritt auf, wenn der NSO die richtige Absicht hat, aber die Befehle, die er an das Gerät sendet, nicht ganz richtig sind. Dies kann passieren, wenn eine andere Geräteversion oder ein anderes Modell mit derselben NED eine etwas andere Syntax hat. Wenn Sie eine ältere Version der NED verwenden, prüfen Sie, ob diese in der neuesten Version der NED noch vorhanden ist. Prüfen Sie außerdem, ob in der Datei README-end-settings.md, die im NED enthalten ist, Endeinstellungen vorhanden sind, um festzustellen, ob Sie dieses Verhalten mit diesen Einstellungen anpassen können. Wenn das Problem mit der neuesten NED weiterhin besteht und die Endeinstellungen keine Möglichkeit zur Problembehebung bieten, erstellen Sie ein Ticket beim TAC. Stellen Sie Folgendes bereit:

• NSO-Version
• Mithilfe der neuesten NED wird eine NED-Ablaufverfolgung ausgeführt, die einen compare-config Vorgang erfasst, gefolgt von einem commit Vorgang, der den falschen Befehl sendet.
• Der Befehl, den die NED derzeit sendet
• Der richtige Befehl, der vorzugsweise als Beispiel auf der CLI des realen Geräts angezeigt wird.
• Die Version und das Modell des Geräts, bei dem das Problem aufgetreten ist
• Alle anderen Versionen und Modelle von Geräten in Ihrem Netzwerk, die diese NED verwenden, sofern das aktuelle NED-Verhalten korrekt ist.

Problem mit der Bestellung

Ein Bestellproblem tritt auf, wenn die NED die richtigen Befehle in der falschen Reihenfolge sendet. Bei einigen Geräten und bestimmten Konfigurations-Payloads ist die Reihenfolge wichtig. Wenn Sie eine ältere Version der NED verwenden, prüfen Sie, ob diese in der neuesten Version der NED noch vorhanden ist. Prüfen Sie außerdem, ob in der Datei README-end-settings.md, die im NED enthalten ist, Endeinstellungen vorhanden sind, um festzustellen, ob Sie dieses Verhalten mit diesen Einstellungen anpassen können. Wenn das Problem mit der neuesten NED weiterhin besteht und die Endeinstellungen keine Möglichkeit zur Problembehebung bieten, erstellen Sie ein Ticket beim TAC. Stellen Sie Folgendes bereit:

• NSO-Version
• Mit der neuesten NED und ohne Service: Eine NED-Ablaufverfolgung, die einen compare-config Vorgang erfasst, gefolgt von einem commit Vorgang, der die falsche Reihenfolge sendet.
• Die Ausgabe von commit dry-run outformat native  für den fehlerhaften Commit. Hier sehen Sie die Reihenfolge, in der die NED die Befehle sendet.
• Die richtige Reihenfolge wird vorzugsweise am Beispiel der realen Geräte-CLI angezeigt.
• Sonstige Voraussetzungen, die für diese Bestellanforderung relevant sind

Anmerkung: In seltenen Fällen ist Cisco nicht in der Lage, eine Bestellanforderung über die NED zu erfüllen. In diesem Fall können Sie einen Multi-Commit-Workflow implementieren oder einen Fehlerbericht beim entsprechenden Anbieter einreichen.

Ungültiges Werteproblem

Ein ungültiger Wert tritt auf, wenn der NSO das Festlegen eines anderen Wertebereichs zulässt, als vom Gerät akzeptiert wird, oder wenn der NSO den vollständigen Bereich, den das Gerät zulässt, nicht zulässt. Mit dem NSO können Sie z. B. einen Wert zwischen 0 und 15 definieren, das Gerät akzeptiert jedoch nur Werte zwischen 0 und 8. Dies kann der Fall sein, wenn die NED mit Blick auf ein bestimmtes Gerätemodell und eine bestimmte Version modelliert wird, andere Geräte jedoch unterschiedliche Erwartungen haben. Wenn Sie eine ältere Version der NED verwenden, prüfen Sie, ob diese in der neuesten Version der NED noch vorhanden ist. Prüfen Sie außerdem, ob in der Datei README-end-settings.md, die im NED enthalten ist, Endeinstellungen vorhanden sind, um festzustellen, ob Sie dieses Verhalten mit diesen Einstellungen anpassen können. Wenn das Problem mit der neuesten NED weiterhin besteht und die Endeinstellungen keine Möglichkeit zur Problembehebung bieten, erstellen Sie ein Ticket beim TAC. Stellen Sie Folgendes bereit:

• NSO-Version
• Für den NSO, der Daten zulässt, die vom Gerät nicht akzeptiert werden, verwenden Sie die neueste NED: Eine NED-Ablaufverfolgung, die einen compare-config Vorgang erfasst, gefolgt von einem commit Senden eines Werts, der vom Gerät zurückgewiesen wird.
• Wenn der NSO die Daten strenger interpretieren kann, als das Gerät es zulässt, mithilfe der neuesten NED: Eine NED-Ablaufverfolgung, die einen sync-from Vorgang erfasst, nachdem Daten auf dem Gerät konfiguriert wurden, was derzeit vom NSO nicht akzeptiert wird.
• Der richtige Wertebereich
• Die Version und das Modell des Geräts, bei dem das Problem aufgetreten ist
• Alle anderen Versionen und Modelle von Geräten in Ihrem Netzwerk, die diese NED verwenden, sofern das aktuelle NED-Verhalten korrekt ist.

Fehler, Warnungen und Informationsmeldungen vom Gerät:

Wenn ein Gerät auf NSO-Befehle mit einer Fehlermeldung oder einer anderen Meldung reagiert, kann dies einen externen Fehler im NSO auslösen. NEDs des NSO verfügen über eine interne Liste von Regex-Ausdrücken, die sie sicher ignorieren können, sowie von Ausdrücken, die einen Fehler auslösen. Mehrere NEDs verfügen über Endeinstellungen, mit denen Sie diese Listen anpassen können, ohne dass eine NED-Erweiterung erforderlich ist. Beispiele: Die Fehlermeldung cisco-iosxr-cli NED ned-setting write config-warning.

Wenn die neueste NED keine solche Option bietet, erstellen Sie ein Ticket beim TAC. Stellen Sie Folgendes bereit:

• NSO-Version
• Eine NED-Ablaufverfolgung, die einen compare-config Vorgang und anschließend den Vorgang erfasst und den Fehler verursacht.
• Eine Anforderung zum Ändern der internen Listen und/oder eine Anforderung zum Hinzufügen von Unterstützung für eine Endeinstelloption, um die Liste selbst anzupassen.
• Die spezifische Nachricht, die das Gerät sendet, verursacht das Problem

Lösungen

Benutzerfehler

Wenn Sie festgestellt haben, dass die vom NSO gesendeten Befehle falsch waren, stellen Sie sicher, dass Ihre Eingabe an den NSO und die von Ihnen erstellten Servicepakete die richtigen Änderungen erzeugt haben. Überprüfen Sie, ob die Ausgabe von commit dry-run mit den gewünschten Änderungen übereinstimmt und ob die Ausgabe von die richtigen Befehle und die Reihenfolge commit dry-run outformat native anzeigt, in der diese Änderungen hervorgerufen werden. Wenn der Testlauf unerwartete Änderungen vorhersagt, müssen Sie Ihre Eingaben in den NSO oder Ihren Servicecode überprüfen. Wenn der Probelauf korrekt ist, die an den NSO gesendeten Befehle jedoch falsch sind, überprüfen Sie die Problemlösungen bei der Übersetzung und Bestellung.

Netzwerkgerät

In einigen Fällen ist ein externer Fehler das Ergebnis einer Konfiguration, von Einstellungen oder sogar eines Fehlers auf dem Netzwerkgerät selbst, z. B. wenn ein Benutzer nicht über die richtige Autorisierung verfügt oder ein Gerät bestimmte Vorgänge einschränkt. Werten Sie aus, ob die Konfiguration oder die Geräteeinstellungen geändert werden können, damit der NSO besser mit dem Gerät zusammenarbeiten kann.

Ned-Einstellungen

Jedes NED verfügt über eine Reihe von Endeinstellungen, mit denen Sie die Interaktion des NSO mit dem Gerät anpassen können. Ned-Settings werden in der Datei README-end-settings.md innerhalb der NED dokumentiert und unterscheiden sich tendenziell von NED zu NED. Die NED cisco-iosxr-cli verfügt über Optionen, um die Art und Weise zu ändern, wie der NSO eine Prüfsumme für das Gerät berechnet, wie viele Befehle als Massensendungen gesendet werden, zusätzliche Befehle anzupassen, um sie basierend auf bestimmten Triggern einzufügen, oder ob die NED Konfigurationsdaten erfassen muss, indem sie die Konfiguration in eine Datei auf dem Gerät schreibt "show running-config"  oder sie mithilfe von SFTP überträgt, was für große Konfigurationen nützlich sein kann.

NED-Service-Konflikt

Ein NED-Service-Konflikt tritt auf, wenn ein problematisches Verhalten vorliegt, wenn die Konfiguration mithilfe eines Service-Pakets geändert oder gelöscht wird, aber nicht, wenn dieselben Konfigurationsänderungen ohne die Verwendung eines Service-Pakets vorgenommen werden. Diese Art von Verhalten kann als unerwartete Konfiguration angezeigt werden, die hinzugefügt oder entfernt wird, was zu externen Fehlern auf dem Gerät führt. Dies ist in der Regel das Ergebnis der Service-Bereitstellung für bestimmte Teile der Konfiguration. Änderungen an der CDB-Konfiguration des NSO, die aus einem Service-Paket resultieren, können die NED-Logik außer Kraft setzen, die normalerweise falsche Änderungen verhindert. Wenn Sie vermuten, dass Sie auf dieses Verhalten gestoßen sind, überprüfen Sie es, indem Sie versuchen, die gleichen Konfigurationsänderungen ohne die Verwendung eines Service-Pakets durchzuführen.

Im Artikel "Understanding NSO Service Ownership" (Kenntnisse über den Besitz von NSO-Services) erfahren Sie mehr über den Besitz von Services und mögliche Lösungen.

NED-Erweiterungen und TAC-Support

Wenn keine anderen Optionen verfügbar sind, können Sie ein Ticket beim Cisco TAC eröffnen und eine Aktualisierung des NED entsprechend Ihrer Anforderungen beantragen.

Die von Cisco bereitgestellten NEDs des NSO basieren auf aktualisierten Standards für Ihre Anwendungsfälle. Cisco versucht nicht proaktiv, alle möglichen Gerätemodelle und -versionen abzudecken, aber das NED wird ständig aktualisiert, um den Anforderungen eines sich weiterentwickelnden Netzwerks und neuen Anwendungsfällen gerecht zu werden. Eine Zusammenfassung des Umfangs des NED-Supports, der von den Crosswork NSO-Entwicklern bereitgestellt wird, finden Sie hier.

Anmerkung: Cisco tut sein Bestes, um eine umfassende interne Testumgebung zu gewährleisten, wir sind jedoch nicht in der Lage, eine Umgebung zu schaffen, die jedes Modell und jede Version für eine breite Palette von Anbietern abdeckt. Daher können wir Ihre Hilfe benötigen, um Zugriff auf ein Gerät zu gewähren, das das fragliche Verhalten zeigt.

Wenn Sie ein Ticket beim Cisco TAC für einen von Cisco bereitgestellten NED erstellen, gehen Sie wie folgt vor:

• NSO-Version
• NED-Ablaufverfolgung auf Protokollierungsebene festgelegt
• Die NED-Ablaufverfolgung muss entweder einen compare-config oder einen sync-from Vorgang erfassen.
• Die NED-Nachverfolgung muss das jeweilige Problem erfassen, bei dem Sie Hilfe benötigen.
• Alle Informationen über andere Geräte oder NEDs, die ebenfalls ein Problem anzeigen
• Informationen über ähnliche Geräte in derselben NED, die kein Problem anzeigen

Anmerkung: Netconf NEDs, die mit dem NSO NED Builder-Tool erstellt wurden, werden von Cisco nur unterstützt, wenn Probleme mit dem Tool selbst auftreten.

Tipp: Verwenden Sie für NEDs, die von den Crosswork NSO-Entwicklern bereitgestellt werden, Technologie: NMS (Netzwerkmanagement-Services und Subtechnologie: Network Service Orchestrator (NSO) - NED