1
Vraag
2
Reageer en help mee
Kermit

Level 11
  • 594Posts
  • 4Oplossingen
  • 170Likes

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

 

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-sne...

@Mark Ziggo 

 

30 Reacties 30
Kermit
Topicstarter
Level 11
  • 594Posts
  • 4Oplossingen
  • 170Likes

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.

efok

Level 17
  • 4066Posts
  • 220Oplossingen
  • 1631Likes

@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:

 

Kermit
Topicstarter
Level 11
  • 594Posts
  • 4Oplossingen
  • 170Likes

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


 

m3ga

Level 1
  • 3Posts
  • 0Oplossingen
  • 0Likes

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

 

Daarna met de 80.x geprobeerd. 

 

 

Kermit
Topicstarter
Level 11
  • 594Posts
  • 4Oplossingen
  • 170Likes

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.

Mark
Oud Community Moderator
Oud Community Moderator
  • 5774Posts
  • 654Oplossingen
  • 1965Likes

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

Kermit
Topicstarter
Level 11
  • 594Posts
  • 4Oplossingen
  • 170Likes

Ha Mark

 

super fijn, dank voor je inzet. 

 

Pinging whoami.akamai.net [212.142.48.77] with 32 bytes of data:
Reply from 212.142.48.77: bytes=32 time=10ms TTL=57
Reply from 212.142.48.77: bytes=32 time=10ms TTL=57

efok

Level 17
  • 4066Posts
  • 220Oplossingen
  • 1631Likes

OK, ik heb dat ook even gedaan:

ping whoami.akamai.net
PING whoami.akamai.net (212.142.48.81) 56(84) bytes of data.
64 bytes from 212.142.48.81 (212.142.48.81): icmp_seq=1 ttl=57 time=11.2 ms
64 bytes from 212.142.48.81 (212.142.48.81): icmp_seq=2 ttl=57 time=14.5 ms
64 bytes from 212.142.48.81 (212.142.48.81): icmp_seq=3 ttl=57 time=11.8 ms

Ook dit IP wisselt geregeld, maar altijd in de 212.142.48.x range

Kermit
Topicstarter
Level 11
  • 594Posts
  • 4Oplossingen
  • 170Likes

Gisteren was het snel tijdens het uitvoeren van het gevraagde commando, nu vandaag weer bedroevend. Hier de complete set:

 

https://share.pingplotter.com/GrDysuVs25H

Pinging whoami.akamai.net [212.142.48.76] with 32 bytes of data:
Reply from 212.142.48.76: bytes=32 time=12ms TTL=56
Reply from 212.142.48.76: bytes=32 time=12ms TTL=56
Reply from 212.142.48.76: bytes=32 time=9ms TTL=56

 

 

http://whatismyip.akamai.com/advanced

 

Kermit
Topicstarter
Level 11
  • 594Posts
  • 4Oplossingen
  • 170Likes

 

Zet ik met een hostfile de DNS fixed op onderstaand adres: dan vliegt het

Dit is een ander cluster adres wat ook mee gaat in de roulatie vanuit Akamai.

 

Pinging e751.dsce4.akamaiedge.net [80.67.92.30] with 32 bytes of data:
Reply from 80.67.92.30: bytes=32 time=9ms TTL=57
Reply from 80.67.92.30: bytes=32 time=10ms TTL=57

Kermit
Topicstarter
Level 11
  • 594Posts
  • 4Oplossingen
  • 170Likes

Vaak ben ik met een klant of werk verbonden en krijg ik hun DNS servers gepushed. Dan gaat het verkeer wel over de Ziggo lijn (split tunnel).

 

Pinging whoami.akamai.net [89.20.184.98] with 32 bytes of data:
Reply from 89.20.184.98: bytes=32 time=11ms TTL=242
Reply from 89.20.184.98: bytes=32 time=22ms TTL=242
Reply from 89.20.184.98: bytes=32 time=11ms TTL=242

E-mail notificaties
Aan Uit

Ontvang een update bij nieuwe reacties in dit topic.

Uitgelicht topic