Wenn OSPF-Nachbarn nicht FULL werden

Die Zustände der Nachbarschaft und was jeder bedeutet

RFC 2328 beschreibt die Nachbarschaft als Zustandsautomaten. Für die Fehlersuche reicht es, zu wissen, welche Bedingung den nächsten Zustand auslöst. Wer weiß, welcher Übergang fehlt, weiß, wo er suchen muss.

Kein Nachbar sichtbar: die vier üblichen Gründe

Wenn show ip ospf neighbor leer bleibt, kommt kein gültiges Hello an. Bevor du an Timern suchst, prüfe die einfachen Dinge in dieser Reihenfolge, denn sie decken die meisten Fälle ab.

• OSPF ist auf dem Interface aktiv: show ip ospf interface brief listet das Interface mit Area und Zustand. Fehlt es, passt die network-Anweisung nicht oder die Interface-Konfiguration ip ospf 1 area 0 fehlt.

• Das Interface ist nicht passiv: Mit passive-interface default sendet OSPF auf keinem Interface Hellos, bis du die Ausnahme mit no passive-interface setzt. show ip ospf interface zeigt dann No Hellos (Passive interface).

• Beide Seiten liegen im selben Subnetz: Auf Broadcast-Netzen muss auch die Maske stimmen. Ein /24 gegen ein /25 verhindert die Nachbarschaft, auch wenn sich beide Adressen per Ping erreichen.

• Nichts filtert unterwegs: Eine Interface-ACL, ein Control-Plane-Policing, ein Firewall-Modul oder ein Switch mit Multicast-Filter kann IP-Protokoll 89 oder 224.0.0.5 verwerfen. Der Test ping 224.0.0.5 vom Nachbarn zeigt, ob Multicast überhaupt ankommt.

R1# show ip ospf interface GigabitEthernet0/0/1
GigabitEthernet0/0/1 is up, line protocol is up
  Internet Address 10.0.12.1/30, Area 0, Attached via Network Statement
  Process ID 1, Router ID 10.255.0.1, Network Type POINT_TO_POINT, Cost: 1
  Transmit Delay is 1 sec, State POINT_TO_POINT
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
  Neighbor Count is 0, Adjacent neighbor count is 0
  Message digest authentication enabled
    Youngest key id is 1

INIT und 2-WAY: Timer, Area, Authentifizierung, DR

Eine Nachbarschaft in INIT ist ein Zeichen für einseitige Kommunikation. Der eine Router hört den anderen, der andere hört ihn nicht. Der Grund liegt deshalb nie in einem Parameter, den beide gemeinsam haben, sondern in der Richtung. Suche zuerst auf dem Router, der den Nachbarn gar nicht oder in DOWN zeigt, mit debug ip ospf hello nach verworfenen Paketen. Häufig zeigt sich dort eine einseitige Authentifizierung oder ein Filter, der nur in eine Richtung wirkt.

Unterschiedliche Timer, Areas oder Authentifizierungsdaten führen dagegen meist gar nicht erst zu INIT, weil das Hello schon bei der Prüfung verworfen wird. Der Nachbar bleibt unsichtbar, und nur das Debug oder das Log verrät, warum. Cisco nennt als Prüfgrößen im Hello Area-ID, Area-Typ, Subnetzmaske, Hello- und Dead-Intervall sowie die Authentifizierung.

2-WAY ist auf Ethernet-Segmenten mit mehr als zwei Routern zwischen zwei DROTHER der Normalzustand. Ob ein Router DR wird, entscheidet zuerst die Priorität und bei Gleichstand die höhere Router-ID. Die Wahl ist nicht präemptiv: Ein neuer Router mit höherer Priorität übernimmt den DR erst, wenn der bisherige ausfällt oder OSPF neu startet. Auf Links mit genau zwei Routern sparst du dir das ganze Thema mit dem Netzwerktyp point-to-point.

R2# debug ip ospf hello
OSPF-1 HELLO Gi0/0/1: Rcv hello from 10.255.0.1 area 0 10.0.12.1
OSPF-1 HELLO Gi0/0/1: Mismatched hello parameters from 10.0.12.1
OSPF-1 HELLO Gi0/0/1: Dead R 40 C 120, Hello R 10 C 30
!
R2# show logging | include OSPF
%OSPF-4-ERRRCV: Received invalid packet: mismatch area ID, from backbone area must be virtual-link but not found from 10.0.12.1, GigabitEthernet0/0/1
!
R2# undebug all

EXSTART und EXCHANGE: MTU und Router-ID

Ab EXSTART tauschen die Router Database-Description-Pakete aus. Diese Pakete sind deutlich größer als ein Hello, und das erklärt, warum MTU-Fehler erst hier auffallen. Die Hellos passen durch, die DBD-Pakete mit Hunderten LSA-Headern nicht. Cisco nennt den MTU-Mismatch in der eigenen Fehlerbeschreibung zu EXSTART und EXCHANGE als häufigste Ursache, besonders zwischen Routern verschiedener Hersteller.

Typisch ist folgendes Bild: Ein Router hat auf einem GRE-Tunnel oder einem PPPoE-Subinterface ip mtu 1476 oder 1492, der Nachbar die Standard-MTU 1500. Der Router mit der kleineren MTU verwirft die DBD-Pakete des anderen und sendet seine eigenen immer wieder. Der Router mit der größeren MTU sieht davon keinen Fehler. Deshalb lohnt das Debug auf beiden Seiten.

Die richtige Lösung ist, die IP-MTU auf beiden Enden gleich zu setzen. ip ospf mtu-ignore auf dem Interface schaltet die Prüfung ab und lässt die Nachbarschaft zu. Das ist nur dort vertretbar, wo die MTU-Werte bewusst verschieden sind und die Pakete trotzdem durchpassen. Sonst bildet sich die Nachbarschaft zwar, aber spätere große LS-Updates werden verworfen, und der Fehler wandert an eine schwerer sichtbare Stelle.

Eine doppelte Router-ID ist der zweite Grund. Sie entsteht oft, wenn eine Konfiguration von einem anderen Router kopiert wurde, samt router-id. Cisco meldet sie mit OSPF-4-DUP_RTRID_NBR im Log. Die Router-ID muss im gesamten OSPF-Bereich eindeutig sein. Nach dem Ändern greift sie erst, wenn du clear ip ospf process ausführst, was alle Nachbarschaften des Prozesses kurz abbaut.

R2# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
10.255.0.1        1   EXSTART/  -     00:00:36    10.0.12.1       Tunnel0
!
R2# debug ip ospf adj
OSPF-1 ADJ Tu0: Nbr 10.255.0.1 has larger interface MTU
!
R1# configure terminal
R1(config)# interface Tunnel0
R1(config-if)# ip mtu 1476
R1(config-if)# end

Netzwerktyp-Mismatch: Broadcast gegen Point-to-Point

Dieser Fehler ist tückisch, weil er keinen falschen Zustand erzeugt. Ethernet-Interfaces sind bei Cisco standardmäßig vom Typ broadcast. Viele setzen auf Router-zu-Router-Links ip ospf network point-to-point, um die DR-Wahl zu sparen, und vergessen es auf einer Seite. Weil beide Typen dieselben Hello-Timer von 10 und 40 Sekunden haben, bildet sich die Nachbarschaft trotzdem und wird FULL.

Das Problem zeigt sich in der Datenbank. Der Router mit point-to-point beschreibt den Link in seinem Router-LSA als Verbindung zu einem Nachbarn, der mit broadcast als Transit-Netz mit DR. Bei der SPF-Berechnung prüft OSPF, ob ein Link von beiden Seiten gleich beschrieben wird. Das ist hier nicht der Fall, und die Netze hinter dem Link fehlen in der Routingtabelle. Andere Kombinationen wie broadcast gegen non-broadcast fallen schneller auf, weil sich dort die Timer unterscheiden und die Nachbarschaft gar nicht entsteht.

Prüfbefehle in fester Reihenfolge

Diese Reihenfolge geht vom Billigen zum Aufwändigen. Die ersten fünf Befehle sind reine Anzeigen und auf jedem produktiven Router unbedenklich. Die Debugs gegen Ende sind auf IOS XE gezielt und erzeugen wenig Last, gehören aber trotzdem auf ein Interface beschränkt und mit undebug all beendet.

Auf IOS XR heißen die Befehle show ospf neighbor und show ospf interface, OSPF wird dort je Interface unter router ospf konfiguriert. Auf NX-OS lautet der Nachbarbefehl show ip ospf neighbors. Die Zustände und Ursachen sind auf allen drei Plattformen gleich.

show ip ospf neighbor
show ip ospf interface brief
show ip ospf interface GigabitEthernet0/0/1
show interface GigabitEthernet0/0/1 | include MTU
show ip ospf | include ID|Area
ping 224.0.0.5
show ip access-lists
terminal monitor
debug ip ospf hello
debug ip ospf adj
undebug all
show ip ospf database router 10.255.0.2