[Berlin-wireless] wie entstehen routen-loops

Marco Tidow martidow
Fr Feb 17 21:50:09 CET 2006


On Fri, Feb.17. 17:12 +0100, onelektra wrote:
> Hi -
Hi,

> Woher kommt das?
> 
> * Jemand hat von Hand an den Routingtabellen schraubt und solche 
> Kreisläufer gebastelt.
Ack.

> * Der Routingdeamon schafft es nicht die Routingtabellen zu synchronisieren

"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.

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.


> * Bugs in OLSR

Dazu mal eine Frage, nämlich nach dem Verbleib und Sinn der MPR (Multi-Point-Relay)
Mechanik im olsrd.  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?

Andererseits dadurch auch "Synchronisierer", weil sich die nicht-als-MPR-
selected-nodes nach demselben link-quality-Bild des nodes-Haufens richten,
wie der jeweilige MPR, anstatt jeder für sich und zwangsläufig "asynchroner"?

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


> * 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.


> * 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.

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 :-)

> cu elektra
bei Gelegeheit, marco


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





Mehr Informationen über die Mailingliste Berlin