Fixing things to the breaking point...
Naar welk endpoint doe jij een ping? Dit wil ik ook op gaan zetten zodat ik dit goed kan monitoren.RGAT schreef op donderdag 7 november 2019 @ 21:25:
Ja hij schoot tussen ~8:15 en ~9:10 even lekker naar 150ms ping en 60% packet loss, hoop dat ze toch weer snel uitvogelen hoe ze het normaal laten werken ipv dit soort gedoe...
Home Assistant | ☀️ 2900 Wp PVOutput | 🔋 Tesla Model 3 RWD 2024
Die mooie verbinding ging naar 1.1.1.1, verder is 8.8.8.8/8.8,4,4, de twee van OpenDNS (en 1.0.0.1) en de website van T-Mobile aangezien die tijdens het DTAG routeren ook zo slecht werkte, daarnaast naar een VPS die toch al draait, wat maar beschikbaar is dusadjego schreef op vrijdag 8 november 2019 @ 08:23:
[...]
Naar welk endpoint doe jij een ping? Dit wil ik ook op gaan zetten zodat ik dit goed kan monitoren.
Fixing things to the breaking point...
EDIT: Dit ligt volgens mij bij Ziggo heb ik al iets over ontdekt.
[ Voor 22% gewijzigd door adjego op 08-11-2019 14:45 ]
Home Assistant | ☀️ 2900 Wp PVOutput | 🔋 Tesla Model 3 RWD 2024
Nee, dat klopt niet helemaal. DTAG (AS3320) is gewoon aanwezig in Amsterdamse PoPs (Points of Presence) en peert in Amsterdam ook met andere Tier-1 netwerken, zoals NTT. De vraag is of die interconnectie capaciteit van AS3320 met andere Tier-1 netwerken voldoende is in Amsterdam. Verkeer wat niet kan worden uitgewisseld in Amsterdam wordt door DTAG naar andere DTAG PoPs in Frankfurt, Parijs, Londen, etc. geleid, om daar uit te wisselen en dat geeft een klein beetje extra latency.ANdrode schreef op maandag 4 november 2019 @ 11:46:
[...]
Even de samenvatting van wat ik observeerde: Al het verkeer ging via DTAG, maar verkeer ging vanuit DTAG in duitsland transit in in plaats van in Nederland/Amsterdam (zoals je zou verwachten).
Klopt die samenvatting?
Er was denk ik niet veel gebeurd als T-Mobile het goed had voorbereid en alleen AS1273 had ingewisseld voor AS3320. Het kappen door T-Mobile van de AMS-IX/NL-IX peerings in Amsterdam is dom geweest. Al het zware media verkeer (Google/Youtube, Akamai, enz.) ging dus ook over die enkele DTAG link i.p.v. over de AMS-IX/NL-IX, wat een hoop 'saturation' veroorzaakt en vervelend is voor eindgebruikers. Afgezet tegen het media internetverkeer is het transitverkeer van 'normale' data maar relatief klein. De Googles, Akamais, Netflixen, enz. peeren veelal direct (private peering) of via een internet exchange.
Wat wij observeerden was zware loss, niet een beetje extra latency. Geen paar procent (die je alleen merkt aan kleiner TCP window) maar 15-25% in combinatie met 30ms extra latency. Daar kom je de halve oceaan naar de VS mee over.camco schreef op vrijdag 8 november 2019 @ 18:21:
[...]
Nee, dat klopt niet helemaal. DTAG (AS3320) is gewoon aanwezig in Amsterdamse PoPs (Points of Presence) en peert in Amsterdam ook met andere Tier-1 netwerken, zoals NTT. De vraag is of die interconnectie capaciteit van AS3320 met andere Tier-1 netwerken voldoende is in Amsterdam. Verkeer wat niet kan worden uitgewisseld in Amsterdam wordt door DTAG naar andere DTAG PoPs in Frankfurt, Parijs, Londen, etc. geleid, om daar uit te wisselen en dat geeft een klein beetje extra latency.
En hoewel je outbound verkeer kan sturen is dat voor inbound verkeer lastiger. Je zegt nu "wordt door DTAG naar een andere pop" geleid, maar voor verkeer terug krijg je dat alleen voor elkaar door de meest specifieke route te adverteren vanuit Frankfurt (het is immers BGP

[ Voor 17% gewijzigd door citruspers op 09-11-2019 16:35 ]
hmm, ik had hier vanmorgen wel beetje traag maar inmiddels via Fing getest en krijg 82.8Mbps down (100mbit abonnement).citruspers schreef op zaterdag 9 november 2019 @ 16:32:
Hier is de internetsnelheid weer gigantisch aan het inkakken. Steam die maar 700KB/s download, Hetzner speedtest die niet boven de 20MB/s uitkomt....verschillende speedtests die wisselen tussen 50 en 200 mbits/s
Hier geen problemen, meerdere speedtests gedaan op meerder locaties van speedtest.netcitruspers schreef op zaterdag 9 november 2019 @ 16:32:
Hier is de internetsnelheid weer gigantisch aan het inkakken. Steam die maar 700KB/s download, Hetzner speedtest die niet boven de 20MB/s uitkomt....verschillende speedtests die wisselen tussen 50 en 200 mbits/s

Hop 195.2.22.202 (C&W) is wederom de boosdoener.
Komende week bellen op mijn abbo na ~2 maanden op te zeggen. Wanneer ze niet happen dan gaat de rechtsbijstand ingeschakeld worden.
[ Voor 10% gewijzigd door thelightning op 10-11-2019 10:42 ]
Kan je een mtr vanaf twee kanten doen? Op de route waarop ik zoiets zag was er een asymmetrische route.thelightning schreef op zondag 10 november 2019 @ 10:39:
Hop 195.2.22.202 (C&W) is wederom de boosdoener.
1 thuis.local.lan (10.40.40.1) 0.162 ms 0.107 ms 0.085 ms
2 1-2-201-31.ftth.glasoperator.nl (31.201.2.1) 1.804 ms 1.981 ms 2.116 ms
3 10.10.80.149 (10.10.80.149) 8.666 ms 8.406 ms 8.605 ms
4 ae24-xcr1.amt.cw.net (195.89.97.129) 6.082 ms 6.091 ms 6.058 ms
5 195.2.22.202 (195.2.22.202) 110.167 ms 110.836 ms 110.822 ms
6 fusixnetworks.te0-2-0-17.br01.ams02.pccwbtn.net (63.218.65.98) 110.420 ms 109.700 ms 109.647 ms
7 r0.eunets.nl.fusixnetworks.net (37.139.139.250) 109.125 ms 109.880 ms 109.016 ms
root@webmail:/home/frank# traceroute 85.144.157.x
traceroute to 85.144.157.89 (85.144.157.89), 30 hops max, 60 byte packets
1 192.168.20.1 (192.168.20.1) 0.159 ms 0.127 ms 0.104 ms
2 router2.fusixnetworks.net (37.139.136.19) 0.495 ms 0.471 ms 0.430 ms
3 r0.drtam1.nl.fusixnetworks.net (37.139.139.251) 0.461 ms 0.419 ms 0.411 ms
4 te0-2-0-17.br01.ams02.pccwbtn.net (63.218.65.97) 1.166 ms 1.299 ms 1.289 ms
5 195.2.22.201 (195.2.22.201) 103.636 ms 103.630 ms 103.610 ms
6 vod-lib-gw1.nl.cw.net (195.89.97.130) 104.709 ms 104.754 ms 104.745 ms
7 * * *
Een asymmetrischeroute is niet perse een probleem. Als het maar efficiente routes zijn die niet overbelast zijn. Bij T-mobile is het zowel verre van efficient en daarnast is de boel ook nog eens extreem overbelast.
Er word wel round the clock gewerkt aan het netwerk getuige de plotselinge aanpassing (lees: verslechtering) van het netwerk om 08:30 vanochtend maar dit praat echt niets goed. We hadden nooit in deze situatie mogen zitten. Dit straalt aan alle kanten amateuristisch prutswerk uit. Ze proberen weer grip te krijgen op de situatie maar tot nu toe lossen ze het ene probleem op maar creeren ze er 3 nieuwe ergens anders.
Maar waren deze routing problemen er dan niet voor 25 oktober?thelightning schreef op zondag 10 november 2019 @ 11:10:
Een asymmetrischeroute is niet perse een probleem. Als het maar efficiente routes zijn die niet overbelast zijn. Bij T-mobile is het zowel verre van efficient en daarnast is de boel ook nog eens extreem overbelast.
Er word wel round the clock gewerkt aan het netwerk getuige de plotselinge aanpassing (lees: verslechtering) van het netwerk om 08:30 vanochtend maar dit praat echt niets goed. We hadden nooit in deze situatie mogen zitten. Dit straalt aan alle kanten amateuristisch prutswerk uit. Ze proberen weer grip te krijgen op de situatie maar tot nu toe lossen ze het ene probleem op maar creeren ze er 3 nieuwe ergens anders.
Dan zijn we weer terug bij af volgens mij, ondanks alle mooie propaganda van T-Mobile.
Hebben ze geen webcare Tweeakers account?
Puurt ter referentie hoe het Ziggo pad loopt.thelightning schreef op zondag 10 november 2019 @ 11:10:
traceroute to www.server-works.com (37.139.136.20), 30 hops max, 60 byte packets
1 thuis.local.lan (10.40.40.1) 0.162 ms 0.107 ms 0.085 ms
2 1-2-201-31.ftth.glasoperator.nl (31.201.2.1) 1.804 ms 1.981 ms 2.116 ms
3 10.10.80.149 (10.10.80.149) 8.666 ms 8.406 ms 8.605 ms
4 ae24-xcr1.amt.cw.net (195.89.97.129) 6.082 ms 6.091 ms 6.058 ms
5 195.2.22.202 (195.2.22.202) 110.167 ms 110.836 ms 110.822 ms
6 fusixnetworks.te0-2-0-17.br01.ams02.pccwbtn.net (63.218.65.98) 110.420 ms 109.700 ms 109.647 ms
7 r0.eunets.nl.fusixnetworks.net (37.139.139.250) 109.125 ms 109.880 ms 109.016 ms
root@webmail:/home/frank# traceroute 85.144.157.x
traceroute to 85.144.157.89 (85.144.157.89), 30 hops max, 60 byte packets
1 192.168.20.1 (192.168.20.1) 0.159 ms 0.127 ms 0.104 ms
2 router2.fusixnetworks.net (37.139.136.19) 0.495 ms 0.471 ms 0.430 ms
3 r0.drtam1.nl.fusixnetworks.net (37.139.139.251) 0.461 ms 0.419 ms 0.411 ms
4 te0-2-0-17.br01.ams02.pccwbtn.net (63.218.65.97) 1.166 ms 1.299 ms 1.289 ms
5 195.2.22.201 (195.2.22.201) 103.636 ms 103.630 ms 103.610 ms
6 vod-lib-gw1.nl.cw.net (195.89.97.130) 104.709 ms 104.754 ms 104.745 ms
7 * * *
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. AS??? 172.16.1.1 0.0% 25 0.7 1.1 0.7 2.2 0.4 2. (waiting for reply) 3. AS33915 mnd-rc0001-cr101-ae124-0.core.as9143.net 0.0% 25 7.6 9.8 7.5 15.6 2.3 4. AS33915 asd-rc0001-cr101-be105-2.core.as33915.net 0.0% 25 11.0 10.6 8.7 17.3 2.1 5. AS33915 nl-ams17b-rc1-lag60-2.core.as33915.net 69.6% 24 8.7 9.6 8.3 14.1 2.0 6. AS6830 nl-ams04a-ri3-ae-9-0.aorta.net 0.0% 24 10.1 13.0 8.8 26.0 5.0 7. AS57866 cr0.nikhef.nl.fusixnetworks.net 0.0% 24 9.3 11.9 8.1 20.3 3.1 8. AS57866 www.server-works.com 0.0% 24 9.2 9.8 8.6 13.9 1.2 PING www.server-works.com (37.139.136.20): 56 data bytes 64 bytes from 37.139.136.20: icmp_seq=0 ttl=56 time=9.340 ms 64 bytes from 37.139.136.20: icmp_seq=1 ttl=56 time=8.805 ms 64 bytes from 37.139.136.20: icmp_seq=2 ttl=56 time=10.332 ms 64 bytes from 37.139.136.20: icmp_seq=3 ttl=56 time=10.347 ms 64 bytes from 37.139.136.20: icmp_seq=4 ttl=56 time=10.211 ms |
traceroute to www.server-works.com (37.139.136.20), 30 hops max, 60 byte packetsthelightning schreef op zondag 10 november 2019 @ 11:10:
traceroute to www.server-works.com (37.139.136.20), 30 hops max, 60 byte packets
1 thuis.local.lan (10.40.40.1) 0.162 ms 0.107 ms 0.085 ms
2 1-2-201-31.ftth.glasoperator.nl (31.201.2.1) 1.804 ms 1.981 ms 2.116 ms
3 10.10.80.149 (10.10.80.149) 8.666 ms 8.406 ms 8.605 ms
4 ae24-xcr1.amt.cw.net (195.89.97.129) 6.082 ms 6.091 ms 6.058 ms
5 195.2.22.202 (195.2.22.202) 110.167 ms 110.836 ms 110.822 ms
6 fusixnetworks.te0-2-0-17.br01.ams02.pccwbtn.net (63.218.65.98) 110.420 ms 109.700 ms 109.647 ms
7 r0.eunets.nl.fusixnetworks.net (37.139.139.250) 109.125 ms 109.880 ms 109.016 ms
1 192.168.1.1 (192.168.1.1) 0.585 ms 0.956 ms 1.214 ms
2
3 10.10.10.201 (10.10.10.201) 7.372 ms 7.641 ms 7.998 ms
4 10.10.10.197 (10.10.10.197) 8.282 ms 8.593 ms 8.942 ms
5 195.2.22.202 (195.2.22.202) 112.717 ms 113.949 ms 114.419 ms
6 fusixnetworks.te0-2-0-17.br01.ams02.pccwbtn.net (63.218.65.98) 112.263 ms 108.311 ms 108.573 ms
7 r0.eunets.nl.fusixnetworks.net (37.139.139.250) 108.907 ms 109.308 ms 109.623 ms
Geen .cw.net bij mij
Anoniem: 1260028
Raar dat er verschillende routes bewandeld worden om bij deze hop uit te komen....space-one schreef op zondag 10 november 2019 @ 14:15:
[...]
traceroute to www.server-works.com (37.139.136.20), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 0.585 ms 0.956 ms 1.214 ms
2
3 10.10.10.201 (10.10.10.201) 7.372 ms 7.641 ms 7.998 ms
4 10.10.10.197 (10.10.10.197) 8.282 ms 8.593 ms 8.942 ms
5 195.2.22.202 (195.2.22.202) 112.717 ms 113.949 ms 114.419 ms
6 fusixnetworks.te0-2-0-17.br01.ams02.pccwbtn.net (63.218.65.98) 112.263 ms 108.311 ms 108.573 ms
7 r0.eunets.nl.fusixnetworks.net (37.139.139.250) 108.907 ms 109.308 ms 109.623 ms
Geen .cw.net bij mij
1 <1 ms <1 ms <1 ms 192.168.10.1
2
3 7 ms 6 ms 6 ms 10.10.80.98
4 6 ms 5 ms 5 ms ae24-xcr1.amt.cw.net [195.89.97.129]
5 109 ms 108 ms 108 ms 195.2.22.202
6 109 ms 108 ms * fusixnetworks.te0-2-0-17.br01.ams02.pccwbtn.net [63.218.65.98]
7 108 ms 109 ms 109 ms r0.eunets.nl.fusixnetworks.net [37.139.139.250]
8 109 ms 109 ms 109 ms www.server-works.com [37.139.136.20]
Maar na de hop cw.net loopt de latency op tot boven de 100 ms....
Nee, ze hebben eigen forum (T-Mobile Community)
[ Voor 7% gewijzigd door Soundwork op 10-11-2019 18:15 ]
Je zou dit toch eens met de klantenservice kunnen bespreken, deze hop is altijd 110ms? Heeft iemand hem al eens lager gezien, ligt deze hop niet ergens in de USA? Zijn er meer locaties die altijd deze hop nemen?
-109 ms 108 ms 108 ms 195.2.22.202
-109 ms 108 ms * fusixnetworks.te0-2-0-17.br01.ams02.pccwbtn.net [63.218.65.98]
-108 ms 109 ms 109 ms r0.eunets.nl.fusixnetworks.net [37.139.139.250]
Feitelijk is het een C&W probleem en niet zozeer van T-Mobile je bent nl dan al op de 2e hop in het C&W netwerk. De eerste hop tussen TM en C&W is heel netjes met 6ms.
- 6 ms 5 ms 5 ms ae24-xcr1.amt.cw.net [195.89.97.129]
-109 ms 108 ms 108 ms 195.2.22.202
[ Voor 17% gewijzigd door stormfly op 10-11-2019 19:09 ]
Wat testen gedaan en als ik iemand die KPN glas heeft via mij iets download gaat dit met zijn maximale snelheid van 100 Mbit. Doe ik ditzelfde testje vanuit een Ziggo verbinding, dan gaat dit met maximaal 600 Kbitadjego schreef op vrijdag 8 november 2019 @ 11:05:
Er lijkt echt weer iets heel mis te zijn. Van T-mobile naar Ziggo gaat nu maar met 1 MB/s met een 1 Gbit verbinding.
EDIT: Dit ligt volgens mij bij Ziggo heb ik al iets over ontdekt.

Heeft die lage snelheid van T-Mobile naar Ziggo te maken met deze trage ping die we zien richting 37.139.136.20? Of zijn dit toch twee verschillende problemen? Zoals gezegd van T-Mobile uploaden naar KPN gaat prima, maar van T-Mobile bestand uploaden naar Ziggo gaat eigenlijk niet.
Overigens gaan mijn speedtests allemaal meer dan prima.

Home Assistant | ☀️ 2900 Wp PVOutput | 🔋 Tesla Model 3 RWD 2024

Ik Ping die hop ook vanuit ziggo en zie dezelfde grafiek onder de “0” lijn. Het piekje boven de lijn heb ik niet.thelightning schreef op maandag 11 november 2019 @ 08:08:
Dit is wat men kan verwachten van de T-Mobile transit verbindings kwaliteit sinds zondagochtend 08:30
[Afbeelding]
Welke sites gaan over dit pad zijn dat er veel?
Dit is ping naar een router. Die worden regelmatig gedropt als de router zwaar belast wordt. Het zegt minder over pakketten die echt in dat netwerk gedropt worden.thelightning schreef op maandag 11 november 2019 @ 08:08:
Dit is wat men kan verwachten van de T-Mobile transit verbindings kwaliteit sinds zondagochtend 08:30
[Afbeelding]
Mogelijk moeten we andere targets in dit netwerk zoeken?
Ik heb wat traceroutes vanaf RIPE Atlas probes naar een router in T-Mobile thuis netwerk gemaakt: https://atlas.ripe.net/measurements/23205714/
Mogelijk zijn de probes mooie ping targets (niet heel netjes), maar tags geven aan dat 10501, 10502, 10506, 10507 en 10510 in netwerk core zitten.
edit: Je ziet in deze traces dat meerdere van de routers vanaf CW ook vanaf in hun netwerk vol zitten. Heb een paar van de probes als troubleshooting IP aan smokeping toegevoegd.
[ Voor 16% gewijzigd door ANdrode op 11-11-2019 11:19 ]
Nee helaas was het maar zoANdrode schreef op maandag 11 november 2019 @ 11:13:
[...]
Dit is ping naar een router. Die worden regelmatig gedropt als de router zwaar belast wordt. Het zegt minder over pakketten die echt in dat netwerk gedropt worden.
Ik beheer de omgevingen aan beide kanten van het pad. Het gaat toch echt bij T-mobile goed mis.
Men is wel bezig met wijzigingen in het netwerk lijkt het;

[ Voor 26% gewijzigd door thelightning op 11-11-2019 11:27 ]
Vanuit mijn perspectief zit het in het transit netwerk. Maar bij een link die vol zit verwacht ik niet zo'n steile stijging van normaal gedrag naar vol. Meestal is de overgang geleidelijker (en meer loss en ruis, niet zo'n strakke lijn op 110ms), daarom denk ik dat er ook een andere effect in zit.thelightning schreef op maandag 11 november 2019 @ 11:24:
[...]
Nee helaas was het maar zo
Ik beheer de omgevingen aan beide kanten van het pad. Het gaat toch echt bij T-mobile goed mis.
Ik hoop het wel. Voor een transit provider is dit soort connectivity hun product. Ik heb wat dingen in CW.net aan smokeping toegevoegd en zal mijn conclusie posten als ik wat heb.
Eens met je conclusies, de link heeft te weinig reflectie van piek en dal tijden. Of tenminste niet de Nederlandse piek en dal tijden.ANdrode schreef op maandag 11 november 2019 @ 11:40:
[...]
Vanuit mijn perspectief zit het in het transit netwerk. Maar bij een link die vol zit verwacht ik niet zo'n steile stijging van normaal gedrag naar vol. Meestal is de overgang geleidelijker (en meer loss en ruis, niet zo'n strakke lijn op 110ms), daarom denk ik dat er ook een andere effect in zit.
[...]
Ik hoop het wel. Voor een transit provider is dit soort connectivity hun product. Ik heb wat dingen in CW.net aan smokeping toegevoegd en zal mijn conclusie posten als ik wat heb.
Is uit de Atlas meting te herleiden welk land de kortste ping heeft naar de beruchte C&W 195.2.22.202 hop? Ik zie in de meting niet direct terug wat jij pingt? (lijkt erop van C&W naar TM?) Andersom vanuit C&W werelddelen, naar de beruchte hop kan ook inzicht geven waar deze locatie zich bevindt?
[ Voor 6% gewijzigd door stormfly op 11-11-2019 12:50 ]
Ik pingde (inderdaad) een router op mijn routes naar het internet. Dus van CW naar T-Mobile thuis.stormfly schreef op maandag 11 november 2019 @ 12:49:
[...]
Eens met je conclusies, de link heeft te weinig reflectie van piek en dal tijden. Of tenminste niet de Nederlandse piek en dal tijden.
Is uit de Atlas meting te herleiden welk land de kortste ping heeft naar de beruchte C&W 195.2.22.202 hop? Ik zie in de meting niet direct terug wat jij pingt?
Geolocation van 195.2.22.202 is lastig (RIPE ipmap ondersteunt alleen hostnames).
Traceroutes vanuit T-mobile thuis naar 195.2.22.202
Traceroutes vanuit T-mobile thuis naar www.server-works.com
Traceroutes vanuit CW naar 195.2.22.202
Traceroutes vanuit CW naar www.server-works.com
[ Voor 7% gewijzigd door ANdrode op 11-11-2019 12:59 ]
Heb je al alternatieven in de zelfde prijs range? Netwerk was altijd prima en de kosten ook. Jammer dat Tweak bij ons geen eigen glas heeftIvysaur schreef op zondag 10 november 2019 @ 20:25:
Merk af en toe dat een pagina laden regelmatig wat traag kan zijn. Geef het nog heel even en anders opstappen.

Mijn boefje is liev!
Nee, helaas. Denk dat ik vast zit aan T-Mobile. Of ik moet een tientje ofzo meer lappen per maand en naar KPN. Of gewoon helemaal geen internet meer, maar dan geen updates meer, geen spellen meer downloaden.JB schreef op maandag 11 november 2019 @ 13:12:
[...]
Heb je al alternatieven in de zelfde prijs range? Netwerk was altijd prima en de kosten ook. Jammer dat Tweak bij ons geen eigen glas heeft
Ik hoor hier en daar van bepaalde paden dat er een hoge(re) latency is, maar ik heb hier geen hinder van ondervonden, en ben van mening dat ik anders wel op iedere slak zout kan leggen.
Wil je een super lage latency, dan ben je duidelijk bij TMT niet aan het juiste adres. Wil je "gewoon" kunnen internetten, en boeit het je verder niet, dan is TMT prima in orde.
[ Voor 24% gewijzigd door Jeffrey87 op 11-11-2019 14:15 ]
hele lage latency (vertraging) heeft. Bij mij bij Tweak zijn 3 tot 5 ms geen uitzondering.
En dat je als internetprovider/ beheerder van het netwerk de meest logische routes instelt.
Als je in Leeuwarden op de trein naar Amsterdam stapt dan verwacht je toch ook
niet via Duitsland te reizen?
Oké, voor de meeste dingen op het internet zal het niet verschrikkelijk veel uitmaken.
Maar soms dus wel. Bijvoorbeeld voor spellen spelen via internet.
Anders ben je elke keer meteen als eerste afgeschoten en dan is de lol er ook wel snel af hè.
Connectie werk:

Vanuit mijn werk (Ziggo connectie) een bestand naar mijn NAS uploaden via FTP/HTTP gaat met een prima snelheid, ruim boven de 500 Mbit/s.
Vanuit mijn werk (Ziggo connectie) een bestand van mijn NAS downloaden via FTP/HTTP gaat met een snelheid van net 8 Mbit/s (Upload is hier ook bijna 1 Gbit/s).
Connectie thuis:

Doe ik deze zelfde test vanuit een KPN connectie (glas) dan zijn het uploaden naar mijn NAS en het downloaden van mijn NAS kwa snelheid nagenoeg identiek, en dan gaat hij voor beide naar de max 100 Mbit van de kpn verbinding.
Home Assistant | ☀️ 2900 Wp PVOutput | 🔋 Tesla Model 3 RWD 2024
Bij mij eindigt vrijdag de bedenktijd van 14 dagen voor aanvraag,meteen bellen voor afspraak om zo snel aansluiting te realiseren,blij dat ik verlost ben van deze soap.JB schreef op maandag 11 november 2019 @ 13:12:
[...]
Heb je al alternatieven in de zelfde prijs range? Netwerk was altijd prima en de kosten ook. Jammer dat Tweak bij ons geen eigen glas heeft
https://www.snlr-glasvezel.nl
[ Voor 3% gewijzigd door GRAD85 op 11-11-2019 16:31 ]
Je zult maar een eendagsvlieg zijn en je dag niet hebben.
Bij mij is de opzegging zonder enige vraag of moeilijkheid gedaan en verwerkt.
Kan je hosts noemen?TheyCallMeSexy schreef op dinsdag 12 november 2019 @ 20:44:
Heeft T-Mobile al uitleg gegeven wanneer dit probleem wordt opgelost? Wat een bende sinds die routing naar Duitsland...al 2 weken 100+ ping
Ik merk na de rollback eigenlijk niets meer (en ik heb een heleboel atlas anchors, binnen en buiten Nederland in smokeping staan).
over a maximum of 30 hops:
VB1
1 <1 ms <1 ms <1 ms Vigor.router [192.168.1.1]
2 2 ms 1 ms 1 ms 1-3-201-31.ftth.glasoperator.nl [31.201.3.1]
3 6 ms 6 ms 5 ms 10.10.80.149
4 107 ms 107 ms 90 ms ams-ix.as13335.net [80.249.211.140]
Tracing route to one.one.one.one [1.1.1.1]
over a maximum of 30 hops:
VB2
1 <1 ms <1 ms <1 ms Vigor.router [192.168.1.1]
2 1 ms 2 ms 1 ms 1-3-201-31.ftth.glasoperator.nl [31.201.3.1]
3 6 ms 6 ms 6 ms 10.10.80.149
4 97 ms 109 ms 104 ms ams-ix.as13335.net [80.249.211.140]
5 74 ms 71 ms 72 ms one.one.one.one [1.1.1.1]
Heb een fritz box met een switch ertussen voor versterken van de wifi signaal, maar ging voorheen altijd goed
Als je andere voorbeelden wilt zien, graag laten weten
Welke hoek van het land zit jij? Je haalt idd vrij slechte latency naar 1.1.1.1 Misschien hebben ze ergens een knip gezet in bepaalde klant segmenten, iemand vroeg er al naar vandaag.TheyCallMeSexy schreef op dinsdag 12 november 2019 @ 21:40:
Tracing route to ams-ix.as13335.net [80.249.211.140]
over a maximum of 30 hops:
VB1
1 <1 ms <1 ms <1 ms Vigor.router [192.168.1.1]
2 2 ms 1 ms 1 ms 1-3-201-31.ftth.glasoperator.nl [31.201.3.1]
3 6 ms 6 ms 5 ms 10.10.80.149
4 107 ms 107 ms 90 ms ams-ix.as13335.net [80.249.211.140]
Tracing route to one.one.one.one [1.1.1.1]
over a maximum of 30 hops:
VB2
1 <1 ms <1 ms <1 ms Vigor.router [192.168.1.1]
2 1 ms 2 ms 1 ms 1-3-201-31.ftth.glasoperator.nl [31.201.3.1]
3 6 ms 6 ms 6 ms 10.10.80.149
4 97 ms 109 ms 104 ms ams-ix.as13335.net [80.249.211.140]
5 74 ms 71 ms 72 ms one.one.one.one [1.1.1.1]
Heb een fritz box met een switch ertussen voor versterken van de wifi signaal, maar ging voorheen altijd goed
Als je andere voorbeelden wilt zien, graag laten weten
[ Voor 4% gewijzigd door stormfly op 12-11-2019 21:43 ]
Haaksbergen gebruik eigen router met daarvoor switch voor de vlanstormfly schreef op dinsdag 12 november 2019 @ 21:53:
Ben benieuwd of de overige met een hoge latency ook oostelijk wonen?
traceroute to 80.249.211.140 (80.249.211.140), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 1.450 ms 1.303 ms 38.935 ms
2 1-192-201-31.ftth.glasoperator.nl (31.201.192.1) 6.030 ms 6.629 ms 6.948 ms
3 10.10.10.201 (10.10.10.201) 7.346 ms 8.465 ms 7.648 ms
4 ams-ix.as13335.net (80.249.211.140) 10.463 ms 13.245 ms 11.244 ms
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 0.768 ms 0.926 ms 1.106 ms
2 1-192-201-31.ftth.glasoperator.nl (31.201.192.1) 5.867 ms 6.195 ms 6.502 ms
3 10.10.10.201 (10.10.10.201) 7.277 ms 7.540 ms 7.895 ms
4 10.10.10.197 (10.10.10.197) 8.544 ms 8.155 ms 8.761 ms
5 one.one.one.one (1.1.1.1) 9.127 ms 9.352 ms 9.699 ms

destination 37.139.136.20
[ Voor 10% gewijzigd door thelightning op 13-11-2019 09:14 ]
Opvallend dat je dit ziet naar Cloudflare (as13335). Wat ik zie is erg netjes (217 average median gedeeld door standard deviation):TheyCallMeSexy schreef op dinsdag 12 november 2019 @ 21:40:
Heb een fritz box met een switch ertussen voor versterken van de wifi signaal, maar ging voorheen altijd goed
Als je andere voorbeelden wilt zien, graag laten weten

Of de afgelopen tien dagen:

ODF en eigen openwrt router
En naar CW zie ik alleen issues bij die specifieke router:

[ Voor 6% gewijzigd door ANdrode op 13-11-2019 09:59 ]
Idem hiero.Soundwork schreef op woensdag 13 november 2019 @ 14:33:
Wat me opvalt, is dat mijn connectie qua routing even een paar minuten wegvalt, en dan is de verbinding weer up. Zonet nog 1 "dip" gehad. Meer mensen last van?
Je zult maar een eendagsvlieg zijn en je dag niet hebben.
De zelfde mail kreeg ik ook toen de ellende begon met het routeren via Duitsland... Gaan ze opnieuw een poging wagen!?
Die mail heb ik niet gekregen. Kan ook gewoon onderhoud zijn aan het fiber netwerk.Qunix schreef op vrijdag 15 november 2019 @ 13:52:
Ik heb net een mail ontvangen dat ze weer onderhoudswerkzaamheden gaan uitvoeren in de nacht van 20 op 21 november tussen 02:00 en 04:00.
De zelfde mail kreeg ik ook toen de ellende begon met het routeren via Duitsland... Gaan ze opnieuw een poging wagen!?
Denk niet dat ze het zo snel weer opnieuw gaan proberen.Qunix schreef op vrijdag 15 november 2019 @ 13:52:
Ik heb net een mail ontvangen dat ze weer onderhoudswerkzaamheden gaan uitvoeren in de nacht van 20 op 21 november tussen 02:00 en 04:00.
De zelfde mail kreeg ik ook toen de ellende begon met het routeren via Duitsland... Gaan ze opnieuw een poging wagen!?
Overigens heb ik geen mail gehad van komende werkzaamheden, en ook niet bij de werkzaamheden van 25 oktober. Dus dat zegt al niets over het wel of niet aanpassen van de routing tables richting DTAG.
Ik heb dezelfde mail net ontvangen. En gezien dat het vorige "onderhoud" op de tijd van dit drama plaats vond ben ik benieuwd hoe het in de ochtend is...Qunix schreef op vrijdag 15 november 2019 @ 13:52:
Ik heb net een mail ontvangen dat ze weer onderhoudswerkzaamheden gaan uitvoeren in de nacht van 20 op 21 november tussen 02:00 en 04:00.
De zelfde mail kreeg ik ook toen de ellende begon met het routeren via Duitsland... Gaan ze opnieuw een poging wagen!?
Moet zeggen dat ik nu in mijn 3de maand buiten het Dtag verhaal geen enkel probleem heb al zou ik liever de ping wat lager zien.
Zodra je voorbij het T-mobile netwerk komen en op de ip range 10.10.xxx.xxx gedumpt word verdubbeld of ver 3 voudigd de ping gewoon. Dit is bij iedereen te zien die een traceroute plaatst.
Het zou mooi zijn als daar een oplossing voor komt
[ Voor 25% gewijzigd door computerjunky op 15-11-2019 18:31 ]
Uplay: Red--Death
Deze werkzaamheden omvatten een firmware update voor alle Zyxel modems.Qunix schreef op vrijdag 15 november 2019 @ 13:52:
Ik heb net een mail ontvangen dat ze weer onderhoudswerkzaamheden gaan uitvoeren in de nacht van 20 op 21 november tussen 02:00 en 04:00.
De zelfde mail kreeg ik ook toen de ellende begon met het routeren via Duitsland... Gaan ze opnieuw een poging wagen!?
Life is what happens to you, while you're busy making other plans (John Lennon) - Ioniq 28kWh / 9,9kWP zonnepanelen (west) / Panasonic 9kW WP
Zou dat in de router zoeken en daar eventueel over bellen.rsnubje schreef op zaterdag 16 november 2019 @ 13:17:
Ik heb na de veranderingen bij T-Mobile nu regelmatig dat mijn internet heel even weg valt, en als ik dan een speedtest doe zit ik onder 100Mb/s, terwijl ik 1000 hoor te hebben. Reset ik mijn router, is het weer ok!?
Hier (ODF) nul packetloss in smokeping (UDP en ICMP).
Uplay: Red--Death
Eens, ik heb wel last van de dips dat er geen routering meer plaatsvind. Dus de verbinding is echt even weg. Daarna weer terug zonder problemen en weer volle snelheid....rsnubje schreef op zaterdag 16 november 2019 @ 16:56:
Bijzonder wel, 2-3 jaar geen issues gehad en nu ineens deze onzin. Het zou inderdaad de router kunnen zijn, maar toch toevallig.
Uplay: Red--Death
Ik vond T-Mobile al een amateuristische club. Alleen tot 25 oktober was het T-Mobile Thuis internet in mijn ogen nog het enige product wat "goed" was.Jeffrey87 schreef op zondag 17 november 2019 @ 11:37:
Mijn abonnement wordt per 16 december beëindigd en ik zal dan overstappen naar Ziggo. Het is gewoon één grote amateuristische bende geworden bij T-Mobile Thuis.
hopelijk voegen ze een manier om de T50 in bridge te zetten toe. Technisch kan het ding het maar hun eigen eisen aan de firmware houden het tegen.Krisp schreef op zaterdag 16 november 2019 @ 13:52:
[...]
Deze werkzaamheden omvatten een firmware update voor alle Zyxel modems.
Helaas natuurlijk weer dezelfde reacties van T-Mobile, bekabeld aansluiten, modems wisselen, etc. Iedereen weet ook wel dat het daar niet aan ligt.
Sinds dat routering geneuzel alleen maar gezeur lijkt het.
[ Voor 23% gewijzigd door xabre16v op 17-11-2019 16:48 ]
Streams buffert hij meestal net lang genoeg zodat je daar geen last van hebt, maar met websites is het echt irri. Vooral op fora, omdat je daar veel klikt.
Welke software kan ik het best gebruiken om dit inzichtelijk te maken? Graag met de optie voor een grafiek.
Heb al even gezocht, maar zie meestal cmd onder windows aangeraden. maar die heeft geen grafiek.
PVoutput 3.4 kWp Solar Frontier SF-170 + Omnik 4.0 TLII
Op grond waarvan en hoe heb je dat voor elkaar gekregen?Jeffrey87 schreef op zondag 17 november 2019 @ 11:37:
Mijn abonnement wordt per 16 december beëindigd en ik zal dan overstappen naar Ziggo. Het is gewoon één grote amateuristische bende geworden bij T-Mobile Thuis.
In de avond tussen 23:00 en 00:00 gebeurd het vaak dat mijn verbinding begint te "kloten", wordt uit games gegooid, Netflix zegt aju.. Behoorlijk irritant aan het worden.xabre16v schreef op zondag 17 november 2019 @ 16:45:
Net weer eens even op het T-Mobile forum gekeken maar ook daar best weer veel meldingen van de afgelopen dagen/weken over instabiele verbindingen. Lage download snelheden en kortstondig wegvallende lijnen (als in snelheid zakt weg tot 1mbit). Dit laatste ervaar ik zelf ook.
Helaas natuurlijk weer dezelfde reacties van T-Mobile, bekabeld aansluiten, modems wisselen, etc. Iedereen weet ook wel dat het daar niet aan ligt.
Sinds dat routering geneuzel alleen maar gezeur lijkt het.
PV 4915wp op oost, 2680 wp op west, 1900 wp op zuid. pvoutput - AUX 8 kW bi bloc
Hm, gewoon einde contract?Segafreak83 schreef op zondag 17 november 2019 @ 21:49:
[...]
Op grond waarvan en hoe heb je dat voor elkaar gekregen?
Het is toch maandelijks opzegbaar? Tenminste voor mij wel. Heb alleen internet btw.Segafreak83 schreef op zondag 17 november 2019 @ 21:49:
[...]
Op grond waarvan en hoe heb je dat voor elkaar gekregen?
Na een jaar wel, anders heb je gewoon een jaarcontract.SOTD schreef op dinsdag 19 november 2019 @ 18:55:
[...]
Het is toch maandelijks opzegbaar? Tenminste voor mij wel. Heb alleen internet btw.
Je hebt gelijk zie ik nu.Jeffrey87 schreef op dinsdag 19 november 2019 @ 18:58:
[...]
Na een jaar wel, anders heb je gewoon een jaarcontract.
Je kan smokeping proberen. Daarmee kan je grafieken van http/https/dns/ping responsetijd maken. Als je het in docker draait (bij sommige containers) alleen ping/dns.Nicap schreef op zondag 17 november 2019 @ 20:29:
Welke software kan ik het best gebruiken om dit inzichtelijk te maken? Graag met de optie voor een grafiek.
Heb al even gezocht, maar zie meestal cmd onder windows aangeraden. maar die heeft geen grafiek.
Daarin zie ik vanaf het moment dat de routering volgens T-Mobile hersteld is geen enkel performance probleem meer.
Als je echt vertraging merkt (en het daarna wel snel is) dan zou ik eerst naar DNS kijken. Dat is wanneer verbinden traag is (en throughput daarna goed) vaak de oorzaak. Zelfs een hoge ping (100ms) merk je tijdens browsen niet (dat is vergelijkbaar met 4G met matige dekking).
Ik gebruik wel een andere DNS server. Als iemand de IP's van de T-Mobile DNS servers post dan voeg ik die ook toe aan smokeping.
37.143.84.228ANdrode schreef op dinsdag 19 november 2019 @ 20:16:
[...]
Als iemand de IP's van de T-Mobile DNS servers post dan voeg ik die ook toe aan smokeping.
37.143.84.229
nieuwe Modem.
Monteur van Guidion en all.
een medewerker van backoffice geeft aan dat er problemen zijn met capaciteit op de omgeving van KPN?
T-Mobile is toch alleen staand zonder KPN? of vergis ik me?
[ Voor 6% gewijzigd door MrOsman op 19-11-2019 22:00 ]
In de meeste gevallen huurt T-Mobile gewoon een verbinding van KPN. T-Mobile neemt in dat geval een WBA dienst af bij KPN wholesale. KPN wholesale zet vervolgens alle data door van en naar T-Mobile's eigen netwerk. Dus een gedeelte van je verkeer loopt via KPN's netwerk, tot in het datacenter/knooppunt van T-Mobile.MrOsman schreef op dinsdag 19 november 2019 @ 21:06:
ben ook al paardagen bezig met T-Mobile na heen en weer met ze.
nieuwe Modem.
Monteur van Guidion en all.
geeft een medewerker aan van backoffice dat er problemen zijn met capaciteit op de omgeving van KPN?
T-Mobile is toch alleen staand zonder KPN? of vergis ik me?
Er zijn ook locaties in NL waar T-Mobile wel een eigen backbone heeft liggen, dan komt KPN vrijwel niet om de hoek kijken.
Echter begrijp ik niet helemaal je punt over de capaciteit bij KPN? Welke capaciteit? Bandbreedte? Te weinig monteurs? Etc
[ Voor 7% gewijzigd door krakendmodem op 19-11-2019 22:00 ]
Na dat hele aanpassing heb ik piek uren last van weg vallende of klapperende verbindingkrakendmodem schreef op dinsdag 19 november 2019 @ 21:58:
[...]
In de meeste gevallen huurt T-Mobile gewoon een verbinding van KPN. T-Mobile neemt in dat geval een WBA dienst af bij KPN wholesale. KPN wholesale zet vervolgens alle data door van en naar T-Mobile's eigen netwerk. Dus een gedeelte van je verkeer loopt via KPN's netwerk, tot in het datacenter/knooppunt van T-Mobile.
Er zijn ook locaties in NL waar T-Mobile wel een eigen backbone heeft liggen, dan komt KPN vrijwel niet om de hoek kijken.
Echter begrijp ik niet helemaal je punt over de capaciteit bij KPN? Welke capaciteit? Bandbreedte? Te weinig monteurs? Etc
Lastig om te zeggen waar het fout gaat. Kan zowel bij T-Mobile als KPN fout gaan.MrOsman schreef op dinsdag 19 november 2019 @ 22:01:
[...]
Na dat hele aanpassing heb ik piek uren last van weg vallende of klapperende verbindingdus belde ik met Tmobile. en de medewerker zij dat ik dan op dat ene omgeving zat
Maar als dit probleem speelt sinds het geknutsel aan de routering bij t-Mobile zelf, dan weet ik het zo nog niet. Kan ook wat anders zijn.
Voorbeeldje: als T-Mobile een 10Gbit lijntje bij KPN afneemt, en die pijp zit vol, dan zal T-Mobile bij KPN moeten aanbellen of ze die pijp willen uitbreiden (tegen extra €€). Kan T-Mobile wel zeggen dat het de schuld van KPN is, maar KPN wil best meer capaciteit leveren, tegen een prijs. Aangezien het overdag niet speelt, gok ik dat er gewoon capaciteitstekort is qua bandbreedte.
Home Assistant | ☀️ 2900 Wp PVOutput | 🔋 Tesla Model 3 RWD 2024
Er zijn verschillende mogelijkheden. Als T-Mobile voor jou in moet kopen bij KPN WBA dan is KPN geheel verantwoordelijk voor de achterliggende capaciteit (van alle KPN WBA klanten bij elkaar) en daar kan T-Mobile inderdaad niet veel aan veranderen.krakendmodem schreef op dinsdag 19 november 2019 @ 22:10:
[...]
Lastig om te zeggen waar het fout gaat. Kan zowel bij T-Mobile als KPN fout gaan.
Maar als dit probleem speelt sinds het geknutsel aan de routering bij t-Mobile zelf, dan weet ik het zo nog niet. Kan ook wat anders zijn.
Voorbeeldje: als T-Mobile een 10Gbit lijntje bij KPN afneemt, en die pijp zit vol, dan zal T-Mobile bij KPN moeten aanbellen of ze die pijp willen uitbreiden (tegen extra €€). Kan T-Mobile wel zeggen dat het de schuld van KPN is, maar KPN wil best meer capaciteit leveren, tegen een prijs. Aangezien het overdag niet speelt, gok ik dat er gewoon capaciteitstekort is qua bandbreedte.
Ben jij aangesloten op eigen apparatuur van T-Mobile in de PoP dan heeft T-Mobile alles zelf in de hand. De vezels op de ringverbinding tussen de Pops in jouw woonplaats huren ze zelf van KPN-Reggefiber en de backboneverbinding vanuit jouw woonplaats naar de rest van de wereld regelen ze via Eurofiber en dus ook niet van KPN.
Dus als deze heldpdeskmedewerker gelijk had dan huurt T-Mobile voor jou de diensten in bij KPN WBA en is het de verantwoordelijkheid van KPN WBA om voldoende capaciteit en bandbreedte te verzorgen.
In geen van de gevallen huurt T-Mobile een lijn met bepaalde capaciteit bij KPN.
Geen ongevraagde verzoeken via DM svp.
Hmm, dan blijft het nog wel vreemd dat na het aanpassen van die routering destijds de verbindingen ineens "trager" zijn. (Als ik zijn verhaal zo lees).Barre73 schreef op vrijdag 22 november 2019 @ 11:54:
[...]
Er zijn verschillende mogelijkheden. Als T-Mobile voor jou in moet kopen bij KPN WBA dan is KPN geheel verantwoordelijk voor de achterliggende capaciteit (van alle KPN WBA klanten bij elkaar) en daar kan T-Mobile inderdaad niet veel aan veranderen.
Ben jij aangesloten op eigen apparatuur van T-Mobile in de PoP dan heeft T-Mobile alles zelf in de hand. De vezels op de ringverbinding tussen de Pops in jouw woonplaats huren ze zelf van KPN-Reggefiber en de backboneverbinding vanuit jouw woonplaats naar de rest van de wereld regelen ze via Eurofiber en dus ook niet van KPN.
Dus als deze heldpdeskmedewerker gelijk had dan huurt T-Mobile voor jou de diensten in bij KPN WBA en is het de verantwoordelijkheid van KPN WBA om voldoende capaciteit en bandbreedte te verzorgen.
In geen van de gevallen huurt T-Mobile een lijn met bepaalde capaciteit bij KPN.
Maar ook al lopen die verbindingen via KPN, ergens zal er dan toch een doorgeefluik moeten zijn richting T-Mobile? Of wordt er bij KPN WBA helemaal niets naar T-Mobile gerouteerd?
Mijn upload blijft nog steeds relatief laag door wat packetloss (waardoor ik met één thread niet de volle snelheid haal). Maar wat betreft routing zijn alle issues voor mij verdwenen.adjego schreef op vrijdag 22 november 2019 @ 10:37:
Zijn er nog steeds mensen die issues hebben? Het lijkt erop dat mijn probleem mbt upload van T-Mobile naar Ziggo verholpen zijn.
Kan je eens een traceroute posten?NeHoX schreef op zaterdag 11 januari 2020 @ 17:31:
SInds vanmiddag zijn het aantal hops naar AMS-IX.net van 6 naar 7 gegaan en zie ik ook downtime.
Merken jullie iets?
Click:
[Afbeelding]
Mnope (nog) nergens last vanNeHoX schreef op zaterdag 11 januari 2020 @ 17:31:
SInds vanmiddag zijn het aantal hops naar AMS-IX.net van 6 naar 7 gegaan en zie ik ook downtime.
Merken jullie iets?
Click:
[Afbeelding]
1
2
3
4
5
6
7
8
9
10
| hoite@T470:~$ mtr ams-ix.net -c 10 -r Start: 2020-01-11T19:50:30+0100 HOST: T470 Loss% Snt Last Avg Best Wrst StDev 1.|-- _gateway 0.0% 10 2.5 2.1 0.9 2.5 0.5 2.|-- 192.168.1.1 0.0% 10 2.6 2.5 1.4 3.3 0.5 3.|-- 1-112-145-85.ftth.glasope 0.0% 10 5.8 5.6 4.4 6.2 0.7 4.|-- 10.10.10.205 0.0% 10 6.7 6.3 5.1 8.2 0.9 5.|-- 10.10.10.197 0.0% 10 6.4 6.3 5.0 7.5 0.6 6.|-- ve111.fw-eun.ams-ix.net 0.0% 10 7.1 7.1 6.3 7.5 0.4 7.|-- lb.ams-ix.net 0.0% 10 6.9 6.7 5.3 7.0 0.5 |
edit: (dit zouden dus 6 hops moeten zijn, ik heb een dubbele NAT, welke ik nog niet heb opgelost vanwege lui)
[ Voor 7% gewijzigd door Hoite op 11-01-2020 19:52 ]
Lekker kort.
De loss die je daar ziet: Zijn dat replies tijdens de traceroutes? Of ICMP ping loss?NeHoX schreef op zaterdag 11 januari 2020 @ 17:31:
SInds vanmiddag zijn het aantal hops naar AMS-IX.net van 6 naar 7 gegaan en zie ik ook downtime.
Ik merk wat betreft ping in smokeping niets. Ik vind het opvallend dat je een stap van 6.0 naar 7.0 hebt in de grafiek. Komt dat misschien door afronding?Merken jullie iets?
Ik zie:
1
2
3
4
5
6
7
8
| ❯ traceroute -a amsix.net traceroute to amsix.net (185.55.136.59), 64 hops max, 52 byte packets 1 [AS198949] router (192.168.1.1) 0.792 ms 0.449 ms 0.377 ms 2 [AS50266] 1-4-251-32.ftth.glasoperator.nl (32.251.4.1) 2.623 ms 3.137 ms 3.459 ms 3 [AS0] 10.10.80.149 (10.10.80.149) 8.679 ms 9.692 ms 9.756 ms 4 [AS1200] rtr-eun-01.ams-ix.net (80.249.208.1) 8.134 ms 7.697 ms 7.650 ms 5 [AS1200] ve111.fw-eun.ams-ix.net (91.200.16.11) 8.121 ms 8.071 ms 7.933 ms 6 [AS1200] redirect.ams-ix.net (185.55.136.59) 8.120 ms 7.912 ms 7.928 ms |
Een van hops is 10.10.80.145
Het leven is te kort om te testen
Ga niet uit van het haalbare, maar van het denkbare
Probleem lijkt vanzelf opgelost te zijn. Heb nu weer 6 hops vanaf m’n servertje. Niet op tijd kunnen testen.ANdrode schreef op zaterdag 11 januari 2020 @ 20:05:
[...]
De loss die je daar ziet: Zijn dat replies tijdens de traceroutes? Of ICMP ping loss?
[...]
Ik merk wat betreft ping in smokeping niets. Ik vind het opvallend dat je een stap van 6.0 naar 7.0 hebt in de grafiek. Komt dat misschien door afronding?
Ik zie:
code:
1 2 3 4 5 6 7 8 ❯ traceroute -a amsix.net traceroute to amsix.net (185.55.136.59), 64 hops max, 52 byte packets 1 [AS198949] router (192.168.1.1) 0.792 ms 0.449 ms 0.377 ms 2 [AS50266] 1-4-251-32.ftth.glasoperator.nl (32.251.4.1) 2.623 ms 3.137 ms 3.459 ms 3 [AS0] 10.10.80.149 (10.10.80.149) 8.679 ms 9.692 ms 9.756 ms 4 [AS1200] rtr-eun-01.ams-ix.net (80.249.208.1) 8.134 ms 7.697 ms 7.650 ms 5 [AS1200] ve111.fw-eun.ams-ix.net (91.200.16.11) 8.121 ms 8.071 ms 7.933 ms 6 [AS1200] redirect.ams-ix.net (185.55.136.59) 8.120 ms 7.912 ms 7.928 ms
23x330Wp NNO & 8x405Wp op Zuid = 10.830Wp
Sinds een paar dagen is mijn T-mobile mobiel weet trager als normaal. Nu heb ik een paar testen gedaan, maar ik zie wederom dat mijn routering op mobiel via Duitsland gaat en vervolgens weer terug als ik een traceroute doe naar tweakers. Op vast internet blijf ik wel gewoon in Nederland en is aanzienlijk sneller.
Hebben er meer hier last van? Ik dacht dat ze gezegd hadden dat ze die gekke dtag routering niet meer zouden doen.
Vaker gemeld: T-Mobile .. mobiel ging/gaat altijd al via DTAG, Duitsland.
Update:
ikbenjoeri in "[T-Mobile Mobiel] Ervaringen & Discussie"
[ Voor 36% gewijzigd door neeecht op 07-02-2020 18:10 ]