[KPN] Lijnmeting goed, toch slechte verbinding. Wat te doen?

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0 Henk 'm!

  • StephanVierkant
  • Registratie: Mei 2003
  • Laatst online: 17:16
TL;DR: Hoe is een verschil tussen lijnmeting/bandbreedte modem en de 'echte' snelheid te verklaren? Intern netwerk is geen probleem. En hoe krijg ik eindelijk een stabiele verbinding?

Sinds september 2014 ervaren wij problemen met onze VDSL-verbinding (ITU-T G.993.2, zakelijk). De verbinding is een stuk trager dan beloofd (maximaal 18 Mbit i.p.v. 50) en valt bovendien vaak weg. We hebben sindsdien veel monteurs op bezoek gehad die lijnmetingen hebben uitgevoerd en/of de router hebben vervangen. Ook zijn al onze kabels in de meterkast vervangen. Niets heeft geholpen.

Na zoveel maanden problemen hebben we alles al onderzoek. We hebben tientallen apparaten (Windows, iOS, OSXl, Android, Ubuntu, Synology) geprobeerd, zowel bedraad als draadloos. Geen enkel apparaat haalt boven de 20 Mbit.

CRC-fouten, V8 versus TG789vn
We hebben eerst een tijdje de V8 gehad, die meerdere keren per dag helemaal uitviel. Lampje van internet brandt dan rood en de automatische reboot kan wel een kwartier duren. Nadat we 5 keer een nieuwe V8 hebben gekregen, heb ik een monteur die toevallig bij mij in de gang (bedrijfsverzamelgebouw) was gevraagd. Hij vroeg naar de CRC-fouten in de router. Die mochten maar enkele per uur zijn, maar na een verse reboot stond hij al op enkele miljoenen. De lijn is toen door hem 'omgecat' (whatever that may be) in de centrale. Daarmee was het probleem echter nog niet verholpen.

Inmiddels hebben we een ouder type router (Thomson TG789vn), omdat de V8 een bug zou bevatten bij teveel 'ruis op de lijn'. De Thomson negeert die fouten gewoon, terwijl de V8 kan crashen. De Thomson crasht inderdaad niet, maar toch valt de verbinding vaak weg. Het streamen van audio of video is niet te doen: regelmatig stopt de stream er helemaal mee.

Lijnmeting prima, speedtest onbetrouwbaar
Maandag was er opnieuw een 'monteur', nadat ik KPN vroeg nu eens eindelijk het probleem echt te onderzoeken. Daarop werd beloofd een monteur te sturen die in de centrale zou kijken en ook de kabels buitenshuis fysiek zou controleren. Helaas kwam er iemand die alleen een lijnmeting kon doen. Hij was totaal niet op de hoogte van de hele geschiedenis. De meetapparatuur gaf 53 Mbit aan en daarom was er volgens hem geen probleem. Ook de router 'traint in' op zo'n 53 Mbit. Dit komt dus prima overeen met de lijnmeting. Ook de andere routers trainden op een hogere snelheid in dan onze 'echte' snelheid.

Dat de speedtest (ook bedraad) slechts 17 Mbit aangaf, was volgens volgens de derdelijns (hij wist het zelf niet, bij elke moeilijke vraag moest hij weer bellen) omdat 'speedtest.net erg onbetrouwbaar zijn'. Daarop heb ik de KPN speedtest gebruikt, maar die kwam zelfs lager uit. Daarop was de monteur ook stil en hij zou de derdelijns monteur inschakelen. Gistermiddag heb ik navraag bij KPN gedaan, maar nu blijkt dat de monteur slechts heeft gerapporteerd dat de lijn prima is.

De uitval (gemiddeld 1-5 minuten geen internet, paar keer per dag) is niet frequent genoeg om opgemerkt te worden door de monteur, die hier slechts 15 minuten is en in de centrale ook maar een paar minuten meet.

Infinite Loop
Sinds september zijn we zo'n 10 keer door het volgende proces gegaan:
  1. We bellen KPN dat onze verbinding traag en instabiel is.
  2. KPN stuurt monteur die de router vervangt en/of een lijnmeting doet. Hij gaat weer weg met het verhaal dat er niets mis is met de lijn en/of dat de nieuwe router de problemen oplost.
  3. KPN belt terug met de vraag of het probleem nu opgelost is. De monteur heeft immers gerapporteerd dat het probleem is opgelost of niet is geconstateerd. Ik geef aan dat het probleem niet is opgelost. Daarop beloven ze een monteur te sturen die niet alleen een herhaling van zetten doet. Dat gebeurt niet.
En nu?
Het probleem is duidelijk: de snelheid van de lijnmeting en van de bandbreedte waarop de router intraint, staat in geen verhouding tot de echte snelheid die wij ervaren. Alle voor de hand liggende problemen (firewall, bekabeling vanaf IS/RA-punt, WLAN, kapotte router, etc. etc.) zijn inmiddels wel uitgesloten. De oorzaak is echter een groot mysterie.

Mijn vraag is nu: wat kan de oorzaak van de problemen zijn, en hoe krijg ik KPN zo ver dit te onderzoeken en op te lossen?

Acties:
  • 0 Henk 'm!

  • Foamy
  • Registratie: November 2006
  • Laatst online: 17-06 17:21

Foamy

Fulltime prutser

Kun je zelf ook zaken als SNR waardes, etc. uitlezen in het modem? Zo ja; wil je die eens posten?

blub


Acties:
  • 0 Henk 'm!

  • StephanVierkant
  • Registratie: Mei 2003
  • Laatst online: 17:16
Foamy schreef op donderdag 25 juni 2015 @ 09:59:
Kun je zelf ook zaken als SNR waardes, etc. uitlezen in het modem? Zo ja; wil je die eens posten?
Nee, helaas. Die TG789vn is zo gesloten als een oester.

Acties:
  • 0 Henk 'm!

  • Foamy
  • Registratie: November 2006
  • Laatst online: 17-06 17:21

Foamy

Fulltime prutser

Hm ,lastig. Je zou (als je zelf wilt kunnen kijken) eens kunnen zien of je met een eigen modem de verbinding kunt opzetten. Je kunt dan in ieder geval zelf je lijnwaardes uitlezen. Op die manier kun je wat makkelijker conclusies trekken.
Een andere optie zou zijn om een wat langer durende lijnmeting aan te vragen. Als ze de aansluiting voor een paar daagjes monitoren dan zou op die manier ook vanuit KPN te zien moeten zijn dat deze af en toe eruit klapt. Wellicht dat ze dan beter kunnen achterhalen wat er speelt.

blub


Acties:
  • 0 Henk 'm!

  • sPENKMAN
  • Registratie: April 2002
  • Laatst online: 26-06 10:08
Apart, wij hebben hier een vergelijkbaar probleem gehad afgelopen maand nadat onze onderburen ook een xDSL verbinding hadden aangevraagd.
Na een paar bezoeken van KPN monteurs bleek het probleem hem in een foutieve aansluiting te zitten waardoor zowel onze modem als die van onze onderburen op hetzelfde aderpaar/draad probeerde in te trainen wat uiteraard voor problemen zorgde (instabiliteit en helft van de daadwerkelijk haalbare snelheid). In deze situatie was de lijnmeting ook prima maar 'zagen' ze op de lijn wel verschillende modems intrainen wat hun op het juiste spoor heeft gezet. Het zou me verbazen als hetzelfde bij jullie van toepassing is maar gezien het bedrijfsverzamelgebouw is die kans natuurlijk wel prima aanwezig.

Eve char: Warock <TEST>


Acties:
  • 0 Henk 'm!

  • StephanVierkant
  • Registratie: Mei 2003
  • Laatst online: 17:16
sPENKMAN schreef op donderdag 25 juni 2015 @ 10:25:
Apart, wij hebben hier een vergelijkbaar probleem gehad afgelopen maand nadat onze onderburen ook een xDSL verbinding hadden aangevraagd.
Na een paar bezoeken van KPN monteurs bleek het probleem hem in een foutieve aansluiting te zitten waardoor zowel onze modem als die van onze onderburen op hetzelfde aderpaar/draad probeerde in te trainen wat uiteraard voor problemen zorgde (instabiliteit en helft van de daadwerkelijk haalbare snelheid). In deze situatie was de lijnmeting ook prima maar 'zagen' ze op de lijn wel verschillende modems intrainen wat hun op het juiste spoor heeft gezet. Het zou me verbazen als hetzelfde bij jullie van toepassing is maar gezien het bedrijfsverzamelgebouw is die kans natuurlijk wel prima aanwezig.
Dit lijkt me inderdaad niet ondenkbaar. We kunnen geen Ziggo-aansluiting krijgen, omdat we geen eigen Ziggo-kabel hebben. We hebben wel een coax-kabel die uit de muur komt, maar dat is een aftakking van een van onze buren. Het is hier een zootje met de bekabeling en er zijn inderdaad ook andere mensen in het pand met problemen.

Acties:
  • 0 Henk 'm!

  • HammerNL
  • Registratie: Maart 2007
  • Niet online
StephanVierkant schreef op donderdag 25 juni 2015 @ 10:08:
[...]

Nee, helaas. Die TG789vn is zo gesloten als een oester.
Breedbandverbinding --> DSL verbinding --> rechterbovenhoek -->Details

Je gaf aan de CRC fouten wel te kunnen uitlezen, die staat op dezelfde overzichtspagina als bijv de SN waarde.

Acties:
  • 0 Henk 'm!

  • StephanVierkant
  • Registratie: Mei 2003
  • Laatst online: 17:16
HammerNL schreef op donderdag 25 juni 2015 @ 10:39:
[...]


Breedbandverbinding --> DSL verbinding --> rechterbovenhoek -->Details

Je gaf aan de CRC fouten wel te kunnen uitlezen, die staat op dezelfde overzichtspagina als bijv de SN waarde.
Excuus, je hebt gelijk. De CRC-fouten had ik toen gezien in de V8, ik dacht dat het in de Thomson was verstopt.
Home > Breedbandverbinding > DSL-verbinding

Acties:
  • 0 Henk 'm!

  • timmie1
  • Registratie: Juni 2008
  • Laatst online: 10:31
Hoe is je ping, in idle en tijdens het downloaden van een testbestand op volle snelheid?
Voer ook eens een traceroute uit, terwijl er geen verkeer op de lijn is en met het downloaden.

Ben je tijdens uitval ook eens zelf in de router gaan kijken? Bijv. in de logs?

Ik lees nergens dat een monteur ook werkelijk in de centrale is gaan kijken, dat is wel nodig om uit te sluiten.
Een rood internetlampje op een experiabox is geen verbroken DSL-verbinding(er is nog steeds contact tussen modem en centrale) maar een verbroken PPPoA/PPPoE-sessie. Simpel gezegd, hij kan niet inloggen bij het netwerk. Als het goed is, zou je het in dat geval ook terug kunnen vinden in de logs van het modem.

Spiegeltje, spiegeltje aan de wand, wie heeft de mooiste telefoon van het land?


Acties:
  • 0 Henk 'm!

  • StephanVierkant
  • Registratie: Mei 2003
  • Laatst online: 17:16
Nu internet eraf gooien levert ruzie met collega's op, maar zal dat eens proberen als de rest naar huis is.

Idle (althans, paar mensen zitten beetje te surfen):
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
PING nu.nl (62.69.166.254) 56(84) bytes of data.
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=1 ttl=248 time=25.2 ms
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=2 ttl=248 time=25.3 ms
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=3 ttl=248 time=31.9 ms
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=4 ttl=248 time=73.0 ms
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=5 ttl=248 time=24.2 ms
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=6 ttl=248 time=42.6 ms
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=7 ttl=248 time=29.0 ms
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=8 ttl=248 time=29.4 ms
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=9 ttl=248 time=35.2 ms
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=10 ttl=248 time=27.8 ms
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=11 ttl=248 time=82.1 ms
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=12 ttl=248 time=54.6 ms
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=13 ttl=248 time=69.7 ms
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=14 ttl=248 time=97.8 ms
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=15 ttl=248 time=29.2 ms
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=16 ttl=248 time=25.4 ms
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=17 ttl=248 time=29.2 ms
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=18 ttl=248 time=43.2 ms
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=19 ttl=248 time=410 ms
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=20 ttl=248 time=43.3 ms
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=21 ttl=248 time=68.3 ms
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=22 ttl=248 time=30.7 ms
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=23 ttl=248 time=25.8 ms
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=24 ttl=248 time=28.5 ms
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=25 ttl=248 time=24.9 ms
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=26 ttl=248 time=64.7 ms
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=27 ttl=248 time=51.0 ms
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=28 ttl=248 time=26.9 ms
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=29 ttl=248 time=25.6 ms
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=30 ttl=248 time=159 ms
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=31 ttl=248 time=25.3 ms


Tijdens downloaden:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
PING nu.nl (62.69.166.254) 56(84) bytes of data.
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=1 ttl=248 time=25.7 ms                                                                                                                                                                                   
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=2 ttl=248 time=77.2 ms                                                                                                                                                                                   
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=3 ttl=248 time=228 ms                                                                                                                                                                                    
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=4 ttl=248 time=140 ms                                                                                                                                                                                    
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=5 ttl=248 time=278 ms                                                                                                                                                                                    
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=6 ttl=248 time=247 ms                                                                                                                                                                                    
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=7 ttl=248 time=494 ms                                                                                                                                                                                    
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=8 ttl=248 time=708 ms                                                                                                                                                                                    
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=9 ttl=248 time=221 ms                                                                                                                                                                                    
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=10 ttl=248 time=149 ms                                                                                                                                                                                   
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=11 ttl=248 time=942 ms                                                                                                                                                                                   
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=12 ttl=248 time=400 ms                                                                                                                                                                                   
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=13 ttl=248 time=151 ms                                                                                                                                                                                   
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=14 ttl=248 time=34.0 ms                                                                                                                                                                                  
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=15 ttl=248 time=175 ms                                                                                                                                                                                   
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=16 ttl=248 time=88.6 ms                                                                                                                                                                                  
64 bytes from 62-69-166-254.ptr.as24646.net (62.69.166.254): icmp_seq=17 ttl=248 time=194 ms


Zodra het lampje van de router overigens rood ging branden, was hij ook onbereikbaar. Logs inzien was er dus niet bij. Na reboot waren de logs gewist. Ik heb dus nooit kunnen ontdekken wat er precies mis ging. Met de router die ik nu heb, heb ik geen crashes meer gehad.

Hier een screenshot van de logs:
Home > Toolbox > Inbraakdetectie

En hier een screenshot van de (niet uit te schakelen) firewall:
Home > Toolbox > Inbraakdetectie

Acties:
  • 0 Henk 'm!

  • StephanVierkant
  • Registratie: Mei 2003
  • Laatst online: 17:16
Vanochtend weer minuutje downtime gehad en daarna minutenlang een heel trage/onbruikbare verbinding. KPN heeft nu eindelijk door dat ze een lijnmeting moeten doen over langere tijd. Na 9 maanden klagen hebben ze eindelijk door dat af en toe 10 minuten meten niet genoeg is.

Ook zijn we erachter gekomen dat we een ander abonnement hebben gekregen dan gevraagd. Dat verklaart dus een deel van het probleem (de snelheid), maar nog niet alles.

Acties:
  • 0 Henk 'm!

  • ThinClientQ
  • Registratie: April 2010
  • Laatst online: 20:14
Ik ervaar ook vaak dit soort problemen, KPN, Ziggo, et cetera.
Ik plaats dan een laptop op locatie en laat deze de hele dag pingen naar Google of een andere stabiele website.
Bedraad, rechtstreeks op de router.

Deze log stuur ik dan door naar de provider met duidelijke informatie, werkt erg goed.

Acties:
  • 0 Henk 'm!

  • Toettoetdaan
  • Registratie: Juni 2006
  • Laatst online: 16-05 09:20
Wij hebben hier een vergelijkbare situatie gehad, bij ons bleek het probleem een `lekke` kabel.

Als het regende kon de verbinding gewoon wegvallen, maar over het algemeen deed de modem zijn best om iets van de verbinding over te laten dus met een beetje nat weer hadden we gewoon een hele slechte verbinding die af en toe weg viel.

Uiteraard kwamen de eerste drie monteurs op mooie droge dagen en wij hadden zelf de relatie tussen het weer en de verbinding nog niet gelegd, pas toen de vierde monteur in de regen kwam meten, was de verbinding minder dan normaal en hij heeft vervolgens een kabel verwisseld. (Ook bedrijfspand dus kabels zat)
Was trouwens een toffe monteur, had nog even onze snelheid omhoog gegooid. Gewoon omdat het kon. (100down/20up)

Het meest hilarische van het verhaal waren voorhal de helpdesk medewerkers die stuk voor stuk als eerst je router resetten op afstand:
Medewerker: Ik los dat zo op!
Onze telefoon: *piep* *piep* *piep*
Bij de vierde toch maar vriendelijk gevraagd niet de modem te resetten waar de vaste telefoon op aangesloten is :+
Pagina: 1