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

[Michael Rack]

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.

> 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, 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.

> 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 ... Verliere ich alle 24 Nachrichten, so ist der Nachbar 
"tot" und ich entferne seine Informationen "LINK DEAD".

> 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.

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....

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.

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.