OSPF-Nachbarn bilden sich nicht über ein VPN? Prüfen Sie diese Punkte der Reihe nach

Der Tunnel steht, die Schnittstellen liegen im selben Subnetz, und OSPF zeigt trotzdem nichts. Meist ist der Tunnel in Ordnung, und eine OSPF-Anforderung ist nicht erfüllt. Arbeiten Sie die fünf Prüfungen unten der Reihe nach ab und stoppen Sie bei der ersten, die fehlschlägt.

Jede Prüfung hat ein eigenes Symptom, deshalb ist die Reihenfolge wichtiger als die Liste.

Prüfung 1: Stimmt das Link-Modell

Eine Punkt-zu-Punkt-Schnittstelle und ein gemeinsam genutztes Multi-Access-Netz sind unterschiedliche OSPF-Umgebungen. Eine Broadcast-LAN-Konfiguration auf einen Tunnel zu kopieren, ist hier der häufigste Fehler. Setzen Sie den Netzwerktyp, den die VPN-Implementierung unterstützt, bei einem gerouteten Tunnel meist Punkt-zu-Punkt. Bestätigen Sie dann, dass die Plattform zustimmt, denn manche Implementierungen ignorieren oder überschreiben die Einstellung.

Ist das Link-Modell falsch, hilft nichts Weiteres auf der Liste.

Prüfung 2: Werden die Pakete durchgelassen

OSPFv2 ist IP-Protokoll 89, kein TCP- oder UDP-Port, daher verwirft eine für Ports geschriebene Firewall-Regel es stillschweigend. Hellos gehen außerdem an Multicast-Adressen, was eine Richtlinie nicht erlauben muss. Erlauben Sie Protokoll 89 zwischen den Tunnelendpunkten und prüfen Sie dann, ob die Plattform explizite Nachbar-Statements benötigt.

Ein Tunnel, der nur Pings durchlässt, ist ein Richtlinienproblem, kein Routingproblem.

Prüfung 3: Stimmen die Nachbarparameter

Bereichs-ID, Hello- und Dead-Intervalle, Authentifizierung und Stub-Flags müssen alle übereinstimmen. Eine Abweichung lässt den Nachbarn meist in einem sichtbaren Zustand hängen, statt still zu scheitern, was nützlich ist. Vergleichen Sie die laufende Konfiguration auf beiden Seiten, nicht die beabsichtigte.

Die MTU-Abweichung ist die subtile. Sie blockiert den Datenbankaustausch bei ExStart, sodass der Nachbar nie Full erreicht.

Prüfung 4: Was sagt der Zustand

Der Zustand benennt den Fehler. Init bedeutet, dass Hellos ankommen, dieser Router aber nicht darin aufgeführt ist, was auf einen Einwegpfad oder ein Multicast-Problem hindeutet. Two-Way ist auf einem Broadcast-Segment mit einem Nachbarn, der nicht DR ist, normal und auf einem Punkt-zu-Punkt-Link unnormal. Hängendes ExStart oder Exchange bedeutet ein MTU- oder Datenbankbeschreibungsproblem. Loading bedeutet, dass Link-State-Anfragen nicht beantwortet werden.

Lesen Sie den Zustand, bevor Sie etwas ändern, denn er schließt den größten Teil der Liste aus.

show ip ospf neighbor gibt den Zustand, die Nachbaradresse und den Dead-Timer aus. Vergleichen Sie diesen Timer mit dem Hello-Intervall auf beiden Seiten: ein Dead-Intervall vom Vierfachen des Hello ist normal, alles andere ist eine Abweichung. Die Zustandsspalte ist die schnellste Lektüre auf der ganzen Seite.

Prüfung 5: Was wird tatsächlich angekündigt

Eine Full-Adjacency ist keine Route. Prüfen Sie, welche Netze erzeugt, welche gelernt und welche in die Routing-Tabelle eingetragen werden. Ein fehlendes Netz-Statement oder eine Redistributionsrichtlinie, die das Standort-Präfix ausschließt, ergibt einen gesunden Nachbarn und eine leere Tabelle.

Testen Sie dann eine Anwendung auf Host-Ebene und den Rückweg, denn ein Routingprotokoll öffnet keine Firewall.

Für IPv6 hat OSPFv3 eigene Anforderungen und ist kein Adressfamilien-Schalter über jeder OSPFv2-Einstellung. Verwenden Sie das passende Protokoll und die Plattformdokumentation. Und wenn die Verbindung ein fester Link ist, vergleichen Sie statische Routen, bevor Sie eine Control Plane hinzufügen, die Sie betreiben müssen.