Beim Aufbau des diac24.net-VPNs gab es hin- und wieder Punkte, an denen wir uns entscheiden mussten. Zum Beispiel mussten wir uns entscheiden, ob wir „numerierte” oder „unnumerierte” Tunnel verwenden. Numeriert bedeutet, dass jeder Tunnel sein eigenes /30er IP-Subnetz hat; unnumeriert bedeutet dass die Tunnel keine eigenen IPs haben sondern jeweils die „Haupt”-Adresse des Routers verwenden.
Die Entscheidung in dieser Angelegenheit wurde so ca. 2002 getroffen, als das VPN noch aus TroJan und mir bestand, und noch über OSPF statt BGP lief. Wir wollten nicht so viel Müll in unseren Routingtabellen und haben uns für unnumerierte Tunnel entschieden. Mittlerweile zweifle ich jedoch an dieser Entscheidung, und zwar aus diesen Gründen:
- Wenn man einen Tunnel zu jemandem hat, und der Tunnel ausfällt, dann ist der Router des Gegenübers nicht erreichbar, auch wenn es noch andere Verbindungen gibt. Denn während die Routen zu Netzen hinter dem Router des Gegenübers verschwinden, bleibt die Route zum Router des Partners erhalten - und zeigt ins Leere.
- Verschiedene Routingsoftware funktioniert mit unnumerierten Tunneln nicht richtig, insbesondere pimd». Das hat dann zu einer Reihe von Patches» geführt, aber nicht jeder hat die im Kernel...
Jedenfalls habe ich mich entschlossen, zwischen charon und dem SpaceBoyZ numerierte Tunnel auszuprobieren. Aber sehen wir uns erst mal an, wie das IPv4-Routing bisher funktioniert:
Auf den ersten Blick nichts besonderes. Was man im Bild allerdings nicht sieht, ist, dass das BGP-Peering über IPv6-Linklocals läuft. Also... woher nimmt der bgpd den Nexthop für IPv4? - Diese Frage hatte ich mir leider bisher noch nie gestellt. 15 Minuten und einige Verwunderung später kannte ich die Antwort:
Nachdem ich nämlich dem Tunnel ein eigenes Subnet verpasst hatte, bekam ich plötzlich keine IPv4-Routen mehr. Das Peering selbst war in Ordnung, an den IPv6-Linklocals hatte sich ja nichts geändert und ich bekam korrekt meine IPv6-Routen. Die Fehlersuche ergab, dass die Routen in sh ip bg ne SBZ received-routes ordnungsgemäss erschienen, es aber nicht nach sh ip bg ne SBZ routes schafften. Die Neighbor-Übersicht zeigte 0 accepted prefixes. Ein genauerer Blick in received-routes enttarnte das Übel:
Network Next Hop Metric LocPrf Weight Path 172.22.24.0/28 172.22.24.1 1 0 64624 i
Einige Sucherei und Fragerei in #quagga» später hatte ich dann als Antwort dass ich IPv4 und IPv6 über getrennte Peerings laufen lassen soll. Der damit verbundene erhöhte Konfigurationsaufwand passte mir allerdings nicht wirklich in den Kram. Ausserdem war das schöne an den IPv6-Peerings dass man die unangetastet lassen konnte, auch wenn sich am Tunnel etwas ändert.
Ungefähr eine halbe Stunde später war das Ergebnis dann dieser Patch». Die Änderung ist ziemlich minimal, anstatt einfach die Router-ID zu verwenden sucht der bgpd jetzt das Interface, über das das Peering geht, nach einer IP ab. Dadurch findet er die korrekte IP:
Zufrieden betrachtete ich meine nun wieder gefüllte IPv4-Routingtabelle:
Network Next Hop Metric LocPrf Weight Path 172.22.24.0/28 172.22.255.253 1 0 64624 i
Der Erfassungsbereich des Patches schliesst nicht nur numerierte Tunnel ein; prinzipiell sind alle Fälle betroffen, wo über IPv6 gepeert wird und bei denen die BGP Router-ID nicht dem Nexthop entspricht. (Wenn ich das korrekt verstanden habe gab es da beim c3d2 wohl auch mal Probleme auf cthulhu)
Der Patch ist an die quagga-Mailingliste submitted, aber Antwort habe ich noch keine bekommen. Mittlerweile existieren im diac24.net 2 numerierte Links: René <--> equinox <--> SpaceBoyZ. Das Ganze scheint stabil zu funktionieren.
René war nett und hat ein OpenWrt-Package für Quagga 0.99.6 gebastelt. Ich war fauler und hab nur eins für 0.98.6 gebaut. Downloadlinks:
- Quagga 0.99.6:
Patch»
bgpd-Binärpackage für OpenWrt» (lokal)»
Rest (quagga, vtysh, ...) für OpenWrt» (lokal)» - Quagga 0.98.6:
Patch»
bgpd-Binärpackage für OpenWrt»
(der Rest ist beim Standard-OpenWrt dabei)
Happy Patching!
