[Wien] lichtwicht tunnel & heuberg
Markus Kittenberger
(spam-protected)
So Dez 28 18:11:08 CET 2008
einer unserer uplinks ist "eingegangen" (d.h. der glasfaserlink hat
mutmasslich packetloss)
dieser link ist nun (seit 1,5h) down, und nach ein paar folgeproblemen ist
nun auch der tunnelserver wieder von aussen erreichbar,..
zwischenzeitlich ist der olsrd am roofnode auch noch abgestürzt gewesen,
aber nun sollte auch das wieder passen,..
somit kann man jetzt auch wieder schauen ob der liechtwicht-tunnel noch
probleme hat/macht,..
lg Markus
2008/12/28 Markus Kittenberger <(spam-protected)>
> nunja momentan haben wir auch packetloss am subway, also eh ziemlihc
> egal,..
>
> nebenbei hat mein skript am liechtwicht auch noch kleine weitere
> problemchen,..
>
> und dann haben wir noch inkompatbilitäten zwischen 1.6.2x und 1.6.3x,
> welche dazu führt das tadellose strecken als INFINITE aufscheinen,..
>
> nunja, nächstes Jahr wird sicher alles besser (-; *g*
>
> lg Markus
>
> 2008/12/28 Erich <(spam-protected)>
>
>> Derzeit läuft der Tunnel ja wieder, aber vorher war ständig der Tunnel
>> weg, es wurde über die "normale" Wlan Strecke geroutet und kurz drauf, war
>> der Tunnel wieder da, wie wenn alles ok wäre.
>> Dadurch sind eben sehr viele Pakete verloren gegangen. Vielleicht liegts
>> aber auch an einer Routenänderung wegen dem schlechten Link zu Spenger25.
>>
>> Sieht dann kurz so aus
>> Routenverfolgung zu wicht.liechtwicht.wien.funkfeuer.at[193.238.158.154] über
>> maximal 30 Abschnitte:
>>
>> 3 6 ms 5 ms 6 ms viviroof.vivi.wien.funkfeuer.at[78.41.112.60]
>> 4 9 ms 7 ms 7 ms ma89v1.ma89.wien.funkfeuer.at[193.238.156.130]
>> 5 * * 4183 ms panelwan.spenger25.wien.funkfeuer.at[193.238.156.201]
>> 6 * * * Zeitüberschreitung der Anforderung.
>> 7 18 ms 25 ms 35 ms wicht.liechtwicht.wien.funkfeuer.at[193.238.158.154]
>>
>> Ablaufverfolgung beendet.
>>
>> Die Pingzeiten steigen an, werden immer höher und dann geht gar nichts
>> mehr. Die Route wird kurz geändert und dann läuft der Tunnel wieder.
>>
>> Antwort von 193.238.158.154: Bytes=32 Zeit=17ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=16ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=58ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=39ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=35ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=18ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=19ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=17ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=19ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=24ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=38ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=24ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=71ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=27ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=37ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=117ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=37ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=54ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=57ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=158ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=387ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=84ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=141ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=323ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=47ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=70ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=200ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=72ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=34ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=1012ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=135ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=388ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=627ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=677ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=164ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=32ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=114ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=90ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=489ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=28ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=171ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=45ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=40ms TTL=58
>> Zeitüberschreitung der Anforderung.
>> Zeitüberschreitung der Anforderung.
>> Zeitüberschreitung der Anforderung.
>> Zeitüberschreitung der Anforderung.
>> Antwort von 193.238.158.154: Bytes=32 Zeit=4092ms TTL=60
>> Zeitüberschreitung der Anforderung.
>> Antwort von 193.238.158.154: Bytes=32 Zeit=39ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=21ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=22ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=44ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=23ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=18ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=24ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=22ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=20ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=52ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=26ms TTL=60
>> Antwort von 193.238.158.154: Bytes=32 Zeit=23ms TTL=60
>>
>> Ping-Statistik für 193.238.158.154:
>> Pakete: Gesendet = 937, Empfangen = 898, Verloren = 39 (4% Verlust),
>> Ca. Zeitangaben in Millisek.:
>> Minimum = 11ms, Maximum = 4318ms, Mittelwert = 174ms
>>
>> Wie du schon geschrieben hast, liegt der Pingverlust am Knoten Spenger25.
>> Komisch ist nur, dass der Tunnel ständig ausfällt.
>> Antwort von 193.238.158.154: Bytes=32 Zeit=19ms TTL=59
>> Antwort von 193.238.158.154: Bytes=32 Zeit=47ms TTL=59
>> Antwort von 193.238.158.154: Bytes=32 Zeit=17ms TTL=59
>> Antwort von 193.238.158.154: Bytes=32 Zeit=45ms TTL=59
>> Antwort von 193.238.158.154: Bytes=32 Zeit=20ms TTL=59
>> Antwort von 193.238.158.154: Bytes=32 Zeit=17ms TTL=59
>> Antwort von 193.238.158.154: Bytes=32 Zeit=54ms TTL=59
>> Antwort von 193.238.158.154: Bytes=32 Zeit=28ms TTL=59
>> Antwort von 193.238.158.154: Bytes=32 Zeit=23ms TTL=59
>> Antwort von 193.238.158.154: Bytes=32 Zeit=21ms TTL=59
>> Antwort von 193.238.158.154: Bytes=32 Zeit=29ms TTL=59
>> Antwort von 193.238.158.154: Bytes=32 Zeit=29ms TTL=59
>> Antwort von 193.238.158.154: Bytes=32 Zeit=31ms TTL=59
>> Antwort von 193.238.158.154: Bytes=32 Zeit=27ms TTL=59
>> Antwort von 193.238.158.154: Bytes=32 Zeit=36ms TTL=59 - vermutlicher
>> Tunnelausfall
>> Antwort von 193.238.158.154: Bytes=32 Zeit=2135ms TTL=5
>> Antwort von 193.238.158.154: Bytes=32 Zeit=457ms TTL=59
>> Antwort von 193.238.158.154: Bytes=32 Zeit=256ms TTL=59
>> Antwort von 193.238.158.154: Bytes=32 Zeit=1199ms TTL=5
>> Antwort von 193.238.158.154: Bytes=32 Zeit=545ms TTL=59
>> Antwort von 193.238.158.154: Bytes=32 Zeit=948ms TTL=59
>> Antwort von 193.238.158.154: Bytes=32 Zeit=763ms TTL=59
>> Antwort von 193.238.158.154: Bytes=32 Zeit=1362ms TTL=5
>> Antwort von 193.238.158.154: Bytes=32 Zeit=2531ms TTL=5
>> Antwort von 193.238.158.154: Bytes=32 Zeit=3382ms TTL=5
>> Zeitüberschreitung der Anforderung.
>> Antwort von 193.238.158.154: Bytes=32 Zeit=3302ms TTL=5
>> Antwort von 193.238.158.154: Bytes=32 Zeit=3641ms TTL=5
>> Zeitüberschreitung der Anforderung.
>> Antwort von 193.238.158.154: Bytes=32 Zeit=64ms TTL=59
>> Antwort von 193.238.158.154: Bytes=32 Zeit=21ms TTL=59
>> Antwort von 193.238.158.154: Bytes=32 Zeit=30ms TTL=59
>> Antwort von 193.238.158.154: Bytes=32 Zeit=24ms TTL=59
>> Antwort von 193.238.158.154: Bytes=32 Zeit=58ms TTL=59
>> Antwort von 193.238.158.154: Bytes=32 Zeit=37ms TTL=59
>> Zeitüberschreitung der Anforderung.
>> Zeitüberschreitung der Anforderung.
>> Antwort von 193.238.158.154: Bytes=32 Zeit=828ms TTL=59
>> Antwort von 193.238.158.154: Bytes=32 Zeit=41ms TTL=59
>> Antwort von 193.238.158.154: Bytes=32 Zeit=41ms TTL=59
>> Zeitüberschreitung der Anforderung.
>> Antwort von 193.238.158.154: Bytes=32 Zeit=23ms TTL=59 - vermutliche
>> Tunnelrückkehr
>> Antwort von 193.238.158.154: Bytes=32 Zeit=30ms TTL=59
>> Antwort von 193.238.158.154: Bytes=32 Zeit=41ms TTL=59
>> Antwort von 193.238.158.154: Bytes=32 Zeit=30ms TTL=59
>> Antwort von 193.238.158.154: Bytes=32 Zeit=17ms TTL=59
>> Antwort von 193.238.158.154: Bytes=32 Zeit=36ms TTL=59
>> Antwort von 193.238.158.154: Bytes=32 Zeit=24ms TTL=59
>> Antwort von 193.238.158.154: Bytes=32 Zeit=46ms TTL=59
>> Antwort von 193.238.158.154: Bytes=32 Zeit=25ms TTL=59
>> Antwort von 193.238.158.154: Bytes=32 Zeit=34ms TTL=59
>> Antwort von 193.238.158.154: Bytes=32 Zeit=31ms TTL=59
>>
>>
>>
>>
>> *To:* Erich <(spam-protected)> ; (spam-protected)
>> *Sent:* Sunday, December 28, 2008 1:22 PM
>> *Subject:* Re: lichtwicht tunnel & heuberg
>>
>> 2008/12/28 Erich <(spam-protected)>
>>
>>> Hallo!
>>>
>>> Angeblich geht das Internet in Haslau recht schlecht und ich vermute es
>>> liegt am Lichtwicht Tunnel.
>>
>> ja der liechtwicht linksys ist überlastet (weniger das adsl, sondern der
>> linksys), hab die letzten Tage in mehrere Schritten seine performance zwar
>> etwas erhöht (andere tunnelkonfigurationen) (dadurch gabs natürlich auch
>> Ausfälle) und glaub vorgestern war für 18h dach&keller am liechtwicht
>> komplett getrennt,.. (d.h. niemand ging über den tunnel), aber im endeffekt
>> hilft nur das blocken von 1-2 fileshare-usern
>>
>> darum hab ich dann gestern abends ein automatisches blocking skript
>> getestet,.. (ist nicht der weisheit letzter schluss, aber die alternative
>> ist den liechtwicht tunnel komplett down zu nehmen,..)
>>
>> das nun seit heute 12:20 im regelbetreib ist, mit dem zweck eben nur die
>> user auszubremsen die den liechtwicht überlasten (filesharer), und dadurch
>> totalausfälle zu vermeiden,.. obs hilft sieht man dann hier
>>
>> http://193.238.157.78/~markus/connstat/view?host=193.238.158.154
>>
>>> Heunord dürfte ja nicht mehr über 5 Ghz direkt mit dem vivi verbunden
>>> sein.
>>
>> Ist schon seit etichen Wochen ausgefallen/bzw. unbrauchbar und darum
>> abgeschaltet,..bishereige versuche die situation zu verbessern waren aber
>> nie allzuerfolgreich (andere lange geschichte)
>>
>>> Daher ändert sich die Route hin und wieder von heunord_h1auf schenk10v1
>>
>> spengergasse wäre normalerweise ein brauchbares backup für den heuberg,
>> aber akku hat auf der ma89 antennen geändert, und somit hat die spengergasse
>> auch keinen brauchbaren link zu ma89 (->zeltgasse)->vivi mehr,..
>>
>>>
>>> Die Route zum Lichtwicht ändert sich ständig von Tunnelserver auf
>>> spenger25 und wieder retour.
>>
>> das ändern der routen ist normal bei olsr, und tritt immer auf wenn 2
>> alternativen beinahe gleich gut sind, irgendwo tritt das immer auf,.. (d.h.
>> wenn ich den lqmult der am tunnel des liechtwichts liegt senke/erhöhe dann
>> halt nicht bei den routern in haslau sondern bei nem anderen knoten)
>>
>> aber wenn ich mir das anschaue
>>
>> http://193.238.157.78/~markus/connstat/view?host=193.238.159.120
>>
>> sieht das ziemlich genauso aus wie der chart vom liechtwicht, haslau
>> routet also eh die meiste zeit übern liechtwicht, nur wenn der aufgrund
>> massivster überlastung nichtmal mehr ressourcen fürn olsr hat, wird in
>> haslau gewechselt,..
>>
>>> Da viele Router über Lichtwicht routen
>>
>> ja idr (deutlich) mehr als 60,..
>>
>>> , nehme ich an, dass das ganze Netz in dem Bereich etwas instabil ist. Im
>>> Lichtwicht-Syslog stand auch kurz hintereinander OLSR restart und sonst nur
>>> restarting wifi.
>>
>> wenn ich garade dort eingeloggt war nicht, ansonst schon,..
>> also wann ???
>>
>>> Hat vermutlich nichts zu bedeuten. Ich nehme an der Tunnel ist einfach
>>> überlastet.
>>
>> was aber keinen olsr restart auslösen kann/darf,..
>>
>>> Komischerweise ändern sich die Werte LQ NLQ ETX für 78.41.112.2 nie.
>>
>> nunja das ADSL ist ja nicht überlastet, sondern der linksys, und olsr
>> traffic wird sowieso priorisiert, und ist damit vergleichsweise immun gegen
>> überlastung (das ist auch gut so, der ETX würde eh nur zu schwingen
>> beginnen, was noch störender ist, weil unser olsr-mesh zulangsam dafür ist)
>> lg Markus
>>
>>
>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/wien/attachments/20081228/718ec27d/attachment.htm>
Mehr Informationen über die Mailingliste Wien