Netwerk Packet drops

[striker_lord]

Mijn eerste post op Tweakers, ik ben benieuwd .

Om het topic af te trappen, ik heb een probleem met Packet drops binnen (of buiten) mijn netwerk op het moment dat ik video's upload naar youtube. Dit wordt voornamelijk ervaren binnen de Teamspeak server omdat er te veel Keep alive packets worden gedropped waardoor een client uit Teamspeak wordt "geschopt".

Netwerk setup en gerelateerde componenten:
Ziggo Technicolor modem - Internet onsluiting
Gigabit Switch - netwerk verdeling over 3 Machines (1 Server, 2 Desktop, 3 Desktop, 4 GB switch voor ad hoc aansluitingen)
Geen ingewikkeld netwerk dus.
De server is ingedeeld in een DMZ, al het binnenkomende (onbekende) verkeer gaat naar deze server.

Wat heb ik geprobeerd?
1. Modem op instellingen gecontroleerd, niks vreemds, SNR van 40 dB, firewall volledig uitgezet en modem herstart - geen verbetering.
2. Switch opnieuw ingedeeld zodat de Server op de 2e poort zit, Switch herstart - geen verbetering.
3. Server naar nieuwste updates gebracht (incl Teamspeak en drivers) - geen verbetering.
4. Speedtest ten tijde van upload geeft aan dat er nog ruimte over is, het is dus geen bandbreedte saturatie 150 Mbps download en 7 Mbps upload ten tijde van het uploaden van een video)

Wanneer doet het probleem zich voor?
Als ik van Desktop 2 een video upload naar Youtube wordt de packet loss extreem en komen er veel dropped connections voor op de Teamspeak server.
Als ik via de Server de video upload (rechstreeks vanaf een share van Desktop 2) dan komen de dropped connections vele malen minder voor (Ratio: 10 drops via Desktop, 2 Drops via Server).

Gezien op dit moment alleen Teamspeak hinder ervaart ben ik nog testen aan het uitvoeren (ping testen naar andere servers ten tijde van video uploads e.d.), de resultaten zal ik dan ook hier delen als deze nuttig zijn.

Zijn er ideeen of suggesties waarmee ik dit verder kan trouble shooten of misschien zelfs kan oplossen?

[a.boogerd]

Heb je al geprobeerd om met QoS het dicht trekken van je verbinding kan voorkomen

[Ravefiend]

Je vermeldt Ziggo en daar is de afgelopen dagen veel op te doen geweest voor wat betreft packet loss naar Google diensten. Net vandaag zouden de problem pas oplost zijn geraakt:

nieuws: Ziggo en Google lossen verbindingsproblemen met Google-diensten op

[Stoelpoot]

Inderdaad zou ik het vandaag weer even opnieuw proberen. Grote kans dat het aan de Ziggo / Google issues lag

[daxy]

Als het niet aan Ziggo/Google lag, probeer eerst eens uit te zoeken of het intern of extern is. Dit kan je vinden door een ping te starten naar je default gateway (Technicolor modem waarschijnlijk) en naar je interne server. Zie je hier hoge respons tijden, dan ligt het probleem intern. Denk dan eens aan het nakijken van alle poorten op je switch, zijn ze wel gigabit of toch 100Mbit/s. Je kan ook uPnP uitzetten en IGMP Snooping op je switch en Technicolor modem, misschien helpt dat.

Gaat dit goed, probeer dan eens een ping naar de eerste host die bereikbaar is binnen het Ziggo netwerk (tracert -n 8.8.8.8 laat ze zien, kies de eerste die buiten je eigen 192.168.x.x netwerk valt). Succes

[striker_lord]

Super deze snelle reacties allemaal!
ik pak jullie suggesties stuk voor stuk door:
QOS
Helaas heeft de Technicolor geen QOS optie (sowieso een punt van zorg voor mij).
Echter zou dit geen tot weinig invloed hebben gezien het spraak verkeer goed gaat, echter komen de keep alive packets veelal niet goed aan waardoor een client gedropped wordt.

Google Diensten
Terecht punt, dit had ik ook al bekeken.
Helaas heeft dat geen verklaring voor het data verkeer naar mijn server voor Teamspeak clients.
Zojuist heb ik ook een meting gedaan op het effect van het uploaden van een Youtube video vs packet loss voor de clients, resultaat staat iets verder in dit bericht.

intern of extern
Middels Spiceworks doe ik hier al een constante meting op, dus deze is snel en makkelijk te beantwoorden .
Intern default gateway: https://ibb.co/kq05rQ
Extern (google): https://ibb.co/dwZWWQ
In de 2e afbeelding is heel goed te zien dat op het moment van uploaden de response tijd toeneemt (gisteren avond, vanmorgen, eind ochtend en middag, allemaal tijden dat er ook een video werd geupload).

Zojuist de 1e en 2e externe hop (die ik met IP kon bevestigen) toegevoegd aan Spiceworks, dat is een goede tip Daxy!
*update* zojuist een nieuwe test gedaan, response tijd van de Default gateway blijft op 1ms, de response tijd van de 2e hop (1e kon ik niet meten helaas ) ging van 9ms gemiddeld naar 50ms gemiddeld. Google ping van 22ms gemiddeld naar 55ms.

Lijkt er dus op dat de oorzaak extern zit, vanavond Ziggo maar eens even bellen! Suggesties blijven welkom.

Wat betreft de testen, onderstaand wat screenshots:
Tijdens uploaden (hoge ping & packet loss, testen worden vanaf de server gedaan): https://ibb.co/mnejJ5
Na het uploaden (lage ping, geen tot weinig packet loss, Stiffie werkt via Wifi wat zijn packet loss verklaart): https://ibb.co/c22tBQ
Let op, de impact is in deze minimaal omdat de bevolking van Teamspeak minimaal is, in de avond als er (vaak boven de 60 man) meer mensen online zijn neemt het aantal packet drops drastisch toe (gemiddelde meting gisteren avond rond de 10%!).

*update* resultaat van een ping test ten tijde dat er geen upload liep. Let op, aantal gebruikers online is in de middag opgelopen tot 40 (verdeeld over 5 virtuele Teamspeak instances, packet loss 0 tot 1% gemiddeld).
https://ibb.co/d2OEkk

geen censuur op de IP's, maar deze heren hebben dynamische IP adressen .

[ Voor 22% gewijzigd door striker_lord op 12-04-2017 15:59 ]

[_-= Erikje =-_]

probeer je network bandwidth eens te throttelen als je een video upload, desnoods knijp je je upload naar een paar mbit. Zo lang je je upload vol trekt ga je deze issues blijven hebben. Quick fix is in Chrome naar developer mode gaan (F12) en bij network een thottle kiezen voordat je naar youtube gaat

[striker_lord]

@_-= Erikje =-_ je bent een held, hier had ik zelf aan moeten denken, ondanks dat dit meer een workaround is dan een daadwerkelijke oplossing (als de upload minder dan de helft van de upload bandwith inneemt mag dergelijke packet loss in mijn ogen niet voorkomen) levert dit wel de lucht die ik nodig heb!
Nooit een fan van Google Chrome geweest, maar dit zet Chrome toch op een voetstuk .

Throtteling ingesteld op 5ms, 2.0Mb/s, 1.0Mb/s doet de truck (2 ms, 30Mb/s, 15Mb/s werkt ook maar levert 0,01% packet loss op tijdens dal tijd, hierom de 5 ms gekozen om ook tijdens piek momenten de packet loss te voorkomen).

Mijn dank is groot!
Mocht ik in de loop der tijd iets anders tegen komen (een oplossing) dan zal ik dit topic updaten.

[_-= Erikje =-_]

striker_lord schreef op donderdag 13 april 2017 @ 12:43:
ondanks dat dit meer een workaround is dan een daadwerkelijke oplossing (als de upload minder dan de helft van de upload bandwith inneemt mag dergelijke packet loss in mijn ogen niet voorkomen)

Niemand garandeert jouw dat je upload niet overboekt is (zeker niet in de piek periodes op een shared medium als kabelinternet). Het is een beetje zoeken naar de sweet spot, maar in het ergste geval duurt het uploaden van je video wat langer. Enige `daadwerkelijke` manier hier omheen is je modem in bridge laten zetten en zelf een router eraan knopen waarbij je QoS in kan gaan richten om je HTTP upload te knijpen (= veel kosten voor iets dat je nu met de hand in chrome doet)