<div dir="ltr"><div>Distance Vector vs Link State dürfte für diese Frage eine untergeordnete Rolle spielen, i.d.R. sehe ich Link State in leichten Vorteil, da diese theoretisch eine bessere Abschätzung machen könnten hinsichtlich des optimalen Pfads, da Sie die komplette Topologie sehen. Je größer die Topologie wird, desto schwieriger wird das natürlich und skaliert vermutlich nicht ewig. Erst recht über Wifi, wo wir auch noch Einschränkungen hinsichtlich Bandbreite und packetloss haben.</div><div><br></div><div>Ich habe gerade einen Blick auf olsrd2 und babel geworfen. Schön ist, dass beide eine bandbreitenähnliche Metrik mitbringen, welche tatsächlich Sende und Empfangsrichtung unterscheiden kann. Babel sieht für mich aufgrund von Interoperabilität schöner aus, da es eine unabhängige Implementierung in bird gibt. Theoretisch könnten wir uns für einen Alpha Test ein paralleles Setup aufbauen mit anderen 1:1 mapbaren IP Adressen, eventuell in nem anderen network namespace, insofern notwendig.. <br></div><div><br></div><div>Was diese Protokolle scheinbar jedoch nicht bieten ist eine SmartGateway-ähnliche Funktionalität, wobei ich eh finde, dass das vom Routing Protokoll getrennt laufen darf. Hat hier wer Alternativen im Blick? Einen kleinen daemon schreiben, welcher unseren SmartGW use-case implementiert und eventuell sogar anständig konfigurierbar im Gegensatz zu dem in olsrd1 enthaltenem ist, dürfte aber auch nicht allzu kompliziert sein.</div><div><br></div><div>Grüße</div><div>Simon<br></div><div><br></div><div class="gmail_quote"><div dir="ltr">Am So., 6. Jan. 2019 um 23:24 Uhr schrieb Philipp Borgers <<a href="mailto:borgers@mi.fu-berlin.de">borgers@mi.fu-berlin.de</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Entweder es wird die Bandbreite des Links in die Metrik einbezogen oder per<br>
default erhalten alle Nachbarn erstmal in der Konfiguration eine schlechtere<br>
Metrik und nur ausgewählte Nachbarn eine bessere, indem man sie explizit in die<br>
Konfiguration aufnimmt (OLSRv1 könnte das).<br>
<br>
OLSRv2 kann die Bandbreite des Links als Kriterium für die Metrik nutzen.<br>
Eigentlich sollte die Funktion für die Metrik in modernen Implementierungen<br>
beliebig austauschbar sein bzw. modular sein, sodass man leicht neue oder<br>
abgewandelte Metriken entwickeln kann.<br>
<br>
Warum ist "distance-vector" ein wichtiger Fakt?<br>
<br>
Gruß Philipp<br>
<br>
On Sat, Jan 05, 2019 at 12:34:14AM +0100, Sven Röderer wrote:<br>
> In wie weit würden uns für sowas denn modernere Routing-protokolle (babel, bmx,<br>
> olsrd2) helfen?<br>
> Die drei genannten sind ja alle "distance-vector" basiert.<br>
> <br>
> Sven<br>
> <br>
> Am 03.01.2019 um 13:52 schrieb simzon:<br>
> > Bekommen wir es eventuell hin, dass im BBB  bandbreitenreiche geplante Links generell mit geringerer Metrik als Link-Wildwuchs konfiguriert werden?<br>
> <br>
> _______________________________________________<br>
> Berlin mailing list<br>
> <a href="mailto:Berlin@berlin.freifunk.net" target="_blank">Berlin@berlin.freifunk.net</a><br>
> <a href="http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin" rel="noreferrer" target="_blank">http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin</a><br>
> Diese Mailingliste besitzt ein ffentlich einsehbares Archiv<br>
_______________________________________________<br>
Berlin mailing list<br>
<a href="mailto:Berlin@berlin.freifunk.net" target="_blank">Berlin@berlin.freifunk.net</a><br>
<a href="http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin" rel="noreferrer" target="_blank">http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin</a><br>
Diese Mailingliste besitzt ein öffentlich einsehbares Archiv</blockquote></div></div>