xDSL.at

Hallo,

das hat nicht so wirklich in einen der anderen Threads gepaßt, da ich nicht wirklich aus Salzburg bin etc.

Ich bin relativ neuer xdsl@home-flat 1024 Kunde in 1090 Wien mit einem inode-eigenen Zyxel650h und hätte daher einige dämliche kleine Fragen---

Zuvorderst zwei Situationsbeschreibungen:

1.) Habe eigentlich immer schon massive routingprobleme zu einem Teil der Welt, namentlich besonders east coast USA. Die jeweiligen urls können zwar einwandfrei aufgelöst werden, aber es schlägt nicht mal ein ping zu den jeweiligen hosts durch. Die traces sterben jeweils in der Region um

Code: Alles auswählen

ott2-gb-04-003.shuttle.vien.inode.at

oder aber auch

Code: Alles auswählen

so-2-1-0.cr2.vie2.at.above.net

oder manchmal geht es gar so aus (ein schöner beispieltrace, gemacht um 23:54:15): [link zur txtfile zum platzsparen]
- während, wenn ich über einen gratisproxy fahre, die jeweiligen hosts perfekt erreichen kann.

2.) Seit Bestehen des Anschlusses eigentlich pro Tag nur wenige Stunden einwandfreier Betrieb; meistens aber derartige Scherze:

Code: Alles auswählen

Routenverfolgung zu www.vix.at [131.130.1.84]  über maximal 30 Abschnitte:

  1   <10 ms   <10 ms   <10 ms  10.70.0.1
  2  2219 ms  2718 ms  2750 ms  ga12-lo-00-000.shuttle.vien.inode.at [62.99.171.
103]
  3  3360 ms  2703 ms  2578 ms  bord-vl-00-499.shuttle.vien.inode.at [62.99.171.
177]
  4  2609 ms  2485 ms  3156 ms  otta-gb-03-001.shuttle.vien.inode.at [62.99.170.
5]
  5  3218 ms     *     2984 ms  Wien1.ACO.net [193.203.0.1]
  6  2484 ms     *       62 ms  ares.cc.univie.ac.at [193.171.13.22]
  7  2687 ms  2906 ms  1953 ms  virtual.univie.ac.at [131.130.1.84]

das geht dann stundenweise so; ich hab es aufgegeben die Zeiten zu notieren weil ich effizienter arbeite indem ich einfach nur mehr Zeiträume angebe ;)

Dabei auch massiver loss, z.b. ergibt ein 50-packet ping auf vix.at einen Ergebnis von

Code: Alles auswählen

Ping-Statistik für 131.130.1.84:
    Pakete: Gesendet = 50, Empfangen = 28, Verloren = 22 (44% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 548ms, Maximum =  3280ms, Mittelwert =  2504ms

wobei man nicht glauben sollte, daß das an vix liegt, denn auch ein ping auf die inode ns1 und ns2 ergibt ungefähr dasselbe. Das ist natürlich auch von einem massiven Einbruch der Bandbreite begleitet - so zwischen 7 und 25 kB/sec.

Aussteiger / desyncs gab es seit Freitag 5-6 relativ kurze, bei denen geduldiges Warten die beste Medizin war, den letzten von 00:26:11 bis 00:29:40. Zyxel ein/aus hat übrigens nie zu was fruchtbarem geführt.

Nun die eigentlichen Fragen zu obigen Situationen:

1.) Bin nur ich davon betroffen oder ist das einfach allgemein so?

2.) Macht es Sinn in diesem Fall den support zu belästigen oder ist das [2.)] einfach am Wochenende so, weil da die Auslastung höher ist?

3.) Ist irgendwas von wegen maintenance bekannt, die die Leitungsprobleme erklären würde bzw. gibt es für Kunden zugängliche infos über anstehende Wartungen/Umbauten usw und ich hab die bloss nicht gefunden?

Falls du derartige Probleme hast, solltest du dich primär an den Inode-Support wenden, dieser ist im Allgemeinen für seine Hilfsbereitschaft und Problemlösungsbereitschaft bekannt.
Bei meiner Leitung habe ich jedenfalls noch nie derartige Probleme festgestellt.

> 3.) Ist irgendwas von wegen maintenance bekannt, die die Leitungsprobleme erklären würde bzw. gibt es für Kunden zugängliche infos über anstehende Wartungen/Umbauten usw und ich hab die bloss nicht gefunden?

findest du hier: http://www6.inode.at/kundenbereich/status.php
grundsaetzlich werden wartungsarbeiten nach moeglichkeit in den fruehen morgenstunden (so ca zwischen 2 und 5, 6) durchgefuehrt.

Danke für den Hinweis.

Tezcatlipoca Itlachiayaqu hat geschrieben:oder manchmal geht es gar so aus (ein schöner beispieltrace, gemacht um 23:54:15): [link zur txtfile zum platzsparen]

ist das ein fehler im textfile oder warum ist die reihenfolge der hops wild durcheinandergewürfelt?

1.) Bin nur ich davon betroffen oder ist das einfach allgemein so?

ist sicher nicht allgemein so.

2.) Macht es Sinn in diesem Fall den support zu belästigen oder ist das [2.)] einfach am Wochenende so, weil da die Auslastung höher ist?

derartiges verhalten der anbindung ist wohl kaum akzeptabel und muß behoben werden. auch zu zeiten stärkster auslastung darf sowas nicht sein. darum bitte kd-nr oder username o.ä., dann werd ichs checken.

Kein fehler im textfile. Die above-net Purschen scheinen ja die Route vor und zurückzuschieben wie wild ;). Sieht übrigens im normalen tracert genauso aus wenn man die 30er beschränkung wegnimmt, nur macht das winmtr das ganze sauberer ;)
Auch: Das ging mir übrigens vor 5 Jahren so als ich bei VOL/Teleport war und Teleport wegen irgendwas in die schweizer blacklists geriet; da wurde dann beim Versuch Genf zu erriechen ab Lausanne zwischen dort & VOL-endpoint hin und hergeroutet ohne Ergebnis...

Code: Alles auswählen

derartiges verhalten der anbindung ist wohl kaum akzeptabel und muß behoben werden. auch zu zeiten stärkster auslastung darf sowas nicht sein. darum bitte kd-nr oder username o.ä., dann werd ichs checken.

kdnr ist 109627, merci vielmals im Voraus für die mühe

Tezcatlipoca Itlachiayaqu hat geschrieben:Kein fehler im textfile. Die above-net Purschen scheinen ja die Route vor und zurückzuschieben wie wild

das glaub ich nicht. das verrückte ist ja, daß mittendrin weit hinten im trace plötzlich wieder inode.at hosts auftauchen. das kann so nicht stimmen (ga12-*.inode.at hat zb keinen direkten link zu irgedeinem above.net host, schon gar nicht zu einem britischen, genausowenig wie otta-*.inode.at einen hat, außerdem ist dein erster hop nach deinem lokalen gateway sicher kein above.net host). welchen host genau hast du da getracet?

routing loops gibt's ja schon, aber die sehen dann doch anders aus. ich denke eher, da ist auf deiner seite was gröberes hin. ping von aussen auf deinen p650 schaut nämlich gut aus (von graz weg):

500 packets transmitted, 500 packets received, 0% packet loss
round-trip min/avg/max = 23.0/27.2/66.9 ms

ping auf deinen pc dahinter hab ich wegen firewall leider nicht machen können.

Trace lief auf 66.98.168.4 - und ja, routing loops sehen anders aus, daher das ";)" - das ganze macht eigentlich wenig sinn.

ich denke eher, da ist auf deiner seite was gröberes hin. ping von aussen auf deinen p650 schaut nämlich gut aus (von graz weg):

500 packets transmitted, 500 packets received, 0% packet loss
round-trip min/avg/max = 23.0/27.2/66.9 ms

ping auf deinen pc dahinter hab ich wegen firewall leider nicht machen können.

witzig auch, bei mir sieht's im moment so aus:

Code: Alles auswählen

Ping-Statistik für www.vix.at (131.130.1.84):
    Pakete: Gesendet = 50, Empfangen = 50, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 16ms, Maximum =  31ms, Mittelwert =  22ms

Nur leider hat das während der letzten Tage nicht wirklich angehalten (habe gestern auch ein mail an den inode-support geklopft, weil der Zyxel angefangen hat massivst auszusteigen, so im 10-minutentakt war der immer wieder weg) ...

re: "ich denke eher, da ist auf deiner seite was gröberes hin"

Falls ich dich da richtig verstehe, meinst du daß da clientseitig was nicht stimmt, ja? Nur, der Fehler tritt maschinenunabhängig auf (hab' auch schon die gentookisten angehängt wenn's mal wieder ganz arg war -> dort dasselbe problem; anderer w2k rechner -> ebenfalls das gleiche, ...), sonst würd' ich eh niemand damit belästigen


Trotzdem Danke fürs nachschaun


N.B.: Firewall blockt ICMP jetzt nicht mehr.

so, ich hab mal versucht, die situation 1:1 nachzustellen... hab das komische traceroute zwar nicht nachvollziehen können, bin dadurch aber auf ein nettes anderes problem draufgekommen und hab dieses auch fixen lassen. vielleicht haben die zwei geschichten ja miteinander was zu tun, kannst du mal testen, ob sich was getan hat?

Etwas getan hat sich, allerdings nicht ganz so, wie Du es Dir vielleicht gewünscht hättest - aber doch!
aaalso:

Code: Alles auswählen

Routenverfolgung zu 66.98.168.4 [66.98.168.4]  über maximal 30 Abschnitte:

  1   <10 ms   <10 ms   <10 ms  10.70.0.1
  2    15 ms    47 ms    32 ms  gar2-lo-00-000.shuttle.vien.inode.at [62.99.171.166]
  3    16 ms    16 ms    31 ms  bord-vl-00-500.shuttle.vien.inode.at [62.99.171.113]
  4    31 ms    16 ms    31 ms  ott2-gb-04-003.shuttle.vien.inode.at [62.99.170.45]
  5    31 ms    16 ms    15 ms  otta-gb-03-008.shuttle.vien.inode.at [62.99.171.249]
  6    15 ms    32 ms    15 ms  ge3-2.mpr2.vie4.at.above.net [212.69.164.10]
  7    16 ms    31 ms    15 ms  so-2-1-0.cr2.vie2.at.above.net [208.184.231.82]
  8    47 ms    31 ms    63 ms  so-3-0-0.cr1.fra1.de.above.net [212.69.164.17]
  9   156 ms   156 ms   141 ms  pos1-0.mpr1.fra2.de.above.net [216.200.115.254]
10   109 ms    62 ms    63 ms  so-4-2-0.cr1.lhr3.uk.above.net [64.125.29.77]
11   125 ms   125 ms   125 ms  so-7-0-0.cr1.dca2.us.above.net [64.125.31.186]
12   141 ms   156 ms   141 ms  pos1-0.mpr2.atl4.us.above.net [64.125.29.41]
13   141 ms   156 ms   141 ms  pos13-0.er1.atl4.us.above.net [64.125.30.237]
14   140 ms   156 ms   172 ms  so-3-3-0.mpr2.iah1.us.above.net [64.125.29.66]
15   140 ms   157 ms   140 ms  216.200.251.29.ev1.net [216.200.251.29]
16   156 ms   156 ms   157 ms  ivhou-207-218-245-112.ev1.net [207.218.245.112]
17     *        *        *     Zeitüberschreitung der Anforderung.
18     *        *        *     Zeitüberschreitung der Anforderung.
19     *        *        *     Zeitüberschreitung der Anforderung.
20     *        *        *     Zeitüberschreitung der Anforderung.
21     *        *        *     Zeitüberschreitung der Anforderung.
22     *        *        *     Zeitüberschreitung der Anforderung.
23     *        *        *     Zeitüberschreitung der Anforderung.
24     *        *        *     Zeitüberschreitung der Anforderung.
25     *        *        *     Zeitüberschreitung der Anforderung.
26     *        *        *     Zeitüberschreitung der Anforderung.
27     *        *        *     Zeitüberschreitung der Anforderung.
28     *        *        *     Zeitüberschreitung der Anforderung.
29     *        *        *     Zeitüberschreitung der Anforderung.
30     *        *        *     Zeitüberschreitung der Anforderung.

man beachte, daß die pseudo-loops weg sind...


das Problem mit den horrenden Pings scheint einstweilen aber verschwunden - man klopfe auf Holz!

Ich hab's hier noch gar nicht erwähnt, aber dem support schon mitgeteilt - es gibt ja eigentlich noch mehr probleme, .z.b. daß, wenn ich den VPN aufbau (was, den installationsanleitungsschritten folgend, an sich einwandfrei funktioniert), dann die Verbindung zur Außenwelt weg ist; sowie ich den VPN kapp' geht alles wieder -- oder daß der mailserver mich partout nicht mag, weder bei der standardmailbox noch bei den selbsteingerichteten (""-ERR Re-Authentication Failure" / "IMAP Verbindungs-Timeout. Es kann sein, daß der Benutzer noch nicht vollständig eingerichtet wurde."). Aber zumindest das eine mit dem plötzlichen Leitungstod scheint behoben - uffa!

Jejeje, zu früh gefreut:

Code: Alles auswählen

Routenverfolgung zu www.vix.at [131.130.1.84]  über maximal 30 Abschnitte:

  1   <10 ms   <10 ms    16 ms  10.70.0.1
  2  2344 ms  2516 ms  2781 ms  gar2-lo-00-000.shuttle.vien.inode.at [62.99.171.166]
  3  2562 ms  2438 ms  2859 ms  bord-vl-00-499.shuttle.vien.inode.at [62.99.171.177]
  4  2750 ms  2344 ms  2406 ms  ott2-gb-04-003.shuttle.vien.inode.at [62.99.170.45]
  5  2625 ms  2922 ms  2969 ms  otta-gb-03-008.shuttle.vien.inode.at [62.99.171.249]
  6  2672 ms  2891 ms  2734 ms  Wien1.ACO.net [193.203.0.1]
  7  2266 ms  2297 ms  2187 ms  ares.cc.univie.ac.at [193.171.13.22]
  8  2235 ms  2531 ms  2609 ms  virtual.univie.ac.at [131.130.1.84]

Ablaufverfolgung beendet.

und:

Code: Alles auswählen

ping -n 50 -w 4000 ns1.inode.at
Ping-Statistik für 195.58.160.2:
    Pakete: Gesendet = 50, Empfangen = 50, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 1922ms, Maximum =  3313ms, Mittelwert =  2109ms

womit wir wieder beim Anfang wären :o

Tezcatlipoca Itlachiayaqu hat geschrieben:

Ich hab's hier noch gar nicht erwähnt, aber dem support schon mitgeteilt - es gibt ja eigentlich noch mehr probleme, .z.b. daß, wenn ich den VPN aufbau (was, den installationsanleitungsschritten folgend, an sich einwandfrei funktioniert), dann die Verbindung zur Außenwelt weg ist; sowie ich den VPN kapp' geht alles wieder -- oder daß der mailserver mich partout nicht mag, weder bei der standardmailbox noch bei den selbsteingerichteten (""-ERR Re-Authentication Failure" / "IMAP Verbindungs-Timeout. Es kann sein, daß der Benutzer noch nicht vollständig eingerichtet wurde."). Aber zumindest das eine mit dem plötzlichen Leitungstod scheint behoben - uffa!

hast du dir schon mal ein mail an deine mail-addi bei inode geschickt - soll manchmal wunder bewirken, das man dann den account benutzen kann.

@Tezcatlipoca Itlachiayaqu: naja... nachdem ich mir das jetzt angeschaut hab, kann ich nur sagen: wenn du emulest wie verrückt, dann darfst dich über solche pings nicht wundern...

Code: Alles auswählen

Node-Lnk Status      TxPkts      RxPkts      Errors  Tx B/s  Rx B/s     Up Time
1-PPPoE Up         5021025     5919778           0   22129   23583    22:54:52

dfx hat geschrieben:naja... nachdem ich mir das jetzt angeschaut hab, kann ich nur sagen: wenn du emulest wie verrückt, dann darfst dich über solche pings nicht wundern...

naja man wirds ja noch probieren dürfen ....

dfx hat geschrieben:@Tezcatlipoca Itlachiayaqu: naja... nachdem ich mir das jetzt angeschaut hab, kann ich nur sagen: wenn du emulest wie verrückt, dann darfst dich über solche pings nicht wundern...

Code: Alles auswählen

Node-Lnk Status      TxPkts      RxPkts      Errors  Tx B/s  Rx B/s     Up Time
1-PPPoE Up         5021025     5919778           0   22129   23583    22:54:52

Ehrlich gesagt, hab' ich auch schon daran gedacht, und sogar durchgetestet, aber auch wenn nur 7 conns offen sind (1-irssi, 4-firefox, 2-thunderbird), tritt dasselbe Problem auf.
Würde das ganze direkt damit zusammenhängen was ich am laufen hab, hätt' ich mich gar nicht erst gemolden ;)

Umgekehrt kann genausogut emule laufen und der Ping bleibt stabil um die 16-32 - vielleicht stell ich mich saudumm an, aber das scheint mir nicht (zumindest nicht die einzige) Ursache zu sein...