Beantwoord

Traag pad naar download2.vmware.com via VPN wel snel

  • 27 mei 2020
  • 25 reacties
  • 509 keer bekeken

@Serkan Ziggo jij vroeg mij om een publiek topic te openen zodat iemand van Ziggo dit intern kan gaan uitzoeken. Zou jij een backbone guru kunnen taggen ;-)

Voor mijn werk gebruik ik veel de VMware site en ik merk dat hij erg langzaam is, dat lijkt een uniek Ziggo probleem te zijn. En wel om de volgende redenen:

-Maandje KPN VDSL gehad met dezelfde router → = snelle download

-Nieuwe eigen router geplaatst op Ziggo →  = geen verschil

-Via een VPN aanbieder (windscribe) → = snelle download

 

Mijn conclusie is dat het pad via Ziggo haar native routing niet goed functioneert, het ligt niet aan de latency maar het lijkt op en bandbreedte cap ergens in het pad.

 

https://share.pingplotter.com/NpiMZfqpncg routing als het traag is

 

Zonder VPN

 

Met VPN

 

icon

Best beantwoord door wopper 14 juli 2020, 16:26

 

@Mark Ziggo ziet er nog steeds goed uit, zelfs 200Mbit+.

 

Ik ga er, zo goed als zeker, vanuit dat seabone een pad heeft hersteld. Wat mij zojuist nog opviel is dat het pad nu loopt via Ziggo POP Hilversum naar Amsterdam en tijdens de traagheid over POP De Meern naar Amsterdam.

 

Anyway happy user over here ;-)

Bekijk origineel

Dit topic is gesloten. Staat je antwoord hier niet bij, stel dan je vraag in een nieuw topic.

25 Reacties

Zojuist is er iets aan (dynamische) routing aangepast. Het wisselt overigens wel vaker, en over Cogentco is het snel.

 

Zou mooi zijn dat dit pad permanent blijft ;-) Geeft ook het juiste beeld over het knelpunt in deze uitdaging → routing pad.

 

 

 

Samenvatting:

 

Seabone.net over Amsterdam is traag

https://share.pingplotter.com/NpiMZfqpncg

 

Seabone.net Londen is snel

https://share.pingplotter.com/3HfiWA7YKp4

 

Cogentco is snel

https://share.pingplotter.com/Tq4y79EELb5

 

 

https://share.pingplotter.com/eFwkxY9hnbh

 

Nog een nieuw pad waarover het wel snel is. Zo zie je maar hoe dynamisch Content Delivery netwerken zijn qua routing.

Reputatie 7

Via glas (GPON):

 

Reputatie 7

Goedemiddag @wopper en welkom op de Community,

Bedankt voor het starten van dit topic met de gevraagd informatie. Zo te zien gaat het dus mis met de routering van Seabone.net over Amsterdam.
Ik laat dit even onderzoeken en kom hier op terug zodra ik een antwoord heb van mijn collega's. 

Reputatie 7

@wopper Mijn collega's hebben naar dit probleem gekeken. Het lijkt mis te gaan bij de host zelf. Dit is te zien in onderstaande screenshot wat je met ons gedeeld hebt. Dit is na de de hop vanaf de AORTA.
Ik raad aan om hierover contact op te nemen met de host en te informeren of daar mogelijk iets misgaat. 
 

 

Goedenmorgen @Paul Ziggo 

 

dank voor het uitzoeken, ik heb inderdaad ook een ticket bij akamai ingeschoten. Maar daar blijft het vooralsnog stil. 

 

Het lijkt inderdaad in het stukje te zitten van Seabone naar Akamai en niet van Ziggo naar Akamai.

 

tnx!

Aan zo’n plot kun je eigenlijk niet zien waar het precies misgaat.

Is het probleem de Target host zelf, of krijgen Ping Try Packets die de Target moeten bereiken (TTL = 8 ), ‘ergens’ niet altijd een Forward?

Ik hou het op een probleem bij de Target host, als meest waarschijnlijke oorzaak.
 

Aan zo’n plot kun je eigenlijk niet zien waar het precies misgaat.

Is het probleem de Target host zelf, of krijgen Ping Try Packets die de Target moeten bereiken (TTL = 😎, ergens geen Forward?
 

Klopt, plus het feit dat ik een trage TCP verbinding meldt en Ziggo een ICMP plot als troubleshoot gebruikt matched ook niet volledig met de gedane melding. Voelt als een kortstondige blik op deze usecase.

Er zal inderdaad loss op de verbinding zitten want Wireshark laat pages vol retransmissions zien. 

Het had mooier geweest als Ziggo de peering met seabone.net had aangeschreven om mij als klant te helpen. Dan hebben beide partijen winst bij de oplossing = packetlossvrij maken. Of de peering tijdelijk op shutdown totdat seabone de zaken op orde heeft met de achterliggende Akamai farm.

Ik heb zojuist seabone gmaild, ben benieuwd.

Reputatie 7

Hey @wopper . Ik kom dit topic bij toeval weer tegen. Hoe gaat het nu? :-) 

Hey @Lycke Ziggo nou ik heb een tweede lijntje aangevraagd bij https://www.budgetthuis.nl/  (KPN) en daar heb ik het probleem niet.

 

Het blijft een knellend pad als het over amsterdam seabone gaat. Het zou heel fijn zijn als Ziggo hier hun verantwoording pakt en zich niet verschuild achter “het zit in de laatste hop”. Ziggo kan het verkeer prima over een ander pad forceren dmv routing of de peering naar seabone een shutdown geven. En hen aanschrijven dat het pad gecontroleerd/gereinigd moet worden, alleen moet deze casus dan bij de juiste mensen op het juiste niveau komen. Wil je daarbij helpen Lycke?

 

NU bij Ziggo 250/25

 

NU bij KPN 100/30

 

 

@Lycke Ziggo heb je nog tijd gehad om een onderzoek in te stellen?

Reputatie 7

Goedemiddag @wopper,

Balen dat het nog niet lekker werkt! Heb je naar aanleiding van mijn bericht van 3 juni 2020 nog contact gehad met Seabone en hiervan een terugkoppeling ontvangen?

@wopper Mijn collega's hebben naar dit probleem gekeken. Het lijkt mis te gaan bij de host zelf. Dit is te zien in onderstaande screenshot wat je met ons gedeeld hebt. Dit is na de de hop vanaf de AORTA.
Ik raad aan om hierover contact op te nemen met de host en te informeren of daar mogelijk iets misgaat. 
 

 

De terugkoppeling die ik van onze expert ontvangen heb is de hostende partij even aan te schrijven om na te gaan waarom het specifiek in dit traject misgaat vanaf een Ziggo verbinding. 

@Paul Ziggo ik heb ze allemaal aangeschreven, je ontvangt gewoonweg geen reacties, van seabone niet, van Akamai niet.

 

Aangezien het alleen via Ziggo speelt, en ik bij jullie een klant ben, heb ik toch bedacht dat ik jullie ga vragen het op te lossen ;) Binnen jullie core team kunnen ze het verkeer beïnvloeden dat dit pad niet meer gekozen wordt.

Ik ben ook van mening dat Ziggo en Liberty Global actiever aan de slag mag gaan met routeringsproblemen. Mijn topic hierover richting Softlayer / IBM Cloud Frankfurt is al gearchiveerd maar het probleem is er na maanden steeds. https://community.ziggo.nl/community-archief-226/vreemde-routering-naar-softlayer-frankfurt-56808. Bij Softlayer / IBM Cloud kan ik het probleem niet neerleggen en bij Liberty Global ook niet.

Je loopt hier als klant helemaal vast. Andere Internet Providers hebben deze problemen niet maar ik wil graag mijn 500/40mbit verbinding behouden. Maar het kan niet de bedoeling zijn dat ik iedere keer een routeringsprobleem bij Ziggo moet gaan omzeilen met een VPN verbinding.

@FlorisMouwen helemaal eens met wat je zegt. Wij kunnen niets aan deze paden veranderen, noch beïnvloeden.

 

In mijn jongere jaren heb ik voor ISP gewerkt die, ons als beheerorganisatie, verplicht stelde de klanten te helpen end to end. Dat wil zeggen wij als NOC moesten met de peeringpartijen in gesprek om bepaalde, aantoonbare, problemen in gezamenlijk overleg op te lossen.

Bij RWS betalen we ook wegenbelasting, en worden de wegen onderhouden. Waarom zou dat anders zijn voor de paden/wegen op het internet, ook daar kunnen soms optimalisaties nodig zijn welke gedragen worden door de abonnementsgelden.

Ik betaal voor het product internet, dat is niet alleen het modem in de meterkast @Lycke Ziggo @Paul Ziggo dat is end-to-end. Waarbij ik als klant eigenlijk alles binnen mijn cirkel van invloed al heb uitgevoerd, binnen de cirkel van invloed van Ziggo zie ik nog geen waarneembare activiteiten?

 

Kunnen we een escalatie starten voor dit onderwerp intern binnen Ziggo?

Reputatie 7

Hi @wopper en @FlorisMouwen, dit is geen standaardproces en ik weet ook niet precies wat hierin wel of niet mogelijk is. Ik heb een contactpersoon bij wie ik dit soort verzoeken neerleg, daar krijg ik dan na enige tijd reactie van (“is opgelost” of “kunnen we niets aan doen”) maar ik heb geen zicht op het proces wat zich daarachter afspeelt.

Ik ben het in die zin met jullie eens dat wij (Ziggo) hier iets mee moeten. Uiteindelijk kost het ons een klant als we er niets mee doen, want jullie stappen over naar een provider waarbij je geen problemen ervaart in de verbinding naar je werk/cloudoplossing/wat dan ook. Ik ga kijken of ik dit proces verder kan onthullen en hopelijk nieuwe inzichten vergaren, schroom niet om hier af en toe eens om een update te vragen, maar ik kan niets beloven.

@Mark Ziggo tnx dat wordt gewaardeerd.

Reputatie 7

@wopper we hebben een ticket bij Akamai ingeschoten en daarop de volgende vragen teruggekregen:

I cannot reproduce packet loss to that host right now.

According to our systems, that content should have been served from a different cluster for your location. Can you tell me what nameservers you use? You can do this by e.g. "ping whoami.akamai.net" and sharing the IP address returned for that hostname. Can you verify that download2.vmware.com still points to the IP address you mention below?

 

Als ik een traceroute doe naar vmware doorloop ik een hele andere route dus ik kan niet checken of er al iets veranderd is, hoe is jouw route momenteel en ervaar je daarmee nog snelheidsproblemen?

Zo ja, check welk ip-adres er verschijnt als je pingt naar whoami.akamai.net

Hoi

 

@Mark Ziggo echt super fijn dat je ermee aan de slag bent gegaan. Als de twee internet reuzen met elkaar mailen is er blijkbaar wel contact mogelijk ;-)

 

Weet dat ik seabone en akamai ook gemaild heb, wellicht heeft seabone een fiber gecleaned oid waardoor de packetloss nu niet te reproduceren is. Dat lijkt ook in lijn met mijn testen op dit moment.

 

Het is nu voor het eerst snel, ook over seabone ams.

 

 

 

Ik zou de case nog niet af willen sluiten, het heeft lang geduurd voor we op dit niveau zijn beland. Nog even wat dagen aan kijken.

 

Qua DNS gebruik ik diverse DNS servers, elke DNS server gaat over zijn eigen pad naar buiten, over de huidige dual ISP setup. 

 

213.75.63.75 (KPN)
195.121.1.34 (KPN)
62.179.104.196 (Ziggo)
84.116.46.23 (Ziggo)
https://doh.opendns.com/dns-query

 

Deze heb ik ook gebruikt

1.1.1.2

9.9.9.11

 

Pinging whoami.akamai.net [195.121.82.115] with 32 bytes of data:

Daar krijg ik op dit moment een KPN adres terug, de genoemde DNS servers worden parallel aangeroepen en de snelste server wordt geselecteerd.

https://bgp.he.net/ip/195.121.82.107

 

Pinging whoami.akamai.net [212.142.48.68] with 32 bytes of data:

Zet ik de DNS servers om naar onderstaande Ziggo adressen dan krijg ik bovenstaande output, wat lijkt te kloppen.

62.179.104.196 (Ziggo)
84.116.46.23 (Ziggo)

 

Wat we hieruit kunnen opmaken, voor jullie als Community medewerkers ook goed ter naslag. Dat je DNS server bij een CDN netwerk behoorlijk relevant is, als we deze kennis eerder hadden gehad hadden we beter toegespitst kunnen testen.

 

Resume van beide problemen.

-optimalisatie via DNS mogelijk, om het meest optimale cluster te benaderen.

-pad lijkt op dit moment beter te presteren van voorheen, actie isp seabone uitgevoerd?

 

Als ik download2.vmware.com resolve via Ziggo DNS krijg ik:

2.17.220.33

https://share.pingplotter.com/fwGvqcadtN7

 

Als ik download2.vmware.com resolve via KPN & 9.9.9.11 DNS krijg ik: 

104.99.232.32

https://share.pingplotter.com/7hf4EF5egUL (deze lijkt gerepareerd want dit was het defecte pad)

 

Als ik download2.vmware.com resolve via 1.1.1.1 & 208.67.222.222 krijg ik:

95.101.184.29

https://share.pingplotter.com/Shrcrovhvot

 

 

Ik heb al bewust de EDNS varianten gepakt om een zo optimaal mogelijk pad te gebruiken, ten koste van wat privacy.

 

What is EDNS Client-Subnet?

EDNS Client-Subnet is a method that includes components of end-user IP address data in requests that are sent to authoritative DNS servers. This means that there is privacy “leakage” for recursive resolvers that send EDNS Client-Subnet data, where components of the end user’s IP address are transmitted to the remote site. While this is typically used to improve the performance of Content Distribution Networks, we have determined that Client-Subnet data falls into a grey area of personally identifiable information, and we do not transmit that data in our default service. In some circumstances, this may result in suboptimal routing between CDN origins and end users.  We do support a secure service that sends Client-Subnet data.

 

Reputatie 7

Klinkt veelbelovend! Mocht er toch weer iets misgaan hoor ik het graag.

 

@Mark Ziggo ziet er nog steeds goed uit, zelfs 200Mbit+.

 

Ik ga er, zo goed als zeker, vanuit dat seabone een pad heeft hersteld. Wat mij zojuist nog opviel is dat het pad nu loopt via Ziggo POP Hilversum naar Amsterdam en tijdens de traagheid over POP De Meern naar Amsterdam.

 

Anyway happy user over here ;-)

@FlorisMouwen jouw probleem lijkt ook opgelost, fZiggo was lid van het NL-IX platform. Sinds vorige week zie ik ook weer data over de NL-IX gaan. Het lijkt dat AS6830 voor Nederlandse paden steeds beter verkeer afhandelt!

 

Je oude topic is al op slot vandaar hier ff;-)

 

jumpserver:~$ traceroute -w1 23.8d.9ca1.ip4.static.sl-reverse.com
traceroute to 23.8d.9ca1.ip4.static.sl-reverse.com (161.156.141.35), 30 hops max, 60 byte packets
 1  172.16.1.1 (172.16.1.1)  0.393 ms  0.345 ms  0.472 ms
 2  195.190.228.34 (195.190.228.34)  5.294 ms  5.726 ms  5.687 ms
 3  * * *
 4  cloudflare.telecity2.nl-ix.net (193.239.117.114)  9.443 ms  9.429 ms  9.466 ms
 5  141.101.64.151 (141.101.64.151)  7.502 ms 141.101.64.155 (141.101.64.155)  10.176 ms 141.101.64.76 (141.101.64.76)  11.026 ms
 6  141.101.64.155 (141.101.64.155)  10.299 ms 141.101.64.60 (141.101.64.60)  9.706 ms 141.101.64.150 (141.101.64.150)  9.643 ms
 7  * * *
 8  * ae5.cbs02.xn01.fra01.networklayer.com (169.45.18.170)  16.117 ms  14.728 ms
 9  ed.13.2da9.ip4.static.sl-reverse.com (169.45.19.237)  13.405 ms  13.399 ms  13.424 ms
10  83.76.9ca1.ip4.static.sl-reverse.com (161.156.118.131)  13.490 ms 85.76.9ca1.ip4.static.sl-reverse.com (161.156.118.133)  15.743 ms 89.76.9ca1.ip4.static.sl-reverse.com (161.156.118.137)  14.272 ms
11  9f.76.9ca1.ip4.static.sl-reverse.com (161.156.118.159)  13.557 ms a3.76.9ca1.ip4.static.sl-reverse.com (161.156.118.163)  13.469 ms 9f.76.9ca1.ip4.static.sl-reverse.com (161.156.118.159)  12.911 ms
 

<edit> foute info verkeerde router.

@Mark Ziggo die post met de traceroute (goedkeuring mod?) mag je droppen.