[Wien] wan-link-quality

[Martin Walter Mildner]

NAJA, 

schätze den Markus wirklich sehr, und akademisch hat er wahrscheinlich
irgendwie recht, aber in der Praxis ist es ganz gut etwas nicht schlecht,
aber schlechter als was anderes zu machen und MEIN  transit Transit will
auch lieber über den von dir entschieden  BEVORZUGTEN Weg gehen, weil der
auch in der Praxis auch besser geht (zb nicht nur wenn das OLSR mit hello
Paketen "testet", sondern wenn wirklich große Pakete daherkommen)

Und bitte komm mir jetzt nicht mit traffic von einem Knoten zum anderen ,
der nicht ins Internet will, der ist in der Praxis vernachlässigbar J

l.g.

Martin

 

Von: (spam-protected)
[mailto:(spam-protected)] Im Auftrag von amadeus scherhaufer
Gesendet: Donnerstag, 05. Februar 2009 14:31
An: Markus Kittenberger; (spam-protected)
Cc: (spam-protected)
Betreff: Re: [Wien] wan-link-quality

 

hallo!

 

kein angst, mir war von anfang an klar, dass es keine option ist, die links
zu

meinen nachbarn zu verschlechtern...deswegen hab ich ja auch nachgefragt!

 

lg,

amadeus

 

From: (spam-protected) [mailto:(spam-protected)]
On Behalf Of Markus Kittenberger
Sent: Donnerstag, 5. Februar 2009 14:17
To: (spam-protected)
Cc: amadeus scherhaufer; Matthias Šubik; (spam-protected)
Subject: Re: [Wien] wan-link-quality

 

achtung! das echte problem ist ja das nicht einer das setup macht sondern
viele, und man eben immer auch das Routing der anderen beeinflusst nicht nur
sein eigenes,..

und insofern sollte human bneing halt auch mal Rücksicht nehmen auf die
anderen, und darum akzeptieren das man nicht alles so ändern kann wie man es
gerade gern hätte,..

 

2009/2/5 Martin Walter Mildner <(spam-protected)>

Hallo "human beeing" !
Kann dich gut verstehen, und habe mir auch überlegt die Version 2 von OSPF
zu verwenden, wenn OLSR so "bockig" ist

ich seh eigenltich wenig unterschied zwischen OSPF und OLSR in der hinsicht

(abgesehen von implementierungs-bugs auf beiden seiten) 

, was menschliche "Händische"
Überarbeitung von bestehenden Routen ist!

nunja in ospf ists zwar halbwegs human readable link-costs fix zu
definieren,

in OLSR überlässt man halt den OLSR gute kosten zu machen

letzteres macht er aber nicht so wie wir gern hätten, vorallem weil mom.
zuviele link optimal niedrige kosten von ca. 1.0 haben

(das ist aber eigentlich nicht die schuld von olsr, sondern von "uns" allen
admins die es olsr erlaubt haben für funkstrekecken das optimum zu nehmen)
weil der lqmult nur in ausnahmefällen verwendung findet, und der default
wert eben 1.0 ist,..

hätten wir standardmässig überall nen lqmult von 0.3 könnte man nicht nur
links verschlechtern sondern auch verbessern,..

aber das netzweit umzustellen ist ne andere gschichte,..
(drum warten wir ja unter anderem auch lieber gleich auf ETT)

 

leider war früher lokal (im grunde wars ein bug) ein lqmult > 1 möglich,
welcher dann aber die einheitlichkeit der topologie verletzte, weil die
anderen olsrd draussen im netz den link mit anderen kosten betrachteten,

und die link states bzw kosten zu fälschen ist bei einem link state routing
protokoll eigentlich das böseste ist was man tun kann,..


In der Praxis ist es aber doch gut, das OLSR halt im Ernstfall "sich neu
Konfiguriert" und "irgendwas" sofort tut, bis du eingreifen kannst wenn zum
Beispiel ein Kabel ausfällt, 

das macht ospf auch, ...

lg Markus

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/wien/attachments/20090205/42005a52/attachment.htm>