[Olsr-users] Route-Flapping | Out of Control [Deutsch]

[Markus Kittenberger]

2010/12/21 Michael Rack <(spam-protected)>

> Am 20.12.2010 21:44, schrieb Markus Kittenberger:
>
>  und warum gehen "nur" olsr pakete verloren???
>>
> Ich denke, das Problem an dem Link festmachen zu können. Mit IPERF bekomme
> ich max. 18 MBit drüber, bei einer Synchronisation von 54 MBit. Eigentlich
> sollte 5,6GHz Hardware (OSBRIDGE 5 GXi) ca 32MBit schaffen (SNR liegt bei ca
> 40). Wenn der Link nun belastet wird (auch 300kByte zählen dabei als Last),
> gehen die OLSR-Pakete verloren. Muss mir deshingehend anscheinend ein QoS
> Einrichten.

hmm, osbrdiges verbau ich nitamal wenn ich sie geschenkt bekomme *G

wenn sie 18mbit schaffen, und bei 300kbit schon packetloss machen, dann ist
das wohl kein mit QOS lösbares problem

>
>
>  olsrd entfernt übrigens die routen auch (und zwar sofort) wenn es keine
>> route zu dem ziel mehr gibt,..
>> und strecken mit lq < 0.1 werden fürs routing nicht verwendet,..
>>
>> und wenn aufeinanderfolgend etliche hellos verloren gehen, ist ein lqwert
>> < 0.1 recht schnell erreicht
>>
> Sprich HNA verliert auch automatisch die Gültigkeit,

nein das hna bleibt gültig *G
es wird nur lediglich nicht verwendet, wenn es keine route zu dem router
gibt der dieses hna gesendet hat,..

sobalds aber wieder irgeneine route gibt, ist das alte hna dann eben noch
da, und es muss nicht erneut auf ein hna gewartet werden (üblicherweise
sendet man hnas ja auch seltener als tcs/hellos)

sobald ein Host mit seinen HELLO-Paketen nicht mehr hinterher kommt. Sprich
> 120 Sekunden für HNA macht in meinem Falle keinen Sinn, weil die 60 Sekunden
> Timeout im HELLO "Link Sensing" bereits vorher eintreten.

es macht sehr wohl sinn das hna länger gültig zu lassen,..  (auch 500
sekunden machen sinn) da sich hnas idr selten ändern,..

>
>
>  weil eben links mit lq < 0.1 nicht für routing verwendet werden, und das
>> linksensing sich (ausser dem packetloss) grossteils nur um das
>> hellointervall des nachbarn kümmert, und weiters nichtmal mehr linear
>> arbeitet, d.h. je mehr pakete fehlen desto schneller sinkt der lq wert,..
>> (afair nach 2 hellointervalls ohne jegliche pakete eines nachbarn geht die
>> lq-kurve dann exponentiell "abwärts")
>>
> Ok, das verstehe ich. Das Verhalten ist ja auch vollkommen korrekt und
> genauso wünscheswert.
>
>
>  hättest du hellointerval von 5 sekunden, und timeout von 10 sekunden, dann
>> würde das timeout den link wohl tatsächlich "abdrehen",..
>>
>> ist das timeout aber 120 sekunden, ist der lq wert idr schon viel früher
>> auf < 0.1.
>>
> Hmmm... also ich verstehe da eher "In 120 Sekunden erwarte ich 24
> HELLO-Nachrichten" ... Erhält OLSR jetzt nur 12 Nachrichten, so ist die LQ
> bei 0.5 ...

wenn genau jedes zweite paket fehlt ist es auch so
fehlen z.b. ca 5 hintereinander, ist der link schon nach z.b. 30 sekunden
als unverwendbar eingestuft

Verliere ich alle 24 Nachrichten, so ist der Nachbar "tot" und ich entferne
> seine Informationen "LINK DEAD".

das passiert dann auch, nur wie gesagt wird zu dem zeitpunkt längst nicht
mehr über ihn geroutet,..


>
>  und dann evt (falls nötig) über ein spezielles linksensing nachdenken
>>
> Ich kenne kein besseres, als OLSR. OLSR ist einfach zu verstehen und
> einfach einzurichten. BGP ist zu komplex und IS-IS zu heavy, ganz geschweige
> denn von OSPF.
>
linksensing ist nur ein teil des olsrd (oder teil eines routing-daemons)

und ich meinte nur: evt brtauchst du ein spezielles lq-plugin für den
olsr,.. (damit es besser mit deinen "seltsamen" 5ghz strecken umgeht)

jedoch solang du ungeklärten packetloss mit olsr paketen hast, ist das mal
sowieso völlig unerheblich


> Eine Frage wurde mir jedoch noch nicht beantwortet...
> Node (A) sendet HELLO Nachrichten mit INTERVAL=2, VALIDITYTIME=6 | HNA mit
> INTERVAL=5, VALIDITYTIME=15
> Node (B) sendet HELLO Nachrichten mit INTERVAL=2, VALIDITYTIME=60 | HNA mit
> INTERVAL=5, VALIDITYTIME=120
>
> Node (B) empfängt von (A) 100% der HELLO-Nachrichten LQ=1.000 | NLQ=1.000
> Nobe (C) empfängt von (B) nur 40% der HELLO-Nachrichten LQ=0.400 |
> NLQ=1.000
>
> Im Routing von (C) sehe ich (B) stabil... Er ist immer vertreten. Es
> scheint kein TIMEOUT (Veraltet) aufzutreten. Die LQ ist natürlich sehr
> schlecht.
>
> Das komische ist aber, dass Node (C) Node (A) nur mit Route-Flapping sieht.
> Sprich, Link auf /32-Adresse ist da, ist weg, ist da, ist weg....
>

falls das hna von A flapped auf C ist das absolut nicht verwunderlich,..

bei ner so kurzen validity time auf A , und dem packetloss von B nach C,
kommen nicht verlässlich hnas von A alle < 15 sekunden bei C an,..


> Sind die Einstellungen "VALIDITYTIME" von (A) Node-Übergreifend? (B)
> tauscht die Daten mit (C) aus, dennoch fällt (A) aus der Routingtabelle von
> (C), obwohl die Verbindung (A) -> (B) optimal ist.
>
nein die validity time des absenders eines pakets wird von keinem forwarder
(in deinem Beispiel B) je verändert,..


> Nun habe ich auf (A) auch ebenfalls die Einstellungen wie bei (B) und (C)
> vorgenommen, seitdem sieht (C) und alle nachfolgenden Routers (A) ohne
> Probleme.
>
ich hoffe dir ist nun inzwischen klar warum,..

lg Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20101221/939e5010/attachment.html>