Packet loss op specifieke server (slechte routing)

[okexox]

Ik heb op dit moment een heel specifiek probleem. Mijn internet werkt prima, maar bij een specifieke server (mc.hypixel.net) heb ik extreme packet loss en daardoor duurt het lang voordat ik verbonden ben. Dit kan soms wel 40 seconden duren, terwijl ik soms wel honderden keren op een dag moet herverbinden. Dit komt door een hele grote packet loss (80%) op "http://nl-ams02a-rc2-lag60-2.core.as33915.net". Ik ben verteld door Ziggo support dat ik voor dit soort problemen hier moet plaatsen.

http://prntscr.com/me6a78

[okexox]

efok wrote:

okexox wrote:
Iedereen toch bedankt voor de antwoorden. Het heeft me wel kritisch laten nadenken over het probleem waardoor ik het probleem nu heel specifiek heb ontdekt, nu hopen dat mijn internet anders kan worden geroute of dat het probleem bij die hop wordt opgelost

Zelfs universitair opgeleide mensen zeggen wel eens dingen die niet kloppen, en ik weet waar ik het over heb, want ik ben universitair opgeleid?

Ik bedoel maar te zeggen, je denkt nu een probleem te hebben ontdekt, waarvan wij betwijfelen of dat wel zo is. Met simpele ICMP pings kunnen we dit niet aantonen/uitsluiten omdat die hypixel servers überhaupt helemaal geen reply geven. Dit wordt een welles/nietes verhaal.
Je hebt geen enkele loss op de hop 6,7,8 in je mtr screenshot, dus waarom die focus op die ene server in Amsterdam?

Ik zie waar je vandaan komt. Even om duidelijk te zijn:
Zowel ik als vrijwilliger en die server operator als volbetaalde baan werken voor die server. We weten beide waarom de pings niet werken en we weten dat WinMTR wel werkt, want dat is hoe het is ontworpen. Dus ondanks dat je inderdaad gelijk hebt dat een onmogelijkheid om te pingen inderdaad een reden kan zijn om de WinMTR niet te vertrouwen, weet ik zeker dat het wel werkt in deze situatie.

Om je toch gerust te stellen heb ik een WinMTR gedraaid naar een server van hen die wel reageert op pings. De locatie is niet helemaal hetzelfde maar je merkt precies hetzelfde resultaat als ik probeer packets de atlantische oceaan over te sturen. Ook daar heb ik last van vergelijkbare connectieproblemen.

http://prntscr.com/mfe0m9

Ook is het heel normaal dat de packet loss % van de servers erna niet beïnvloed wordt door de server daarvoor. Dat zou diagnostiek veel moeilijker maken aangezien je moeilijker kunt zien of andere routers daarna ook packet loss hebben. Zie hier een paar compleet willekeurige screenshots die ik van het internet heb gehaald.

http://i66.tinypic.com/yidu9.png
https://external-preview.redd.it/nVkCAORFQj1pdbgRkyk85NUOfnl5oWpfMdsRJMZy3tE.jpg?width=696&height=364.397905759&auto=webp&s=53ac1bd335962d14ef38a8ab8d0877e28c44b245
http://i.imgur.com/ATiV82r.jpg

Ziet u hoe de loss % weer op 0 gaat nadat een andere server daarvoor al packets heeft verloren. Deze servers zijn echt niet allemaal aan het rate-limiten

[efok]

Ik zie in dit screenshot gewoon 40 verzonden packets, met 40 replies van de eindbestemming. Dat kan alleen als er geen pakketjes verloren zijn onderweg. Dan is er dus geen probleem. Het niet reageren op een ICMP echo request van een hop/router wil niet zeggen dat die router zijn werk niet goed doet. Hij geeft alleen geen of een lage prioriteit aan het beantwoorden van ICMP verkeer. Het spijt me, maar ik kan dus niet meegaan in je redenering.
Verdiep je even in hoe mtr werkt. Het zijn opeenvolgende ICMP requests, met een oplopende TTL. Zolang de eindbestemming op ieder request antwoord is er niets aan de hand.

[hanh]

Ben het helemaal eens met efok en ArieKanarie

okexox
Packet Loss onderweg op een Route bij een Traceroute wil zeggen:
de host geeft geen (of een te laat) ICMP Time Exceeded Response op ping try packets met TTL=1 als eenmaal aangekomen op de hop.
Vaak expres geen Response geven, kan zo zijn ingesteld op de host. Een pakketje met TTL=1 moet toch maar de prullenmand in.
Ping try pakketjes met een hogere TTL worden netjes overhandigd aan de eerstvolgende hop.
Er zijn veel misverstanden hierover. Alleen de Response van de Target host doet er toe. Packet Loss aldaar kan een indicatie zijn van een probleem, maar niet altijd, zoals in deze Case met een Target host die helemaal niet op ping reageert. Een evt matige response van de Target host bij een trace zegt te weinig over het niet goed werken van een te gebruiken service op die host!
De voorspellende waarde van een traceroute mbv ping pakketjes is nu eenmaal beperkt. (Met een goed Tool kun je ook andere typen pakketjes gebruiken voor de trace, maar die aanpak heeft hetzelfde euvel).

Voor goed begrip is bestudering zinvol van hoe een traceroute werkt.
Je hoeft beslist niet universitair geschoold te zijn om dit te kunnen begrijpen.
Zou wel eens een handicap kunnen zijn. Zeker voor bv een gemiddelde historicus.
Enige basiskennis over Internet protocollen is wel gewenst.
https://en.wikipedia.org/wiki/Traceroute

Gr Han

[Michael Z1]

Hoi okexox. Het is inmiddels al een tijdje stil in dit topic. Heb je nog een update van de huidige status voor ons? Is er nog wat nieuws onder zon?

[okexox · Accepted solution]

Michael Ziggo wrote:
Hoi okexox. Het is inmiddels al een tijdje stil in dit topic. Heb je nog een update van de huidige status voor ons? Is er nog wat nieuws onder zon?

Mijn connectie met deze server is een stuk stabieler geworden de laatste tijd. Het lijkt nu echt beter. Mijn routing is ook lichtelijk veranderd. Ik weet nog steeds niet precies wat het probleem was, maar het lijkt voor nu opgelost.

En bedankt voor de reactie, zowel van het Ziggo team als de andere mensen.

[Michael Z1]

Kijk, dat is goed nieuws zo aan het eind van de week. Fijn om te lezen! Mocht je in de toekomst nog een vraag hebben of ergens tegenaan lopen, open dan gerust weer een nieuw topic op onze Community.