Vraag

download.vmware.com traagbij Ziggo via VPN en KPN niet

  • 3 september 2020
  • 30 reacties
  • 385 keer bekeken

 

Mark van Ziggo kan jij hier weer verder mee, het is de laatste weken weer erg slecht. Voor alle historie, zie het oude tickets.

 

https://community.ziggo.nl/community-archief-226/traag-pad-naar-download2-vmware-com-via-vpn-wel-snel-57016?postid=618218#post618218

@Mark Ziggo 

 


30 Reacties

Ha Mark 

 

vorige keer hebben we gekeken naar DNS in relatie tot het pad met packetloss. Het is echter zo dat ik deze software gebruik voor mijn werk. En als ik via mijn werk een VPN opzet dan dwingen zij een bepaalde set DNS servers af.

 

Een feit is dat dit pad, via seabone.net Amsterdam packetloss heeft naar de Ziggo core, ik zou graag daarop focussen. Zouden we per mail met de Akamai engineer kunnen schakelen, waar de vorige keer de case voor geopend was?

Reputatie 7

Ik zal Mark even berichten voor je 

@Dave- tnx! Een PB was bijna nooit mogelijk, maar een tag ook niet meer begrijp ik? 

 

Zou je willen delen hoe e.a. verloopt tegenwoordig in een paar regels?  tnx

Reputatie 7

Een PB ligt aan de persoon zelf hoe hij deze hebt ingesteld en als ie je niet volgt dan kan je ook niks sturen.

 

Een Tag wat je met mijn naam doet wel, zo reageer ik weer op jou die werkt wel, maar door drukte bij Ziggo misschien wel de community gezien, kan het zijn dat ie later reageert of door drukte dat het langer duurt.

 

Ik als Super Expert sta in contact met de moderators, meer dan dat kan ik niet doen dan hem berichten.

Nu even afwachten :wink:  

 

 

In smokeping zie je perfect wanneer het defect is (blauw= packetloss) en groen is (OK). Bijzonder genoeg lijkt het overdag (tijdens werktijden) vaker defect dan savonds.

Reputatie 7

vorige keer hebben we gekeken naar DNS in relatie tot het pad met packetloss. Het is echter zo dat ik deze software gebruik voor mijn werk. En als ik via mijn werk een VPN opzet dan dwingen zij een bepaalde set DNS servers af.

Een feit is dat dit pad, via seabone.net Amsterdam packetloss heeft naar de Ziggo core, ik zou graag daarop focussen. Zouden we per mail met de Akamai engineer kunnen schakelen, waar de vorige keer de case voor geopend was?

Hi wopper, sorry dat ik hier nu pas aan toekom. Het is momenteel ontzettend druk.

Vorige keer was er geen packetloss onderweg, alleen op de eindbestemming (in het geval van de route via Seabone Amsterdam). Nu zeg je dat er packetloss optreedt tussen Ziggo en Seabone en dat is nieuw. Kun je opnieuw voorbeelden geven van de probleemroute om deze te kunnen analyseren?

Hoi @Mark Ziggo 

 

Ik zal mijn beeld schetsen van de vorige keer. 

  • Jullie engineer gaf aan packetloss op de eindbestemming/serverfarm 
  • Ik heb seabone en akamai gemaild, 0 reactie.
  • Toen aangegeven bij KPN is het perfect, we betalen Ziggo voor werkend internet, niet alleen voor een modem in de meterkast.
  • Jij maakte toen de stap om echt toegevoegde waarde te leveren, en toen kwam er een Akamai ticket welke geïnitieerd was vanuit Ziggo. 
  • In dat ticket ging het toen over DNS, en toewijzingen van de juiste akamai clusters welke horen bij een bepaalde ISP domein. Ongelukkig genoeg zaten we toen net in een "groene/werkende” periode waardoor e.a gerepareerd leek.
  • Verkeer lijkt inderdaad corrupt te raken in het Akamai gedeelte, als klant kom ik daar via mijn ISP Ziggo. Waardoor ik van mening ben dat jullie hier iets voor moeten ondernemen, hoe complext deze casus ook is.

 

next step: weer met Akamai in gesprek via Ziggo, om e.a. te laten onderzoeken. Mag van mij ook op de mail 1op1 met iemand van jullie op CC.

Niet om te narren maar wel om reflectie te bieden. Hieronder de lijn via KPN naar hetzelfde cluster IP van akamai.

 

 

Reputatie 7

Zonder de route kan ik niets, ik kan nu immers niet eens zien welke eindbestemming je nu pingt. Kun je daar een recent voorbeeld van geven op het moment dat er problemen zijn waarin de hele route zichtbaar is?

 

 

dit is de trace wanneer het stuk is

 

 

dit is de trace wanneer het stuk is

@woppermijn trace: die gaat niet via seabone, maar ik heb ook een ander IP voor de eindhost dan jij.. met excuses voor de opmaak

mtr -wrb download2.vmware.com
Start: 2020-09-09T12:18:33+0200
HOST: eelco-desktop Loss% Snt Last Avg Best Wrst StDev
1.|-- router (192.168.2.250) 0.0% 10 0.4 0.4 0.3 0.4 0.0
2.|-- 10.255.166.1 0.0% 10 5.9 6.1 5.6 6.7 0.4
3.|-- 213.51.192.189 0.0% 10 9.4 10.0 8.2 16.5 2.4
4.|-- asd-tr0021-cr101-be150-10.core.as9143.net (213.51.158.22) 0.0% 10 12.1 12.9 11.4 14.7 0.9
5.|-- nl-srk03a-ri1-ae51-0.aorta.net (213.51.64.198) 0.0% 10 13.3 12.4 11.3 13.7 0.8
6.|-- 213.46.182.138 0.0% 10 16.9 53.1 13.1 289.4 87.0
7.|-- a2-17-212-33.deploy.static.akamaitechnologies.com (2.17.212.33) 0.0% 10 12.6 12.2 11.2 13.5 0.7

Edit: Ik krijg wisselende IPs terug voor download2.vmware.com, en jij ook zie ik nu. Ik zie bv 104.108.178.98, die wordt gerouteerd via Duitsland Aorta. Het hangt inderdaad sterk af van welke je terug krijgt wat de routering wordt. Niet wegnemend dat je volledig gelijk hebt hierover aan de bel te trekken, zou ik denk even een host met goede routering in mijn Hosts file kloppen
 

 

Klopt Akamai is een content delivery network (CDN) en die kunnen vanaf meerdere plaatsen op het internet content aanbieden. Ze wisselen meerdere keren per dag van locatie (IP), en één van die paden is defect.

 

Waardoor het soms goed werkt en soms niet.

@wopper , ja ik zag te laat dat je dat allang gezien had :blush: , daarom mijn eerder bericht nog even ge-edit.

 

https://share.pingplotter.com/bsn1vLvU7fR

 

 

Het moet echt iets zijn binnen het Akamai cluster:

 

-dezelfde tracert

-dezelfde file

-ander tijdstip

 

Resultaat = snel

 

Als we een ingang bij akamai kunnen creëren zijn ze misschien nog wel blij met onze feedback ook.

Ik kan die file zelf niet downloaden maar ik zal er ook eens een smokeping opzetten. Kunnen we die eens naast elkaar leggen. En een mtr naar de verschillende hosts.

@efok dat zou wel tof zijn:

 

104.81.140.32 (host met loss op bepaalde tijdsmomenten)

80.67.92.30 (host zonder loss)

download2.vmware.com op basis van DNS

 

@wopperIk heb vannacht 3 x een mtr laten lopen, 1000x met een interval van 25 seconden. Zie de resultaten hieronder. Bij mij geen rare uitschieters of loss op de eindhosts, ook niet op de host waar jij problemen ervaart. Ik weet het: moment opname. Ik zal ze vandaag overdag nog eens runnen. Mijn smokepings had ik niet goed in de config gezet, dus die moet ik even opnieuw doen, maar dit geeft eigenlijk al een goed beeld. Zij het niet grafisch in de tijd.

Check!

 

Juist tijd is een belangrijke factor in dit troubleshoot traject; het is er soms wel en soms niet. Met name overdag is het aanwezig, als het blauw is dan ervaar ik de loss: https://bit.ly/33cmi8t

Reputatie 7

Dit is ook apart:

 

Tijdens je pingtest op 9-9 tussen 10:29 en 10:39 is het ip-adres van de download2.vmware.com 2x verandert. De download liep tijdens deze test constant mee en was ook constant traag? Dan is onze focus op 104.81.140.32 als slechte host onterecht toch?

Mark

het CDN netwerk wijzigt continu de adressen, dat is een normaal gedrag. Je ziet in die output de 3 meest voorkomende locaties, waarvan alleen het 104 adres traag is.

Als het snel is, is de tijd te kort om te meten of het vertraagd. Als het traag is dan blijft het traag en komt de download nooit af binnen een werkdag.

Bij het opbouwen van een TCP sessie doe je een nieuwe DNS request, bij een lopende TCP sessie blijft hij end to end staan op het eerder resolved DNS→IP adres. Waardoor het altijd traag blijft als je met de trage server bent verbonden.

@Samplex  wil ook meetesten hij heeft een VMware account. Zojuist was het op het het 104.adres wel snel bij ons beide.

 

Zodra het weer traag is, test hij ook mee, als het hem schikt. Dan weten we wat meer.

@Mark Ziggobijgaand mijn mtr die ik vandaag overdag heb laten lopen:

1,5 % packet loss bij akamai op host 104.81.140.32, en niet op de andere hosts. Hoewel de laaste hop bij seabone wel eens traag reageert daar geen packet loss:

 

Bijhorende smokeping:


Ik zie hetzelfde patroon als bij @wopper , vooral overdag enige packet loss, met een max van 8,6%. Gezien de mtr lijkt het bij de eindhost te zitten, en omdat het vooral overdag is, toch congestie daar?

Ik haal er niet direct uit dat het in de Ziggo “backbone(s)” zit.

Als toetje nog een mtr vanaf een KPN lijn, die ik pas later heb gestart, dus niet helemaal 1 op 1 vergelijk. Wel zelfde host. De route is aanmerkelijk directer, maar hier toch ook lichte packetloss:

 

Het lijkt niet de Ziggo backbone, maar het is wel stuk via het Ziggo internet pad. Over KPN naar dezelfde host (zie screenshot van een paar dagen terug). Zoals eerder gezegd betaal ik voor internet, niet voor een modem in de meterkast. Als dit een hobby site zou zijn ergens in een ver land zou je mij niet horen.

 

Dit is het grootste CDN netwerk ter wereld wat met Ziggo een traffic issue heeft during peak office hours. Dat moet opgelost worden omwille van de kwaliteit welke Ziggo nastreeft en terug laat komen in haar abonnementsprijzen. Wie weet wat akamai nog meer host wat over hetzelfde pad loopt.

 

Over KPN is smokeping en MTR helemaal groen / OK.

 

Dan kom je op het volgende punt, Ziggo zal een Akamai ticket moeten openen om verder te kijken. Dat mag ik niet als eindgebruiker.

 

Ik heb er als klant al veel teveel tijd in zitten… @Mark Ziggo ik wil best onderdeel zijn van de communicatie flow per mail tussen Akamai en Ziggo. Maar eerst moet iemand de deuren openen bij Akamai.

 

Hello,

As per our security policy we need a valid Luna Control Center account in order to provide you the information requested.

You may want to inquire first of your internal Akamai administrator, who would need to approve you access and is capable of creating your portal account

We apologize for any inconvenience this may cause. As you may understand, we need to keep the information of our customers safe.

If you have a valid login, please provide us with it. Also you can ask a colleague with a valid Luna login to validate your account by adding the contact to this thread.
With the approval, we can proceed.

And finally, an account from either a Luna portal admin at your company, or your Akamai account team who can validate your access.

 Best Regards,
 Akamai Technical Support.
 Akamai Technologies


 

Net even proberen te reproduceren maar het verschil is wel aanzienlijk. onderstaande via de 104.x 

 

Daarna met de 80.x geprobeerd. 

 

 

Kijk dat helpt, dank!

 

Dat ziet er net zo slecht uit als bij mij.

 

Op kantoor via KPN zelfde cluster 104-IP is hier wel snel.

Reputatie 7

Dank voor alle uitgebreide tests! Ik heb zelf ook geen ingang bij Akamai maar ik doe mijn best om de juiste mensen binnen ons bedrijf (die wel een ingang hebben bij Akamai) in beweging te krijgen.

 

Edit: Vanuit daar meteen weer het verzoek om het resultaat van dit commando te delen: ping whoami.akamai.net

Reageer