Zoals de kop het al aangeeft, heb ik elke dag wel drops in mijn internetverkeer.
Youtube filmpjes kunnen niet meer bufferen, ondertussen check ik of ik nog naar 8.8.8.8 kan pingen wat gewoon lukt.
Hetzelfde geldt voor websites die niet meer benaderbaar zijn, ze worden niet geladen terwijl pingen naar ip adressen en dns adressen wel gewoon lukt.
Ik gebruik mijn eigen hardware als router, maar dit gebeurt ook met de Draytek aangesloten.
Het heeft niets met WiFi te maken omdat ik het niet eens gebruik.
De kwaliteit van de verbinding is, eigenlijk sinds de overname van T-Mobile, heel erg slecht.
Als hier niet snel verandering in gaat komen zal ik toch moeten gaan overstappen.
Ik zit met een 200/200 lijn, omdat ik anders op een verouderde 100 Mbit lijn kom te zitten
en niet mijn eigen router kan gebruiken, met de kosten waar nieuwe klanten 750/750 krijgen.
Iets wat niet echt klantvriendelijk is. Ik wil graag klant blijven maar dan zal er wel wat van de kant van T-Mobile moeten komen.
Bladzijde 1 / 1
Hallo @Bart_Smith ,
Zou je kunnen checken of de verbinding ook weg valt ? of heb je wel een hogen uptime op je wan verbinding. Ik weet niet of je ook regelmatige ringtests - speedtests doet op je router zodat we wellicht daar iets in kunnen zien. er zijn nu niet genoeg aanknopingen punten om iets mee te kunnen. zit je in een WBA of ODF gebied ?
Sommige locaties hebben nog 100Mbit apparatuur maar als je bent overgezet naar het gigabit netwerk zal je niet weer terug gezet worden naar 100Mbit apparatuur als je zou downgraden naar 50Mbit dit word uitgefaseerd.
Zou je kunnen checken of de verbinding ook weg valt ? of heb je wel een hogen uptime op je wan verbinding. Ik weet niet of je ook regelmatige ringtests - speedtests doet op je router zodat we wellicht daar iets in kunnen zien. er zijn nu niet genoeg aanknopingen punten om iets mee te kunnen. zit je in een WBA of ODF gebied ?
Sommige locaties hebben nog 100Mbit apparatuur maar als je bent overgezet naar het gigabit netwerk zal je niet weer terug gezet worden naar 100Mbit apparatuur als je zou downgraden naar 50Mbit dit word uitgefaseerd.
Goedemorgen :)
In alle tests die ik al heb uitgevoerd heb ik gezien dat mijn WAN verbinding niet wegvalt, ik doe alle tests ook direct op de router.
De uitvallen gebeuren sporadisch, ik zit youtube te kijken en stopt om te bufferen waarna ik al weet dat de verbinding weer plat ligt.
Dat wil zeggen, Ik heb wel een WAN connectie, pingen naar IP en DNS lukt maar wel met hier en daar een drop en als ik eindelijk op de speedtest webpagina kom ( âgelukâ dat de outage zo lang duurt ) de test failed op de latency test.
Ik ga ervan uit dat ik op ODF zit, ik kan tot 750Mbit upgraden als ik zou willen maar niet ga doen omdat je als vast klant gestraft wordt en 10+ euro meer mag betalen dan een nieuwe klant.
Ik heb wel monitoring draaien ( data ) maar verbruik te weinig om hier echt iets nuttigs uit te halen en geen tijd op het moment om een goede monitoring op te zetten.
Ook bestaande klanten kunnen overstappen naar een nieuw prijsplan. je gaat dan wel een nieuw contract aan van 12 maanden.
Laten we eerst eens kijken of we de problemen kunnen oplossen. Wellicht dat een moderater een lijn meting kan doen en kan zien of er iets raars is op je verbinding. je moet dan wel even het modem van t-mobile aansluiten anders lukt de meting niet goed. Welk modem heb je van T-Mobile ?
Laten we eerst eens kijken of we de problemen kunnen oplossen. Wellicht dat een moderater een lijn meting kan doen en kan zien of er iets raars is op je verbinding. je moet dan wel even het modem van t-mobile aansluiten anders lukt de meting niet goed. Welk modem heb je van T-Mobile ?
Dat wil zeggen, Ik heb wel een WAN connectie, pingen naar IP en DNS lukt maar wel met hier en daar een drop en als ik eindelijk op de speedtest webpagina kom ( âgelukâ dat de outage zo lang duurt ) de test failed op de latency test.
Je zou eens waar de routes zoal langslopen. Wat mij van TMT nog steeds niet duidelijk is wat voor (open ) specificatie ten grondslag ligt aan het gebruik van private 10.x.x.x adressen tussen klantrouter en rest van internet. Het hoeft helemaal niks met deze hicups te maken te hebben, maar het geeft te denken.
Ik ga ervan uit dat ik op ODF zit, ik kan tot 750Mbit upgraden als ik zou willen maar niet ga doen omdat je als vast klant gestraft wordt en 10+ euro meer mag betalen dan een nieuwe klant.
Dat je kan upgraden tot 750Mbit kan ook een soort voorspiegeling zijn; Pas nadat je op de 'upgrade' knop heb gedrukt start T-Mobile de procedure om voor jouw locatie iemand op pad te sturen om de omschakeling te laten uitvoeren.
De slogan 'nieuw prijsplan' kan net zo zijn als "I have very special price for you 🙂 " wat je weleens op een markt hoort. Het speciale eraan is dat je denkt dat je goedkoper uit bent maar uiteindelijk na een tijdje (minuten tot jaren) vaststelt dat dat eigenlijk niet zo is.
Laten we eerst eens kijken of we de problemen kunnen oplossen. Wellicht dat een moderater een lijn meting kan doen en kan zien of er iets raars is op je verbinding. je moet dan wel even het modem van t-mobile aansluiten anders lukt de meting niet goed. Welk modem heb je van T-Mobile ?
Het is een Draytek.
Kun je aangeven wat die lijnmeting voor glasvezel inhoud?
Is het lager dan de IP layer?
Is het een packetlatency test op secondebasis?
En hoe detecteert men dat er een capaciteits probleem is of zou zijn m.b.t. peering?
In een lijnmeting zie je vooral naar de demping van de verbinding. (niet van de kabel)
Je kijkt naar frame errors dus onder de ip layer.
Als je de connector onder de microscoop bekijkt ziet het er zo uit
Vieze connector:
Een connector schoongemaakt met je vinger
Als je de connector niet of verkeerd schoonmaakt.
Een schoongemaakte connector ziet er zo uit
Dit is de oorzaak van een te hoge demping.
Gebruik daarom altijd je juiste tools om je koppelvlakken schoon te maken.
een lijn kan voor een week in monitoring worden gezet. dan kunnen ze eventuele problemen zien.
En hoe detecteert men dat er een capaciteits probleem is of zou zijn m.b.t. peering?
Ik weet niet hoe T-Mobile dit doet dat ga ik even voor je na vragen. maar je heb verschillende core routers er tussen zitten. je buurman met T-Mobile hoeft geen problemen te hebben met de capaciteit zelfde pop maar andere router.
Je kijkt naar frame errors dus onder de ip layer.
Als je de connector onder de microscoop bekijkt ziet het er zo uit
Vieze connector:
Een connector schoongemaakt met je vinger
Als je de connector niet of verkeerd schoonmaakt.
Een schoongemaakte connector ziet er zo uit
Dit is de oorzaak van een te hoge demping.
Gebruik daarom altijd je juiste tools om je koppelvlakken schoon te maken.
een lijn kan voor een week in monitoring worden gezet. dan kunnen ze eventuele problemen zien.
En hoe detecteert men dat er een capaciteits probleem is of zou zijn m.b.t. peering?
Ik weet niet hoe T-Mobile dit doet dat ga ik even voor je na vragen. maar je heb verschillende core routers er tussen zitten. je buurman met T-Mobile hoeft geen problemen te hebben met de capaciteit zelfde pop maar andere router.
Tweede keer vandaag dat de boel weer niets doet, het begint normaal te worden........
Traceroute naar google:
Traceroute naar google:
Hi @Bart_Smith , bedankt voor de informatie! Te zien aan de traceroute vindt de packet loss al plaats in je interne netwerk, dus al voordat je verbinding 'naar buiten' gaat. Hoe ziet je opstelling er uit? Heb je toevallig nog een router/switch achter je modem zitten? Als je alleen de modem aansluit zonder andere hardware ervaar je de problemen dan ook? Ik kan eventueel de binnenkomende verbinding controleren zoals @Hidden.nld aangeeft maar dit kan alleen wanneer het door ons geleverde modem aan is gesloten. Aan de hand van het geplaatste screenshot lijkt het alleen niet de binnenkomende verbinding te zien maar iets op je interne netwerk. Ik ben benieuwd naar de resultaten van de 'cleane' verbinding!
Hoi @Brian
De traceroute die ik heb gepost is vanaf de router, dus direct naar buiten en niet over een intern netwerk.
Dus voor de duidelijkheid, de traceroute begint direct op de WAN/SFP poort.
De connectie is als volgt:
Glasvezel---------SFP|MikroTIK RB3011|LAN1------------PC
Omdat het probleem intermittend is is het lastig te troubleshooten, als het voorkomt, en ik de Draytek aansluit is het meestal weer weg of zwakt af.
PS: vandaag nog geen problemen ondervonden.
De traceroute die ik heb gepost is vanaf de router, dus direct naar buiten en niet over een intern netwerk.
Dus voor de duidelijkheid, de traceroute begint direct op de WAN/SFP poort.
De connectie is als volgt:
Glasvezel---------SFP|MikroTIK RB3011|LAN1------------PC
Omdat het probleem intermittend is is het lastig te troubleshooten, als het voorkomt, en ik de Draytek aansluit is het meestal weer weg of zwakt af.
PS: vandaag nog geen problemen ondervonden.
Als je goed kijkt naar die traceroute, is de eerste hop de TM netwerkrouter waar
Pingen of traceroute zeggen ook eigenlijk niet zoveel, omdat echt een momentopname is, veel belangrijker is of je bandbreedte op dat moment knijp loopt.
Dus als het weer gebeurt, check dan eens je bandbreedte of die niet klein is.
Er is trouwens een plugin "Magic Actions for Youtube" voor chrome, maar dat is natuurlijk een lapmiddel op een gevolg.
YT filmpje voor de settings
Ah my bad, ik dacht dat de 10.x.x.x. adressen interne adressen waren 
Hoi,
Packetloss op T-Mobile's netwerk.
Packetloss op T-Mobile's netwerk.
Hi @Bart_Smith , ik heb al een reactie van mijn collega's. Dat er drops zijn is duidelijk maar wat de oorzaak is nog niet en daarnaast vertellen alleen de drops nog niet het hele verhaal. Mijn collega geeft overigens aan dat alleen de 10.10.10.xxx adressen ons domein zijn. De 108.170.xxx.xxx zijn het Google domein. Ik zou toch je binnenkomende verbinding eens willen controleren, is het voor jou mogelijk om tijdelijk ons modem aan te sluiten zodat we deze uit kunnen lezen? Ik hoor het graag!
Edit: Ik ben ook benieuwd of je verder nog andere hardware aan hebt gesloten of is het echt een rechtstreekse verbinding van desktop/laptop naar het modem? En misschien wat lastig te testen maar welke snelheid haal je via een speedtest op het moment dat het gebeurt? En speelt het op meerdere apparaten?
Edit: Ik ben ook benieuwd of je verder nog andere hardware aan hebt gesloten of is het echt een rechtstreekse verbinding van desktop/laptop naar het modem? En misschien wat lastig te testen maar welke snelheid haal je via een speedtest op het moment dat het gebeurt? En speelt het op meerdere apparaten?
Hoi,
Ik ben nu bezig met diverse andere hardware te testen.
Routers om te testen :
MikroTIk RB3011 direct op de glasvezel.
TP-Link MC 220L + Asus RT66U
Draytek Provider modem
Lokaal netwerk:
PC 1 - UTP
PC 2 - UTP
Laptop - UTP
ShieldTV - UTP
Probleem komt voor op alle apparaten.
Bijna elke dag valt de verbinding weg ( dat wil zeggen , wel internet connectie, kan pigen maar met packetloss, speedtest failed op eerste test - Latency time-out )
Beetje raar dat je vraagt hoe mijn interne apparaten aangesloten zijn, als de screenshot duidelijk laten zien dat de packetloss buiten mijn WAN IP beginnen en ik de traceroutes direct op de router uitvoer.
Ik ben nu nog eerst met de Asus aan het testen, omdat het draytek modem niet genoeg poorten heeft voor mijn apparaten en ik dan met een handicapt netwerk zit.
Wanneer het ook voorkomt op de Asus gaat de Draytek er wel op en bel ik de helpdesk om te testen.
Ik ben nu bezig met diverse andere hardware te testen.
Routers om te testen :
MikroTIk RB3011 direct op de glasvezel.
TP-Link MC 220L + Asus RT66U
Draytek Provider modem
Lokaal netwerk:
PC 1 - UTP
PC 2 - UTP
Laptop - UTP
ShieldTV - UTP
Probleem komt voor op alle apparaten.
Bijna elke dag valt de verbinding weg ( dat wil zeggen , wel internet connectie, kan pigen maar met packetloss, speedtest failed op eerste test - Latency time-out )
Beetje raar dat je vraagt hoe mijn interne apparaten aangesloten zijn, als de screenshot duidelijk laten zien dat de packetloss buiten mijn WAN IP beginnen en ik de traceroutes direct op de router uitvoer.
Ik ben nu nog eerst met de Asus aan het testen, omdat het draytek modem niet genoeg poorten heeft voor mijn apparaten en ik dan met een handicapt netwerk zit.
Wanneer het ook voorkomt op de Asus gaat de Draytek er wel op en bel ik de helpdesk om te testen.
Hi @Bart_Smith , we zijn aan onze kant ook een aantal zaken aan het nalopen, ik heb naar aanleiding daarvan nog een drietal vragen:
Ik hoor het graag!
- Wanneer is het probleem precies begonnen, sinds welke datum?
- Speelt het probleem de hele dag of alleen in de avond?
- Zijn er alleen problemen met Google Diensten? Je noemt Youtube en pingt naar de Google DNS, hoe zit het bijvoorbeeld met packetloss naar Facebook of iets dergelijks, gaat dit wel goed of ervaar je hier hetzelfde mee?
Ik hoor het graag!
Ik zou zeggen gebruik thuis.t-mobile.nl (31.201.6.41) als referentie voor ping i.p.v. 8.8.8.8. Of misschien is er een ander IP adres wat sowieso binnen de verantwoordelijkheid van T-Mobile Thuis ligt.
Dan kan ik net zo goed naar localhost pingen.
Als ik naar de DNS van Google ping en de packetloss start al op het T-Mobile netwerk, kan ik je zeggen dat dat niet aan Goggle ligt :)
Wanneer is het probleem precies begonnen, sinds welke datum?
- Eigenlijk al een maand of 3, maar duidelijk na de eerste grote netwerk onderhoud dit jaar.
- Het is zeer random, dus zeg maar de hele dag
- Eigenlijk elke denkbare service al is email wat lastiger te meten.
Als ik naar de DNS van Google ping en de packetloss start al op het T-Mobile netwerk, kan ik je zeggen dat dat niet aan Goggle ligt :)
De gedachte hierachter is dat het hopelijk meer focus legt bij T-Mobile op de packetloss. Vragen van een moderator over website- of diensten niveau (Facebook b.v.) leiden alleen maar de aandacht af en komt dan in feite neer op tijdrek ten toon spreiden en wekt de indruk dat er een poging wordt gedaan om de oorzaak buiten T-Mobile te zoeken, terwijl in ieder geval bij mij duidelijk is dat T-Mobile hier aan zet is om het probleem voor jouw op te lossen.
Hi @tmoesel , erg jammer dat je (opnieuw) aannames doet over onze reacties, ik zou het fijn vinden als je deze aannames checkt, we kunnen altijd in gesprek. Ze kloppen namelijk niet 😉 In dit geval kwamen de vragen rechtstreeks van ons netwerk team, zij hebben een vermoeden van de mogelijk oorzaak maar wilden een aantal zaken bevestigd zien.
@Bart_Smith De informatie is helaas nog niet specifiek genoeg maar we hebben andere aansluitingen in het gebied bekeken en we zien hier geen vergelijkbare situaties. Wel zien we een stijging in het verkeer en de packet loss is lastig te verklaren dus we hebben de melding doorgezet naar onze netwerkpartner.
We zijn er dus zeker serieus mee bezig maar om realistische verwachtingen te scheppen (ik zou niet willen dat je denkt dat ik tijd rek 😉 ), het kan een tijdje duren voordat we hier een terugkoppeling op otnvangen van onze netwerkpartner om het hier om Ă©Ă©n enkel geval specifiek geval gaat. Uiteraard is elke klant even belangrijk maar de realiteit is dat er een prioritering gemaakt moet worden in eventuele netwerkissues. Dat gezegd hebbende houd ik je vraag persoonlijk in de gaten en je ontvangt hoe dan ook een update!
We zijn er dus zeker serieus mee bezig maar om realistische verwachtingen te scheppen (ik zou niet willen dat je denkt dat ik tijd rek 😉 ), het kan een tijdje duren voordat we hier een terugkoppeling op otnvangen van onze netwerkpartner om het hier om Ă©Ă©n enkel geval specifiek geval gaat. Uiteraard is elke klant even belangrijk maar de realiteit is dat er een prioritering gemaakt moet worden in eventuele netwerkissues. Dat gezegd hebbende houd ik je vraag persoonlijk in de gaten en je ontvangt hoe dan ook een update!
Ik heb nog geen zwart-wit aannames gedaan, vandaar mijn bewoording:
"tijdrek ten toon spreiden"; dat is een constatering dat het probleem nog niet opgelost is, het duurt voort.
"wekt de indruk"; dit is een beschrijving van een process van beeldvorming
Een ander punt is dat deze thread op beantwoord staat. Is vaker gebleken dat dat niet in goede aarde valt als het probleem waarom een thread is aangemaakt, nog niet is opgelost.
Als je in gesprek zou willen met mij: dat lost verder niks op voor Bart_Smith. Iemand van het netwerk team, kan in principe direct in gesprek met hem, hij heeft ruim voldoende technische bagage en kunde daarvoor is mijn indruk.
Verder zijn technische details en ook daaraan verbonden commerciele overwegingen doorgaans vertrouwelijk. Dus o.a. mijn opmerking en eigenlijk gewoon een vraag: "Wat mij van TMT nog steeds niet duidelijk is wat voor (open ) specificatie ten grondslag ligt aan het gebruik van private 10.x.x.x adressen tussen klantrouter en rest van internet." zal verder zo blijven zoals dat is.
OFF_TOPIC
Private IP's worden ook door andere netwerken toegepast en is dus wel degelijk geen vreemde of afwijkende werkwijze. De reden waarom is verschillend en soms ook omstreden, maar het gebruik ervan is wereldwijd.
Hierboven dus een stortvloed van private IP's, dus@tmoesel .. voorstander of niet .. het gebeurt overal en dus niet alleen in het TM netwerk zoals je hierboven ziet naar IP: 188.162.12.1
Hier stelt iemand diezelfde vraag, waarom zie ik in mijn traceroute private IP's
/OFF_TOPIC
Private IP's worden ook door andere netwerken toegepast en is dus wel degelijk geen vreemde of afwijkende werkwijze. De reden waarom is verschillend en soms ook omstreden, maar het gebruik ervan is wereldwijd.
code:
pieter@B:~$ traceroute 188.162.12.1
traceroute to 188.162.12.1 (188.162.12.1), 64 hops max
1 192.168.x.x 0,409ms 0,223ms 0,214ms - internal
2 192.168.x.x 0,856ms 0,471ms 0,422ms - internal
3 31.201.x.x 3,746ms 3,349ms 3,321ms - WAN
4 10.10.80.149 4,455ms 3,965ms 4,177ms
5 80.249.208.125 10,777ms 4,809ms 4,969ms
6 83.169.204.90 103,647ms 103,292ms 103,354ms
7 83.169.204.85 103,655ms 103,865ms 103,085ms
8 10.222.78.133 104,100ms 103,689ms 103,954ms
9 10.222.177.166 110,513ms 107,805ms 107,579ms
10 * * *
11 10.222.2.170 108,438ms 108,114ms 108,119ms
12 10.222.54.122 127,025ms 114,408ms 185,944ms
13 37.29.17.74 108,695ms 108,784ms 108,332ms
14 10.92.130.129 104,253ms 103,533ms 103,192ms
15 * * *
16 * * *
17 * * *
Hierboven dus een stortvloed van private IP's, dus
Hier stelt iemand diezelfde vraag, waarom zie ik in mijn traceroute private IP's
/OFF_TOPIC
Bart_Smith stelt min of meer dat er een oplossing van T-Mobile moet komen anders is de andere optie/oplossing overstappen.
Gezien dat het hier om een gebruiker gaat die z'n eigen router gebruikt, lijkt voor overstapkeuze hoofdzakelijk de karakteristiek van de internet verbinding nog het onderscheid (in ieder geval technisch gezien, misschien spelen andere TMO abo's ook nog een rol). Wel/niet IPv6, DualStack of DualStack Lite, PPPoE of niet, 464XLAT zoals b.v. TMO US, etc, etc.
Toepassing van 10.0.0.0/8 komt meer voor, hoewel ik dit bij T-Mobile Thuis voor het eerst zie als ISP. Bij KPN en Ziggo heb ik dit niet gezien. Ikzelf had in binnen- en buitenland altijd compleet DualStack sinds IPv6 gemeengoed is en geen private IP's, nu bij TMO NL alleen IPv4. Medio dit jaar wordt het glasvezel met o.a. PPPoE.
Please be informed that no packet loss was found in the last hop (8.8.8.8) meaning that it might be a control plane policy enforced during the path.
On the other side i have tried to ping the destination 8.8.8.8 from the bng where the customer is connected and no packet loss could be found using 1000 packets.
RP/0/RSP0/CPU0:bng2.asd-dc2.nl#ping 8.8.8.8 source Loopback0 repeat 1000
Thu May 30 17:32:54.719 CEST
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
?Success rate is 100 percent (1000/1000), round-trip min/avg/max = 2/2/8 ms
Please check with our customer for local connectivity issues or bandwidth utilisation direct on customer cpe. Also check for other sites/destinations where the trace might show the same behavior.
We zien dus zelf op testen geen packet loss als we direct vanaf de BNG pingen naar Google. We hebben ook geen andere meldingen uit jouw regio hierover ontvangen. Het vreemde is wel dat je het met verschillende modems hebt dus de CPE lijkt ook niet de oorzaak te zijn. Als je een aantal specifieke websites als voorbeeld hebt dan kunnen we hier nog verder naar kijken of we een mogelijke oorzaak kunnen vinden maar op dit moment heb ik in alle eerlijkheid geen oplossing voorhanden omdat we het issue niet kunnen reproduceren.
Ik heb op het moment ook geen issues meer (een paar dagen al )
Ik zit nog steeds met mijn eigen apparatuur te werken.
Hopelijk is het dan vanzelf opgelost.
Ik zit nog steeds met mijn eigen apparatuur te werken.
Hopelijk is het dan vanzelf opgelost.
Reageer
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.