[Berlin-wireless] wie entstehen routen-loops

[onelektra]

hi marco -


> "synchronisieren" ist etwas unglücklich gewählt; obwohl es genau darum
> geht, eben um loops zu vermeiden, daß die router ihre Tabellen möglichst
> zeitnah den aktuellen HF-Wegen anpassen.  Doch eine zentrale Referenzquelle
> als Grundlage der routing-Entscheidung, die allen und zur selben Zeit zur
> Verfügung steht, gibt es nicht.

in der tat - der sinn und das ziel von olsrd ist nicht eine *einzige* 
routingtabelle zu haben die in jedem node des mesh absolut gleich ist. 
es genügt wenn die routinginformationen in einem lokalen bereich (in der 
aktuellen fisheye-version sind das drei hops) um einen node 
einigermassen korrekt ist - und das zeitnah, damit veränderungen 
rechtzeitig bekannt sind und es nicht in einem lokalen raum zu 
unstimmigkeiten - sprich: loops kommt

> 
> Um so mehr, als daß seit fisheye die Ausbreitung der link-quality info's
> länger dauert, stellen nodes ihr routing so verschieden schnell auf eine
> Änderung der HF-Wege neu ein.

über die lokale sicht der topologie hinaus ist es ok wenn die sicht dann 
  'fuzzy' wird. es ist für einen node in weissensee nicht relevant wie 
in kreuzberg 36 geroutet wird. der node muss nur wissen dass da noch 
jemand ist und dass er ihn erreichen kann wenn er seine pakete in eine 
bestimmte richtung schickt.

der node in weissensee mag den irrglauben haben den exakten pfad zu node 
xy in kreuzberg zu kennen - da wir aber kein source-routing machen stört 
das nicht weiter! jeder node schaut ohnehin in seine routingtabelle und 
trifft dann selbständig die entscheidung wo es lang geht. diese werden 
umso genauer und wichtiger je näher das paket seinem ziel kommt.
> 
> 
> 
>>* Bugs in OLSR
> 
> 
> Dazu mal eine Frage, nämlich nach dem Verbleib und Sinn der MPR (Multi-Point-Relay)
> Mechanik im olsrd.  


diese mechanik macht IMHO keinen sinn. es ist eine altlast, die wir bei 
gelegenheit mit olsrd 0.5.0 und höher unauffällig entsorgen können. 
ebenso wie die hysterese und einiges andere.

ich will das nicht noch einmal erklären - besser ist es sich die slides 
dazu vom 22C3 anzusehen www.scii.nl/~elektra


IMHO vom Konzept her gedacht, einerseits die Zahl der
> nodes zu reduzieren, die ihre Umgebung mit "über-Nachbar-Grenzen-hinaus-
> reichenden" Verbindungs-info's belästigen/versorgen, was angesichts der
> exponentiell zunehmenden node-anzahl einen wohl erheblichen CPU-Last
> mildernden Effekt hätte?


die mprs reduzieren die redundanz der informationen lokal - das ist für 
die stabilität negativ. diese idee ist ein hemmschuh und bewirkt IMHO 
das gegenteil. in einem mesh gibt es dauernd paketloss und kollisionen. 
diese redundanz muss sein. sonst kommt es zu lokalen loops. ausserdem 
wird beim olsr rfc mit jeder topologie-kontrollnachricht (TC) immer das 
*gesamte* netz geflutet. und das von jedem einzelnen node. das macht 
überhaupt keinen sinn. da ist das bestimmen von MPRs eine zweifelhafte 
'optimierung' die wenig einbringt - ausser ärger

um die stabilität und eine weitgehende loopfreiheit zu ermöglichen muss 
man die TCs sehr oft schicken - bestenfalls sehr viel öfter als die 
Hellos, damit die veränderungen der topologie zeitnah und sicher von 
denen zur kenntnis genommen werden die es angeht - und das sind die 
nachbarn bis zu n-hopcount. ohne fisheye geht das nicht damit würde das 
netz ersticken und die CPUs glühen. aktuell machen wir das bis 3 hops. 
selten schicken wir einen 'globalen' broadcast. das schema ist hart 
gecodet und kann sicher noch optimiert werden. siehe das 
link-quality-fisheye-readme im olsr-paket.

> Nur fällt es mir schwer, trotz mittlerweile wieder auf "7" gesetzter MprCoverage
> MPR-selections und Wirkung zu erkennen.

das hat niemand behauptet. es ist einem missverständnis in der 
kommunikation. MPR ist IMHO Unsinn und fällt raus

was aktuell unter olsr hier in Berlin firmiert ist jetzt:

keine mpr-selections
keine hysterese
ETX-LQ
grosse sliding window size für die Hello-Statistik
Fisheye

es wäre zeit für ein neues RFC - es kann aber IMHO nicht mehr olsr 
heissen, die ganzen optimierungen die olsr von irgendeinem 
links-state-routing unterscheiden sind raus.

installiert man den olsrd-0.4.10 von der source mit

make install

wird automatisch die alte rfc-kompatible version der konfigurationsdatei 
installiert - die leute die den olsrd so verwenden werden sicher so 
enttäuscht sein wie wir vor zwei jahren anfangs von olsr enttäuscht wurden.

inzwischen haben wir einige verbesserungen gemacht. leider ist 
olsrd.conf dadurch überaus komplex und kaum noch zu überblicken. ein 
grosser teil der olsrd.conf dient nur noch dem zweck die alten 
optimierungen abzustellen oder auszutricksen - siehe MprCoverage 7

höchste zeit auszumisten
> 
> 
> 
>>* Die CPU-Last in den Nodes ist so gross, dass OLSR nicht mehr mit dem 
>>Berechnen der Routingtabellen klar kommt und verrückt spielt
> 
> 
> Ack.
> 
> Hier widerspricht sich der Wunsch, immer weiter zusätzliche nodes ins Netz
> zu bekommen, und die Notwendigkeit, Verbindungsinfo aller link-Strecken an
> alle nodes zu verteilen, und das so schnell es irgendwie geht, um günstigsten-
> falls innerhalb des timeouts der retry-Versuche des TCP-stacks Packete auf
> einen funktionierenden Weg zu bringen.


die roadmap ist die: das olsrexperiment wird sich weiter vergrössern und 
wir werden den olsrd weiter optimieren, bis wir von der CPU-Last her 
irgendwann gegen die wand fahren. wir kommen unweigerlich an ein limit, 
da wir ein proaktives protokoll verwenden. die routingtabellen werden 
irgendwann so gross dass es einfach nicht mehr geht. dann werden wir das 
riesige einzige subnetz in kleinere subnetze unterteilen und eine 
subnetz-hierarchie einführen. wir werden aber keine anderen 
routingprotokolle einsetzen, denke ich.

jede meshwolke ist dann ein autonomes system, die autonomen systeme 
werden dann wiederum von einem höheren subnetz untereinander verbunden. 
in jedem dieser subnetze läuft olsrd und zwischen den subnetzen routed 
wieder olsrd. olsrd ist so lange zweckmässig so lange wir drahtlose 
links einsetzen. wenn wir das mal nicht mehr tun, können wir auf ospf, 
rip oder bgp zurückgreifen

vorher können wir aber noch an dem djikstra-algorithmus feilen. wie wäre 
es mit einem inkrementellen djikstra, der wesentlich weniger cpu-last 
verbraucht? und fliesskommaberechnungen können wir ebenfalls weglassen.
> 
> 
>>* Wenn OLSR-Nodes über Infrastruktur-Links funken und der Master-Node 
>>ebenfalls OLSR auf dem AccessPoint-Interface spricht führt das zu Chaos, 
>>einschliesslich Loops. Olsrd glaubt, dass der AP und seine Clients 
>>sämtlich Single-Hop-Nachbarn sind. Sind sie aber nicht, da der AP 
>>zwischen den Clients als Basisstation sitzt und als Bridge agiert. Olsrd 
>>wird in diesem Fall wahrscheinlich dank ETX versuchen den AP als Router 
>>zwischen den Clients einzutragen - was keinen Sinn macht, da dieser das 
>>ohnehin transparent tut. Ausserdem kann es u.U. passieren, dass Olsrd 
>>versucht um den AP herumzurouten - was ebenfalls keinen Sinn macht.
> 
> 
> Aeh, ein als bridge arbeitender master (AP) ist "unsichtbar" für das über
> seinen ethernet-port angeschlossene interface, und den darauf und mit
> dessen Adresse laufenden olsrd.
> Er braucht/hat keine eigene IP im zu bridge-nden Netz.  Macht also keinen
> Ärger.

Gemeint war das ein Accesspoint-Router zwischen den drahtlosen Clients 
bridged, dazu brauchts keine IP auf demselben. Es geht also um die 
Technik des Clients-kommunizieren-miteinander-über-die-Basisstation, 
nicht darum dass der AP zum Ethernet bridged. Ich verstehe, dass da die 
Begrifflichkeiten verschwimmen.

> 
> Ein "Accesspoint-router" ist dasselbe, also eine bridge, die aber mit
> der LAN-Seite eines routers fest verbunden ist.  Auch hierbei braucht der
> router-Teil keine eigene IP im Funk-Netz, solange man verkabelte olsr-
> Gegenüber ausschließlich an seine LAN-ports dranhängt.
> 
> Probleme entstehen (weil ein router eben "routen" will ;-), wenn man 
> über seinen WAN-port dasselbe subnet erreichen will, das auch für die
> LAN-/Funk-clients gilt.  Meistens zwingt das Konzept des routing-
> Teils, auf der LAN-Seite mit einer kleineren, statischen netmask
> zu arbeiten, als auf der WAN-Seite.  Damit kommen die oben von
> elektra als "Punkt 1" genannten manuellen routen ins Spiel.
> 
> Als Faustformel kann man vielleicht sagen, sobald man versucht ist,
> einem Ap-router eine IP-Adresse zu geben, um "über ihn" Funk-traffic
> zu schicken, Finger wech :-)

Exakt!

cu elektra

_______________________________________________
Berlin mailing list
Berlin at olsrexperiment.de
https://www.olsrexperiment.de/cgi-bin/mailman/listinfo/berlin