We are in the process of migrating this forum. A new space will be available soon. We are sorry for the inconvenience.

Routing nach Österreich (UPC und Telekom Austria)


eVolvE
30.09.14, 16:45
Bin erst jetzt dazu gekommen mir das weiter anzuschauen. Nachdem ich alle logfiles durchsucht hatte, die Configs gecheckt habe etc. und nichts auffälliges entdeckt habe, hab ich mich dazu entschlossen meinen FTP-Client neu zu installieren. Siehe da, jetzt klappts wieder. Lag also scheinbar doch nicht am Server und auch nicht am Routing, sondern wie immer am DAU vorm Rechner

Naja, danke trotzdem für deine Hilfe. Komm mir jetz mal wieder extra dumm vor.

tester
23.09.14, 21:40
Da bei mir auch andere Testfiles schlechte Speedwerte aufzeigen ist heute bei UPC wohl gerade happy Dienstag...
vielleicht verstopft jetzt Netflix auch in der EU peerings

Aus deiner Sicht würde ich mal die Serverconfig checken...
Was macht dein Server sonst noch?

eVolvE
23.09.14, 21:20
Okok.

Gegengetestet mit folgenden Downloads:
1) http://mirror.nl.leaseweb.net/speedtest/1000mb.bin
http://i.imgur.com/J9Lyd9l.jpg

2) http://mirror.de.leaseweb.net/speedtest/1000mb.bin
http://i.imgur.com/XMLD1hZ.jpg

3) und hier wird's interessant weil ebenfalls bei OVH: http://rbx.proof.ovh.net/files/1Gio.dat
http://i.imgur.com/t6cH0UC.jpg

Die letzten beiden sind für mich normal. Das OVH Testfile ist wohl besonders interessant. Aber was mach ich jetzt mit der Info? Worauf deutet das hin?

Thx übrigens für deine Hilfe.

tester
23.09.14, 21:04
Das sagt mir das wir zwar beide schwankende speeds haben, ich nicht so schlimm wie du - jedoch alle Datenpakete ankommen.

Ich lege das bei UPC in die Ablage "sucht euch mal gute Netzwerker"
hab das einfach zeitenweise...

Zieh du mal ein Testfile von einem anderen großen Hoster und prüfe mal gegen obs an der TA oder OVH liegt..

eVolvE
23.09.14, 20:59
Ah ok.

Ping vom Server zu mir:
Code:
--- 178.191.169.xxx ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99122ms
rtt min/avg/max/mdev = 33.982/35.157/36.805/0.541 ms
und umgekehrt:
Code:
Ping-Statistik für 5.135.177.xxx:
    Pakete: Gesendet = 287, Empfangen = 287, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 38ms, Maximum = 53ms, Mittelwert = 39ms
Dann sieht da ja eigentlich gut aus. Hmm. Also liegts am FTP?

tester
23.09.14, 20:45
nein, ich meinte tatsächlich einen ping...
ping 1.2.3.4 -n 60


>Schaut nicht gerade toll aus.
10 178-191-169-xx.adsl.highway.telekom.at (178.191.169.xx) 34.511 ms 34.929 ms 35.717 ms

35ms sind für adsl ja normal...

eVolvE
23.09.14, 20:41
Hey tester,

hatte bisher wirklich nie Probleme seit ich vor einigen Jahren zu A1 wechselte, erst neuerdings.
Ich nehm an du meintest einen Traceroute und keinen Ping, oder?

Traceroute von mir zu OVH:
Code:
Routenverfolgung zu 5.135.177.xxx
über maximal 30 Hops:

  1     1 ms     1 ms     1 ms  A1MODEM [10.0.0.138]
  2    21 ms    17 ms    15 ms  178-191-175-254.adsl.highway.telekom.at [178.191.175.254]
  3     *       16 ms    15 ms  195.3.68.114
  4    15 ms    15 ms    16 ms  195.3.68.113
  5    15 ms    17 ms    18 ms  195.3.70.50
  6     *       89 ms   201 ms  vix.vie-1-6k.routers.ovh.net [193.203.0.151]
  7     *       21 ms    21 ms  pra-1-6k.cz.eu [213.251.128.97]
  8     *        *        *     Zeitüberschreitung der Anforderung.
  9    37 ms    37 ms    37 ms  rbx-g2-a9.fr.eu [94.23.122.117]
 10     *       35 ms     *     vss-9b-6k.fr.eu [178.33.100.74]
 11    36 ms    35 ms    36 ms  5.135.177.xxx

Ablaufverfolgung beendet.
Vom Server zu mir:
Code:
traceroute  178.191.169.xx
traceroute to 178.191.169.xx (178.191.169.xx), 30 hops max, 60 byte packets
 1  vss-9a-6k.fr.eu (5.135.177.253)  0.322 ms * *
 2  rbx-g2-a9.fr.eu (91.121.131.157)  1.027 ms  1.495 ms  1.488 ms
 3  * fra-5-6k.fr.eu (91.121.131.133)  9.359 ms *
 4  pra-1-6k.cz.eu (213.251.128.109)  15.808 ms * *
 5  vie-1-6k.at.eu (213.251.128.98)  20.322 ms * *
 6  vix2.highway.telekom.at (193.203.0.11)  26.549 ms  25.668 ms  25.539 ms
 7  AUX10-IIX11.highway.telekom.at (195.3.70.217)  20.270 ms 195.3.118.29 (195.3.118.29)  20.210 ms  20.173 ms
 8  195.3.68.114 (195.3.68.114)  4266.588 ms  2810.430 ms  2904.989 ms
 9  178-191-175-254.adsl.highway.telekom.at (178.191.175.254)  30.138 ms  25.749 ms  24.989 ms
10  178-191-169-xx.adsl.highway.telekom.at (178.191.169.xx)  34.511 ms  34.929 ms  35.717 ms

tester
23.09.14, 20:39
@evolve

das beim Router anpingen(was dein mtr macht) packetloss auftritt ist normal!
Das wollte Marius damit uns/dir mitteilen.

Pinge doch mal direkt wie ich bereits vorgeschlagen habe und lass uns das ergebnis von 1 Minute oder länger zukommen...
Für längere Beobachtungen eignet sich smokeping recht gut

eVolvE
23.09.14, 20:31
[Edit: nur damit hier keine Missverständnisse auftreten, diese Antwort ist an Marius gerichtet] Also ist da in deinen Augen alles normal? Für mich nämlich nicht. Erstens gibt's 100erte Beispiele im Internet von MRT Reports die ohne Packet Loss ablaufen und selbst wenn auf ICMP requests nicht immer geantwortet wird soll mir das zwar recht sein, aber das hier kein Problem vorliegt lass ich mir nicht einreden. Ich weiß nicht ob du die Grafik unten gesehen hast, aber normal ist das nicht.

Ich hab versucht möglichst viele Informationen bereitzustellen, und mich an das gehalten was die User weiter oben auch in etwa bereitgestellt haben. Ich kann nur von meinen derzeitigen und bisherigen Erfahrungen berichten. Ich bin seit 5 Jahren Kunde bei OVH, hatte ungefähr 1 Jahr lang grobe Probleme mit UPC (die hier auch im Thread nachvollziehbar sind), bin anschließend zu A1 gewechselt und hatte seither nie Probleme bis mir eben vor einigen Tagen zum ersten Mal aufgefallen ist das es jetzt offenbar welche gibt.

Falls du mir Tipps geben kannst wie ich deiner Meinung nach effektiver rausfinden kann wo das Problem liegt, bin ich gerne bereit dir zuzuhören, andernfalls wirkt dein Post einfach nur so als würdest du gerne deinen Postcount erhöhen.

MfG

tester
23.09.14, 20:25
ping mal direkt von deinem pc zuhause auf OVH und umgekehrt auf deinen Router zuhause....

deinen speedgraph via FTP kann ich vom UPC Netz aus bestätigen, der Durchsatz ist heute/jetzt gerade sehr schlecht...

Österreich braucht endlich mal einen guten Internetprovider!




http://weathermap.ovh.net/wien


Routenverfolgung zu *-ext [188.165.197.x]
über maximal 30 Hops:

1 <1 ms 1 ms <1 ms OpenWrt.lan [10.0.0.1]
2 2 ms 1 ms 2 ms FRITZ-NAS [192.168.178.1]
3 41 ms 36 ms 16 ms 84.116.231.161
4 13 ms 14 ms 16 ms 84.116.229.209
5 15 ms 14 ms 13 ms at-grz-lazg-pe01-vl-2086.upc.at [84.116.229.81]
6 33 ms 32 ms 32 ms at-vie01a-rd1-vl-2031.aorta.net [84.116.228.81]
7 36 ms 38 ms 35 ms us-was02a-rd1-pos-1-0.aorta.net [213.46.160.106]
8 32 ms 34 ms 31 ms 84.116.132.170
9 40 ms 44 ms * fra-5-6k.de.eu [91.121.131.77]
10 45 ms 45 ms 43 ms rbx-g2-a9.fr.eu [91.121.131.134]
11 * 40 ms 40 ms vss-3-6k.fr.eu [213.251.130.77]
12 41 ms 41 ms 41 ms *-ext [188.165.197.x]

Ablaufverfolgung beendet.



Routenverfolgung zu 85-127-74-x.dynamic.xdsl-line.inode.at [85.127.74.x]
über maximal 30 Hops:

1 35 ms 1 ms * vss-3b-6k.fr.eu [188.165.197.252]
2 1 ms 1 ms 1 ms rbx-g1-a9.fr.eu [213.186.32.253]
3 * * * Zeitüberschreitung der Anforderung.
4 * 8 ms * fra-5-6k.fr.eu [94.23.122.222]
5 59 ms 203 ms 120 ms pra-1-6k.cz.eu [213.251.128.109]
6 201 ms 207 ms 198 ms vie-1-6k.at.eu [213.251.128.98]
7 * * * Zeitüberschreitung der Anforderung. [Dieser Router antwortet nie, laut Weathermap müssten da ja noch welche kommen ]
8 27 ms 27 ms 30 ms 213.46.173.126
9 27 ms 27 ms 27 ms at-grz-lazg-pe02-vl-2032.upc.at [84.116.228.86]
10 24 ms 23 ms 23 ms at-grz-mk43-pe01-vl-2084.upc.at [84.116.229.74]
11 27 ms 27 ms 27 ms 84.116.229.122
12 38 ms 40 ms 38 ms 85-127-74-x.dynamic.xdsl-line.inode.at [85.127.74.x]

Ablaufverfolgung beendet.

us-was02a-rd1-pos-1-0.aorta.net [213.46.160.106]
ist wohl aufgrund des niedrigen Pings falsch...

marius
23.09.14, 20:00
Zitat Zitat von eVolvE
Was ist da los? Der PacketLoss scheint ja schon ganz früh und noch im OVH-Netz zu passieren. Könnt ihr das mal prüfen und hoffentlich beheben. Bin ich der einzige dem das hier auffällt?
Da tritt kein Packet Loss auf.
Die Router antworten nur nicht immer auf ICMP requests, was völlig normal ist.

eVolvE
23.09.14, 19:36
Tut mir leid das ich den Thread mal wieder hervorholen muss, aber ich kann momentan nichts gutes über die Verbindung zwischen A1 und OVH berichten, oder generell irgendwohin.

Hier mal 3 MTR Reports vom Server zu einigen Zielen:
1. Ziel mein Rechner zu Hause, Provider A1
Code:
mtr --report  178.191.169.77
HOST: ks3285350.kimsufi.com       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- vss-9a-6k.fr.eu           50.0%    10    0.5   2.8   0.4  12.1   5.2
  2.|-- rbx-g2-a9.fr.eu            0.0%    10    1.0   1.1   0.8   2.2   0.4
  3.|-- fra-5-6k.fr.eu            70.0%    10    8.4  36.6   8.4  52.9  24.5
    |  `|-- 94.23.122.118
  4.|-- pra-1-6k.cz.eu            10.0%    10  182.0  97.1  15.9 182.0  72.4
  5.|-- vie-1-6k.at.eu            10.0%    10  109.3  33.8  19.9 109.3  30.4
  6.|-- vix2.highway.telekom.at    0.0%    10   23.8  27.4  22.5  30.1   2.7
  7.|-- 195.3.70.53                0.0%    10   20.3  21.0  20.3  23.3   1.0
  8.|-- 195.3.68.114               0.0%    10   21.2  26.3  21.2  38.0   5.6
  9.|-- 178-191-175-254.adsl.high  0.0%    10   22.6  23.1  21.4  28.4   1.9
 10.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
2. Ziel vom Server zu Google.com
Code:
 mtr --report google.com
HOST: ks3285350.kimsufi.com       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- vss-9b-6k.fr.eu           10.0%    10    1.0   7.1   0.7  54.8  17.9
  2.|-- rbx-s2-6k.fr.eu            0.0%    10    0.7   8.2   0.7  44.9  13.7
  3.|-- rbx-g2-a9.fr.eu           30.0%    10    0.9   1.2   0.9   2.0   0.4
  4.|-- gsw-g1-a9.fr.eu            0.0%    10    4.7   4.8   4.6   4.9   0.1
  5.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  6.|-- google.as15169.fr.eu       0.0%    10    5.9   5.8   4.7   6.5   0.6
  7.|-- 2001:4860::1:0:4a3a        0.0%    10   20.2   8.5   5.1  22.2   6.7
  8.|-- 2001:4860::8:0:5e18        0.0%    10    5.4   5.3   5.2   5.5   0.1
  9.|-- 2001:4860::8:0:507c        0.0%    10    9.5   9.7   9.5   9.8   0.1
 10.|-- 2001:4860::8:0:6401        0.0%    10   28.1  28.0  27.8  28.1   0.1
 11.|-- 2001:4860::8:0:4fc9        0.0%    10   40.7  40.8  40.6  41.1   0.2
 12.|-- 2001:4860::8:0:59da        0.0%    10   49.3  54.3  49.1  59.6   3.8
 13.|-- 2001:4860::2:0:6ad4        0.0%    10   49.8  50.4  49.6  56.3   2.1
 14.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
 15.|-- 2a00:1450:4010:c05::65     0.0%    10   49.8  49.7  49.6  49.9   0.1
3. Ziel vom Server zu einem Rechner im UPC Netzwerk:
Code:
mtr --report 
HOST: ks3285350.kimsufi.com       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- vss-9a-6k.fr.eu           10.0%    10    1.0   2.2   0.5   7.7   2.3
  2.|-- rbx-g2-a9.fr.eu            0.0%    10    0.8   0.9   0.7   1.2   0.2
  3.|-- fra-5-6k.fr.eu            80.0%    10   28.9  47.3  28.9  65.6  26.0
    |  `|-- 91.121.131.202
  4.|-- pra-1-6k.cz.eu             0.0%    10   15.8  15.9  15.7  16.3   0.2
  5.|-- vie-1-6k.at.eu            20.0%    10   20.1  21.2  19.9  28.5   3.0
  6.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  7.|-- 213.46.173.126             0.0%    10   20.4  20.6  20.4  20.8   0.1
  8.|-- at-vie-sk11-pe06-vl-2048.  0.0%    10   21.9  21.4  21.2  21.9   0.2
  9.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
 10.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
 11.|-- chello06217xxxx100.13.11.  0.0%    10   35.8  31.3  29.2  35.8   1.9
Was ist da los? Der PacketLoss scheint ja schon ganz früh und noch im OVH-Netz zu passieren. Könnt ihr das mal prüfen und hoffentlich beheben. Bin ich der einzige dem das hier auffällt?

Zuletzt kann ich noch einen Graphen von Windows 8 anbieten der die Auslastung am Netzwerkcontroller bei mir zuhause anzeigt. Download eines großen Files über FTP vom besagten Server. Ich kann nur sagen, dass dieser Graph nicht normal ist und zB bei diversen Speedtests und sonstigen Übertragungen viel, viel konstanter ist als das hier.
http://i.imgur.com/XZRVo2E.jpg

tester
04.04.14, 12:55
Gestern Abend hatten wir gewohnte OVH Qualität, der smokeping von Caddy bestätigt das ja....


Interessehalber: Wo wird der Traffic aktuell übergeben?
Hop 9 antwortet ja leider nicht...

Pakete: Gesendet = 16744, Empfangen = 16727, Verloren = 17
Abends werd ich mich wieder melden...

Caddy
04.04.14, 12:03
Zitat Zitat von Felix
Und, wie war's? :-)

Felix
Nun, basierend auf unserem Smokeping von GRA aus - Ungefähr so:
http://i.imgur.com/O5V2lqu.png

Das Test-Zielobjekt liegt im 213.47.x.x Subnet von UPC, Mein Kollege in Wien hat mir ebenfalls bestätigt, dass es gestern keine Probleme gab.
Das gilt aber nur für UPC :-)

Gruß, Klaus

Felix
04.04.14, 11:47
Zitat Zitat von tester
Jetzt gerade[17:00 - 17:20] gibts 0% loss
mal schauen wies am Abend ist...
Und, wie war's? :-)

Felix

tester
03.04.14, 17:21
Routenverfolgung zu 85-127-59-*.dynamic.xdsl-line.inode.at [85.127.59.*]
über maximal 30 Hops:

1 <1 ms * <1 ms 142.4.211.252
2 1 ms 1 ms 1 ms bhs-g2-6k.qc.ca [198.27.73.19]
3 9 ms * * 198.27.73.206
4 * * * Zeitüberschreitung der Anforderung.
5 84 ms 85 ms 84 ms rbx-g2-a9.fr.eu [91.121.131.243]
6 95 ms * 102 ms fra-5-6k.fr.eu [94.23.122.118]
7 * 95 ms 95 ms pra-1-6k.cz.eu [213.251.128.109]
8 102 ms 154 ms 103 ms vie-1-6k.at.eu [213.251.128.98]
9 * * * Zeitüberschreitung der Anforderung.
10 110 ms 110 ms 112 ms at-vie01a-ra3-ge-0-1-0.aorta.net [213.46.173.118
]
11 110 ms 113 ms 110 ms at-grz-lazg-pe01-vl-2031.upc.at [84.116.228.82]

12 144 ms 133 ms 129 ms at-grz-mk47-pe01-vl-2086.upc.at [84.116.229.82]

13 110 ms 110 ms 110 ms 84.116.229.210
14 141 ms 141 ms 130 ms 85-127-59-*.dynamic.xdsl-line.inode.at [85.127.
59.*]

Ablaufverfolgung beendet.
laut Weathermap gehts noch übers Wien PNI http://weathermap.ovh.net/wien ?
Jetzt gerade[17:00 - 17:20] gibts 0% loss
mal schauen wies am Abend ist...

Caddy
03.04.14, 17:10
Im Moment (ist ja mitten am Tag) sieht's noch gut aus.
Route von meinem Wiener Kollegen zu uns:
Code:
Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 192.168.126.2                     0.0%    13    0.1   0.3   0.1   1.4   0.3
 2. 192.168.0.1                       0.0%    12    1.4   1.1   0.8   1.6   0.0
 3. ???
 4. 84.116.4.161                      0.0%    12   10.3  11.8   8.6  19.4   3.8
 5. at-vie15a-rd1-vl-2043.aorta.net   0.0%    12   48.9  32.0  17.4  64.6  12.8
 6. 84.116.136.118                    0.0%    12   24.2  26.7  19.0  43.5   7.4
 7. 84.116.133.113                    0.0%    12   26.1  24.9  20.6  33.5   3.4
 8. fra-5-6k.de.eu                   16.7%    12   44.0  25.8  20.0  44.0   7.5
 9. sbg-g2-a9.fr.eu                   0.0%    12   25.4  28.6  23.9  46.6   6.4
10. gsw-g1-a9.fr.eu                   0.0%    12   30.5  33.7  29.5  43.1   4.8
11. gra-g1-a9.fr.eu                   0.0%    12   35.6  36.5  33.9  42.7   2.4
    gra-g1-a9.fr.eu
12. gra-3a-6k.fr.eu                  63.6%    12   41.4  35.6  32.5  41.4   3.9
13. xxxxxxx.tv                        0.0%    12   42.6  37.0  32.0  44.4   3.5
Vom Server nach Wien:
Code:
Host                                   Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. ???
 2. gra-g2-a9.fr.eu                      0.0%    18    1.1   0.9   0.8   1.2   0.1
 3. th2-g1-a9.fr.eu                      0.0%    18    5.0   5.0   4.9   5.2   0.1
 4. sbg-g1-a9.fr.eu                      0.0%    17   11.7  11.4  11.2  11.7   0.1
    sbg-g2-a9.fr.eu
 5. fra-1-6k.fr.eu                      70.6%    17   13.3  14.8  13.3  19.1   2.5
 6. fra-5-6k.fr.eu                      37.5%    17   28.5  15.1  13.3  28.5   4.8
 7. pra-1-6k.cz.eu                       0.0%    17   46.2  22.5  20.7  46.2   6.2
 8. vie-1-6k.at.eu                       5.9%    17   25.0  25.0  24.9  25.4   0.1
 9. ???
10. 213.46.173.126                       0.0%    17   25.9  30.9  25.7  74.9  12.6
11. at-vie-sk11-pe02-vl-2043.upc.at      0.0%    17   26.9  27.0  26.9  27.1   0.0
12. ???
13. ???
14. chello213047xxxxxx.11.vie.surfer.at  0.0%    17   34.8  38.2  31.9  44.7   4.5
Vermutlich wird aber der Auslöser die Route von OVH nach UPC AT beim Ausstieg in Wien sein. Die Frage wäre, da UPC ja auch in Frankfurt mit OVH ein Peering betreibt, ob man zumindest UPC AT nicht direkt in Frankfurt übergeben kann, und den Transport einfach UPC selbst überlässt.

Aus meiner persönlichen langen Erfahrung (ich selbst habe Unitymedia (Auch UPC) und ich habe (das ist durchaus als Lob zu verstehen) seit dem UPC Peering in Frankfurt grundsätzlich immer Fullspeed und keinerlei Latenzprobleme und erst recht keinen Loss :-)

Gruß, Klaus

Felix
03.04.14, 15:39
Hallo,

wir haben das Peering in Wien testweise deaktiviert - könnt ihr testen ob sich die Situation für euch dadurch verbessert hat?

MfG,
Felix

tester
01.04.14, 00:31
01.04.2014
00:22


vie-3-f10 -> UPC #1 und #2 bei 25%, 26%

pro Verbindung ~20kb/s
22% loss



für eine openvpn Verbindung, alsauch HTTP Dienstleistungen ist das der tot!
sollte ich hier nichts mehr hören werd ich ein Ticket eröffnen müssen...

*Dies ist kein Aprilscherz!


selbiges bei

OVH -> AS8445 83.215.0.0/16

1 21 ms 4 ms * 142.4.211.252
2 1 ms 1 ms 1 ms bhs-g1-6k.qc.ca [198.27.73.17]
3 2 ms * * mtl-1-6k.qc.ca [198.27.73.0]
4 * * * Zeitüberschreitung der Anforderung.
5 * * * Zeitüberschreitung der Anforderung.
6 * * * Zeitüberschreitung der Anforderung.
7 130 ms 129 ms 130 ms rbx-g1-a9.fr.eu [91.121.215.141]
8 * * 171 ms fra-1-6k.de.eu [91.121.131.206]
9 139 ms 137 ms 139 ms fra-5-6k.fr.eu [94.23.122.218]
10 * 147 ms * pra-1-6k.cz.eu [213.251.128.109]
11 332 ms * 149 ms vie-1-6k.at.eu [213.251.128.98]
12 156 ms * 158 ms vix.sol.at [193.203.0.29]
.
.
.

HOP 4-6 antworten auch nach dem 4. trace nicht...


Ich sehe da eine Gemeinsamkeit, die ist euer Router in Wien...
(ich nehme mal an das bis dorthin alles funktioniert, sonst hätten auch noch andere diese Probleme)

tester
24.03.14, 02:15
Ist da der Link #2 down?

Ist zwar die andere Richtung, drüber geht trotzdem wenig...
meine Openvpn Verbindungen reißen auch gerne ab,...

Caddy
23.03.14, 16:15
Ich bin ja nicht so für's Pushen, aber:
http://s14.directupload.net/images/140323/saee72t5.png
und
http://s7.directupload.net/images/140323/uyvg7tts.png
sieht für mich so aus, als wenn die temporären Probleme über den vie-1-6k auf Kapazitätsprobleme hindeuten, oder?
Vielleicht müssen da noch ein paar "Strippen" mehr dran :-)

Gruß, Klaus

Caddy
20.03.14, 18:17
Ich nehme an, Du fragst deswegen:
http://s14.directupload.net/images/140320/syammc39.png

OVH Smokeping:
http://s1.directupload.net/images/140320/tqdahdqq.png

Eigener Smokeping (GRA):
http://s7.directupload.net/images/140320/dr85wpy6.png

Der Bekannte, der mich eben informiert hat, hat ausschliesslich Probleme nach OVH, zu allen anderen Anbietern nicht.
Leider ist es gerade heute wieder besonders schlimm...

Felix? (trommel)

Gruß, Klaus

tester
20.03.14, 16:11
any updates?

Grüße

Caddy
17.03.14, 02:53
Hallo zusammen,

Ich habe mal zum Vergleich ein paar Speedtests von meinem Bekannten aus Wien machen lassen, jetzt gerade eben, mitten in der Nacht bei freiem Netz:

OVH:
http://www.speedtest.net/my-result/3375606492

Frankfurt (LeaseWeb):
http://www.speedtest.net/my-result/3375608900

Luxemburg (P&T):
http://www.speedtest.net/my-result/3375612161

Utrecht (NL):
http://www.speedtest.net/my-result/3375614334

Limoges (wo immer das auch ist):
http://www.speedtest.net/my-result/3375615875

Die Aussage, dass höchstens 20 Mbit über das Vienna Peering gehen, ist ja damit schon fast bestätigt.
Egal, an wem das nun genau liegt (vorher hatte Felix ja schon einmal irgendwo geschrieben, dass seitens OVH dort nichts eingeschränkt wird), halte ich es wirklich für sinnvoll, dass sich da vielleicht beide Beteiligten (OVH und UPC) doch noch einmal in Verbindung setzen :-)

Die Speedtests wurden aus dem UPC Subnetz 213.47.x.x getätigt.

Gruß, Klaus

tester
15.03.14, 20:41
Ja

7 222 ms 143 ms 96 ms pra-1-6k.cz.eu [213.251.128.109]
8 102 ms 101 ms 104 ms vie-1-6k.at.eu [213.251.128.98]

prag und wien,
peering laut weathermap zu 30% ausgelastet...

denis
15.03.14, 17:38
Zitat Zitat von iSO
vielleicht muss ich halt den nächsten server dort mieten.
Mach das.
Aber les vorher den Thread "Packetloss / Verbindungsabbrüche" in deren Forum.

Unitymedia (gehört auch zu LGI) <-> H. ist sehr schlimm in letzter Zeit, ständig packet loss und Latenzen über 100ms.
(routing über Level3, da H. immer noch kein direktes Perring mit LGI hat)
Meine 100mbits erreiche ich da zudem nie, bei ovh schon.

iSO
15.03.14, 17:27
zu UPC in der Schweiz wirds wohl auch nie besser, obwohl auch hier das peering gemäss weathermap eigentlich nicht soooo stark ausgelastet sein sollte:

ovh-->upc
Code:
HOST: mein-server                      Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- vss-5a-6k.fr.eu                   0.0%    10   85.5  13.7   0.0  85.5  28.9
  2.|-- rbx-g1-a9.fr.eu                   0.0%    10    1.2   3.7   0.0  14.1   5.4
  3.|-- fra-1-6k.de.eu                   70.0%    10    7.0   8.2   7.0  10.6   2.1
    |  `|-- 94.23.122.209
  4.|-- fra-5-6k.fr.eu                   60.0%    10  243.9  67.4   8.1 243.9 117.7
  5.|-- zur-1-6k.ch.eu                    0.0%    10   19.6  25.3  14.4  99.6  26.2
  6.|-- ???                              100.0    10    0.0   0.0   0.0   0.0   0.0
  7.|-- 84.116.134.141                    0.0%    10   16.9  17.0  14.6  19.2   1.3
  8.|-- 84.116.200.242                    0.0%    10   20.3  17.6  15.1  20.3   2.0
  9.|-- 217-168-63-90.static.cablecom.ch  0.0%    10   18.3  18.1  15.5  20.2   1.5
 10.|-- ???                              100.0    10    0.0   0.0   0.0   0.0   0.0
 11.|-- mein-anschluss-bei-upc            0.0%    10   26.1  28.0  22.6  34.7   3.6
upc-->ovh
Code:
Start: Sat Mar 15 17:14:28 2014
HOST: iso-i7                           Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.12.254                    0.0%    10    0.2   0.3   0.2   0.5   0.0
  2.|-- 84-74-16-1.dclient.hispeed.ch     0.0%    10    8.1  11.1   7.2  16.6   2.8
  3.|-- 217-168-63-89.static.cablecom.ch  0.0%    10   18.9  16.9   8.5  31.2   6.7
  4.|-- 84.116.200.241                   60.0%    10   16.9  11.8   8.8  16.9   3.5
  5.|-- ch-zrh01b-ra1-ae-1.aorta.net      0.0%    10    7.4  10.2   7.4  15.3   2.5
  6.|-- zur-1-6k.ch.eu                    0.0%    10    8.5  22.3   8.5  47.0  13.4
  7.|-- fra-5-6k.fr.eu                   20.0%    10   23.2  22.6  15.8  37.1   7.5
  8.|-- rbx-g2-a9.fr.eu                   0.0%    10   25.6  29.9  24.7  52.9   8.4
  9.|-- vss-5a-6k.fr.eu                  40.0%    10   28.5  29.4  25.2  39.5   5.2
 10.|-- meinserver                        0.0%    10   29.1  28.9  24.4  36.3   3.4
mein server steht in rbx, von proof.ovh.net krieg ich auch nicht mehr als die 5-20mbit (von der tageszeit abhängig). bei speedtest.net und auch aus steam etc. krieg ich eigentlich immer die 150mbit/s...
bei hetzner gibts auch einiges mehr....
Code:
Resolving www.hetzner.de (www.hetzner.de)... 213.133.107.227, 2a01:4f8:d0a:2001::2
...
2014-03-15 17:25:06 (3.90 MB/s) - ‘/dev/null’ saved [104840234/104840234]
vielleicht muss ich halt den nächsten server dort mieten. den vorteil, den ihr bisher hattet (das ich meine failover-ip weiternutzen kann) scheint ihr ja jetzt auch nicht mehr zu bieten (oder kann man jetzt failover-ips von ovh zu soy umziehen?)

Caddy
15.03.14, 02:45
Sind in Deiner Route von OVH zu UPC AT zufällig auch diese Punkte vorhanden:
Code:
 6  pra-1-6k.cz.eu (213.251.128.109)  20.781 ms * *
 7  vie-1-6k.at.eu (213.251.128.98)  24.969 ms * *
Irgendwie hat nämlich genau dieser Weg in den letzten Wochen ziemlich oft ziemliche Probleme wie Packet Loss, langsame Übertragung und / oder auch beides zusammen.

Das Peering am vie-1-6k ist dabei aber nicht ausgelastet, zumindest nicht laut weathermap.
Ich selbst bin ja auch schon länger UPC (Unitymedia, die wurden ja von LGI gekauft), ich bin aber in DE und hier klappt das Peering, was in Frankfurt seinerzeit eingerichtet wurde, hervorragend.

Für meine Bekannten in Österreich (und einem guten Freund in Wien) wäre das natürlich ein Traum, wenn das dort genau so zuverlässig funktionieren könnte :-)

Gruß, Klaus

tester
14.03.14, 18:47
Hetzner -> UPC gut
Leaseweb -> UPC gut
OVH -> UPC schlecht

OVH -> Telekom Austria gut


ovh -> hetzner/ leaseweb kann ich derzeit nicht testen...

Felix
13.03.14, 10:55
sorry, das ich nochmal nachhake... meinst du OVH => (Hetzner|Leaseweb) oder (Hetzner|Leaseweb) => UPC ?
Kannst du eventuell beides mal testen?

nosxxx
13.03.14, 08:23
Ich bin bei A1, bei mir passt eigentlich alles. (Rz GRA)

tester
12.03.14, 21:07
Hallo Felix!

von hetzner und leaseweb ja...

Felix
12.03.14, 19:17
Um sicher zu gehen und andere Einflüsse auszuschliessen - von nicht-UPC Gegenstellen können höhere Durchsätze erreicht werden?

Felix

tester
11.03.14, 23:51
Hallo Felix!

Consumer aus dem Bereich
Announced as 85.127.0.0/16 (UPC Austria GmbH)
Announced as 85.126.0.0/15 (UPC Austria GmbH)
Announced as 85.124.0.0/14 (UPC Austria GmbH)

bekommen 24/7 ca. 1-2 mbit, auch von proof.ovh.net

Seit ihr mit UPC in Kontakt?

Grüße
Traceroute to AS6830
C:\Users\admin>tracert 85.127.36.xxx

Routenverfolgung zu 85-127-36-xxx.dynamic.xdsl-line.inode.at [85.127.36.xxx]
über maximal 30 Hops:

1 26 ms <1 ms * 142.4.211.252
2 1 ms 1 ms 1 ms bhs-g2-6k.qc.ca [198.27.73.19]
3 * 9 ms * 198.27.73.206
4 78 ms * * ldn-5-6k.qc.ca [198.27.73.10]
5 91 ms 85 ms 86 ms rbx-g2-a9.fr.eu [178.33.100.79]
6 * * 101 ms fra-5-6k.fr.eu [178.33.100.245]
7 222 ms 143 ms 96 ms pra-1-6k.cz.eu [213.251.128.109]
8 102 ms 101 ms 104 ms vie-1-6k.at.eu [213.251.128.98]
9 * * * Zeitüberschreitung der Anforderung. (Timeout)
10 108 ms 107 ms 107 ms 213.46.173.126
11 107 ms 108 ms 108 ms at-grz-lazg-pe02-vl-2032.upc.at [84.116.228.86]
12 109 ms 108 ms 108 ms at-grz-mk43-pe01-vl-2084.upc.at [84.116.229.74]
13 108 ms 108 ms 107 ms 84.116.229.218
14 121 ms 119 ms 122 ms 85-127-36-xxx.dynamic.xdsl-line.inode.at [85.127.36.xxx]

Ablaufverfolgung beendet.


Traceroute to OVH
C:\Users\H>tracert [bhs1 (T01B29)]

Routenverfolgung zu
über maximal 30 Hops:

1 2 ms 1 ms 1 ms fritz.box [192.168.178.1]
2 14 ms 20 ms 12 ms 84.116.231.162
3 19 ms 19 ms 22 ms 84.116.229.213
4 19 ms 19 ms 20 ms at-grz-lazg-pe01-vl-2086.upc.at [84.116.229.81]
5 23 ms 24 ms 23 ms at-vie01a-rd1-vl-2031.aorta.net [84.116.228.81]
6 24 ms 24 ms 26 ms at-vie05b-ri2-xe-3-2-0.aorta.net [213.46.173.117]
7 27 ms * 23 ms vie-1-6k.at.eu [91.121.131.65]
8 * * 23 ms pra-1-6k.cz.eu [213.251.128.97]
9 31 ms 32 ms * fra-5-6k.fr.eu [213.251.128.110]
10 40 ms 42 ms 43 ms rbx-g2-a9.fr.eu [94.23.122.117]
11 * * 61 ms ldn-5-6k.uk.eu [91.121.131.240]
12 * * * Zeitüberschreitung der Anforderung.
13 159 ms 138 ms 126 ms bhs-g2-6k.qc.ca [198.27.73.207]
14 155 ms * 122 ms bhs-3a-6k.qc.ca [198.27.73.14]
15 123 ms 124 ms 121 ms xxx [142.4.211.xxx]

Ablaufverfolgung beendet.

Caddy
19.12.13, 18:29
Zitat Zitat von Felix
davon ausgehend das es sich um eine IP im Netz 213.47.x.x handelt, sollte es nun besser sein - über eine Rückmeldung würden wir uns freuen!

Felix
Jetzt passt es. Und ja, es war eine IP aus diesem Netz, ich hatte sporadisch vorher schonmal durchgesehen, es wäre egal gewesen, welche IP ihr zum testen genommen hättet, denn das ganze Netz ging diesen merkwürdigen Weg.

Code:
Host                                      Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. ???
 2. gra-g1-a9.fr.eu                         0.0%     6    0.8   0.9   0.8   1.1   0.1
 3. gsw-g1-a9.fr.eu                        60.0%     6    4.7   5.1   4.7   5.5   0.5
 4. gsw-2-6k.fr.eu                         83.3%     6    9.9   9.9   9.9   9.9   0.0
 5. th2-g1-a9.fr.eu                        16.7%     6    5.0   4.9   4.8   5.0   0.1
    th2-g1-a9.fr.eu
 6. sbg-g2-a9.fr.eu                         0.0%     6   11.3  11.5  11.3  11.6   0.1
 7. fra-5-6k.fr.eu                         33.3%     6   13.5  13.4  13.4  13.5   0.1
 8. pra-1-6k.cz.eu                          0.0%     6   20.9  52.2  20.8 189.8  67.8
 9. vie-1-6k.at.eu                         33.3%     6   25.0  25.1  25.0  25.1   0.1
10. ???
11. 213.46.173.126                          0.0%     6   25.6  25.5  25.5  25.6   0.1
12. at-vie-sk11-pe02-vl-2043.upc.at         0.0%     5   48.6  30.3  25.7  48.6  10.2
13. ???
14. ???
15. chello2130470xx0xx.11.vie.surfer.at     0.0%     5   44.1  38.8  33.1  44.2   5.0
Getestet habe ich das mit derselben IP wie eingangs auch.
Vielen Dank, das ging wirklich fix

Gruß, Klaus

Felix
19.12.13, 16:48
davon ausgehend das es sich um eine IP im Netz 213.47.x.x handelt, sollte es nun besser sein - über eine Rückmeldung würden wir uns freuen!

Felix

Felix
19.12.13, 16:07
$ host chello2130470xx0xx.11.vie.surfer.at
Host chello2130470xx0xx.11.vie.surfer.at not found: 3(NXDOMAIN)

Um das problem nachzuvollziehen bräuchten wir die IP mit welcher das Problem bei dir aufgetreten ist - wenn du sie nicht im forum haben willst sonst auch per mail.

Gruß,
Felix

Felix
16.12.13, 18:56
Hallo,

Danke für die Rückmeldung. UPC scheint uns das Netzwerk nicht komplett zu announcen, wir werden daher mit UPC in Kontakt treten und um ein korrektes Announce bitten.

Felix

Caddy
14.12.13, 13:59
Vielleicht könntet ihr noch diese kleine "Weltreise" etwas verkürzen:

Code:
Host                                          Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. rbx-6-m1.fr.eu                              0.0%    35    0.5   0.5   0.4   0.8   0.1
 2. rbx-1-6k.fr.eu                              0.0%    35    1.6   4.0   0.3  65.9  12.3
 3. rbx-g1-a9.fr.eu                             0.0%    35    0.9   1.9   0.6  16.4   3.0
 4. fra-1-6k.de.eu                             76.5%    35   14.0  12.9   7.9  24.9   7.6
    fra-1-6k.de.eu
    fra-1-6k.de.eu
    fra-1-6k.de.eu
 5. fra-5-6k.fr.eu                             76.5%    35    7.9  52.9   7.9 312.7 106.6
 6. ???
 7. if-4-1108.tcore1.FNM-Frankfurt.as6453.net   0.0%    35    8.2   8.6   8.2   9.8   0.4
 8. if-7-2.tcore1.FR0-Frankfurt.as6453.net      0.0%    35   12.2  11.6  11.2  12.6   0.4
 9. if-4-2.tcore1.PVU-Paris.as6453.net          0.0%    34   21.9  12.1  11.0  21.9   2.4
10. 80.231.153.98                               0.0%    34   33.6  33.7  33.5  34.6   0.2
11. nl-ams04a-ri2-xe-9-2-1-2345.aorta.net       0.0%    34   34.4  36.7  33.8  44.8   3.3
12. 84.116.134.30                               0.0%    34   34.9  36.7  34.0  51.5   5.3
13. at-vie-sk11-pe01-vl-2042.upc.at             0.0%    34   34.4  36.3  33.8  83.9   8.9
14. at-vie-sk11-pe02-vl-2044.upc.at             0.0%    34   33.8  36.4  33.7  82.9   9.7
15. ???
16. ???
17. chello2130470xx0xx.11.vie.surfer.at         0.0%    34   43.1  44.9  36.7  58.4   4.1
Code:
inetnum:        213.47.18.0 - 213.47.39.255
netname:        CHELLO
descr:          UPC Austria GmbH
descr:          DHCP Range
country:        AT
Das geht wohl noch über TATA - Die Hin-Route aus Wien passt bereits.

Gruß, Klaus

iSO
10.12.13, 07:34
EDIT: ne, doch nicht besser. scheint eher zufall gewesen zu sein

Ja es hat sich scheinbar gebessert, die Form der Speedverteilung ist aber noch die selbe (zuerst ca. 3 sek Top-Speed, danach recht konstant 20mbit) - aber eben, viel besser als auch schon:

Code:
2013-12-10 07:26:54 (7.10 MB/s) - ‘/dev/null’ saved [262144000]
2013-12-10 07:28:28 (4.97 MB/s) - ‘/dev/null’ saved [262144000]
2013-12-10 07:30:16 (3.02 MB/s) - ‘/dev/null’ saved [262144000]
proof ist lustigerweise derzeit langsamer für mich als mein eigener server ziemlich genau 20mbit/s

toxi
08.12.13, 13:22
Hallo,

hab einen 150mbit Anschluss bei UPC Wien und zumindest was den proof.ovh.net speedtest angeht ist die performance eigentlich perfekt. Ich lade fast mit fullspeed 130-150mbit das file herunter - also anscheinend passt nun wieder alles (den link hab ich verwendet: ttp://proof.ovh.net/files/10Gb.dat)

dafür habe ich nun probleme mit hosteurope - hab dort noch restbestände an server aber nun lade ich von dort mit 300kb runter -. also irgenwie hakts doch wohl imme wie es scheint daher suche ich alternativen, da der speed einfach nicht tragbar ist .... aber das ist eine andere geschichte

hier noch das traceroute zu ovh von upc wien aus:

Code:
tracert proof.ovh.net

Routenverfolgung zu proof.ovh.net [188.165.12.106]
über maximal 30 Hops:

  1    <1 ms    <1 ms    <1 ms  toxi-router [192.168.1.1]
  2     *        *        *     Zeitüberschreitung der Anforderung.
  3    51 ms     8 ms     9 ms  84.116.25.113
  4    20 ms     9 ms    19 ms  at-vie-xion-pe01-vl-2098.upc.at [84.116.229.129]

  5     *        7 ms     8 ms  213.46.173.125
  6    36 ms     *       51 ms  vie-1-6k.at.eu [91.121.131.65]
  7     *       38 ms     *     pra-1-6k.cz.eu [213.251.128.97]
  8     *       31 ms     *     fra-5-6k.fr.eu [213.251.128.110]
  9    41 ms    40 ms    40 ms  rbx-g2-a9.fr.eu [178.33.100.244]
 10    39 ms    40 ms     *     rbx-s3-6k.fr.eu [213.186.32.166]
 11    31 ms    46 ms    33 ms  proof.ovh.net [188.165.12.106]

Felix
31.10.13, 17:52
iSO wrote:
> also... müsste man versuchen bei upc ein ticket zu eröffnen?


ja.

iSO
31.10.13, 16:56
also... müsste man versuchen bei upc ein ticket zu eröffnen? oder wie könnten wir der lösung näher kommen?
ich nehme an das peering mit upc wurde wegen dem bandbreitenproblem gemacht - wie kann es denn sein dass nicht dabei direkt festgestellt wurde, dass das bandbreitenproblem quasi identisch besteht?

Felix
31.10.13, 15:30
OK, das Routing ist symmetrisch...
Das NOC hat im Laufe dieser Woche nochmal sämtliche Router, ports und -konfigurationen überprüft, von unserer Seite gibt es keinen Grund das deine Bandbreite recht niedrig ist, es muss sich dabei also um ein bug oder "feature" seitens UPC handeln.

iSO
31.10.13, 14:54
ja, hier:
Code:
 1:  192.168.12.250                                        0.142ms pmtu 1500
 1:  192.168.12.254                                        2.580ms 
 1:  192.168.12.254                                        2.520ms 
 2:  no reply
 3:  217-168-63-89.static.cablecom.ch                     11.306ms 
 4:  84.116.211.25                                        12.674ms asymm  8 
 5:  84.116.202.241                                       11.784ms 
 6:  ch-zrh01b-ra1-ae-9-0.aorta.net                       17.208ms asymm  5 
 7:  zur-1-6k.ch.eu                                       11.839ms asymm  6 
 8:  fra-5-6k.fr.eu                                       17.605ms asymm  7 
 9:  rbx-g2-a9.fr.eu                                      26.530ms asymm  8 
10:  vss-5a-6k.fr.eu                                      29.681ms 
11:  87-98-xxx-xx.ovh.net                                 68.850ms reached
     Resume: pmtu 1500 hops 11 back 54
ping ist aber besser als hier gezeigt:
Code:
150 packets transmitted, 150 received, 0% packet loss, time 149224ms
rtt min/avg/max/mdev = 24.490/27.082/37.511/3.058 ms

Felix
31.10.13, 14:45
Zitat Zitat von iSO
sieht bei mir jetzt so aus (ovh -> cablecom ch)
Hast du noch einen traceroute in die andere Richtung? (cablecom => OVH)

Danke,
Felix

iSO
31.10.13, 14:42
sieht bei mir jetzt so aus (ovh -> cablecom ch) ... ist doch identisch wie vorher?:

Code:
HOST: mein-server                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- vss-5a-6k.fr.eu            0.0%    10   36.7  47.8   0.6 193.0  69.3
  2.|-- rbx-g1-a9.fr.eu            0.0%    10    1.0   1.0   0.8   1.4   0.1
  3.|-- fra-1-6k.de.eu            60.0%    10    8.3  18.3   8.3  47.0  19.1
    |  `|-- 94.23.122.209
  4.|-- fra-5-6k.fr.eu            30.0%    10   51.6  19.1   8.1  51.6  17.5
  5.|-- zur-1-6k.ch.eu            10.0%    10   15.2  75.2  15.2 195.6  84.4
  6.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  7.|-- 84.116.134.141             0.0%    10   15.5  15.7  15.5  16.5   0.3
  8.|-- 84.116.200.242             0.0%    10   16.3  17.1  16.3  18.5   0.8
  9.|-- 217-168-63-90.static.cabl  0.0%    10   17.7  17.5  16.7  19.4   0.8
 10.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
 11.|-- 84-74-xx-xx.dclient.hispe  0.0%    10   24.1  24.3  23.1  25.6   0.7
speed auch praktisch identisch:
Code:
2013-10-31 14:40:38 (1.29 MB/s) - `/dev/null' saved [262144000]

Felix
29.10.13, 15:56
Die traceroutes sehen doch schonmal viel besser aus. Werde noch weiteres feedback abwarten bevor wir das intern validieren...

panda
29.10.13, 13:32
Geht jetzt in beide Richtungen direkt, soweit die Hops zu sehen sind. Danke.

Cablecom CH => OVH
Code:
1     7 ms     3 ms     7 ms  fritz.box [192.168.178.1]
  2    17 ms    27 ms    14 ms  84-72-48-1.dclient.hispeed.ch [84.72.48.1]
  3    15 ms    24 ms    24 ms  217-168-57-25.static.cablecom.ch [217.168.57.25]

  4    27 ms    34 ms    27 ms  84.116.211.25
  5    25 ms    24 ms    23 ms  84.116.202.241
  6    27 ms    26 ms    25 ms  de-fra03a-rd1-xe-3-2-0.aorta.net [213.46.160.53]

  7    22 ms    22 ms    24 ms  84.116.132.162
  8    34 ms     *       24 ms  fra-5-6k.de.eu [91.121.131.77]
  9    32 ms    33 ms    31 ms  rbx-g2-a9.fr.eu [91.121.131.134]
 10     *       33 ms     *     vss-7a-6k.fr.eu [91.121.128.119]
 11    63 ms    31 ms    30 ms  meinovhserver  [x.x.x.x]

Ablaufverfolgung beendet.
OVH => Cablecom CH
Code:
 1  vss-7a-6k.fr.eu (176.31.126.253)  0.351 ms * *
 2  rbx-g1-a9.fr.eu (91.121.128.114)  0.735 ms  1.232 ms  1.536 ms
 3  * * *
 4  fra-5-6k.fr.eu (94.23.122.222)  8.169 ms * *
 5  zur-1-6k.ch.eu (94.23.122.146)  15.282 ms * *
 6  * * *
 7  84.116.134.141 (84.116.134.141)  14.828 ms  14.832 ms  15.798 ms
 8  84.116.200.242 (84.116.200.242)  15.453 ms  15.569 ms  15.847 ms
 9  XXX.dclient.hispeed.ch (x.x.x.x)  27.596 ms !X  27.658 ms !X  25.870 ms !X
Die maximale Downloadgeschwindigkeit gemäss proof.ovh.net ist jedoch scheinbar ggü. anderen speedtest.net Ergebnissen auf ca. 25 Mbps begrenzt(können andere mit schnellerer Anbindung bestimmt genauer sagen, für mich ist das nicht so wichtig).

Felix
29.10.13, 12:23
Hallo,

Es wurden einige Änderungen am Routing mit UPC vorgenommen, die insbesondere für unsere Kunden in der Schweiz positive Auswirkungen haben sollten.

Könnt ihr sagen ob es nun besser ist? Idealerweise mit einem traceroute in beide Richtungen (also UPC => OVH und OVH => UPC) um zu prüfen ob alles so geklappt hat wie geplant

Felix

tester
23.10.13, 22:54
Yahoodi ich kauf dir deinen Server ab...
christiandyndns gmail.com
bei Interesse

iSO
23.10.13, 10:52
hat sich OVH bzgl. dieser Thematik seit der Einführung des Peerings eigentlich wieder einmal geäussert?

Yahoodi
22.10.13, 23:58
Würde ich wohl auch tun, aber in der Schweiz ist die Alternative nicht so gross. Es gibt eigentlich gegen UPC nur noch die Swisscom, aber die liefert an meinem Wohnort "nur" 30 Mbit allerdings auch für mehr Geld :-)
UPC funktioniert hier schon ganz OK, selbst von Servern in Polen bekomme ich 140 Mbit. Das Peering zu OVH ist mit Abstand das schlechteste. Ich glaube selbst Neuseeland geht besser ;-)

marius
22.10.13, 23:49
Ja gut, wenn man nur einen vServer zum Spielen hat, kann man das machen.
Ich persönlich hab auch Konsequenzen gezogen, die besseren:
Ich habe meinen unitymedia Anschluss (ist ja auch UPC/LGI) zum Ende des Jahres gekündigt, und das schon vor Monaten, bevor es das PNI gab, und die Probleme anfingen.
Achja: und unsere Kunden die sich über Geschwindigkeitsprobleme beschweren, und bei einem ISP Kunde sind, der zu LGI gehört bekommen von uns auch immer diesen einzig richtigen Ratschlag: einfach den ISP wechseln.

Yahoodi
22.10.13, 23:20
Ich für meinen Teil werde die Konsequenzen wohl ziehen und meine OVH-Kiste kündigen. Bei einem Mitbewerber in DE (Köln) habe ich einen V-Server von dem ich zur schlechtesten Zeit 80 Mbit bekomme. Da ich viel mit Owncloud arbeite sind die 6 Mbit pro TCP Stream einfach nicht haltbar. Ob da jetzt UPC oder OVH der Buhmann ist, ist mir mitlerweile sch*** egal. Sie hatten ihre Chance und ich habe keine Zeit mehr für warten und basteln.

Ende der Durchsage :-)

Felix
22.10.13, 23:18
bene wrote:
> Ich würde fast vermuten, OVH drosselt dort den Speed künstlich aus


Nein... Das PNI wurde ja, trotz erheblicher Kosten, geradeeben eingerichtet um
einen Flaschenhals zu verhindern, nicht um einen neuen zu haben.

tester
22.10.13, 20:53
dann is das routing zur und von deiner schule besser als von ovh zu dir
bzw. die uplinks ausreichend dimensioniert

marius
22.10.13, 20:12
Zitat Zitat von bene

Ich würde fast vermuten, OVH drosselt dort den Speed künstlich aus Kostengründen, denn zu sehr ausgelastet ist das Interconnect nicht und selbst mitten in der Nacht sieht es nicht anders aus.
Und warum sollte OVH das tun, wenn es nicht stark ausgelastet ist?
Macht überhaupt keinen Sinn, OVH zahlt ja nicht nach Traffic.
Ich würde eher wetten, dass es an UPC/LGI liegt, an wem sonst.

bene
22.10.13, 19:56
Es geht über das PNI (bezahlter Interconnect) am CHTIX.
Aber bei mir genau das gleiche Problem, es ist wie "gedrosselt" auf 10MBit/s / Verbindung.

OVH und UPC schieben sich wie immer gegenseitig die Schuld dafür in die Schuhe und angeblich gemacht hat keiner was...

Ich würde fast vermuten, OVH drosselt dort den Speed künstlich aus Kostengründen, denn zu sehr ausgelastet ist das Interconnect nicht und selbst mitten in der Nacht sieht es nicht anders aus.
Greiffe ich über meinen IPv6 Tunnel von HE.net (getunnelt über meinen upc Anschluss) dagegen auf das OVH Netz zu erreiche ich auch jederzeit die maximale Leistung meines Anschlusses...

iSO
22.10.13, 17:20
Zitat Zitat von Yahoodi
aber wenn ich das 10 mal mache, hat trotzdem jeder Stream die gleiche Geschwindigkeit.
du meinst, dass du mit 5 parallelen verbindungen 5 mal so viel gesamtübertragungsrate hast wie mit nur einer verbindung?
das sehe ich auch, auch wenn sichs bei mir eher so um die 2.5 bewegt... allerdings ist dies nicht für alle dienste ein gangbarer weg

stossend ist halt auch, dass ich bei mir zuhause eine um ein vielfaches schnellere übertragung erreiche, wenn ich mich via vpn ins netz der schule einwähle;

direkt:
Code:
2013-10-22 17:15:54 (1.19 MB/s) - `/dev/null' saved [262144000]
via schul-vpn:
Code:
2013-10-22 17:13:13 (7.86 MB/s) - ‘/dev/null’ saved [262144000]
route:
Code:
  1.|-- vss-5a-6k.fr.eu            0.0%    15    0.5  15.8   0.5 158.4  41.3
  2.|-- rbx-g1-a9.fr.eu            0.0%    15    1.0   1.0   0.9   1.1   0.1
  3.|-- fra-1-6k.de.eu            66.7%    15   13.7   9.3   8.1  13.7   2.5
    |  `|-- 178.33.100.249
    |   |-- 91.121.131.194
  4.|-- ???                       100.0    15    0.0   0.0   0.0   0.0   0.0
  5.|-- zur-1-6k.ch.eu             0.0%    15   15.3  18.2  15.3  33.5   6.0
  6.|-- ???                       100.0    15    0.0   0.0   0.0   0.0   0.0
  7.|-- 84.116.134.141             0.0%    15   14.6  15.6  14.6  18.4   1.3
  8.|-- 84.116.200.242             0.0%    15   18.3  18.5  18.3  19.4   0.3
  9.|-- 217-168-63-90.static.cabl  6.7%    15   18.9  19.2  18.7  19.8   0.4
 10.|-- ???                       100.0    15    0.0   0.0   0.0   0.0   0.0
 11.|-- 84-74-xx-xx.dclient.hispe  0.0%    15   26.7  29.2  25.5  37.8   3.8
geht der traffic denn nun nicht über das peering (?) am chtix? sollte dadurch der speed nicht besser ausfallen?

Yahoodi
29.09.13, 19:44
wie ist bei euch der speed? für test:
Bei mir auch so 400-600 kB/Sek. - aber wenn ich das 10 mal mache, hat trotzdem jeder Stream die gleiche Geschwindigkeit. Von meinem eigenen Server hab ich das gleiche. Hab mich schon gewundert wieso Owncloud neuerdings so lange braucht.

iSO
29.09.13, 19:31
das routing scheint sich ja geändert zu haben ... aber bzgl. geschwindigkeit scheint sich bei mir nicht viel getan zu haben

Code:
2013-09-29 18:47:00 (634 KB/s) - ‘/dev/null’ saved [262144000]
traceroute vom server zu mir:
Code:
 1  vss-5a-6k.fr.eu (46.105.121.253)  27.262 ms *  0.653 ms
 2  rbx-g2-a9.fr.eu (178.33.100.70)  0.872 ms  0.926 ms  0.920 ms
 3  fra-5-6k.fr.eu (178.33.100.245)  10.353 ms fra-5-6k.fr.eu (94.23.122.118)  8.038 ms *
 4  zur-1-6k.ch.eu (94.23.122.146)  15.416 ms *  15.476 ms
 5  * * *
 6  84.116.134.141 (84.116.134.141)  25.990 ms  15.456 ms  19.480 ms
 7  84.116.200.242 (84.116.200.242)  18.488 ms  18.455 ms *
 8  * (...ich)
wie ist bei euch der speed? für test:
Code:
wget -O /dev/null http://proof.ovh.net/files/100Mio.dat

Yahoodi
15.08.13, 21:38
Ich glaube das Netz 94.23.13.xxx scheint in mehrere Teile geteilt zu sein x.127 hat z.B. eine andere Route als x.128 und so weiter. Vielleicht hat jedes Rack seine eigene Route :-)

bene
15.08.13, 20:53
Hi,

vermute da ist wieder mal ein Reverse DNS Eintrag falsch, bie mir sieht es zu dem genannten Netz gut aus:
Code:
HOST: netstal.smooth-status.de          Loss%   Snt   Last   Avg  Best  Wrst StDev
1.|-- 192.168.0.1                        0.0%    10    0.8   0.8   0.7   1.1   0.1
2.|-- 80-219-132-1.dclient.hispeed.ch    0.0%    10   33.7  15.5   8.5  33.7   8.9
3.|-- 217-168-55-173.static.cablecom.ch  0.0%    10   10.8  13.5   9.7  21.8   4.0
4.|-- 84.116.200.245                    10.0%    10   24.4  26.2  21.5  34.5   3.9
5.|-- 84.116.136.174                     0.0%    10   26.6  24.6  21.6  28.3   2.6
6.|-- 84.116.133.113                     0.0%    10   35.7  30.7  21.5  53.6  10.4
7.|-- fra-5-6k.de.eu                    30.0%    10   19.9  24.4  19.5  43.0   8.4
8.|-- rbx-g2-a9.fr.eu                    0.0%    10   37.9  38.0  35.1  53.0   5.4
9.|-- vss-1b-6k.fr.eu                    0.0%    10   33.4  53.1  33.4  87.7  19.6
|  `|-- 91.121.131.29
10.|-- ks367714.kimsufi.com               0.0%    10   36.0  37.4  34.2  43.4   3.4

Yahoodi
15.08.13, 01:07
bei mir geht die Hin-Route zu OVH noch über Prag (allerdings wohl nur zum 94.23.13.0/24-Netz, alle anderen mir bekannten OVH-Netze gehen direkt über FRA):
Code:
Host                                                    Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 192.168.192.1                                         0.0%    67    4.4   0.9   0.4  12.1   1.8
 2. 80-219-128-1.dclient.hispeed.ch                       0.0%    67   13.1  14.7  11.7  26.7   2.9
 3. 217-168-56-65.static.cablecom.ch                      0.0%    67   13.7  14.2  12.2  21.4   1.6
 4. 84.116.211.25                                         0.0%    67   20.4  21.0  18.5  34.1   2.2
 5. 84.116.202.241                                       14.9%    67   20.0  28.1  19.7  60.5   9.3
 6. cz-prg02a-ra2-xe-3-0-0.aorta.net                      0.0%    67   26.7  20.9  18.0  29.4   2.4
 7. 84.116.132.162                                        0.0%    67   22.8  23.7  21.0  72.9   6.5
 8. fra-5-6k.de.eu                                       34.8%    66   20.1  26.4  18.6  84.2  16.7
 9. rbx-g2-a9.fr.eu                                       0.0%    66   34.7  35.1  31.6 123.4  11.1
10. vss-1-6k.fr.eu                                       13.6%    66   32.3  51.5  31.3 235.0  45.8
    vss-1b-6k.fr.eu
11. 94.23.13.xxx                                          0.0%    66   26.7  26.5  24.9  29.6   1.1
Zurück gehts korrekt FRA-ZRH.
Speed ist in beiden Richtungen aber trotzdem OK.
Vielleicht steht die Büchse gar nicht in Prag und nur der PTR-Record ist falsch ;-)

Caddy
13.08.13, 12:15
Zitat Zitat von tester
"Was ist eine Route?"
"Die bekommen wir erst im Dezember mit dem Nikolaus wieder rein"

Aber mal Ernst beiseite - Meines Erachtens reicht das auch, wenn die Hin Route in Frankfurt übergeben wird, denn der UPC Backbone bis Frankfurt scheint dick genug zu sein, es würde meiner Meinung nach keinen Vorteil bringen, auch die Hin-Route über zur-1-6k.ch.eu zu führen, denn letztendlich landet die eh danach in Frankfurt :-)

Die Übergaben von OVH nach UPC (Wien) über TATA in Frankfurt anstatt über das PNI finde ich da schon unglücklicher.

Gruß, Klaus

tester
11.08.13, 13:34
Ich kenne die UPC Austria Hotline leider zu gut um die Antwort abzuschätzen können...
"Was ist eine Route?"

strex
11.08.13, 12:50
Von dir aus zu OVH ist aber UPC der Ansprechpartner. UPC entscheidet hier wo der Traffic übergeben wird. Da solltest du dich an UPC wenden, mit der Bitte.

bene
10.08.13, 21:21
Hi, habe grad gesehn zu mir geht es nun endlich von OVH zu upc über das PNI in Zürich:
Code:
 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. vss-9a-6k.fr.eu                  11.3%   186    0.9  15.7   0.4 330.8  43.6
 2. rbx-g2-a9.fr.eu                   0.0%   186    0.9   3.2   0.7  47.7   8.4
 3. fra-5-6k.fr.eu                   45.9%   186   12.9  15.4  12.8  53.4   8.8
    fra-5-6k.fr.eu
    fra-5-6k.fr.eu
    fra-5-6k.fr.eu
    fra-5-6k.fr.eu
    fra-5-6k.fr.eu
    fra-5-6k.fr.eu
 4. zur-1-6k.ch.eu                    2.7%   186   19.9  32.4  19.8 267.3  41.5
 5. ???
 6. ch-zrh02a-ra1-xe-3-2-0.aorta.net  0.0%   186   20.0  22.7  19.6  64.5   4.6
 7. 84.116.202.246                    0.0%   186   24.6  23.7  23.6  25.3   0.2
 8. 217-168-55-174.static.cablecom.c  0.5%   186   25.2  25.8  24.9  71.5   3.5
 9. ???
10. 80-219-132-xxx.dclient.hispeed.c  0.0%   186   35.9  36.6  33.6  68.4   3.8
Aber von mir zu OVH wird der Traffic weiterhin in FFM übergeben, kann man das nicht auch in ZRH übergeben?
Code:
HOST: netstal.smooth-status.de          Loss%   Snt   Last   Avg  Best  Wrst StDev
1.|-- 192.168.0.1                        0.0%    10    0.8   0.8   0.7   0.9   0.1
2.|-- 80-219-132-1.dclient.hispeed.ch    0.0%    10    8.5  13.1   7.9  49.5  12.8
3.|-- 217-168-55-173.static.cablecom.ch  0.0%    10    9.8  11.0   9.4  18.2   2.6
4.|-- 84.116.200.245                    20.0%    10   22.3  23.2  21.5  27.7   1.9
5.|-- 84.116.136.214                     0.0%    10   21.2  22.9  21.2  28.9   2.3
6.|-- 84.116.132.194                     0.0%    10   23.9  25.6  23.9  34.1   3.0
7.|-- fra-5-6k.de.eu                    40.0%    10   23.3  29.4  22.3  45.4   8.8
8.|-- rbx-g2-a9.fr.eu                    0.0%    10   36.0  38.4  36.0  43.3   3.0
9.|-- vss-9b-6k.fr.eu                    0.0%    10   36.5  42.9  35.3  92.7  17.5
|  `|-- 91.121.131.156
10.|-- 5.39.79.x                     0.0%    10   44.1  39.0  36.5  44.1   2.8

Caddy
08.08.13, 15:37
Das UPC Routing nach Wien geht übrigens noch immer über TATA:

Code:
 1  rbx-6-m1.fr.eu (87.98.216.253)  0.697 ms  0.853 ms  0.988 ms
 2  rbx-2-6k.fr.eu (213.251.191.130)  0.243 ms * *
 3  rbx-g2-a9.fr.eu (91.121.131.10)  0.695 ms  0.927 ms  0.989 ms
 4  * * *
 5  * * *
 6  if-4-1108.tcore1.FNM-Frankfurt.as6453.net (195.219.156.133)  12.778 ms  12.685 ms  13.658 ms
 7  if-7-2.tcore1.FR0-Frankfurt.as6453.net (195.219.50.1)  14.093 ms  14.094 ms  14.108 ms
 8  213.46.179.137.aorta.net (213.46.179.137)  13.828 ms  13.827 ms  13.441 ms
 9  84.116.132.185 (84.116.132.185)  25.939 ms  27.325 ms  27.024 ms
10  84.116.136.117 (84.116.136.117)  25.561 ms  25.431 ms  26.864 ms
11  at-vie-sk11-pe02-vl-2043.upc.at (84.116.228.130)  25.550 ms  25.451 ms  25.521 ms
12  chello213047115xxx.20.11.vie.surfer.at (213.47.115.xxx)  34.376 ms  40.660 ms  40.780 ms
Ich weiß, UPC müsste das entsprechend announcen aber irgendwie hält dieser Zustand schon recht lange an. Die Hin-Route geht ja schon über's PNI...

Gruß, Klaus

strex
03.05.13, 15:46
Oder eben über lambdanet, geht auch zügig:

Code:
traceroute to 84.116.229.81 (84.116.229.81), 30 hops max, 60 byte packets
 1  gateway.ipv4.fra.filemedia.net (62.113.241.1) [AS47447]  0.258 ms  0.207 ms  0.179 ms
 2  62.80.98.141 (62.80.98.141) [AS13237/AS8218]  0.573 ms  0.543 ms  0.557 ms
 3  ae4.irt1.fra25.de.as13237.net (217.71.96.69) [AS13237]  0.872 ms  0.898 ms  0.916 ms
 4  AMS-2-pos300.nl.lambdanet.net (82.197.128.18) [AS13237]  23.192 ms  23.295 ms  23.422 ms
 5  nl-ams09b-ri1-ge-7-1-0.aorta.net (213.46.183.13) [AS6830]  23.083 ms  23.056 ms  23.028 ms
 6  nl-ams05a-rd2-xe-4-2-2.aorta.net (84.116.130.21) [AS6830]  15.408 ms 84.116.136.82 (84.116.136.82) [AS6830]  15.502 ms nl-ams05a-rd2-xe-4-2-2.aorta.net (84.116.130.21) [AS6830]  15.341 ms
 7  at-vie01a-rd1-xe-0-2-0.aorta.net (84.116.130.82) [AS6830]  48.384 ms  79.665 ms  79.612 ms
 8  at-grz-lazg-pe01-vl-2031.upc.at (84.116.228.82) [AS6830]  90.256 ms  61.680 ms *

Eddy
03.05.13, 15:26
Ich glaube langsam nichtmehr an ein peering in FFM

Habe die frage auch mal oles auf twitter gestellt, leider keine antwort drauf erhallten, obwohl er dort wohl sehr redselig ist.

P.s. in den Niederlanden nutzen fast alle anbieter Atrato IP um daten ins UPC netz zu schicken und das funktionert sehr gut, wäre ja evtl auch für OVH eine alternative zu TaTa.

1 tge1-1.fra02-1.de.as5580.net (78.152.61.241) [AS5580] 0.224 ms
2 upc-6830-ic.fra02-1.de.as5580.net (78.152.43.150) [AS5580] 0.230 ms
3 84.116.132.177 (84.116.132.177) [AS6830] 0.656 ms
4 84.116.133.113 (84.116.133.113) [AS6830] 0.598 ms
5 84-116-131-150.aorta.net (84.116.131.150) [AS6830] 0.605 ms

iSO
03.05.13, 09:52
gibt es Neuigkeiten hierzu? der Durchsatz zu mir nach CH ist unverändert tief

Eddy
24.04.13, 13:55
Zitat Zitat von iSO
Das verwundert mich eben auch, allerdings ist Hop 6 ja ein Router von aorta. Und Hop 5 trägt AS6830 im Namen...

ist der gleiche laden AS6830 ist Liberty Global die haben UPC ( Aorta ) aufgekauft.

iSO
24.04.13, 08:30
Zitat Zitat von Eddy
komisch ist das schon, da ja in der schweiz ein peering mit UPC besteht welches ja laut traceroute auch genutzt wird.
Das verwundert mich eben auch, allerdings ist Hop 6 ja ein Router von aorta. Und Hop 5 trägt AS6830 im Namen...

Eddy
23.04.13, 16:08
Zitat Zitat von iSO
ist diese thematik eigentlich auch für den schlechten durchsatz zu den UPC-Kunden in der schweiz verwantwortlich? am morgen erreiche ich etwa 1mbyte/s, gegen abend etc eher 300kbyte/s - von anderen anschlüssen (insbesondere an der uni) erreiche ich _immer_ volle 100mbit/s von diesem server

zu zeiten an denen ich von diesem server nur ca 300kbyte/s erreiche, erhalte ich von anderen servern sehr hohe bandbreiten (also eine auslastung des lokalen tv-kabelnetzes ist nicht vorhanden zu diesem zeitpunkt)

hier der pfad vom server zum user:

Code:
[iso@meinserver ~]$ mtr **** --report -c 50
HOST: meinserver                  Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- vss-5b-6k.fr.eu            0.0%    50    1.4  10.1   0.6 119.7  23.9
  2.|-- rbx-g2-a9.fr.eu            0.0%    50    1.3   2.4   0.9  29.4   5.0
  3.|-- fra-5-6k.fr.eu            74.0%    50   42.9  11.1   8.3  42.9   9.5
    |  `|-- 178.33.100.255
    |   |-- 91.121.131.202
  4.|-- zur-1-6k.ch.eu             0.0%    50   15.4  23.8  15.3 346.6  47.1
  5.|-- upc.as6830.ch.eu           0.0%    50   14.6  15.4  14.6  42.3   3.9
  6.|-- ch-zrh02a-ra1-xe-3-2-0.ao  0.0%    50   16.7  20.3  16.2  52.8  10.7
  7.|-- 84.116.202.226             0.0%    50   16.9  16.8  16.5  17.2   0.1
  8.|-- 84.116.211.22              0.0%    50   16.8  16.7  16.5  17.1   0.1
  9.|-- 217-168-63-26.static.cabl  2.0%    50   17.9  21.0  17.6  61.3   9.6
 10.|-- *************.dynamic.his  0.0%    50   25.0  27.8  23.8  39.7   3.6

komisch ist das schon, da ja in der schweiz ein peering mit UPC besteht welches ja laut traceroute auch genutzt wird.

Hook
22.04.13, 22:44
UPC ist häufig nun mal langsam, gewöhnt euch dran

marius
18.04.13, 13:55
Zitat Zitat von iSO
ist diese thematik eigentlich auch für den schlechten durchsatz zu den UPC-Kunden in der schweiz verwantwortlich?
Ja, betrifft alle bei denen das Routing über Aorta (AS6830) läuft.
Also auch UPC Schweiz Kunden.

iSO
18.04.13, 11:23
ist diese thematik eigentlich auch für den schlechten durchsatz zu den UPC-Kunden in der schweiz verwantwortlich? am morgen erreiche ich etwa 1mbyte/s, gegen abend etc eher 300kbyte/s - von anderen anschlüssen (insbesondere an der uni) erreiche ich _immer_ volle 100mbit/s von diesem server

zu zeiten an denen ich von diesem server nur ca 300kbyte/s erreiche, erhalte ich von anderen servern sehr hohe bandbreiten (also eine auslastung des lokalen tv-kabelnetzes ist nicht vorhanden zu diesem zeitpunkt)

hier der pfad vom server zum user:

Code:
[iso@meinserver ~]$ mtr **** --report -c 50
HOST: meinserver                  Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- vss-5b-6k.fr.eu            0.0%    50    1.4  10.1   0.6 119.7  23.9
  2.|-- rbx-g2-a9.fr.eu            0.0%    50    1.3   2.4   0.9  29.4   5.0
  3.|-- fra-5-6k.fr.eu            74.0%    50   42.9  11.1   8.3  42.9   9.5
    |  `|-- 178.33.100.255
    |   |-- 91.121.131.202
  4.|-- zur-1-6k.ch.eu             0.0%    50   15.4  23.8  15.3 346.6  47.1
  5.|-- upc.as6830.ch.eu           0.0%    50   14.6  15.4  14.6  42.3   3.9
  6.|-- ch-zrh02a-ra1-xe-3-2-0.ao  0.0%    50   16.7  20.3  16.2  52.8  10.7
  7.|-- 84.116.202.226             0.0%    50   16.9  16.8  16.5  17.2   0.1
  8.|-- 84.116.211.22              0.0%    50   16.8  16.7  16.5  17.1   0.1
  9.|-- 217-168-63-26.static.cabl  2.0%    50   17.9  21.0  17.6  61.3   9.6
 10.|-- *************.dynamic.his  0.0%    50   25.0  27.8  23.8  39.7   3.6

Felix
13.02.13, 20:36
zakazak wrote:
> routing wieder im eimer.. grade zufällig aufgefallen.. 300kbit/s max.


Ich verweise auf folgenden Thread mit allen aktuellen Infos:
http://forum.ovh.de/showthread.php?t=11748

zakazak
13.02.13, 20:05
routing wieder im eimer.. grade zufällig aufgefallen.. 300kbit/s max.

lächerlich

Caddy
14.01.13, 03:21
Oder Strato.
http://s7.directupload.net/images/130114/jxefj8gu.png

Abwarten oder Provider wechseln. Wie schon geschrieben, habe ich mittlerweile das selbe Problem, seitdem Unitymedia erfolgreich in LGI reingefrickelt wurde.

Gruß, Klaus

strex
13.01.13, 15:30
Dann solltest du einmal in´s Heztner Forum reinschauen und die Threads zu LGI (United Media, KabelBw, UPC,..) anschauen. Das sieht´s nur bitter aus, aber wenn das so gut ist, warum bist du dann noch hier? Bitte sei aber danach nicht enttäuscht..

UPCUser
13.01.13, 15:20
@ Strex

Wenn ich Speedtests auf Hetzner & Leaseweb durchführe erreiche ich meine 100 mbit, zwar nicht grade mit der besten Ping aber ich hab vollen Speed.

MFG

strex
13.01.13, 14:33
Leb damit oder Wechsel, pass aber auf, Heztner und co. haben dieselbe Problematik..Immer groß ankündigen und dann doch nicht machen, zeugt für mich von einfacher heißen Luft.

UPCUser
13.01.13, 00:35
Mag sein, aber dann hätte man vorher nicht groß reden sollen ....

Nun gut Jänner ist noch nicht vorbei, aber so wies aussieht wird wieder nur vertröstet, dann heissts "Im Februar dann" und dann komt "Ist sich nicht ausgegangen März"....

Und so verliert man seine Kunden

Hook
10.01.13, 19:11
Ich glaube UPC hat aktuell auch einfach keine Zeit und Lust dazu, gerade durch die Sache mit Unitymedia ...
Deren Netz ist überlastet genug, die haben aktuell wohl erst mal wichtigere Baustellen.

UPCUser
06.01.13, 18:00
So jetzt hätten wir Jänner. Wie siehts denn jetzt mit der Lösung aus?

Bei der Geschwindigkeit hat sich nach wie vor nichts geändert...

MFG

Eddy
20.12.12, 16:23
Ist ja interessant, wieso schafft es in diesem fall TaTa direkt in FFM den traffic an Aorta zu übergeben.

Bei einer UM IP geht das erstmal über 2 andere Länder.

Code:
  1 if-0-1-2-0.tcore1.FR0-Frankfurt.as6453.net (195.219.50.133) [MPLS: Label 564320 Exp 0] 60 msec 16 msec 16 msec
  2 if-7-2.tcore1.FNM-Frankfurt.as6453.net (195.219.50.2) [MPLS: Label 319328 Exp 0] 12 msec
    if-9-2.tcore1.FNM-Frankfurt.as6453.net (195.219.50.42) [MPLS: Label 319328 Exp 0] 16 msec
    if-7-2.tcore1.FNM-Frankfurt.as6453.net (195.219.50.2) [MPLS: Label 319328 Exp 0] 16 msec
  3 if-5-2.tcore1.AV2-Amsterdam.as6453.net (195.219.194.13) [MPLS: Label 304496 Exp 0] 16 msec
    if-6-3.tcore1.AV2-Amsterdam.as6453.net (195.219.194.77) [MPLS: Label 304496 Exp 0] 16 msec
    if-5-2.tcore1.AV2-Amsterdam.as6453.net (195.219.194.13) [MPLS: Label 304496 Exp 0] 12 msec
  4 if-2-2.tcore2.AV2-Amsterdam.as6453.net (195.219.194.6) [MPLS: Label 304512 Exp 0] 16 msec 16 msec 16 msec
  5 if-8-2.tcore2.L78-London.as6453.net (80.231.131.5) 16 msec
    if-7-2.tcore2.L78-London.as6453.net (80.231.152.14) 16 msec 12 msec
  6 Vlan757.icore2.LDN-London.as6453.net (80.231.20.21) 12 msec
    Vlan756.icore2.LDN-London.as6453.net (80.231.131.26) 16 msec 12 msec
  7 213.46.179.105.aorta.net (213.46.179.105) [AS 6830] 16 msec 16 msec 12 msec
  8 uk-lon01b-rd1-xe-7-0-0.aorta.net (84.116.133.229) [AS 6830] 16 msec 16 msec 16 msec
  9 1411g-mx960-02-ae3.neuss.unity-media.net (84.116.131.146) [AS 6830] 12 msec 12 msec 16 msec
 10 13NOC-MX960-02-ae9.krp.unity-media.net (80.69.107.5) [AS 20825] [MPLS: Label 613279 Exp 0] 16 msec 12 msec 12 msec
 11 13NOC-MX960-01-ae0.krp.unity-media.net (80.69.107.201) [AS 20825] [MPLS: Label 531148 Exp 0] 16 msec 20 msec 16 msec
 12 7111A-MX960-01-ae8.fra.unity-media.net (80.69.107.25) [AS 20825] 16 msec 12 msec 20 msec

tester
18.12.12, 19:59
ich bin privat schon lange von upc geflüchtet....

Darky68
18.12.12, 19:13
Zitat Zitat von strex
Beide Richtungen sind nicht die Besten, sind aber von UPC so gewünscht. Für deinen Fall den Zugangsanbieter wechseln, wenn dir das Routing nicht passt.
gerade gekündigt , nach 7jahren , das war halt meine lösung weg von inode der tochter von upc . wobei ich schon einmal von upc geflüchtet bin damals zu inode (leider vor paar jahren aufgekauft von upc um die geflüchteten kunden wieder zu bekommen)

naja schaun ma ab 1.2.2013 neuer isp und dann neuen ovh server


danke für die hilfe strex

strex
18.12.12, 17:25
Beide Richtungen sind nicht die Besten, sind aber von UPC so gewünscht. Für deinen Fall den Zugangsanbieter wechseln, wenn dir das Routing nicht passt.

Darky68
18.12.12, 17:10
heist das - wenn ich mich mit ftp zum ovh server binde - wählt der ftp die langsame komisch route und somit schickt ovh zu mir über die andere route udn nicht über tata

udn somit bricht die geschwindigkeit ein - weil ich schaff nur zw 70-300kb/s obwohl 2mbit mögich sind

oder versteh ich das jetzt falsch?

strex
18.12.12, 17:04
Kein Problem (Wie schon bekannt über TATA):

Code:
traceroute to 84.116.231.160 (84.116.231.160), 30 hops max, 60 byte packets
 1  vss-7a-6k.fr.eu (176.31.119.253)  0.560 ms * *
 2  rbx-g2-a9.fr.eu (91.121.128.118)  2.327 ms  2.337 ms  2.315 ms
 3  fra-5-6k.fr.eu (178.33.100.251)  7.952 ms * *
 4  tata.as6453.de.eu (213.251.130.106)  9.280 ms  9.186 ms  9.213 ms
 5  if-4-1108.tcore1.FNM-Frankfurt.as6453.net (195.219.156.133)  8.491 ms  8.410 ms  8.376 ms
 6  if-9-2.tcore1.FR0-Frankfurt.as6453.net (195.219.50.41)  8.824 ms  8.900 ms if-7-2.tcore1.FR0-Frankfurt.as6453.net (195.219.50.1)  8.620 ms
 7  213.46.179.137.aorta.net (213.46.179.137)  8.610 ms  8.466 ms  8.545 ms
 8  84.116.132.145 (84.116.132.145)  8.423 ms 84.116.132.173 (84.116.132.173)  8.687 ms 84.116.132.145 (84.116.132.145)  8.599 ms
 9  fr-par02a-rd1-pos-2-0.aorta.net (213.46.160.105)  22.597 ms 84.116.136.117 (84.116.136.117)  22.066 ms 84.116.136.109 (84.116.136.109)  21.513 ms
10  at-vie-xion-pe01-vl-2050.upc.at (84.116.228.194)  23.392 ms  22.400 ms at-vie-xion-pe02-vl-2051.upc.at (84.116.229.2)  22.547 ms
11  at-vie-xion-pe04-vl-2056.upc.at (84.116.228.206)  46.798 ms at-vie-xion-pe04-vl-2055.upc.at (84.116.229.10)  47.297 ms at-vie-xion-pe04-vl-2056.upc.at (84.116.228.206)  46.536 ms
12  * * *

Darky68
18.12.12, 16:49
aber könntest du mal ein traceroute zu mir von deinem ovh server machen

wäre interesant wie ovh zu inode(upc) routet

strex
18.12.12, 16:26
Auch hier wird von UPC in´s AS3320 geroutet und dann zu OVH, ein Problem von OVH ist das nicht, da die Rückroute nicht von OVH sondern von UPC bestimmt wird.

Darky68
18.12.12, 13:30
so sieht ein tracert zu einem bekannten von mir aus der nen ovh server hat

also inode (upc) zu ovhserver



Routenverfolgung zu ns383xxx.ovh.net [46.105.xxx.xx] über maximal 30 Abschnitte:


1 <1 ms 1 ms 1 ms fritz.box
2 27 ms 26 ms 29 ms 84.116.231.160
3 59 ms 42 ms 41 ms 84.116.229.197
4 78 ms 41 ms 27 ms at-vie-xion-pe02-vl-2054.upc.at [84.116.228.201]

5 66 ms 43 ms 28 ms at-vie15a-rd1-vl-2051.aorta.net [84.116.229.1]
6 78 ms 32 ms 27 ms 213.46.173.125
7 29 ms 40 ms 39 ms 80.150.169.233
8 48 ms 54 ms 46 ms 217.239.40.230
9 * * * Zeitüberschreitung der Anforderung.
10 57 ms 57 ms 57 ms rbx-g1-a9.fr.eu [178.33.100.252]
11 48 ms * 68 ms vss-5b-6k.fr.eu [178.33.100.30]
12 53 ms 49 ms 55 ms ns383763.ovh.net [46.105.xxx.xx]

Ablaufverfolgung beendet.

und so zu einem anderen ovh server



Routenverfolgung zu ks220xxx.kimsufi.com [188.165.xxx.xxx] über maximal 30 Absch
nitte:

1 <1 ms <1 ms 1 ms fritz.box [192.168.178.1]
2 35 ms 27 ms 29 ms 84.116.231.160
3 35 ms 112 ms 39 ms 84.116.229.205
4 28 ms 27 ms 32 ms at-vie-xion-pe02-vl-2058.upc.at [84.116.228.209]

5 31 ms 28 ms 29 ms at-vie15a-rd1-vl-2051.aorta.net [84.116.229.1]
6 31 ms 39 ms 27 ms 213.46.173.125
7 30 ms 33 ms 28 ms 80.150.169.233
8 42 ms 50 ms 47 ms 217.239.39.26
9 41 ms * * fra-1-6k.de.eu [94.23.122.153]
10 50 ms 52 ms 61 ms rbx-g1-a9.fr.eu [178.33.100.242]
11 50 ms * 74 ms vss-4-6k.fr.eu [94.23.122.160]
12 49 ms 49 ms 50 ms ks220xxx.kimsufi.com [188.165.xxx.xxx]

Ablaufverfolgung beendet.


ich bin ein laie , aber für mich sieht das aus als hätte da die von ovh bzw franzosen ein problem (wie gesagt kenn mich da ned so aus viell kannst einer genauer interpredieren)

Caddy
18.12.12, 10:34
Spannende Route :-)

Das mit den mehreren Verbindungen ist übrigens anscheinend je nach Auslastung des UPC Netzes eine UPC Angelegenheit. Mein Kontakt in Wien hat das ab und zu auch zu / von anderen Servern. Wir haben das mal mit ihm und einem Strato-Server getestet, er bekam dort manchmal Fullspeed (100 Mbit/s), zu Hauptzeiten schonmal 50 MBit/s pro TCP Stream, oder auch 25 MBit/s pro Stream (man beachte diese haargenaue runde Teilung). Das Problem wird aber schon seit langer Zeit an diversen Stellen im Netz diskutiert.

LG, Klaus

strex
17.12.12, 19:01
Deine Verbindung läuft auch nicht über TATA oder UPC direkt sondern über das AS3320 (DTAG). Ziemlich komisch eigentlich, sollte nicht so sein. Bis jetzt gab es nie eine Route bei der die DTAG als Durchgangsnetz dient.

tester
17.12.12, 17:06
C:\Users\Admin>tracert host.org

Routenverfolgung zu host.org [***.***.***.***] über maximal 30 Abschnitte:

1 * * * Zeitüberschreitung der Anforderung.
2 29 ms 31 ms 39 ms 10.255.118.1
3 62 ms 64 ms 62 ms at-grz-lazg-pe01-vl-2086.upc.at [84.116.229.81]

4 55 ms 67 ms 63 ms at-vie01a-rd1-vl-2031.aorta.net [84.116.228.81]

5 51 ms 58 ms 45 ms at-vie05b-ri2-xe-3-2-0.aorta.net [213.46.173.117
]
6 46 ms 58 ms 47 ms 80.150.169.233
7 41 ms 44 ms 43 ms 217.239.39.34
8 53 ms * * fra-1-6k.de.eu [94.23.122.153]
9 43 ms 49 ms 48 ms rbx-g1-a9.fr.eu [91.121.131.193]
10 83 ms 87 ms 79 ms vss-8b-6k.fr.eu [91.121.215.213]
11 98 ms 89 ms 58 ms host.org [***.***.***.***]

Ablaufverfolgung beendet.

ich bekomme immer Fullspeed (18mbit) symetrisch...
allerdings brauch ich dazu manchmal 2-3 Verbindungen, wobei die Leitung ja nicht nur mir gehört

strex
13.12.12, 20:32
Zitat Zitat von nenad
Es liegt einzig und alleine an OVH wie die Pakete zurückgeroutet werden und wenn OVH keine gute Route zu UPC hat, müssen die Franzosen versuchen manuell Routen zu setzen (sofern die das Wissen dazu haben oder 50 eur für das Buch Routing for Dummies investieren dürfen...) welche bevorzugt für AS6830 genutzt werden, falls dies keine Besserung bringt einen Upstream Provider finden welcher eine gute Anbindung bietet oder direkt bei UPC IP Transit kaufen....
OVH besitzt mit UPC ein eigenes Peering. Siehe Weathermap..

Zitat Zitat von nenad
Aber Leute hört doch auf der UPC sonen Mist zu schreiben.... Ich komme nochmals an meinen Vorschlag zurück, die Option Premium Traffic einführen da soll dann halt UPC Upstream, Level3, Tata, D-Telekom, Verzizon ... mit hoher Priorität zur Verfügung stehen....
Gibt es doch schon lange, OVH besitzt mit allen eigene Peerings. Siehe Weathermap..

Zitat Zitat von nenad
Nebenbei sowas bietet Bandbreitenmässig der grösste Hoster Europas (in NL zu hause) bereits seit Jahren an.... wobei dieser zu allen ISP top angebunden ist.... liegt daran das zahlreiche Video- und Filesharing Portale dort gehostet werden und da hat jeder ISP Freude daran
Das stimmt Leaseweb hat 3 Tbit/s, OVH hat nur 2 Tbit/s. Wobei nach neuerster Aussage von Oles (paar Tage) nur knapp 40% ausgelastet sind. Was Leaseweb aber fehlt ist ein weltweite Backbone, wie es eben OVH gerade aufbaut. Da gehen eben mal 200 Gbit/s über den Teich und in kleinerer Menge bis nach Tokio und HongKong. Somit ist man in der Lage den Traffic dort zu übergeben (Weltweit) wo es am Besten ist. Man darf eines nicht vergessen, es bringt unendlich viel Kapazität nichts, wenn man die Netze selbst nicht kontrolliert.

Was es in diesem Fall ist, ist reine Politik ähnlich wie mit der Telekom und hat keinerlei technische Grundlage..

Caddy
13.12.12, 20:16
Zitat Zitat von Hook
Peerings mit z.B. UPC oder auch der Deutschen Telekom musst du i.d.R. einkaufen. Ich glaube das hatte er gemeint.
Das mag ja sein. Ich glaube aber, ein Geschäftsmodell, bei dem man durch zubuchbaren Premium Traffic zu bestimmten Providern / AS bessere Geschwindigkeiten bekommt, ist eher kontraproduktiv.

Es geht ja auch (hat er wohl auch überlesen) um den Upstream von OVH nach UPC über vie-3-f10. Auch, wenn direktes Peering zwischen UPC und OVH in keiner Peering DB steht (es findet wohl keins statt), oxydiert dieses Gerät da nun mal in Wien herum und tut nicht das, was es soll. Auf welcher Seite auch immer, das versuchten wir ja gerade rudimentär herauszubekommen :-)

Ich glaube kaum, dass OVH den Upstream nach UPC drosselt, also muss ja da etwas schief laufen.

Nebenbei:
( Thu, 6 Dec 2012 16:56:54 +0100 (CET) ) Ihre Email wurde an die zuständige Abteilung weitergeleitet und wird schnellstmöglich bearbeitet.
Gruß, Klaus

Hook
13.12.12, 19:59
Zitat Zitat von Caddy
IP Transit? Um aus einem Netz A (UPC) in ein Netz B (OVH) zu kommen, soll OVH IP Transit bei UPC kaufen? Möchtest Du das nicht nochmal überdenken? IP Transit kaufe ich, wenn ich durch ein Netz durch will, nicht, wenn ich direkt etwas "von" einem Netz will.
Peerings mit z.B. UPC oder auch der Deutschen Telekom musst du i.d.R. einkaufen. Ich glaube das hatte er gemeint.

Caddy
13.12.12, 19:35
Zitat Zitat von nenad
Ich finde die Mails an UPC sehr amüsant, wie sollte den UPC beinflussen wie der Traffic von OVH an euch zurückgesendet wird?
Wo steht, dass das verlangt wird?

Zitat Zitat von nenad
Es liegt einzig und alleine an OVH wie die Pakete zurückgeroutet werden und wenn OVH keine gute Route zu UPC hat, müssen die Franzosen versuchen manuell Routen zu setzen (sofern die das Wissen dazu haben oder 50 eur für das Buch Routing for Dummies investieren dürfen...) welche bevorzugt für AS6830 genutzt werden, falls dies keine Besserung bringt einen Upstream Provider finden welcher eine gute Anbindung bietet oder direkt bei UPC IP Transit kaufen....
IP Transit? Um aus einem Netz A (UPC) in ein Netz B (OVH) zu kommen, soll OVH IP Transit bei UPC kaufen? Möchtest Du das nicht nochmal überdenken? IP Transit kaufe ich, wenn ich durch ein Netz durch will, nicht, wenn ich direkt etwas "von" einem Netz will.

Damit auch Du heute Nacht gut schlafen kannst:
Transit is distinct from peering, in which only traffic between the two ISPs and their downstream customers is exchanged and neither ISP can see upstream routes over the peering connection.
Zitat Zitat von nenad
Aber Leute hört doch auf der UPC sonen Mist zu schreiben.... Ich komme nochmals an meinen Vorschlag zurück, die Option Premium Traffic einführen da soll dann halt UPC Upstream, Level3, Tata, D-Telekom, Verzizon ... mit hoher Priorität zur Verfügung stehen....
Deine Transit-Aussage disqualifiziert Dich von diesem Vorschlag.

Zitat Zitat von nenad
Nebenbei sowas bietet Bandbreitenmässig der grösste Hoster Europas (in NL zu hause) bereits seit Jahren an
Na und? Um den geht es hier aber nicht. Mein Förmchen ist auch viel schöner als Deins.

Gruß, Klaus

nenad
13.12.12, 17:25
Ich finde die Mails an UPC sehr amüsant, wie sollte den UPC beinflussen wie der Traffic von OVH an euch zurückgesendet wird?

Es liegt einzig und alleine an OVH wie die Pakete zurückgeroutet werden und wenn OVH keine gute Route zu UPC hat, müssen die Franzosen versuchen manuell Routen zu setzen (sofern die das Wissen dazu haben oder 50 eur für das Buch Routing for Dummies investieren dürfen...) welche bevorzugt für AS6830 genutzt werden, falls dies keine Besserung bringt einen Upstream Provider finden welcher eine gute Anbindung bietet oder direkt bei UPC IP Transit kaufen....
Aber Leute hört doch auf der UPC sonen Mist zu schreiben.... Ich komme nochmals an meinen Vorschlag zurück, die Option Premium Traffic einführen da soll dann halt UPC Upstream, Level3, Tata, D-Telekom, Verzizon ... mit hoher Priorität zur Verfügung stehen....
Nebenbei sowas bietet Bandbreitenmässig der grösste Hoster Europas (in NL zu hause) bereits seit Jahren an.... wobei dieser zu allen ISP top angebunden ist.... liegt daran das zahlreiche Video- und Filesharing Portale dort gehostet werden und da hat jeder ISP Freude daran

UPCUser
09.12.12, 22:09
So hab jetzt nochmal getestet und das mit verschiedenen Root Anbietern und meiner Homeleitung (100mbit)... Tests wurden mehrmals am Tag wiederholt -->

strato - 11,7 MB Download
leaseweb - 11,4 MB Download
hetzner - 11,5 MB Download
host europe - 10,9 MB Download
1&1 - 11,6 MB Download
euserv - 11,8 MB Download
worldstream - 11,2 MB Download

OVH - 0,9 MB Download (und das maximal)

NUR bei OVH klappt der Speed nicht....
Zu mehr Servern hab ich leider keinen Zugang, aber das Ergebnis spricht ja für sich...
Und dabei waren da einige Roots dabei die wesentlich weiter entfernt sind als die in Frankreich.....

MFG

tester
07.12.12, 17:53
dieleitung is symetrisch und synct mir 18mbit, nachts bekomm ich die von einem privatem server... gebe euch nächste woche mal tracerts durch...

UPCUser
07.12.12, 13:43
Zitat Zitat von tester
ich sitze hier hinter einer buisness leitung von upc...
bekomme zu einem privatem server full speed 18mbit
hat jemand eine ip zum tracen ?

lg
18MB geht ja garnicht mit ner 100er Leitung?

Woher kommst du denn, Wien?

Btw wo steht denn der Server? Gibt ja nur Probleme zu OVH.

MFG

Edit: Ach grad gelesen sind ja nur 18mbit ^^ verlesen sorry

tester
07.12.12, 08:35
ich sitze hier hinter einer buisness leitung von upc...
bekomme zu einem privatem server full speed 18mbit
hat jemand eine ip zum tracen ?

lg

Darky68
06.12.12, 18:35
ich inodekunde tochter upc hänge somit im upc netz mit xdsl entbündelter leitung

und kann dies immo nur mehr via ftp auf ftp.ovh.net testen mit dem 100mb file

und ich erhalte 300 kib/s voon möglichen 2mbit

mehr kann ich leider nicht testen mehr - da ich keinen server mehr habe

UPCUser
06.12.12, 12:44
Alles klar, wenn du noch was brauchen solltest lass ich dir gern meine Mail zukommen.


MFG

Caddy
05.12.12, 23:36
Zitat Zitat von UPCUser
@Caddy

Du kannst mir gern ne IP schicken auf die ich ein Tracert machen soll.

MFG
Derweil habe ich keine, die ich öffentlich posten könnte. Macht aber nichts, ich habe UPC eben geantwortet und ein Traceroute auf eine betroffene IP Deines Subnetzes geschickt und dort auch geschrieben, dass das Problem ab einem bestimmten Hop auftritt (nämlich genau beim OVH/UPC Übergang). Ich denke, man wird sich melden, wenn das zu wenig Infos sind, dann müssen wir uns mal irgendwie austauschen.

Gruß, Klaus

UPCUser
05.12.12, 16:29
@Caddy

Du kannst mir gern ne IP schicken auf die ich ein Tracert machen soll.

MFG

Felix
05.12.12, 09:45
Zitat Zitat von Caddy
(eigentlich sollte sowas ja koordiniert zwischen den Beteiligten geschehen, wer weiß, wo die da rumschrauben, wenn sie nicht miteinander sprechen)...
Eine Verschlechterung seitens UPC ist wohl kaum zu erwarten.
Und im Januar wird eh' alles anders

Caddy
05.12.12, 01:45
Zitat Zitat von UPCUser
Hier bei mir (WIEN) IP 62.178.***.*** hat sich nichts geändert.. Ping schlecht Speed schlecht

MFG

Edit: Von nem Proof OVH --> Download startet mit 3MB´s und fällt innerhalb von Sekunden auf 200-400kbs ab...

Von nem Kimsufi noch schlechter --> Down startet mit 2,5MB´s und fällt innerhalb Sekunden auf 150-300kbs.
Hab ich schon fast befürchtet. Kannst Du mal ein traceroute zu einem kimsufi machen? Wenn irgendwie möglich zu einem in Roubaix 1, wenn ich schon die Möglichkeit habe und UPC so nett nachfragt, würde ich gerne die Nachfrage von UPC nutzen, falls Felix / OVH mich nicht stoppt :-) (eigentlich sollte sowas ja koordiniert zwischen den Beteiligten geschehen, wer weiß, wo die da rumschrauben, wenn sie nicht miteinander sprechen)...

LG, Klaus

UPCUser
05.12.12, 00:48
Hier bei mir (WIEN) IP 62.178.***.*** hat sich nichts geändert.. Ping schlecht Speed schlecht

MFG

Edit: Von nem Proof OVH --> Download startet mit 3MB´s und fällt innerhalb von Sekunden auf 200-400kbs ab...

Von nem Kimsufi noch schlechter --> Down startet mit 2,5MB´s und fällt innerhalb Sekunden auf 150-300kbs.

Caddy
04.12.12, 23:45
Es gibt etwas Neues.

UPC hat mir geantwortet und angeblich etwas geändert. Das gilt vermutlich aber nur für Wien. Es müsste nun nochmal jemand testen, der definitiv noch über die alte Rückroute geht (die Netze hatte ich weiter oben beschrieben) Von meinem UPC Kontakt im 15. Bezirk habe ich mir gerade noch mal die Route von ihm zum Server schicken lassen, die hat sich allerdings nicht verändert. Für diejenigen, die es interessiert, hänge ich den kurzen Schriftverkehr um ein paar persönliche Details gekürzt nachfolgend an.

Gruß, Klaus

Meine Anfrage:
Gesendet: Montag, 19. November 2012 10:51

An: UPC Wien (Mailadresse entfernt)

Betreff: Technische Anfrage: Übertragungsgeschwindigkeiten UPC / OVH

Sehr geehrte Damen und Herren,

ich bin mir nicht sicher, ob diese eher technische Anfrage bei Ihnen unter dieser Mail-Adresse richtig platziert ist, falls nicht, wäre es nett, wenn Sie mir die richtige Adresse nennen, oder die Anfrage entsprechend weiterleiten. Es geht hier um sehr niedrige Übertragungsgeschwindigkeiten Ihrer Internetkunden zum Hosting-Anbieter OVH.

Als Betreiber (Details entfernt) haben wir in der letzten Zeit vermehrt Anfragen von UPC Kunden aus Wien, bei denen sehr niedrige Übertragungsgeschwindigkeiten zu und von unseren Servern die Nutzung stark beeinträchtigen.

Unsere Server stehen beim Anbieter OVH in Frankreich, mit dem wir eigentlich sonst keine Probleme dieser Art haben.

Wir stehen nun bereits in Kontakt mit OVH, wobei dort berichtet wird, dass sich das Thema nicht gerade einfach gestaltet. Details dazu gab es bisher nicht, da sich das Problem aber bereits über mehrere Monate erstreckt, möchten wir auf diesem Wege einmal direkt bei Ihnen anfragen.

Wir stehen auch in Kontakt mit einem UPC Kunden im 15. Bezirk, mit dem wir mehrfach ein paar Tests durchgeführt haben. In der Hauptzeit (ca. 18 bis 23 Uhr) bekommt dieser Kunde mit einer 100Mbit/s Leitung von UPC im Höchstfall ca. 1 Mbit/s Downloadgeschwindigkeit von unseren Servern bei OVH. Tests zu anderen Hostingabnietern in Deutschland zur gleichen Zeit zeigen Geschwindigkeiten von 50 Mbit/s und mehr, was durchaus akzeptabel ist.

Es gibt dazu ein Thema im deutschen Forum des Anbieters OVH, dessen Verlauf Sie hier einsehen können:

http://forum.ovh.de/showthread.php?t=11404

Das Thema wurde schon fast 5000 Mal gelesen, was auch ein erhebliches Interesse aufzeigt.

OVH bietet auch einen eigenen Speedtest an, den Sie hier

finden:

http://proof.ovh.net/

Ich würde mich sehr über eine Antwort freuen.

Mit freundlichen Grüßen

(ich)
Antwort von UPC:
Tue, 4 Dec 2012 14:16:24 +0000

Sehr geehrter Herr (ich),

vielen Dank, dass Sie uns kontaktiert haben.

Unsere zuständige Abteilung hat die Routingeinträge angepasst.

Verzeichnen Sie noch immer Performanceeinbußen aus dem Bereich Wien?
Die Frage (auch an Felix bzw. OVH) ist natürlich (ich habe eine direkte Antwortadresse von UPC bekommen und natürlich auch den Namen des Bearbeiters) ob es eher kontraproduktiv ist, wenn ich dort einfach mal weiter bohre, falls die Änderungen (wobei ich vom Routing her von UPC nach OVH keine Änderung sehe) nichts gebracht haben, oder ob ich's lieber lasse :-)

LG, Klaus

Yahoodi
02.12.12, 16:44
Moment, ist das nicht andersrum ?
Ein Trace vom Server zu UPC geht direkt - von UPC zu OVH geht über Telia.

Oder habe ich da was falsch verstanden ?

nenad
01.12.12, 02:58
Ich habe eine Idee.... OVH könnte die Option "UPC Upstream" bieten, wenn man diese bucht kommt man in den Genuss eines direkten Routings in's UPC Netz

NB: Solange OVH bei UPC keinen IP Transit einkauft ändert sich da nichts gross.....

Caddy
28.11.12, 11:39
Zitat Zitat von Darky68
und warum bekomme ich vom ftp.ovh.net server (fazit ein ovh server) nur noch 70-300 schwankend

@strex vielleicht kannst du die frage einem laien beantworten ovh und upc können es nicht
Wie soll er die Frage beantworten, man kann hier als Außenstehender nur Vermutungen anstellen. Wenn man dabei aber mal die Fakten zusammenzählt, deutet es schon darauf hin, dass das Problem bei UPC liegt, denn:

- Das Peering in die Schweiz nach UPC verhält sich EXAKT genau so. Die gleichen schlechten Übertragungsraten, der selbe Packet Loss.

- Zig andere Peerings von OVH verhalten sich völlig korrekt und haben diese Probleme nicht

- UPC antwortet mir als Außenstehender auf Anfragen überhaupt nicht. Klar, wer bin ich auch, ich bin ja kein UPC Kunde. (Die Vermutung stimmt nicht, denn ich bin Unitymedia Kunde. Unitymedia gehört Liberty Global, UPC gehört ebenfalls Liberty Global).

- Andere Probleme (Auslastungsprobleme, die ganz klar bei OVH liegen / lagen) werden von OVH erkannt und behoben.

Da mutmaßt man ja schon, dass das Problem wohl eher bei UPC liegt.
Wenn man dann noch mal etwas tiefer ins Netz schaut und findet zig Artikel, die mutmaßen, dass UPC den Traffic manchmal und zu diversen Zielen limitiert, da macht man sich schon seine Gedanken.

Wir als "Endverbraucher" werden vermutlich auch immer die Antwort bekommen, dass jeweils die andere Seite das Problem ist. Das Problem kann nur auf technischer Ebene direkt zwischen OVH und UPC geklärt werden. Das läuft ja bereits, wie Felix auch schon schrieb ("Wir sind dran", "Es ist nicht einfach").

Gruß, Klaus

Darky68
27.11.12, 18:21
Zitat Zitat von UPCUser
Zu nem Speedtest werden meist mehrere Verbindungen gleichzeitig aufgebaut, wenn du mit FTP was lädst dann nur mit einer Verbindung.

Wobei ich komme beim Speedtest nicht über 2mbit mit meiner 100mbit Leitung

Also mir kommt es vor als würde da jemand absichtlich drosseln (ws eh UPC)
zur info ich probier beides mit ftp prog filezilla client

fazit müsste wenn alles ok ist - bei beiden testservern ein 100mbit file bei mir maximal 2mbit rüber kommen

was A nur bei einem passiert und B beim ovh server eben nicht nur wie gesagt immer schwankend schlechtester wert in 2wochen 70 besster wert in 2wochen 300

UPCUser
27.11.12, 18:18
Zitat Zitat von Darky68

jetzt ist meine frage warum bekomme ich vollen speed 2mbit zb von einem testserver speedtest.qsc.de wenn ich ein 100mb grosses testfile lade

und warum bekomme ich vom ftp.ovh.net server (fazit ein ovh server) nur noch 70-300 schwankend
Zu nem Speedtest werden meist mehrere Verbindungen gleichzeitig aufgebaut, wenn du mit FTP was lädst dann nur mit einer Verbindung.

Wobei ich komme beim Speedtest nicht über 2mbit mit meiner 100mbit Leitung

Also mir kommt es vor als würde da jemand absichtlich drosseln (ws eh UPC)

Darky68
27.11.12, 18:10
Zitat Zitat von UPCUser
Laut UPC Service Techniker und auch der Businesshotline stimmen die Auslastungen auf der Weathermap nicht und mir wurde empfohlen mich an OVH zu wenden da der Fehler nicht am UPC Netz liegen soll.

Angeblich ist irgend ein langsamer Switch dazwischen or what ever ich kenn mich da auch nicht so aus damit.

War mit denen in Kontakt mit mehreren "Beweis Tracings" etc ,...

Und ja ich weis wenn ich nochmal anrufe sagt mir ein andrer Techniker wieder was ganz andres.

Darum wär es ja das beste wie schon von mir geschrieben das sich OVH mit UPC in Verbindung setzt, denn als normaler User hat man da anscheinend eh keine Chance.

MFG
das kann ich mit guten gewissen unterschreiben - wiegesagt bin inode kunde aus wien und habe wie schon beschrieben das gleiche problem

weiters wurde mir auch von inode und upc gesagt das sie hier keine probleme haben und man möge sich an ovh wenden, denn wenn man auf einen anderen server in deutschland zumt esten geht funktioniert alles einwandfrei, kommt man auf einen ovh server ist schluss damit


jetzt ist meine frage warum bekomme ich vollen speed 2mbit zb von einem testserver speedtest.qsc.de wenn ich ein 100mb grosses testfile lade

und warum bekomme ich vom ftp.ovh.net server (fazit ein ovh server) nur noch 70-300 schwankend

@strex vielleicht kannst du die frage einem laien beantworten ovh und upc können es nicht


klar das inode/upc sagen liegt nicht an uns - aber an wem liegt es dann wenn jetzt nicht an ovh oder irgendeinen lahmen router switch im netz

UPCUser
27.11.12, 17:57
Ich hab ja nicht gedroht, mir bleibt leider nix andres übrig... Ich muss jeden Tag mehrere GB an Daten Up und Downloaden und wenn ich leider nur 1Mbit erreiche geht das so leider nicht.

Klar hätte ich es auch freundlicher ausdrücken können, aber ich werd von UPC hierher verwiesen und hier heissts ich soll bei UPC fragen.

Und das es ja besser geht sieht man ja da andre User jetz Vollspeed haben. Habe diesbezüglich auch bei UPC schon angefragt ob sie mir nicht einfach eine andre IP geben können auf der das Tata Routing läuft, das machen sie aber mit der Begründung nicht das diese Statische IPs sind.

Deshalb hatte ich ja drauf gehofft das es OVH hinkriegt wenn UPC eben nicht will, nur schade das es eben nicht bei allen UPC Usern geht. Jetzt sind wir faktisch zweigespalten...der eine voll der andre nix.

strex
27.11.12, 17:47
Zitat Zitat von UPCUser
Darum wär es ja das beste wie schon von mir geschrieben das sich OVH mit UPC in Verbindung setzt, denn als normaler User hat man da anscheinend eh keine Chance.
MFG
Das wurde sicher schon lange getan. Das braucht eben seine Zeit. Als das selbe Spiel mit der Telekom war, hat das durchaus fast ein Jahre gedauert. Ihr seit also noch gut dran. Bis Januar ist ja nicht mehr lange, warum ist das denn nicht hinnehmbar, dass man mit Kündigung droht?

UPCUser
27.11.12, 17:42
Laut UPC Service Techniker und auch der Businesshotline stimmen die Auslastungen auf der Weathermap nicht und mir wurde empfohlen mich an OVH zu wenden da der Fehler nicht am UPC Netz liegen soll.

Angeblich ist irgend ein langsamer Switch dazwischen or what ever ich kenn mich da auch nicht so aus damit.

War mit denen in Kontakt mit mehreren "Beweis Tracings" etc ,...

Und ja ich weis wenn ich nochmal anrufe sagt mir ein andrer Techniker wieder was ganz andres.

Darum wär es ja das beste wie schon von mir geschrieben das sich OVH mit UPC in Verbindung setzt, denn als normaler User hat man da anscheinend eh keine Chance.

MFG

strex
27.11.12, 17:16
Zitat Zitat von UPCUser
Erstmal hab ich nie gesagt das ich einen Isgenug hab, zweitens wer sagt dir das es nur ein Root ist?
Auch wenn es 10 oder 100 sind, dass würde die Kosten für das Peering mit UPC bei weitem nicht decken.

Zitat Zitat von UPCUser
Und ich hab auch NICHT behaupted das OVH schuld ist.
Da lesen deine Beiträge sich aber ganz schön anders, du forderst von OVH das es schnell liegt und jammerst wenn das nicht möglich ist. Hast du schon so viel Kommunikation mit UPC betrieben. Ich glaube nicht..

Zitat Zitat von UPCUser
Und wenn du schon von Niveau redest solltest dir mal deine eigenen Postings durchlesen, denn statt Lösungsvorschläge oder dergleichen vorzuschlagen postest du so gut wie überall nur Schwachsinn dazu den eh keinen interessiert oder nichts mit dem Thema zu tun hat.
Meine Posting sind meist sehr hilfreich, sonst wären das nicht schon 1600 Stück. Nur das ewige Gejammere und die Forderung bringen ab und zu auch einmal in paar nette Kommentare um die User, wie auch dich, wieder auf den Boden der Tatsachen herunterzuholen. Dir reicht nicht der Januar, alles soll sofort zur Verfügung stehen, sind wir im Wunschparadis? Dann will ich auch was Du forderst und drohst mit Kündigung, konstruktiv nenne ich was anderes, wenn ich da meine Postings mit deinen vergleiche, hmm, wer hat da wohl mehr Niveau?

Zitat Zitat von UPCUser
Du hast ws den ganzen Tag nichts besseres zu tun als Leute zu beleidigen oder zu nerven.
Selbst wenn du persönlich gegen mich was haben solltest, was hat das jetzt mit dem Thema hier zu tun ?!
Ich habe hier noch keinen Beleidigt, so etwas verbitte ich mir! Alles was ich geschrieben habe, war konstruktiv und korrekt. Beleidigen tuen hier nur andere

Zitat Zitat von UPCUser
Übrigens garantiert OVH natürlich nicht den vollen Speed, das macht kein Provider, jedoch kann ich mich dunkel erinnern das 90mbit garantiert sind.
Garantiert bis nach Hause ist gar nichts, auch keine 90 Mbit/s oder eine andere Bandbreite. OVH hat nur Kontrolle über das eigene Netz, sobald die Pakete dies verlassen haben ist eine Kontrolle nicht mehr möglich. Das wäre aber für eine Garantie von Nöten.

Zitat Zitat von UPCUser
Und die sollten auch mit meiner UPC 100mbit Leitung abrufbar sein.
Und selbst wenn die nicht garantiert sind erreiche ich nur 1 !! MBIT.... und zwischen 100 und 1 ist aber schon n Unterschied denkst du nicht?
Warum sollten die abrufbar sein? Wer sagt oder garantiert dir das? Keiner! Ich erhalten von meinem Handy, aus China oder Afrika auch nicht die volle Bandbreite? Erstelle ich dafür zig Threads und Postings und fordere garantierte Bandbreite nach China. Nein das tue ich nicht, auch wenn die Bandbreite aus China und Afrika durchaus noch schlechter sind. Wer etwas technisches Verständnis für Netzinfrastruktur hat, weiß auch warum das nicht möglich ist.


Zitat Zitat von UPCUser
UPC hat hier bei uns eben eine Monopolstellung und da hat man eben nicht die große Auswahl, schon garnicht wenn man anständigen Speed möchte.
Wie man sieht, bringt UPC zu einigen Ziele nicht besonders viel Speed. Vielleicht ein anderer, bestimmt! Dann musst du auch mit dem Speed leben und nicht jeden Tag weitere Postings verfassen. Was soll das bringen, du drohst ja ständig mit einer Kündigung, dann setze auch einmal deine Worte in Taten um. Das wäre wohl für dich und OVH das Beste.

Zitat Zitat von UPCUser
Also nochmal extra für dich --> Mir egal wer schuld ist, ob OVH oder UPC, es muss sich nur was ändern da eben besagte UPC User im Moment nichts anfangen mit nem Root von OVH.
Wenn dir egal ist wer Schuld hat, wende dich an die UPC oder such dir einen anderen Serverhost. Wenn Felix es sagt es ist nicht möglich, ist es nicht möglich. Was soll man da weiter diskutieren und jammern. Genau, das bringt nix! Die Lösungen wurden dir aufgezeigt, jammern bringt nichts, also bis du am Zug etwas zu unternehmen.

UPCUser
27.11.12, 16:29
Erstmal hab ich nie gesagt das ich einen Isgenug hab, zweitens wer sagt dir das es nur ein Root ist?

Stimmt schon das wegn ein paar Roots OVH nicht untergeht, ich hab auch nur gesagt das man als UPC User im Moment OVH nicht ordentlich nutzen kann...

Und ich hab auch NICHT behaupted das OVH schuld ist.

Und wenn du schon von Niveau redest solltest dir mal deine eigenen Postings durchlesen, denn statt Lösungsvorschläge oder dergleichen vorzuschlagen postest du so gut wie überall nur Schwachsinn dazu den eh keinen interessiert oder nichts mit dem Thema zu tun hat.

Du hast ws den ganzen Tag nichts besseres zu tun als Leute zu beleidigen oder zu nerven.
Selbst wenn du persönlich gegen mich was haben solltest, was hat das jetzt mit dem Thema hier zu tun ?!

Übrigens garantiert OVH natürlich nicht den vollen Speed, das macht kein Provider, jedoch kann ich mich dunkel erinnern das 90mbit garantiert sind.

Und die sollten auch mit meiner UPC 100mbit Leitung abrufbar sein.
Und selbst wenn die nicht garantiert sind erreiche ich nur 1 !! MBIT.... und zwischen 100 und 1 ist aber schon n Unterschied denkst du nicht?

UPC hat hier bei uns eben eine Monopolstellung und da hat man eben nicht die große Auswahl, schon garnicht wenn man anständigen Speed möchte.

Also nochmal extra für dich --> Mir egal wer schuld ist, ob OVH oder UPC, es muss sich nur was ändern da eben besagte UPC User im Moment nichts anfangen mit nem Root von OVH.

strex
27.11.12, 15:31
Zitat Zitat von UPCUser
Und wenn ich nen 100mbit Root habe will ich auch 100 Mbit nutzen können und nicht nur 1!!MBIT.... Ich kauf mir auch keinen Porsche mit 50 PS...
Dir garantiert keiner (Kein Serveranbieter der Welt), dass du Fullspeed bis nach Hause bekommst. Es wird der lediglich 100 Mbit/s am Switchport gegeben. Ich krieg ja auch nicht 1000 Mbit/s nach Hause, der Root kann es, wenn meine Leitung nur 50 Mbit/s ermöglicht. Ich will ja volle Leistung...

Der Autovergleich ist ja auch voll daneben, wie fast alle Aussagen von dir. Eher kannst du den Porsche nicht voll ausfahren, weil die Geschwindigkeit begrenzt ist. Kann dafür der Hersteller etwas? Genau, nein der ist nicht verantwortlich.

Zitat Zitat von UPCUser
Auf alle Fälle können UPC User im Moment nichts mit OVH anfangen da man ja dann nicht weis welchen Speed man bekommt...
Drehen wir doch die Geschichte um, mit UPC kann man nichts anfangen..Dann solltest du den Anbieter wechseln. Bitte mach deine Drohung war und verlass uns, wegen dem einen Isgenug, geht OVH schon nicht unter. Dann ist hier endlich wieder ein richtiges Niveau vorhanden.

UPCUser
27.11.12, 15:12
Nun ich weis das es nurnoch 8 Wochen sind bis Jänner, nur wer garantiert mir das diese Lösung dann funktioniert? Im Moment haben UPC User lahmen Speed und andre UPC User bekommen den maximalen.... das ist doch irgendwie nicht in Ordnung, egal ob es jetzt an OVH oder UPC liegt.... Ok OVH hat etwas dagegen getan und ein paar UPC User auf Tata geroutet, aber von einer Lösung ist das weit entfernt.

Wenn jetzt jemand aus Wien bei OVH einen Root mietet dann wird es zum Glücksspiel ob er nun lahmen oder vollen Speed bekommt....

Das ist doch nicht Sinn der Sache oder?

Und wenn ich nen 100mbit Root habe will ich auch 100 Mbit nutzen können und nicht nur 1!!MBIT.... Ich kauf mir auch keinen Porsche mit 50 PS...

Ja das Peering auf der Weathermap sieht leer aus, na und es geht trotzdem nichts weiter und alles ist lahm... Was hab ich davon wenn die Auslastung bei 0% liegt und ich keinen Speed bekomme? Da ist mir lieber es wird 80% angezeigt und dafür geht was weiter..

Auf alle Fälle können UPC User im Moment nichts mit OVH anfangen da man ja dann nicht weis welchen Speed man bekommt...

Caddy
27.11.12, 13:44
Zitat Zitat von UPCUser
Na toll.... dann bin ich der nächste der bei OVH kündigt.
Naja, wenn wir mal ehrlich sind, zieht sich das eigentliche Problem ja schon mehrere Monate hin. Ich weiß ja nicht, wie lange Du schon bei OVH bist, wenn wir von einer Lösung bis Ende Januar ausgehen, sind das noch ca. 8 Wochen. Ich bin zwar persönlich bei diesem Problem nahezu unbetroffen, lediglich einer unserer Gameserver Admins kommt aus Wien und ein paar Spieler. Wir würden aber dafür nicht den Anbieter wechseln. Mit dem Peering der restlichen Netze bin ich zufrieden und ich liebe die Transparenz von OVH.

Bemerkenswert in dieser Angelegenheit ist auch, dass ich am 19.11.2012 UPC in dieser Angelegenheit einmal ganz unverbindlich angeschrieben habe, es gab bis heute weder irgend eine Rückmeldung, noch sonst irgendein Lebenszeichen.

Gruß, Klaus

kenshin
27.11.12, 08:58
http://weathermap.ovh.net/wien

nuja, die Leitung ist aber nunmal ziemlich leer. Nicht zuletzt da jetzt der Großteil der User über TATA geht. (Warum das für die restlichen nicht ohne weiteres geht muss Felix mal detaillierter erklären wenn es ihm möglich ist, das ist mir auch nicht ganz klar).
Allerdings: Ne ohnehin leere Leitung in die Richtung zu drosseln erscheint mir reichlich widersinnig.

Und UPC hat in Sachen Peering Policy nunmal seinen Ruf weg, der schwarze Peter/Beweislast mangels Transparenz seh ich in dem Fall nicht zuletzt dank der offen einsehbaren Weathermap hier erstmal bei UPC , auch wenn das hier natürlich das OVH Forum ist.

Darky68
27.11.12, 08:38
Zitat Zitat von kenshin

Dein Speed ist trotzdem scheisse. Könnte es eventuell an UPC liegen? Nie nicht.
ist nicht nur chello von upc

ist ja entbündelte telefonleitung xdsl von inode das gleiche

und laut inode (tochter von upc) wird nichts gedrosselt man soll sich mit ovh in verbindung setzen

ovh sagt dann upc

da wird man wie ein squashball hin und her geschickt

warum setzt sich ovh nicht mal mit inode in verbindung bzw auch mit upc und klärt das von firma zu firma

kenshin
27.11.12, 08:27
Zitat Zitat von UPCUser
Na toll.... dann bin ich der nächste der bei OVH kündigt.

Bis Jänner warte ich nicht da such ich mir einen andren Hoster.

Mir ist nicht ganz klar warum bereits andere UPC User über Tata gehn aber für die restlichen das nicht möglich sein soll....


Ok das wars für mich hier

So long... MFG

also: du hast aktuell ne leere Leitung zwischen OVH und deinem ISP. OVH drosselt nichts laut Felix und Bandbreite ist auch genug da.

Dein Speed ist trotzdem scheisse. Könnte es eventuell an UPC liegen? Nie nicht.

zakazak
26.11.12, 21:40
Schade das ein OVH Kunde nach dem anderen geht... da bei mir vorerst der Speed in Ordnung ist werd ich wohl nicht kündigen und mal 3 Monate verlängern.

strex
26.11.12, 16:29
Tschüss

UPCUser
26.11.12, 15:28
Zitat Zitat von Felix
Das ist momentan leider nicht möglich.
Na toll.... dann bin ich der nächste der bei OVH kündigt.

Bis Jänner warte ich nicht da such ich mir einen andren Hoster.

Mir ist nicht ganz klar warum bereits andere UPC User über Tata gehn aber für die restlichen das nicht möglich sein soll....


Ok das wars für mich hier

So long... MFG

Felix
26.11.12, 13:12
Zitat Zitat von Caddy
Die Frage ist ja nun, ob es noch möglich ist (zumindest bis im Januar eine Lösung in Sicht ist), die verbliebenen Subnets ebenfalls über TATA zu routen.
Das ist momentan leider nicht möglich.

Caddy
26.11.12, 12:32
Zitat Zitat von Felix
Das Peering mit UPC in Wien ist nun fast leer, es gibt von unserer Seite keinerlei Restriktionen, Überlastungen oder sonstiges. Wir vermuten das seitens UPC gedrosselt wird.
Wie auch immer und was auch immer dafür sorgt, dass auf dem alten Peering selbst dann, wenn es leer ist, alles total langsam ist - Das Problem aus der "Nutzer Sicht" ist ja derzeit, dass alles, was ihr an UPC Netzen derzeit über TATA routet, "Fullspeed" gibt, alles was noch auf dem alten Wiener Peering liegt, langsam ist. Ihr habt ja jetzt unbewusst eine 2-Klassen Gesellschaft geschaffen:

- UPC User, die auf dem alten Peering verblieben sind (langsam)
- UPC User, die über TATA routen (schnell)

Die Leute wohnen teilweise nur ein paar Straßen vonenander entfernt. Bei UPC bzw. speziell bei Chello (ehemals Telekabel Wien) haben die Nutzer quasi eine statische IP-Adresse - Sie ändert sich (manchmal) nur, wenn man das Kabelmodem wechseln lässt.

Die Frage ist ja nun, ob es noch möglich ist (zumindest bis im Januar eine Lösung in Sicht ist), die verbliebenen Subnets ebenfalls über TATA zu routen.

Gruß, Klaus

Felix
26.11.12, 10:59
Zitat Zitat von UPCUser
Tut sich hier noch was ?
Das Peering mit UPC in Wien ist nun fast leer, es gibt von unserer Seite keinerlei Restriktionen, Überlastungen oder sonstiges. Wir vermuten das seitens UPC gedrosselt wird.

UPCUser
24.11.12, 15:28
Tut sich hier noch was ?

Ich hab nach wie vor lahmen Speed :/ und die Route läuft immer noch nicht über Tata mit meiner IP.

MFG

UPCUser
22.11.12, 12:19
Sorry ja hattest recht IP ist 62.178.255.**** und da geht nach wie vor nicht viel.... Bitte nochmal ransetzen OVH.

Danke für die Mühe

Edit: Zu nem Proof OVH schaff ich 1MB UP und zu nem Kimsufi nur zwischen 50-150kbs.... Das ne Katastrophe, bitte kriegt das noch hin.

Edit2: Hab jetzt auch mal ein Tracert zu OVH gemacht mit dem Ergebnis das es ständig Packetlos gibt und hier nicht über Tata geroutet wird. (also immer noch die alte Route verwendet wird)

IP 62.178.255.***

Caddy
21.11.12, 21:33
Zitat Zitat von UPCUser
Meine IP bei UPC ist 162.178.****** und der Speed ist zwar besser aber noch nicht das gelbe vom Ei.
Bist Du sicher mit der IP? Laut RIPE könnte es eher 62.178.x.x sein:
http://bit.ly/Qvljbm

Dieses Netz geht übrigens auch noch über die alte Route:
Code:
 Host                                          Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. rbx-6-m1.fr.eu                              0.0%     9    0.8   0.8   0.4   1.4   0.2
 2. rbx-2-6k.fr.eu                             11.1%     9    0.3   0.7   0.3   1.9   0.6
 3. rbx-g2-a9.fr.eu                             0.0%     9    0.8  10.6   0.7  88.6  29.2
 4. fra-5-6k.fr.eu                             87.5%     9    8.1   8.1   8.1   8.1   0.0
 5. pra-1-6k.cz.eu                              0.0%     9   16.3  48.8  16.1 164.9  64.6
 6. vie-1-6k.at.eu                              0.0%     8   20.9  22.9  20.7  37.3   5.8
 7. upc.as6830.at.eu                            0.0%     8   26.3  26.4  26.3  26.6   0.1
 8. at-vie01a-ra3-ge-0-1-0.aorta.net            0.0%     8   21.8  26.3  21.4  50.9  10.1
 9. at-vie-sk11-pe01-vl-2042.upc.at             0.0%     8   26.7  29.0  26.7  43.8   6.0
10. chello062178XXXXXX.4.11.vie.surfer.at       0.0%     8   21.9  21.8  21.5  22.7   0.4
Ob die vielleicht vergessen wurden, dazu kann nur Felix was sagen. Wenn dem so ist, wäre auch klar, warum es bei euch noch langsam ist.

Gruß, Klaus

Hook
21.11.12, 20:17
Zitat Zitat von Darky68
jetzt stellt sich noch eine frage für mich - wenn ich provider wechsel zb zu telekom hab ich da die gleichen probleme?????
nein.

UPCUser
21.11.12, 19:45
Meine IP bei UPC ist 162.178.****** und der Speed ist zwar besser aber noch nicht das gelbe vom Ei. Download mit einem Stream schwankt zwischen 300kbs und 2 MB... Der Upload mit einem Stream zwischen 300kbs und 1MB.

Grade auf den UPLOAD wär ich angewiesen das der stabil ist. Und mehr als ein Stream ist nicht möglich bei mir.

MFG

Caddy
21.11.12, 18:38
Zitat Zitat von Felix
Wie genau äussern sich denn Probleme bei diesen IP-Ranges?
Die Route vom Server zu meinem UPC Kunden, der richtig Speed bekommt:

Code:
 Host                                          Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. rbx-6-m1.fr.eu                              0.0%    74    0.7   1.1   0.5  26.4   3.1
 2. rbx-2-6k.fr.eu                             27.4%    74    0.4   4.5   0.2 121.2  18.8
 3. rbx-g2-a9.fr.eu                             0.0%    74    0.7  12.9   0.5 344.8  53.5
 4. fra-5-6k.fr.eu                             33.8%    74    7.9   9.1   7.9  51.5   6.4
 5. tata.as6453.de.eu                           0.0%    74   18.4  12.7   8.0  21.4   4.4
 6. if-4-1108.tcore1.FNM-Frankfurt.as6453.net   0.0%    74    8.3   9.1   8.0  60.3   6.2
 7. if-5-2.tcore1.AV2-Amsterdam.as6453.net      0.0%    74   10.7  12.1  10.3  41.1   5.3
 8. if-2-2.tcore2.AV2-Amsterdam.as6453.net      0.0%    74   10.3  11.0   9.9  60.0   5.8
 9. 80.231.152.22                               0.0%    74   14.7  14.6  14.2  17.7   0.5
10. nl-ams05a-rd2-xe-4-2-2.aorta.net            2.7%    74   28.4  28.9  27.8  59.8   4.0
11. at-vie01a-rd1-xe-0-2-0.aorta.net            5.5%    73   33.3  36.0  33.1  76.8   7.5
12. at-vie-sk11-pe01-vl-2042.upc.at             2.7%    73   33.2  36.4  32.9 117.6  12.4
13. at-vie-sk11-pe02-vl-1.upc.at                2.7%    73   27.9  30.1  27.8  56.8   6.7
14. ???
15. chello213047xxxxxx.20.11.vie.surfer.at      0.0%    73   40.8  44.4  39.7  70.4   4.9
Die IP des Kunden liegt im 213.47.x.x Bereich und wird von unserem Server in Roubaix 1 über TATA geroutet.

Die beiden Netze, die ich oben beschrieben habe sind ebenfalls UPC Vienna und routen den Weg:
Code:
 Host                                          Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. rbx-6-m1.fr.eu                              0.0%    11    0.6   0.7   0.5   1.0   0.1
 2. rbx-2-6k.fr.eu                              0.0%    11    2.3   1.8   0.3  14.5   4.3
 3. rbx-g2-a9.fr.eu                             0.0%    11    0.9  36.9   0.8 396.1 119.1
 4. fra-5-6k.fr.eu                             27.3%    11    8.4   8.1   7.9   8.4   0.2
 5. pra-1-6k.cz.eu                              0.0%    11   16.0  16.1  16.0  16.3   0.1
 6. vie-1-6k.at.eu                              0.0%    11   20.7  20.8  20.6  21.5   0.3
 7. upc.as6830.at.eu                            0.0%    10   26.5  26.4  26.3  26.5   0.1
 8. 213.46.173.126                              0.0%    10   21.5  22.4  21.4  28.6   2.2
 9. at-vie-sk11-pe02-vl-2043.upc.at            20.0%    10   22.9  22.5  22.2  23.0   0.3
10. at-vie-sk11-pe01-vl-1.upc.at                0.0%    10   26.9  29.3  26.9  50.0   7.3
11. ???
12. chello084112XXXXXX.23.11.vie.surfer.at      0.0%    10   30.0  29.2  27.8  30.9   1.0
Das ist die alte Route, die nicht über TATA geht. Die IP Blöcke tauchen im Posting von sting und Faultier auf, die auch beide noch den alten langsamen Speed haben ...

Gruß, Klaus

Darky68
21.11.12, 18:04
obwohl ich nur noch 2tage kunde bin da ja der speed zu ovh servern noch immer für mich im keller ist

kann ich euch nur sagen - das ich zum ftp.ovh.net server mit dem test.bin file

im schnitt nur 75-200kb/s schaffe - einzig heute früh um 9herum gings mal auf 500

ich bin inode kunde einem tochterunternehmen von upc

ich würde gern wieder einen server bei euch mieten aber erst wenn ihr zumindest eine bandbreite zu upc/inode von mindest 1.0mbit verischern könnt - alles darunter wäre unzumutar


ich würd mich über eine rückmeldung von ovh - wenn dies erreicht ist gern freuen - da ihr dann wieder einen kunden habt

Felix
21.11.12, 15:41
Zitat Zitat von Caddy
@Felix : Falls Du noch mit liest, ihr habt vermutlich ein paar Netzblöcke vergessen, zumindest den da:
inetnum: 80.108.148.0 - 80.109.127.255
Wie genau äussern sich denn Probleme bei diesen IP-Ranges?

Caddy
20.11.12, 23:15
Zitat Zitat von sting
Kann mein UPC Kontakt in Wien so leider nicht bestätigen...

Tests @ proof.ovh.net:
Code:
IP		Down (kb/s)	Up (kb/s)	Latency (ms)
80.109.39.xxx	11745		7209		69
80.109.39.xxx	12769		8160		68
80.109.39.xxx	10037		8615		68
Auslastung laut Weathermap (vie-3-f10): 49% und 56%

Speedtest.net:
http://www.speedtest.net/result/2320921019.png
@Felix : Falls Du noch mit liest, ihr habt vermutlich ein paar Netzblöcke vergessen, zumindest den da:
inetnum: 80.108.148.0 - 80.109.127.255
netname: CHELLO
descr: UPC Telekabel
route: 80.109.0.0/16

Das ist auch der Grund, warum vielleicht manche UPC Kunden noch Probleme haben. Leider kann man dort als UPC Kunde ja auch nicht so einfach seine IP wechseln ...

Gruß, Klaus

Edit: Den auch:
inetnum: 84.112.0.0 - 84.115.43.7
netname: CHELLO
descr: UPC Austria
route: 84.112.0.0/14

Gehen beide über die alte Route (upc.as6830.at.eu).

Edit2: Für die Weathermap Freaks - Wenn der Traffic über TATA geroutet wird, dann kann vie-3-f10 in Flammen stehen, darüber geht der Traffic gar nicht mehr :-)

UPCUser
20.11.12, 22:29
Zitat Zitat von faultier
bei mir UPC Wien:
84.114.63.xxx 41680 9081 32

Das sieht gut aus, ABER beim FTP geht nur 1400 kb/s im Moment, schwankend nach unten.
Früher hatte ich 4000 kb/s.

Aber wenn es vorerst mal so bleibt, damit kann ich mal leben.
Wenn du mit FTP arbeitest kannst du ja die gleichzeitigen Downloads erhöhen dann passt der Speed auch wieder.

Ich hatte das Problem das ich nur 1nen Stream habe, mehrere auch nicht möglich sind, und da kam ich nicht über 200kbs.

Ps.: Auch UPC Wien

faultier
20.11.12, 21:51
bei mir UPC Wien:
84.114.63.xxx 41680 9081 32

Das sieht gut aus, ABER beim FTP geht nur 1400 kb/s im Moment, schwankend nach unten.
Früher hatte ich 4000 kb/s.

Aber wenn es vorerst mal so bleibt, damit kann ich mal leben.

UPCUser
20.11.12, 21:45
Es geht auf alle Fälle mal besser als vorher. Die Auslastung lag sonst Rund um die Uhr bei 70-90% bei UPC Wien. Der Upload flutscht jetzt auch Richtung OVH Root. Der Down schwankt zwischen 2MB und 6 MB.... Bin zufrieden bis Januar wenn es so bleibt.... Auf alle Fälle nochmal ein dickes Danke für die Mühe... und bitte nicht wieder was zerbasteln

sting
20.11.12, 21:16
Kann mein UPC Kontakt in Wien so leider nicht bestätigen...

Tests @ proof.ovh.net:
Code:
IP		Down (kb/s)	Up (kb/s)	Latency (ms)
80.109.39.xxx	11745		7209		69
80.109.39.xxx	12769		8160		68
80.109.39.xxx	10037		8615		68
Auslastung laut Weathermap (vie-3-f10): 49% und 56%

Speedtest.net:
http://www.speedtest.net/result/2320921019.png

Caddy
20.11.12, 20:15
Irgendwer hat doch heimlich den proof.ovh.net repariert :-)
Mein UPC Kontakt jubelt schon so laut, dass ich es fast hier in DE höre, die Speedtests vom proof.ovh.net liegen bei ihm jetzt durchgehend zwischen 40 und 80 Mbit/s.

Jetzt habe ich, neugierig wie ich bin, von mir (Unitymedia, NRW) auch nochmal getestet:
Last Result:
Download Speed: 112442 kbps (14055.3 KB/sec transfer rate)
Upload Speed: 5071 kbps (633.9 KB/sec transfer rate)
Latency: 32 ms
Dienstag, 20. November 2012 20:05:48

Für mich lege ich das erstmal als erledigt ab. Auch wenn die Pings abends hochgehen, der Durchsatz bleibt bisher. Ich hoffe dann, dass die "Januar" Lösung dann nochmal einen kleinen Latenzschub bringt.

Danke :-)
Gruß, Klaus

Yahoodi
20.11.12, 19:14
So, jetzt habe ich mal was recht verrücktes gebastelt. Ich habe noch einen V-Server bei einem Mitbewerber in Deutschland. Zu diesem habe ich von meiner Linux-Kiste zuhause einen OpenVPN gebaut und benutze ihn als Gateway. Weil ich zu faul bin in diesem Tunnel ein ordentliches Routing einzurichten habe ich noch zusätzlich 2 x NAT dazwischen. Der Windows-Rechner benutzt meine Linux-Kiste als Gateway. Nun bekomme ich 96 Mbit von proof.ovh.net und sogar 99 Mbit von meinem Server in Roubaix ;-)

Wenn selbst so eine Krüppelkonfiguration um diese Uhrzeit geht - tja dann werde ich mir wohl erstmal keine Sorgen mehr machen :-)

Direkt (UPC in der Nähe von Zürich) tröpfeln von proof.ovh.net so um die 3 Mbit durch, vom Server immerhin 4. Das war auch schonmal schlechter ...

zakazak
20.11.12, 16:47
download und ping sind aufjedenfall besser geworden !

10mbit/s durchschnittlich.

UPCUser
20.11.12, 12:58
Also im Moment sieht es gut aus -->

http://www10.pic-upload.de/20.11.12/ejsmjwfqw93.jpg

Jedoch ist die Auslastung auf der Weathermap Wien gerade niedriger, ich trau mich wetten das heute Abend wieder nichts mehr durch die Leitung geht.

Wenn es so bleiben würde dann wär ich zufrieden und bleib bei OVH... Mal heute Nacht nochmal prüfen dann wirds wieder stauen

faultier
20.11.12, 09:53
Also ich bin in Wien, UPC 100 mb Leitung, im Moment erreiche ich ca 900 -1100 kb/s. Viel besser geworden als in den letzten Tagen, normalerweise habe ich bis zu 4000 kb/s bei dem FTP Server.
Aber je länger es dauert, um so langsamer wird es. Jetzt nur noch 800 kb/s

Caddy
20.11.12, 00:00
Also ich habe mit meinem UPC Kontakt gerade nochmal getestet. Speedtests über proof.ovh.net bringen irgendwie nichts, das Ding ist ziemlich unzuverlässig. Wir haben nochmal einen Download direkt von unseren Servern gemacht. Es kommen von Roubaix 1 tx: 38.52 Mbit/s 3608 p/s (mit vnstat direkt auf dem Serverinterface gemessen, deckt sich auch mit der Angabe beim Testenden. So viel gab's schon lange nicht mehr.
Von einem anderen Server (Roubaix 3): tx: 61.15 Mbit/s 5457 p/s

Das "Testobjekt" sitzt im 15. Bezirk in Wien. Geschwindigkeit vor der Änderung: höchstens 1-2 Mbit/s.

Den Speedtest unter proof.ovh.net sollten wir wohl vergessen

Gruß, Klaus

UPCUser
19.11.12, 23:28
Ja bei mir auch nach wie vor sehr starke Schwankungen von 20- 200kbs maximal...

Wenn sich bis Ende der Woche nix ändert werd ich wohl auch kündigen, Kann mir ja keiner zumuten nen 100mbit Root mit 200kbs zu nutzen.

Yahoodi
19.11.12, 23:01
über UPC in der Nähe von Zürich mit 100 Mbit-Anschluss:

Download Speed: 5556 kbps (694.5 KB/sec transfer rate)
Upload Speed: 4512 kbps (564 KB/sec transfer rate)
Latency: 34 ms
Mon Nov 19 23:00:11 2012

Ich glaube das war die letzten Tage aber immer so.

zakazak
19.11.12, 22:13
173kbit/s

UPCUser
19.11.12, 20:18
@ OVH Team

Erstmal vielen Dank das ihr euch so mühe gebt, und das auch noch so schnell. Normal sollte sich da ja UPC drum kümmern.

Erreiche beim Speedtest 200-300 kbs beim Down von nem Proof.OVH - Des weiteren zeigt die Weathermap UPC Wien ja auch gerade 87% auslastung. da geht ws nicht mehr.

Caddy
19.11.12, 19:37
Zitat Zitat von Felix
OK, noch etwas Feintuning: Jetzt noch besser?
Last Result:
Download Speed: 2812 kbps (351.5 KB/sec transfer rate)
Upload Speed: 2640 kbps (330 KB/sec transfer rate)
Latency: 106 ms
Montag, 19. November 2012 19:29:39

von eurem Speedtest, Testdownload von unserem Server: zwischen 4 und 8 MBit/s, kein Packet Loss. Der Ping zu unserem Server (Roubaix 1) liegt auch recht gleichmäßig bei 45ms, bei eurem Speedtest deutlich höher. Vielleicht testet auch gerade Gott und die Welt :-)

Edit: Euren Speedtest nehme ich dann lieber nicht mehr. Der zeigt bei mir über Unitymedia folgendes:
Download Speed: 3562 kbps (445.3 KB/sec transfer rate)
Upload Speed: 4061 kbps (507.6 KB/sec transfer rate)
Latency: 27 ms

Von unserem Server bekomme ich aber Fullspeed ( ~98Mbit/s ) :-)
Ich habe meinen UPC Kontakt auch lieber von unserem Server downloaden lassen.

Gruß, Klaus

Felix
19.11.12, 19:24
Zitat Zitat von Felix
das bleibt jetzt erstmal so bis die bessere Lösung umgesetzt werden kann.
OK, noch etwas Feintuning: Jetzt noch besser?

Felix
19.11.12, 19:17
Zitat Zitat von Caddy
Beim Routing über TATA hatte sich vorher schon gezeigt, dass es zwar recht stabil ist, aber auch ziemlich Tageszeitabhängig... Wenn es geht, lasst es bitte erst mal so
Danke für die Rückmeldung! Ja, das bleibt jetzt erstmal so bis die bessere Lösung umgesetzt werden kann.

zakazak
19.11.12, 19:16
ich versteh nicht ganz warum ich bei proof.ovh 7,8mbit/s schaffe und zu meinem server nichtmal 3mbit/s (von möglichen max. 20mbit/s)

Caddy
19.11.12, 19:05
@Felix:

Seit ziemlich exakt 18:20 Uhr ist der Packet Loss verschwunden, das Routing vom Server nach UPC geht wieder über TATA, der Durchsatztest lag gerade bei ca. 4Mbit/s Server -> UPC - Das ist für "temporär" schon mal gut :-)

Beim Routing über TATA hatte sich vorher schon gezeigt, dass es zwar recht stabil ist, aber auch ziemlich Tageszeitabhängig... Wenn es geht, lasst es bitte erst mal so

Gruß, Klaus

Darky68
19.11.12, 19:02
ftp.ovh.net test.bin file

jetzt 200-230kbs

Felix
19.11.12, 18:39
Zitat Zitat von UPCUser
Edit: Es spricht doch nichts gegen eine temporäre Lösung bis Januar.. Hauptsache es läuft mal mit akzeptablem Speed.
Ja, an der arbeiten wir in diesem Moment... Kannst du jetzt nochmal testen (sowie erneuten traceroute posten falls nicht besser)

Darky68
19.11.12, 17:26
meine lösung sieht so aus

ich kündige den ovh server

ich wechsel den provider von upc/inode zu 99% a1telekom

und nehm mir dann wieder einen ovh server


nur das sollte keine lösung für keinen ovh/UPCInode-Kunden sein

das ist eine für österreichische zwitterlösung mit der ich nicht grad glücklich bin aber wenns klappt zufriedener

ich hoffe für ovh udn den anderne upc kunden das sich die problematik lösen lässt

UPCUser
19.11.12, 17:15
Und wie sieht die entgültige Lösung aus ? Hat UPC zugesagt für den Traffic zu zahlen ? Oder werden die Routings geändert? Bis Jänner warten ist eine Katastrophe.

Eben getestet von einem PROOV.OVH bekomme ich mit nur einem Stream 200kbs und das bei meiner 100.000er Leitung....

Ping ist extrem schlecht und die 200kbs schwanken zwischen 10kbs!! und 200...

Schade ich hatte mich vor ein paar Wochen so gefreut da da ja alles bestens lief mit 12MB..

LG

Edit: Es spricht doch nichts gegen eine temporäre Lösung bis Januar.. Hauptsache es läuft mal mit akzeptablem Speed.

Felix
19.11.12, 17:09
Hum, ok... Danke für das Feedback, ist schon weitergeleitet... Wir sind dran.
Eine endgültige (statt temporärer) Lösung ist in Sicht, kann aber voraussichtlich erst im Januar umgesetzt werden.

Darky68
19.11.12, 16:55
ich teste das mit filezilla auf

ftp.ovh.net

und lade das test.bin file

und habe 84kb/s (gerne auch screen wenn gewünscht)

traceroute zum ftp.ovh.net

Routenverfolgung zu ftp.ovh.net [213.186.33.9] über maximal 30 Abschnitte:

1 <1 ms <1 ms <1 ms fritz.box [192.168.178.1]
2 57 ms 65 ms 48 ms 84.116.231.159
3 48 ms 47 ms 49 ms 84.116.229.185
4 48 ms 59 ms 48 ms at-vie-xion-pe02-vl-2054.upc.at [84.116.228.201]

5 47 ms 53 ms 59 ms at-vie15a-rd1-vl-2051.aorta.net [84.116.229.1]
6 51 ms 47 ms 49 ms 213.46.173.125
7 51 ms 61 ms 49 ms 213.46.176.118
8 53 ms 60 ms 60 ms prag-bb1-link.telia.net [213.155.133.66]
9 104 ms 183 ms 76 ms ffm-bb1-link.telia.net [213.155.130.202]
10 67 ms 66 ms 80 ms ffm-b10-link.telia.net [80.91.247.185]
11 * * * Zeitüberschreitung der Anforderung.
12 * * * Zeitüberschreitung der Anforderung.
13 * * * Zeitüberschreitung der Anforderung.
14 * * * Zeitüberschreitung der Anforderung.
15 * * * Zeitüberschreitung der Anforderung.
16 * * * Zeitüberschreitung der Anforderung.


tracerout kann ich von meinen noch im besitz befindlichen ovhserver machen

Routenverfolgung zu ks3094123.kimsufi.com [91.121.202.136] über maximal 30 Absch
nitte:

1 <1 ms <1 ms <1 ms fritz.box [192.168.178.1]
2 45 ms 46 ms 62 ms 84.116.231.159
3 58 ms 47 ms 47 ms 84.116.229.189
4 49 ms 48 ms 56 ms at-vie-xion-pe01-vl-2055.upc.at [84.116.229.9]
5 63 ms 61 ms 65 ms at-vie01a-rd1-vl-2050.aorta.net [84.116.228.193]

6 61 ms 47 ms 66 ms at-vie05b-ri2-xe-3-2-0.aorta.net [213.46.173.117
]
7 57 ms 51 ms 109 ms 213.46.176.118
8 88 ms 59 ms 61 ms win-bb2-link.telia.net [80.91.247.0]
9 72 ms 74 ms 78 ms ffm-bb2-link.telia.net [213.155.131.212]
10 64 ms 74 ms 57 ms ffm-b10-link.telia.net [80.91.247.189]
11 66 ms * * fra-5-6k.fr.eu [213.186.32.225]
12 73 ms 86 ms 81 ms rbx-g2-a9.fr.eu [91.121.131.130]
13 135 ms 82 ms 87 ms rbx-1-6k.fr.eu [91.121.131.13]
14 76 ms 75 ms 68 ms rbx-24-m1.fr.eu [213.251.191.67]
15 81 ms 84 ms 70 ms ks3094123.kimsufi.com [91.121.202.136]






als gegentest nehme ich speedtest.qsc.de

und habe 1.2mbit (auch hier screen möglich)

Routenverfolgung zu speedtest.qsc.de [195.90.7.115] über maximal 30 Abschnitte:

1 <1 ms 1 ms <1 ms fritz.box [192.168.178.1]
2 53 ms 47 ms 66 ms 84.116.231.159
3 60 ms 61 ms 63 ms 84.116.229.193
4 61 ms 48 ms 58 ms at-vie-xion-pe02-vl-2058.upc.at [84.116.228.209]

5 59 ms 64 ms 56 ms at-vie15a-rd1-vl-2051.aorta.net [84.116.229.1]
6 47 ms 84 ms 47 ms 213.46.173.125
7 62 ms 115 ms 50 ms 213.46.176.118
8 65 ms 67 ms 65 ms prag-bb1-link.telia.net [213.155.133.66]
9 65 ms 58 ms 64 ms ffm-bb1-link.telia.net [213.155.131.216]
10 70 ms 87 ms 83 ms ddf-b2-link.telia.net [213.155.135.93]
11 82 ms 83 ms 70 ms core1.dus.qsc.de [213.248.73.2]
12 86 ms 71 ms 70 ms core5.dus.qsc.de [213.148.134.110]
13 73 ms 84 ms 79 ms ssgate-ext.dus.qsc.de [87.234.8.210]
14 75 ms 74 ms 88 ms speedtest.qsc.de [195.90.7.115]


test proof.ovh

Last Result:
Download Speed: 2156 kbps (269.5 KB/sec transfer rate)
Upload Speed: 417 kbps (52.1 KB/sec transfer rate)
Latency: 506 ms
Montag, 19. November 2012 16:58:09



meine homeleitung ist

Empfangsrichtung Senderichtung
DSLAM-Datenrate Max. kbit/s 20000 1024
DSLAM-Datenrate Min. kbit/s 32 32
Leitungskapazität kbit/s 22820 859
Aktuelle Datenrate kbit/s 19994 826

zakazak
19.11.12, 16:53
besser?

130 kbit/s download von meinem ovh server.. das ist ein neuer mindestrekord ! Beim proof.ovh komm ich wenigstens auf 200kbit/s dafür ping 118ms und bei meinem server ping 33ms.

2 84.116.231.159 (84.116.231.159) 14.490 ms 7.776 ms 7.769 ms
3 84.116.229.193 (84.116.229.193) 20.139 ms 71.212 ms 10.067 ms
4 at-vie-xion-pe01-vl-2057.upc.at (84.116.229.13) 9.981 ms 9.021 ms 9.514 ms
5 at-vie01a-rd1-vl-2050.aorta.net (84.116.228.193) 9.160 ms 41.298 ms 9.188 ms
6 at-vie05b-ri2-xe-3-2-0.aorta.net (213.46.173.117) 8.837 ms 8.969 ms 7.813 ms
7 213.46.176.118 (213.46.176.118) 9.285 ms 11.764 ms 14.664 ms
8 win-bb2-link.telia.net (80.91.247.0) 14.539 ms 15.426 ms 14.963 ms
9 ffm-bb2-link.telia.net (213.155.133.54) 21.520 ms
ffm-bb2-link.telia.net (213.155.131.108) 21.356 ms
ffm-bb2-link.telia.net (213.155.133.54) 59.832 ms
10 ffm-b10-link.telia.net (80.91.251.124) 27.770 ms
ffm-b10-link.telia.net (80.91.251.250) 21.638 ms
ffm-b10-link.telia.net (80.91.247.189) 22.082 ms
11 fra-5-6k.fr.eu (213.186.32.225) 22.650 ms * *
12 rbx-g2-a9.fr.eu (178.33.100.250) 30.532 ms 30.536 ms 29.656 ms
13 * vss-2-6k.fr.eu (91.121.131.89) 29.916 ms 96.205 ms
14 serv8.foserv.fr (91.121.54.14) 29.195 ms 29.375 ms 29.876 ms
@edit: Okay bei proof.ovh schaffe ich inzwischen 5.35mbit/s. Das ist von meinen möglichen 20mbit/s noch weit entfernt aber schonmal ein anfang. Bei meinem server ist bei ~140kbit/s trotzdem schluss.

Felix
19.11.12, 15:28
Ist es jetzt wieder besser?
Wenn nein, könnt ihr nochmal ein aktuelles traceroute posten?

Felix

Darky68
19.11.12, 13:31
Zitat Zitat von FrankP
Hallo Darky68,

die Bearbeiterin, die sich um deinen Fall gekümmert hat, ist leider ein paar Tage ausgefallen. Die Übernahme Ihrer Fälle hat nicht richtig funktioniert - dafür entschuldige ich mich.

Ich hake gerne nochmal nach, wie der Stand der Dinge mit UPC ist. Versprechen kann ich da natürlich nichts - diese Probleme sind schon beim NOC bekannt.
Wer daran "Schuld" ist kann ich natürlich auch nicht sagen. ich gehe nicht davon aus, dass es an OVH liegt.

Geschwindigkeitsprobleme mit Anbieter Telekom sind mir momentan nicht bekannt.

Gruß
FrankP
OVH Team
Danke für die Anwort, das erklärt zumindest das supportproblem


schade ich werd mir evtl andern rootanbieter suchen müssen und

ICH HOFFE ES LIEST EIN UPC MITARBEITER - ich werde definitiv nächstes jahr UPC/INODE verlassen und zu telekom wechseln


ps ironienote am rande - man flüchtet von chello/upc vor 10jahren im jahr 2002 weils immer wieder probleme mit stabiler verbindung gab bzw geschwindigkeitsprobleme schon damals und wechselt zu inode einem privaten anbieter und ahtte aufeinmal VOLLE LEISTUNG

2006 kauft upc inode und was ist seit gut 3jahrne für probleme - die gleichen wie 2002 instablies internet geschwindigkeitseinbussen


auch ich gehe schon langsam davon aus und wenn das so ist, ist ovh schuldlos

das UPC hier massive eingriffe durchführt um wenig traffic zu haben oder von anderen firmen für traffic soviel kohle verlangen das die sich das nicht leisten können ..keine ahnung was stimmt - irgendwas davon wird stimmen


schade ovh wäre gern bei euch geblieben und hätte sogar noch stärken server gemietet - aber unter diesen umständen ist das rausgeschmissenes geld

UPCUser
19.11.12, 11:40
@ OVH Team

Könntet ihr nicht mal den Link hierher einem zuständigen Mitarbeiter bei UPC senden? Wie man an den klicks sieht sind ja sehr viele Leute an dem Thread interessiert.

Mich würde interessieren warum wieder umgestellt wurde nachdem es ja schon funktioniert hat. Ein Normalsterblicher User kann bei UPC sicher nichts ausrichten, aber OVH ist ja kein normaler User.

Hier beschweren sich mittlerweile massiv Leute, aber es geschieht nichts.

FrankP
19.11.12, 10:19
Hallo Darky68,

die Bearbeiterin, die sich um deinen Fall gekümmert hat, ist leider ein paar Tage ausgefallen. Die Übernahme Ihrer Fälle hat nicht richtig funktioniert - dafür entschuldige ich mich.

Ich hake gerne nochmal nach, wie der Stand der Dinge mit UPC ist. Versprechen kann ich da natürlich nichts - diese Probleme sind schon beim NOC bekannt.
Wer daran "Schuld" ist kann ich natürlich auch nicht sagen. ich gehe nicht davon aus, dass es an OVH liegt.

Geschwindigkeitsprobleme mit Anbieter Telekom sind mir momentan nicht bekannt.

Gruß
FrankP
OVH Team

Darky68
19.11.12, 10:01
sehr geehrte damen und herren,

wie eben mit einem sehr netten freundlichen herren von ihnen gesprochen, teile ich ihnen mit das ich den gemieteten server nicht weiter mieten werde


dafür gibt es 2 sehr extrem unterschiedliche trifftige gründe


1. wenn ich mich mit ftp auf den server verbinde bekomme ich umd ie 200kb/s zusammen obwohl ich 1.9mbit schaffen könnte.

dies wurde auch mit ihrem ftp.ovh.net server getestet hier das gleiche problem . fazit liegt es entweder am routing von ovh zu mir oder an dem grund das ich bei dem provider inode (tochter von upc) bin und es hier probleme zw ovh und upc gibt.

gehe ich zb auf einen anderen test server speedtest.qsc.de erhalte ich sofort um die 1800-1900kb/s - also ist meine homeleitung vollkommen für mich inordnung udn das problem tritt nur mit servern der firma OVH auf. auch dies wurde getestet mit freunden aus deutschland die bei ihnen einen server haben und auch dort habe ich die gleichen geschwindigkeitsprobleme

fazit liegt der grund für mich als laie an ovh und oder upc


2. das hinhalten des support ist eine frechheit. ein ticket mit dem problem am 3.11 eröffnet bis 9.11 mit blablabla hingehalten alles getestet was gefordert , dann verlangt in rescue mode zugehen udn auf die frage meiner seits an welchen tag(weil kann ja ned ewig den server in rescue lassen) bekam ich vom 9.11 bis heute 19.11 - 10 TAGE LANG KEINE ANTWORT !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

mfg
sr58367-ovh



PS mich würd schon interessieren wer jetzt wo die schuld trägt upc/inode oder ovh mit dem routing nach österreich zu dne upc/inode kunden

ka bin laie

jetzt stellt sich noch eine frage für mich - wenn ich provider wechsel zb zu telekom hab ich da die gleichen probleme?????

strex
18.11.12, 21:31
Natürlich betrifft das mich aus, weil ich unzählige User in ganz Europa mit meinem Server darüber bediene. Das ist nicht gerade wenig, bei einige PB Gesamtvolumen pro Jahr. Nur was bringt das Jammern, dass was gesagt werden musste wurde alles gesagt. Weiteres Jammern bringt es nicht weiter, eine Statistik hin oder her.

Wer wirkliches Interesse daran hat, wendet sich an oles@ovh.net. Für wen die Anbindung geschäftskritisch ist, muss eben die Konsequenzen ziehen und wechseln bzw. Alternativen für diese User anbieten.

Zitat Zitat von UPCUser
Die Frage ist doch --> zuerst ging es nicht, dann hat es für ca. 1 Woche hingehauen mit Downloadgeschwindigkeiten bis 12 MB/s und jetzt geht es wieder nicht...
TATA Traffic ist einfach zu teuer für UPC. Wenn die Provider sich querstellen, soll es nicht ander´s sein. Wenn UPC ein Angebot geben täte, dass normal auf dem Markt ist würde OVH sicher nicht nein sagen. Aber für solchen Traffic solche Preis zu verlangen und doppelt zu kassieren geht nicht.

UPCUser
18.11.12, 20:56
Die Frage ist doch --> zuerst ging es nicht, dann hat es für ca. 1 Woche hingehauen mit Downloadgeschwindigkeiten bis 12 MB/s und jetzt geht es wieder nicht... Also ist denen das Problem durchaus bekannt... Nur eine Stellungnahme bleibt aus :/ Dann sollen sie gleich sagen "Wir wollen nicht" ... UPC und OVH ist dieser Thread sicher bekannt....

Caddy
18.11.12, 20:47
Da komme ich ja gerade richtig. Wie ich sehe, wird der Ton schon schärfer hier.
Ich sehe auch, dass das Thema wohl nicht gerade uninteressant ist, denn es wurde innerhalb kurzer Zeit bereits fast 5000 Mal gelesen.

Die aktuellen Werte sind derzeit ca. 1 Mbit/s von OVH nach UPC (eben noch testen lassen), Routen stehen massenhaft zur Verfügung, der definierte Zeitpunkt, wann das wieder so drastisch schlecht wurde ist, als das Routing von TATA wieder auf upc.as6830.at.eu geroutet wurde.

Dazu kommt - wie ich auch bereits schon schrieb - eine gehörige Portion Packet Loss.

Es wurde bereits von Felix (OVH) gesagt, dass dran gearbeitet wird, es wäre dann jetzt auch mal an der Zeit, mal einen Zwischenstand zu erfahren, ich denke, das ist bei den Werten wirklich angebracht.

Gruß, Klaus

panda
18.11.12, 18:51
Zitat Zitat von strex
...
Wie gesagt, dass Jammer bringt nichts. Hatten wir mit der Telekom hier in .de auch in den 2010. Das hat dann rund ein Jahr gedauert und die Uplinks wurden dann trotzdem bezahlt. Der Kundenmarkt ist für OVH wohl zu klein, um viel zu überteuerte UPC Leitungen zu buchen.
Eine Rechtfertigung, "früher war die Anbindung woanders schlecht" ist ein Witz. Wenn Dich das "Gejammere" stört, dann behalte es doch einfach für Dich, es geht darum ein Problem, welches Dich scheinbar nicht betrifft, aufzuzeigen. Mit meinem Beitrag wollte ich auf objektive Weise mit aktuellen Marktanteilen die Bedeutung dieses Providers verdeutlichen.

strex
18.11.12, 11:51
Du hast keinerlei Garantien auf bestimmte Bandbreite zu bestimmten Zielen. Dir wird ja nicht mal vollständig die Bandbreite des Servers garantiert.

Wenn du was garantiert haben möchtest, dann musst du entsprechend mehr ausgeben. Gibt das dein Projekt nicht her, sollte es eigengestellt werden.

Wie gesagt, dass Jammer bringt nichts. Hatten wir mit der Telekom hier in .de auch in den 2010. Das hat dann rund ein Jahr gedauert und die Uplinks wurden dann trotzdem bezahlt. Der Kundenmarkt ist für OVH wohl zu klein, um viel zu überteuerte UPC Leitungen zu buchen.

panda
18.11.12, 04:16
Kann leider das Problem nur bestätigen. Es ist echt frustrierend, ich wählte einen Server-Provider mit begrenztem Inklusiv-Traffic und klar definierter Server-Anbindung. Und dann wird doch wieder irgendwo gedrosselt.

Warum ist mir eigentlich egal. CH ist ein relevanter Markt für meine Einnahmen und letztendlich Finanzierung der Server und UPC/Cablecom macht als grösster Kabelanbieter knapp 30% dieses Marktes aus (http://www.comcom.admin.ch/dokumenta...x.html?lang=de).

Drosselung bei Excessive use ist ok, aber nicht für eine bezahlte Dienstleistung und da sehe ich ovh in der Pflicht, sei es in Form von mehr Investitionen in die Peering Anbindung oder in Form des bitteren Apfels Transit.

zakazak
17.11.12, 11:17
wird es hierfür noch einmal ein update geben oder wars das mit ovh als upc kunde ?

Katzi
10.11.12, 16:13
Super ! sehe gerade 0 % Auslastung auf der Weathermap, demnach dürfte die Geschwindigkeit noch über der 100mbit marke liegen

Leider halt nur im Traum, die Geschw. ist nach wie vor lahm.

Im Vergleich dazu hat OVH mit LiWest keine Probleme, 1.000 kb mit 1er Verbindung, da können UPC Kunden (derzeit) nur davon träumen.

tester
09.11.12, 22:56
wenn manche schreiben das sie gerade mit ein paar hundert kb/s sich herumschlagen müssen, dacht ich mir ich bring das mit meiner 16er mal an...
Danke für die Steinigung...

strex
08.11.12, 20:42
Kein teurer Telia Traffic an UPC Kunden, richtig so! Mit der Telekom ham sie sich ja auch geeinigt, wenn UPC nicht will, dann nicht

UPCUser
08.11.12, 19:17
Ich habe UPC 100 Mbit und erreiche Rund um die Uhr damit MINDESTENS 90 MBIT.... Ich denke nicht das man das mit ner 16.000er von A1 vergleichen kann, von dem mal abgesehen wenn du nur 400 Meter vom Wählamt wech bist dann drosseln sie dich schon auf ne 8000er weil ja mehr angeblich nicht geht.... Ich habe nen Root und will den auch mit anständigem Speed nutzen können, und warum sollte ich wechseln?? Vor ein zwei Wochen ging es doch, nur wurde mal wieder was umgestellt....

Hook
08.11.12, 17:49
Zitat Zitat von tester
ich hab dort gigaspeed 16 und komm auch auf die 16mbit zu jeder Tageszeit
Aber das ist ja viel viel weniger als die 50MBit Ich will doch mehr als meine Kollegen haben (auch wenn ich den Speed eh nicht immer krieg) aber auf die Zahl/Größe die da steht kommts doch an, oder?

tester
08.11.12, 17:01
wie wärs eigentlich wenn ihr zu nem anderen inet anbieter wechselts ? a1 z.b. ?
ich hab dort gigaspeed 16 und komm auch auf die 16mbit zu jeder Tageszeit

zakazak
08.11.12, 12:50
da bin ich ja mit meinen 3mbit/s download welche ich erreiche ja noch richtig schnell dran im vergleich zu andere !

Caddy
07.11.12, 17:16
Zitat Zitat von strex
... Seiten wie youtube oder google lahm werden, dann geht´s fix. Das ist aber noch nicht erreicht, wird aber kommen.
Das war schon: http://futurezone.at/digitallife/101...it-youtube.php

strex
07.11.12, 09:49
Zitat Zitat von Katzi
..
Wenn bei 70-80% aller Österreichischen / Schweitzer Kunden das "lahm" bleibt muss man sich eben von OVH trennen und den Server woanders mieten.
...
Mit dieser Lösung unterstützt du nur die UPC mit ihrem Verhalten. Ist wie bei der DTAG, die wollen einfach doppelt kassieren. Deshalb irgendwann wir der Punkt erreicht sein, wo die Provider nicht mehr zahlen wollen und Seiten wie youtube oder google lahm werden, dann geht´s fix. Das ist aber noch nicht erreicht, wird aber kommen.

Ob sich die Kosten für die paar Kunden die von UPC angebunden sind rentiert, ich weiß es nicht, scheinbar ist das OVH zu teuer und es muss sich dann also nicht rentieren. Dann ändert sich auch nichts. Dann solltest du ein Wechsel in Betracht ziehen, weil das wäre für beide Partner die beste Lösung.

Katzi
07.11.12, 08:53
Zitat Zitat von strex
Der Telia Traffic ist einfach zu teuer um den an UPC zu verschenken. Wenn die kein Upgrade wollen oder nur gegen Geld, bleibt´s halt lahm für UPC Kunden..
Das Problem an der sache ist.,d as die UPC in Österreich quasi Monopolöstellung hat.

Was wiederum bedeutet das man kaum eine Wahl hat welchen ISP man sich nimmt.

Wenn bei 70-80% aller Österreichischen / Schweitzer Kunden das "lahm" bleibt muss man sich eben von OVH trennen und den Server woanders mieten.

Es ist ja eine Zumutung bei einer 100mbit leitung nur 75 kb/s zu bekommen.

Wäre mal nicht schlecht wenn sich jemand von den OVH Mitarbeitern zu dem Thema äußern würde.

bene
06.11.12, 18:18
Spass macht es nicht:
http://i.imm.io/KFF0.png

strex
06.11.12, 17:15
Der Telia Traffic ist einfach zu teuer um den an UPC zu verschenken. Wenn die kein Upgrade wollen oder nur gegen Geld, bleibt´s halt lahm für UPC Kunden..

failbob
06.11.12, 16:53
Also wenn man sich das mal anguckt und die Posts zurückverfolgt, ab wann die Probleme aufhörten und wieder anfingen, kann man hier eindeutig darauf schließen, dass da irgendwo rumgefummelt wurde

http://p19.smokeping.ovh.net/ovh-ser...1348956000.png

Caddy
05.11.12, 23:01
Hi,

auch noch ein paar Infos:
vom Server (Roubaix 1):
Code:
Host                                      Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. rbx-6-m1.fr.eu                          0.0%   214    0.4   0.6   0.4   5.4   0.4
 2. rbx-1-6k.fr.eu                          8.4%   214   61.3   8.2   0.2 235.0  33.0
 3. rbx-g2-a9.fr.eu                         0.0%   214    0.8  11.9   0.6 293.0  48.9
 4. fra-5-6k.fr.eu                         29.6%   213    8.2  18.0   7.9 301.8  32.4
    fra-5-6k.fr.eu
    fra-5-6k.fr.eu
    fra-5-6k.fr.eu
    fra-5-6k.fr.eu
    fra-5-6k.fr.eu
    fra-5-6k.fr.eu
 5. pra-1-6k.cz.eu                          7.5%   213   16.1  25.6  15.9 217.6  32.8
 6. vie-1-6k.at.eu                          3.8%   213   20.6  26.5  20.5 244.9  29.2
 7. upc.as6830.at.eu                        6.1%   213   42.8  27.3  26.3  72.0   4.5
 8. at-vie01a-rd1-xe-1-0-0.aorta.net        4.7%   213   21.9  27.9  21.4  86.7  11.1
 9. at-vie-sk11-pe01-vl-2042.upc.at         4.7%   213   26.8  27.7  26.6  68.2   4.8
10. at-vie-sk11-pe02-vl-1.upc.at            5.2%   213   21.6  24.0  21.4  58.5   7.5
11. ???
12. chelloxxxxxxxxxxxx.20.11.vie.surfer.at  6.1%   213   43.3  34.2  27.9  93.9   8.5
Wobei ich mich echt wundere, was für ein IP-Adressen-Wunder der fra-5-6k ist :-)

Vom UPC Kunden (Wien):
Code:
|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                             192.168.1.1 -    0 |   23 |   23 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |    4 |    0 |    0 |    0 |    0 |    0 |
|                             84.116.4.49 -    0 |   23 |   23 |    7 |   14 |   41 |   10 |
|         at-vie15a-rd1-vl-2043.aorta.net -    0 |   23 |   23 |    8 |   15 |   40 |   15 |
|                          213.46.173.125 -    0 |   23 |   23 |    8 |   17 |   42 |   33 |
|                          213.46.176.118 -    0 |   23 |   23 |    8 |   14 |   51 |    8 |
|                  win-bb2-link.telia.net -    0 |   23 |   23 |   13 |   20 |   38 |   17 |
|                  ffm-bb2-link.telia.net -    0 |   23 |   23 |   24 |   29 |   46 |   26 |
|                  ffm-b10-link.telia.net -    0 |   23 |   23 |   22 |   30 |   61 |   27 |
|                          fra-5-6k.fr.eu -   28 |   11 |    8 |    0 |   40 |   69 |   26 |
|                         rbx-g2-a9.fr.eu -    6 |   19 |   18 |   29 |   37 |   51 |   32 |
|                          rbx-2-6k.fr.eu -   14 |   15 |   13 |   30 |   34 |   51 |   33 |
|                          rbx-6-m1.fr.eu -    6 |   18 |   17 |   28 |   34 |   49 |   34 |
|                              xxxxxxx.tv -    6 |   19 |   18 |   28 |   34 |   52 |   32 |
|________________________________________________|______|______|______|______|______|______|
OVH Speedtest von dort:
http://s1.directupload.net/images/121105/crlv35gr.jpg

Der Packet Loss ist tatsächlich in beide Richtungen verdächtig identisch.
Zumindest lässt sich sehr genau sagen, wann der Loss angefangen hat, denn nach den Anfängen mit langsamen Verbindungen läuft auf einer meiner nicht ausgelasteten Kisten in Roubaix 1 Smokeping, der folgendes zeigt:

http://s7.directupload.net/images/121105/orxnktbl.png

Das deckt sich dann wohl mit den Aussagen, dass es so ca. zwischen dem 31.10. und 1.11. irgendwie langsamer geworden ist ....

Das sind mit den anderen zusammen aber jetzt reichlich Infos

Gruß, Klaus

Hook
05.11.12, 20:38
Eigentlich sieht man doch klar wo das Problem liegt.

Der Traffic geht jetzt wieder von OVH übers direkte Peering mit UPC in Wien, und das ist einfach überlastet. Das war schon der Fall, dann ging zeitweise alles nen anderen Weg (über telia glaube ich) wo es funktioniert hat, und jetzt läufts wieder über das private Peering mit UPC.

Normalerweise bin ich kein Mensch der sich öffentlich leicht aufregt, aber ich verstehe nicht warum man da jetzt überhautp noch traceroutes braucht, wenn das Problem sogar schon für mich ersichtlich ist?! Ihr solltet das doch als erstes sehen oder wissen wenn irgendwas an eurem Routing geändert wurde?!

Sorry wenn ich mich jetzt hier aufrege, aber ich bin davon ausgegangen dass das Problem mit UPC vom Tisch ist ....

sting
05.11.12, 19:45
Hier aus Wien, über UPC:

Von UPC zu OVH:
Code:
 3     9 ms     9 ms     8 ms  84.116.6.129 
 4    11 ms    27 ms     9 ms  at-vie01a-rd1-vl-2018.aorta.net [84.116.228.29] 
 
 5    10 ms     9 ms    10 ms  at-vie05b-ri2-xe-3-2-0.aorta.net [213.46.173.11 
 
 6    30 ms    20 ms    10 ms  213.46.176.118 
 7    36 ms    15 ms    15 ms  win-bb2-link.telia.net [213.155.133.76] 
 8    63 ms    57 ms    22 ms  ffm-bb2-link.telia.net [213.155.133.54] 
 9    36 ms    44 ms    25 ms  ffm-b10-link.telia.net [213.155.134.137] 
10     *       21 ms     *     fra-5-6k.fr.eu [213.186.32.225] 
11    31 ms    30 ms    50 ms  rbx-g2-a9.fr.eu [91.121.131.130] 
12    87 ms    66 ms    31 ms  rbx-s2-6k.fr.eu [178.33.100.94]
Von OVH zu UPC:
Code:
traceroute to 84.116.6.129 (84.116.6.129), 30 hops max, 60 byte packets
 1  * * *
 2  rbx-g2-a9.fr.eu (178.33.100.89)  0.787 ms  2.311 ms  2.315 ms
 3  fra-5-6k.fr.eu (178.33.100.245)  8.132 ms fra-5-6k.fr.eu (178.33.100.251)  8.095 ms *
 4  * * *
 5  * * *
 6  upc.as6830.at.eu (91.121.131.66)  26.473 ms  26.549 ms  26.516 ms
 7  at-vie01a-ra3-ge-0-1-0.aorta.net (213.46.173.118)  46.574 ms  41.006 ms  27.504 ms
 8  84.116.228.30 (84.116.228.30)  42.010 ms * *
Speedtest proof.ovh.net:
http://www0.xup.in/exec/ximg.php?fid=21143004

Speedtest.net zu einem Server in Linz:
http://www.speedtest.net/result/2288087494.png

bene
05.11.12, 18:15
Hallo,

hier mal ein Ergebnis wie es zu mir in die Schweiz aussieht:
http://i.imm.io/KymC.jpeg

Traceroute zum Server:
Code:
Routenverfolgung zu ks3262608.kimsufi.com [5.39.77.139] über maximal 30 Abschnitte:

  1     8 ms     7 ms     8 ms  84-74-12-1.dclient.hispeed.ch [84.74.12.1]
  2     9 ms     8 ms     7 ms  217-168-55-173.static.cablecom.ch [217.168.55.173]
  3     9 ms    10 ms    12 ms  62.2.4.177
  4     *        *       10 ms  nl-ams05a-rd2-xe-4-1-1.aorta.net [84.116.134.22]
  5    10 ms    11 ms    12 ms  213.46.171.66
  6    21 ms    25 ms    22 ms  ffm-bb1-link.telia.net [213.155.133.214]
  7    22 ms    20 ms    20 ms  ffm-b10-link.telia.net [80.91.247.185]
  8    64 ms    45 ms     *     fra-5-6k.fr.eu [213.186.32.225]
  9    45 ms    30 ms    35 ms  rbx-g2-a9.fr.eu [91.121.131.134]
 10    36 ms     *       29 ms  vss-9b-6k.fr.eu [178.33.100.74]
 11    29 ms    27 ms    29 ms  ks3262608.kimsufi.com [5.39.77.139]

Ablaufverfolgung beendet.
Und vom Server zu mir:
Code:
traceroute to 84-74-12-28.dclient.hispeed.ch (84.74.12.28), 30 hops max, 60 byte packets
 1  * * *
 2  rbx-g2-a9.fr.eu (91.121.131.157)  2.354 ms  2.346 ms  2.326 ms
 3  fra-5-6k.fr.eu (178.33.100.251)  8.041 ms * *
 4  zur-1-6k.ch.eu (94.23.122.146)  15.299 ms * *
 5  upc.as6830.ch.eu (94.23.122.166)  17.349 ms  17.334 ms  17.312 ms
 6  ch-zrh02a-ra1-xe-3-2-0.aorta.net (84.116.134.21)  17.676 ms  17.852 ms  17.817 ms
 7  62.2.4.178 (62.2.4.178)  17.794 ms 62.2.4.182 (62.2.4.182)  18.088 ms 62.2.4.178 (62.2.4.178)  17.941 ms
 8  * * *
 9  * * *
Früher ging es über Level(3) mit Fullspeed...

[EDIT]: Zum Vergleich, dass ich meine Leitung ausschliessen kann:
http://www.speedtest.net/result/2287958373.png

strex
05.11.12, 16:14
Zitat Zitat von UPCUser
Wieso sollte ich den Root Anbieter wechseln...
Wenn dir die Gegebenheiten nicht passen, ist ein Umzug die beste Wahl. Da dein Fordern nichts bringt bleibt dir nichts anders übrig, vielleicht wollen ja beide oder einer von beiden nicht die Kapazität erhöhen. Eine Garantie das es super laufen muss gewährt dir aus guten Gründen keiner, also hast du kein Anrecht. Dann kannst du so viel Fordern wie du willst, bringen tut es nichts. Es hilft hier dann nur noch ein Wechsel. Klar? Sollte doch nicht schwer sein.

Zitat Zitat von UPCUser
Was heisst zum Zeitpunkt wenn das Problem auftritt, das Problem besteht die ganze Zeit... Schau dir mal die Weathermap an.. sagt eh schon alles.
Dir ist aber schon bekannt, dass sich das Routing öfters verändern kann und das Frames nicht denselben Hin- und Rückweg nehmen können. Da die Uplinkkapazität nicht von heute auf morgen zunimmt und dann Tage wieder später abnimmt, hat sich etwas am Routing geändert.

Wenn du eventuell eine Behebung willst, dann poste die geforderten Daten oder lebe mit dem Speed.

UPCUser
05.11.12, 16:00
Was heisst zum Zeitpunkt wenn das Problem auftritt, das Problem besteht die ganze Zeit... Schau dir mal die Weathermap an.. sagt eh schon alles.

Felix
05.11.12, 13:44
zakazak wrote:
> Und das wars dann wieder.
>
> Seit gestern sind nicht mehr wie 2 mbit/s drinnen...


Die übliche Rückfrage - Könnt ihr zum Zeitpunkt wenn das Problem auftritt
traceroutes machen und diese posten? Idealerweise in beide Richtungen, also
einmal UPC => OVH und einmal OVH => UPC.

UPCUser
04.11.12, 16:33
Wieso sollte ich den Root Anbieter wechseln ? Nur weil UPC oder OVH das nicht gebacken bekommt?? Das ist doch nicht mein Problem... und das es funktionieren kann hat man ja gesehen, da es ja vor ein Paar Tagen noch funktioniert hat... Nur haben die ja anscheinend wieder was umgestellt... und das obwohl alles ging..

BITTE OVH setzt euch doch mal mit UPC in Verbindung...

Katzi
04.11.12, 08:15
selbst um 4 Uhr am Morgen ist die Auslastung noch immer kanpp bei 50 %
O.k. Speed ist besser dann , aber je später der Tag wird, desto höher wird die Auslastung.
Zur Zeit (8:12) ist sie schon bei 63%.

Ab 12 Uhr Mittag ist dann sowieso schluss , dann geht nichts mehr (90%).

Noch vor 6 Tagen war Abends so gegen 18:00 die Auslastung sogar noch unter 30 %

UPC vertickt halt immer gerne fette leitungen, investiert aber nicht gerne in den Netzausbau.

Hook
03.11.12, 21:23
Es ist hier wohl UPC Austria gemeint, nach UPC Schweiz funktioniert auch alles

Hetzner und Hosteurope sind nach UPC Österreich übrigens schnell mit mehreren MB/sec. Ohne da jetzt irgendwie Schleichwerbung machen zu wollen, nur falls hier jemand Kunden aus Österreich hat die sich schon wieder anfangen zu beschweren ...

strex
03.11.12, 14:30
Wenn euch der Speed zu UPC wichtig ist, warum wählt ihr dann keinen Provider direkt in der Schweiz? Vielleicht einmal ein Server in SBG 1 testen, dort läuft der Traffic direkt von Straßburg nach Frankfurt und Zurich an UPC. Die Links sind nicht ausgelastet.

UPCUser
03.11.12, 13:42
Ich würde jetz gern mal wissen wer da jetzt wirklich Schuld ist, UPC schiebts auf OVH und umgekehrt.... Kann ja nicht angehn das ich mit ner 100mbit Leitung nicht meinen Server nutzen kannn hier.... OVH sollte sich mal mit UPC in verbindung setzen.... so gehts nicht!!

Hook
03.11.12, 13:30
Kann ich bestätigen.

Speed ist für UPC Kunden leider wirklich wieder grottig ... Jetzt kann ich die Server bei anderen Hostern wohl doch nicht durch OVH Server ersetzen ...

UPCUser
03.11.12, 12:01
Stimmt, ist mir auch schon aufgefallen und die Weathermap zeigt bis zu 90% Auslastung.... Wär auch zu schön gewesen.... Das kanns doch echt nicht mehr sein!!

zakazak
03.11.12, 11:56
Und das wars dann wieder.

Seit gestern sind nicht mehr wie 2 mbit/s drinnen...

UPCUser
08.10.12, 15:25
Hmm naja ist doch egal, die Hauptsache ist doch das es flutscht. Und wo lag dann der Fehler?

MFG

strex
07.10.12, 15:33
Zitat Zitat von UPCUser
Hab ich ja auch nicht behauptet, habe ja auch gesagt das die Routings gleich geblieben sind. Nur wie gesagt seit mehr Channels zur Verfügung stehen läuft es... Mir egal warum, Hauptsache es läuft und die basteln nicht wieder rum.
Die Channels in deinem Modem beeinfluss aber bei weitem nicht die Peering Kapazität zwischen den beiden. Das ist Bestens ein Zufall mehr nicht.

Hook
07.10.12, 14:28
Das Routing von dir zu OVH wurde nicht geändert. Die andere Richtung allerdings, also von OVH zu dir, wurde geändert

UPCUser
07.10.12, 13:42
Hab ich ja auch nicht behauptet, habe ja auch gesagt das die Routings gleich geblieben sind. Nur wie gesagt seit mehr Channels zur Verfügung stehen läuft es... Mir egal warum, Hauptsache es läuft und die basteln nicht wieder rum.

strex
07.10.12, 10:40
Modem Downstream Channels oder ähnliches hat aber nichts mit dem Routing zwischen OVH und UPC zu tun. Daran liegt es nicht.

UPCUser
06.10.12, 11:29
So hab mich jetzt hier extra mal registriert.

Bin auch UPC Kunde aus Wien und nach langer Zeit geht endlich mal der Download von OVH Servern flott. Erreiche bis zu 100 Mbit. Wenn man sich die Weathermap ansieht aus Wien sieht man das es die gleichen Routings sind aber die Kapazität anscheinend erhöht wurde.

Was mir aufgefallen ist, ist das in den Modem die Downstream Channels von 4 auf 8 erhöht wurden. Daduch sind meine Leitungswerte etwas schlechter geworden (vor allem beim letzten Channel) aber dafür flutscht jetzt auch der Download von OVH...

Ich hoffe mal das das so bleibt und UPC nicht wieder etwas umstellt, also der Fehler lag eindeutig bei UPC wenns jetzt mit den extra Channels besser flutscht.

Caddy
05.10.12, 20:35
Wow!

Gerade mal von UPC Wien aus testen lassen. Download einzelner TCP Stream: Bis zu 40 MBit/s, mit mehreren parallel geht's bis 100MBit (mein testender UPC Kunde hat nicht mehr downstream).

Die Routen sind übrigens geblieben. Irgendeiner hat wohl an irgendeiner Stelle die Kapazität erhöht :-)

Code:
|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                             192.168.1.1 -    0 |    7 |    7 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |    1 |    0 |    0 |    0 |    0 |    0 |
|                             84.116.4.49 -    0 |    7 |    7 |    6 |   18 |   51 |   51 |
|         at-vie15a-rd1-vl-2043.aorta.net -    0 |    7 |    7 |   11 |   17 |   38 |   11 |
|                          213.46.173.129 -    0 |    7 |    7 |   10 |   17 |   33 |   33 |
|                          213.46.176.118 -    0 |    7 |    7 |   10 |   13 |   18 |   12 |
|                  win-bb2-link.telia.net -    0 |    7 |    7 |   16 |   20 |   28 |   28 |
|                  ffm-bb2-link.telia.net -    0 |    7 |    7 |   23 |   43 |  125 |   23 |
|                  ffm-b10-link.telia.net -    0 |    7 |    7 |   24 |   26 |   29 |   28 |
|                          fra-5-6k.de.eu -   25 |    4 |    3 |    0 |   81 |  187 |   28 |
|                         rbx-g2-a9.fr.eu -    0 |    7 |    7 |   35 |   40 |   50 |   42 |
|                          rbx-2-6k.fr.eu -   25 |    4 |    3 |    0 |   33 |   37 |   32 |
|                          rbx-6-m1.fr.eu -    0 |    7 |    7 |   32 |   49 |  137 |   34 |
|                              xxxxxxx.tv -   25 |    4 |    3 |    0 |   35 |   38 |   33 |
|________________________________________________|______|______|______|______|______|______|
Gruß, Klaus

Edit sagt: Der 25% Packet Loss ist ein Winmtr Bug Es geht auch ohne.

kenshin
04.10.12, 03:25
eben mal nen ösi testen lassen, 6mb/s von nem Superplan ... kann man lassen.

welten besser als die 500k/s sonst.

bene
03.10.12, 20:43
Es läuft momentan über Tata und das wirklich wie geschmiert, hoffen wir, dass es so bleibt

Hook
03.10.12, 19:52
Sehr schön, es funktioniert zur Zeit wirklich schön schnell!

Sehe ich das richtig, dass ihr jetzt garnicht mehr euer privates Peering mit UPC benutzt? Ganz schön frech, aber scheint eine sehr gute Entscheidung gewesen zu sein!

zakazak
03.10.12, 17:47
kann ich bestätigen ! sehr nice

ping ist nun auch von ~38ms runter auf 30ms.

bene
03.10.12, 09:46
Ein Wunder ist geschehen?

http://i.imm.io/Gwl8.png

Hook
02.10.12, 20:49
Ist völlig egal, wer hier Schuld hat. Wenn sich alle auch bei UPC beschweren und nicht nur bei OVH, ist die Chance so oder so größer dass da mal irgendwas passiert.

bene
30.09.12, 19:57
@Hook: Warum sollen wir uns bei upc beschweren?
Das Problem liegt auf OVH Seite, ich habe andere Server die gehen über die gleichen Transit Links und haben keine Speedprobleme.
Einfach ist OVH zu geizig den "Premiumtraffic" von UPC zu zahlen...

Denn ich kann hier kein UPC Problem erkennen:

Code:
Routenverfolgung zu bene.us [176.31.109.151] über maximal 30 Abschnitte:

  1     6 ms     6 ms     6 ms  84-74-12-1.dclient.hispeed.ch [84.74.12.1]
  2     8 ms     9 ms     9 ms  217-168-55-173.static.cablecom.ch [217.168.55.173]
  3    10 ms    14 ms    14 ms  62.2.4.177
  4    17 ms    11 ms    11 ms  ch-zrh02a-ra1-xe-5-1-0.aorta.net [84.116.134.58]
  5     *       10 ms     9 ms  ch-zrh01b-ra1-ae-1.aorta.net [84.116.134.142]
  6    12 ms    10 ms    10 ms  4.68.127.49
  7    40 ms    11 ms    12 ms  ae-11-11.car2.Zurich1.Level3.net [4.69.133.234]
  8    16 ms    15 ms    15 ms  ae-7-7.ebr2.Frankfurt1.Level3.net [4.69.133.237]
  9    18 ms    24 ms    22 ms  ae-92-92.csw4.Frankfurt1.Level3.net [4.69.140.30]
 10     *        *       16 ms  ae-4-90.edge5.Frankfurt1.Level3.net [4.69.154.201]
 11    18 ms     *       16 ms  fra-5-6k.de.eu [91.121.131.5]
 12    57 ms    53 ms     *     rbx-g2-a9.fr.eu [91.121.131.134]
 13   321 ms     *      109 ms  vss-6a-6k.fr.eu [91.121.128.40]
 14   162 ms   101 ms   162 ms  srv.rollik.net [176.31.109.151]

Ablaufverfolgung beendet.
Sondern es schaut einfach nur so aus, als das OVH das Routing zu UPC nicht vernünftig gebacken bekommt...

Hook
30.09.12, 14:48
Bitte einfach mal alle bei UPC direkt beschweren, die davon betroffen sind. Und auch andere Leute animieren sich an die zu wenden.
Was anderes hilft in dem Fall glaub ich einfach nicht.

zakazak
23.09.12, 19:25
350kbit/s.. mehr gehen nicht. Zu keiner tageszeit..

Caddy
06.09.12, 22:54
Das hört sich gut an. Teilweise gehen anscheinend über (jetzt etwas andere) Telia Links zwischen Roubaix und Wien manchmal sogar bis zu 10 MBit/s :-)

Gut, dass ihr dran bleibt.

Gruß, Klaus

Felix
06.09.12, 11:08
zakazak wrote:
> Hey ich konnte heute schon 3 mbit/s erreichen.
>
> Das ganze ist irgendwie lächerlich. Vorallem wenn ich meinen server
> bloß für mich private nutze.


Wir sind mit UPC in Kontakt, und es ist auch Besserung in Aussicht... Wird
allerdings noch einige Wochen brauchen.

timmy
10.07.12, 23:10
peering bei upc in at
oder
network bei upc in at
mal probiert?
(Insbesondere wenn man dort Kunde ist)

Nibor
05.07.12, 17:04
Zitat Zitat von Hook
Beschwert euch bitte alle mal bei eurem Provider wenn ihr davon betroffen seid.
Ich hab die schon nen paar mal kontaktiert, bin da allerdings nicht Kunde und entsprechend wenig wird man vermutlich auch ernst genommen.
Aus meiner Erfahrung wirst du von dem Support eh nicht ernstgenommen/die können im Prinzip auch nichts tun außer es weiterzuleiten...

Hook
05.07.12, 13:07
Beschwert euch bitte alle mal bei eurem Provider wenn ihr davon betroffen seid.
Ich hab die schon nen paar mal kontaktiert, bin da allerdings nicht Kunde und entsprechend wenig wird man vermutlich auch ernst genommen.
Oder einfach mal kündigen, dann rufen die sowieso nochmal an, fragen nach dem Grund und versprechen einem das blaue vom Himmel wenn man die Kündigung zurückzieht. Oder ist das in Österreich anders?

Ich würd als OVH ja einfach hingehen und den ganzen Traffic einfach übers VIX routen, falls möglich und auf UPC sche**en .... So viel höher dürfte die Latenz dann auch nicht sein, oder?

zakazak
05.07.12, 11:07
Hey ich konnte heute schon 3 mbit/s erreichen.

Das ganze ist irgendwie lächerlich. Vorallem wenn ich meinen server bloß für mich private nutze.

Caddy
24.06.12, 22:23
Anscheinend nicht, ausser die Häufung von Fragen von UPC Usern, wieso unser Server so schlecht zu erreichen ist.

Bei ca. 2 MBit/s download (vom Server zum UPC Kunden) und zeitweise bis 6% Packet Loss ist das jetzt nicht gerade befriedigend :-(

Gruß, Klaus

Hook
22.06.12, 20:02
Anscheinend gibts immernoch keine Neuigkeiten?

Caddy
07.06.12, 19:36
Ich glaube, so einfach ist das nicht Ich habe im Moment auch das Gefühl, dass das Problem tatsächlich bei UPC liegt, ich habe gottseidank sehr guten Kontakt zu einem UPC Kunden (daher ist auch das tracert), wir haben auch mal von drei.at (UMTS) getraced, das Routing geht ganz brav über VIX und steigt in Wien ins OVH Netz ein.

Dazu müsste aber vielleicht noch mal jemand von OVH was sagen, wenn kar ist, was da überhaupt passiert

Im Moment ist der Durchsatz von UPC Kunden denkbar schlecht. Ich frage mich auch, wie die beiden UPC Links so ausgelastet sind, wenn wir es von UPC aus nicht schaffen, über diesen vorgesehenen Weg zu gehen :-)

Gruß, Klaus

Hook
07.06.12, 15:12
Zitat Zitat von Caddy
Zwischen UPC und OVH läuft aber generell derzeit etwas schief:
[ ... ]
Ich denke, UPC sollte doch eigentlich direkt auch von client zum OVH Netz über euer Peering direkt in Wien gehen, oder sehe ich das falsch?
Diese Informationen haben sowohl OVH als auch UPC von mir bereits mehrmals bekommen. Bisher ist aus User-Sicht allerdings rein garnichts passiert.

Ich denke die österreichischen UPC Kunden sollten einfach mal ihren Provider nerven, irgendwann müssen die ihr Peering mit OVH ja mal upgraden. OVH hat ja soweit ich das sehe eine sehr gute Peering-Policy. Allerdings habe ich das Gefühl, dass Störungsmeldungen oder Beschwerden bei UPC in Ablage P verschwinden ... Auf Emails wird nicht reagiert und ein Anruf bringt nur die Antwort "wir werdens weiterleiten" ...

Könnte man nicht als Load-Balancing zu UPC-Kunden noch einfach das VIX-Peering hinzuschalten? Da ist laut der weathermap zumindest noch genug Luft.

Caddy
07.06.12, 00:58
Zwischen UPC und OVH läuft aber generell derzeit etwas schief:

traceroute von einem UPC user zu unserem OVH Server:

Code:
Routenverfolgung zu x [87.98.216.x] über maximal 30 Abschnitte:

  1     *        *        *     Zeitüberschreitung der Anforderung.
  2     *        *        *     Zeitüberschreitung der Anforderung.
  3    18 ms    17 ms    13 ms  84.116.4.33
  4    12 ms    16 ms    19 ms  at-vie15a-rd1-vl-2043.aorta.net [84.116.228.129]

  5    20 ms     9 ms    12 ms  213.46.173.125
  6    22 ms    14 ms    19 ms  213.46.176.118
  7    23 ms    25 ms    18 ms  win-bb2-link.telia.net [213.155.133.78]
  8    31 ms    31 ms    28 ms  ffm-bb2-link.telia.net [80.91.246.142]
  9    83 ms    41 ms    37 ms  prs-bb2-link.telia.net [213.155.132.154]
 10    39 ms    42 ms    87 ms  prs-b4-link.telia.net [80.91.251.114]
 11     *       34 ms     *     gsw-1-6k.fr.eu [213.251.130.81]
 12    42 ms    39 ms    41 ms  th2-g1-a9.fr.eu [91.121.215.134]
 13    37 ms    37 ms    34 ms  rbx-g1-a9.fr.eu [91.121.215.133]
 14    44 ms     *       77 ms  rbx-2-6k.fr.eu [213.186.32.234]
 15    43 ms    42 ms    38 ms  rbx-6-m1.fr.eu [213.251.191.141]
 16    41 ms    36 ms    36 ms  x [87.98.216.x]

Ablaufverfolgung beendet.
Von unserem OVH Server aus zu eben demselben User:

Code:
traceroute to x (213.47.115.x), 30 hops max, 60 byte packets
 1  rbx-6-m1.fr.eu (87.98.216.253)  0.591 ms  0.757 ms  0.973 ms
 2  rbx-2-6k.fr.eu (213.251.191.130)  204.752 ms * *
 3  rbx-g2-a9.fr.eu (91.121.131.10)  2.459 ms  2.474 ms  2.479 ms
 4  fra-5-6k.fr.eu (178.33.100.245)  23.180 ms fra-5-6k.fr.eu (178.33.100.255)  23.113 ms *
 5  pra-1-6k.cz.eu (213.251.128.109)  16.089 ms * *
 6  vie-1-6k.at.eu (213.251.128.98)  20.593 ms * *
 7  upc.as6830.at.eu (94.23.122.98)  29.519 ms  29.455 ms  29.434 ms
 8  at-vie01a-ra3-ge-0-1-0.aorta.net (213.46.173.118)  36.795 ms  25.357 ms  24.407 ms
 9  at-vie-sk11-pe01-vl-2042.upc.at (84.116.228.126)  30.230 ms  30.226 ms  30.084 ms
10  at-vie-sk11-pe02-vl-1.upc.at (212.17.99.138)  30.347 ms  30.373 ms  30.143 ms
11  chello213047115xxx.20.11.vie.surfer.at (213.47.115.x)  35.805 ms  34.803 ms  39.595 ms
Ich denke, UPC sollte doch eigentlich direkt auch von client zum OVH Netz über euer Peering direkt in Wien gehen, oder sehe ich das falsch?

Besagter User bekommt derzeit von allen unseren OVH Servern ca. 2 Mbit/s pro TCP stream. Öffnet er 2 Downloads, bekommt jeder ca. 2Mbit/s ...

Gruß, Klaus

Hook
30.05.12, 13:15
Das dachte ich mir schon.
Danke trotzdem.

Felix
30.05.12, 10:24
Hook wrote:
> Gibts denn schon Neuigkeiten?


Nein, die Kommunikation scheint etwas zaeh zu sein...

Hook
27.05.12, 17:15
Gibts denn schon Neuigkeiten?

Habt ihr auch mal drüber nachgedacht, das ganze private Peering mit UPC einfach sein zu lassen und alles übers decix oder was weiß ich laufen zu lassen? Offensichtlich ist der Provider ja nicht in der Lage, sein Netzwerk ordentlich zu pflegen ...

Hier mal nen traceroute von nem hetzner Server auf ne IP die von dem Problem betroffen ist. Mit hetzner gibts wie oben beschrieben keine Probleme.
Code:
traceroute to 80.108.240.125 (80.108.240.125), 30 hops max, 60 byte packets
 1  static.x.x.x.176.clients.your-server.de (176.x.x.x)  0.038 ms  0.010 ms  0.008 ms
 2  hos-tr4.juniper2.rz14.hetzner.de (213.239.224.225)  0.132 ms hos-tr3.juniper2.rz14.hetzner.de (213.239.224.193)  0.126 ms 213-239-224-129.clients.your-server.de (213.239.224.129)  0.135 ms
 3  hos-bb1.juniper4.ffm.hetzner.de (213.239.240.230)  4.835 ms  4.818 ms  4.794 ms
 4  tengigabitethernet9-4.ar3.fra3.gblx.net (207.138.95.9)  19.537 ms  19.570 ms  19.683 ms
 5  po2-20G.ar4.FRA3.gblx.net (67.16.133.34)  19.532 ms  19.580 ms  19.630 ms
 6  de-fra01a-ri2-xe-0-3-0.aorta.net (213.46.179.65)  5.020 ms  69.838 ms  69.812 ms
 7  de-fra01a-rd3-xe-1-0-0.aorta.net (213.46.179.98)  18.956 ms de-fra01a-rd3-xe-0-0-0.aorta.net (213.46.179.109)  18.925 ms de-fra01a-rd3-xe-1-0-0.aorta.net (213.46.179.98)  18.919 ms
 8  at-vie15a-rd1-xe-4-3-0.aorta.net (213.46.160.134)  17.344 ms 84.116.136.105 (84.116.136.105)  17.497 ms at-vie15a-rd1-xe-4-3-0.aorta.net (213.46.160.134)  17.462 ms
 9  84.116.228.34 (84.116.228.34)  18.544 ms  17.620 ms  17.508 ms
10  * * *
11  chello080108240125.2.14.vie.surfer.at (80.108.240.125)  50.862 ms  50.854 ms  34.641 ms

Felix
21.05.12, 15:28
Hook wrote:
> Ich stelle schon seit mehreren Wochen fest, dass das Routing vor allem
> nach UPC ziemlich schlecht ist. Es werden abends oft nicht mal 100kb/sec


Zwischenstand: Das NOC steht mit UPC in Kontakt um eine Lösung zu finden.

niko86
20.05.12, 22:35
kann ich bestätigen, mit einer Verbindung 150-250 kb/s
Von hetzner 4mb/s zu jeder Tageszeit

tester
17.05.12, 16:09
bin atm bei der telekom, erreiche mit einer verbindung 650kb/s
das is mein leitungsmaximum

Hook
17.05.12, 15:35
Ich stelle schon seit mehreren Wochen fest, dass das Routing vor allem nach UPC ziemlich schlecht ist. Es werden abends oft nicht mal 100kb/sec erreicht, Mittags und Nachts sind zwar höhere Geschwindigkeiten möglich, allerdings auch selten mehr als 1MB/sec.
Auch von einem Kunden der Telekom Austria habe ich bereits Beschwerden über eine langsame Verbindung bekommen.

Wenn man auf der Weathermap nachsieht, sind die Peerings auch fast zu jeder Tageszeit über 70%. Viel höher gehts einfach nicht, nur die Datenraten sinken in den Abendstunden ab. Ich denke also nicht dass es an OVH direkt liegt, sondern an UPC.

Direkte Nachfragen bei UPC haben bisher auch nichts gebracht, angeblich wird das entsprechend weitergeleitet. Aber vermutlich ging das in die Ablage P ....

Kann OVH eventuell mal bei UPC Druck machen, damit das Peering verbessert wird?

Zum Vergleich sind von hetzner, hosteurope oder von fdcservers (zlin) etwa 4MB/sec (maximum) pro Verbindung möglich, lediglich OVH wird "gedrosselt" und ist für die entsprechenden Nutzer schon fast eine Zumutung ....