Nach meinem Umzug auf OpenWRT kam ich in den Genuss, das bei einem Reconnect nicht jeder Dienst neu gestartet wird. Leider hatte dieses „normale“ verhalten dazu geführt, das BIRD nicht mehr alle Routen propagiert hat. Das Problem: Es tauchten unvermittelt meldungen in folgendem Format im Syslog auf:

KRT: Received route 192.168.100.128/25 with strange next-hop 192.168.100.130

Zu Meldungen dieser Art kommt es wenn eine Routing-Regel aus der Kernel-Routing Tabelle gelernt wird, die ein direkt angeschlossenes Netz über einen entfernten Gateway schleifen will. Typisch für P-T-P und P-T-MP Verbindung wie OpenVPN oder PPPD. Interessanterweise stört BIRD das nur bei neu erlernten Routen. Ist die Route beim Dienst-Start schon in der Routing-Tabelle gibt es keine Probleme. Die Meldung kann man Unterdrücken, was jedoch stört ist die Tatsache, dass die entsprechende Routing-Rule nicht an die anderen Protokolle übertragen wird. Die möglichen Lösungen:

• Eine statische Route über das Interface definieren und via Filter verhindern, dass diese Route zurück in den Kernel geschrieben wird.
• BIRD nach einem Reconnect neu starten.
• Diverse Protokolle bieten es an Netzwerke zu propagieren, die sie eigentlich nicht kennen. Unter OSPF kann man z.B. ein stubnet Konfigurieren. Dies hat den Charme, dass man der Route gleich entsprechende Kosten auferlegen kann. Die Route wird nur an die OSPF-Neighbors weitergereicht nicht an irgendein ein anderes Protokoll in der BIRD Instanz.

Welche der Lösungen man wählt hängt wohl vom Einsatzgebiet ab, ich hab mich für letztere entscheiden.