[Discuss] Babel im Mesh mit IPv6

[Markus Kittenberger]

2008/12/21 Adrian D <(spam-protected)>

> wir haben das selbe problem wie mit einem metrik-update bei olsr: wir
> brauchen einen testmöglichkeit bzw einen update-pfad für das netz.
> adhoc fallen mir zwei varianten ein: ein anderer ip range

für die evaluierungphase wür d ich sagen parallellauf,
.
und ja sobald man sich für nen umstieg entschieden hat (egal ob
metrikwechsel oder routingdaemon oder beides), muss man halt für das bisher
z.b. in anderer ip range operienden testnetz aufs gesamte mesh vergrössern
und ihm wenn noch nötig auch public ips geben das dann jeder auf dieses
umsteigen kann, (das alte aber ncoh ne weile weiterläuft,..)
.
aber vorerst sind das nur mal die ersten evaluierungsschirtte, umstieg steht
ncoh nciht im raum

> oder ein
> anderes vlan über funk.

vlans funktioneren nicht verlässlich, hab noch nie wrklich funktionierende
vlans zwischen ner fonera und nem linksys zamgebracht

> beides hat den nachteil es irgendwann mal eine
> big-bang-umstellung geben muss - aber vielleicht fällt uns noch was
> besseres ein? eines, wo wir routen über die jeweils andere metrik

alles ist machbar, aber alles muss auch wer machen,.. (-;
.
verschiedene routing-daemons können untereinander routen austauschen, ein
routingdamoen kann auch könnt auchg mehrere metriken parallel fahren,.. usw.

>
> automatisch integrieren können? hmm..
> allzu lange werden wir uns davor nicht mehr drücken können.
>
>
> ich war leider nicht bei dem babel-vortrag dabei, hab jetzt nur die
> folien gesehen und muss sagen: super dass man sich wichtiger nachteile
> des olsr angenommen hat (zb synchronizität bei route veränderungen).
> aber ein zentraler nachteil bleibt: es verwendet ebenfalls die
> ETX-metrik mit den zwei gravierendsten nachteilen:


> *) es bewertet einen hop mit 50% packetloss (ETX=2) als besser, als zwei
> hops mit jeweils nur 1% packetloss (ETX 1.01+1.01=2.02)

das mag desweilen auch gut sein, würden alle ihre persönlich beste routen
kriegen die dann länger und theoretisch schneller wären, ist das schnell mal
insgesamt schlechter, weil es global weitaus mehr airtime braucht
.
aber klar ich liebe etx auch nicht

>
> *) wird ein link tatsächlich belastet, konkurrieren datenpakete mit

indirekt über die airtime ja (da stören aber eher benachbarte links mehr als
der eigene), direkt nur wenn keine entsprechende traffic control (wie sie
auf auf jedem freifunk-router existiert) (aka. QOS) konfiguriert ist,..
.
aber auch das ist ein metrik problem,.
.
olsr kann nur nebenbei schlecht mit diesen "schnellen" metrikänderungen
umgehen,.. und auch schlecht mit anderen metriken welche z.b. auch auf
bandbreite rücksicht nehmen und dadurch auch mutmasslich mehr metrik
schwankungen haben werden,..

>
> hellopaketen was den ETX wert ansteigen läßt, und zu route-switching auf
>  schlechtere routen führen kann.

schlechter ist realtiv, die andere route ist ja scheints bei dem beispiel ja
eh überlastet, problematisch ist eher das dies gern zum schwingen anfängt,..

> zumindest kommt es bei babel beim
> routswitching nicht zu einstweiligen schleifen und damit zu aussetzern.

mal sehen,.. (-;
das sind im grund metrikprobleme, keineswegs unwichtig, aber wechselbar
(metrikwechsel sind natürlich auch nicht leichter als routingdaemonwechsel)

>
>
>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/discuss/attachments/20081221/0b88bf6c/attachment.htm>