[Wien] [Core] noch ein paar traceroutes

[Andreas Marksteiner]

Hallo,

otti wrote:
> hmm, also dass die Route wechselt gehöhrt zur normalen Funktion von olsr
> und kann auch erwünscht sein (load balacing). Problem ist wohl das

ja schon, aber Ziel sollte es ja doch eher sein die momentan Beste bzw.
bei eher statischen Umgebungsbedingungen eine langfristig stabile Route
zu finden. Klar stellt sich die Frage was ist "gut", was ist "besser".
Wenn ich surfe bzw. z.B. bei VoIP eigentlich eine Route mit konstanter
Qualität - sogar, wenn mit geringerem maximalem Datendurchsatz. Beim
Download sind mir Aussetzer wiederum egal - solange der Datendurchsatz
möglichst hoch ist (wobei unsere Aussetzer ja eh meißt von
zwischenzeitlich inkonsistenten Zustand der einzelnen Routing Tables
kommen und nicht von realen kurzen Störungen der Funkverbindungen).

An Load Balancing hab ich auch schon gedacht - denke aber nicht, dass
das hier absichtlich passiert? Gibts da schon Überlegungen dazu bzw. ist
das schon eine Vorstufe von Load Balancing?


> Auftreten von Loops wärend des Wechsels. Angezeigt durch:
> 
>>From 193.238.158.105 icmp_seq=12 Time to live exceeded
> 
> Das zeigt, dass 193.238.158.105 und einer seiner Nachbarn nicht die
> selbe Routingentscheidung treffen und sich daher das Paket solange
> gegenseitig schicken bis die TTL abgelaufen ist.

Je dynamischer das Netz gestaltet ist bzw. je öfter der Algorithmus eine
neue beste Route errechnet, desto schwerer stelle ich mir vor zu einem
bestimmten Zeitpunkt auf allen Nodes einen Zustand mit "gültiger"
routing table zu erreichen.

> Ein Vergleich der
> Routingtables auf den Routern würde sicher das Problem aufzeigen.

Hmm müßten wohl Snapshots vom Routing Table mit Timestamp und
synchronisierter Systemzeit auf allen Nodes sein.

Arbeitet nicht Wolfgang auch an so einem Projekt, wo er automatisiert
über längere Zeit die Entwicklung in div. mesh wireless Netzen
dokumentieren will. Aus dem System kann man in Zukunft dann vielleicht
für solche Probleme wertvolle Info gewinnen.


> Auch bei gemischten olsr versionen gabs teilweise komisches Verhalten.
> Ich hab leider auch FishEye in verdacht, Routing Loops zu erzeugen.
> 
> Es ist sicher nen Versuch wert die Firmwares/olsrds auf dem Router und
> seinen Nachbarn upzugraden und Fisheye testweise auszuschalten.

Hmm mal sehen, ob ich auf ausreichend viele meiner Nachbar Router
Zugriff habe, um das mal zu versuchen.


Grüße, Andi.

P.S. Da gibts zwar sicher jede Menge Theorie dazu, aber ad Load
Balancing - stelle mir vor, man könnte Pakete je nach Qualität der
möglichen Routen entsprechend anteilig auf diese Routen verteilen. Dann
ist es aber in etwa so, als würde ich mehrere Routing Tables
unterschiedlicher Qualität nebeneinder benutzen. Angenommen ich schicke
  ein Paket zu einem Nachbarknoten über meine beste Route, darf dann
dieses Paket z.B. auf dem Nachbarknoten nach einer schlechteren Route
weiterversendet werden - möglicherweise beinhaltet diese Route, ja als
NextHop den Quellknoten vom vorherigen Hop? Weiters könnte es vielleicht
problematisch sein, wenn z.B. UDP Pakete von einem Audio Stream über
mehrere Routen zu verteilen, denn es wäre ja denkbar, dass so Pakete
andere Pakete "überholen"? Man müßte also das Balancing vielleicht sogar
protollabhängig machen? Ok viele Fragen, weil ich dazu keine Theorie
kenne - scheint aber recht interessant zu sein. Ob es dazu schon
Lösungen gibt?