Wir betreiben zwei Supernodes, die unser Freifunk-Netz über GRE-Tunnel an das Backbone des Freifunk Rheinland e.V. (FFRL) anbinden (sollen).
Für IPv4 funktioniert das Netz bereits. Nur auf IPv6 funktioniert die Rückroute für die Pakete nicht. Ein Datenpaket kommt zwar am Zielhost an, doch ein Router des FFRL 2a03:2260::5 findet die Rückroute nicht.
Anfangs hatte ich die Ursache darin vermutet, dass sich die bird6 auf den GRE-Tunneln nicht miteinander verbinden.
# birdc6 show protocol ... gre_dus_a BGP master start 21:38:20 Connect ...
Nach langem Suchen und fand ich die Ursache mehr oder weniger durch Zufall. Die eingehenden Pakete hatten ein HOP=64, die ausgehenden einen HOP=1.
Durch einfügen der Zeile multihop 64; im Uplink Template und Restart des bird6 konnten sich die bird6 dann verbinden.
template bgp uplink {
local as 65201;
import where is_default();
export filter hostroute;
gateway recursive;
multihop 64;
}
Damit verbinden sich die bird6. – Endlich.
# birdc6 show protocol ... gre_dus_a BGP master up 21:42:11 Established ...
Ein Test mit ping ergibt das minimale Hop Limit = 10 auf den GRE-Tunnel, damit alle bird6 sich verbinden.
for IP in $(ip a | grep -A 4 ': gre' | grep 'inet6' | sed 's#.* inet6 ##; s#2/64.*#1#'); do ping -6 -t 4 -c1 $IP ; done
Nun Frage ich mich, wieso auf den GRE-Tunneln mehr als ein HOP entsteht. Eigentlich nicht möglich. Aber ein traceroute zeigt:
# traceroute -6 2a03:2260:0:520::1 traceroute to 2a03:2260:0:520::1 (2a03:2260:0:520::1), 30 hops max, 80 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 2a03:2260:0:520::1 (2a03:2260:0:520::1) 7.839 ms 7.947 ms 7.808 ms
Leider war dies nur ein erster Schritt in Richtung einer Lösung, denn der Router 2a03:2260::5 findet den Rückweg trotzdem nicht.