OSPF-buren blijven op Init of Exstart staan

Je hebt OSPF aangezet op twee routers, de buur verschijnt in de lijst en blijft daar hangen. Hij komt niet op Full, dus er worden geen routes uitgewisseld en je netwerk kent de andere kant niet. Soms staat hij op Init, soms op Exstart of Exchange, soms wisselt hij daartussen.

Wat het niet is: dit is geen routeringsprobleem. Er is nog niets uitgewisseld, dus over routes valt nog niets te zeggen. Het is ook geen kwestie van geduld: een gezonde adjacency is binnen enkele seconden Full. Blijft hij ergens staan, dan blijft hij daar. De toestand geeft precies aan hoe ver het gekomen is.

Down of helemaal geen buur: Er komen geen hellos aan. Interface, area, authenticatie of firewall.
Init: Jij hoort hem, hij hoort jou niet. Het verkeer is eenrichtingsverkeer.
Exstart of Exchange: Ze praten, maar de database-pakketten komen niet door. Bijna altijd de MTU.

De snelle controles, op volgorde

Wat is de toestand precies? /routing ospf neighbor print. Goed antwoord: state: Full. Noteer de toestand aan beide kanten, want die kunnen verschillen en dat verschil is informatie.
Doet de interface mee? /routing ospf interface print. Goed antwoord: de interface staat er met de juiste area en niet als passive. Een passieve interface stuurt geen hellos en krijgt dus nooit een buur.
Komen de hellos aan? /tool sniffer quick interface=tunnel ip-protocol=ospf, of /log print where topics~"ospf". Goed antwoord: je ziet pakketten in beide richtingen. Zie je ze maar één kant op, dan is dat je Init.
Laat de firewall het toe? /ip firewall filter print stats en kijk naar de input-chain. Goed antwoord: er is een regel die verkeer van de buur-interface accepteert, en de afsluitende drop telt niet op terwijl OSPF probeert. OSPF is IP-protocol 89 en gaat naar 224.0.0.5.
Is de MTU gelijk? /interface print aan beide kanten, en vergelijk de MTU van de interface waar OSPF op draait. Goed antwoord: precies hetzelfde getal. Dit is de controle die Exstart oplost.
Komt een groot pakket erdoor? /ping buur size=1400 do-not-fragment. Goed antwoord: antwoord. Werken kleine pings wel en grote niet, dan zit de vernauwing ergens onderweg.

De gewone oorzaken, meest voorkomend eerst

Exstart: de MTU verschilt

Bij het opbouwen van de database sturen beide kanten hun interface-MTU mee. Verschillen die, dan weigert de ander en blijft het staan op Exstart of Exchange. Over een tunnel is dit de standaardfout, want elk tunneltype heeft zijn eigen overhead: GRE houdt 1476 over, IPIP 1480, EoIP 1458 en WireGuard staat standaard op 1420. Zet je aan één kant iets met de hand en aan de andere niet, dan verschilt het. De oplossing is aan beide kanten hetzelfde getal zetten, niet het hoogste getal zoeken.

Init: het verkeer gaat maar één kant op

Jouw router ziet de hellos van de buur en noemt hem daarom, maar zijn hellos komen niet bij jou aan, of andersom. Dat is bijna altijd een firewall: de input-chain van één van beide routers accepteert het verkeer van die interface niet. Bij een tunnel gebeurt dat als de tunnelinterface niet in de LAN-lijst zit, want de standaardregels accepteren input vanaf LAN en droppen de rest.

Area, timers of authenticatie verschillen

OSPF vormt alleen een relatie tussen buren die het over de basis eens zijn: dezelfde area-ID, dezelfde hello- en dead-interval, aan beide kanten wel of geen MD5-sleutel, en dezelfde sleutel. Eén kant met authenticatie en de andere zonder geeft geen foutmelding die je verwacht; er gebeurt gewoon niets.

Router-ID ontbreekt of komt dubbel voor

Zonder loopback of ingevuld router-ID kiest RouterOS er zelf een, en die kan veranderen als een interface wegvalt. Twee routers met hetzelfde ID geven adjacencies die steeds opnieuw beginnen.

Wat de configurator hiervan doet

OSPF zit in het onderdeel Routing, standaard uit, bedoeld voor core-routers. Je vult een of meer Areas in, met backbone op 0.0.0.0 als eerste, en daaronder Interface-templates met per regel een area, een interface of een netwerk, een cost, een vinkje passief en een vinkje MD5-authenticatie.
Het veld Loopback/router-id adres maakt een bridge lo zonder spanning tree met een /32 erop, en dat adres wordt het router-ID als je het veld Router-ID leeg laat. Vul het in: het is de goedkoopste manier om de twee problemen met router-IDs voor te zijn.
Zet je MD5-authenticatie aan op een template, dan komt die sleutel op alle templates met authenticatie te staan, met auth-id=1. De andere kant moet dezelfde sleutel en hetzelfde id gebruiken.
Een template die een interface noemt en niet passief is, krijgt type=broadcast. Voor een gewone LAN-interface klopt dat. Op een lijn met twee kanten is een DR-verkiezing overbodig; blijft een buur over een tunnel op 2-Way staan, zet dan aan beide kanten type=ptp.
Wees eerlijk over de belangrijkste blinde vlek: de tool controleert de MTU van een tunnel niet. In de meerdere-apparaten-weergave worden de MTU's van de twee kanten van een getekende kabel vergeleken, en de bridge-MTU van apparaten die aan elkaar vastzitten, maar een tunnel valt daarbuiten. De controles op tunnels gaan over publieke adressen, sleutels, rollen en botsende adresreeksen, niet over MTU. Juist bij OSPF over een tunnel is dat precies het getal dat je wilt weten, en dat moet je zelf aan beide kanten nakijken.
Er zijn wel twee losse waarschuwingen over MTU in de buurt: over WireGuard boven PPPoE en over VXLAN, dat 1550 bytes over de weg nodig heeft. Die gaan over doorvoer, niet over OSPF, maar ze wijzen naar hetzelfde getal.
De tool controleert ook niet of jullie aan beide kanten dezelfde area en dezelfde timers gebruiken. Hij kent maar één kant van de verbinding, tenzij je beide routers in dezelfde site zet.

Als het niet aan je router ligt

De weg tussen de twee. Loopt de tunnel over internet, dan bepaalt de kleinste MTU onderweg wat er doorkomt. Grote pakketten die stilletjes verdwijnen, geven hetzelfde beeld als een MTU-verschil.

Verder lezen: OSPF, MTU en OSPF tussen locaties.