OSPF tussen locaties

Statische routes zijn voorspelbaar en dat is hun grootste voordeel. Ze zijn ook dom: een route blijft staan als de weg eronder weg is. Zolang er precies één pad naar elke vestiging is, is dat geen probleem. Zodra er twee zijn, moet iets kiezen, en dat iets is een routeringsprotocol.

Wanneer je het nodig hebt

• Twee wegen naar dezelfde vestiging. Een glasverbinding met een tunnel over internet als reserve, of een ring van tunnels tussen drie of meer locaties.
• Vestigingen die elkaar via een derde moeten bereiken. Bij een handvol filialen is dat met de hand te doen; vanaf een stuk of tien is het bijhouden van routes op elke router het echte werk geworden.
• Netwerken die veranderen. Elk nieuw subnet op een vestiging betekent anders een route erbij op elke andere router.

En wanneer je het niet nodig hebt: een hoofdkantoor met vijf filialen die elk via één tunnel binnenkomen. Eén pad, één route. Een protocol voegt daar alleen bewegende delen toe. Zie Hoofdkantoor met vijf filialen.

Waar het in de tool zit

Het onderdeel heet Routing (OSPF, BGP, policy). Het staat standaard uit en alleen de rol Core router zet het aan; in een site schakel je het dus per router in via Instellen bij dat apparaat.

Wat je invult:

• Loopback/router-id. Vul hier een /32-adres in, bijvoorbeeld 10.255.0.1. De tool maakt daar een bridge lo met protocol-mode=none van en zet dat adres erop. Dat is het adres waaraan je deze router herkent in elke logregel en elke buurtabel, en het blijft bestaan als een interface uitvalt. Geef elke router er een, oplopend.
• OSPFv2 aanzetten.
• Areas. Er staat er al een: backbone met area-id 0.0.0.0. Per area kun je het type op default, stub of nssa zetten.
• Interface-templates. Per regel: in welke area, welke interface (de lijst bevat ook je tunnels), of een netwerk in plaats van een interface, de cost, of de interface passief is, en of MD5-authenticatie aan staat.
• Redistribueren, standaard connected, en of deze router een standaardroute adverteert.

Wat het script maakt

/routing ospf instance
add name=ospf-v2 version=2 router-id=10.255.0.1 redistribute=connected disabled=no
/routing ospf area
add name=backbone area-id=0.0.0.0 instance=ospf-v2 disabled=no
/routing ospf interface-template
add area=backbone interfaces=wg1 cost=10 type=broadcast auth=md5 auth-key=... auth-id=1 disabled=no

Meer niet. Eén instantie, de areas die je opgaf, en een template per regel.

Areas, zonder plechtigheid

Areas bestaan om te voorkomen dat elke router alles van elke andere router hoort. Bij tien routers is dat geen probleem, dus:

• Tot ongeveer vijftig routers: alles in area 0. Eén area, klaar. Dat is geen luiheid, dat is het juiste antwoord voor een netwerk van deze omvang.
• Heeft een vestiging intern meerdere routers, geef die vestiging dan een eigen area (0.0.0.1, 0.0.0.2) en laat alleen de vestigingsrouter in area 0 meedoen. De rest van het netwerk hoort dan één samenvatting in plaats van elk intern netwerk.
• Stub is bruikbaar voor een vestiging die alleen een standaardroute nodig heeft en niets van de buitenwereld hoeft te weten. De tool zet het type, maar biedt geen veld voor de kosten van de standaardroute of voor het samenvatten van een area. Dat doe je met de hand.

Het eerlijke deel

De tool genereert OSPF, maar hij bouwt geen OSPF-ontwerp. Dit is wat hij niet doet:

Die tweede regel is de belangrijkste van dit hoofdstuk. WireGuard stuurt alleen door wat in de allowed-address staat, en OSPF-hellos gaan naar multicastadres 224.0.0.5. De tunnel die de tool maakt zet het adres van de overkant en de netwerken erachter in de allowed-address, maar geen multicast. Het gevolg: de tunnel werkt, ping werkt, en OSPF komt nooit verder dan Down. Voeg 224.0.0.5/32 aan beide kanten toe, of gebruik voor de OSPF-koppeling een GRE-tunnel, die multicast gewoon draagt.

MTU, de tweede stille oorzaak

OSPF wisselt bij het opbouwen van een buurrelatie een beschrijving van zijn database uit, en daarbij vergelijken beide kanten hun MTU. Verschilt die, dan blijven de buren steken in Exstart of Exchange en komen ze nooit in Full. Dat is precies de fout die de MTU-controles van de tool voor bekabelde verbindingen melden: de twee kanten van een kabel hebben een andere MTU. Voor tunnels doet de tool die controle niet, dus controleer daar zelf dat de MTU aan beide kanten gelijk is.

Een werkbare opzet

1. Geef elke router een loopback: 10.255.0.1, .2, .3, en zo door. Dat wordt meteen zijn router-id.
2. Leg de tunnels zoals je ze nodig hebt en laat Routes naar de andere locatie uit: OSPF gaat die routes leveren, en een statische route ernaast is een route die blijft staan als OSPF hem intrekt.
3. Zet op elke router de routing-module aan, met één area backbone.
4. Voeg per router een interface-template toe voor elke tunnel, in area backbone, met MD5-authenticatie aan en overal dezelfde sleutel.
5. Voeg per router ook een template toe voor de interne netwerken, met passief aan. Passief betekent: het netwerk wordt geadverteerd, maar er worden geen buren gezocht. Je wilt geen OSPF-hellos op een werkplek-VLAN.
6. Laat redistribueren op connected staan, maar bedenk wat dat publiceert. Op een router met een WAN-interface hoort het transfernetwerk van je provider daar ook bij.
7. Laat één router, meestal het hoofdkantoor, de standaardroute adverteren met if-installed. Dan verdwijnt die route vanzelf als dat kantoor zijn internet kwijt is.

Controleren

• /routing ospf neighbor print: elke buur hoort in Full te staan. Blijft er een op Exstart hangen, kijk dan naar de MTU. Staat er helemaal niets, kijk dan naar multicast in de allowed-address.
• /ip route print where ospf: staan de netwerken van de andere vestigingen erin, met het juiste tunnelinterface als gateway?
• Trek het primaire pad los en kijk of het verkeer binnen enkele seconden over het reservepad gaat. Een tweede pad dat je nooit getest hebt, is geen tweede pad.

Verder lezen: OSPF, Statische routes en Hoofdkantoor met vijf filialen.