Slechte peering naar AS6453 / Hetzner toe

[Sanderluc]

Ik ervaar de laatste dagen hele slechte peering naar Hetzner toe.
Dit probleem lijkt zich vooral voor te doen op een AMX knooppunt die zich in amsterdam bevind. Hierdoor valt mijn verbinding telkens weg naar Hetzner toe. Mogelijk speelt dit probleem bij nog veel meer websites die zich ergens bij Hetzner en/of Duitsland bevinden.

Ook is de ping 68 ms abnormaal hoog. Dit is normaal rond de 30.

Zijn er meer mensen die problemen ervaren met dit connectpunt?

code:

Tracing route to hetzner.nl [213.133.107.241]
over a maximum of 30 hops:

  1     2 ms     1 ms     1 ms  10.0.0.1
  2    11 ms    11 ms    10 ms  10.255.166.1
  3    16 ms    15 ms    12 ms  213.51.192.185
  4    27 ms    19 ms    18 ms  asd-rc0001-cr101-be150-10.core.as9143.net [213.51.158.20]
  5    26 ms    16 ms    22 ms  nl-ams04a-ri3-ae50-0.aorta.net [213.51.64.66]
  6    21 ms    16 ms    14 ms  ix-ae-30-0.tcore1.ad1-amsterdam.as6453.net [80.231.80.30]
  7    57 ms    58 ms    58 ms  if-ae-7-3.tcore1.av2-amsterdam.as6453.net [80.231.80.57]
  8    62 ms    65 ms    56 ms  if-ae-17-79.tcore2.fnm-frankfurt.as6453.net [195.219.194.63]
  9    62 ms    64 ms    57 ms  if-ae-59-2.tcore1.fr0-frankfurt.as6453.net [195.219.87.195]
 10    60 ms    67 ms    57 ms  195.219.219.10
 11    62 ms    63 ms    63 ms  core12.nbg1.hetzner.com [213.239.245.246]
 12    62 ms    65 ms    60 ms  ex9k2.dc1.nbg1.hetzner.com [213.239.203.218]
 13    62 ms    64 ms    61 ms  dedihetzner.your-server.de [213.133.107.241]

Trace complete.

Foto: Van wegvallende connectie
https://prnt.sc/s4ru9e

[Freeaqingme]

Ik zie hier vanaf Ziggo (AS9143) hetzelfde. Het lijkt fout te gaan rond hop 10, waar de latency rond hop 10 ineens naar de 58ms schiet. Aan de hand van de hostnames lijkt dat AS6453 (Tata Communications) te zijn. Jij hebt geen relatie met hen, maar dat hebben Ziggo en Hetzner beiden wel. Als je klant bent bij Hetzner zou ik eens aan hen vragen of ze contact op willen nemen met Tata.

[Sanderluc]

Freeaqingme schreef op donderdag 23 april 2020 @ 19:15:
Ik zie hier vanaf Ziggo (AS9143) hetzelfde. Het lijkt fout te gaan rond hop 10, waar de latency rond hop 10 ineens naar de 58ms schiet. Aan de hand van de hostnames lijkt dat AS6453 (Tata Communications) te zijn. Jij hebt geen relatie met hen, maar dat hebben Ziggo en Hetzner beiden wel. Als je klant bent bij Hetzner zou ik eens aan hen vragen of ze contact op willen nemen met Tata.

Ja erg vervelend, ik vrees dat ik hier weinig mee zal bereiken. Kennende hoe de support overal is.

Ik heb een vriend van mij ook laten tracen naar hetzner.nl, echter neemt het netwerk van KPN waarbij hij zit een kortere route ernaar toe. Die connectie lijkt veel directer te zijn. Vreemd dat Ziggo dan helemaal een omweg neemt richting die servers in Amsterdam.

[ Voor 5% gewijzigd door Sanderluc op 23-04-2020 19:23 ]

[SMSfreakie]

hier ook vanaf Ziggo direct een latency van rond de 65~70

via VPN, endpoints in Amsterdam, Parijs & Isle of Man leveren betere latency op..tussen de 25 en 40ms
lijkt er dus inderdaad op dat de verbinding tussen Ziggo < -> Tata Com. <-> hetzner moeilijk doet..

[Freeaqingme]

Sanderluc schreef op donderdag 23 april 2020 @ 19:21:
[...]


Ja erg vervelend, ik vrees dat ik hier weinig mee zal bereiken. Kennende hoe de support overal is.

Wat bedoel je met 'overal'? Ik heb in het verleden wel bij een ISP gewerkt, en daar kwam het ook wel eens voor dat iemand ons attenderdeerde op een wat ongelukkige route. Als we daar dan op gewezen werden konden we - al dan niet via onze transitpartijen - kijken wat we daar aan konden doen. Je kan als ISP nou eenmaal niet het internet naar _alles_ monitoren.

Ik heb zelf ook wel eens een bedrijf vergelijkbaar met Hetzner er op gewezen. Ik kreeg toen een heel duidelijke uitleg dat de route frankfurt - amsterdam - london - parijs - frankfurt inderdaad wat ongelukkig was, en dat men dat ging oppakken. Week later ging ik van 50ms naar <1ms.

Mijn suggestie om het via Hetzner te spelen is dat ik denk dat de eerste lijn van ziggo nog wat minder technisch is. Essentieel is in ieder geval dat je de traceroute output meestuurt.

Sanderluc schreef op donderdag 23 april 2020 @ 19:21:
[...]

Vreemd dat Ziggo dan helemaal een omweg neemt richting die servers in Amsterdam.

Da's niet heel gek. Ziggo zal bij Tata transit diensten afnemen, en dat doet Hetzner ook. Vervolgens heeft Tata ergens een foutje gmeaakt, of er wordt ergens wat 'subtiele druk' uitgeoefend om 1 van die klanten op een ander contract over te krijgen. Heel veel opties, maar vanuit het perspectief van Hetzner alsook dat van Ziggo zal het gewoon transit zijn.

[Sanderluc]

Freeaqingme schreef op donderdag 23 april 2020 @ 19:36:
[...]


Wat bedoel je met 'overal'? Ik heb in het verleden wel bij een ISP gewerkt, en daar kwam het ook wel eens voor dat iemand ons attenderdeerde op een wat ongelukkige route. Als we daar dan op gewezen werden konden we - al dan niet via onze transitpartijen - kijken wat we daar aan konden doen. Je kan als ISP nou eenmaal niet het internet naar _alles_ monitoren.

Ik heb zelf ook wel eens een bedrijf vergelijkbaar met Hetzner er op gewezen. Ik kreeg toen een heel duidelijke uitleg dat de route frankfurt - amsterdam - london - parijs - frankfurt inderdaad wat ongelukkig was, en dat men dat ging oppakken. Week later ging ik van 50ms naar <1ms.

Mijn suggestie om het via Hetzner te spelen is dat ik denk dat de eerste lijn van ziggo nog wat minder technisch is. Essentieel is in ieder geval dat je de traceroute output meestuurt.


[...]


Da's niet heel gek. Ziggo zal bij Tata transit diensten afnemen, en dat doet Hetzner ook. Vervolgens heeft Tata ergens een foutje gmeaakt, of er wordt ergens wat 'subtiele druk' uitgeoefend om 1 van die klanten op een ander contract over te krijgen. Heel veel opties, maar vanuit het perspectief van Hetzner alsook dat van Ziggo zal het gewoon transit zijn.

Bedankt voor je bericht.
Dit verklaard al een stuk meer...

Ik heb in het verleden wel eens contact gehad met verschillende bedrijven, echter als de vraag al iets te technisch werd, dan werd ik al meerdere keren doorverbonden, vervolgens leidde dit uiteindelijk tot niks of dan zouden ze erna kijken en dan hoor je vervolgens niks. Maar dat zal wel komen omdat ik als particulier bel en dat minder serieus genomen wordt.

In iedergeval, ik zal Hetzner hierover gaan mailen en hopelijk kunnen ze dit oplossen.

[c-nan]

Aan een 1 weg traceroute heb je niet heel veel. De terugweg kan namelijk een ander pad pakken. Beste is een bidirectionele MTR.
Beschik je tot een server bij hetzner?

[Freeaqingme]

c-nan schreef op donderdag 23 april 2020 @ 19:54:
Aan een 1 weg traceroute heb je niet heel veel. De terugweg kan namelijk een ander pad pakken. Beste is een bidirectionele MTR.
Beschik je tot een server bij hetzner?

In een ideale wereld zijn alle routes symmetrisch. Maar het is wel een goed punt. Voor hetzelfde geld gaat de terugweg via Timbuktu, en verklaart dat de vertraging. Denk het in dit geval niet, maar uitsluiten kan geen kwaad.

[Dr Pro]

Dit is het bij mij (T-Mobile)

code:

C:\WINDOWS\system32>tracert -d hetzner.nl

Tracing route to hetzner.nl [213.133.107.241]
over a maximum of 30 hops:

  1     1 ms     1 ms     1 ms  192.168.59.1
  2     4 ms     3 ms     5 ms  31.201.2.1
  3     9 ms     9 ms     9 ms  10.10.80.98
  4     9 ms     9 ms     9 ms  80.249.209.55
  5    16 ms    16 ms    16 ms  213.239.245.14
  6    19 ms    20 ms    19 ms  213.239.252.26
  7    19 ms    20 ms    19 ms  213.239.203.218
  8    18 ms    18 ms    18 ms  213.133.107.241

Trace complete.

[SMSfreakie]

code:

traceroute to hetzner.nl (213.133.107.241), 64 hops max, 40 byte packets
 1  10.255.98.1 (10.255.98.1)  7.145 ms  14.130 ms  8.174 ms
 2  213.51.193.153 (213.51.193.153)  23.124 ms  17.724 ms  8.863 ms
 3  asd-rc0001-cr101-be150-10.core.as9143.net (213.51.158.20)  13.379 ms  10.753 ms  12.293 ms
 4  nl-ams04a-ri3-ae50-0.aorta.net (213.51.64.66)  13.032 ms  22.012 ms  10.783 ms
 5  ix-ae-30-0.tcore1.ad1-amsterdam.as6453.net (80.231.80.30)  12.281 ms  17.183 ms  13.014 ms
 6  if-ae-2-33.tcore1.av2-amsterdam.as6453.net (195.219.150.114)  50.415 ms
    if-ae-7-4.tcore1.av2-amsterdam.as6453.net (80.231.80.59)  49.047 ms
    if-ae-7-2.tcore1.av2-amsterdam.as6453.net (195.219.194.45)  48.686 ms
 7  if-ae-12-12.tcore1.fnm-frankfurt.as6453.net (195.219.194.60)  50.208 ms
    if-ae-17-69.tcore2.fnm-frankfurt.as6453.net (195.219.194.25)  51.171 ms
    if-ae-12-12.tcore1.fnm-frankfurt.as6453.net (195.219.194.60)  43.568 ms
 8  if-ina-2.tcore1.fr0-frankfurt.as6453.net (5.23.30.17)  43.899 ms
    if-ae-59-2.tcore1.fr0-frankfurt.as6453.net (195.219.87.195)  42.754 ms
    if-ae-4-2.tcore1.fr0-frankfurt.as6453.net (195.219.87.18)  52.980 ms
 9  195.219.219.10 (195.219.219.10)  40.995 ms
    if-ae-45-2.tcore1.fr0-frankfurt.as6453.net (195.219.50.20)  48.671 ms
    195.219.219.10 (195.219.219.10)  55.653 ms
10  core12.nbg1.hetzner.com (213.239.245.246)  46.652 ms
    195.219.219.10 (195.219.219.10)  42.105 ms
    core12.nbg1.hetzner.com (213.239.245.246)  46.347 ms
11  core11.nbg1.hetzner.com (213.239.245.34)  47.518 ms
    core12.nbg1.hetzner.com (213.239.245.246)  46.790 ms
    ex9k2.dc1.nbg1.hetzner.com (213.239.203.218)  52.175 ms
12  * ex9k2.dc1.nbg1.hetzner.com (213.239.203.214)  49.366 ms *
13  * * *

op BSD krijg ik sowieso al een andere output dan op Windows 10

code:

  1     1 ms     1 ms     1 ms  192.168.10.1
  2     6 ms     7 ms     7 ms  10.255.98.1
  3    10 ms    12 ms    11 ms  213.51.193.153
  4    12 ms    18 ms    13 ms  asd-rc0001-cr101-be150-10.core.as9143.net [213.51.158.20]
  5    13 ms    20 ms    12 ms  nl-ams04a-ri3-ae50-0.aorta.net [213.51.64.66]
  6    14 ms    14 ms    15 ms  ix-ae-30-0.tcore1.ad1-amsterdam.as6453.net [80.231.80.30]
  7    50 ms    49 ms    49 ms  if-ae-2-33.tcore1.av2-amsterdam.as6453.net [195.219.150.114]
  8    54 ms    45 ms    46 ms  if-ae-12-12.tcore1.fnm-frankfurt.as6453.net [195.219.194.60]
  9    44 ms    45 ms    45 ms  if-ae-9-2.tcore2.fr0-frankfurt.as6453.net [5.23.30.17]
 10    47 ms    44 ms    47 ms  if-ae-45-2.tcore1.fr0-frankfurt.as6453.net [195.219.50.20]
 11    45 ms    46 ms    56 ms  195.219.219.10
 12    47 ms    46 ms    47 ms  core11.nbg1.hetzner.com [213.239.245.34]
 13    47 ms    47 ms    50 ms  ex9k2.dc1.nbg1.hetzner.com [213.239.203.214]
 14    48 ms    49 ms    48 ms  dedihetzner.your-server.de [213.133.107.241]

[Sanderluc]

c-nan schreef op donderdag 23 april 2020 @ 19:54:
Aan een 1 weg traceroute heb je niet heel veel. De terugweg kan namelijk een ander pad pakken. Beste is een bidirectionele MTR.
Beschik je tot een server bij hetzner?

Ik heb van beide kanten nog even getest.
De dipjes lijken voorbij en de ping is nu 50 vanaf beide kanten. Dit is al een stuk acceptabeler, toch lijkt mij 50 ms nog steeds aan de hogere kant, omdat je bij andere providers makkelijk de 20 ms kan aantikken.

Dit is de traceroute vanaf mijn Hetzner server naar mijn thuisverbinding:

code:

Tracing route to 82.73.xx.xx
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  static.xxx.xxx.9.5.clients.your-server.de [5.9.xxx.xxx]
  2    20 ms    <1 ms    <1 ms  static.1.198.202.116.clients.your-server.de [116.202.198.1]
  3    <1 ms    <1 ms    <1 ms  core23.fsn1.hetzner.com [213.239.245.41]
  4     5 ms     5 ms     5 ms  core4.fra.hetzner.com [213.239.229.73]
  5     5 ms     5 ms     5 ms  ix-ae-55-0.tcore1.fr0-frankfurt.as6453.net [195.219.219.9]
  6     5 ms     5 ms     5 ms  de-fra03b-ri1-ae-24-0.aorta.net [213.46.179.137]
  7    50 ms    36 ms    36 ms  de-fra01b-rc1-ae-3-0.aorta.net [84.116.132.177]
  8     *       41 ms    41 ms  nl-ams17b-rc1-lag-40-0.aorta.net [84.116.130.9]
  9    46 ms    47 ms    47 ms  asd-rc0001-cr101-be61-2.core.as33915.net [213.51.64.33]
 10    40 ms    40 ms    40 ms  asn-rc0002-cr101-new-et2-2.core.as33915.net [213.51.5.1]
 11    41 ms    41 ms    41 ms  213.51.192.186
 12    50 ms    50 ms    49 ms  82-73-xxx-xxx.cable.dynamic.v4.ziggo.nl [82.73.xx.xx]

Trace complete.

[Kanarie]

Ik ben al 10 jaar klant bij Hetzner en ze hebben regelmatig ruzie met ISPs (T-Mobile en LibertyGlobal/UPC wat vaker dan anderen), sinds vandaag 13:00 is het weer bagger voor Ziggo klanten.



De komende dagen/weken zal er wel weer geruzied worden over wie gaat betalen voor het upgraden van een link o.i.d., dat is vaak de reden voor deze bizarre pings en loss statistieken.

[ Voor 27% gewijzigd door Kanarie op 23-04-2020 20:59 ]

[c-nan]

Freeaqingme schreef op donderdag 23 april 2020 @ 20:03:
[...]


In een ideale wereld zijn alle routes symmetrisch. Maar het is wel een goed punt. Voor hetzelfde geld gaat de terugweg via Timbuktu, en verklaart dat de vertraging. Denk het in dit geval niet, maar uitsluiten kan geen kwaad.

Die ideale wereld is er niet. Een ISP kan bepalen hoe hij zijn verkeer naar buiten routeert, maar niet via welk route het binnenkomt.

Het gaat mij niet om of het via Timboektoe gaat, maar via netwerken. Je heen weg kan prima zijn, terwijl je terugweg dat niet is (of andersom).

Hetzner kan niet bepalen dat jouw verkeer via een bepaalde route hun kant op komt. Enkel het terugweg verkeer kunnen ze bepalen.

Wat ze wel kunnen is hun lijntjes uitbreiden, maar dan nog kan het bijvoorbeeld prima aan je eigen provider liggen omdat zij geen dikkere pijpen/afspraken willen.

[ChaserBoZ_]

c-nan schreef op donderdag 23 april 2020 @ 21:20:
[...]
Die ideale wereld is er niet. Een ISP kan bepalen hoe hij zijn verkeer naar buiten routeert, maar niet via welk route het binnenkomt.

Het gaat mij niet om of het via Timboektoe gaat, maar via netwerken. Je heen weg kan prima zijn, terwijl je terugweg dat niet is (of andersom).

Hetzner kan niet bepalen dat jouw verkeer via een bepaalde route hun kant op komt. Enkel het terugweg verkeer kunnen ze bepalen.

Wat ze wel kunnen is hun lijntjes uitbreiden, maar dan nog kan het bijvoorbeeld prima aan je eigen provider liggen omdat zij geen dikkere pijpen/afspraken willen.

Er zijn instellingen voor om, als je een redundant pad hebt, het ene pad boven het andere te laten verkiezen. Negeert 'de andere kant' dat, dan werkt dat niet uiteraard.

Voor traceroute's heen en weer, kijk eens of Hetzner een LookingGlass heeft . . .

[Zenix]

Het ligt in niet aan Hetzner. Die zijn prima te bereiken via IXP's, alleen Liberty global zal wel niet met ze willen peeren, waardoor het via transit moet. Dus ik zou vooral bij Ziggo klagen.

Met Tweak gaat het ook goed. Dat AS nummer is van Tata, dit is Hetzner.

https://bgp.he.net/AS24940#_asinfo Zoals je kan zien zijn ze aanwezig op de AMS-IX, NL-IX en SPEED-IX. Zonde dat het verkeer dan via transit moet.

Het probleem is dus https://bgp.he.net/AS6830 waarschijnlijk is het opgelost als ze andere transit partij gebruiken voor die route. Maar het zal nooit zo goed worden als direct via een IXP.

[ Voor 49% gewijzigd door Zenix op 23-04-2020 23:24 ]

[c-nan]

Zenix schreef op donderdag 23 april 2020 @ 23:13:
Het ligt in niet aan Hetzner. Die zijn prima te bereiken via IXP's, alleen Liberty global zal wel niet met ze willen peeren, waardoor het via transit moet. Dus ik zou vooral bij Ziggo klagen.

Met Tweak gaat het ook goed. Dat AS nummer is van Tata, dit is Hetzner.

https://bgp.he.net/AS24940#_asinfo Zoals je kan zien zijn ze aanwezig op de AMS-IX, NL-IX en SPEED-IX. Zonde dat het verkeer dan via transit moet.

Van AS9143 (Ziggo) naar AS6453 (TATA Amsterdam) zit het probleem niet, maar van AS6453 (TATA Amsterdam) naar AS6453 (TATA Frankfurt) wel.

[d-Frag]

Zenix schreef op donderdag 23 april 2020 @ 23:13:
Het ligt in niet aan Hetzner. Die zijn prima te bereiken via IXP's, alleen Liberty global zal wel niet met ze willen peeren, waardoor het via transit moet. Dus ik zou vooral bij Ziggo klagen.

Ook niet perse waar, via twee routes gekeken en ik zie de spikes in dezelfde node van Hetzner...

KPN International:
Looking Glass - traceroute 213.133.107.241 as-number-lookup inet wait 1
Location: Route-Server Amsterdam (Juniper)

1 asd2-rou-1043.NL.eurorings.net (62.132.1.6) 0.723 ms 0.433 ms 0.393 ms
2 asd2-rou-1022.NL.eurorings.net (134.222.48.222) 1.217 ms 1.353 ms 1.131 ms
MPLS Label=300544 CoS=0 TTL=1 S=1
3 asd-s7-rou-1042.NL.eurorings.net (134.222.48.239) 1.567 ms 0.988 ms 0.988 ms
MPLS Label=299776 CoS=0 TTL=1 S=1
4 asd-s17-rou-1041.NL.eurorings.net (134.222.48.237) 1.514 ms 0.964 ms 0.930 ms
5 ae-6.r25.amstnl02.nl.bb.gin.ntt.net (80.249.208.36) 11.079 ms 2.002 ms 2.034 ms
6 ae-18.r25.amstnl02.nl.bb.gin.ntt.net (129.250.2.108) [AS 2914] 1.924 ms 9.399 ms 1.896 ms
MPLS Label=319572 CoS=0 TTL=1 S=1
7 ae-17.r21.frnkge13.de.bb.gin.ntt.net (129.250.3.76) [AS 2914] 14.885 ms 27.789 ms 10.814 ms
MPLS Label=441 CoS=0 TTL=1 S=1
8 ae-8.r01.frnkge13.de.bb.gin.ntt.net (129.250.6.51) [AS 2914] 10.366 ms 11.994 ms 10.347 ms
9 213.198.82.130 (213.198.82.130) [AS 2914] 16.864 ms 11.850 ms 10.900 ms
10 core12.nbg1.hetzner.com (213.239.252.26) [AS 24940] 14.532 ms core11.nbg1.hetzner.com (213.239.252.22) [AS 24940] 48.048 ms 82.966 ms
11 ex9k2.dc1.nbg1.hetzner.com (213.239.203.218) [AS 24940] 16.088 ms 14.932 ms ex9k2.dc1.nbg1.hetzner.com (213.239.203.214) [AS 24940] 13.061 ms

Ziggo (thuis)
Tracing route to hetzner.nl [213.133.107.241]
over a maximum of 30 hops:

1 3 ms 2 ms 1 ms <cemsored>
2 12 ms 12 ms 20 ms <cemsored>
3 13 ms 14 ms 20 ms <cemsored>
4 13 ms 16 ms 13 ms nl-ams04a-ri3-ae50-0.aorta.net [213.51.64.66]
5 16 ms 14 ms 13 ms ix-ae-30-0.tcore1.ad1-amsterdam.as6453.net [80.231.80.30]
6 35 ms 36 ms 34 ms if-ae-2-33.tcore1.av2-amsterdam.as6453.net [195.219.150.114]
7 36 ms 64 ms 54 ms if-ae-17-69.tcore2.fnm-frankfurt.as6453.net [195.219.194.25]
8 34 ms 34 ms 35 ms if-ae-59-2.tcore1.fr0-frankfurt.as6453.net [195.219.87.195]
9 36 ms 35 ms 34 ms 195.219.219.10
10 39 ms 39 ms 47 ms core12.nbg1.hetzner.com [213.239.245.246]
11 37 ms 37 ms 38 ms ex9k2.dc1.nbg1.hetzner.com [213.239.203.218]
12 50 ms 51 ms 37 ms dedihetzner.your-server.de [213.133.107.241]

[Zenix]

Dat klopt, maar alsnog zou dit geen probleem zijn als de grote ISP's gewoon peeren via IXP's als die mogelijkheid er is.

Kanarie schreef op donderdag 23 april 2020 @ 20:59:
Ik ben al 10 jaar klant bij Hetzner en ze hebben regelmatig ruzie met ISPs (T-Mobile en LibertyGlobal/UPC wat vaker dan anderen), sinds vandaag 13:00 is het weer bagger voor Ziggo klanten.

[Afbeelding]

De komende dagen/weken zal er wel weer geruzied worden over wie gaat betalen voor het upgraden van een link o.i.d., dat is vaak de reden voor deze bizarre pings en loss statistieken.

Dit inderdaad. Bij mijn Tweak verbinding gaat het direct via Speed-IX. Ik was aan het gamen met 20ping op een Hetzner server, terwijl het voor de Ziggo klanten niet te doen was. Het is triest dat een kleine ISP een veel betere ervaring kan leveren dan een grote, daarbij gaat het alleen maar om geld.

Dus ik blijf wel bij mijn mening dat het bij Ziggo zit, want transit is niet nodig.

Overigens is AS9143 gemigreerd naar AS33915 en die is weer gekoppeld aan AS6830 https://bgp.he.net/AS33915#_graph4

Ook leuk om te lezen: https://wiki.hetzner.de/index.php/Peering_Policy/en Een open peering policy hebben ze, vooral het transit stuk is hier van toepassing.

[ Voor 11% gewijzigd door Zenix op 24-04-2020 00:08 ]

[ChaserBoZ_]

Zenix schreef op donderdag 23 april 2020 @ 23:43:
Dat klopt, maar alsnog zou dit geen probleem zijn als de grote ISP's gewoon peeren via IXP's als die mogelijkheid er is.


[...]


Dit inderdaad. Bij mijn Tweak verbinding gaat het direct via Speed-IX. Ik was aan het gamen met 20ping op een Hetzner server, terwijl het voor de Ziggo klanten niet te doen was. Het is triest dat een kleine ISP een veel betere ervaring kan leveren dan een grote, daarbij gaat het alleen maar om geld.

Dus ik blijf wel bij mijn mening dat het bij Ziggo zit, want transit is niet nodig.

Overigens is AS9143 gemigreerd naar AS33915 en die is weer gekoppeld aan AS6830 https://bgp.he.net/AS33915#_graph4

Ook leuk om te lezen: https://wiki.hetzner.de/index.php/Peering_Policy/en Een open peering policy hebben ze, vooral het transit stuk is hier van toepassing.

Voor die kleine partijen gaat het indirect ook om geld waarschijnlijk; met lage volumes betalen die veel meer voor een Megabit transit. Ziggo koopt per 10 of 100 Gigabit in, dan kost je dat een paar dubbeltjes per Mbps hooguit. Koop je heel weinig in, dan wordt dat een factor x hiervan.

Direct peeren zie je daarom bij heel veel kleine/middelgrote clubjes, terwijl de giganten juist transit willen gebruiken.

Vergis je niet in de tijd en kennis nodig om een hele hoop peerings te bouwen & te onderhouden.

[Zenix]

ChaserBoZ_ schreef op vrijdag 24 april 2020 @ 11:12:
[...]


Voor die kleine partijen gaat het indirect ook om geld waarschijnlijk; met lage volumes betalen die veel meer voor een Megabit transit. Ziggo koopt per 10 of 100 Gigabit in, dan kost je dat een paar dubbeltjes per Mbps hooguit. Koop je heel weinig in, dan wordt dat een factor x hiervan.

Direct peeren zie je daarom bij heel veel kleine/middelgrote clubjes, terwijl de giganten juist transit willen gebruiken.

Vergis je niet in de tijd en kennis nodig om een hele hoop peerings te bouwen & te onderhouden.

Dat is ook zo, maar die giganten hebben wel de mogelijkheden om het anders te doen.

Denk bijvoorbeeld aan een AS per land
met lokale exchanges en een minder restrictieve peering policy voor een optimale ervaring en het globale netwerk voor de rest. Dat zou met AS33915 bijvoorbeeld kunnen. Alleen gaat het om geld idd, en is het makkelijker om alles maar in AS6830 te gooien en de klanten een mindere ervaring te leveren.