Der Flattermann und das Routing

Nach dem Fiasko am Vortag war es mit Ubuntu LTS ein Selbstläufer …

Was mit Debian Jessie noch ein Fiasko war, tat, wie erwartet, mit Ubuntu 14.04 LTS wie erwartet: »Notice: Finished catalog run in 544.02 seconds.« Okay, ein Reboot war noch notwendig, um das »rechte« batman_adv-Kernelmodul zu laden, denn wir nutzen, mal wieder ;), eine gut abgehangene Version …

Lahmstes Gate­way wo gibt.
Lahmstes Gate­way wo gibt.
Kurzum: ich habe nun einen FSC Futro S550 als (Gluon-) Gateway konfiguriert. Und nachdem ich ein lange bestehendes Syntax-Problem in der fastd-Konfiguration der Backbone-Peers untereinander erkannt, und gelöst, hatte, verband sich mein, hinter einem VDSL 22/2,5-Anschluß hängender, Futro auch mit unseren anderen Gateways. Ich habe absichtlich eine seeehr niedrige Trafficstufe – 2048KBit down vs. 512KBit up – eingestellt, um genau das, was derzeit passiert, zu vermeiden :(

Wie jetzt, 5 Knoten wählen mein (Test-) Gate­way?!
Wie jetzt, 5 Knoten wählen mein (Test-) Gate­way?!
Denn, wie der Meshviewer zeigt, verwenden andere, ebenfalls hinter DSL-Anschlüssen stehende Knoten, mein Test-Gateway als (IPv4-) Default-Gateway.

WTF? Nicht nur, daß es latenzmäßiger Müll ist, auch von den konfigurierten Bandbreiten ist es eher suboptimal. Wieso macht batman_adv das? Wieso wird ein batman_adv-Gateway, zu dem keine direkte Verbindung besteht, als (IPv4-) Gateway ausgewählt? An dieser Stelle jedenfalls hat sich der Flattermann ganz gehörig verflogen.

Und ich muß zugeben, damit hatte ich auch nicht gerechnet: das Test-Gateway befindet sich in einem RFC1918-Netz, ist direkt also (für fastd-Verbindungen) gar nicht zu erreichen — aber, klar, über’s Mesh natürlich schon … Daß mein Test-Gateway aller­dings, wie leider die meisten unserer Gateways, nicht in der Statistik als solches auftaucht, ist dann nur noch eine Randbemerkung wert.