OSPF multi-sites sur MikroTik#

Table des matières#

1. Le problème résolu
2. Architecture retenue
3. Plan d'adressage
4. Concepts OSPF utiles
5. Configuration de référence par routeur
6. Cohabitation OSPF / policy-routing
7. Filtrage inter-sites
8. Différences de syntaxe v6 / v7
9. Pièges rencontrés en production
10. Procédure de diagnostic
11. Checklist de déploiement

1. Le problème résolu#

Avant#

Cinq routeurs reliés par des tunnels VPN, avec du policy-routing statique : des address-lists (via_lsmc, via_plage, via_fbxlsmab) associées à des règles mangle et des routes pointant sur les adresses de tunnel.

Trois défauts structurels :

• Aucune bascule automatique. Une address-list ne sait pas qu'un tunnel est tombé. Des scripts check_vpn_* en RouterOS Script tentaient de compenser en pingant et réécrivant les routes — fragiles, dépendants de numéros de règles codés en dur, et cassés à chaque changement de config.
• Adresses de tunnel comme gateway. gateway=10.16.0.72 est l'adresse portée par l'interface du tunnel. Tunnel coupé → adresse disparue → route morte, même si un autre chemin existe.
• NAT partout. Chaque site masquait la source, donc les ACL distantes ne voyaient jamais la vraie origine, et le transit site-à-site était impossible.

Après#

OSPF dans la table main. Chaque routeur annonce ses LAN, apprend ceux des autres, et recalcule automatiquement en cas de coupure. Le policy-routing est conservé uniquement pour ce à quoi il sert vraiment : choisir par quelle sortie internet passe tel ou tel trafic.

Distinction fondamentale à retenir :

Le policy-routing n'a de sens que quand plusieurs chemins se disputent la même destination. Pour des préfixes RFC1918 distincts, main suffit — et OSPF le remplit tout seul.

2. Architecture retenue#

Double hub, spokes bi-attachés. Deux routeurs pivots (mappy à la maison, jesapelrout sur un VPS OVH), et trois sites distants reliés aux deux.

                mappy ═══════════ jesapelrout
              (10.255.0.1)  20   (10.255.0.2)
               ╱    │    ╲      ╱     │     ╲
          10 ╱      │10    ╲10 ╱50    │50     ╲50
           ╱        │        ╳        │         ╲
     minimappy    lsmc    lsmab (chaque spoke a 2 liens)
    (10.255.0.3) (.0.4)  (.0.5)

Chaque site distant a deux tunnels : un vers mappy (coût 10, primaire), un vers jesapelrout (coût 50, secours). Le lien entre les deux hubs coûte 20.

Vérification des coûts#

Limite structurelle : si mappy tombe, son LAN tombe avec lui. La redondance protège les chemins, pas les sites eux-mêmes.

Diversité des points d'entrée#

Volontaire et à conserver : lsmc et lsmab montent leurs tunnels vers l'IP OVH FTTH de mappy (109.X.X.X), minimappy vers l'IP Freebox (82.X.X.X). Une panne d'un lien WAN maison ne coupe pas tous les tunnels d'un coup.

Conséquence à connaître : rebooter la session PPPoE OVH coupe les tunnels de lsmc et lsmab. Avec keepalive-timeout=disabled côté client, ils ne s'en rendent pas compte et ne rappellent pas — il faut forcer la reconnexion depuis le site distant (accessible via jesapelrout).

3. Plan d'adressage#

Principe : séparer les plages par fonction#

Cette séparation est ce qui permet un matching par networks= avec un coût distinct par catégorie de lien, sans énumérer les interfaces.

Attribution#

Loopbacks#

LAN annoncés#

4. Concepts OSPF utiles#

États d'adjacence#

Une adjacence traverse plusieurs états. Savoir les lire fait gagner du temps :

Coût et sélection de chemin#

Le coût total d'un chemin est la somme des coûts des interfaces traversées. OSPF choisit le plus faible. À coût égal, il installe plusieurs routes (ECMP, visible avec le flag + dans /ip route print).

Distance administrative : les routes OSPF ont 110, les statiques 1. Une statique reste donc prioritaire — pratique pour déployer OSPF en parallèle sans rien changer, puis basculer en désactivant les statiques.

Le router-id et pourquoi un loopback#

Le router-id identifie le routeur dans la base OSPF. S'il est pris sur une interface qui peut disparaître (un tunnel), l'identité change en cours de route et l'adjacence se recalcule inutilement. Un loopback /32 ne tombe jamais.

Il sert aussi de cible stable : 10.255.0.4 est joignable par n'importe quel chemin OSPF vers lsmc, contrairement à 10.99.0.10 qui n'existe que tant que le tunnel direct vit. C'est le point clé de la section 6.

Interfaces passives#

Une interface passive est annoncée dans la base OSPF mais n'émet pas de hellos et n'accepte pas de voisins. C'est ce qu'on veut pour les LAN : leur préfixe est publié aux autres routeurs, mais aucun poste du LAN ne peut établir d'adjacence.

5. Configuration de référence par routeur#

Clé partagée sur tout le domaine : Gx7-Mesh26-Kd9p Contrainte : 16 caractères maximum (limite RouterOS 6, qui s'impose à tous puisque la clé doit être identique des deux côtés d'un lien).

mappy — hub principal (v7)#

/interface bridge add name=loopback protocol-mode=none
/ip address add address=10.255.0.1/32 interface=loopback

/routing ospf instance
add name=ospf1 version=2 router-id=10.255.0.1 originate-default=never disabled=no

/routing ospf area
add name=backbone instance=ospf1 area-id=0.0.0.0

/routing ospf interface-template
add area=backbone networks=10.99.0.0/24 type=ptp cost=10 auth=md5 auth-id=1 auth-key="Gx7-Mesh26-Kd9p"
add area=backbone networks=10.99.2.0/24 type=ptp cost=20 auth=md5 auth-id=1 auth-key="Gx7-Mesh26-Kd9p"
add area=backbone networks=192.168.3.0/24 passive
add area=backbone networks=10.2.0.0/24 passive
add area=backbone networks=10.16.0.0/24 passive
add area=backbone networks=10.255.0.1/32 passive

/ip firewall filter add chain=input action=accept protocol=ospf comment="OSPF"

Matching par networks= et non interfaces= : les tunnels côté serveur PPP sont des interfaces dynamiques (<l2tp-mktlsmc>, <pptp-mktlsm>) dont le nom change à chaque reconnexion. Le matching par adresse contourne le problème.

jesapelrout — hub de secours (v7)#

/interface bridge add name=loopback protocol-mode=none
/ip address add address=10.255.0.2/32 interface=loopback

/routing ospf instance
add name=ospf1 version=2 router-id=10.255.0.2 originate-default=never disabled=no

/routing ospf area
add name=backbone instance=ospf1 area-id=0.0.0.0

/routing ospf interface-template
add area=backbone networks=10.99.1.0/24 type=ptp cost=50 auth=md5 auth-id=1 auth-key="Gx7-Mesh26-Kd9p"
add area=backbone networks=10.99.2.0/24 type=ptp cost=20 auth=md5 auth-id=1 auth-key="Gx7-Mesh26-Kd9p"
add area=backbone networks=10.100.0.0/24 passive
add area=backbone networks=10.255.0.2/32 passive

/ip firewall filter add chain=input action=accept protocol=ospf comment="OSPF"

minimappy — spoke (v7)#

Ses tunnels sont des clients à noms fixes → matching par interface possible et plus lisible.

/interface bridge add name=loopback protocol-mode=none
/ip address add address=10.255.0.3/32 interface=loopback

/routing ospf instance
add name=ospf1 version=2 router-id=10.255.0.3 originate-default=never disabled=no

/routing ospf area
add name=backbone instance=ospf1 area-id=0.0.0.0

/routing ospf interface-template
add area=backbone interfaces=mappy2 type=ptp cost=10 auth=md5 auth-id=1 auth-key="Gx7-Mesh26-Kd9p"
add area=backbone interfaces=jesappelrout type=ptp cost=50 auth=md5 auth-id=1 auth-key="Gx7-Mesh26-Kd9p"
add area=backbone networks=192.168.22.0/24 passive
add area=backbone networks=10.255.0.3/32 passive

/ip firewall filter add chain=input action=accept protocol=ospf comment="OSPF"

lsmc — spoke (v6.49)#

/interface bridge add name=loopback
/ip address add address=10.255.0.4/32 interface=loopback

/routing ospf instance
set default router-id=10.255.0.4

/routing ospf network
add network=10.99.0.0/24 area=backbone
add network=10.99.1.0/24 area=backbone
add network=192.168.43.0/24 area=backbone
add network=10.255.0.4/32 area=backbone

/routing ospf interface
add interface=mapy network-type=point-to-point cost=10 \
    authentication=md5 authentication-key="Gx7-Mesh26-Kd9p" authentication-key-id=1
add interface=jsapelrout network-type=point-to-point cost=50 \
    authentication=md5 authentication-key="Gx7-Mesh26-Kd9p" authentication-key-id=1
add interface=bridge passive=yes

/ip firewall filter add chain=input action=accept protocol=ospf comment="OSPF"

Ne pas ajouter redistribute-connected=no redistribute-static=no : ces paramètres existent mais la ligne échoue si on y ajoute redistribute-default, qui s'appelle en réalité distribute-default et vaut déjà never par défaut. Poser seulement le router-id suffit.

lsmab — spoke (v6.48)#

Identique à lsmc, avec router-id=10.255.0.5, réseau 192.168.40.0/24, et les interfaces douvres (coût 10) et jesapelrout (coût 50).

6. Cohabitation OSPF / policy-routing#

C'est la partie la plus subtile, et celle qui a causé le plus de pannes.

Ce que fait quoi#

• OSPF route les LAN internes entre sites, dans main.
• Le policy-routing choisit par quelle sortie internet part un flux donné. Il reste indispensable pour : via_ftth (OVH), via_free (Freebox), via_hivane, via_livebox, et les sorties internet déportées — par exemple faire sortir certaines IP publiques par la Livebox de lsmc.

La règle d'or : gateway = loopback, jamais IP de tunnel#

Une route de policy-routing vers un site distant doit pointer sur son loopback, pas sur l'adresse de son tunnel :

# MAUVAIS — casse si le tunnel direct tombe
/ip route add dst-address=0.0.0.0/0 gateway=10.99.0.10 routing-table=via_lsmc

# BON — résilient, suit OSPF
/ip route add dst-address=0.0.0.0/0 gateway=10.255.0.4 routing-table=via_lsmc \
    check-gateway=none target-scope=30

Trois paramètres, trois raisons :

• gateway=10.255.0.4 : le loopback est annoncé en OSPF et joignable par n'importe quel chemin. L'adresse de tunnel 10.99.0.10 disparaît avec son interface.
• target-scope=30 : sans ça, la résolution récursive échoue. Les routes OSPF ont un scope de 30 ; une route dont le target-scope est 10 (défaut) refuse de résoudre sa gateway via une route de scope 30. Symptôme : route I (inactive) avec immediate-gw="".
• check-gateway=none : avec OSPF derrière, le check-gateway est nuisible. Pendant les ~40 s de recalcul après une coupure, le ping échoue et RouterOS désactive la route — qui ne se réactive pas forcément ensuite. OSPF gère déjà la disponibilité.

Table de référence#

Address-lists : séparer LAN et sorties internet#

Une même liste peut contenir deux choses de nature différente. Exemple avec via_lsmc :

Le NAT masquerade dst-address-list=via_lsmc reste nécessaire pour les IP publiques : le trafic sort par l'IP publique de lsmc, il faut masquer la source.

FastTrack : incompatible#

Un paquet fasttracké contourne le mangle prerouting. Sur une infrastructure qui dépend du mark-routing, cela court-circuite tout le policy-routing dès la deuxième trame d'une connexion.

La règle fasttrack-connection doit rester désactivée. Sur un CCR1036, le coût CPU du traitement complet est négligeable.

7. Filtrage inter-sites#

Objectif : depuis un LAN distant, on atteint les routeurs mais pas les machines du LAN maison. Le sens maison → distant reste ouvert.

À poser sur les deux hubs (sinon contournement par le second).

/ip firewall address-list
add list=LAN_MAISON address=192.168.3.0/24
add list=LAN_MAISON address=192.168.1.0/24
add list=LAN_MAISON address=10.2.0.0/24
add list=ROUTEURS_ADMIN address=192.168.3.252
add list=LAN_DISTANTS address=192.168.40.0/24
add list=LAN_DISTANTS address=192.168.43.0/24
add list=LAN_DISTANTS address=192.168.22.0/24
add list=LAN_DISTANTS address=10.100.0.0/24

Trois règles, dans cet ordre, placées juste après le drop invalid :

/ip firewall filter
add chain=forward action=accept connection-state=established,related \
    comment="Maison<->distants: reponses OK"
add chain=forward action=accept src-address-list=LAN_DISTANTS \
    dst-address-list=ROUTEURS_ADMIN comment="Distants -> admin routeurs OK"
add chain=forward action=drop src-address-list=LAN_DISTANTS \
    dst-address-list=LAN_MAISON comment="Distants -> LAN maison DROP"

Puis les déplacer par numéro (/ip firewall filter move), car place-before avec un [find] qui matche plusieurs règles échoue avec no such item.

Logique : la règle 1 laisse revenir ce que la maison a initié (sinon maison→distant serait cassé). La règle 2 ouvre l'exception admin. La règle 3 jette tout le reste.

Attention : ne mettre dans ROUTEURS_ADMIN que des adresses routées. 192.168.1.250 (mappy côté radio) est inutile ici puisque 192.168.1.0/24 n'est pas annoncé en OSPF — les distants ne peuvent pas l'atteindre de toute façon.

8. Différences de syntaxe v6 / v7#

La refonte du routage en v7 a tout changé. Vérifier avec add ? dans le menu concerné : la documentation en ligne est parfois en retard sur la build installée.

Instance#

Interfaces#

/routing ospf interface devient lecture seule en v7 : il montre les interfaces matchées par les templates.

Paramètres « flag »#

En v7, certains paramètres refusent une valeur. passive=yes renvoie expected end of command. Écrire simplement passive.

Le matcher networks#

Il teste le préfixe réseau de l'adresse d'interface. Sur une liaison point-à-point, cela correspond à l'adresse de l'extrémité distante. Les deux bouts d'un tunnel doivent donc tomber dans le même préfixe déclaré.

9. Pièges rencontrés en production#

9.1 Les templates référencent l'area par identifiant interne (v7)#

Le piège le plus coûteux. Un interface-template stocke l'area par son identifiant interne (*4), pas par son nom. Supprimer puis recréer l'area laisse les templates pointer sur un objet mort.

Symptôme :

0 I ;;; ospf area not active
    area=*4 networks=10.99.0.0/24 type=ptp …

Conséquence en cascade : zéro interface OSPF → zéro voisin → zéro route apprise → les gateways loopback des routes policy deviennent irrésolubles → effondrement de tout le routage inter-sites et des sorties internet déportées. Quatre symptômes apparemment sans rapport, une seule cause.

Correction :

/routing ospf interface-template set [find] area=backbone

9.2 Relancer un add après une erreur crée des doublons#

Une commande add qui échoue sur un paramètre laisse parfois une entrée partielle, et la relance en crée une seconde. Résultat observé : 19 templates au lieu de 6, et 5 instances OSPF identiques.

Effet : le router-LSA devient incohérent et les LAN passifs cessent d'être annoncés. Symptôme caractéristique — adjacence Full mais aucune route installée côté distant, et lsa print detail sans les préfixes LAN dans le corps.

Réflexe : après toute erreur, faire print avant de retaper. Corriger par remove <numéro>, jamais par remove [find] sans critère (qui coupe l'adjacence).

9.3 Changer un /ppp secret ne renumérote pas une session vivante#

Les adresses sont négociées à la connexion. Avec keepalive-timeout=disabled, un tunnel peut rester des heures avec ses anciennes adresses. Il faut forcer la renégociation :

/ppp active remove [find name="mktlsm"]

9.4 Les ACL de management doivent être étendues, jamais remplacées#

Réadresser les tunnels avant d'élargir les ACL SSH/API/SNMP verrouille l'accès aux routeurs distants : la nouvelle plage source n'est autorisée nulle part.

Ordre correct, site par site :

1. Étendre les ACL (garder anciennes et nouvelles plages)
2. Vérifier l'accès
3. Seulement alors, réadresser

Garder le chevauchement jusqu'à la fin de la migration. C'est lui qui rend l'opération réversible à chaud.

9.5 La clé MD5 est masquée en v7#

auth-key n'apparaît jamais en print detail, même sans hide-sensitive. Pour la lire :

:put [/routing ospf interface-template get [find networks="10.99.0.0/24"] auth-key]

En v6, elle s'affiche en clair dans /routing ospf interface print — pratique pour repérer un placeholder oublié. Un <secret> laissé littéralement monte une adjacence (les deux côtés ont la même chaîne) mais n'apporte aucune sécurité.

9.6 Un ping depuis le routeur ne teste pas le policy-routing#

/ping x.x.x.x part en chain=output et ne traverse pas le mangle prerouting. Il ne valide donc pas les règles de marquage.

Pour tester une table spécifique :

/ping 8.8.8.8 routing-table=via_ftth

(traceroute n'accepte pas ce paramètre.)

9.7 Le NAT sur les interfaces LAN casse le routage symétrique#

Les règles masquerade out-interface=<bridge|RESEAU> masquent la source de tout ce qui entre dans un LAN. Tant qu'elles existent, le site distant ne voit jamais la vraie origine, et les ACL basées sur les préfixes réels ne peuvent pas fonctionner.

9.8 Les connexions établies gardent leur décision de routage#

Le conntrack fige le chemin à la première trame. Après tout changement de marquage ou de route :

/ip firewall connection remove [find dst-address~"<IP>"]

Et arrêter le ping en cours avant de purger : un ping en boucle recrée l'entrée immédiatement avec l'ancienne décision.

9.9 Une table de routage vide jette les paquets#

Un paquet marqué vers une table qui ne contient aucune route n'est pas renvoyé vers main — il est jeté. Après une migration v6→v7, les tables survivent mais leurs routes peuvent avoir disparu.

9.10 Le symptôme peut être externe#

Un repl-packets=0 dans le conntrack peut simplement signifier que la destination ne répond pas — pare-feu distant, service arrêté. Vérifier depuis un autre point de sortie avant de suspecter sa propre configuration.

10. Procédure de diagnostic#

À suivre dans l'ordre. Ne pas modifier avant d'avoir identifié l'étage en panne.

Étage 1 — les tunnels#

/ppp active print

Les trois spokes doivent apparaître avec leurs adresses 10.99.x. Si absents : problème de transport, pas d'OSPF.

Étage 2 — l'instance et l'area#

/routing ospf instance print
/routing ospf area print detail
/routing ospf interface-template print

Chercher : instance unique et active, area backbone rattachée à l'instance, templates sans flag I ni commentaire « ospf area not active ».

Étage 3 — les adjacences#

/routing ospf neighbor print

Nombre attendu : 4 sur chaque hub, 2 sur chaque spoke. Tous en Full. Bloqué en Init → firewall. Bloqué en ExStart → clé MD5 divergente.

Étage 4 — les routes apprises#

/ip route print where ospf

Doit contenir tous les LAN distants et les loopbacks 10.255.0.x. Si l'adjacence est Full mais qu'il manque des préfixes :

/routing ospf lsa print detail where originator=<router-id>

Le corps du LSA doit lister les préfixes en type=stub. S'ils manquent, le problème est l'annonce côté émetteur (templates dupliqués, LAN non déclaré).

Étage 5 — le policy-routing#

/ip firewall mangle print stats where comment="<la regle>"   # le compteur bouge ?
/ip firewall connection print detail where dst-address~"<IP>" # quelle decision ?
/ip route print detail where routing-table=<table>            # route active ?
/tool torch interface=<WAN attendu> dst-address="<IP>"        # sort par ou ?

Lecture croisée :

11. Checklist de déploiement#

Pour ajouter un site ou refaire une migration.

Avant#

• [ ] /export compact file=avant-<date> sur chaque routeur, récupéré hors du routeur
• [ ] Vérifier les types de tunnels (WireGuard nécessite 224.0.0.5/32 dans allowed-address)
• [ ] Prévoir un second chemin d'accès à chaque routeur

Ordre des opérations#

• [ ] 1. Étendre les ACL de management (SSH, API, SNMP) — ajouter, ne pas remplacer
• [ ] 2. Vérifier l'accès à chaque routeur après extension
• [ ] 3. Créer les loopbacks
• [ ] 4. Réadresser les /ppp secret puis forcer la renégociation, un tunnel à la fois
• [ ] 5. Configurer OSPF sur le hub principal
• [ ] 6. Configurer OSPF sur un site pilote — vérifier Full avant de continuer
• [ ] 7. Configurer le second hub (indispensable au secours)
• [ ] 8. Enchaîner les autres spokes, un par un, en vérifiant Full à chaque fois
• [ ] 9. Poser le filtrage inter-sites sur les deux hubs
• [ ] 10. Repointer les routes policy sur les loopbacks (target-scope=30, check-gateway=none)
• [ ] 11. Désactiver les NAT et statiques, site par site, avec test d'accès immédiat
• [ ] 12. /export compact file=stable-<date> sur les cinq

Règles permanentes#

• [ ] originate-default=never / distribute-default=never partout, sans exception — un site qui redistribue sa route par défaut casse tout l'arbitrage multi-WAN
• [ ] FastTrack désactivé
• [ ] Une fenêtre = un site
• [ ] Après une erreur de commande : print avant de retaper
• [ ] Toute modification de /ppp secret → mettre à jour les entrées DNS .tun

Vérification finale#

# sur chaque routeur
/routing ospf neighbor print          # tous Full
/ip route print where ospf            # tous les LAN distants
# depuis un poste
ping <LAN de chaque site>
# test de bascule sur un spoke
/interface <type>-client disable <tunnel primaire>
# apres ~40s, verifier le reroutage puis reactiver