[Berlin-wireless] wie entstehen routen-loops

[Peter Lazarev]

Erstmal danke an euch alle für die Erklärungen. Diese habe ich trozt
eines Informatikatudiums nur zum Teil verstanden.
Die bereinigung des olsr können vermutlich alle nur begrüssen.
Die ursprungliche Frage bleibt für mich jedoch offen: Sobald der Bouche
uplink ausfällt, gibt es loops innerhalb des BBB, warum gerade an den
beiden Nodes?:

12    47 ms    34 ms    13 ms  104.0.4.1
13     7 ms    10 ms    13 ms  104.0.0.14
14    14 ms     7 ms    17 ms  104.0.4.1
15    15 ms     9 ms    11 ms  104.0.0.14
16     7 ms    11 ms     8 ms  104.0.4.1

da ich auch direkt am BBB hänge (104.0.4.200) gehe ich davon aus dass
die ursache etwas mit managed links zu tun hat.
das problem habe ich  allerdings nicht ganz begriffen. ich weiss schon
dass loops entstehen wenn die knoten ping-pong spielen. Was dies, aber
mit dem vergeben einer zusätzlichen IP-adresse im Router, oder gar was
Sven-Ola mit einer "indirekten Verbindung via AP" genau meint weiss ich
nicht.
Für mich kling es es erstmal sonderbar, dass die art der layer 0
verbindung (Managed oder ad-hoc) die loops beim  layer-3 (hmm... oder
2?)-routing produziert.
gruss Peter

onelektra wrote:
> 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
>


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