<br><div class="gmail_quote"><div>nun das ist ja auch nicht verwunderlich (das subway - kryptaroof keinen packetloss haben)<br></div><div>denn ich tippe mal darauf dass weder der subway noch der kryptaroof irgendwie schuld an der situation haben</div>
<div>sondern der tunnelserver (wie ich ja schon gestern geschrieben habe)</div><div>denn versuchst du den subway direkt vom kryptaroof zu pingen hast du keinen packetloss weil die antworten des subway direkt zugestellt werden,..</div>
<div>fuer ips aus dem freenet routet der subway diese via tunnelserver, und dieser hat nunmal immerweidermal 100% load dank durchdrehenden openvpn</div><div>allerdings war ich gestern abend nicht erfolgreich rauszufinden was genau das auslöst, denn nach einen openvpn restart ist idr eine unbestimmt lange zeit alles in ordnung,.. und dann hat er ploetzlich wieder (0% idle)</div>
<div>durch diese "unbestimmt lange zeit" wird eine binäre suche ob es an einem bestimmten tunnel liegt ziemlich langwierig (und dafuer hab ich keine zeit), und ich bin mir eh nicht sicher ob es ueberhaupt an einem einzelnen tunnel liegt,..</div>
<div>.</div><div>was ich jetzt mal machen werde ist die ospf cost des tunnelserver hochzuziehen so dass nicht aller incoming traffic durch ihn durchgerotet wird,..</div><div>mittelfristig sollten wir aber entweder rausfinden was mit openvpn am tunnelserver los ist, oder unsre tunnel auf (sowieso performantere) ipip oder gre tunnel umstellen denn layer2 tunnel brauchen wir ja eigentlich eh nicht</div>
<div>lg Markus</div><br><div class="gmail_quote">2009/7/9 Clemens Hopfer <span dir="ltr"><<a href="mailto:datacop@wireloss.net">datacop@wireloss.net</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Das komische ist ja, dass die Router selber kein Problem damit haben...<br>
Soeben ist mein Traceroute beim Kryptaroof stehen geblieben, bis zum subway<br>
kam es nicht, auch die Pings sind dort verreckt.<br>
Vom Kryptaroof selbst konnt ich aber in der Zeit subway ohne Probleme<br>
erreichen, auch ein Floodping zeigte keine Auffälligkeiten, avg 0,1ms, max<br>
8ms<br>
<br>
Mir würde nur das Policy Routing als Fehlerquelle einfallen...<br>
<br>
cu,<br>
Clemens<br>
<br>
Am Donnerstag 09 Juli 2009 14:21:11 schrieb akku:<br>
<div><div class="h5">> zwischen br33.kryptaroof und subway treten immer wieder mal<br>
> hintereinander verzögerungen von 0.5 bis über 1 sekunde auf<br>
> das hält manchmal stundenlange manchmal nur 20 sekunden lange an<br>
><br>
> dann ist wiedermal stunden tage lange nur wenige ms<br>
> schlechte tage waren samstag mittwoch und heute fangt es auch gerade<br>
> wieder an<br>
> betroffen vivi und krypta :( bis 40% paketlos !<br>
><br>
> schön im smokeping zu sehen<br>
> <a href="https://marvin.funkfeuer.at/cgi-bin/smokeping/freenet.cgi?target=vivi.vivir" target="_blank">https://marvin.funkfeuer.at/cgi-bin/smokeping/freenet.cgi?target=vivi.vivir</a><br>
>oof<br>
> <a href="https://marvin.funkfeuer.at/cgi-bin/smokeping/freenet.cgi?target=kryptaroof" target="_blank">https://marvin.funkfeuer.at/cgi-bin/smokeping/freenet.cgi?target=kryptaroof</a><br>
>.eth1<br>
><br>
> hf akku<br>
><br>
> L. Aaron Kaplan schrieb:<br>
> > mtr ist ein sehr cooles tool.<br>
> ><br>
> >> von wo aus pingst du bzw. hast du schon mal versucht den Pfad zu<br>
> >> tracen?<br>
> >> Es kann sein, dass es zu den unterschiedlichen Gateways in der Krypta<br>
> >> unterschiedliche Pfade gibt.<br>
> ><br>
> > lg,<br>
> > a.<br>
> ><br>
> ><br>
> > --<br>
> > Wien mailing list<br>
> > <a href="mailto:Wien@lists.funkfeuer.at">Wien@lists.funkfeuer.at</a><br>
> > <a href="http://lists.funkfeuer.at/mailman/listinfo/wien" target="_blank">http://lists.funkfeuer.at/mailman/listinfo/wien</a><br>
<br>
<br>
<br>
--<br>
Wien mailing list<br>
<a href="mailto:Wien@lists.funkfeuer.at">Wien@lists.funkfeuer.at</a><br>
<a href="http://lists.funkfeuer.at/mailman/listinfo/wien" target="_blank">http://lists.funkfeuer.at/mailman/listinfo/wien</a></div></div></blockquote></div><br>
<br>
</div><br>