Package losses: Teams instabiel

Profitable

Member
Hallo,

We hebben een nieuwe installatie van Telenet (verhuis) en sindsdien heb ik een zeer slechte ervaring met videocalls in Teams.
Video werkt niet, freezes, disconnects, ...

Los daarvan merk ik niets aan de kwaliteit van ons netwerk: downloadsnelheid is dichtbij de 300 MB/s waarvoor we ook betalen.
TV streamen via Apple TV/Telenet TV app (UTP rechtstreeks op modem) gaat ook zonder problemen.
Surfen/streamen op smartphones is ook probleemloos (via Unifi Lite 6 AP) en heb overal bereik.

Korte schets van mijn setup:

Telenet modem (DOCSIS 3.1 Wireless) met hierop rechtstreeks aangesloten via kabel:
1) 2 aansluitingen voor Niko Home Control domotica
2) 1 aansluiting voor bureau (om te testen, normaal stak hier de Apple TV)
3) 1 aansluiting naar een TP link TL-SG108PE POE Switch

Op die POE switch staat nu:
1) Op een POE poort: kabel naar bovenverdieping waar bekabeld een Unifi 6 Lite access point werd aangesloten
2) Op een gewone poort: Apple TV en ook de zonnepanelen (Huawei)
Andere kamers heb ik even ontkoppeld wegens niet in gebruik.

In de bureau staat er ook een kleine switch (Netgear GS105) om mijn desktop, laptop en NAS bedraad te verbinden.
Met PingPlotter heb ik eens een paar tests gedaan.
Ook via cmd ping -t www.telenet.be is het constant minder dan 40ms, met om de paar minuten eens een "Request timed out".

1) Telenet modem => Kabel naar bureau => kabel naar Netgear switch => kabel naar laptop.
Het resultaat is dit:

2) Telenet modem => kabel naar bureau => kabel naar laptop
Geeft eigenlijk een gelijkaardig resultaat:

Aan de switch in de bureau ligt het dus al niet.
Aangezien ik de problemen al heb rechtstreeks op de modem, ga ik er van uit dat het probleem zich ook daar situeert en niet in de instellingen van mijn TP Link POE switch of Unifi AP?

3) uitschakelen firewall Telenet en herstart modem.
Verder heb ik niets aangepast aan de standaardinstellingen van de modem (bv port forwarding).
Hoewel ik nu geen rode balken heb in de grafiek onderaan, staan er bovenaan wel 2 rijen in het rood (Hop 1 en 3) met een package loss van > 70%?
Ook geen time outs meer in de ping -t www.telenet.be


4) Via Wi-Fi Unifi AP (5Ghz)

Test naar www.telenet.be en teams.microsoft.com tonen nu na 10 minuten nog steeds geen package losses.
Of toch niet in de grafiek beneden, maar wel in de tabel bovenaan zo te zien. Is dit een issue?

Telenet.be
Teams


Tot zover mijn beperkte kennis/troubleshooting... is er iets dat ik nog kan proberen?
Is het ok om die firewall uit te schakelen, wellicht niet?
En in hoeverre speelt die modem reboot een rol, want misschien komt het probleem binnen een paar dagen terug?
Zo een TP POE switch is normaal toch gewoon plug & play?
Hier hoef ik in principe niets aan te passen, idem voor de Unifi AP?

Alvast bedankt voor jullie deskundig advies ;-)
 
Ik volg dit van nabij, heb ook problemen met teams en telenet. Zie topic.


Om het signaal stabieler te maken een mesh AP bijgekocht die vandaag hier zal zijn.

Maar toeval bestaat misschien niet in dit geval??

Telenet is langsgeweest en vond niks van hunne kant uit. Maar dit valt nog af te wachten dus.

Ik zie dat ik dus niet alleen ben met dit probleem, heb alles van unifi binnen mijn thuisnetwerk, dus dat zou in principe toch deftig materiaal moeten zijn... Subbed
 
Ik volg dit van nabij, heb ook problemen met teams en telenet. Zie topic.


Om het signaal stabieler te maken een mesh AP bijgekocht die vandaag hier zal zijn.

Maar toeval bestaat misschien niet in dit geval??

Telenet is langsgeweest en vond niks van hunne kant uit. Maar dit valt nog af te wachten dus.

Ik zie dat ik dus niet alleen ben met dit probleem, heb alles van unifi binnen mijn thuisnetwerk, dus dat zou in principe toch deftig materiaal moeten zijn... Subbed
Ik heb jouw topic inderdaad ook diagonaal gelezen (veel termen die mij niks zeggen ;-)).
Maar in principe ligt het bij mij niet aan Unifi, want het is rechtstreeks op de modem ook al problematisch...
De firewall afzetten van Telenet lijkt voorlopig wel te werken. Net een videocall kunnen doen van 10 min zonder issues...
 
Zet die firewall eens ASAP terug aan!
Ik veronderstel dat je nu je NAS en zo publiek toegankelijk hebt staan... Dat is vragen om problemen. Wat je ook doet, niet meer afzetten tenzij je een eigen router ertussen zet met een eigen firewall erop.

Zet eens een ping op vanop je device waar je problemen mee hebt, tot op het LAN IP van je router (192.168.0.1 waarschijnlijk) en kijk eens of je daar packet loss hebt? Zo niet, is het 99,99% aan de WAN kant dat je een probleem hebt dat Telenet moet oplossen. Op die grafiek lijkt het packetloss zich ook al af te spellen tussen publieke IP's, wat ook op een WAN probleem duidt.

AP en switch moeten normaal out of the box werken, binnen het default LAN van de telenet router.
 
@zephir : gezien gij duidelijk expert zijt in deze materie, wat kan ik doen om mijn slechte verbinding te testen? Gewone huis opstelling telenet, niks van extra AP's , switches oid ertussen.
Zou graag kunnen voorleggen aan Telenet dat mijn verbinding wegvalt. Want nu kom ik telkens op medewerker die er evenveel van kent als ik
 
Zet die firewall eens ASAP terug aan!
Ik veronderstel dat je nu je NAS en zo publiek toegankelijk hebt staan... Dat is vragen om problemen. Wat je ook doet, niet meer afzetten tenzij je een eigen router ertussen zet met een eigen firewall erop.

Zet eens een ping op vanop je device waar je problemen mee hebt, tot op het LAN IP van je router (192.168.0.1 waarschijnlijk) en kijk eens of je daar packet loss hebt? Zo niet, is het 99,99% aan de WAN kant dat je een probleem hebt dat Telenet moet oplossen. Op die grafiek lijkt het packetloss zich ook al af te spellen tussen publieke IP's, wat ook op een WAN probleem duidt.

AP en switch moeten normaal out of the box werken, binnen het default LAN van de telenet router.
Firewall staat weer aan :fingerguns_r:

Hierbij een test van ongeveer 10 minuten op het IP van mijn router:
Dat ziet er volgens mij ok uit...
Dit is trouwens via de PoE switch naar de Unifi AP en dan via Wi-Fi, dus ik mag er van uitgaan dat heel mijn interne setup vanaf de modem ok is?

Dus probleem buitenshuis?
Hoe formuleer ik best mijn vraag zodat ze direct mee zijn?
 
Laatst bewerkt:
@zephir : gezien gij duidelijk expert zijt in deze materie, wat kan ik doen om mijn slechte verbinding te testen? Gewone huis opstelling telenet, niks van extra AP's , switches oid ertussen.
Zou graag kunnen voorleggen aan Telenet dat mijn verbinding wegvalt. Want nu kom ik telkens op medewerker die er evenveel van kent als ik
Ik zou al speedtest van ookla doen en ping testen

Ping meter googelen daarvoor, en daarvan eens de resultaten posten

Verschillende tijdstippen en plaatsen in het huis is aangeraden
 
Laatst bewerkt:
Ik heb jouw topic inderdaad ook diagonaal gelezen (veel termen die mij niks zeggen ;-)).
Maar in principe ligt het bij mij niet aan Unifi, want het is rechtstreeks op de modem ook al problematisch...
De firewall afzetten van Telenet lijkt voorlopig wel te werken. Net een videocall kunnen doen van 10 min zonder issues...
Nochtans als ik uw posts lees heb je er toch ook redelijk veel verstand van...
 
Ping -t is your friend, en/of alle variaties of automatisaties daarvan...
De automation in een Unifi gateway is niet meer dan dat in een mooie interface gecombineerd met een periodieke speedtest.
Ik heb geen eerstehand ervaring met pingplotter, maar het lijkt erop dat die tool doet wat je wil? Aantoonbaar maken waar precies de latencies optreden?

Werk met eliminatie: van je PC naar de Gateway van je Telenet router (192.168.0.1 meestal). Met een kabel moet die 1-2ms zijn, via WiFi onder de 15ms of zo. Als dat consistent goed is, sluit je uit dat daar een probleem zit. Dan moet je naar de volgende hop gaan: de gateway van je ISP modem. Die kan je vinden met het tracert command, waarschijnlijk die 84. in je screenshot. Opnieuw even volhouden, of zo'n tooltje gebruiken. Die hop is al buiten jouw vermogen om er impact op te hebben. Dat is wat ze de "last mile" noemen, van de cabine tot aan jouw huis. Als daar iets mis is, moeten ze daar gaan zoeken en hun kast checken op contacten en eventueel uw kabel uitmeten of vervangen.

Als jij die grafieken kan voorleggen aan Telenet, en kan uitsluiten dat het bij jou ligt (want dat gaat hun eerste actie zijn), moeten ze wel verder zoeken.
 
Ping -t is your friend, en/of alle variaties of automatisaties daarvan...
De automation in een Unifi gateway is niet meer dan dat in een mooie interface gecombineerd met een periodieke speedtest.
Ik heb geen eerstehand ervaring met pingplotter, maar het lijkt erop dat die tool doet wat je wil? Aantoonbaar maken waar precies de latencies optreden?

Werk met eliminatie: van je PC naar de Gateway van je Telenet router (192.168.0.1 meestal). Met een kabel moet die 1-2ms zijn, via WiFi onder de 15ms of zo. Als dat consistent goed is, sluit je uit dat daar een probleem zit. Dan moet je naar de volgende hop gaan: de gateway van je ISP modem. Die kan je vinden met het tracert command, waarschijnlijk die 84. in je screenshot. Opnieuw even volhouden, of zo'n tooltje gebruiken. Die hop is al buiten jouw vermogen om er impact op te hebben. Dat is wat ze de "last mile" noemen, van de cabine tot aan jouw huis. Als daar iets mis is, moeten ze daar gaan zoeken en hun kast checken op contacten en eventueel uw kabel uitmeten of vervangen.

Als jij die grafieken kan voorleggen aan Telenet, en kan uitsluiten dat het bij jou ligt (want dat gaat hun eerste actie zijn), moeten ze wel verder zoeken.

Morgen heb ik een afspraak op afstand met een technieker kunnen regelen via hun whatsapp account.

Die tracert command is mij onbekend en ik zie niet waar jij die 84 vandaan haalt? :)
Als je mij kan zeggen hoe ik die gateway van de ISP modem kan achterhalen zal ik ook dat eens testen.

Ik heb het dan maar even geprobeerd met "tracert teams.microsoft.com" en kreeg dit resultaat:

Dat ziet er niet al te best uit zeker?

Kunnen ze die diagnose op afstand vaststellen?
Benieuwd naar morgen, ik hou jullie op de hoogte.
 
Update na gesprek met Telenet:

Ze zagen onmiddellijk dat mijn TP link switch het probleem was.
Ook al test ik rechtstreeks op de modem, zolang die aangesloten is kan die ook storingen geven.
Ze hebben dan mijn scherm overgenomen en wat instellingen aangepast.
Volgens hen is het nu allemaal in orde, signaal naar buiten is zeer goed.
Ze hebben ook nog een firmware upgrade gedaan van de modem.

Die tracert commands geven wel nog dezelfde timeouts, maar heb wel 2 Teams calls kunnen doen zonder enige problemen.

@zephir: lijkt dat een plausibele verklaring? Of hadden ze wat verder moeten kijken?

In ieder geval bedankt voor de hulp
 
Zoals eerder gezegd: kleine foutjes bij het testen, altijd naar lokale IP's testen om uw eigen netwerk uit te sluiten.
Wat niet gezegd geweest is, is toestellen gaan uitsluiten. Kan soms gebeuren dat er ergens iets storing geeft.

ik was aan het denken, die TP-link switch is een managed switch. daar moet toch ook een IP ingesteld zijn? toevallig dat dit geen storing gaf?
 
Zoals eerder gezegd: kleine foutjes bij het testen, altijd naar lokale IP's testen om uw eigen netwerk uit te sluiten.
Wat niet gezegd geweest is, is toestellen gaan uitsluiten. Kan soms gebeuren dat er ergens iets storing geeft.

ik was aan het denken, die TP-link switch is een managed switch. daar moet toch ook een IP ingesteld zijn? toevallig dat dit geen storing gaf?

Ze hebben wat instellingen aangepast, oa het ip adres van 192.168.0.155 naar .99 (nut?) en dan wat andere settings (DHCP setting disabled, IGMP snooping disabled en loop prevention disabled).
 
Laatst bewerkt:
Sorry voor late reactie, was wat druk bezet...

tracert maakt net zoals pingplotter een weergave van de "hops" (=tussenstops) die je signaal aflegt van het device van waarop je dat commando uitvoert, tot bij de destination.

Je PC en de destination hebben een IP adres. Een pc, een telefoon, een server, een router hebben zelf een IP adres, soms meerdere, en ze hebben netwerkpoorten (en WiFi adapters) die mac adressen hebben IP van IP adressen.

tracert/pingplotter geven aan welke IP's er eventueel tussen je source en destination zitten, en wat de "round trip" tijd is tussen elke "hop." Een hoge round trip tijd, duidt op een probleem tussen die 2 hops. Tracert pinpoint WAAR het issue zit op het pad van A naar B, zodat je daar precies verder kan zoeken.

Routers werken op basis van IP adressen, en gaan verschijnen als hops.
Switchen en Access Points werken niet met IP adressen (voor hun kerntaak toch niet, wel voor hun management interface), maar met Mac adressen, en gaan meestal niet verschijnen als hops.

Het kan wel dat die switch issues geeft, daar zijn meerder oorzaken mogelijk (kapotte hardware, overbelasting, config), en dat zie je dan in tracert omdat er tussen de 2 hops waar je weet dat die switch tussen zit en langere round trip time is, veroorzaakt door packet loss...

Wat Telenet zegt kan dus. En als je hem er tussenuit haalt, of de config wijzigt en het probleem is opgelost, dan lijkt het probleem opgelost en de schuldig geïdentificeerd.

Het aanpassen van het IP van een switch is nuttig, omdat de range 2-100 vaak gereserveerd is voor static IP's en alles daarboven voor DHCP. Ze hebben die switch nu een static IP gegeven, buiten de range van de DHCP server die ingebakken zit in de router van Telenet. Daardoor kan die niet per ongeluk het als static ingestelde IP van de switch, ook aan een ander device dubbel toekennen (leasen).

IGMP snooping is een functie die belangrijk is voor de goede werking van zaken zoals Digicorders, mogelijk werken die nu niet meer achter die switch. IGMP is een protocol dat als een shotgun packets op het netwerk blaast (multicast) naar elke device dat het wil horen, bij telenet om alle digicorders dezelfde stream aan te leveren zonder hun locatie te hoeven kennen. IGMP snooping gaat op poort / device niveau even checken welke poort multicast traffic wil. Zo ja: doorlaten, zo neen, blocken. Dat haalt heel wat overbodig traffic van je netwerk, downstream toch. Als je IGMP snooping opzet, houdt de switch in een soort logboek bij, welke devices / poorten een abonnement op multicast traffic willen, en welke niet. Dit afzetten, belast de switch minder, maar zorgt wel dat er meer onnodige trafiek door je netwerk vliegt.

Waarom ze (R)STP hebben afgezet (loop prevention), snap ik niet goed. Mogelijk ook om cpu / memory van de switch te sparen als ze dachten dat daar het probleem lag?
 

Bedankt voor de deskundige uitleg!

Ik ga er voorlopig afblijven, want tot op heden heb ik geen problemen meer.
Een digicorder hebben we niet, we doen alles via de Telenet TV app.

Mocht ik toch opnieuw problemen krijgen dan zal ik die switch inderdaad eens volledig ontkoppelen.
 
Terug
Bovenaan