<br><br><div class="gmail_quote">2010/12/21 Michael Rack <span dir="ltr"><<a href="mailto:michael.rack@rsm-freilassing.de">michael.rack@rsm-freilassing.de</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Am 20.12.2010 21:44, schrieb Markus Kittenberger:<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
und warum gehen "nur" olsr pakete verloren???<br>
</blockquote></div>
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.</blockquote>
<div>hmm, osbrdiges verbau ich nitamal wenn ich sie geschenkt bekomme *G </div><div><br></div><div>wenn sie 18mbit schaffen, und bei 300kbit schon packetloss machen, dann ist das wohl kein mit QOS lösbares problem</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
olsrd entfernt übrigens die routen auch (und zwar sofort) wenn es keine route zu dem ziel mehr gibt,..<br>
und strecken mit lq < 0.1 werden fürs routing nicht verwendet,..<br>
<br>
und wenn aufeinanderfolgend etliche hellos verloren gehen, ist ein lqwert < 0.1 recht schnell erreicht<br>
</blockquote></div>
Sprich HNA verliert auch automatisch die Gültigkeit, </blockquote><div><div>nein das hna bleibt gültig *G </div>es wird nur lediglich nicht verwendet, wenn es keine route zu dem router gibt der dieses hna gesendet hat,.. </div>
<div><br></div><div>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)<br><br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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.</blockquote>
<div>es macht sehr wohl sinn das hna länger gültig zu lassen,..  (auch 500 sekunden machen sinn) da sich hnas idr selten ändern,.. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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")<br>

</blockquote></div>
Ok, das verstehe ich. Das Verhalten ist ja auch vollkommen korrekt und genauso wünscheswert.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
hättest du hellointerval von 5 sekunden, und timeout von 10 sekunden, dann würde das timeout den link wohl tatsächlich "abdrehen",..<br>
<br>
ist das timeout aber 120 sekunden, ist der lq wert idr schon viel früher auf < 0.1.<br>
</blockquote></div>
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 ... </blockquote><div>wenn genau jedes zweite paket fehlt ist es auch so</div>
<div>fehlen z.b. ca 5 hintereinander, ist der link schon nach z.b. 30 sekunden als unverwendbar eingestuft</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Verliere ich alle 24 Nachrichten, so ist der Nachbar "tot" und ich entferne seine Informationen "LINK DEAD".</blockquote><div>das passiert dann auch, nur wie gesagt wird zu dem zeitpunkt längst nicht mehr über ihn geroutet,..</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
und dann evt (falls nötig) über ein spezielles linksensing nachdenken<br>
</blockquote></div>
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.<br></blockquote><div>linksensing ist nur ein teil des olsrd (oder teil eines routing-daemons)</div>
<div> </div><div>und ich meinte nur: evt brtauchst du ein spezielles lq-plugin für den olsr,.. (damit es besser mit deinen "seltsamen" 5ghz strecken umgeht)</div><div><br></div><div>jedoch solang du ungeklärten packetloss mit olsr paketen hast, ist das mal sowieso völlig unerheblich</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Eine Frage wurde mir jedoch noch nicht beantwortet...<br>
Node (A) sendet HELLO Nachrichten mit INTERVAL=2, VALIDITYTIME=6 | HNA mit INTERVAL=5, VALIDITYTIME=15<br>
Node (B) sendet HELLO Nachrichten mit INTERVAL=2, VALIDITYTIME=60 | HNA mit INTERVAL=5, VALIDITYTIME=120<br>
<br>
Node (B) empfängt von (A) 100% der HELLO-Nachrichten LQ=1.000 | NLQ=1.000<br>
Nobe (C) empfängt von (B) nur 40% der HELLO-Nachrichten LQ=0.400 | NLQ=1.000<br>
<br>
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.<br>
<br>
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....<br></blockquote><div><br></div><div>falls das hna von A flapped auf C ist das absolut nicht verwunderlich,..</div>
<div><br></div><div>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,..</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
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.<br></blockquote>
<div>nein die validity time des absenders eines pakets wird von keinem forwarder (in deinem Beispiel B) je verändert,.. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
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.<br>
</blockquote></div><div>ich hoffe dir ist nun inzwischen klar warum,..<br></div><div><br></div><div>lg Markus</div>