OVH Community, your new community space.

Routing Unitymedia / OVH


Marcel40625
22.04.14, 17:19
und es geht wieder los oder was ? ich glaub da müssen neue linecards bei fra-5-6k.de.eu rann ... die teile mucken wohl immernoch ...

Marcel40625
22.04.14, 02:10
joa bei mir auffen server gehts auch wild herr bei UPC DE und CH ...

http://abload.de/img/upcdedu_last_10800mres5.png

1 <1 ms <1 ms <1 ms 192.168.1.1
2 9 ms 5 ms 5 ms 10.156.64.1
3 5 ms 4 ms 5 ms 1411b-mx960-01-ae10-1010.met.unity-media.net [81.210.131.213]
4 5 ms 5 ms 5 ms 1411b-mx960-02-ae0.met.unity-media.net [80.69.106.161]
5 7 ms 6 ms 7 ms 13noc-mx960-01-ae3.krp.unity-media.net [80.69.107.77]
6 12 ms 7 ms 7 ms 13noc-mx960-02-ae0.krp.unity-media.net [80.69.107.202]
7 8 ms 6 ms 7 ms 1411g-mx960-02-ae9.nss.unity-media.net [80.69.107.6]
8 15 ms 15 ms 17 ms 84.116.197.249
9 12 ms 11 ms 17 ms nl-ams09b-ri1-xe-10-2-0.aorta.net [84.116.130.22]
10 30 ms * * ams-5-6k.nl.eu [91.121.131.85]
11 38 ms 40 ms 37 ms rbx-g2-a9.fr.eu [178.33.100.226]
12 37 ms * 170 ms rbx-1-6k.fr.eu [91.121.131.13]
13 37 ms 37 ms 37 ms rbx-5-m2.fr.eu [213.251.191.11]
14 40 ms 35 ms 38 ms ***.fly-host.eu [91.***.**186]

dagegen tcom ... alles ruhig ...

http://abload.de/img/dtagems_last_10800e6jix.png


EDIT: 3:00 UHR: soweit scheint nun alles wieder okay zu sein hier ... geht wieder schön über frankfurt ...

Caddy
21.04.14, 23:41
Irgendwer spielt da aber "BGP-Tennis", der Hin-Weg pendelt schön zwischen Amsix und FRA ... Noch immer zwischendurch.

Gruß, Klaus

Edit: http://travaux.ovh.net/?do=details&id=10667 passt wohl sehr gut dazu, weil das UPC Peering leider kein 2. "Beinchen" auf den 1-6k hat.

jgwegg
21.04.14, 22:35
Mittlerweile geht es bei mir auch wieder, eben sah es noch so aus:

Code:
  1     *        *        *     Request timed out.
  2     1 ms     1 ms     1 ms  gra-g2-a9.fr.eu [178.33.103.227]
  3     *        *        *     Request timed out.
  4     3 ms     *        *     ldn-1-6.uk.eu [213.251.130.121]
  5     *        *        *     Request timed out.
  6    32 ms     *       32 ms  var-1-6k.pl.eu [213.251.128.125]
  7     *        *        *     Request timed out.
  8    41 ms    41 ms    42 ms  pl-waw04a-rd2-xe-0-2-1.aorta.net [84.116.135.233
]
  9    41 ms    41 ms    41 ms  84.116.136.137
 10    41 ms    41 ms    41 ms  1611a-mx960-02-ae2.bfe.unity-media.net [80.69.10
6.173]
 11    42 ms    42 ms    41 ms  ph-1611m-ubr10k-01-Po2.pad.unity-media.net [81.2
10.130.38]

marius
21.04.14, 22:28
Zitat Zitat von jgwegg
Mies, in der Rückrichtung laufen die Pakete im Moment über London und Warschau
Kann ich so nicht bestätigen, lief bzw. läuft bei mir durchgängig über das peering in FRA.

jgwegg
21.04.14, 22:21
Mies, in der Rückrichtung laufen die Pakete im Moment über London und Warschau (in der Hinrichtung immer noch über Holland).

Sind wohl gerade ein paar Router abgeraucht oder so: http://fra.smokeping.ovh.net/ovh-ser...et=EU.AS6830-4

marius
21.04.14, 22:05
Ist mir auch aufgefallen, scheinbar läuft das jetzt über NL.

Das routing in die andere Richtung läuft aber noch über das direkte peering.

edit: Ist wieder normal.

jgwegg
21.04.14, 22:03
Wurde das Routing nochmals geändert? Anscheinend gibt es jetzt kein direktes Peering am DE-CIX mehr:

Code:
 1. router                                           0.0%   131    0.3   0.4   0.3   1.9   0.2
 2. 10.193.0.1                                       0.0%   131    6.7   8.0   5.5  17.1   1.9
 3. 1611a-mx960-01-ae10.bfe.unity-media.net          0.0%   131    8.0  11.8   6.3  66.1  11.4
 4. 1611a-mx960-02-ae0.bfe.unity-media.net           0.0%   131   10.5  12.0   6.8  41.0   7.6
 5. de-fra01b-rc1-ae17.fra.unity-media.net           0.0%   131   21.5  23.9  21.2  42.4   3.1
 6. nl-ams02a-rd1-tge-0-4-0-2.aorta.net              0.0%   131   22.5  24.2  20.5  67.3   6.8
 7. 84.116.135.206                                   0.8%   131   23.2  23.7  20.9  41.0   3.0
 8. ams-5-6k.nl.eu                                  63.8%   131   22.1  26.8  21.0  91.5  10.0
 9. rbx-g2-a9.fr.eu                                 42.0%   131   30.3  28.0  23.0  90.0   7.8
10. gsw-g1-a9.fr.eu                                 43.8%   130   32.5  42.7  25.3 410.9  58.6
    gsw-g1-a9.fr.eu
11. gra-g1-a9.fr.eu                                 41.5%   130   33.0  32.2  30.1  40.6   2.2
    gra-g1-a9.fr.eu
12. gra-3a-6k.fr.eu                                 98.4%   130   94.6  62.9  31.3  94.6  44.8
13. ks3x.kimsufi.com                            41.5%   130   31.4  31.9  29.3  40.3   2.1

SchwippSchwapp
31.07.13, 15:04
danke!

auch wenn ich keine geschwindigkeits probleme hatte ist die kürzere route mir natürlich lieber

Felix
31.07.13, 12:44
Felix wrote:
> Habe es ans NOC weitergeleitet und hoffe auf baldige Besserung.


fixed :-)
http://fra.smokeping.ovh.net/ovh-ser...et=EU.AS6830-4

Felix
31.07.13, 12:14
SchwippSchwapp wrote:
> weil laut eurer smokeping seite ist das routing nun über amsterdam und
> der ping von 7ms auf 18ms gestiegen. In der Weathermap stehen die links
> in frankfurt als ungenutzt da.


Habe es ans NOC weitergeleitet und hoffe auf baldige Besserung.

Caddy
30.07.13, 15:13
Zitat Zitat von SchwippSchwapp
wird das UPC peering in frankfurt extra nicht benutzt?

weil laut eurer smokeping seite ist das routing nun über amsterdam und der ping von 7ms auf 18ms gestiegen. In der Weathermap stehen die links in frankfurt als ungenutzt da.

http://fra.smokeping.ovh.net/ovh-ser...et=EU.AS6830-4

Jo. Von UPC nach OVH manchmal schon, von OVH nach UPC (speziell Unitymedta) geht's plötzlich über AMSIX. Ist eigentlich eher ein Randomizer

Aber zumindest ist es bei mir noch schnell:
Code:
 1  rbx-6-m1.fr.eu (87.98.216.253)  0.573 ms  0.836 ms  0.985 ms
 2  rbx-2-6k.fr.eu (213.251.191.130)  13.732 ms * *
 3  rbx-g2-a9.fr.eu (91.121.131.10)  2.167 ms  2.260 ms  2.320 ms
 4  ams-5-6k.nl.eu (94.23.122.190)  42.810 ms * ams-5-6k.nl.eu (91.121.131.170)  42.765 ms
 5  * * *
 6  nl-ams05a-rd2-xe-4-0-0.aorta.net (84.116.130.1)  12.908 ms  12.779 ms  12.751 ms
 7  84.116.197.250 (84.116.197.250)  17.628 ms  16.454 ms  16.360 ms
 8  13NOC-MX960-02-ae9.krp.unity-media.net (80.69.107.5)  11.721 ms  11.696 ms  11.756 ms
 9  13NOC-MX960-01-ae0.krp.unity-media.net (80.69.107.201)  11.748 ms  11.594 ms  11.651 ms
10  1214A-MX80-01-ae1.wup.unity-media.net (80.69.107.74)  12.643 ms  12.608 ms  12.611 ms
11  PH-1214A-uBR10k-01-Te-1-2-0-1010.wup.unity-media.net (81.210.131.94)  13.593 ms  12.984 ms  13.010 ms
12  ip-178-200-x-x.unitymediagroup.de (178.200.x.x)  17.893 ms  17.753 ms  18.234 ms
Die Österreicher (UPC) laufen anscheinend noch über TATA. Sehr "sinnvoll", denn es steigt in Frankfurt nach TATA aus um auch in Frankfurt wieder bei UPC einzusteigen :-)

Gruß, Klaus

SchwippSchwapp
29.07.13, 21:13
wird das UPC peering in frankfurt extra nicht benutzt?

weil laut eurer smokeping seite ist das routing nun über amsterdam und der ping von 7ms auf 18ms gestiegen. In der Weathermap stehen die links in frankfurt als ungenutzt da.

http://fra.smokeping.ovh.net/ovh-ser...et=EU.AS6830-4

bene
27.06.13, 01:45
Hallo Felix,

hier auch nochmal ein Traceroute von OVH zu mir:
Code:
 1  vss-9a-6k.fr.eu (5.39.79.253)  6.478 ms * *
 2  rbx-g1-a9.fr.eu (91.121.131.155)  1.763 ms  1.756 ms  1.728 ms
 3  fra-1-6k.de.eu (178.33.100.249)  8.129 ms fra-1-6k.de.eu (94.23.122.209)  8.107 ms fra-1-6k.de.eu (91.121.131.194)  8.090 ms
 4  fra-5-6k.fr.eu (94.23.122.222)  8.036 ms * *
 5  * * *
 6  if-12-1656.tcore1.FR0-Frankfurt.as6453.net (195.219.50.89)  8.374 ms  8.246 ms if-4-1108.tcore1.FNM-Frankfurt.as6453.net (195.219.156.133)  8.151 ms
 7  if-9-2.tcore1.FR0-Frankfurt.as6453.net (195.219.50.41)  57.667 ms if-7-2.tcore1.FR0-Frankfurt.as6453.net (195.219.50.1)  8.614 ms 213.46.179.137.aorta.net (213.46.179.137)  8.432 ms
 8  84.116.132.185 (84.116.132.185)  20.029 ms 213.46.179.137.aorta.net (213.46.179.137)  8.404 ms 84.116.132.185 (84.116.132.185)  20.183 ms
 9  84.116.132.185 (84.116.132.185)  20.123 ms  20.054 ms  20.030 ms
10  84.116.136.62 (84.116.136.62)  14.149 ms 84.116.200.246 (84.116.200.246)  23.366 ms  23.401 ms
11  84.116.200.246 (84.116.200.246)  26.315 ms *  23.504 ms
12  * * *
Aber läuft wirklich super auch über den TATA Link....

Felix
26.06.13, 10:54
Yahoodi wrote:
> im Moment bin ich nicht @home, aber das sieht genau so aus wie bei
> Bene.
> Ich bin in der Schweiz, in der Nähe von Zürich - Subnetz 80.219.129.x


ok, dann habe ich schon traceroutes
Danke!

Yahoodi
26.06.13, 10:43
Zitat Zitat von Felix
Yahoodi wrote:
> Der Rückweg geht zwar immernoch über TATA (deswegen wohl auch 50ms) -


Deutschland / Oesterreich / Schweiz?
Kannst du eventuell noch einen traceroute/mtr posten (idealerweise in beide
richtungen: von OVH zu dir, und von dir zu OVH)?
Hallo Felix,

im Moment bin ich nicht @home, aber das sieht genau so aus wie bei Bene.
Ich bin in der Schweiz, in der Nähe von Zürich - Subnetz 80.219.129.x

Vom Server zu mir :
Code:
traceroute to 80.219.129.x (80.219.129.x), 30 hops max, 60 byte packets
 1  vss-1-6k.fr.eu (94.23.13.253)  2.566 ms * *
 2  rbx-g2-a9.fr.eu (91.121.131.30)  25.148 ms  25.146 ms  25.257 ms
 3  fra-5-6k.fr.eu (91.121.131.133)  7.995 ms fra-5-6k.fr.eu (178.33.100.255)  7.996 ms *
 4  * * *
 5  if-12-1656.tcore1.FR0-Frankfurt.as6453.net (195.219.50.89)  11.033 ms  15.822 ms if-4-1108.tcore1.FNM-Frankfurt.as6453.net (195.219.156.133)  8.174 ms
 6  213.46.179.137.aorta.net (213.46.179.137)  8.409 ms if-7-2.tcore1.FR0-Frankfurt.as6453.net (195.219.50.1)  10.170 ms  15.304 ms
 7  84.116.132.185 (84.116.132.185)  16.816 ms 84.116.132.177 (84.116.132.177)  16.943 ms 213.46.179.137.aorta.net (213.46.179.137)  8.304 ms
 8  84.116.136.62 (84.116.136.62)  16.684 ms  13.815 ms 84.116.132.177 (84.116.132.177)  19.700 ms
 9  84.116.136.173 (84.116.136.173)  13.879 ms  14.142 ms 84.116.200.242 (84.116.200.242)  15.618 ms
10  * * 84.116.200.242 (84.116.200.242)  15.280 ms
11  * * *

Felix
26.06.13, 10:22
Yahoodi wrote:
> Der Rückweg geht zwar immernoch über TATA (deswegen wohl auch 50ms) -


Deutschland / Oesterreich / Schweiz?
Kannst du eventuell noch einen traceroute/mtr posten (idealerweise in beide
richtungen: von OVH zu dir, und von dir zu OVH)?

Yahoodi
26.06.13, 08:39
https://dl.dropboxusercontent.com/u/...2008.35.05.jpg

Der Rückweg geht zwar immernoch über TATA (deswegen wohl auch 50ms) - aber das sieht ja mal gut aus.

Felix
21.06.13, 12:54
bene wrote:
> @Felix: Momentan läuft es aber auch über TATA super:
> [image: http://i.imm.io/19Pqh.jpeg]


wow, 29 ms? Das schaffen gewisse provider nicht mal von Saarbruecken aus, und
das liegt auf halber strecke

Theoretisch muesste es noch ein ganz klein bisschen besser werden wenn die 2.
Route auch noch direkt ueber das neue Peering geht statt über TATA...

bene
20.06.13, 21:56
@Felix: Momentan läuft es aber auch über TATA super:
http://i.imm.io/19Pqh.jpeg

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

  1     8 ms     6 ms     6 ms  80-219-132-1.dclient.hispeed.ch [80.219.132.1]
  2    10 ms    10 ms    10 ms  217-168-55-173.static.cablecom.ch [217.168.55.173]
  3     *       21 ms    22 ms  84.116.200.245
  4    21 ms    21 ms    21 ms  84.116.136.61
  5    22 ms    21 ms    21 ms  84.116.132.194
  6    20 ms    21 ms     *     fra-5-6k.de.eu [91.121.131.77]
  7    33 ms    33 ms    32 ms  rbx-g2-a9.fr.eu [91.121.131.134]
  8     *       31 ms     *     rbx-s3-6k.fr.eu [213.251.128.80]
  9    30 ms    28 ms    29 ms  proof.ovh.net [188.165.12.106]

Ablaufverfolgung beendet.
Wenn es so bleibt... TipTop

Felix
18.06.13, 16:32
bene wrote:
> Scheins wurden alle AT/CH Netze noch nicht geändert.


Ist seitens UPC "in Bearbeitung" (die muessen uns diese neuen Netze ueber das
PNI ankuendigen)

strex
17.06.13, 21:26
Zitat Zitat von SchwippSchwapp
vom nachbarn gehts direkt nach frankreich und bei mir über chicago.
Das geht auch nicht über Chicago, sieht man doch am Ping von 47. Sonst wäre das Überlichtgeschwindigkeitskommunikation. Ist nur wieder ein falscher Reverse DNS Eintrag.

Zumal die Richtung UM -> OVH, nicht von OVH sondern von UM angepasst werden muss. Denn die entscheiden wo der Traffic übergeben wird.

SchwippSchwapp
17.06.13, 21:22
obere ist über wlan vom nachbarn und zweite versuch war über meine leitung, bin leider einer von den neuen mit ip6

http://abload.de/thumb/unbenannt2cto2t.png

vom nachbarn gehts direkt nach frankreich und bei mir über chicago.

Felix
17.06.13, 10:20
SchwippSchwapp wrote:
> an dem routing muss aber noch gearbeitet werden, bei mir geht der trace
> zu proof.ovh.net über frankfurt nach ovh in chicago und dann nach
> frankreich.


Ja, bitte einen screenshot schicken/hier einstellen

SchwippSchwapp
17.06.13, 02:07
hab nen screenshot gemacht aber der is auffem notebook und das liegt gerade wo anders.

wenns morgen wieder so ist werd ich ihn mal reinstellen, will ja selber das es bestmöglich läuft

Caddy
16.06.13, 23:46
Zitat Zitat von SchwippSchwapp
an dem routing muss aber noch gearbeitet werden, bei mir geht der trace zu proof.ovh.net über frankfurt nach ovh in chicago und dann nach frankreich.
Da wäre aber ein tracert schon aus meinem privaten Interesse sehr spannend gewesen. Ich habe Zugang zu mehreren Business Anschlüssen mit wirklich bunt gemischen IP's im Unitymedia Netz und die gehen alle fra-5-6k und dann direkt nach rbx...

Gruß, Klaus

SchwippSchwapp
16.06.13, 23:22
an dem routing muss aber noch gearbeitet werden, bei mir geht der trace zu proof.ovh.net über frankfurt nach ovh in chicago und dann nach frankreich.

Yahoodi
15.06.13, 14:47
2% [=============================> ] 560'333'688 10.1M/s ETA 84s

Prima, damit kann man doch schonmal grundsätzlich arbeiten :-) Frohe Weihnachten ;-)

bene
14.06.13, 09:35
Hallo,

bei mir geht es ebenfalls zu OVH direkt über FFM, zurück noch über TATA.
Scheins wurden alle AT/CH Netze noch nicht geändert.

Code:
inetnum:        80.219.96.0 - 80.219.191.255
netname:        CABLECOMMAIN-NET
descr:          Cablecom GmbH
descr:          DHCP Scopes
country:        CH

panda
13.06.13, 23:29
Zitat Zitat von Felix
Kannst du uns Beispiel-IPs geben die noch ueber TATA gehen? dann kann ich das
entsprechend weiterleiten / pruefen lassen.
Für CH wäre das beispielsweise
84.72.32.0 - 84.72.59.255

UPC->OVH ist wie bei Caddy ebenfalls direkt.

Caddy
13.06.13, 18:55
Zitat Zitat von Felix
Kannst du uns Beispiel-IPs geben die noch ueber TATA gehen? dann kann ich das
entsprechend weiterleiten / pruefen lassen.
Kann ich im Moment nur fuer ein Netz, vielleicht schauen ja noch mehr aus Oesterreich hier rein. Mein Wien-Kontakt ist z.B. in diesem Netz:

inetnum: 213.47.112.0 - 213.47.143.255
netname: CHELLO
descr: UPC Telekabel


Seine Rueckroute von ihm zu OVH wird bereits ueber ffm geroutet, nur OVH zu ihm geht noch ueber TATA

Gruß, Klaus

Felix
13.06.13, 17:46
Caddy wrote:
> Ich weiss, es ist ein anderer Thread, aber werden die Routen Richtung
> UPC Österreich (Wien) und Richtung Schweiz auch noch angepasst? Die
> routen nämlich noch über TATA...


Ja, sollten... Sind noch mit UPC in Kontakt damit die ihre announces anpassen,
ganz abgeschlossen ist dieser Fall also noch nicht.

Kannst du uns Beispiel-IPs geben die noch ueber TATA gehen? dann kann ich das
entsprechend weiterleiten / pruefen lassen.

Caddy
13.06.13, 15:46
YES!

Code:
Unitymedia > Roubaix 3:
 1  10.196.192.1 (10.196.192.1)  8.880 ms  8.715 ms  8.711 ms
 2  1214A-MX80-01-ae10-1010.wup.unity-media.net (81.210.131.93)  8.886 ms  8.889 ms  8.885 ms
 3  13NOC-MX960-01-ae2.krp.unity-media.net (80.69.107.73)  10.575 ms  10.935 ms  10.934 ms
 4  7111A-MX960-01-ae8.fra.unity-media.net (80.69.107.25)  13.938 ms  13.956 ms  13.968 ms
 5  84.116.197.245 (84.116.197.245)  13.694 ms  13.704 ms  13.702 ms
 6  fra-5-6k.de.eu (91.121.131.77)  13.774 ms  13.136 ms *
 7  rbx-g2-a9.fr.eu (91.121.131.130)  22.702 ms  22.181 ms  22.142 ms
 8  vss-3-6k.fr.eu (213.251.130.77)  20.147 ms * vss-3b-6k.fr.eu (213.186.32.174)  20.030 ms
 9  ?.de (188.165.x.x)  19.304 ms  19.314 ms  19.301 ms
Code:
Roubaix 3 > Unitymedia:
 1  vss-3b-6k.fr.eu (188.165.201.252)  0.288 ms * *
 2  rbx-g1-a9.fr.eu (213.186.32.253)  0.728 ms  0.961 ms  1.036 ms
 3  fra-1-6k.de.eu (178.33.100.249)  7.890 ms * *
 4  fra-5-6k.fr.eu (94.23.122.218)  7.875 ms * *
 5  * * *
 6  84.116.197.246 (84.116.197.246)  8.204 ms  8.225 ms  8.028 ms
 7  13NOC-MX960-01-ae8.krp.unity-media.net (80.69.107.26)  12.007 ms  11.938 ms  11.953 ms
 8  1214A-MX80-01-ae1.wup.unity-media.net (80.69.107.74)  12.854 ms  12.835 ms  12.866 ms
 9  PH-1214A-uBR10k-01-Te-1-2-0-1010.wup.unity-media.net (81.210.131.94)  12.855 ms  12.842 ms  12.861 ms
10  ip-178-200-x-x.unitymediagroup.de (178.200.x.x)  16.943 ms  20.105 ms  19.829 ms
Es muss tatsächlich Weihnachten sein.
Als Threadstarter muss ich mich an der Stelle auch mal bedanken !!

Ich weiss, es ist ein anderer Thread, aber werden die Routen Richtung UPC Österreich (Wien) und Richtung Schweiz auch noch angepasst? Die routen nämlich noch über TATA...

Gruß, Klaus

Felix
13.06.13, 14:32
Eddy wrote:
> Eine sache würde mich da echt noch interessieren, aber ist
> wahrscheinlich interna


korrekt.

Eddy
13.06.13, 13:12
4 7 ms 7 ms 7 ms 7111A-MX960-01-ae0.fra.unity-media.net [80.69.10
7.213]
5 8 ms 6 ms 7 ms 84-116-131-149.aorta.net [84.116.131.149]
6 8 ms * 7 ms fra-5-6k.de.eu [91.121.131.77]
7 15 ms 15 ms 17 ms rbx-g2-a9.fr.eu [91.121.131.134]
8 15 ms * 15 ms rbx-s3-6k.fr.eu [213.251.128.80]
9 15 ms 14 ms 15 ms proof.ovh.net [188.165.12.106]



Satte 10Ms und 4 Hops weniger als zuvor
Speed ist auch hervorragend

--2013-06-13 13:24:36-- http://proof.ovh.net/files/1Gio.dat
Resolving proof.ovh.net... 188.165.12.106
Connecting to proof.ovh.net|188.165.12.106|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1073741824 (1.0G) [application/octet-stream]
Saving to: `NUL'

4% [> ] 44,884,430 8.16M/s eta 2m 10s

Leitung gesättigt

Eine sache würde mich da echt noch interessieren, aber ist wahrscheinlich interna aber ich versuchs mal, müsst ihr für das PNI zahlen port/Traffic ?

Hier noch ein Trace nach Strassbourg

4 6 ms 7 ms 7 ms 7111A-MX960-01-ae0.fra.unity-media.net [80.69.10
7.213]
5 * 6 ms 7 ms 84-116-131-149.aorta.net [84.116.131.149]
6 6 ms * 6 ms fra-5-6k.de.eu [91.121.131.77]
7 10 ms 10 ms 10 ms sbg-g1-a9.fr.eu [91.121.128.127]
8 9 ms * 10 ms sbg-s4-6k.fr.eu [91.121.131.150]
9 9 ms 9 ms 10 ms sbg.proof.ovh.net [5.135.128.81]

<3

Felix
13.06.13, 12:54
Eddy wrote:
> läuft aber noch kein traffic darüber


Weihnachten findet 2013 im Juni statt.

Der link ist schon halb konfiguriert und traegt ein wenig traffic, wir warten
auf UPC fuer die letzte Huerde (BGP-Konfiguration)

saber2003
12.06.13, 18:48
http://status.ovh.net/?do=details&id=4864

Felix
12.06.13, 17:12
Eddy wrote:
> sind das 3x10gbits ?


ja

Eddy
12.06.13, 17:08
und nummer 3 leuchtet

sind das 3x10gbits ?

Felix
12.06.13, 16:30
Caddy wrote:
> (Ironie on) Bestimmt wurden die angeschaltet, um das wilde F5 Gedrücke
> auf der Weathermap zu unterbinden (Irnoie off)


darfst ruhig weiterdruecken, dann wirst du bald auch noch den 3. sehen.

Interconnection ist also "schon" up! jetzt warten wir "nur" noch auf die
Aktivierug von BGP seitens UPC... Bin aber wieder sehr optimistisch das es
diese Woche doch noch klappen koennte.

Caddy
12.06.13, 16:16
Zitat Zitat von Eddy
Ooohh 2 der 3 links sind anscheinend Hell
(Ironie on) Bestimmt wurden die angeschaltet, um das wilde F5 Gedrücke auf der Weathermap zu unterbinden (Irnoie off)

Ernst beiseite, ich freue mich wirklich über jeden kleinen Fortschritt in der Richtung. Bisschen Farbe könnte jetzt nicht schaden :-)

Gruß, Klaus

Eddy
12.06.13, 14:58
Ooohh 2 der 3 links sind anscheinend Hell

läuft aber noch kein traffic darüber

Eddy
06.06.13, 23:43
Zitat Zitat von Caddy
Klar, das Lametta ist ja auch noch so farblos

Ich habe aber mal irgendwann zwangsweise getestet, wieso ich nach einem Unitymedia Ausfall und einer IP, die ich vorher noch nie hatte, plötzlich einen saumäßigen Ping habe. Danach wurde mir klar, dass TATA verschiedene Subnetze von Unitymedia leider über verschiedene nicht sinnvolle Wege schicken. Dabei funktioniert für mich 178.200.x noch am besten und zu den meisten Zeiten auch mit genügend Durchsatz.

Diese Art von Experimenten haben aber sicher bald ein Ende, wenn es um den fra-5-6k oben links etwas bunter wird. Ich nehme alle Farben ausser rot :-)

Gruß, Klaus
Stimmt ich kenne 3 routen

1te Tata FFM zu Aorta FFM
2te Tata FFm zu TATA Frankreich zu AORTA Frankreich
3te TATA FFM zu TATA Amsterdam zu TATA England zu Aorta England


Mir ist auf der Weathermap eben aufgefallen, es gibt nun auch UPC peering am AMS-5-6k dies scheint sogar aktiv zu sein, könnte man nicht derweil den traffic über dieses abwickeln ?

Dürfte pingtechnisch nicht schlimm sein, Vodafone geht z.b. immer über den AMSIX zurück.

SchwippSchwapp
06.06.13, 18:47
da es ein neuanschluss ist hab ich leider IP6 und keinen einfluss auf die IP4 addresse nach "draußen"

hatte beim testen jedenfalls bei den IP4 und IP6 speedtests unterschiedliche geschwindigkeiten, da lief das IP6 routing deutlich besser.

Caddy
06.06.13, 16:55
Zitat Zitat von Eddy
aus dem 109.90er Netz aber geht halt trotzdem alles noch über TATA/Level3
Klar, das Lametta ist ja auch noch so farblos

Ich habe aber mal irgendwann zwangsweise getestet, wieso ich nach einem Unitymedia Ausfall und einer IP, die ich vorher noch nie hatte, plötzlich einen saumäßigen Ping habe. Danach wurde mir klar, dass TATA verschiedene Subnetze von Unitymedia leider über verschiedene nicht sinnvolle Wege schicken. Dabei funktioniert für mich 178.200.x noch am besten und zu den meisten Zeiten auch mit genügend Durchsatz.

Diese Art von Experimenten haben aber sicher bald ein Ende, wenn es um den fra-5-6k oben links etwas bunter wird. Ich nehme alle Farben ausser rot :-)

Gruß, Klaus

Eddy
06.06.13, 16:32
Ping wird ausgeführt für proof.ovh.net [188.165.12.106] mit 32 Bytes Daten:
Antwort von 188.165.12.106: Bytes=32 Zeit=24ms TTL=50
Antwort von 188.165.12.106: Bytes=32 Zeit=25ms TTL=50
Antwort von 188.165.12.106: Bytes=32 Zeit=24ms TTL=50
Antwort von 188.165.12.106: Bytes=32 Zeit=25ms TTL=50

Ping-Statistik für 188.165.12.106:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 24ms, Maximum = 25ms, Mittelwert = 24ms


aus dem 109.90er Netz aber geht halt trotzdem alles noch über TATA/Level3

Caddy
06.06.13, 06:03
Zitat Zitat von SchwippSchwapp
ich hoffe da tut sich wirklich bald was, hab nun in der neuen wohnung seit gestern unitymedia und hab da nen ping von 110-120ms zu proof.ovh.net.
Och, manchmal lässt sich das temporär leicht beheben. Du musst nur Deinen Router überreden, dass er eine neue IP von Unitymedia bezeht. Der hohe Ping ist nämlich nicht ortsabhängig, sondern IP abhänging :-)

Mit 178.200.x geht das:
Code:
--- proof.ovh.net ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 32.092/32.248/32.446/0.147 ms
Gruß, Klaus

SchwippSchwapp
02.06.13, 22:21
ich hoffe da tut sich wirklich bald was, hab nun in der neuen wohnung seit gestern unitymedia und hab da nen ping von 110-120ms zu proof.ovh.net.

bin mal gespannt wenn ich eingezogen bin wie es dann bei längerer benutzung aussieht.

Eddy
30.05.13, 14:45
Zitat Zitat von Caddy
Nicht ganz - Erst, wenn das Glasfaser-Lametta zwischen den zwei Router-Bäumchen bunt wird

haste wohl recht gehabt, schon wieder ne ganze woche um und nichts leuchtet

glaub dauert nochmal nen halbes jahr

Caddy
24.05.13, 12:04
Das liegt - vermutlich - aber eher an einer Optimierung seitens TATA. Für Teile der Unitymedia Netze z.B. 178.200.0.0/15AS20825 wäre eine Optimierung, wenn OVH das Routing über ldn-x-6k an TATA übergibt, denn TATA routet das sowieso nach London und übergibt es dort an LGI:

Code:
6. if-4-1108.tcore1.FNM-Frankfurt.as6453.net
8. if-2-2.tcore2.AV2-Amsterdam.as6453.net
10. Vlan800.icore2.LDN-London.as6453.net
11. 213.46.179.105.aorta.net
Falls das die Mühe überhaupt noch lohnt, denn wenn nicht wieder einer der TATA Links in Frankfurt ausfällt, kann ich persönlich derzeit auch mit der monentanen Lösung leben, die Latenz ist halt unnötig hoch aber der Durchsatz ist meistens ok.

Gruß, Klaus

Marya
23.05.13, 22:01
Ich sehe momentan auch nicht das sonst übliche absurde Routing Fra->Par->Fra im TATA-Netz, das 10ms mehr Latenz zur Folge hatte. Aber nicht zu früh freuen. Das war vor ein paar Monaten auch schonmal kurze Zeit so.

bene
22.05.13, 20:47
Etwas unglaubliches ist geschehen:
http://i.imm.io/16XiR.jpeg

Leider sind scheinbar noch nicht alle IP Ranges umgestellt, von meinem Server (5.39.79.XXX IP) aus geht es weiterhin über TATA mit ca 10MBit/s zu mir...

Hier nochmal aktuelle Traceroutes:
Code:
 1  * * *
 2  217-168-55-173.static.cablecom.ch (217.168.55.173)  6.610 ms  6.085 ms  7.864 ms
 3  84.116.200.245 (84.116.200.245)  22.883 ms  22.609 ms  19.465 ms
 4  ch-zrh01b-ra1-ae-1.aorta.net (84.116.134.142)  19.136 ms  18.920 ms  18.762 ms
 5  4.68.127.49 (4.68.127.49)  90.803 ms  90.407 ms  90.251 ms
 6  ae-11-11.car2.Zurich1.Level3.net (4.69.133.234)  106.842 ms  92.203 ms  92.145 ms
 7  ae-7-7.ebr2.Frankfurt1.Level3.net (4.69.133.237)  22.139 ms  22.552 ms  22.306 ms
 8  ae-72-72.csw2.Frankfurt1.Level3.net (4.69.140.22)  22.113 ms ae-92-92.csw4.Frankfurt1.Level3.net (4.69.140.30)  22.419 ms ae-82-82.csw3.Frankfurt1.Level3.net (4.69.140.26)  23.690 ms
 9  ae-4-90.edge5.Frankfurt1.Level3.net (4.69.154.201)  24.010 ms *  22.458 ms
10  * * *
11  rbx-g2-a9.fr.eu (91.121.131.130)  31.107 ms  30.541 ms  33.700 ms
12  vss-9b-6k.fr.eu (178.33.100.74)  29.925 ms * vss-9a-6k.fr.eu (91.121.131.156)  30.757 ms
13  ks3266XXX.kimsufi.com (5.39.79.XXX)  30.522 ms  30.153 ms  32.807 ms
und

Code:
 1  vss-9a-6k.fr.eu (5.39.79.253)  1.027 ms * *
 2  rbx-g1-a9.fr.eu (91.121.131.155)  1.226 ms  1.206 ms  2.784 ms
 3  * * *
 4  * * *
 5  tata.as6453.de.eu (213.251.130.106)  13.845 ms  13.829 ms  13.805 ms
 6  if-12-1656.tcore1.FR0-Frankfurt.as6453.net (195.219.50.89)  8.498 ms if-4-1108.tcore1.FNM-Frankfurt.as6453.net (195.219.156.133)  8.266 ms  8.483 ms
 7  213.46.179.137.aorta.net (213.46.179.137)  8.716 ms if-7-2.tcore1.FR0-Frankfurt.as6453.net (195.219.50.1)  8.930 ms 213.46.179.137.aorta.net (213.46.179.137)  8.381 ms
 8  84.116.132.177 (84.116.132.177)  20.173 ms 84.116.132.185 (84.116.132.185)  20.085 ms 213.46.179.137.aorta.net (213.46.179.137)  8.504 ms
 9  84.116.132.185 (84.116.132.185)  20.404 ms  20.252 ms 84.116.132.177 (84.116.132.177)  20.229 ms
10  fr-par02a-rd1-gi-15-0-0.aorta.net (213.46.160.49)  14.216 ms 84.116.200.246 (84.116.200.246)  20.378 ms 84.116.136.173 (84.116.136.173)  15.834 ms
11  84.116.200.246 (84.116.200.246)  20.744 ms  23.345 ms *
12  * * *
13  * * *
14  *^C

Caddy
22.05.13, 16:34
Zitat Zitat von Eddy
Ja ist den heut schon weihnachten
Nicht ganz - Erst, wenn das Glasfaser-Lametta zwischen den zwei Router-Bäumchen bunt wird

Eddy
22.05.13, 14:48
Zitat Zitat von Caddy
Ich muss ja mal ganz kleinlaut hinzufügen, dass ich gerade auf der Weathermap am fra-5-6k diese netten 3 kleinen Links nach UPC sehe - Ich hab' irgendwie ja jetzt ein bisschen Vorfreude und kann es kaum erwarten, da Aktivität drauf zu sehen :-)
Ja ist den heut schon weihnachten

Bin auchmal gespannt, in wieweit die last dann auf dem tatat in fra-5-6k abfällt.

warscheinlich werden die 2 links komplett eingespart werden können

Caddy
21.05.13, 15:21
Ich muss ja mal ganz kleinlaut hinzufügen, dass ich gerade auf der Weathermap am fra-5-6k diese netten 3 kleinen Links nach UPC sehe - Ich hab' irgendwie ja jetzt ein bisschen Vorfreude und kann es kaum erwarten, da Aktivität drauf zu sehen :-)

Eddy
21.05.13, 14:24
Würde LGI sich nicht so anstellen, könnten sie einfach mit paar klicks das decix peering für ovh öffnen und der drops wäre gelutscht :/

bzw zumindest solange bis sie es endlich aufe reihe bekommen das eigene ans laufen zu bekommen....

Caddy
21.05.13, 13:54
Zitat Zitat von Felix
Wir versuchen derzeit nochmal alles um die Zeit bis zur Fertigstellung des
Peerings seitens UPC [...] moeglichst sauber zu ueberbruecken.[...]
Wenn ich mir die traceroutes so anschaue und davon ausgehe, dass ihr LGI (upc, unitymedia, cablecom ch etc) im Moment weiter über TATA routet, wird das aber bestimmt nicht einfach. Der Übergabepunkt ist ja überall Frankfurt, nur TATA routet ja teilweise ganze Subnetze völlig wirr durchs Land.

Z.B. 178.200.x.x (Unitymedia) läuft Roubaix->Frankfurt(tata)->Amsterdam(tata)->London(tata)->London(lgi/upc)->Neuss(Unitymedia)...

Für mich bedeutet das, ich habe vom Server zu mir 18 Hops, durch die teilweise sehr weiten Wege treibt das die Latenz ziemlich in die Höhe...

Der Durchsatz ist allerdings im Moment (bei mir) sehr gut - Gerade nochmal gemessen: 104.857.600 10,9M/s in 11s

Mehr kann der Server nicht - Er hat nur 100Mbit/s :-)

Bei der Masse an UPC Kunden (ich sage mal lieber LGI Kunden, denn letztendlich hat es ja LGI geschafft, diverse Anbieter aufzukaufen und über ein gemeinsames Netz zu führen) und eurer Größe kann es eigentlich nur eine entsprechende Peering Lösung (oder PNI, whatever) geben, die auch entsprechend vorangetrieben werden sollte :-)

Gruß, Klaus

bene
15.05.13, 23:54
Hi,

in die Schweiz schaut es momentan so aus:

Code:
 1  * * *
 2  rbx-g1-a9.fr.eu (91.121.131.155)  0.647 ms  0.961 ms  0.947 ms
 3  * * *
 4  * * *
 5  tata.as6453.de.eu (213.251.130.106)  9.136 ms  9.361 ms  9.348 ms
 6  if-4-1108.tcore1.FNM-Frankfurt.as6453.net (195.219.156.133)  8.095 ms if-12-1656.tcore1.FR0-Frankfurt.as6453.net (195.219.50.89)  8.249 ms  8.299 ms
 7  if-9-2.tcore1.FR0-Frankfurt.as6453.net (195.219.50.41)  8.578 ms 213.46.179.137.aorta.net (213.46.179.137)  8.154 ms if-7-2.tcore1.FR0-Frankfurt.as6453.net (195.219.50.1)  8.454 ms
 8  213.46.179.137.aorta.net (213.46.179.137)  8.416 ms 84.116.132.145 (84.116.132.145)  22.538 ms 213.46.179.137.aorta.net (213.46.179.137)  8.454 ms
 9  84.116.132.153 (84.116.132.153)  22.956 ms 84.116.133.117 (84.116.133.117)  22.382 ms  22.423 ms
10  84.116.133.117 (84.116.133.117)  19.931 ms  19.961 ms ch-zrh01a-ra1-xe-1-0-0.aorta.net (213.46.160.46)  19.031 ms
11  ch-zrh01a-ra1-xe-1-0-0.aorta.net (213.46.160.46)  19.062 ms 84.116.134.45 (84.116.134.45)  19.162 ms 84.116.202.246 (84.116.202.246)  20.311 ms
12  84.116.202.246 (84.116.202.246)  23.032 ms  23.222 ms  23.223 ms
13  80-219-132-XXX.dclient.hispeed.ch (80.219.132.XXX)  29.438 ms  32.727 ms  31.302 ms
bzw

Code:
 1  * * *
 2  217-168-55-173.static.cablecom.ch (217.168.55.173)  13.867 ms  13.614 ms  13.608 ms
 3  84.116.200.245 (84.116.200.245)  19.282 ms  19.014 ms  18.881 ms
 4  ch-zrh01b-ra1-ae-1.aorta.net (84.116.134.142)  22.136 ms  21.942 ms  18.932 ms
 5  213.46.171.22 (213.46.171.22)  21.219 ms  21.250 ms  20.816 ms
 6  pos0-1-1-0.gencr1.Geneve.opentransit.net (193.251.243.65)  24.856 ms  22.622 ms  23.461 ms
 7  pos14-0-1.pascr4.Paris.opentransit.net (193.251.240.53)  45.750 ms  47.867 ms  47.613 ms
 8  193.251.133.21 (193.251.133.21)  43.740 ms tengige0-5-0-11.auvtr1.Aubervilliers.opentransit.net (193.251.129.205)  34.031 ms  36.023 ms
 9  xe-10-0-2-0.auvtr3.Aubervilliers.opentransit.net (193.251.131.201)  99.571 ms  99.068 ms  98.877 ms
10  th2-5-6k.fr.eu (213.251.128.57)  32.925 ms * *
11  gsw-g1-a9.fr.eu (213.186.32.210)  32.047 ms  41.711 ms  41.480 ms
12  rbx-g2-a9.fr.eu (91.121.131.213)  40.572 ms rbx-g2-a9.fr.eu (91.121.215.151)  39.763 ms rbx-g2-a9.fr.eu (91.121.131.213)  35.882 ms
13  vss-9b-6k.fr.eu (178.33.100.74)  114.708 ms * vss-9a-6k.fr.eu (91.121.131.156)  40.098 ms
14   ks3266XXX.kimsufi.com (5.39.79.XXX)  33.112 ms  31.387 ms  37.189 ms

josen
15.05.13, 18:53
Code:
traceroute to ping.ovh.net (213.186.33.13), 30 hops max, 60 byte packets
 1  firewall.local (172.16.1.1)  0.169 ms  0.146 ms  0.138 ms
 2  fritz.box (192.168.178.1)  0.532 ms  1.357 ms  1.450 ms
 3  10.150.192.1 (10.150.192.1)  8.714 ms  9.424 ms  12.640 ms
 4  1211F-MX960-01-ae10-1310.dtm.unity-media.net (80.69.105.81)  44.189 ms  44.625 ms  44.638 ms
 5  1211F-MX960-02-ae0.dtm.unity-media.net (80.69.107.210)  18.915 ms  14.951 ms *
 6  * * *
 7  * 7111A-MX960-01-ae0.fra.unity-media.net (80.69.107.213)  23.674 ms *
 8  * 84-116-131-149.aorta.net (84.116.131.149)  20.074 ms  15.064 ms
 9  84.116.132.193 (84.116.132.193)  19.346 ms de-fra01a-ri2-xe-5-1-1.aorta.net (84.116.133.114)  20.450 ms  20.454 ms
10  * 84.116.132.186 (84.116.132.186)  60.060 ms 84.116.132.178 (84.116.132.178)  19.645 ms
11  4.68.62.237 (4.68.62.237)  20.411 ms  20.407 ms *

Caddy
15.05.13, 10:32
Unitymedia Wuppertal nach OVH (Roubaix 1):
Code:
traceroute to ..tv (87.98.x.x), 30 hops max, 60 byte packets
 1  10.196.192.1 (10.196.192.1)  6.625 ms  6.607 ms  6.603 ms
 2  1214A-MX80-02-ae10-2010.wup.unity-media.net (81.210.131.97)  6.718 ms  6.721 ms  6.717 ms
 3  1214A-MX80-01-ae0.wup.unity-media.net (80.69.107.237)  11.568 ms  11.587 ms  11.600 ms
 4  13NOC-MX960-01-ae2.krp.unity-media.net (80.69.107.73)  12.622 ms  12.635 ms  12.632 ms
 5  7111A-MX960-01-ae8.fra.unity-media.net (80.69.107.25)  16.165 ms  16.172 ms  16.169 ms
 6  * * *
 7  de-fra01a-ri2-xe-5-1-1.aorta.net (84.116.133.114)  15.381 ms  14.723 ms  14.728 ms
 8  84.116.132.178 (84.116.132.178)  14.630 ms  14.150 ms  14.138 ms
 9  4.68.62.237 (4.68.62.237)  14.180 ms  13.636 ms  13.599 ms
10  ae-4-90.edge5.Frankfurt1.Level3.net (4.69.154.201)  13.628 ms  13.060 ms  13.022 ms
11  fra-5-6k.fr.eu (91.121.131.5)  30.971 ms * *
12  rbx-g2-a9.fr.eu (178.33.100.254)  46.776 ms  47.105 ms  47.410 ms
13  rbx-2-6k.fr.eu (91.121.131.9)  46.730 ms * rbx-1-6k.fr.eu (91.121.131.13)  41.356 ms
14  rbx-6-m1.fr.eu (213.251.191.13)  41.951 ms rbx-6-m1.fr.eu (213.251.191.141)  46.390 ms  46.394 ms
15  ..tv (87.98.x.x)  41.227 ms  36.855 ms  35.703 ms
OVH (Roubaix 1) nach Unitymedia Wuppertal:
Code:
traceroute to  (178.200.x.x), 30 hops max, 60 byte packets
 1  rbx-6-m1.fr.eu (87.98.216.253)  0.748 ms  0.928 ms  1.069 ms
 2  rbx-2-6k.fr.eu (213.251.191.130)  33.153 ms * *
 3  rbx-g2-a9.fr.eu (91.121.131.10)  2.464 ms  2.471 ms  2.479 ms
 4  * * fra-5-6k.fr.eu (178.33.100.251)  8.548 ms
 5  tata.as6453.de.eu (213.251.130.106)  8.108 ms  8.148 ms  8.152 ms
 6  if-4-1108.tcore1.FNM-Frankfurt.as6453.net (195.219.156.133)  8.112 ms  8.174 ms  8.166 ms
 7  if-5-2.tcore1.AV2-Amsterdam.as6453.net (195.219.194.13)  20.469 ms  20.655 ms  20.641 ms
 8  if-2-2.tcore2.AV2-Amsterdam.as6453.net (195.219.194.6)  20.623 ms  20.767 ms  20.755 ms
 9  if-7-2.tcore2.L78-London.as6453.net (80.231.152.14)  20.294 ms  20.460 ms  20.693 ms
10  Vlan800.icore2.LDN-London.as6453.net (80.231.131.54)  25.282 ms  25.347 ms  30.674 ms
11  213.46.179.105.aorta.net (213.46.179.105)  28.830 ms  28.834 ms  28.842 ms
12  uk-lon01b-rd1-xe-7-0-0.aorta.net (84.116.133.229)  28.832 ms  28.867 ms  28.924 ms
13  1411g-mx960-02-ae3.neuss.unity-media.net (84.116.131.146)  30.384 ms  30.432 ms  31.758 ms
14  13NOC-MX960-02-ae9.krp.unity-media.net (80.69.107.5)  35.212 ms  35.148 ms  30.337 ms
15  13NOC-MX960-01-ae0.krp.unity-media.net (80.69.107.201)  31.421 ms  31.406 ms  31.198 ms
16  1214A-MX80-01-ae1.wup.unity-media.net (80.69.107.74)  31.489 ms  31.315 ms  31.273 ms
17  PH-1214A-uBR10k-01-Te-1-2-0-1010.wup.unity-media.net (81.210.131.94)  31.412 ms  31.376 ms  31.766 ms
18  ip-178-200-x-x.unitymediagroup.de (178.200.x.x)  36.842 ms  36.817 ms  36.026 ms
UPC Wien nach OVH (Roubaix 1):
Code:
Routenverfolgung zu ..tv [87.98.x.x] über maximal 30 Abschnitte:

1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Zeitüberschreitung der Anforderung.
3 13 ms 12 ms 15 ms 84.116.4.49
4 11 ms 15 ms 12 ms at-vie15a-rd1-vl-2043.aorta.net [84.116.228.129]

5 16 ms 13 ms 11 ms 213.46.173.125
6 16 ms 16 ms 12 ms 213.46.184.6
7 22 ms 44 ms 44 ms prag-bb1-link.telia.net [80.91.245.232]
8 71 ms 31 ms 31 ms ffm-bb1-link.telia.net [213.155.136.134]
9 34 ms 52 ms 32 ms ffm-b10-link.telia.net [80.91.251.120]
10 35 ms 31 ms * fra-5-6k.fr.eu [213.186.32.225]
11 38 ms 44 ms 68 ms rbx-g2-a9.fr.eu [91.121.131.130]
12 78 ms * * rbx-2-6k.fr.eu [91.121.131.9]
13 39 ms 40 ms 40 ms rbx-6-m1.fr.eu [213.251.191.13]
14 56 ms 61 ms 61 ms ..tv [87.98.x.x]
OVH (Roubaix 1) nach UPC Wien:
Code:
traceroute to ..at (213.47.x.x), 30 hops max, 60 byte packets
 1  rbx-6-m1.fr.eu (87.98.216.253)  0.673 ms  0.916 ms  1.125 ms
 2  rbx-2-6k.fr.eu (213.251.191.130)  0.340 ms * *
 3  rbx-g2-a9.fr.eu (91.121.131.10)  0.846 ms  0.911 ms  1.216 ms
 4  * fra-5-6k.fr.eu (178.33.100.255)  33.217 ms *
 5  tata.as6453.de.eu (213.251.130.106)  13.286 ms  13.322 ms  13.351 ms
 6  if-4-1108.tcore1.FNM-Frankfurt.as6453.net (195.219.156.133)  8.334 ms  8.026 ms  8.127 ms
 7  if-7-2.tcore1.FR0-Frankfurt.as6453.net (195.219.50.1)  8.575 ms  8.545 ms  8.842 ms
 8  213.46.179.137.aorta.net (213.46.179.137)  8.352 ms  8.342 ms  8.228 ms
 9  84.116.132.153 (84.116.132.153)  22.137 ms  22.124 ms  21.821 ms
10  84.116.133.117 (84.116.133.117)  27.444 ms  27.324 ms  27.646 ms
11  213-46-160-109.aorta.net (213.46.160.109)  22.242 ms  22.158 ms  22.209 ms
12  at-vie-sk11-pe01-vl-2042.upc.at (84.116.228.126)  22.034 ms  22.186 ms  21.920 ms
13  at-vie-sk11-pe02-vl-1.upc.at (212.17.99.138)  54.034 ms  53.894 ms  53.157 ms
14  chello213047xxxxxx.20.11.vie.surfer.at (213.47.x.x)  61.195 ms  60.225 ms  60.066 ms
Leider routet TATA nach Unitymedia das etwas "wild" :-)

Gruß, Klaus

Laubie
14.05.13, 20:35
kein Problem:

von mir zu euch, erster Versuch:
Code:
traceroute to ping.ovh.net (213.186.33.13), 30 hops max, 60 byte packets
 1  fritz.box (192.168.1.1)  0.623 ms  0.891 ms  1.007 ms
 2  10.204.64.1 (10.204.64.1)  8.125 ms  8.112 ms  12.441 ms
 3  1511G-MX960-01-ae12-1080.bom.unity-media.net (80.69.106.49)  12.739 ms  12.726 ms  12.710 ms
 4  1511G-MX960-02-ae0.bom.unity-media.net (80.69.107.62)  12.973 ms  12.959 ms  12.946 ms
 5  1211F-MX960-02-ae4.dtm.unity-media.net (80.69.107.66)  36.349 ms  36.520 ms  36.506 ms
 6  7111A-MX960-02-ae9.fra.unity-media.net (80.69.107.22)  26.921 ms  17.564 ms *
 7  7111A-MX960-01-ae0.fra.unity-media.net (80.69.107.213)  17.139 ms  17.095 ms  17.259 ms
 8  * * *
 9  84.116.132.193 (84.116.132.193)  22.586 ms  22.576 ms  22.561 ms
10  84.116.132.186 (84.116.132.186)  22.564 ms 84.116.132.178 (84.116.132.178)  14.123 ms  47.942 ms
11  4.68.62.237 (4.68.62.237)  19.105 ms  18.820 ms  19.045 ms
12  * ae-4-90.edge5.Frankfurt1.Level3.net (4.69.154.201)  18.924 ms *
13  * * *
14  * * *
...
30  * * *
2. Versuch:
Code:
traceroute to ping.ovh.net (213.186.33.13), 30 hops max, 60 byte packets
 1  fritz.box (192.168.1.1)  0.623 ms  0.891 ms  1.007 ms
 2  10.204.64.1 (10.204.64.1)  8.125 ms  8.112 ms  12.441 ms
 3  1511G-MX960-01-ae12-1080.bom.unity-media.net (80.69.106.49)  12.739 ms  12.726 ms  12.710 ms
 4  1511G-MX960-02-ae0.bom.unity-media.net (80.69.107.62)  12.973 ms  12.959 ms  12.946 ms
 5  1211F-MX960-02-ae4.dtm.unity-media.net (80.69.107.66)  36.349 ms  36.520 ms  36.506 ms
 6  7111A-MX960-02-ae9.fra.unity-media.net (80.69.107.22)  26.921 ms  17.564 ms *
 7  7111A-MX960-01-ae0.fra.unity-media.net (80.69.107.213)  17.139 ms  17.095 ms  17.259 ms
 8  * * *
 9  84.116.132.193 (84.116.132.193)  22.586 ms  22.576 ms  22.561 ms
10  84.116.132.186 (84.116.132.186)  22.564 ms 84.116.132.178 (84.116.132.178)  14.123 ms  47.942 ms
11  4.68.62.237 (4.68.62.237)  19.105 ms  18.820 ms  19.045 ms
12  * ae-4-90.edge5.Frankfurt1.Level3.net (4.69.154.201)  18.924 ms *
13  * * *
...
30  * * *
und von meinem OVH-Server zu mir:
Code:
traceroute to 176.199.117.xxx (176.199.117.xxx), 30 hops max, 60 byte packets
 1  vss-2-6k.fr.eu (94.23.192.253)  0.549 ms * *
 2  rbx-g1-a9.fr.eu (94.23.122.174)  0.754 ms  1.007 ms  1.118 ms
 3  * * *
 4  * * *
 5  tata.as6453.de.eu (213.251.130.106)  13.915 ms  14.211 ms  14.202 ms
 6  if-12-1656.tcore1.FR0-Frankfurt.as6453.net (195.219.50.89)  8.486 ms if-4-1108.tcore1.FNM-Frankfurt.as6453.net (195.219.156.133)  8.004 ms if-12-1656.tcore1.FR0-Frankfurt.as6453.net (195.219.50.89)  8.363 ms
 7  if-5-2.tcore1.PVU-Paris.as6453.net (80.231.153.121)  15.873 ms if-9-2.tcore1.FR0-Frankfurt.as6453.net (195.219.50.41)  10.993 ms if-7-2.tcore1.FR0-Frankfurt.as6453.net (195.219.50.1)  10.964 ms
 8  if-5-2.tcore1.PVU-Paris.as6453.net (80.231.153.121)  11.317 ms  133.509 ms 80.231.153.98 (80.231.153.98)  11.239 ms
 9  80.231.153.98 (80.231.153.98)  16.233 ms 84.116.134.209 (84.116.134.209)  25.602 ms  11.361 ms
10  * fr-par02a-rd1-ge-6-0.aorta.net (213.46.163.85)  11.613 ms 213.46.163.138 (213.46.163.138)  11.006 ms
11  84.116.133.113 (84.116.133.113)  32.612 ms * 84.116.132.194 (84.116.132.194)  17.978 ms
12  84.116.132.194 (84.116.132.194)  18.073 ms  18.004 ms 84.116.133.113 (84.116.133.113)  32.893 ms
13  7111A-MX960-02-ae0.fra.unity-media.net (80.69.107.214)  32.874 ms  22.911 ms  32.915 ms
14  1211F-MX960-02-ae9.dtm.unity-media.net (80.69.107.21)  23.922 ms  23.840 ms  38.866 ms
15  1511G-MX960-02-ae1.bom.unity-media.net (80.69.107.65)  24.318 ms  24.551 ms  24.418 ms
16  1511G-MX960-02-ae1.bom.unity-media.net (80.69.107.65)  38.849 ms  24.692 ms debom01a-cr08-Te-3-2-0-2080.bom.unity-media.net (80.69.106.54)  38.816 ms
17  ip-176-199-117-xxx.unitymediagroup.de (176.199.117.xxx)  35.348 ms !X debom01a-cr08-Te-3-2-0-2080.bom.unity-media.net (80.69.106.54)  38.643 ms  24.406 ms
und von mir zu meinem server:
Code:
traceroute to xxxxx.de (94.23.192.221), 30 hops max, 60 byte packets
 1  fritz.box (192.168.1.1)  0.574 ms  0.646 ms  0.855 ms
 2  10.204.64.1 (10.204.64.1)  7.091 ms  11.231 ms  11.225 ms
 3  1511G-MX960-01-ae12-1080.bom.unity-media.net (80.69.106.49)  11.600 ms  11.586 ms  11.570 ms
 4  1511G-MX960-02-ae0.bom.unity-media.net (80.69.107.62)  11.555 ms  11.545 ms  11.530 ms
 5  1211F-MX960-02-ae4.dtm.unity-media.net (80.69.107.66)  15.984 ms  15.969 ms  15.954 ms
 6  7111A-MX960-02-ae9.fra.unity-media.net (80.69.107.22)  21.968 ms  14.427 ms  13.830 ms
 7  7111A-MX960-01-ae0.fra.unity-media.net (80.69.107.213)  51.330 ms  51.346 ms  44.511 ms
 8  * * *
 9  de-fra01a-ri2-xe-5-1-1.aorta.net (84.116.133.114)  19.591 ms  19.207 ms  19.206 ms
10  84.116.132.178 (84.116.132.178)  19.542 ms * *
11  4.68.62.237 (4.68.62.237)  19.597 ms  19.466 ms  19.561 ms
12  ae-3-80.edge5.Frankfurt1.Level3.net (4.69.154.137)  16.668 ms * *
13  * * fra-5-6k.fr.eu (91.121.131.5)  30.034 ms
14  rbx-g2-a9.fr.eu (178.33.100.250)  53.096 ms  53.318 ms  49.020 ms
15  vss-2-6k.fr.eu (91.121.131.89)  39.863 ms vss-2b-6k.fr.eu (94.23.122.94)  98.561 ms *
16  server1.xxxx.de (94.23.192.xxx)  33.194 ms  32.055 ms  36.293 ms
Grüße
Laubie

Felix
14.05.13, 16:32
SchwippSchwapp wrote:
> Felix der April ist nun aber auch schon wieder vorbei
>
> gibt es irgendwelche neuigkeiten?


noch keine guten Nachrichten, leider :-/

Wir versuchen derzeit nochmal alles um die Zeit bis zur Fertigstellung des
Peerings seitens UPC [...] moeglichst sauber zu ueberbruecken. Hierzu waere es
hilfreich wenn wir nochmal aktuelle traceroutes von und zu OVH (z.B.
ping.ovh.net) erhalten koennten, und zwar einmal von Kunden aus AT und einmal
aus DE...

Danke vorab

Felix

Eddy
05.05.13, 23:53
was den nun mit den tata links los in ffm ? seit 3 tagen permanent 80-100ms paketlaufzeit

SchwippSchwapp
04.05.13, 09:45
Felix der April ist nun aber auch schon wieder vorbei

gibt es irgendwelche neuigkeiten?

Hook
22.04.13, 22:40
Das kriegen die zum Glück wohl eher nicht genehmigt, also keine Sorge.

Eddy
17.04.13, 19:43
UPC will Kabel Deutschland kaufen

ohje ohje besser das peering gleich auf 100gbit+ laufen lassen :S

kenshin
13.04.13, 01:55
darf man fragen ob die einfach nur zu dumm sind ein paar kabel anzuschliessen und die routen zu konfigurieren oder was bitte dauert da 2+ monate nachdem der papierkram ja doch längst erledigt ist (und man sich zu welchen konditionen auch immer nunmal auf das konnektieren geeinigt hat) ?

Ich verstehe es einfach nicht ;-) Übrigens herzliches Beileid an deine Tischkante

Felix
12.04.13, 13:30
josen wrote:
> kannst du uns eine Perspektive nenen ob und bis wann sich eine
> Verbesserung der Anbindung zu Unitymedia zu erwarten ist?


Momentan sieht es so aus als wäre die Interconnection auf jeden Fall vor Ende
April fertig, die ganze Angelegenheit hat etwas neuen Schwung aufgenommen da
wir seitens UPC einen anderen, etwas reaktiveren Ansprechpartner haben

Jedoch bin ich nach dem bisherigen Verlauf auch etwas vorsichtiger geworden,
und wuerde ungern meine Hand dafuer ins Feuer legen :-/

Jusic
11.04.13, 19:08
Sehr merkwürdig @Eddy

1 <1 ms <1 ms <1 ms OpenWrt.lan [192.168.1.1]
2 57 ms 77 ms 60 ms 10.153.128.1
3 19 ms 22 ms 64 ms 1311A-MX960-01-ae15-1010.*.unity-media.net [81.210.130.165]
4 60 ms 36 ms 85 ms 1411C-MX960-02-ae1.mhm.unity-media.net [80.69.107.85]
5 30 ms 27 ms 86 ms 1411C-MX960-01-ae0.mhm.unity-media.net [80.69.106.169]
6 75 ms 58 ms 57 ms 13NOC-MX960-02-ae3.krp.unity-media.net [80.69.107.81]
7 81 ms 45 ms 30 ms 13NOC-MX960-01-ae0.krp.unity-media.net [80.69.107.201]
8 29 ms 40 ms 30 ms 7111A-MX960-01-ae8.fra.unity-media.net [80.69.107.25]
9 * * 52 ms 84-116-131-149.aorta.net [84.116.131.149]
10 33 ms 33 ms 27 ms 84.116.132.193
11 32 ms 79 ms 53 ms 84.116.132.178
12 43 ms 83 ms 69 ms 213.46.179.194.aorta.net [213.46.179.194]
13 181 ms 68 ms 27 ms ffm-bb1-link.telia.net [213.155.133.140]
14 23 ms 31 ms 45 ms ddf-b2-link.telia.net [213.155.135.93]
15 50 ms * 38 ms myloc-ic-141049-ddf-b2.c.telia.net [213.248.81.58]
16 49 ms 40 ms 128 ms xe92-dus1-v4-cisip.dus2-de.myloc.de [62.141.47.110]
17 61 ms 27 ms 40 ms *.zebra.fastwebserver.de [*.*.*.*]

Andersrum

1 5.104.106.1 (5.104.106.1) 0.429 ms 0.429 ms 0.455 ms
2 xe15-dus2-v4-brip.dus1-de.myloc.de (62.141.47.105) 0.302 ms 0.321 ms 0.310 ms
3 * * *
4 1411G-MX960-02-ae0.nss.unity-media.net (80.69.107.206) 6.212 ms 6.226 ms 6.149 ms
5 13NOC-MX960-02-ae9.krp.unity-media.net (80.69.107.5) 5.758 ms 5.770 ms 5.761 ms
6 1411C-MX960-01-ae1.mhm.unity-media.net (80.69.107.82) 6.300 ms 6.553 ms 6.543 ms
7 1411C-MX960-02-ae0.mhm.unity-media.net (80.69.106.170) 6.533 ms 6.533 ms 6.442 ms
8 1311A-MX960-01-ae1.*.unity-media.net (80.69.107.86) 6.758 ms 6.682 ms 6.730 ms
9 PH-1311A-uBR10k-01-Te-1-2-0-1010.*.unity-media.net (81.210.130.166) 6.602 ms 6.616 ms 6.593 ms
10 *.unitymediagroup.de (*.*.*.*) 28.022 ms 43.418 ms 67.360 ms

josen
11.04.13, 18:52
Hallo Felix,

kannst du uns eine Perspektive nenen ob und bis wann eine Verbesserung der Anbindung zu Unitymedia zu erwarten ist?

Ich würde aufgrund eurer Verwaltungswerkzeuge gern bei euch bleiben, aber selbst eher budgetorientierte Kunden wollen jetzt weg und sind bereit Migrationskosten zu tragen.

Grüße

Eddy
09.04.13, 15:09
Zitat Zitat von Jusic
Ich glaube UPC ist schlicht noch nicht fertig mit der Verschlimmbesserung Ihres Routings. Bis vor einem Monat hat Unitymedia noch mit myLoc/Webtropia direkt am ECIX in Düsseldorf gepeert, ich hatte Pingzeiten von 6-8ms. Jetzt läuft das auch alles über FFM -> aorta.net -> Arsch der Welt.

3 7111A-MX960-02-ae10-2410.fra.unity-media.net (81.210.130.21) 11.103 ms 11.017 ms 10.931 ms
4 1211F-MX960-02-ae9.dtm.unity-media.net (80.69.107.21) 17.807 ms 17.737 ms 17.780 ms
5 1211F-MX960-01-ae0.dtm.unity-media.net (80.69.107.209) 17.576 ms 17.619 ms 17.410 ms
6 1411G-MX960-01-ae8.nss.unity-media.net (80.69.107.9) 18.979 ms 17.671 ms 17.571 ms
7 xe1-ecix-v4.dus4-de.myloc.de (194.146.118.11) 23.157 ms 23.401 ms 23.107 ms
8 62.141.47.202 (62.141.47.202) 20.808 ms 30.210 ms 29.980 ms
9 webtropia.com (217.79.176.131) 20.208 ms 19.320 ms 25.450 ms

zurück

1 xe0-spts-v4.dus1-de.myloc.de (62.141.47.65) [AS24961] 8.116 ms 8.182 ms 8.447 ms
2 * * *
3 1211F-MX960-01-ae8.dtm.unity-media.net (80.69.107.10) [AS20825] 8.134 ms 8.107 ms 8.157 ms
4 1211F-MX960-02-ae0.dtm.unity-media.net (80.69.107.210) [AS20825] 7.195 ms 7.213 ms 7.231 ms
5 7111A-MX960-02-ae9.fra.unity-media.net (80.69.107.22) [AS20825] 6.985 ms 6.994 ms 7.006 ms

bei mir zumindest ecix

mich wundert nur, das von mir aus gesehen der ping von ffm nach dortmund um 6ms zunimmt, wo er auf dem rückweg dies nicht tut

Jusic
09.04.13, 09:48
Ich glaube UPC ist schlicht noch nicht fertig mit der Verschlimmbesserung Ihres Routings. Bis vor einem Monat hat Unitymedia noch mit myLoc/Webtropia direkt am ECIX in Düsseldorf gepeert, ich hatte Pingzeiten von 6-8ms. Jetzt läuft das auch alles über FFM -> aorta.net -> Arsch der Welt.

strex
08.04.13, 21:34
Da hat wohl einer vergessen den Stecker zu ziehen

Eddy
08.04.13, 18:49
Richtig, mich wunderts aber warum sie beim ecix nicht auch depeered sind mit Unitymedia wie sie es UPC bei den anderen getan haben.

Verschiedene andere hoster die ich getested habe, die ein peering am ecix haben laufen auch über diese zu UM.

scheint nicht Selective zu sein

strex
08.04.13, 18:43
Zitat Zitat von Eddy
Gerade auf der ECIX seite gelesen, wo UM noch ein 80gbits peering hat.
Das heißt aber noch lange nicht, auch wenn du dort vertreten bist, UM/LGI/UPC mit dir ein PNI betreiben möchte. Nur weil du da ein Port hast, tauscht du mit den anderen noch lange nicht den Traffic aus. Zumal UPC wie auch die DTAG ja gerne Geld sieht

gerry
08.04.13, 18:25
Zitat Zitat von Eddy
Gerade auf der ECIX seite gelesen,

100GE Presence in Frankfurt

Nur 5k mtl. für nen 100G Port?
Mal schauen was das dann beim DE-CIX kosten soll.

Eddy
08.04.13, 17:31
Gerade auf der ECIX seite gelesen, wo UM noch ein 80gbits peering hat. PeeringDB UM Record

100GE Presence in Frankfurt


Wäre doch ne gute alternative

marius
07.04.13, 18:57
Zitat Zitat von Eddy
Ob das evtl bei UPC funktionieren würde Link

Wir hatten diese "Traffic Manipulation: Increase Peer Transit Load" Taktik vor Jahren mal erfolgreich durchgezogen und erreichten dadurch ein Peering.
Mit wem bloß

Hook
07.04.13, 12:56
Das funktioniert, sofern man genug Traffic hat (ist bei OVH vmtl. gegeben) und man weiß, welcher Carrier UPC richtig Geld kostet.
Aber auch dann gibts noch Möglichkeiten, die Bandbreite zu begrenzen, die von OVH reinkommt. Und dann wären wir wieder beim oben angesprochenen Problem. :/

Eddy
07.04.13, 12:30
Ob das evtl bei UPC funktionieren würde Link

Hook
07.04.13, 03:28
Weder ist die Netzneutralität vorgeschrieben, noch gibt es Richtlinien dafür. Die Telekom macht es aktuell ja gerade vor, wie man den Rest an Netzneutralität auch noch komplett aushebelt (Traffic für eigene Dienste wie Home Entertain oder auch für Spotify wird nicht berechnet, restliches Internet max. 300GB pro Monat).
Peeren kann man praktisch mit wem man will, oder eben auch nicht, und damit auch (indirekt) drosseln wen man will. Dann müssen die Daten nämlich unnötige Umwege nehmen, wodurch es meistens auch langsamer wird. Dadurch kann sich der ISP zumindest etwas die eigenen vorhandenen Leitungen entlasten und/oder effektiver nutzen. Prinzip der Gewinnmaximierung.
Oder man geht absichtlich kein Peering mit jemandem ein und lässt denjenigen einfach ein bisschen zappeln. Die Kunden vom Serverhoster beschweren sich dann (es liegt natürlich nicht an der eigenen Internetleitung, weil von woanders gehts ja), und rennen dem Hoster davon. Der Hoster will natürlich keine Kunden verlieren, und ist evtl. auch bereit mehr zu zahlen, damit das Peering sofort zustande kommt und alles wieder schnell läuft. Der ISP freut sich und kriegt zusätzlich zum Geld seiner eigenen Kunden noch Geld vom Rechenzentrum (wird von großen ISP's manchmal so gemacht).

Noch dazu haben einige große Provider (wie auch UPC) sehr restriktive Peering-Regeln, so muss i.d.R. auch immer ein Ratio eingehalten werden oder es muss an mehreren Standorten gepeert werden, um überhaupt ein Peering zu erhalten.
Mindest-Traffic, was manche vorschreiben ist zwischen OVH und UPC denke ich eher kein Problem.
Beispielsweise muss dann, um das Ratio einhalten zu können, für 1TB Traffic was ins Netz des Providers geht, auch 300GB abgenommen werden. Da UPC aber hauptsächlich ein ISP ist, frage ich mich immer wieder wie z.B. OVH als Serverhoster so viele Daten von UPC Kunden erhalten soll ...
Wenn jemand einen Dienst kennt (außer Filesharing) bei dem die User aktiv etwas hochladen müssen und dies dann nur von max. 3 anderen Leuten heruntergeladen/empfangen wird, immer her mit den Ideen!
Kann das Ratio aber nicht eingehalten werden (was bei Serverhostern ja i.d.R. der Fall ist weil einfach die Upload-Bandbreite vom Kunden nicht da ist und es einfach keine entsprechenden Dienste gibt) oder auch nur weil der ISP grade Lust drauf hat oder mehr Geld haben will, müssen Serverhoster an den ISP nicht unerhebliche Summen zahlen. Das kann auch schnell in den Euro-Bereich pro MBit Bandbreite reichen! Das sind bei 10GBit dann also auch schnell mal über 20k Euro pro Monat.
Aber so ist das nun mal, die großen Provider können sich das ja erlauben, sie haben genug Kunden die sich dann beim Serverhoster beschweren wenns nicht läuft wie es soll.

Von der technischen Seite her kann ich mir auch nicht vorstellen dass es an OVH liegt, immerhin werden da die Leitungen regelmäßig erweitert (wenn man der weathermap vertraut). Peerings hat OVH auch genug, einfach nen weiteres Peering dazuzuschalten ist denke ich auch kein Problem. UPC hat sicherlich in einigen Gebäuden Leitungen liegen in denen OVH auch irgendwie vertreten ist.

Und natürlich ist das alles meine eigene Meinung und soll nicht gegen die großen Provider aufhetzen.

Eddy
06.04.13, 19:17
normal müsste man UPC die ganzen Transit kosten über TATA nun in rechnung stellen bei den verzögerungen ihrer seits

Felix
06.04.13, 19:00
strex wrote:
> Es scheitert ja nicht an der technischen Umsetzung


Doch, angeblich schon...

Bis das alles endlich funktioniert werde ich eine neue Tischkante brauchen.

Eddy
06.04.13, 17:29
Ich mein mal wo gelesen zuhaben, das peerings nur 1mal pro monat bearbeitet werden bei UPC.


wenn das verkabelungsproblem nun behoben ist, müsste es also theoretisch diesen Monat ja dann klappen

strex
06.04.13, 16:55
Zitat Zitat von Eddy
Laut diesem Post hir http://forum.ovh.de/showpost.php?p=70460&postcount=112

scheint es doch ein techniches problem zu sein ?
Das hätte man sicher zeitnah realisieren können, wenn man möchte

sting
06.04.13, 16:40
Peering + UPC != einfach ... leider

Direktes Peering mit UPC gäbe es z.B. auch in Wien, siehe hier: http://weathermap.ovh.net/wien

Ich sehe da laut Grafik auch immer Traffic drüberfließen...meine Kunden aus Wien werden allerdings wie folgt geroutet:

Einmal von UPC zu OVH:
Code:
 
  3    10 ms    30 ms    11 ms  84.116.6.129 
  4    15 ms    11 ms    13 ms  at-vie01a-rd1-vl-2018.aorta.net [84.116.228.29] 
 
  5    16 ms    19 ms    20 ms  at-vie05b-ri2-xe-3-2-0.aorta.net [213.46.173.117 
] 
  6    43 ms    76 ms    21 ms  213.46.184.6 
  7    23 ms    24 ms    21 ms  prag-bb1-link.telia.net [80.91.245.232] 
  8    69 ms    58 ms    37 ms  ffm-bb1-link.telia.net [80.91.246.136] 
  9    35 ms    30 ms    29 ms  ffm-b10-link.telia.net [80.91.251.120] 
 10     *       30 ms     *     fra-5-6k.fr.eu [213.186.32.225] 
 11    39 ms    37 ms    40 ms  rbx-g2-a9.fr.eu [91.121.131.130]
Und von OVH zu UPC:
Code:
 2  rbx-g2-a9.fr.eu (178.33.100.89)  1.709 ms  1.890 ms  1.970 ms
 3  * fra-5-6k.fr.eu (91.121.131.202)  8.854 ms *
 4  tata.as6453.de.eu (213.251.130.106)  22.031 ms  22.042 ms  22.047 ms
 5  if-12-1656.tcore1.FR0-Frankfurt.as6453.net (195.219.50.89)  11.932 ms if-4-1108.tcore1.FNM-Frankfurt.as6453.net (195.219.156.133)  8.955 ms if-12-1656.tcore1.FR0-Frankfurt.as6453.net (195.219.50.89)  11.940 ms
 6  213.46.179.137.aorta.net (213.46.179.137)  11.912 ms if-9-2.tcore1.FR0-Frankfurt.as6453.net (195.219.50.41)  10.173 ms 213.46.179.137.aorta.net (213.46.179.137)  10.015 ms
 7  213.46.179.137.aorta.net (213.46.179.137)  9.988 ms  7.364 ms  13.059 ms
 8  84.116.132.145 (84.116.132.145)  30.064 ms  28.546 ms 84.116.133.117 (84.116.133.117)  23.502 ms
 9  84.116.133.117 (84.116.133.117)  22.205 ms  23.579 ms at-vie01a-rd1-xe-4-0-0.aorta.net (213.46.160.101)  41.556 ms
10  84.116.228.30 (84.116.228.30)  23.842 ms * *
Geschwindigkeit natürlich im Keller - warum geht der Traffic hier nicht den direkten Weg übers Peering in Wien?

Eddy
06.04.13, 16:36
Laut diesem Post hir http://forum.ovh.de/showpost.php?p=70460&postcount=112

scheint es doch ein techniches problem zu sein ?

strex
06.04.13, 16:34
Zitat Zitat von Eddy
Könnte man nicht temporär, bis das mit FFM geklärt ist nicht einfach in Frankreich ein peering mit UPC für UM Kunden errichten ?
Es scheitert ja nicht an der technischen Umsetzung, wenn das Management kein Peering in DE will, dann sicher auch nicht in Frankreich.

Eddy
06.04.13, 15:59
Könnte man nicht temporär, bis das mit FFM geklärt ist nicht einfach in Frankreich ein peering mit UPC für UM Kunden errichten ?

Traffic muss ja so oder so von Frankreich -> Deutschland, so kann man ihn auch gleich in Frankreich übergeben.

wird zwar für die SPB kunden etwas höhere pings ergeben und für die nach USA, aber über die transits ist es ja auch nicht optimal z.zt

Telehouse Paris 2 (Voltaire) gibts sowohl Liberty Global (UPC) als auch OVH

Caddy
02.04.13, 08:06
Zitat Zitat von danielsan2000
Also Probleme mit "dem großen roten H" kann ich ebenfalls (vor mir aus auch "noch") nicht nachvollziehen. Volle Geschwindigkeit aus allen Ecken Deutschlands und zu jeder Uhrzeit.
Das kann ich zumindest überhaupt nicht nachvollziehen. Die Latenzen sind meistens zwar weitaus besser als bei OVH (noch), aber ein Tag beim "großen roten H" sieht aus Sicht eines Unitymedia Anschlusses derzeit nämlich ganz anders aus.

Die letzten 30 Stunden nach "H" (das wiederholt sich täglich):
http://s1.directupload.net/images/130402/scwpfkzf.png

Die Tendenz zu "H":
http://s1.directupload.net/images/130402/uq9ivtil.png

Die Tendenz von OVH dagegen:
http://s1.directupload.net/images/130402/skfov3hq.png

Das "H" ist nicht gerade vielversprechend, oder?

Gruß, Klaus

danielsan2000
01.04.13, 11:35
Also Probleme mit "dem großen roten H" kann ich ebenfalls (vor mir aus auch "noch") nicht nachvollziehen. Volle Geschwindigkeit aus allen Ecken Deutschlands und zu jeder Uhrzeit. Wenn meine Vorrauszahlung diesen Monat ausläuft, ist dann auch der letzte OVH Server meinerseits weg. Da den Worten hier seit Monaten keine Taten folgen, gehe ich mal davon aus, dass OVH keine UPC Kunden mehr "bedienen" wird. Schade.
Dennoch schöne Ostern allen Leidensgenossen hier.

Eddy
31.03.13, 16:31
hehe init7 und UPC da gibts paar schöne beiträge in einem Blog

strex
31.03.13, 14:21
Zitat Zitat von bene
@strex: Deine Meinung zu upc in Ehren. Dennoch treten die Probleme so extrem NUR bei OVH auf.
Komischerweise schaffen es alle anderen Anbieter eine Lösung mit upc zu finden.
Dann geb im Hetzner Forum einmal "UPC" ein, genau so schlecht und desöfteren mit PacketLoss verbunden. (z.B. http://forum.hetzner.de/wbb2/thread....69&hilight=upc) Auch dort geht das Routing entweder über Level3 oder init7, beim letzteren hast du wirklich pech, da noch schlechter.

Code:
Routenverfolgung zu ts.esetec.eu 
[78.46.221.121] über maximal 30 Abschnitte: 
1 <1 ms <1 ms <1 ms fritz.box [192.168.1.1] 
2 11 ms 7 ms 8 ms 10.139.64.1 
3 15 ms 67 ms 10 ms 1211F-MX960-02-ae12-1090.dtm.unity-media.net [80.69.106.109] 
4 21 ms 13 ms 12 ms 1511G-MX960-02-ae1.bom.unity-media.net [80.69.107.65] 
5 10 ms 10 ms 16 ms 1511G-MX960-01-ae0.bom.unity-media.net [80.69.107.61] 
6 13 ms 10 ms 14 ms 1415A-MX960-01-ae1.ess.unity-media.net [80.69.107.57]
7 30 ms 32 ms 29 ms uk-lon01b-rd1-ae-1.aorta.net [84.116.131.145]
8 54 ms 56 ms 55 ms 84.116.137.62
9 52 ms 53 ms 54 ms 84.116.135.213 
10 * * * Zeitüberschreitung der Anforderung. 
11 66 ms 56 ms 67 ms r1fra1.core.init7.net [77.109.128.101] 
12 57 ms 55 ms 63 ms r1fra3.core.init7.net [77.109.128.222] 
13 56 ms 60 ms 59 ms r1nue2.core.init7.net [77.109.140.54] 
14 55 ms 60 ms 61 ms r1nue1.core.init7.net [77.109.140.153] 
15 132 ms 61 ms 58 ms gw-hetzner.init7.net [77.109.135.102] 
16 * * * Zeitüberschreitung der Anforderung. 
17 63 ms 63 ms 59 ms hos-tr3.ex3k6.rz16.hetzner.de [213.239.223.199] 
18 * * * Zeitüberschreitung der Anforderung. 
19 61 ms 57 ms 62 ms ts.esetec.eu [78.46.221.121]
Quelle: http://forum.hetzner.de/wbb2/thread....50&hilight=upc

marius
30.03.13, 22:11
Zitat Zitat von bene

Zu dem bekannten Serveranbieter mit dem grossen roten H habe ich zum Beispiel keine Probleme...

Korrektur:
Zu dem Anbieter mit dem roten H hast du im Moment keine Probleme.
Ein Peering mit LGI haben die nämlich auch (noch) nicht, und das Routing verläuft genauso wie zu OVH auch über Level3.
Zu Stoßzeiten ist die Geschwindigkeit da auch sehr schlecht, und vorhin hatte ich als Unitymedia Kunde beispielsweise auch eine Reaktionszeit von >80ms zu deren Server.

bene
30.03.13, 19:14
@strex: Deine Meinung zu upc in Ehren. Dennoch treten die Probleme so extrem NUR bei OVH auf.
Komischerweise schaffen es alle anderen Anbieter eine Lösung mit upc zu finden.

Zu dem bekannten Serveranbieter mit dem grossen roten H habe ich zum Beispiel keine Probleme...

Code:
--2013-03-30 19:10:24--  http://213.133.107.227/100MB.iso
HTTP request sent, awaiting response... 200 OK
Length: 104840234 (100M) [application/x-iso9660-image]
Saving to: `100MB.iso'

100%[======================================>] 104,840,234 1.73M/s   in 70s

2013-03-30 19:11:34 (5.43 MB/s) - `100MB.iso' saved [104840234/104840234]

strex
30.03.13, 18:06
Google nach UPC+LGI+Peering..da findest genug. Kurz gesagt, UPC ist einfach Käse und davon sollte man einen großen Bogen machen. Mich wundert es, dass UPC nicht schon bei allen den Zugang zum Internet abgeschaltet hatte.

h0nd
30.03.13, 17:57
Warum? Nicht, dass es eine Überraschung wäre. Aber ich habe, was das Internet betrifft, mehr als 10 Jahre gute Erfahrungen mit Cablecom gemacht und hatte nie vergleichbare Vorfälle - nur eben mit OVH.

kenshin
30.03.13, 16:04
Zitat Zitat von h0nd
Guten Tag ich habe einen 100Mbit Server von OVH und eine 75MBit Leitung der UPC Cablecom.

Mein Durchsatz liegt bei ~350KB/s. Wo ist das Problem?
Beim fettmarkierten.

h0nd
30.03.13, 15:41
Guten Tag ich habe einen 100Mbit Server von OVH und eine 75MBit Leitung der UPC Cablecom.

Mein Durchsatz liegt bei ~350KB/s. Wo ist das Problem?

Felix
21.03.13, 19:00
danielsan2000 wrote:
> oder das es jeden Moment eine Änderung geben wird, aber man möchte "den Tag
> nicht vor dem Abend loben"?


Das da.

danielsan2000
21.03.13, 16:24
Schade das hier nun schon seit Wochen seitens OVH Stille herrscht. Heißt das die Sache wird vorläufig so wie so nichts oder das es jeden Moment eine Änderung geben wird, aber man möchte "den Tag nicht vor dem Abend loben"?

josen
19.03.13, 15:18
Hallo,

gestern nur 10Mbit/sec Download von OVH, gegen circa 23 Uhr. Die ersten elf Server von Kunden sind von OVH abgezogen.

Sehr schade, eigentlich hat mir OVH immer gefallen. Aber wenn andere billiger und besser für die Kundenanforderungen sind und das sogar mit Umzugskosten eingerechnet, hat man keine Wahl.

Grüße

Caddy
19.03.13, 14:45
Yep, gestern war es leider wieder einmal sehr schlimm. Die TATA Links am fra-5-6k waren während der Zeit auch quasi voll ausgelastet. Dazu kommt leider auch, dass bei den Umbauarbeiten am Netz von OVH auch alles nicht so glatt gelaufen ist, wie es geplant war. Letzteres ist zwar alles erklärbar, für mich persönlich auch kein Problem, wenn es aber die ohnehin schon genervten UPC / Unitymedia Kunden trifft, ist das nicht mehr so toll...

Es wäre nun total toll, wenn ihr irgendwie die letzten 50 Meter hin bekommt :-)

Gruß, Klaus

danielsan2000
19.03.13, 12:12
Dem kann ich mich nur anschließen Eddy :-(

Ende des Monats werde ich dann auch meine beiden anderen OVH Server abziehen. Ist sehr schade und ärgerlich.

Eddy
18.03.13, 20:44
4 7 8 9 ms 7111A-MX960-01-ae0.fra.unity-media.net [80.69.10
7.213]
5 7 9 ms 8 ms 84-116-131-149.aorta.net [84.116.131.149]
6 7 ms 11 ms 8 ms 84.116.132.193
7 13 ms 7 ms 9 ms 84.116.132.186
8 9 ms 13 ms 11 ms 213.46.179.194.aorta.net [213.46.179.194]
9 7 ms 8 ms 20 ms ffm-bb2-link.telia.net [80.91.246.218]
10 8 ms 8 ms 17 ms ffm-b10-link.telia.net [80.91.251.124]
11 95 ms 107 ms 103 ms fra-5-6k.fr.eu [213.186.32.225]
12 129 ms 301 ms 96 ms rbx-g2-a9.fr.eu [178.33.100.254]
13 257 ms 92 ms 96 ms vss-6a-6k.fr.eu [91.121.128.40]
14 93 ms 94 ms 91 ms ns******.ovh.net [176.31.*.*]


danielsan2000
13.03.13, 09:42
Morgen Felix! Was machen die letzten 50 Meter? :-)

Eddy
05.03.13, 20:41
Zitat Zitat von marius
Woher hasst du denn die Info, dass das PNI mit LGI in FFM realisiert wird?
na hir aus dem thread http://forum.ovh.de/showpost.php?p=70153&postcount=52

marius
05.03.13, 20:37
Zitat Zitat von Eddy
UPC nichtmal in einem der 2 RZ in FFM anwesend, wo ihr euer equipment stehen habt ?

Naja was wundert es mich, bei der komischen peering policy muss man auch nirgends anwesend sein
Woher hasst du denn die Info, dass das PNI mit LGI in FFM realisiert wird?

danielsan2000
05.03.13, 20:09
Das sind doch schon mal gute News!

Eddy
05.03.13, 17:24
UPC nichtmal in einem der 2 RZ in FFM anwesend, wo ihr euer equipment stehen habt ?

Naja was wundert es mich, bei der komischen peering policy muss man auch nirgends anwesend sein

Felix
05.03.13, 17:18
Felix wrote:
> Mehr News hoffentlich in Kuerze.


Es liegt jetzt nur noch an der Verbindung fuer die letzten (geschaetzt) 50
Metern zwischen 2 Gebaeuden... Und bitte sag jetzt keiner "WLAN"

danielsan2000
05.03.13, 13:32
Joa, leider tut sich scheinbar nicht viel. Oder in sehr kleinen Schritten.
Ich musste nun den ersten Server leider schon zur Konkurrenz shiften, da ich scheinbar viele Uniytimedia Nutzer im Kundenkreis habe und entsprechend schlechtes Feedback bekomme. Ich hoffe dass noch im März etwas spürbar wird, sonst muss es leider im April mit den anderen Servern weitergehen :-/

SchwippSchwapp
03.03.13, 00:30
wie schauts nun aus? auf der weathermap sind 2 neue TATA links in frankfurt seit einigerzeit und nun sind sie in betrieb. Ist das schon die änderung oder kommt da noch ein extra UPC/unity peering hinzu?

ich werd nächsten monat den unitymedia anschluss für meine neue wohnung bestellen und hoffe deshalb auf eine gute verbindung von ovh zu unitymedia.

Caddy
26.02.13, 23:00
Nun ist zumindest eine Antwort von Unitymedia da, die ich ungefähr so in kurze Worte fasse: "... wird sich ab März 2013 eine spürbare Besserung ergeben", man bittet aber um Verständnis, dass man auf weitere technische Details nicht eingehen kann.

Das deckt sich ja schon fast mit der Aussage von Felix ... "in Kürze".

LG, Klaus

strex
26.02.13, 15:46
Das werden die sicher net machen, erstens passt es zu der Peering Policies von LGI nicht und zweitens hätten Sie dann sicher die Links auch nicht beendet. Bitte glaubhaft bleiben, dass Thema haben wir doch jetzt schon zig mal diskutiert.

Eddy
26.02.13, 15:12
anstatt einem PNI, koennte man ja auch versuchen sie zu überreden das decix peering richtung ovh zu öffnen

Caddy
26.02.13, 14:18
Zitat Zitat von Felix
... aber das der Stein wieder ins Rollen
gekommen ist und sich in die richtige Richtung bewegt.
Ich bin sehr gespannt. Meine Anfrage bei Unitymedia schlummert noch in der Fachabteilung... Vielleicht schlummern da noch mehr und man ist dort wach geworden?

Danke für den Status zwischendurch :-)

Gruß, Klaus

danielsan2000
26.02.13, 11:32
Alles klar, danke für die Info!

Felix
26.02.13, 11:22
danielsan2000 wrote:
> Wars ein Fehlalarm? Hier tut sich leider nichts :-/


wohl eher ein Missverstaendnis... mit "es bewegt sich was" wollte ich nicht
sagen das das PNI schon fertig ist, aber das der Stein wieder ins Rollen
gekommen ist und sich in die richtige Richtung bewegt.

danielsan2000
26.02.13, 11:14
Hi Felix! Die Daumen werden blau ;-)

Wars ein Fehlalarm? Hier tut sich leider nichts :-/

Felix
25.02.13, 19:32
Felix wrote:
> Von unserer Seite ist alles bereit, der ganze Papierkram ist erledigt und wir
> warten nur auf die technische Umsetzung seitens UPC. Diese scheint jedoch trotz
> inzwischen täglicher Erinnerungen von unserer Seite nicht voranzuschreiten...


Es bewegt sich etwas... Es dürfen Daumen gedrückt werden, aber die Luft
anhalten werde ich nicht solange

Mehr News hoffentlich in Kuerze.

Marya
20.02.13, 22:49
Im Ticket steht, dass in Katzenelnbogen (~50km westlich von FFM) die Glasfaser nach Frankfurt durchtrennt wurde. Vor einer Stunde wurde die betreffende Sektion des Kabels vor Ort lokalisiert.

Offenbar ist das Routing von OVH zusammengebrochen. Vorhin waren zeitweise nur noch die Routen nach Paris (und ein paar kleine andere) verfügbar und die Pakete, die nicht gedroppt wurden, wurden teilweise im Kreis geroutet.

danielsan2000
20.02.13, 20:27
Dem kann ich mich nur anschließen - ich kann (sitze selbst in Frankfurt) kaum noch auf irgendetwas von OVH zugreifen. Da erscheinen die 300kb/sek der letzen Wochen tatsächlich als schnell... :-/ Wann wird das Problem behoben sein?

Marya
20.02.13, 17:46
In dem Ticket steht Frankfurt-Brüssel!?

Edit: In Frankfurt scheint's der Weathermap nach tatsächlich einen (nahezu) Komplettausfall zu geben.

Caddy
20.02.13, 17:36
Durch den Ausfall der Verbindungen zwischen Roubaix und Frankfurt gehen die Routen derzeit andere Wege. An der Latenz wird sich erst wieder was ändern, wenn Frankfurt repariert ist Was wir jetzt sehen, sind Notfall-Lösungen.

Siehe http://travaux.ovh.net/?do=details&id=8099

Gruß, Klaus

Eddy
20.02.13, 17:35
Ist ja interessant.

Bei mir ist der Speed gut.

Download Speed: 66360 kbps (8295 KB/sec transfer rate)
Upload Speed: 5140 kbps (642.5 KB/sec transfer rate)

mehr geht nicht zumindest im Download

Ping ist natürlich durch die route nicht optimal aber das war er vorher ja nun auchnicht.

Wird aber wohl nur temporär so sein wegen dem Ausfall.

Marya
20.02.13, 17:25
Über Level 3 gehen bei mir die Pakete von UM in Richtung OVH.

marius
20.02.13, 17:21
Bei mir geht das nach wie vor über Level3.

Marya
20.02.13, 17:18
Bei mir hat sich, nach einem kurzen Komplettausfall der OVH-Route, das Routing ins UM-Netz geändert. Sieht nach dem UPC-Peering aus, das wohl in Polen stattfindet. Latenz und Durchsatz sind noch verbesserungswürdig:

Code:
 1  vss-9a-6k.fr.eu (5.39.94.253)  2.944 ms * *
 2  rbx-g2-a9.fr.eu (91.121.131.157)  1.108 ms  1.113 ms  1.393 ms
 3  ams-5-6k.nl.eu (178.33.100.237)  5.598 ms * ams-5-6k.nl.eu (178.33.100.231)  5.594 ms
 4  * * var-1-6k.pl.eu (91.121.131.246)  29.215 ms
 5  upc.as9141.pl.eu (213.251.130.70)  29.113 ms  29.127 ms  29.099 ms
 6  84.116.135.229 (84.116.135.229)  32.967 ms  33.356 ms 84.116.135.198 (84.116.135.198)  32.264 ms
 7  84.116.136.189 (84.116.136.189)  33.341 ms 84.116.134.193 (84.116.134.193)  32.949 ms 84.116.136.189 (84.116.136.189)  33.339 ms
 8  de-fra01a-ri2-xe-2-0-1.aorta.net (84.116.133.98)  32.827 ms  33.197 ms 84.116.133.117 (84.116.133.117)  35.074 ms
 9  84.116.132.162 (84.116.132.162)  33.179 ms  33.463 ms 84.116.132.194 (84.116.132.194)  32.288 ms
10  84-116-131-150.aorta.net (84.116.131.150)  32.003 ms  32.119 ms  34.267 ms
...
Code:
PING 95.223.0.* (95.223.0.*) 56(84) bytes of data.
64 bytes from 95.223.0.*: icmp_req=1 ttl=48 time=41.0 ms
64 bytes from 95.223.0.*: icmp_req=2 ttl=48 time=43.7 ms
64 bytes from 95.223.0.*: icmp_req=3 ttl=48 time=43.9 ms
64 bytes from 95.223.0.*: icmp_req=4 ttl=48 time=45.2 ms
64 bytes from 95.223.0.*: icmp_req=5 ttl=48 time=50.1 ms
64 bytes from 95.223.0.*: icmp_req=6 ttl=48 time=49.0 ms
64 bytes from 95.223.0.*: icmp_req=7 ttl=48 time=38.1 ms
64 bytes from 95.223.0.*: icmp_req=8 ttl=48 time=54.0 ms
64 bytes from 95.223.0.*: icmp_req=9 ttl=49 time=42.4 ms
64 bytes from 95.223.0.*: icmp_req=10 ttl=49 time=42.9 ms

--- 95.223.0.* ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9011ms
rtt min/avg/max/mdev = 38.135/45.072/54.002/4.474 ms
Code:
------------------------------------------------------------
Server listening on TCP port 3333
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.1.133 port 3333 connected with 5.39.94.* port 56220
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.5 sec  20.8 MBytes  16.7 Mbits/sec
[  5] local 192.168.1.133 port 3333 connected with 5.39.94.* port 56221
[  5]  0.0-10.4 sec  21.5 MBytes  17.4 Mbits/sec
[  4] local 192.168.1.133 port 3333 connected with 5.39.94.* port 56222
[  4]  0.0-10.5 sec  20.6 MBytes  16.4 Mbits/sec

strex
18.02.13, 12:00
Wahrscheinlich werden die nicht antworten oder sich nicht zuständig fühlen. Jedenfalls sind das die Leute die für das Network und die Peering Policies zuständig sind. Da aber keinen Vertrag mit dem Network an sich habt, wird das wohl abgewiesen.

Du kannst gern das Problem schildern wie du meinst und mit traceroutes und Messungen hinterlegen und der Bitte das Peering endlich mit OVH aufzunehmen.

Viel Glück wird man dabei aber wohl nicht haben.

danielsan2000
18.02.13, 09:25
Guten Morgen!

Danke für die Recherche der Emailadresse. Dazu möchte ich noch mal meine Frage wiederholen: Was genau muss ich UM inhaltlich schreiben?

Danke für einen Hinweis!

Grüße
Daniel

strex
17.02.13, 21:27
Die richtigen Ansprechpartner wären wohl peering@aora.net, martin.hummers@unitymedia.de, peering@unitymedia.de, ip-noc@unitymedia.de und sven.juergensen@umkbw.de.

Caddy
17.02.13, 21:13
Zitat Zitat von aqua
Stimmt, aber Leuten zu unterstellen, das diese zu doof sind zum googeln, UPC Kunden sowieso Idioten sind, den man das Geld aus der Tasche leiern soll und obendrein nicht mal Kunde ist bzw. betroffen ist, ist für die ganze Angelegenheit natürlich sehr konstruktiv.
Ich glaube, Du hast vielleicht zu schnell gelesen. So, wie Du es beschreibst, hat er das nicht geschrieben. Dabei sollten wir es aber auch belassen.

Zitat Zitat von aqua
Ich habe bereits zwei mal bei Unitymedia angerufen und jedes mal wussten die nicht mal wovon ich überhaupt rede, weil die Mitarbeiter diesbezüglich offensichtlich ungeschult sind. ...
Deswegen habe ich denen auch geschrieben und nicht dort angerufen. Die Mitarbeiter, die Du als Privatkunde dort an der Hotline erreichst, werden wohl kaum wissen, was Peering ist. Die "Sensoren", auf die sie reagieren werden sein: "zu langsam" "schlechter Ping" "Abendstunden" - Daraus entfaltet sich dann ein Plan, was sie zu tun haben. Vermutlich der Plan, den wir nicht erwarten :-)
Es gibt auf der Unitymedia Seite auch eine Kontaktmöglichkeit, die man da findet, wo man sie vermutlich am wenigsten vermutet: GANZ OBEN (nicht vom Logo ablenken lassen, das ist nicht ganz oben :-) ) rechts: "Kontakt"
Dann etwas rechts in der Mitte: "Kontaktformulare", Technische Anfrage.
Als Kunde kannst Du dort auch Deine Kundennummer eintragen, ich habe dann relativ nett und ziemlich ausführlich beschrieben um was es geht und abgeschickt. Bei wem es auch immer zuerst landet - Eine solche Anfrage wird in der Regel so lange weitergeleitet, bis die den Richtigen erreicht hat.
Das funktioniert bei Unitymedia in der Regel sogar. Bei UPC leider nicht (die hatte ich bereits angeschrieben, eine 2. Antwort steht bis heute aus, aber da bin ich auch kein Kunde, steht im Österreich Thread).

Gruß, Klaus

aqua
17.02.13, 19:13
Stimmt, aber Leuten zu unterstellen, das diese zu doof sind zum googeln, UPC Kunden sowieso Idioten sind, den man das Geld aus der Tasche leiern soll und obendrein nicht mal Kunde ist bzw. betroffen ist, ist für die ganze Angelegenheit natürlich sehr konstruktiv.

Ich habe bereits zwei mal bei Unitymedia angerufen und jedes mal wussten die nicht mal wovon ich überhaupt rede, weil die Mitarbeiter diesbezüglich offensichtlich ungeschult sind. Viel mehr als sinnloses Leitungsmessen und rumgedruckse kommt nicht bei rum.

Caddy
17.02.13, 18:59
Zitat Zitat von aqua
Marya, mach dir nichts aus dem Troll strex, einfach ignorieren.
Das dient dem eigentlichen Thema überhaupt nicht. Vielleicht sollte man seine Energie vielleicht besser dafür verwenden, mal bei UPC / Unitymedia nachzuhören, woher die Verzögreung kommt. Ich für meinen Teil habe das sehr ausführlich getan, das war am Freitag, ich denke, dass eine Antwort dazu in den nächsten Tagen kommen sollte.

Gruß, Klaus

aqua
17.02.13, 17:42
Marya, mach dir nichts aus dem Troll strex, einfach ignorieren.

strex
17.02.13, 14:28
Zitat Zitat von Marya
Mir persönlich ist es ziemlich egal, wer die Sache wie löst, solange es zu einer Lösung kommt. Darüber zu lamentieren, wer der Schuldige ist und warum, führt nicht zu einem besseren Routing. Als Kunde beider Seiten kann ich nur an beide appellieren, etwas zu tun, und sie mit hilfreichen Informationen unterstützen. Ob und wie eine Lösung gefunden wird, ist Sache der beteiligten Unternehmen. Wenn dem firmenpolitische Sperenzchen im Wege stehen, kann ich daran nichts ändern, sondern nur ggf. mit dem Geldbeutel abstimmen.
Das ist ja das arme, jeder Kunde kann etwas bewirken, wenn er will. Einen schuldigen muss man immer identifizieren, so funktioniert auch unser Rechtssystem. Ein Wechsel, auch wenn es persönlich ein Rückschritt bedeutet und mit der Zeit wird sich UPC den üblichen Gegebenheiten stellen. Wer aber als Kunde alles hin nimmt, der sollte gerne zur Kasse gebeten werden.

Marya
17.02.13, 03:22
Ich habe niemandem irgendetwas unterstellt, sondern nur auf die Vorposter geantwortet, die der irrigen Hoffnung waren, dass ein geändertes Routing Richtung UM->OVH irgendwas am verstopften Uplink in Gegenrichtung ändern könnte.

Mir persönlich ist es ziemlich egal, wer die Sache wie löst, solange es zu einer Lösung kommt. Darüber zu lamentieren, wer der Schuldige ist und warum, führt nicht zu einem besseren Routing. Als Kunde beider Seiten kann ich nur an beide appellieren, etwas zu tun, und sie mit hilfreichen Informationen unterstützen. Ob und wie eine Lösung gefunden wird, ist Sache der beteiligten Unternehmen. Wenn dem firmenpolitische Sperenzchen im Wege stehen, kann ich daran nichts ändern, sondern nur ggf. mit dem Geldbeutel abstimmen.

strex
17.02.13, 01:42
Zitat Zitat von Marya
Der Engpass besteht ja zwischen OVH->AS6453 (TATA) und nicht andersherum. Solange der Traffic darüber läuft, wird sich nichts ändern.
Das ist ja nur temporär um Überhaupt Richtung UPC Traffic auszutauschen. Zu UM und co. bestand ja früher ein direktes Peering am DE-CIX, dass seitens UPC/LGI gekündigt wurde. Da sich OVH ja darum kümmert und sicher einiges an Geld investiert kann man OVH nicht unterstellen dort nichts zu tun. OVH sollte die Kosten noch besser an UPC Nutzer bzw. Nutzer die mit hoher Prio Richtung UPC senden wollen umlegen, um somit noch viel mehr Druck zu erzeugen. Das wäre konsequent und richtig!

Wer sich aktuell immer noch querstellt ist UPC/LGI, die wollen oder können nicht. Equipment und Verträge von OVH sind gestellt. Das zeigt noch immer, dass man von UPC und co. einen sehr weiten Bogen machen sollte, wer sich darauf einlässt ist selber schuld..

Marya
16.02.13, 17:39
Der Engpass besteht ja zwischen OVH->AS6453 (TATA) und nicht andersherum. Solange der Traffic darüber läuft, wird sich nichts ändern.

aqua
15.02.13, 21:39
Aktuell wieder schlechte Geschwindigkeit und hoher Ping. War wohl ein Reinfall.

Hook
15.02.13, 18:18
Zitat Zitat von Felix
Caddy wrote:
> Leider hat Unitymdia mittlerweile ein erhebliches Kundenpotential, ich
> gehöre ja leider auch dazu, für mich gibt es aber an meinem Standort
> keine Breitbandalternative.


Von unserer Seite ist alles bereit, der ganze Papierkram ist erledigt und wir
warten nur auf die technische Umsetzung seitens UPC. Diese scheint jedoch trotz
inzwischen täglicher Erinnerungen von unserer Seite nicht voranzuschreiten...

Daher kann ich die UPC-Kunden hier nur wiederholt an euren Provider verweisen,
und hoffen das Druck von der eigenen Kundschaft eventuell den Stein ins Rollen
bringt.
Hoffentlich bezahlt ihr nicht den Preis den UPC fürs peering haben will ... Wenn dann noch mehr Kunden zu UPC/Unitymedia gehen müssen die Server bzw. die Bandbreite bei euch ja bald doppelt so teuer werden

aqua
15.02.13, 16:39
Kann ich bestätigen. Bei mir gehts jetzt auch über Level 3 und bisher auch wieder Fullspeed. (52 mbit)

Mal sehen ob es heute Abend auch so bleibt.

Eddy
15.02.13, 14:12
heute hat sich das Routing von Unitymedia zu OVH etwas geändert.

Die route hin geht nun per Level3 vorher war es Telia.

danielsan2000
15.02.13, 12:02
Hallo Felix, danke für die Information.

Was genau muss ich Unitymedia da schreiben?

Gruß
Daniel

Felix
13.02.13, 20:34
Caddy wrote:
> Leider hat Unitymdia mittlerweile ein erhebliches Kundenpotential, ich
> gehöre ja leider auch dazu, für mich gibt es aber an meinem Standort
> keine Breitbandalternative.


Von unserer Seite ist alles bereit, der ganze Papierkram ist erledigt und wir
warten nur auf die technische Umsetzung seitens UPC. Diese scheint jedoch trotz
inzwischen täglicher Erinnerungen von unserer Seite nicht voranzuschreiten...

Daher kann ich die UPC-Kunden hier nur wiederholt an euren Provider verweisen,
und hoffen das Druck von der eigenen Kundschaft eventuell den Stein ins Rollen
bringt.

Caddy
11.02.13, 10:02
Stimmt leider - gestern war es auch mal wieder besonders schlimm. Weiterhin ist auch von Bedeutung, wo die Server stehen. Unser Gameserver steht in Roubaix 1, die Rückroute vom Server zu Unitymedia geht einen ganz anderen (viel schlimmeren) Weg als von Roubaix 3 zur selben Unitymedia IP. Das wird allerdings innerhalb von TATA "erledigt".
Das erweckt manchmal den Eindruck, dass Teile von Roubaix 1 überlastet sind - Sind sie aber nicht.

Derweil haben auch alle Mitbewerber außer Strato das Problem im Griff.

Leider hat Unitymdia mittlerweile ein erhebliches Kundenpotential, ich gehöre ja leider auch dazu, für mich gibt es aber an meinem Standort keine Breitbandalternative.


Gruß, Klaus

aqua
10.02.13, 20:49
Da muss ich leider zustimmen. Ich muss täglich 6 bis 7 GB an Backups von meinem OVH Server saugen und das ist aktuell ein einziger Krampf.

Wenn bis Ende des Monats keine Lösung parat ist - auch wenn es nicht direkt die Schuld von OVH ist - werde ich mein Server auch nicht mehr verlängern.

danielsan2000
10.02.13, 18:13
Ja, das stimmt. Sollte auch mehr ein "bitte hakt da wirklich mal nach" mit rüber kommen. "müssen wohl mal wieder nachhaken" klang irgendwie wie gar nicht zuversichtlich/ambitioniert.

marius
10.02.13, 14:38
Vor 3 Tagen hat Felix doch geschrieben, dass sie seit der letzten Meldung noch nichts von UPC gehört haben.

josen
10.02.13, 14:34
Hallo,

auch bei mir steht bald eine Kaufentscheidung an. Ich kann mit dem zur Zeit von Unitymedia zu OVH erreichbaren Maximaldurchsatz meine Server nicht bei OVH kaufen und werde darum zu einem Konkurrenten gehen.

Und da ich keine halben Sachen mache, dann leider auch die anderen Server die ich betreue, dorthin umziehen.

Schade, aber wenn sich da seit dem 14.12. nichts tut, wird sich da auch die kommenden Wochen nichts tun.

Sehr sehr schade

PS.: Oder könnt ihr einen konkreten Zeitrahmen angeben, Felix?

Grüße

danielsan2000
10.02.13, 13:55
Hallo! Auch von mir nun noch einmal die Frage nach dem Stand der Ding bei der genannten Problembehebung. Ich nach längerer Evaluierung möchte ich nun meine eigene Cloud aufbauen - mit einem OVH Server. Ich werde mich jedoch anderweitig umsehen müssen, wenn ich weiterhin nur eine 300kb/sek. Anbindung zuhause erreiche. Auch mein laufender Server plus dem Shared Hosting Paket laufen am Rande des Erträglichen. Ein Umzug all meiner Produkte zu einem anderen Hoster möchte ich vermieden, denn ich war immer sehr zufrieden mit OVH! Lange ist diese Situation jedoch auch nicht mehr "aushaltbar".
Ich hoffe es kann möglichst bald von einer Besserung berichtet werden.

Viele Grüße
Daniel

Felix
07.02.13, 12:42
strex wrote:
> Es kommt wann es kommt. Da hilft auch ein Push #99999 nix..


sowas erschwert mir und allen anderen die Lesbarkeit des Threads. Haben noch
nix von UPC gehört seit der letzten Meldung, müssen wohl mal wieder nachhaken.

strex
07.02.13, 12:14
Es kommt wann es kommt. Da hilft auch ein Push #99999 nix..

strex
05.02.13, 12:03
Zitat Zitat von RockyBaby
Habe letztens einen Neuanschluß bei KBW bekommen der eigentlich mit IPv6 laufen sollte aber da stimmte was an den Einstellungen nicht und nun hab ich IPv4 bekommen. Speed zu OVH ist immer fullspeed (habe 50/2,5 MBit) und das sogar nach BHS...
KabelBW ist aktuell noch nicht in´s LGI Netz integriert und hat somit noch eigene Peerings am DECIX.

aqua
05.02.13, 11:58
Felix, die Woche ist genau heute rum. Gibts schon Neuigkeiten?

aqua
01.02.13, 13:45
Zitat Zitat von Felix
DS-Lite klingt für mich auf den ersten Blick gar nicht so übel - du solltest
eher beim Betreiber von XBOX meckern das dieser seine Dienste nicht nur per
IPv4 anbietet :-)
Ich denke beide Parteien müssen sich den Schuh anziehen. Mit normalen DS würde es gar keine Probleme geben.

Anderseits sind natürlich auch Xbox (und viele andere Dienste) schuldig, immerhin gibt es ipv6 nicht erst seit gestern.

RockyBaby
01.02.13, 01:14
Habe letztens einen Neuanschluß bei KBW bekommen der eigentlich mit IPv6 laufen sollte aber da stimmte was an den Einstellungen nicht und nun hab ich IPv4 bekommen. Speed zu OVH ist immer fullspeed (habe 50/2,5 MBit) und das sogar nach BHS...

Caddy
01.02.13, 00:31
In den einschlägigen Foren von KabelBW und UnityMedia sorgt DS-Lite aber dafür, dass sich die ersten schon wieder auf reines IPV4 zurückstellen lassen. IPV6 hätte wesentlich mehr Verbreitungschancen mit einem echten Dual-Stack. Da Unitymedia für NRW aber nur ein IPv6 Netz benötigt und für echten DualStack Betrieb noch genau so viele IPV4 Adressen / Netze benötigt, wie vorher auch, fällt das wohl aus Kostengründen weg.

Wenn ich meinen Unitymedia Anschluss von 128MBit auf 150 umstellen lassen würde, würde mir vermutlich auch DS-Lite aufgezwungen. Ich würde fast wetten, IPV6 hätte schon wesentlich mehr Verbreitung, wenn diese blöde Frickelei mit den IPV4 im Tunnel über NAT-Server nicht wäre.

So bleibt mein Anschluss eben so lange wie möglich so, wie er ist. Da tunnel ich mir lieber selbst ein paar unbenutzte V6 Adressen von irgendwelchen Kisten aus meinem Wirkungsfeld nach Hause durch :-)

Gruß, Klaus

Felix
31.01.13, 19:22
kenshin wrote:
> KabelDeutschland veranstaltet denselben Schwachsinn @DSlite. Rumnerven
> hilft da aber wohl auch.


DS-Lite klingt für mich auf den ersten Blick gar nicht so übel - du solltest
eher beim Betreiber von XBOX meckern das dieser seine Dienste nicht nur per
IPv4 anbietet :-)

kenshin
31.01.13, 18:40
KabelDeutschland veranstaltet denselben Schwachsinn @DSlite. Rumnerven hilft da aber wohl auch.

strex
31.01.13, 18:37
DS-Lite an sich ist kein Dual Stack, weder ein echtes noch kein echtes. Man bekommt dort nur eine IPv6 Adresse keine IPv4. Über einen 4to6 Tunnel werden dann über NAT Router die IPv4 Kommunikation abgewickelt. Somit ist kein Port Forwarding (IPv4) mehr möglich.

Jeder kann aber über die Hotline in der Regel einen neuen Zugang anfordern.

aqua
31.01.13, 17:48
Zitat Zitat von Felix
BTW und rein aus Neugierde... In Deutschland rollen UnityMedia & KabelBW seit November natives IPv6 für alle Neuzugänge aus - hat das schon jemand getestet, gibt's da schon feedback was das Peering, Latenzen und Bandbreiten betrifft?
Ich habe glücklicherweise noch ein altes Cisco Modem, mit dem IPV6 nicht möglich ist. Jedenfalls rollt Unitymedia Dual Stack lite für Neukunden und Vertragswechsler aus, also kein echtes Dual Stack, wodurch wohl viele Kunden Probleme mit ihrer XBOX und Port Forwarding haben sollen. Der Speed soll wie beim nativen IPv4 gleich sein.

Felix
31.01.13, 17:05
BTW und rein aus Neugierde... In Deutschland rollen UnityMedia & KabelBW seit November natives IPv6 für alle Neuzugänge aus - hat das schon jemand getestet, gibt's da schon feedback was das Peering, Latenzen und Bandbreiten betrifft?

Edding
31.01.13, 16:31
Naja das problem ist ja, das sich UPC unitymedia erkauft hat, vorher hatte man nicht viel mit dem Verein zutun und es gabs auch nie wirklich speed probleme.


Eine andere möglichkeit Unitymedia zumindest z.zt noch zu erreichen ist der ECIX.

Aber wer weis wielange die dort noch sein werden.

Und am WE ist ihr Link dort eigentlich auch überlastet.

P.s. könnte man schon ein paar einzelheiten über das peering erhalten ?

Ist es direkt mit Um odr UPC ?
Wie gross wird der Link sein ?

Hook
30.01.13, 22:46
Zitat Zitat von strex
Wer sich mit LGI (UPC) einlässt, muss damit leben..
Korrekt.

Und da Server nicht teurer werden sollen, find ichs gut dass ein paar Rechenzentren sich weigern, die Preise von UPC/LibertyGlobal fürs Peering zu zahlen! Das sollten eigentlich alle machen ....
Leider verstehen aber die Kunden der Provider nicht, wo das Problem eigentlich liegt

Felix
29.01.13, 14:38
aqua wrote:
> Das hört sich doch schon mal gut an! Kann mir jemand sagen was ein PNI
> ist?


Sorry :-/
http://en.wikipedia.org/wiki/Private...rivate_peering

Caddy
29.01.13, 14:24
Nun, um die korrekte sachliche Erklärung für PNI zu finden, musste ich schon verdammt lange "websuchen" :-)

Mit dem avisierten Zeitrahmen kann ich leben - Und wenn's tatsächlich in Frankfurt direkt ins OVH Netz ein/aussteigt, sollte das Problem ja dann auch erledigt sein.

Ich bin gespannt.

Gruß, Klaus

strex
29.01.13, 14:06
Private Network Interconnection, die Websuche ist wohl nicht deine Stärke..

aqua
29.01.13, 14:04
Das hört sich doch schon mal gut an! Kann mir jemand sagen was ein PNI ist?

Felix
29.01.13, 12:28
Caddy wrote:
> Wie gesagt, OVH wäre dann mit einem Statement dran :-)


Wie im November geschrieben ist eine Besserung in Aussicht... konkret, ein PNI
in Frankfurt. Wir warten gerade noch auf die technische Umsetzung seitens
Unitymedia, ich hoffe (und bin zuversichtlich) das dies in spätestens einer
Woche fertiggestellt ist.

Felix

Caddy
29.01.13, 10:51
Zitat Zitat von aqua
Ich weiß jetzt nicht ob es an der Uhrzeit liegt,
Ja.
Zitat Zitat von aqua
oder ob Änderungen vorgenommen wurden,
Nein.
Zitat Zitat von aqua
aber aktuell habe ich wieder 30 ms und fullspeed (52 mbit).
Wenn Du Dir den vorherigen Threadverlauf ansiehst, weißt Du auch, warum.
Wenn Änderungen vorgenommen werden, hättest Du ca. 18ms durchgehend und immer Fullspeed.

Wie gesagt, OVH wäre dann mit einem Statement dran :-)

Gruß, Klaus

aqua
29.01.13, 10:28
Ich weiß jetzt nicht ob es an der Uhrzeit liegt, oder ob Änderungen vorgenommen wurden, aber aktuell habe ich wieder 30 ms und fullspeed (52 mbit).

strex
28.01.13, 20:26
Zitat Zitat von aqua
Hab ich auch gemacht, dort ist schön ersichtlich das ich bei "fra-5-6k" aktuell sogar 70% loss habe....
Das ist normal, die Router bearbeiten ICMP Pakets nur wenn gerade frei sind, sonst werden die gedropped. Loss immer am Ende der Kette ablesen..

Das der Traffic nicht gesamt über die teuren Telia Uplinks umgeleitet wird, sollte doch verständlich sein.

Marya
28.01.13, 20:14
Ich bin auch betroffen und habe ebenfalls ein Ticket geschrieben. Ich habe auf die Weathermap verwiesen, in der klar zu sehen ist, dass die zwei Links von fra-5-6k nach TATA überlastet sind (eigenartigerweise taucht der TATA Link in der Weathermap für Frankfurt nicht auf bzw. am falschen Router und mit nur 1%) und habe konkret vorgeschlagen, Unitymedia-Traffic über die wenig belasteten Telia-Links zu schicken, über die auch der Traffic auf dem Hinweg zu OVH läuft. Das sollte auch das absurde Routing RBX->FRA->PAR->FRA beheben.

aqua
28.01.13, 19:02
Kurze Zwischenmeldung:

Mein Ticket wurde vorhin beantwortet, ich solle neue MTR Werte posten. Hab ich auch gemacht, dort ist schön ersichtlich das ich bei "fra-5-6k" aktuell sogar 70% loss habe.

Ich hab ihm außerdem noch gesagt, sofern er Deutsch versteht, soll er sich mal den Thread hier durchlesen...

Caddy
28.01.13, 16:57
Zitat Zitat von aqua
Hallo Leute,
ich bin auch Unitymedia Kunde in NRW (nähe Duisburg) und hab auch seit etwa 1 1/2 Wochen sehr starke Speedproblemen und ein recht hohen Ping nach OVH. Mein Störungsticket wurde von (...) geschlossen mit dem Hinweis auf folgende URL: http://travaux.ovh.net/?do=details&id=7929
(...)
Die in Deinem Ticket erwähnte Statusmeldung bezieht sich auf das:
http://forum.ovh.de/showthread.php?t=11795

Das ist bereits behoben und hatte "nur" ziemliche Latenzschwankungen auf den IPv4 Routen über fra-5-6k / rbx-g2-a9 erzeugt, sowie eine verdammt hohe Latenz auf IPv6 über diese beiden Router. Ich hatte das über mehrere Tage beobachtet und im Thread oben gepostet. Das wurde nach meinem Posting auch ziemlich schnell behoben und kommt jetzt in diesem Moment (ich weiss nicht, von wann Dein Ticket ist) nicht mehr zum Tragen.

Deine Schwankungen werden vermutlich - wie bei allen Unitymediakunden in NRW, zu denen ich ja auch gehöre, derzeit von den zu Hauptzeiten völlig überlasteten TATA Links am fra-5-6k verursacht.

Den Rest hat strex ja schon beschrieben. Obwohl ich andere Anbieter ungern erwähne, gab es hier mal den Hinweis, dass Hetzner dasselbe Problem hatte - Anscheinend ist "hatte" das richtige Wort, denn von meinem Unitymedia Anschluss habe ich durchgehend 15-20ms Ping und volle Geschwindigkeit von Hetzner Servern. Um noch einen anderen zu nennen: Server4you hatte ebenfalls Probleme - Von welcher Seite aus und durch wessen Mitarbeit und / oder Veranlassung sich das normalisiert hat, kann ich nicht beurteilen. Fakt ist, wenn ich z.B. abends gegen 21 Uhr die Pings vergleiche:

Hetzner: 15-20ms
Server4you: 14-16ms
OVH: >100ms

Um weitere Spekulationen zu vermeiden, kann dazu wirklich nur jemand von OVH etwas zu sagen. Das wünsche ich mir auch für alle anderen Threads (Österreich, Schweiz), die ja mutmaßlich dieselbe Ursache haben :-)

Gruß, Klaus

strex
28.01.13, 16:22
Das ist egal, es sind in deinem Vertrag keine Garantie über Bandbreite und Bandbreite zu bestimmten Netzen enthalten, sondern nur "bis zu" Werte. Eben bis zu 50 Mbit/s, da fallen auch 1 Mbit/s darunter.. Auch wurde dir keine Anzahl an Peerings oder sonst etwas garantiert und somit völlig irrelevant. Alles andere kann sein wie es will, nur ein Sonderkündigungsrecht gibt es da nicht.

aqua
28.01.13, 16:12
Naja, es hat ja offensichtlich eine Einschränkung stattgefunden (http://bgp.he.net/AS20825), wodurch die Leistung laut meinem 50 mbit Angebot nicht mehr erfüllt wird. Ein "Speed-Fairsprechen" besteht wohl nur für Neukunden. Nur wenn ich für 50 mbit bezahle, und gerade zu den Stoßzeiten nicht mal 1 mbit erreiche, läuft hier was gewaltig schief.

Ich habe vorhin auch mal bei Unitymedia angerufen und der Mitarbeiter wusste nichtmal wer die Liberty Global, Inc ist....

strex
28.01.13, 15:57
Nope, kein Kündigungsrecht. Der Vertrag garantiert dir weder die Bandbreite noch eine Bandbreite zu bestimmte Ziele. Sonst hätte ja jeder ein Sonderkündigungsrecht, weil ich von Server aus Asien immer langsam lade..

aqua
28.01.13, 15:38
Na, klasse! Ich bin gut 1 Jahr Unitymedia Kunde und hatte bis vor kurzem nie Probleme. Weiß jemand ob man jetzt ein Kündigungsrecht hat? So bringt mir die Leitung nichts mehr, da bin ich mit DSL noch schneller unterwegs.

strex
28.01.13, 14:29
Das wurde dadurch verursacht, dass UM in das LGI Netz integriert wurde, die per se kein Peering am DECIX wollen. Das ist ein Problem deines Anbieters und nicht von OVH, denn sie könnten, wenn sie wollten das problemlos beheben.

aqua
28.01.13, 13:50
Wer oder was ist bitte LGI? Zuvor konnte ich meine 50mbit Leitung mit 52 mbit nach OVH problemlos auslasten und hatte etwa 30 ms. Aktuell bin ich froh wenn ich (gerade zu den Stoßzeiten) 400 k bekomme und liege bei 80 bis 140 ms.

edit: ahh, ok! http://de.wikipedia.org/wiki/Liberty_Global

strex
28.01.13, 13:30
Auf die Lösung kannst du lange warten, so lange sich LGI quer stellt und bald auch noch KabelBW folgt wird das nichts. Wer sich mit LGI (UPC) einlässt, muss damit leben..

aqua
28.01.13, 13:10
Hallo Leute,
ich bin auch Unitymedia Kunde in NRW (nähe Duisburg) und hab auch seit etwa 1 1/2 Wochen sehr starke Speedproblemen und ein recht hohen Ping nach OVH. Mein Störungsticket wurde von Meryam J. geschlossen mit dem Hinweis auf folgende URL: http://travaux.ovh.net/?do=details&id=7929

Aber da das Problem nach wie vor besteht, kann es daran nicht gelegen haben. Also habe ich das Ticket wieder eröffnet und erwarte jetzt hoffentlich eine Lösung.

Ich werde hier berichten...

Gruß

Caddy
28.01.13, 12:58
Eben. Frankreich -> Frankfurt -> Frankreich -> irgendwo -> Unitymedia :-)

Mindestens einmal Frankreich zuviel :-)

bene
28.01.13, 12:54
Hi,

das wird in der Tat "interessant" geroutet zu dir ;-)

Der Server hat nur 100MBit, somit bekommst du die volle Geschwindigkeit.
Das ist ja schonmal gut. Aber warum OVH es nicht in Frankreich übergibt bzw es so lustig hin und her geht ist wirklich auch eine gute Frage...

Caddy
28.01.13, 12:44
Da Du ja so nett den vollständigen Pfad der 1Gio.dat drin gelassen hast, habe ich das mal kurz von meinem Unitymedia Anschluss zuhause "angeladen":

Code:
11% [==================>...] 124.713.600 11,2M/s  ETA 90s
Die TATA Links sind ja auch "noch" einigermaßen ruhig. Abends wird das nicht mehr gehen. Im Moment ist das wohl Vollgas, ich spekuliere auf eine 100MBit/s Anbindung des Servers :-)

Ausserdem bist Du ja auch in der Schweiz, ich bin in DE :-) Wenn Du in Deinem http log eine IP 130.180.82.x hast, die eben die 1Gio.dat requested hat, darfst Du gerne mal ein trace drauf machen, das wird schön über TATA quer durch die Weltgeschichte geroutet ...

Gruß, Klaus

bene
28.01.13, 12:08
Routingtechnisch sieht es bei mir eigentlich brauchbar aus...

Routing vom Server zu mir:
Code:
                                       Packets               Pings
 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. vss-9a-6k.fr.eu                  41.3%   104   17.6  21.6   0.5 204.6  46.1
 2. rbx-g2-a9.fr.eu                   0.0%   104    1.0   6.0   0.7 219.5  27.5
 3. fra-5-6k.fr.eu                   28.8%   104    8.2  11.8   8.1  48.7   9.9
 4. zur-1-6k.ch.eu                    0.0%   104   15.3  18.5  15.1 106.2  12.9
 5. upc.as6830.ch.eu                  1.0%   104   17.5  19.4  17.3  93.3   9.0
 6. ch-zrh02a-ra1-xe-3-2-0.aorta.net  0.0%   104   19.1  18.6  17.8  40.3   3.0
 7. 84.116.202.246                    0.0%   104   21.9  21.9  21.8  22.7   0.1
 8. 217-168-55-174.static.cablecom.c  1.0%   104   23.2  23.7  23.1  30.0   0.7
 9. 84-74-xxx-yyy.dclient.hispeed.ch    0.0%   103   31.6  31.4  29.6  50.4   2.5

...nur ändert es nichts daran, dass der Link wohl total dicht ist.

Was mich nur wundert, ist das OVH scheinbar irgendwie die proof.ovh.net priorisiert. Anders kann ich mir sowas nicht erklären:
http://i.imm.io/Untp.jpeg

vs von meinem Server:
http://i.imm.io/UnsF.jpeg

Edit: Auslastung des UPC Links zzt bei nur 50%....:
http://i.imm.io/Unu3.png

Caddy
28.01.13, 10:21
Hi,

ich glaube, irgendwelche Neuigkeiten wären jetzt schon gut. Zumal sich ja über die TATA Links noch UPC Österreich quält. Das nimmt leider auch langsam ziemlich gewaltige Ausmaße an. Da ich davon ausgehe, dass Unitymedia von OVH aus deswegen über TATA geroutet wird, weil die Übergabepunkte im selben Netz liegen wie die von UPC Austria, könnte man zumindest die IP Ranges von Unitymedia an einer sinnvolleren Stelle übergeben als über den mittlerweile völlig überlasteten TATA Link in Frankfurt. Ich habe irgendwo gesehen, dass das Zeug wieder nach Paris geht und dann ins LGI Netz einsteigt, das ist vom Weg her ein irrsinniges hin und her.

Grafisch darstellen lässt sich das auch:
http://s1.directupload.net/images/130128/azcbddys.png

Vielleicht kann da ja jemand von OVH nochmal was dazu sagen, zumal die Mitbewerber (außer Strato) das Problem anscheinend irgendwie schon gelöst haben.

Gruß, Klaus

SchwippSchwapp
27.01.13, 21:10
gibts schon neuigkeiten?

die tata links in frankfurt sind ja ab dem nachmittag immer ausgelastet

extrem101
20.01.13, 23:38
Schon hart wie überlastet das aktuelle Unitymedia routing ganztägig sonntags ist. Mit einem IPv6 Tunnel lässt sich immerhin etwas mehr durchquetschen.
vss-8a-6k.fr.eu scheint jedoch weiterhin eine Katastrophe zu sein. Eine Ticketeröffnung hat jedenfalls nichts gebracht und das ich den ssh supportkey installiere kommt leider nicht in frage.
Wäre cool wenn man einen Rackumzug beantragen könnte

Code:
  1    39 ms    13 ms    12 ms  *.tunnel.tserv6.fra1.ipv6.he.net [2001:470:****:****::1]
  2    11 ms    11 ms    10 ms  gige-g2-20.core1.fra1.he.net [2001:470:0:69::1]
  3     9 ms    13 ms     8 ms  as1299.gige-g2-9.core1.fra1.he.net [2001:470:0:168::2]
  4    22 ms    48 ms    28 ms  prs-b7-v6.telia.net [2001:2000:3018:18::1]
  5     *        *        *     Zeitüberschreitung der Anforderung.
  6    52 ms    27 ms    26 ms  rf-1-a1.fr.eu [2001:41d0::c32]
  7    27 ms     *       57 ms  gsw-2-6k.fr.eu [2001:41d0::731]
  8    34 ms    35 ms    35 ms  th2-g1-a9.fr.eu [2001:41d0::5a1]
  9    38 ms    92 ms    38 ms  rbx-g1-a9.fr.eu [2001:41d0::b71]
 10   290 ms   232 ms   551 ms  vss-8a-6k.fr.eu [2001:41d0::167]
 11    80 ms    28 ms    50 ms  2001:*****:8:*****::1

Stefan
06.01.13, 13:08
Bitte dazu ein Störungsticket für die Admins erstellen, damit dies genau geprüft werden kann.
Auch die beiden Richtungen aufzeigen, zu proof.ovh.net ok und die Route zu deinem Server nicht ok.

Stefan

extrem101
05.01.13, 22:59
In letzter zeit ist es wirklich grausam. Aber es liegt in meinem Fall bestimmt auch an den Rack in dem mein isgenug steht. Ich hatte vor ca. einem Monat ein wechsel auf eine neue Hardware und seitdem läuft es DEUTLICH schlechter. Auch schon vor den Unitymedia aufkauf von UPC.

Man kommt sich natürlich auch etwas verarscht vor wenn der eigene Server lahmt wie sau und man bei proof.ovh.net ohne Probleme ordentliche Werte erreicht. Von meinem isgenug erreiche ich im Moment nicht einmal 10Mbit/s.
Ich denke vss-8a-6k.fr.eu ist auch immer ein Nadelöhr

Proof:
Code:
Download Speed: 61535 kbps (7691.9 KB/sec transfer rate)
Upload Speed: 4478 kbps (559.8 KB/sec transfer rate)
heim --> root
Code:
  1    <1 ms    <1 ms    <1 ms  router [192.168.5.254]
  2     5 ms     5 ms     6 ms  10.146.0.1
  3     6 ms     5 ms     5 ms  7411A-MX960-01-ae12-1020.ful.unity-media.net [80.69.105.129]
  4     7 ms     8 ms     6 ms  7411A-MX960-02-ae0.ful.unity-media.net [80.69.107.125]
  5    15 ms     8 ms     7 ms  7111A-MX960-02-ae2.fra.unity-media.net [80.69.107.121]
  6     8 ms     7 ms     7 ms  7111A-MX960-01-ae0.fra.unity-media.net [80.69.107.213]
  7     9 ms    14 ms     7 ms  84-116-131-149.aorta.net [84.116.131.149]
  8     7 ms    10 ms     8 ms  de-fra01a-ri2-xe-5-1-1.aorta.net [84.116.133.114]
  9    10 ms     9 ms     9 ms  84.116.132.174
 10    13 ms     9 ms     7 ms  213.46.179.194.aorta.net [213.46.179.194]
 11    21 ms     9 ms     9 ms  ffm-bb1-link.telia.net [80.91.246.224]
 12    10 ms    13 ms     8 ms  ffm-b10-link.telia.net [80.91.247.185]
 13    87 ms    22 ms     *     fra-5-6k.fr.eu [213.186.32.225]
 14    28 ms    30 ms    30 ms  rbx-g2-a9.fr.eu [91.121.131.130]
 15    72 ms    35 ms     *     vss-8a-6k.fr.eu [91.121.215.187]
 16    71 ms    72 ms    73 ms  ks3100xxx.kimsufi.com [37.59.62.xxx]
root --> heim
Code:
 1  vss-8a-6k.fr.eu (37.59.62.253)  0.767 ms * *
 2  rbx-g2-a9.fr.eu (91.121.215.186)  1.752 ms  3.176 ms  3.157 ms
 3  fra-5-6k.fr.eu (91.121.131.133)  86.639 ms fra-5-6k.fr.eu (91.121.131.202)  86.650 ms fra-5-6k.fr.eu (178.33.100.255)  86.636 ms
 4  tata.as6453.de.eu (213.251.130.106)  55.386 ms  55.406 ms  55.384 ms
 5  if-4-1108.tcore1.FNM-Frankfurt.as6453.net (195.219.156.133)  52.001 ms  52.018 ms  52.001 ms
 6  * * if-6-3.tcore1.AV2-Amsterdam.as6453.net (195.219.194.77)  55.499 ms
 7  * * if-2-2.tcore2.AV2-Amsterdam.as6453.net (195.219.194.6)  56.883 ms
 8  if-7-2.tcore2.L78-London.as6453.net (80.231.152.14)  56.861 ms  56.797 ms  56.698 ms
 9  Vlan757.icore2.LDN-London.as6453.net (80.231.20.21)  58.208 ms  58.198 ms  56.848 ms
10  213.46.179.105.aorta.net (213.46.179.105)  66.005 ms  65.986 ms  65.966 ms
11  uk-lon01b-rd1-xe-7-0-0.aorta.net (84.116.133.229)  80.043 ms  79.963 ms  79.974 ms
12  1411g-mx960-02-ae3.neuss.unity-media.net (84.116.131.146)  66.641 ms  71.479 ms  65.511 ms
13  13NOC-MX960-02-ae9.krp.unity-media.net (80.69.107.5)  66.752 ms  68.203 ms  71.659 ms
14  13NOC-MX960-01-ae0.krp.unity-media.net (80.69.107.201)  112.757 ms *  86.224 ms
15  7111A-MX960-01-ae8.fra.unity-media.net (80.69.107.25)  67.756 ms  67.517 ms  67.503 ms
16  7111A-MX960-02-ae0.fra.unity-media.net (80.69.107.214)  67.448 ms  67.385 ms  67.920 ms
17  7411A-MX960-02-ae1.ful.unity-media.net (80.69.107.122)  73.981 ms  70.866 ms  71.234 ms
18  PH-7411A-uBR10k-02-Te-3-2-0-2020.ful.unity-media.net (80.69.105.134)  71.336 ms  71.280 ms  71.211 ms
19  * * *
20  * * *

bene
05.01.13, 19:38
Hallo,

bei mir geht es momentan eigentlich was den Speed angeht. Berauschend ist etwas anderes, aber wenigstens so um 10MBit/s geht ca.

Von proof.ovh.net:
Code:
Download Speed: 10791 kbps (1348.9 KB/sec transfer rate)
Upload Speed: 4389 kbps (548.6 KB/sec transfer rate)
Latency: 34 ms
Das Routing geht nun hin über Telia und zurück über das OVH Peering in Zürich.
Interessant, dass ich auch Packetloss habe über diese Route, von einem anderen Server (der UPC Upstream hat) jedoch z.Bsp. nicht:

Code:
  1     8 ms     7 ms     7 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    18 ms    16 ms    22 ms  84.116.200.245
  4    14 ms    19 ms    13 ms  ch-zrh01b-ra1-ae-1.aorta.net [84.116.134.142]
  5    12 ms    15 ms    14 ms  213.46.171.66
  6    25 ms    55 ms    33 ms  ffm-bb2-link.telia.net [80.91.249.115]
  7    24 ms    24 ms    28 ms  ffm-b10-link.telia.net [80.91.251.124]
  8    30 ms    26 ms     *     fra-5-6k.fr.eu [213.186.32.225]
  9    33 ms    31 ms    32 ms  rbx-g2-a9.fr.eu [94.23.122.117]
 10    33 ms     *       70 ms  vss-9a-6k.fr.eu [91.121.131.156]
 11    31 ms    33 ms    33 ms  ks326XXX.kimsufi.com [5.39.79.xxx]
Zurück von OVH mit Loss:
Code:
                                        Packets               Pings
 Host                                 Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. vss-9a-6k.fr.eu                   27.8%    55    0.8  10.8   0.4 226.9  38.6
 2. rbx-g2-a9.fr.eu                    0.0%    55    1.1  16.4   0.7 294.1  60.9
 3. fra-5-6k.fr.eu                    38.2%    55   15.4  15.4   8.0 118.6  20.7
 4. zur-1-6k.ch.eu                     0.0%    55   16.0  21.4  15.1 136.8  21.8
 5. upc.as6830.ch.eu                   3.6%    55   46.9  20.7  17.3  82.2  10.9
 6. ch-zrh02a-ra1-xe-3-2-0.aorta.net   5.5%    55   17.9  21.8  17.9  49.5   6.9
 7. 84.116.202.246                     0.0%    55   22.2  22.0  21.8  22.6   0.2
 8. 217-168-55-174.static.cablecom.ch  7.4%    54   23.3  23.3  23.0  23.8   0.2
 9. 84-74-xxx-yyy.dclient.hispeed.ch     5.6%    54   31.3  32.1  29.9  49.3   2.9
Und von wo anders ohne Loss:
Code:
                                     Packets               Pings
 Host                               Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 81.223.xxx.yyy                     0.0%    85    0.9   5.1   0.7 102.1  17.3
 2. upc.dc1.grz.as57169.net          0.0%    85    0.9  10.8   0.9  80.3  20.6
 3. at-grz-lazg-pe02-vl-2084.upc.at  0.0%    85   30.2  31.2  30.1  59.0   4.2
 4. at-vie15a-rd1-vl-2032.aorta.net  0.0%    85   30.1  35.5  30.0  82.2  11.2
 5. 84.116.136.118                   0.0%    85   32.5  30.7  28.7  51.8   3.7
 6. 84.116.136.213                   0.0%    85   24.1  24.8  23.8  32.9   1.5
 7. 84.116.200.246                   0.0%    85   33.4  33.3  33.2  34.7   0.2
 8. 217-168-55-174.static.cablecom. 10.6%    85   32.0  31.7  31.6  32.0   0.1
 9. 84-74-xxx-yyy.dclient.hispeed.ch   0.0%    84   42.7  43.6  39.7  68.0   4.4

Eddy
04.01.13, 22:35
5 8 ms 17 ms 11 ms de-fra01a-ri2-xe-4-1-1.aorta.net [84.116.133.118
]
6 6 ms 9 ms 16 ms 84.116.132.146
7 7 ms 25 ms 23 ms 213.46.179.194.aorta.net [213.46.179.194]
8 11 ms 16 ms 10 ms ffm-bb2-link.telia.net [80.91.246.218]
9 14 ms 9 ms 8 ms ffm-b10-link.telia.net [80.91.247.189]
10 29 ms 24 ms * fra-5-6k.fr.eu [213.186.32.225]
11 40 ms 31 ms 39 ms rbx-g2-a9.fr.eu [91.121.131.134]
12 93 ms 97 ms 174 ms vss-1-6k.fr.eu [91.121.131.29]
13 93 ms 88 ms 89 ms ksXXXXX.kimsufi.com [xx.xx.xx.xx]


Hook
03.01.13, 22:09
UPC hat definitiv auch Engpässe im eigenen Netz. Ich weiß von einem direkten Peering mit UPC welches nicht sonderlich ausgelastet ist (<70%) und der Speed für UPC Kunden trotzdem vor allem in Spitzenzeiten nicht sonderlich gut ist (einige hundert kb/sec).
Wie wirr das dann im UPC Netz weitergeroutet wird, hab ich hier im Forum ja an anderer Stelle schonmal geschrieben.

Ich persönlich würde als Endkunde soweit Abstand von UPC nehmen wie nur irgendwie möglich, man ärgert sich dann ja doch nur über die nicht erbrachte Leistung ...

Caddy
03.01.13, 15:11
Wenn die Laggs ungefähr in diesem Zeitraum liegen:

http://s7.directupload.net/images/130103/kuudakmj.png

... ist es so ziemlich egal, welches Protokoll man verwendet :-)

fr-par02a-rd1-ge-6-0.aorta.net ... Da müsste OVH ja erst einmal eine Verbindung schaffen, das wäre natürlich ein Traum: Roubaix, Paris, LGI (Aorta), denn innerhalb des LGI Netzes scheint sich auch was zu tun, Laufzeiten zu einigen "Mitbewerbern" sind schon deutlich runtergegangen.

Gruß, Klaus

Eddy
03.01.13, 14:24
fr-par02a-rd1-ge-6-0.aorta.net

dort könnte OVh doch normal schön den traffic an UPC übergeben.(Aber UPC will ja anscheinend nicht)

dann düfte es auch wurscht sein wohin im UPC netz er im endeffekt gehen wird.

Ausser UPC hat im eigen Netz auch überlastungen

Das mit den packetloos scheitn aber nicht nur ICMP zu betreffen ich glaube es ist generell TCP traffic.

Auf einem Game server auf dem ich ab und an spiele , gibt es nun Lags die vorher nie da waren.

Auch der Speed war jetzt die Feiertage grauenhaft teils.

Wo es vorher über den decix nie probleme gab hatte ich nun teils nur noch 850kb/s im WGET

Caddy
03.01.13, 09:35
Frohes Neues erst einmal.

Ich habe etwas ziemlich interessantes festgestellt: Der Packet Loss, den wir ja mittlerweile alle nachvollziehen können, scheint NUR und AUSSCHLIESSLICH bei ICMP Paketen aufzutreten, lustigerweise auch NUR zwischen Liberty Global und OVH. Während ich mit einem MTR schön Loss zu einem unserer Server in Roubaix 3 habe, habe ich mal mit iperf mehrere Tests mittels 1Mbit/s und 3Mbit/s UDP zu dem selben Server durchgeführt:

Code:
[  3] local 188.165.201.x port 5001 connected with 130.180.82.x port 54170
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3]  0.0- 1.0 sec    122 KBytes  1000 Kbits/sec  1.080 ms    0/   85 (0%)
[  3]  1.0- 2.0 sec    122 KBytes  1000 Kbits/sec  1.029 ms    0/   85 (0%)
[  3]  2.0- 3.0 sec    122 KBytes  1000 Kbits/sec  0.900 ms    0/   85 (0%)
[  3]  3.0- 4.0 sec    122 KBytes  1000 Kbits/sec  1.391 ms    0/   85 (0%)
[  3]  4.0- 5.0 sec    122 KBytes  1000 Kbits/sec  1.292 ms    0/   85 (0%)
[  3]  5.0- 6.0 sec    122 KBytes  1000 Kbits/sec  1.197 ms    0/   85 (0%)
[  3]  6.0- 7.0 sec    122 KBytes  1000 Kbits/sec  0.968 ms    0/   85 (0%)
[  3]  7.0- 8.0 sec    122 KBytes  1000 Kbits/sec  1.054 ms    0/   85 (0%)
[  3]  8.0- 9.0 sec    122 KBytes  1000 Kbits/sec  0.940 ms    0/   85 (0%)
[  3]  9.0-10.0 sec    122 KBytes  1000 Kbits/sec  1.368 ms    0/   85 (0%)
[  3]  0.0-10.0 sec  1.19 MBytes  1.00 Mbits/sec  1.676 ms    0/  852 (0%)
[  4] local 188.165.201.x port 5001 connected with 130.180.82.x port 41195
[  4]  0.0- 1.0 sec    121 KBytes    988 Kbits/sec  1.600 ms    0/   84 (0%)
[  4]  1.0- 2.0 sec    122 KBytes  1000 Kbits/sec  1.259 ms    0/   85 (0%)
[  4]  2.0- 3.0 sec    123 KBytes  1.01 Mbits/sec  1.644 ms    0/   86 (0%)
[  4]  3.0- 4.0 sec    122 KBytes  1000 Kbits/sec  1.336 ms    0/   85 (0%)
[  4]  4.0- 5.0 sec    122 KBytes  1000 Kbits/sec  2.654 ms    0/   85 (0%)
[  4]  5.0- 6.0 sec    122 KBytes  1000 Kbits/sec  1.204 ms    0/   85 (0%)
[  4]  6.0- 7.0 sec    122 KBytes  1000 Kbits/sec  2.145 ms    0/   85 (0%)
[  4]  7.0- 8.0 sec    122 KBytes  1000 Kbits/sec  1.793 ms    0/   85 (0%)
[  4]  8.0- 9.0 sec    122 KBytes  1000 Kbits/sec  1.370 ms    0/   85 (0%)
[  4]  9.0-10.0 sec    122 KBytes  1000 Kbits/sec  1.112 ms    0/   85 (0%)
[  4]  0.0-10.0 sec  1.19 MBytes  1.00 Mbits/sec  1.096 ms    0/  852 (0%)
[  3] local 188.165.201.x port 5001 connected with 130.180.82.x port 51463
[  3]  0.0- 1.0 sec    366 KBytes  3.00 Mbits/sec  1.225 ms    0/  255 (0%)
[  3]  1.0- 2.0 sec    366 KBytes  3.00 Mbits/sec  1.373 ms    0/  255 (0%)
[  3]  2.0- 3.0 sec    365 KBytes  2.99 Mbits/sec  0.883 ms    0/  254 (0%)
[  3]  3.0- 4.0 sec    366 KBytes  3.00 Mbits/sec  0.900 ms    0/  255 (0%)
[  3]  4.0- 5.0 sec    366 KBytes  3.00 Mbits/sec  1.616 ms    0/  255 (0%)
[  3]  5.0- 6.0 sec    368 KBytes  3.01 Mbits/sec  1.478 ms    0/  256 (0%)
[  3]  6.0- 7.0 sec    366 KBytes  3.00 Mbits/sec  1.664 ms    0/  255 (0%)
[  3]  7.0- 8.0 sec    366 KBytes  3.00 Mbits/sec  1.084 ms    0/  255 (0%)
[  3]  8.0- 9.0 sec    368 KBytes  3.01 Mbits/sec  1.388 ms    0/  256 (0%)
[  3]  9.0-10.0 sec    366 KBytes  3.00 Mbits/sec  1.060 ms    0/  255 (0%)
[  3]  0.0-10.0 sec  3.58 MBytes  3.00 Mbits/sec  0.942 ms    0/ 2552 (0%)
[  3]  0.0-10.0 sec  1 datagrams received out-of-order
Derweil werden leider Pakete von OVH nach Unitymedia ebenfalls über TATA geroutet, sie werden in Frankfurt dorthin übergeben:

4. tata.as6453.de.eu

Um danach wieder nach Frankreich übergeben zu werden:
9. fr-par02a-rd1-ge-6-0.aorta.net

10. 84.116.136.17 <- Das Ding ist laut whois in AT (UPC Broadband GmbH, Vienna, AT) - Ist es aber nicht, von mir zuhause aus NRW hat das Ding einen Ping von 9ms (nach Wien technisch unmöglich). Vermutlich auch deswegen die "Entscheidung", das Routing über TATA zu führen.

Leider sorgt dieses wilde Routing dafür, dass abends ein sinnvolles Arbeiten auf OVH Servern nicht mehr wirklich möglich ist.

Ich warte also sehnsüchtig auf die von OVH angekündigten Änderungen im Januar, die dann hoffentlich nicht nur Österreich betreffen :-)

Gruß, Klaus

neto
20.12.12, 17:48
Hier mal ein Screenshot vom Pingplotter - Monitoring von Unitymedia zu meinem OVH Server. Auf gut Deutsch - da geht nichts mehr. Eine sinnvolle Nutzung ist nicht mehr möglich. Einzigster Trost - auch bei vielen anderen RZs tauchen deutliche Probleme auf. So sieht also eine neue Firmenpolitik bei Liberty Global auf - das nenne ich doch mal eine deutliche Qualtätssteigerung für den Endkunden.

http://picpaste.de/Routingumstellung...s-2vm5lV3S.png

bjo
19.12.12, 22:30
Zitat Zitat von strex
Das Problem werden wir in nächster Zeit noch vermehrt haben. Dazu gibt es einen netten Artikel in der letzten c´t. Die Anschlussanbieter wollen weg davon nur einen Internetanschluss anzubieten sondern Content wie im Kabelnetz verkaufen. Das wird wohl irgendwann dazu führen, dass wir zwei oder drei Anschlüsse benötigten um das gesamte Internet ausreichend zu erreichen. Denn nur wer an die Anbieter wie UPC oder Telekom bezahlt kann seine Angebote (youtube, online games,..) auch mit entsprechender Geschwindigkeit erreichen. Das google und co. dann bei mehreren bezahlen werden, bezweifle ich und auch die c´t. Also stellt euch lieber einmal ein auf ein getrenntes Internet mit mehreren Klassen. Das wird auch bei OVH der Fall sein, denn sie werden sich nicht weltweit bei jedem Anbieter Traffic einkaufen um deren Kunden (DSL, Kabel,...) zu erreichen. Aus diesem Grund sollte man sie einfach meiden und zu anderen wechseln auch wenn das mit Geschwindigkeitsverlust verbunden ist und somit Firmen wie UPC die Quittung ausstellen.
Ach, was waren das doch noch für schöne Zeiten mit BTX, Compuserve und AOL

Hook
19.12.12, 20:06
Kann ich bestätigen. Peering mit UPC ist teuer bzw. von UPC überhaupt nicht erwünscht mit ihren komischen Peering-Policies ....

Erfahrungen bei nem anderen Hoster (nicht OVH):
Traffic von meinen Servern in Frankfurt geht beispielsweise über Berlin -> Warschau, und dort erst ins UPC/Unitymedia Netz. Peering in Frankfurt will UPC anscheinend nicht.
Intern siehts bei denen aber auch nicht besser aus, dort herrscht mMn ein heilloses Durcheinander. Nach Österreich läuft der Traffic zurück nach Berlin -> Amsterdam -> London -> Frankfurt -> irgendwo nach Tschechien -> Wien .... (zumindest wenn man den Reverse-DNS Einträgen glauben darf, laut Pings könnte dies aber schon stimmen).
Aber Hauptsache in Frankfurt den Traffic nicht wollen ...

strex
16.12.12, 23:49
Unity Media bzw. UPC kann jederzeit das Routing verändern wenn sie wollen. Dazu gibt es keine Verträge, wie der Traffic gehandelt werden. Wenn Unity Media nicht mehr am DECIX Traffic austauschen will, können die das jederzeit machen. Da kann man keinen zwingen wie das Unternehmen so verfährt. Wie und wo Traffic getauscht wird, wird bei Peering Verträgen, wenn Sie eh explizit untereinander abgeschlossen sind nicht auf das Verfahren abgestimmt wie der Traffic zu tauschen ist. Also kann UPC machen was sie wollen, was sie auch tun.

Das Problem werden wir in nächster Zeit noch vermehrt haben. Dazu gibt es einen netten Artikel in der letzten c´t. Die Anschlussanbieter wollen weg davon nur einen Internetanschluss anzubieten sondern Content wie im Kabelnetz verkaufen. Das wird wohl irgendwann dazu führen, dass wir zwei oder drei Anschlüsse benötigten um das gesamte Internet ausreichend zu erreichen. Denn nur wer an die Anbieter wie UPC oder Telekom bezahlt kann seine Angebote (youtube, online games,..) auch mit entsprechender Geschwindigkeit erreichen. Das google und co. dann bei mehreren bezahlen werden, bezweifle ich und auch die c´t. Also stellt euch lieber einmal ein auf ein getrenntes Internet mit mehreren Klassen. Das wird auch bei OVH der Fall sein, denn sie werden sich nicht weltweit bei jedem Anbieter Traffic einkaufen um deren Kunden (DSL, Kabel,...) zu erreichen. Aus diesem Grund sollte man sie einfach meiden und zu anderen wechseln auch wenn das mit Geschwindigkeitsverlust verbunden ist und somit Firmen wie UPC die Quittung ausstellen.

kenshin
16.12.12, 19:11
Zitat Zitat von strex
Nur direkt für UPC Kunden in der Schweiz, wie es mit LGI generell (Deutschland etwa) aussieht wird, ist noch sehr vage. Da andere Provider die einen sehr guten Uplink zu UPC (Schweiz & Deutschland) hatten nun den Traffic auch über andere Länder austauschen wird das Thema noch sehr interessant. Ich denke das zu Januar es erst einmal die Schweizer Kunden verbessern wird, der Rest aber weiter in die Röhre schaut.

Eventuell wird es doch Zeit, möglichst schnell von UPC und deren Kabelnetze wegzukommen. UPC hat ja bestehende DECIX Peering Abkommen von Unity Media einfach abgebrochen und in LGI integriert. Dort hätte man auch bestehende Abkommen beibehalten können. Da sieht man aber wieder, dass es kein Problem der Serveranbieter sondern der von UPC ist. Sie wollen einfach ein lahmes Internet für Ihre Kunden. OVH sollte einfach einmal zeigen, dass es so nicht geht. Die Größe dafür hätten sie ja.
Was mich an der Stelle wundert is das sowas dann mitten im Monat passiert - man sollte meinen sowas beruht auf Verträgen, und das die mitten im Monat enden? ... Steck ich natürlich nicht drin, aber wundern tuts halt schon. Ich hätte sowas eher zu nem Monats oder Quartalsende erwartet oder eben passende zum Jahresende nun?

Caddy
16.12.12, 18:58
Zitat Zitat von strex
Nur direkt für UPC Kunden in der Schweiz, wie es mit LGI generell (Deutschland etwa) aussieht wird, ist noch sehr vage. Da andere Provider die einen sehr guten Uplink zu UPC (Schweiz & Deutschland) hatten nun den Traffic auch über andere Länder austauschen wird das Thema noch sehr interessant. Ich denke das zu Januar es erst einmal die Schweizer Kunden verbessern wird, der Rest aber weiter in die Röhre schaut.
Das wäre eigentlich die Frage, die nur Felix / OVH beantworten kann, denn es ging auch explizit um eine Verbesserung der Lage im Österreich Thread, nicht nur in der Schweiz.

Zitat Zitat von strex
Eventuell wird es doch Zeit, möglichst schnell von UPC und deren Kabelnetze wegzukommen. UPC hat ja bestehende DECIX Peering Abkommen von Unity Media einfach abgebrochen und in LGI integriert. Dort hätte man auch bestehende Abkommen beibehalten können. Da sieht man aber wieder, dass es kein Problem der Serveranbieter sondern der von UPC ist. Sie wollen einfach ein lahmes Internet für Ihre Kunden. OVH sollte einfach einmal zeigen, dass es so nicht geht. Die Größe dafür hätten sie ja.
Vielleicht tun sie das gerade. OVH war ja auch sehr schweigsam, was das Thema Österreich/Schweiz betrifft. Ich habe mich ja schon gewundert, dass ich von UPC überhaupt eine Antwort auf meine Anfrage bekommen habe. Meine weiterführende Frage auf deren Antwort schlummert allerdings noch "in der Bearbeitung", ich vermute auch, dass sie da auch weiter schlummert.

Ich für meinen Teil habe noch das unverschämte Glück, eine 6Mbit/s ADSL Leitung zuhause als Backup zu haben, zu unserem Gameserver in Roubaix1 habe ich über meinen internen Router die Route zu dem Server nun auf die ADSL Leitung gelegt.

http://s7.directupload.net/images/121216/kymts3vq.png

Zumindest kann ich jetzt wieder vernünftig zocken, wenn ich Bock habe.

Vielleicht verrät uns Felix / OVH ja noch, ob die Änderung im Januar global für LGI (Unitimedia, UPC, und bald auch KabelBW) gilt, oder nur einzelne Bereiche beinhaltet. Das würde mir die Entscheidung erleichtern, ob ich mir einen Traktor leihe und den VDSL Kasten 100m näher an mein Haus schleppe :-)

LG, Klaus

Eddy
16.12.12, 18:03
geholfen wäre evtl schon, wenn man in FFM den traffic zu Telia übergeben würde anstatt Tata.

Bei telia funktioniert die übergabe nach Aorta in FFM im gegensatz zu Tata, wo es nur von Aorta nach Tata direkt in ffm stattfindet.


1 ffm-bb2-link.telia.net (80.91.246.216) 0.495 ms ffm-bb2-link.telia.net (80.91.251.162) 25.038 ms ffm-bb1-link.telia.net (80.91.249.81) 10.777 ms
2 ffm-b2-link.telia.net (213.155.133.141) 0.807 ms ffm-b2-link.telia.net (80.91.252.174) 0.826 ms ffm-b2-link.telia.net (213.155.132.205) 2.354 ms
3 213.46.179.193.aorta.net (213.46.179.193) 0.803 ms 0.968 ms de-fra01a-ri2-xe-1-3-0.aorta.net (213.46.179.61) 15.918 ms
4 de-fra03a-rd1-xe-5-2-0.aorta.net (84.116.130.145) [AS 6830] 1.074 ms 84.116.132.173 (84.116.132.173) [AS 6830] 0.974 ms 84.116.132.145 (84.116.132.145) [AS 6830] 0.847 ms
MPLS Label=300256 CoS=0 TTL=1 S=1
5 84.116.133.113 (84.116.133.113) [AS 6830] 1.140 ms 84.116.133.117 (84.116.133.117) [AS 6830] 1.291 ms 1.257 ms
6 84-116-131-150.aorta.net (84.116.131.150) [AS 6830] 1.151 ms 2.915 ms 1.797 ms

strex
16.12.12, 18:00
Nur direkt für UPC Kunden in der Schweiz, wie es mit LGI generell (Deutschland etwa) aussieht wird, ist noch sehr vage. Da andere Provider die einen sehr guten Uplink zu UPC (Schweiz & Deutschland) hatten nun den Traffic auch über andere Länder austauschen wird das Thema noch sehr interessant. Ich denke das zu Januar es erst einmal die Schweizer Kunden verbessern wird, der Rest aber weiter in die Röhre schaut.

Eventuell wird es doch Zeit, möglichst schnell von UPC und deren Kabelnetze wegzukommen. UPC hat ja bestehende DECIX Peering Abkommen von Unity Media einfach abgebrochen und in LGI integriert. Dort hätte man auch bestehende Abkommen beibehalten können. Da sieht man aber wieder, dass es kein Problem der Serveranbieter sondern der von UPC ist. Sie wollen einfach ein lahmes Internet für Ihre Kunden. OVH sollte einfach einmal zeigen, dass es so nicht geht. Die Größe dafür hätten sie ja.

kenshin
16.12.12, 17:50
Für Januar waren ja größere Änderungen an der ganzen Geschichte angekündigt...

Eddy
16.12.12, 17:26
SO und schon merkt man die ersten auswirkungen.

Der Tata Link in fra-5-6k läuft auf beiden ports mit 97% last und die speed schwankt zwischen 13 und 40mbit.

Eddy
15.12.12, 18:03
Also früher ging das teilweise auch schon über Aorta(UPC)

Aber ebend nur dann, wenns anderweitig nicht zu erreichen war.

nun geht ja alles über Aorta und dann zu nem Transit/peer.

Die Pings sind teilweise wirklich drastisch gestiegen.

Zu OVH meine ich ist doppelt soviel nun und es gibt wie im Anfangs post geschrieben nun auch Packetloss.

Wenn das so bleibt steuern wir auf rosige zeiten zu....

gerry
15.12.12, 14:51
Zitat Zitat von bene
@kenshin:
Die sind nun UPC.
Und die integrieren eben jedes zugekaufte ASN in ihr AS-AORTA - leider
Wenn die Aorta verstopft ist, stirbt der Organismus.
Aber das werden die BWLer nicht kapieren, war ja nicht Bestandteil des Studiums...

Caddy
15.12.12, 02:18
http://de.wikipedia.org/wiki/Liberty_Global

Ich schrieb ja im Österreich Thread, dass ich mit Unitymedia quasi zum selben Konzern gehöre wie UPC. Leider habe ich jetzt wohl denselben Mist, wie die Österreicher und Schweizer... Meine Kupfer-Doppelader ist leider zu lang, Unitymedia ist der einzige Betreiber, der hier guten Speed anbieten konnte...

LG, Klaus

Edit:
Zum Vergleich:
01.03.2012:
http://www.speedtest.net/result/1805328550.png

15.12.2012:
http://www.speedtest.net/result/2373222901.png

kenshin
15.12.12, 00:24
ah, k. die Verbindung der Firmen war mir in dem Fall unklar.

bene
14.12.12, 23:53
@kenshin:
Die sind nun UPC.
Und die integrieren eben jedes zugekaufte ASN in ihr AS-AORTA - leider

kenshin
14.12.12, 23:42
kurz gesagt die möchten nun dieselbe A...tour fahren wie Telekom und UPC?

gerry
14.12.12, 21:39
Zitat Zitat von strex
Unitymedia wurde in das LGI Netz integriert, die eine andere Routing Policy verfolgen und den Traffic entsprechend routen möchte. KabelBW wird wohl als nächster folgen.
Danke für den Hinweis. Werd das im Bekanntenkreis im Auge behalten. Wenn die Kabelanbieter keinen ordentlichen Service liefern wollen, dann wird halt wieder auf die Kupfer-Doppelader gewechselt soweit sinnvoll machbar.

Die Preise sind ja auch nicht mehr so prickelnd seit der Fusion. Statt 32MBit down bekommt man jetzt halt 50, sobald man die aber nicht mehr ausreizen kann ist das auch nur Augenwischerei.

marius
14.12.12, 21:38
Und hier zum Vergleich noch KabelBW, wo alles noch normal ist:
http://bgp.he.net/AS29562

strex
14.12.12, 21:28
Einfach Peer Count anschauen, dass erklärt alles: http://bgp.he.net/AS20825

Caddy
14.12.12, 20:01
Zitat Zitat von strex
Mehr dazu im Hetzner Forum.
Hab ich keinen Account.
Ich stelle leider auch fest, dass (wie Du schon schriebst) so ziemlich alle Routen ziemlich kranke Wege gehen, es gibt nun DEN SELBEN Packet Loss wie auf den Routen über Wien im Österreich Thread, dessen "Schuldfrage" für mich ja nun relativ eindeutig geklärt ist. Ich hatte jahrelang keine Probleme mit Unitymedia, aber selbst die Routen nach Strato sind total krank und völlig inakzeptabel. Die Latenzzeiten sind völlig im Eimer.

LG, Klaus

strex
14.12.12, 18:51
Das ist kein Problem von OVH, selbes tritt auch bei Hetzner auf. Unitymedia wurde in das LGI Netz integriert, die eine andere Routing Policy verfolgen und den Traffic entsprechend routen möchte. KabelBW wird wohl als nächster folgen. LGI hat einen Anschluss am DECIX wollen aber den Traffic darüber nicht austauschen, deshalb erfolgen die Routen über das europäische Ausland etwa über Österreich. Mehr dazu im Hetzner Forum.

Caddy
14.12.12, 15:55
Hin:
Code:
Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 10.196.192.1                      0.0%   198   13.9   8.7   4.4  27.7   3.5
 2. 1214A-MX80-01-ae10-1010.wup.unit  0.0%   198   49.8  10.3   4.5  57.8   8.5
 3. 13NOC-MX960-01-ae2.krp.unity-med  0.0%   198    7.5   9.8   6.0  55.8   6.1
 4. 7111A-MX960-01-ae8.fra.unity-med  0.0%   198   18.5  14.1   9.4  69.2   6.9
 5. 84-116-131-149.aorta.net          7.1%   197   11.0  13.5   9.6  73.1   6.9
 6. de-fra01a-ri2-xe-5-1-1.aorta.net  0.0%   197   12.4  14.0  10.2  64.1   6.3
 7. 84.116.132.174                    0.0%   197   10.7  17.2   9.9  99.3  13.8
 8. 213.46.179.194.aorta.net          0.0%   197   16.7  15.2  10.0  64.8   6.2
 9. ffm-bb2-link.telia.net            0.0%   197   11.6  19.4  10.2 152.0  16.6
10. ffm-b10-link.telia.net            0.0%   197   14.5  14.2  10.2  52.7   5.4
    ffm-b10-link.telia.net
    ffm-b10-link.telia.net
    ffm-b10-link.telia.net
11. fra-5-6k.fr.eu                    4.1%   197   25.3  39.5  24.0 315.4  41.2
12. rbx-g2-a9.fr.eu                   3.6%   197   33.2  35.7  32.3  51.3   3.8
13. vss-3-6k.fr.eu                   21.4%   197   36.0  50.4  27.9 243.9  44.5
14. xxxxxxxxx.de                      5.1%   197   29.0  30.3  27.1  51.0   3.6
Zurück:
Code:
Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. rbx-6-m1.fr.eu                    0.0%     6    0.6   1.9   0.6   7.9   3.0
 2. rbx-1-6k.fr.eu                   16.7%     6  205.3  41.3   0.3 205.3  91.7
 3. rbx-g2-a9.fr.eu                   0.0%     6    0.9  24.5   0.6 142.8  58.0
 4. fra-5-6k.fr.eu                   66.7%     6    7.9   7.9   7.9   7.9   0.0
 5. tata.as6453.de.eu                 0.0%     6   16.3  10.7   8.1  16.3   3.2
 6. if-4-1108.tcore1.FNM-Frankfurt.a  0.0%     6    8.0   8.0   8.0   8.1   0.0
 7. if-5-2.tcore1.AV2-Amsterdam.as64  0.0%     6   46.1  18.9  11.8  46.1  13.6
 8. if-2-2.tcore2.AV2-Amsterdam.as64  0.0%     6   11.8  16.2  11.8  32.8   8.4
 9. if-7-2.tcore2.L78-London.as6453.  0.0%     6   12.2  12.1  11.7  13.1   0.5
10. Vlan756.icore2.LDN-London.as6453  0.0%     6   11.7  16.2  11.7  22.3   5.1
11. 213.46.179.105.aorta.net          0.0%     6   19.2  19.3  19.2  19.3   0.0
12. uk-lon01b-rd1-xe-7-0-0.aorta.net  0.0%     5   20.3  20.4  20.2  20.8   0.3
13. 1411g-mx960-02-ae3.neuss.unity-m 20.0%     5   26.1  26.0  26.0  26.2   0.1
14. 13NOC-MX960-02-ae9.krp.unity-med  0.0%     5   26.5  26.4  26.3  26.5   0.1
15. 13NOC-MX960-01-ae0.krp.unity-med  0.0%     5   26.2  27.0  26.2  29.8   1.6
16. 1214A-MX80-01-ae1.wup.unity-medi 20.0%     5   27.2  39.1  27.2  74.5  23.6
17. PH-1214A-uBR10k-01-Te-1-2-0-1010  0.0%     5   27.3  27.3  27.2  27.4   0.1
18. ip-109-90-xx-xx.unitymediagroup.  0.0%     5   32.6  36.1  32.6  45.1   5.4
Der "Kaputt" Zeitpunkt (12.12. ca. 0:00 Uhr):
http://s14.directupload.net/images/121214/3dysbckz.png

Man beachte den Packet Loss. Ist das so gewollt?
Das ging früher über De-Cix und hatte nur 8 Hops.

Gruß, Klaus