• Let op: Dit is het archief van het Provider Forum. De berichten die je hier ziet zijn gedateerd en er kan niet meer op worden gereageerd.

Heeftt UPC wat peering problemen in NL ?

Berichten
406
Internet
  1. Ziggo
Digitale TV
  1. Ziggo
Avond,

Merkte vanavond traagheid bij sites als webwereld en nu.nl. Tracerts laten nu ineens zien dat routes via Frankfurt en Cogentco gaan? Hebben meer mensen dit bemerkt?

Code:
Traceren van de route naar webwereld.nl [85.112.20.124]
via maximaal 30 hops:

  1   <1 ms   <1 ms   <1 ms  WL.arnhem.chello.nl [192.168.2.1]
  2    17 ms    19 ms    19 ms  10.15.92.129
  3    32 ms    21 ms    21 ms  p2129.net.upc.nl [212.142.2.129]
  4    15 ms    29 ms     9 ms  84.116.244.65
  5    37 ms    17 ms    21 ms  84-116-130-6.aorta.net [84.116.130.6]
  6     *        *        *     Time-out bij opdracht.
  7    30 ms    30 ms    25 ms  if-3-3205.tcore1.AV2-Amsterdam.as6453.net [195.219.150.94]
  8    33 ms    29 ms    30 ms  if-5-2.tcore1.FNM-Frankfurt.as6453.net [195.219.194.14]
  9    48 ms    39 ms    36 ms  if-7-2.tcore1.FR0-Frankfurt.as6453.net [195.219.50.1]
 10     *      257 ms   291 ms  te0-7-0-6.mpd22.fra03.atlas.cogentco.com [130.117.15.149]
 11     *        *      257 ms  te0-1-0-2.mpd22.ams03.atlas.cogentco.com [130.117.0.230]
 12   253 ms   260 ms     *     te1-1.mpd03.ams03.atlas.cogentco.com [130.117.0.242]
 13   129 ms   129 ms   133 ms  dedigate-nv.demarc.cogentco.com [130.117.241.86]
 14   132 ms   136 ms   128 ms  t9-3.gw1.ams2.terremark.net [85.112.0.73]
 15   134 ms   134 ms   132 ms  host008.85-112-20.ixs.dedigate.com [85.112.20.8]
 16   130 ms   126 ms   137 ms  host124.85-112-20.ixs.dedigate.com [85.112.20.124]

De trace is voltooid.
 
Tracing route to host124.85-112-20.ixs.dedigate.com [85.112.20.124]
over a maximum of 30 hops:

1 5 ms 5 ms 22 ms 10.15.xx.x
2 8 ms 7 ms 8 ms p3129.net.upc.nl [212.142.3.129]
3 19 ms 10 ms 10 ms 84.116.244.73
4 9 ms 9 ms 9 ms 84-116-131-13.aorta.net [84.116.131.13]
5 16 ms 9 ms 9 ms br1.ams.terremark.net [195.69.145.48]
6 11 ms 9 ms 10 ms t9-3.gw1.ams2.terremark.net [85.112.0.73]
7 10 ms 10 ms 9 ms host008.85-112-20.ixs.dedigate.com [85.112.20.8]
8 12 ms 10 ms 10 ms host124.85-112-20.ixs.dedigate.com [85.112.20.124]

Trace complete.

Hier (PC: 2986) dus een heel ander plaatje.
 
Zou best kunnen dat weer eens een ip range een probleem ondervind, dit is wel eens vaker gebeurt, meestal lost het vanzelf naar uurtje of 2 weer op.
 
Traceren van de route naar webwereld.nl [85.112.20.124]
via maximaal 30 hops:

1 3 ms <1 ms <1 ms WL.arnhem.chello.nl [192.168.2.1]
2 10 ms 10 ms 14 ms 10.15.92.129
3 9 ms 16 ms 39 ms p2129.net.upc.nl [212.142.2.129]
4 18 ms 14 ms 9 ms 84.116.244.65
5 18 ms 18 ms 18 ms 84-116-131-13.aorta.net [84.116.131.13]
6 16 ms 8 ms 13 ms br1.ams.terremark.net [195.69.145.48]
7 13 ms 19 ms 17 ms t9-3.gw1.ams2.terremark.net [85.112.0.73]
8 33 ms 18 ms 17 ms host008.85-112-20.ixs.dedigate.com [85.112.20.8]
9 19 ms 10 ms 19 ms host124.85-112-20.ixs.dedigate.com [85.112.20.124]

De trace is voltooid.
 
(alvast sorry van deze bump)

Ik huur al meer dan een jaar een dedicated 100/100 server bij i3d.net. Voorheen had ik hier geen problemen mee, maar sinds december ondervind ik hele hoge response tijden als gevolg van, naar mijn idee, slechte peering van upc. Doordeweeks begint dat rond 13:30 's middags en stopt pas weer rond 01:30 's nachts. Het weekend is nog veel erger. Dan begint het al om 10:00 's ochtends en heb ik weer een normale response tijd (20-25ms) rond de klok van 03:00 's nachts. (zie screenshot) Overdag zit ik opgescheept met een responsetijd van 120-300ms en trek dan maximaal 10mbit van de server, terwijl ik in de schare nachtelijke daluren de volle 60mbit van m'n upc-lijn kan gebruiken.

Hieronder een traceroute om bij een server in Rotterdam te komen. Hop #5 is Frankfurt, bij #8 naar Hamburg, terug naar #9 Amsterdam en uiteindelijk bij #12 in Rotterdam. (als ik het goed lees)

Code:
01. [10.15.17.1]
02. p6001.net.upc.nl [212.142.6.1]
03. [84.116.244.33]
04. 84-116-130-102.aorta.net [84.116.130.102]
05. de-fra01a-ri2-xe-4-0-1.aorta.net [84.116.133.110]
06. 213.46.179.6.aorta.net [213.46.179.6]
07. ffm-bb2-link.telia.net [80.91.252.175]
08. hbg-bb2-link.telia.net [80.91.245.118]
09. adm-bb4-link.telia.net [80.91.248.210]
10. adm-b5-link.telia.net [80.91.253.173]
11. interactive-ic-135079-adm-b5.c.telia.net [213.248.85.70]
12. 10ge-3-1.cr1.smartdc.rtd.as49544.net [188.122.95.70]
13. 10ge-5-1.br1.smartdc.rtd.as49544.net [188.122.95.83]
14. hosted-by.i3d.net [213.163.66.*]

Dat lijkt mij een hele omslachtige, onnodige route. Ik heb uitgebreid kunnen communiceren met mensen van i3d vanmiddag (dan merk je dat er ook supportdesks zijn die wel met 'moeilijkere materie' overweg kunnen) en ondervinden geen overbelasting binnen hun netwerk. Dit bevestigen ook de niet-upc lijnen die ik de server heb laten pingen en normale, lage responsetijden terugkregen. Sterker nog, i3D geeft aan dat ze al meerdere verzoeken voor een peering opzet bij UPC hebben ingediend, maar worden genegeerd om ze een te kleine speler in die markt zijn. Nu weet ik wel aardig wat, althans ik ga al wat jaartjes mee, maar ik heb werkelijk geen idee hoeveel moeite en/of geld zoiets kost, maar het klinkt als een makkelijke klus. :) Misschien dat 1 van de aanwezige upc-technici hierop zou willen antwoorden. Niet per se bij mij, dat mag ook bij i3D. Ik ben zelf geen gamer (meer), maar kan me voorstellen dat er een aantal upc-gebruikers hinder moeten ondervinden op de gameservers van i3d.

Onderstaand screenshot is opgenomen tussen zaterdagavond 19-feb 20:30 en zondagmorgen 20-feb 03:30. Om de 15 seconden is er een traceroute uitgevoerd naar de server. Het is misschien slecht te zien, maar de hoge lijn ligt rond de 120ms met vanavond als uitschieter 142ms. Rond 02:00 zie je de responsetijd afnemen en om uiteindelijk 03:00 heb ik de normale 20-25ms weer terug. De rode lijntjes in de onderste grafiek zijn complete drops. (niet bereikbaar - timeout) Klik op de image voor een 1:1 versie.



Ik heb deze keer een 62.194.* ipadres van upc, en voorheen had ik altijd een 77.249.* adres. Zijn er meer mensen die hetzelfde ervaren, misschien uit dezelfde ip-reeks? Liever nog dat 1 van de upc-forummembers met inzicht in deze materie tijd zou willen maken om er naar te kijken, danwel een antwoord te geven. Misschien is het overbodig om te vermelden, maar ik ben recentelijk niet van abbo-vorm oid gewisseld en ik heb er al wat jaartjes (bijna) probleemloos upc opzitten. (zie mijn postcount :))

Dan ga ik nu een grote file van de server binnentrekken, om nog enigzins van die 60mbit upc en de dedicated server te kunnen genieten...


Zelfs als ik 60mbit vol dichttrek, blijf ik 2x zo lage responsetijden houden dan degene die ik normaal overdag heb zonder iets te doen.
 
YEHEZ! zei:
Ik huur al meer dan een jaar een dedicated 100/100 server bij i3d.net.

Noticed the same thing when I rented a BFBC2 server there and I still see it in the TS server I rent from them. It used to go through level3 if I recall correctly.

Code:
Tracing route to i3d.net [188.122.94.99]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     4 ms     3 ms     7 ms  10.15.161.129
  3     5 ms     5 ms     6 ms  p8129.net.upc.nl [212.142.8.129]
  4    19 ms    17 ms    17 ms  nl-ams05a-rd2-ae-20-2365.aorta.net [84.116.244.61]
  5    17 ms    24 ms    17 ms  uk-lon01b-rd1-xe-0-3-0.aorta.net [84.116.133.222]
  6    18 ms    17 ms    17 ms  84.116.134.34
  7    18 ms    17 ms    17 ms  ldn-b5-link.telia.net [213.248.96.89]
  8    17 ms    19 ms    15 ms  ldn-bb2-link.telia.net [80.91.250.169]
  9    20 ms    20 ms    20 ms  adm-bb4-link.telia.net [80.91.250.126]
 10    16 ms    15 ms    16 ms  adm-b5-link.telia.net [80.91.253.160]
 11    23 ms    17 ms    24 ms  interactive-ic-135079-adm-b5.c.telia.net [213.248.85.70]
 12    21 ms    19 ms    20 ms  10ge-3-1.cr1.smartdc.rtd.as49544.net [188.122.95.70]
 13    17 ms    17 ms    17 ms  10ge-5-1.br1.smartdc.rtd.as49544.net [188.122.95.83]
 14    21 ms    21 ms    21 ms  www.i3d.net [188.122.94.99]

Trace complete.
 
Ik ervaarde hetzelfde met een OVH colo host. Traceroute's daarvandaan naar UPC gingen via veel langere routes, met veel langere responstijden. Traceroutes naar XMSnet gingen met een kortere route en snellere responses.

(dit is van 19 januari)
OVH->UPC
traceroute to UPC (xxxxxx), 30 hops max, 60 byte packets
1 rbx-20-m2.fr.eu (91.121.75.252) 0.568 ms 1.155 ms 1.498 ms
2 rbx-2-6k.fr.eu (213.251.191.130) 0.247 ms * *
3 * * *
4 gblx.as3549.fr.eu (213.186.32.129) 4.130 ms 4.163 ms 4.202 ms
5 upc-1.ar6.lon3.gblx.net (64.212.107.14) 23.182 ms * 23.188 ms
6 84.116.132.61 (84.116.132.61) 21.165 ms 32.861 ms 21.518 ms
7 nl-ams02a-rd1-tg-0-6-0-5.aorta.net (84.116.130.33) 26.255 ms 26.250 ms 26.247 ms
8 84.116.244.34 (84.116.244.34) 22.371 ms 22.135 ms 22.227 ms
9 p6014.net.upc.nl (212.142.6.14) 19.817 ms 19.828 ms 19.821 ms
10 UPC (xxxxxxxx) 47.245 ms !X 41.310 ms !X 27.403 ms !X

OVH->XMSnet
traceroute to XMSnet (xxxxxx2), 30 hops max, 60 byte packets
1 rbx-20-m2.fr.eu (91.121.75.252) 1.466 ms 1.664 ms 1.924 ms
2 rbx-1-6k.fr.eu (213.251.191.1) 0.542 ms * *
3 ams-5-6k.nl.eu (213.251.130.66) 5.807 ms * *
4 pr1.nik-asd.internl.net (195.69.144.204) 5.978 ms 6.027 ms 6.032 ms
5 217.149.196.102 (217.149.196.102) 6.222 ms 6.115 ms 6.225 ms
6 XMSnet (xxxxxx2) 8.995 ms 9.590 ms 9.038 ms

Dat zijn een 4 tal hops minder, plus het gaat van OVH->XMSnet een stuk sneller
 
Hier ook problemen. Heb gelukkig net op tijd het opzeggen van mijn adsl lijn kunnen cancellen. UPC moet er snel iets aan doen anders dan kunnen ze de boel terug krijgen.
 
Terug
Bovenaan