Moin,
wir haben im Nordwest-Netz mittlerweile massiven Overhead, der Traffic der Supernodes liegt bei 10-15 TB / Monat. Bisher haben wir die Supernodes per Tinc verbunden und darüber ebenso Batman gesprochen.
Nun stellte sich uns die Frage, wie andere Communities das Problem lösen. Nach der Lektüre einiger Dokumentation wird wohl von manchen iBGP eingesetzt, aber letztlich erschließt sich nich, ob die Verbindungen zwischen den Supernodes dann auch per fastd laufen.
Unsere 3 Gateways kommunizieren direkt via fastd untereinander. Tinc an sich hat ja intern eine art Mesh Protokoll und darüber nochmal BATMAN_adv zu machen ist ja doppelt gemoppelt.
Der FFRL benutzen glaube ich GRE Tunnel und sprechen darauf iBGP.
Wir haben in Münster vor einiger Zeit auf BGP GRE umgestellt, um die CPU-Auslastung der Gateways zu senken.
@MPW
Mit GRE-Tunneln dazwischen?
An die BGP-Experten: Lässt sich auf allen Supernodes dann derselbe IPv6-Prefix (Public sowie ULA) announcen?
Ja natürlich. Hab wohl falsch im Buchstabensalat geangelt.
Gemeint ist hierbei GRETAP (Layer2) und iBGP, nicht GRE…
Wo liegt der Vorteil im Vergleich zu GRE?
GRE ist ne groutete Verbindung im IP Layer, GRETAP ist Layer2 (alle Pakete die Du links reinpustest kommen unbewertet rechts wieder raus)
Ja, klar - welchen Vorteil hat denn Layer2, wenn ihr zwischen den Supernodes eh routet?
BTW, laut http://canonversteher.de/sites/canonversteher.de/files/Freifunk/FF-RL-supernodes.pdf habt ihr im Ruhrgebiet auch noch Batman zwischen den Supernodes - ist das mittlerweile obsolet?
In der Hauptdomäne Ruhrgebiet:
Jeder Server, egal welche Aufgabe er hat, bekommt so automatisch sämtliche Routen, egal ob vom ICVPN Gateway in entfernte Communities oder auch den GRE Gateways in die Netze der Subdomänen.
Da jede Subdomäne mit mehreren GRE Tunneln angebunden ist, werden Pakete von und zu anderen Netzen ebenfalls dynamisch über die unterschiedlichen Wege geroutet (wenn mittlerweile auch priorisiert, um bessere Wege zu erzeugen).
In anderen Hauptdomänen bpsw. Albufer und auch in Subdomänen des Ruhrgebiets wurden die fastd Backbone Instanzen (Methode „null“) gegen GRETAP ausgetauscht. Ist im laufenden Betrieb von der Methodik her 1:1 identisch, ob es dadurch schneller wird kann ich in Ermangelung von Messwerten nicht sagen.
Um auf das ursprüngliche Thema zurück zu kommen, wir haben den Traffic und das Grundrauschen im Ruhrgebiet nur dadurch in den Griff bekommen können indem wir GRE angebundene Subnetze erstellt haben. Diese sind ausschließlich bgp geroutet und haben alle eigene IP Subnetze, sowohl für IPv4 als auch für IPv6.
Die Zahlen auf den Maps sind Augenwischerei, wir haben zwar über 2.000 Router online, aber in getrennten Netzen. Die Daten werden lediglich für die Maps dann wieder zusammengeführt.
Hmm. GRE hat eine MTU von max. 1462, welche MTU fahrt Ihr bei fastd? Die GRETAPs habt Ihr dann einfach dem batX hinzugefügt? Sollte zumindest weniger CPU-Overhead sein als via fastd.
IIRC fragmentiert batman_adv ja die von WiFi kommenden Pakete, sodaß jene mit 1500+overhead durch die fastd-Röhre passen. Da wir bislang einen 1500er Exit fahren, ggf. aber Teile des Netzes über FFRL exiten lassen werden (MTU der GRE-Tunnel: 1400), macht es dann Sinn, von Exit aus die MTU für fastd zu setzen. damit keine MTU-Probleme auftreten (zwischen Clients & dem Internet)? Oder setzt batman_adv am Ende die Pakete wieder zu max. 1500er Frames zusammen, wenn sie batman_adv-Interfaces verlassen?
Forciere ich Fragmentierung in GRE (nopmtudisc) oder auch in OpenVPN, habe ich am Ende zwei ausgehende Pakete, dort wird also nicht reassembliert.
Nutzt Ihr die GRETAPs dann auch für iBGP oder grabt Ihr dafür separate GREs?
@CHRlS
Danke für deine Ausführungen. Bei uns kernelpanicen Supernodes, die mehr als ein Interface in bat0 haben, in regelmässigen Abständen. Habt/hattet ihr diese Probleme auch?
[quote=„bjo, post:12, topic:6888“]
Bei uns kernelpanicen Supernodes, die mehr als ein Interface in bat0 haben,[/quote]
Hatten wir auf alter i686-Installation. Alle neuen VMs sind x64 und entweder Debian Wheezy oder Ubunty Trusty, und dort klappt es zumindest mit 2 fastds (mit unterschiedlichen MTUs; BB ist schon auf 1400, der zu den Clients noch auf 1426).
Wir setzen bei uns ja bei fastD auf 1312, die GRE-Tunnel haben das auch.
Die Supernodes haben Debian 8.1
Welche Kernel und welche Batman-Version nutzt ihr denn?
3.2.0-4-amd64 bzw. 3.13.0-45-generic; batman 2013.4.0 (DKMS).
Ah ok. Damit hatten wir auch keine Probleme. Mit 3.16 und 2014.3 kommen die Panics regelmässig vor. Ein Update auf Kernel 4.1 mit 2015.0 führte dazu, dass eine Supernode generell nach 5 Minuten panicte 
Wir hatten das auf KVM. Allerdings keine echte Panic, so dass keine automatischer Neustart ausgelöst wurde, sondern einfach freezed.
Seit wir alles nur noch auf VMware haben, sind die Probleme nicht mehr existent.
Eine Subdomäne von uns (ebenfalls auf VMware) hat noch Abstürze, da tippe ich aktuell aber nicht auf den batman…
Das ist leider auf echten Kisten bei uns auch so. Da läuft die eine KVM Kiste noch stabiler…
Das würde ich ja mal testen wollen. Kann ja nicht sein das kvm schlechter läuft. warum auch … hypervisor ist hypervisor