Wie man eine Routingschleife von flatternden Routen auf VPN-Standorten unterscheidet
Eine Routingschleife und eine flatternde Route verursachen denselben zeitweiligen Verlust. Drei Prüfungen an den Gateways unterscheiden sie, bevor Sie irgendetwas ändern.
Zwei Standorte, ein Tunnel und ein entferntes Präfix, das eine Weile antwortet und dann verstummt. Der Reflex ist, das eine Routingschleife zu nennen, und manchmal ist es genau das. Aber eine Schleife und eine flatternde Route erzeugen dieselbe Beschwerde und brauchen entgegengesetzte Reparaturen: Die eine ist eine Weiterleitungsentscheidung, die nie endet, die andere ein Präfix, das die Tabelle immer wieder verlässt. Drei Beobachtungen trennen sie, und alle drei lassen sich an der Kommandozeile des Gateways sammeln, bevor Sie einen Filter anfassen oder einen Tunnel neu starten.
Eine Schleife entscheidet sich Hop für Hop. Standort A wählt B als nächsten Hop für das Ziel, B wählt A für dasselbe Ziel, und das Paket läuft nach zwei Runden auf der TTL ab. Ein Flattern entscheidet stattdessen das Routingprotokoll: Das Präfix wird zurückgezogen, neu installiert oder durch einen alternativen nächsten Hop ersetzt, sodass manche Pakete gar keine Route haben, während andere einer völlig guten folgen.
Die drei Prüfungen, die die Frage klären
Für die erste Entscheidung brauchen Sie keinen Paketmitschnitt. Sie brauchen den Zustand des Präfixes an beiden Enden, den nächsten Hop, den jede Seite wählt, und eine Hop-Zahl, die sich entweder wiederholt oder nicht. Bleibt das Präfix mit demselben nächsten Hop installiert, während der Verkehr scheitert, lebt die Schleife im Weiterleitungspfad. Verschwindet das Präfix und kommt zurück, liegt der Fehler oberhalb der Weiterleitung, und die Reparatur gehört ins Routingprotokoll, nicht in eine statische Route.
| Observation | Routing loop | Route flapping |
|---|---|---|
| Prefix in the table | Installed, same next hop throughout | Withdrawn and reinstalled, or next hop alternates |
| Hop count | Reaches zero at the same two gateways | Expires only while the prefix is missing |
| Failure shape | Consistent loss for that prefix from every source | Bursts, often after a link or peer event |
| Where the fix belongs | The site that owns the prefix, plus filters on the transit path | Advertisement, hold timers, or the flapping link |
Eine Warnung vorab. Wenn Sie das über den Tunnel lesen, der schleift, stirbt Ihre Sitzung in dem Moment, in dem Sie die Route ändern. Öffnen Sie eine Konsole oder einen Verwaltungspfad, der nicht von dem Präfix abhängt, das Sie reparieren wollen.
Prüfung eins: Ist das Präfix stabil oder zappelt es
Fragen Sie den Kernel, was er installiert hat, nicht was die Konfigurationsdatei verspricht. Auf einem Linux-Gateway führt ip route get 10.20.30.40 dieselbe Suche aus wie der Weiterleitungspfad, einschließlich Policy-Tabellen, während ip route show 10.20.30.0/24 den Eintrag selbst zeigt. ip monitor route überträgt jede Änderung im Moment ihres Eintretens, was der schnellste Weg ist, ein Präfix kommen und gehen zu sehen.
Auf einem Router mit FRR oder BIRD ist die Weiterleitungstabelle nicht die interessante. show ip bgp 10.20.30.0/24 liefert den gewählten Pfad und seine Laufzeit; eine Laufzeit, die sich alle paar Minuten zurücksetzt, ist ein Flattern, das Sie benennen können, keine Schleife. show ip bgp summary zeigt Nachbarzustand und Präfixzahlen, sodass ein Peer, der immer wieder ausfällt, die Schuld vom Weiterleitungspfad nimmt.
Schreiben Sie die Antwort auf, bevor Sie etwas ändern. Zehn Minuten stabil, während Pings scheiterten, und viermal in zehn Minuten verschwunden führen zu unterschiedlichen nächsten Schritten. Der zweite Fall macht jede Theorie zur statischen Route irrelevant.
Prüfung zwei: Zeigt der nächste Hop zurück in den Ankunftstunnel
Eine Schleife braucht zwei Gateways, die sich einig sind. Betrachten Sie am empfangenden Standort die Route, mit der das Paket hinausgeht: ip route get 10.20.30.40 from 10.10.5.20 mit der echten Quelladresse, denn eine Policy-Regel kann anders antworten als die Haupttabelle. Wiederholen Sie die Suche dann am sendenden Standort. Wählt jede Seite die andere als nächsten Hop für dasselbe Präfix, ist die Schleife bewiesen, und kein Mitschnitt wird etwas hinzufügen.
Die Ursache ist fast immer eine Ankündigung, die den Tunnel nicht hätte überqueren dürfen. Eine in den Tunnel umverteilte Standardroute, ein Aggregat, das das eigene Subnetz des entfernten Standorts abdeckt, oder eine statische Route zum Peer auf Verdacht erzeugen alle denselben wechselseitigen nächsten Hop. Der Tunnel kann vollständig aufgebaut sein und den Verkehr trotzdem im Kreis tragen; die Hinweise zur Weiterleitung von strongSwan beschreiben die Routingseite dieser Anforderung.
WireGuard verdient eine eigene Anmerkung, denn es gibt keine Ankündigung, der man die Schuld geben könnte. wg show listet die AllowedIPs für jeden Peer, und der Kernel akzeptiert ein Ziel für einen Peer nur, wenn es in diesen Bereich fällt. Eine Schleife dort ist ein überlappender AllowedIPs-Bereich oder eine statische Route, die über die Schnittstelle zurückzeigt, also lebt die Reparatur an genau diesen zwei Stellen.
Prüfung drei: Lesen Sie die Hop-Zahl, nicht die Sterne
traceroute -n -I 10.20.30.40 und mtr -n -r -c 20 10.20.30.40 zeigen beide den Pfad, und der ICMP-Modus überlebt oft eine Filterung, die UDP-Sonden frisst. Eine Schleife sieht aus wie eine kurze, sich wiederholende Folge derselben zwei Gateway-Adressen, wobei die TTL jedes Mal steigt. Ein Ausfall sieht aus wie Sterne nach dem letzten Gateway, das geantwortet hat, und ein einzelner stiller Hop ist kein Beweis für irgendetwas.
Wenn der Pfad mehrdeutig ist, lesen Sie die TTL auf der Leitung. tcpdump -ni any -vv icmp auf beiden Gateways zeigt die TTL jedes Pakets und die Quelladresse jeder Antwort über überschrittene Zeit. Kommt ein Paket am entfernten Standort mit einer TTL an, die niedriger ist als die Zahl der Hops, die der Pfad enthalten kann, fügt etwas Hops hinzu, die Ihnen traceroute nicht zeigt, und das passiert, wenn die Firewall des einen Standorts Sonden im Namen des anderen beantwortet.
Reparieren Sie den Eigentümer des Präfixes, dann prüfen Sie beide Richtungen
Entscheiden Sie, welcher Standort das Ziel erzeugt und welche Transitpfade erlaubt sind, und ändern Sie dann die Ankündigung oder die statische Route bei diesem Eigentümer. Den empfangenden Standort zu korrigieren ist verlockend und meist falsch: Es versteckt die Schleife für ein Präfix und lässt die schlechte Ankündigung für das nächste stehen. Routen-Tags, Distributionslisten und Split-Horizon-Regeln existieren, um das an der Quelle zu stoppen, und sie sind billiger als ein Filter, der auf ein einzelnes Präfix passt.
Prüfen Sie nach der Änderung Hin- und Rückweg getrennt, denn eine Schleife kann durch ein schwarzes Loch ersetzt werden, ohne dass sich das Symptom sichtbar bessert. Führen Sie ip route get von beiden Enden aus, senden Sie Verkehr von einem Host, der nicht das Gateway ist, und lassen Sie ip monitor route mindestens einen Hold-Timer laufen, damit ein Flattern nicht für eine Reparatur gehalten wird.
Bevor Sie etwas ändern, bestätigen Sie diese fünf Punkte: Das Präfix ist stabil oder zappelt, der nächste Hop an beiden Enden zeigt auf einen Tunnel, die Hop-Zahl wiederholt sich oder nicht, ein Standort besitzt das Präfix, und Sie haben einen Verwaltungspfad, der die Änderung übersteht. Ist einer der fünf unbekannt, sind die anderen vier Vermutungen.