Praktische Schritte für die Fehlerbeseitigung im SD-WAN

Monitoring des SD-WANs

Beim SD-WAN-Troubleshooting geht es im ersten Schritt darum, den Zeitpunkt zu ermitteln, seit wann das Netzwerk nicht mehr die geforderte Performance liefert. In der Regel unterscheidet sich das Monitoring eines SD-WANs nicht allzu sehr vom Monitoring eines normalen Netzwerks.

Die physischen Komponenten lassen sich üblicherweise am einfachsten überwachen – entweder sie funktionieren oder sie funktionieren nicht. Die logischen Funktionen können eine größere Herausforderung darstellen. Das liegt an den Abstraktionen, die dafür sorgen, dass mehrere Netzwerkverbindungen nach außen wie eine einzige erscheinen.

Für das SD-WAN-Monitoring können Netzwerkteams verschiedene Tools und Methoden verwenden.

Ereignisbehandlung (Event Handling)

Das hilfreichste Element einer guten Netzwerkmanagement-Architektur ist die Untersuchung von Ereignissen, die von Netzwerkgeräten stammen, einschließlich SD-WAN-Geräten. Stellen Sie sich Ereignisse als Informationssystem des Netzwerks vor, das Ihnen auf diese Weise alle wichtigen Vorfälle meldet. Der Prozess erfordert kein Polling und skaliert gut, wenn das Netzwerk wächst.

Ich bevorzuge Syslog-Ereignisse über SNMP-Traps (Simple Network Management Protocol), weil sie nicht voraussetzen, dass eine bestimmte Management Information Base (MIB) in das Managementsystem geladen werden muss, um die Details zu sehen. IT-Teams sollten die SD-WAN-Komponenten so konfigurieren, dass sie Ereignisse an ein gängiges System für die Ereignisbehandlung senden. Dort können sie gespeichert, korreliert und verarbeitet werden.

Für Organisationen mit kleinem Budget empfehlen sich Open-Source-Lösungen wie Syslog-ng zusammen mit anderen Analyse-Tools, um die große Menge an Ereignissen zusammenzufassen, die ein Netzwerk generieren kann. Wer weitere Analysemöglichkeiten sucht, sollte einen Blick auf Elasticsearch, Logstash und Kibana (die sogenannten ELK-Lösungen) werfen. Falls Sie Anbieter-Support benötigen, gibt es entsprechend unterstützte ELK-Versionen sowie Offerten von Netzwerkausrüstern und Logging-Anbietern.

Das System für die Ereignisverarbeitung sollte so eingerichtet werden, dass es automatisch ein Trouble Ticket erzeugt oder einen Alarm in Echtzeit an die IT-Abteilung sendet, wenn es ein kritisches Ereignis entdeckt. Alle Ereignisse sollten in einer täglichen oder wöchentlichen Übersicht gemeldet werden, um zu garantieren, dass verpasste Ereignisse doch noch bemerkt werden. Beispielsweise ist es gut, zu wissen, wenn ein redundantes Design zur Hälfte nicht funktionsfähig ist.

Active Path Testing

SD-WAN nutzt mehrere Verbindungen, um einen zuverlässigen End-to-End-Service zu ermöglichen. Per Active Path Monitoring kann das System prüfen, wie erfolgreich das SD-WAN in puncto gewünschter Zuverlässigkeit arbeitet. Möglicherweise sind mehrere Tests nötig, um die Pfade für verschiedene Traffic-Typen, etwa Echtzeit- versus Bulk-Daten, zu checken. Wenn die Anzahl der SD-WAN-Standorte wächst, ist eine einfache Bereitstellung für eine erfolgreiche Implementierung von entscheidender Bedeutung.

Achten Sie darauf, die Tests so zu konfigurieren, dass sie echten Anwendungs-Traffic emulieren. Dazu gehören Paketgröße, Übertragungsrate und QoS-Markierungen (Quality of Service). Ein Vorteil von Active Path Testing liegt darin, dass es Probleme außerhalb normaler Arbeitszeiten erkennen kann, wenn es keinen Anwendungs-Traffic gibt. Active Path Testing emuliert echten Anwendungs-Traffic und testet das End-to-End-System insgesamt, einschließlich Link-Auswahl.

IT-Teams können diesen Testtyp während Proof-of-Concept-Evaluierungen nutzen, indem sie jeden WAN-Link deaktivieren und überwachen, wie sich die Testergebnisse verändern. Das empfiehlt sich insbesondere dann, um festzustellen, wie gut eine günstige Breitbandverbindung Echtzeit-Traffic oder Traffic mit hoher Priorität bewältigt, wenn der Pfad mit geringer Latenz nicht zur Verfügung steht.

Lassen Sie die Tests durchgehend laufen. Auf diese Weise lässt sich auch sehen, wie sich die Anwendungen zu verschiedenen Zeiten verhalten. Oder Sie möchten das Performance-Level kennen, wenn andere Anwendungen laufen – zum Beispiel Backups oder die Datenbanksynchronisierung – oder das Breitbandnetzwerk stark ausgelastet ist.

Physischer Status

SD-WAN-Geräte basieren typischerweise auf einem x86-System mit interner CPU, Speicher, Schnittstellen, Stromversorgungen und Kühlung. Ein Netzwerkereignis, üblicherweise Syslog, sollte Probleme mit diesen Komponenten melden.

Das Monitoring mit SNMP kann zusätzliche Daten zur Nutzung dieser Ressourcen bereitstellen und Antworten etwa auf die folgenden Fragen liefern:

• Wie viele Puffer werden für jeden Pfad verwendet?
• Ist die CPU zu Zeiten, an denen viel los ist, stark ausgelastet?
• Funktioniert die Stromversorgung ordnungsgemäß, oder kommt es zu Schwankungen, die außerhalb der Spezifikationen für die Stromversorgung liegen?

Die Standardkonfigurationen für Parameter wie das Buffering sind im Allgemeinen korrekt. Manchmal müssen Sie jedoch die Möglichkeit haben, die Anzahl der Puffer anzupassen, um die Funktionseigenschaften einer Anwendung, wie das Handling einer großen Zahl sehr kleiner Pakete, zu unterstützen. Stellen Sie sicher, dass die Queue-Tiefen bei Bedarf geändert werden können.

Sie sollten überprüfen, ob der SD-WAN-Controller Alarme und Berichte liefert, wenn eine physische Verbindung Probleme hat. Er sollte Folgendes erkennen: instabile Verbindungen, Schnittstellenfehler, verworfene Pakete aufgrund von Überlastung und Duplex Mismatch. Ja, es stimmt: Duplex Mismatch ist nach wie vor ein häufiges Problem. Daher sollten Sie wenn möglich Auto Negotiation nutzen. Verwenden Sie tägliche oder wöchentliche Berichte, um Probleme zu identifizieren, bei denen die zugehörigen Alarme eventuell übersehen wurden.

Topologiekarten

Die Topologie zu kennen, ist für das Troubleshooting wichtig. Doch das manuelle Aktualisieren von Topologiekarten ist sehr zeitaufwendig und fehleranfällig. Besser ist ein SD-WAN-Kontrollsystem, das in der Lage ist, dynamische Karten der physischen und logischen Topologie zu generieren. Die Baseline ist wie ein Network Source of Truth (NSoT) für die physische SD-WAN-Topologie. Und wenn Sie wissen, inwiefern sich der tatsächliche und der gewünschte Status voneinander unterscheiden, kann dies das SD-WAN-Troubleshooting um ein Vielfaches einfacher machen.

Feststellen des Problems

Entscheidend für das Troubleshooting jedes Netzwerkproblems ist ein methodisches Vorgehen. Starten Sie an einem Ende, und arbeiten Sie sich zum anderen vor. Oder setzen Sie eine Divide-and-Conquer-Strategie ein. Stellen Sie fest, welche Art von Problem wahrscheinlich vorliegt, indem Sie sich die Symptome anschauen.

Das OSI-Modell (Open Systems Interconnection) ist praktisch, um die Art des Problems zu bestimmen und das Troubleshooting in die richtige Richtung zu lenken, etwa folgendermaßen:

• ein physisches Problem, wie eine ausgefallene Schnittstelle
• ein Verbindungsproblem, zum Beispiel Duplex Mismatch
• ein Routing-Problem, etwa wenn einige Ziele erreichbar und Single-Hop-Tests erfolgreich sind
• ein Anwendungsproblem, beispielsweise Firewall- oder MTU-Probleme

Falls einige Daten übertragen werden, arbeiten Funktionen auf den unteren Schichten höchstwahrscheinlich korrekt, so dass Sie sich auf die oberen Schichten konzentrieren können.

Schritte für das SD-WAN-Troubleshooting

Zur Analyse des Problems gehören in der Regel die folgenden Punkte:

1. Überprüfen Sie die grundlegende Funktionalität des SD-WAN-Knotens.

In diesem Schritt werden CPU, Speicher und Schnittstellenkonnektivität untersucht. Der Knoten sollte imstande sein, mit dem Controller zu kommunizieren und seine Konfiguration herunterzuladen.

2. Kontrollieren Sie die grundlegende Schnittstellenfunktionalität

Die gewünschten Schnittstellen sollten aktiviert sein und mit dem Gerät am anderen Ende der Verbindung kommunizieren. Es sollte eine grundlegende Konnektivität mit dem SD-WAN-Controller gegeben sein, um seine Konfiguration herunterzuladen.

3. Prüfen Sie die VPN-Funktionalität

SD-WAN-Produkte erstellen ein logisches VPN-Overlay, das auf der physischen Topologie aufsetzt. Sie müssen wissen, wie der Verschlüsselungsprozess des VPNs funktioniert, wie es dabei zu Fehlern kommen kann und wie Sie feststellen, ob er korrekt arbeitet.

4. Integration in die allgemeine Routing-Architektur.

Die SD-WAN-Geräte fassen mehrere Verbindungen zusammen, so dass sie funktionell wie ein einziger Link wirken. Welche Netzwerke am jeweiligen Standort erreichbar sind, muss den anderen Standorten mitgeteilt werden, ohne die allgemeine Routing-Architektur zu beeinträchtigen. Das bedeutet, kein Routing von Black Holes, Loops oder nicht erreichbaren Subnetzen. Sie müssen verstehen, wie Route Distribution funktioniert und wie deren Troubleshooting aussieht.

5. Überprüfen der Weiterleitungs-Policy.

Nehmen die Pakete den passenden Weg zwischen SD-WAN-Geräten? Die SD-WAN-Geräte messen Latenz, Paketverluste und Jitter zwischen sich und verwenden Policies, um festzulegen, welche Verbindung die betreffende Anwendung nutzen sollte.

Wenn eine Verbindung für eine Anwendung ausfällt – oder für diesen Traffic-Typ nicht geeignet ist –, wird der Traffic zu einem anderen Link verschoben. Das wirkt sich potenziell auf die verschobene Anwendung aus sowie auf die Anwendungen, die die immer noch funktionierenden Links nutzen. Diese Analyse erfordert möglicherweise einige systemnahe Befehle, um auf die detaillierten Daten zuzugreifen.

In diesem Fall ist die Kommandozeile hilfreich. Es handelt sich dabei einerseits um show-Befehle, um den Systemstatus zu untersuchen, und andererseits um Kommandos wie Ping und Traceroute zum Testen. Lernen Sie, wie Sie die Befehle für einzelne Links und das Testen von Anwendungs-Traffic einsetzen.

Paketmitschnitte sind dann notwendig, um eine Anwendung zu diagnostizieren, die Probleme hat, die Sie auf andere Weise nicht eingrenzen können Wireshark etwa bietet eine grafische Darstellung des TCP-Sequenzraums. Diese hilfreiche Funktionalität benötigt dateibasierte Paketmitschnitte.

WAN-Carrier- und Link-Probleme

Sie brauchen detaillierte Einblicke in Verbindungsmerkmale von Paketverlusten, Latenz und Jitter. Entsprechen sie den von Ihnen festgelegten Richtlinien? Stimmt die Link-Performance mit den Vereinbarungen in den Service Level Agreements (SLA) überein? Während es für einen MPLS-Link wahrscheinlich ein SLA gibt, ist dies für eine preiswerte Breitbandverbindung meist nicht der Fall.

Hier könnte der Divide-and-Conquer-Ansatz notwendig sein. Aktivieren Sie gezielt nur einen physischen Link gleichzeitig, und prüfen Sie, ob der Link funktioniert. Probieren Sie dann Link-Kombinationen, bis schließlich alle Verbindungen funktionieren. Vergessen Sie nicht zu kontrollieren, ob die Policies stimmen. Link-Charakteristiken können sich ändern, so dass diese Links von keiner Policy erfasst werden.

Es ist ratsam, einen wöchentlichen Bericht der Link-Charakteristiken und -Nutzung zu erstellen. Für eine große SD-WAN-Implementierung wird dieser Bericht selbst zu umfangreich, um hilfreich zu sein. Filtern Sie daher die Ergebnisse, damit nur die Links übrigbleiben, deren Eigenschaften unter keine Policy fallen.

Überprüfen Sie auf unpassende MTU-Werte. Anwendungen, die kleine Pakete nutzen, funktionieren, Anwendungen, die größere Pakete benötigen, hingegen nicht. Wenn Ping- und Terminal-Verbindungen erfolgreich sind, aber Dateitransfers, Backups und die Datenbanksynchronisierung scheitern, sollten Sie sich die MTU-Werte ansehen. Testen Sie auf MTU-Probleme, indem Sie Pings mit großen Paketen durchführen.

Duplex Mismatch ist immer noch ein häufig auftretendes Problem. Untersuchen Sie Schnittstellenstatistiken, um festzustellen, ob ein Duplex Mismatch vorliegt, auch wenn Sie nicht die Konfiguration jeder Schnittstelle einer Ethernet-Verbindung prüfen können. Eine Vollduplex-Schnittstelle wird den Empfang von Runt-Paketen zeigen, eine Halbduplex-Schnittstelle Late Collisions. Diese Zähler sollten nur wenige Werte enthalten. Die Zahl steigt bei einem aktiven Link, wenn es zu unpassenden Werten kommt.

Fazit

Troubleshooting ist halb Kunst, halb Wissenschaft. Ich empfehle in der ersten Proof-of-Concept-Phase, sich intensiv damit zu beschäftigen, wie das jeweilige SD-WAN-Produkt funktioniert und welche Tools für das SD-WAN-Troubleshooting zur Verfügung stehen. Es bietet sich ein einfaches Textdokument an, in dem Sie die grundlegenden durchzuführenden Schritte für einen bestimmten SD-WAN-Anbieter festhalten. Auf diese Weise erhalten Sie eine optimierte Vorgehensweise für das SD-WAN-Troubleshooting, wenn im Netzwerk Probleme auftreten.