VPN Traag instabiel bij avond gebruik en in de weekends(UPC)

[Ludo_luud]

VPN Traag instabiel bij avond gebruik (UPC)

Ik maak voicetracks voor een radioprogramma en gebruik daarvoor een thuis licentie van het Broadcast Partners software programma PCRadio 6 (Radio Automatiseringsoftware). Hiervoor gebruik ik een VPN verbinding van privé naar de productie pc in de remote studio. Dit zorgt nogal voor de nodige problemen.

Werk ik 's morgens of 's middags dan loopt het redelijk tot goed;

Werk ik 's avonds (vanaf 20uur) en /of in het weekend dat is de verbinding heel erg slecht.

Ik heb stellig de indruk dat hier het probleem ligt bij de UPC verbinding. Hoezo? Als ik een lijntje glasvezel van de buurman leen en deze verbinding gebruik werk de hele VPN verbinding als een tierlelier.

Ik gebruik UPC Power 120down en 6 mbit Up
De Radio Studio werkt met Glasvezel 60 down/ 60 up
Ik gebruik een Technicolor TC7200 modem in router mode


Wie kan mij hierin adviseren; wie kent ditzelfde probleem??
Ik zie met belangstelling jullie reactie tegemoet. groet Luud

[Gravit0n]

Heb je voor de grap UPC al eens gebeld?

[dion_b]

Hoe zit het met andere toepassingen op momenten dat je problemen hebt met de VPN?

[Verwijderd]

Het is gewoon "druk" op de kabel, in de avonduren. Dit is "normaal"..... Uiteraard, niet voor jou.

[Jolke]

Met laatste reactie eens; kabel deel je met de wijk. 's Avonds zijn er dan meer mensen online en dan heb je effectief minder bandbreedte ter beschikking. Als je onafhankelijk wilt zijn, moet je over naar DSL of glasvezel.

[lier]

Jolke schreef op vrijdag 03 januari 2014 @ 09:39:
Als je onafhankelijk wilt zijn, moet je over naar DSL of glasvezel.

Als je onafhankelijk wil zijn dan moet je voor een dienst kiezen zonder overboeking. Dat is de enige manier om gegarandeerd geen last te hebben van anderen.

[dion_b]

Jolke schreef op vrijdag 03 januari 2014 @ 09:39:
Met laatste reactie eens; kabel deel je met de wijk. 's Avonds zijn er dan meer mensen online en dan heb je effectief minder bandbreedte ter beschikking. Als je onafhankelijk wilt zijn, moet je over naar DSL of glasvezel.

Dit is waar, maar totdat TS aangeeft hoe andere diensten werken weten we niet of dit van toepassing is hier.

Sowieso, VPN instabiliteit gaat doorgaans meer over latency dan bandbreedte...

[Jolke]

Met onafhankelijk bedoelde ik dus idd meer bandbreedte, waarbij ook latency verbeterd m.i. ... maar als TS professioneel bezig is, dan vraag ik me sowieso af wat je nog bij UPC doet - dan zou ook je ISP professioneel verzorgd moeten worden.

[Ludo_luud]

Een algehele reactie mijnerzijds. De Pc funtioneert normaal tijdens het VPN probleem. Alleen dus het programma dat werkt met VPN heeft en geeft problemen. Natuurlijk heb ik hier ruimschoots contact over gehad met UPC. het verhaal over bandbreedte delen begrijp ik en heb dit uiteraard voorgelegd aan UPC. Antwoord: dat delen was vroeger maar is met de huidige tactieken verleden tijd. De speedtest geeft de juiste snelheid. Ik heb aan UPC ping en tracert verstrekt. Ik wacht nog op de reactie van mijn laatste email met tracert gegevens. Eerlijk gezegd verwacht ik er niet veel van, temeer om dat de medewerker van UPC al liet doorschemeren dat ze niets meer voor me kunnen doen. Wat ik mezelf niet kan voorstellen dat andere Voice trackers ook allemaal hetzelfde probleem bij UPC hebben. Hebben die anderen dan allemaal glasvezel ?? PC radio met voicetracking at home bestaat denk ik al langer dan de uitrolling van glasvezel. Wordt iemand er nu iets wijzer van? alle adviezen blijven uiteraard welkom gr Luud

[Sander]

Het effect van overboeking is per wijk / gemeente verschillend. Stel: Jouw hele straat met 100 huizen heeft UPC Fiberpower 120mb, maar in de wijkcentrale ligt slechts een fiber van 1gbit. Dit betekend dat je overdag prima verbinding kunt hebben maar 's avonds niet. En daarom kunnen anderen op plekken met weinig UPC gebruikers hier geen last van hebben.

Bij mij thuis met Ziggo idem, overdag gaat het prima, maar na 5u 's middags heb ik regelmatig spikes in ping en connection drops. En daarbij hebben ze 's avonds ook problemen met overboeking van hun extern ingekochte traffic richting US. Helaas zijn gedetailleerde analyses van het probleem, samen met vergelijkbare waarden vanaf een XS4ALL lijn 2 deuren verder geen reden om er iets aan te doen. Dat is het nadeel van een consumentenlijntje, mocht je dat niet willen dan zou ik je adviseren over te stappen naar de zakelijke varianten van UPC waarbij je gegarandeerde overboeking krijgt.

[ Voor 4% gewijzigd door Sander op 06-01-2014 11:50 ]

[dion_b]

Ludo_luud schreef op maandag 06 januari 2014 @ 11:35:
Een algehele reactie mijnerzijds. De Pc funtioneert normaal tijdens het VPN probleem. Alleen dus het programma dat werkt met VPN heeft en geeft problemen.

Hmm. Ook goede, lage pings?

Natuurlijk heb ik hier ruimschoots contact over gehad met UPC. het verhaal over bandbreedte delen begrijp ik en heb dit uiteraard voorgelegd aan UPC. Antwoord: dat delen was vroeger maar is met de huidige tactieken verleden tijd.

Helaas is jou een lading onzin verkocht. Kabel is per definitie een gedeelde medium, 3/4 van het DOCSIS-protocol gaat over dat in goede banen leiden. Als er genoeg capaciteit over is gaat het goed, maar als het volledig vol loopt, met name de upload, stort alles in.

Dat gezegd, als dat aan de orde was geweest waren je speedtestresultaten ook waardeloos geweest en had je niet eens fatsoenlijk een webpagina kunnen openen. Dus ook al klopt het verhaal van de medewerker nadrukkelijk niet, hier heb je geen last van.

De speedtest geeft de juiste snelheid. Ik heb aan UPC ping en tracert verstrekt. Ik wacht nog op de reactie van mijn laatste email met tracert gegevens.

Hoe ziet die tracert eruit? Post eens hier, misschien dat dat meer verheldert...

Eerlijk gezegd verwacht ik er niet veel van, temeer om dat de medewerker van UPC al liet doorschemeren dat ze niets meer voor me kunnen doen.

Misschien wel, misschien niet. Eerst moeten iemand achterhalen exact waar het fout gaat.

Wat ik mezelf niet kan voorstellen dat andere Voice trackers ook allemaal hetzelfde probleem bij UPC hebben. Hebben die anderen dan allemaal glasvezel ?? PC radio met voicetracking at home bestaat denk ik al langer dan de uitrolling van glasvezel. Wordt iemand er nu iets wijzer van? alle adviezen blijven uiteraard welkom gr Luud

Voice tracking is nou niet bepaald iets wat veel mensen doen, zeker niet mbv specifiek deze VPN. Maar omgekeerd: ongeveer 25% van consumenteninternetverbindingen in NL loopt via UPC. Goede kans dus dat meerdere mensen die je binnen de voice tracking community kent ook UPC hebben. Je zou daar navraag kunnen doen.

Mijn vermoedens tot nu toe iig:

1) jouw verbinding naar netwerk van UPC en 'het internet' is prima, ook op drukke momenten.
2) de tijden van de problemen die je ervaart wijzen toch sterk op drukte.
3) probleem zit niet bij (internteverbinding van) remote studio want op zelfde moment gaat het wel goed vanaf een andere verbinding.
3) die drukte zit dus vrijwel zeker ergens anders in de keten tussen jouw PC en de server in de remote studio, een zwakke schakel waar jouw verkeer wel overheen gaat maar niet het verkeer van bij de buurman.

Exact waar dat is, wiens verantwoordelijkheid het is om het op te lossen en welke eventuele workarounds je in de tussentijd kunt toepassen is nog niet duidelijk, misschien dat wij iets uit die traceroutes kunnen halen. Heb je ook een traceroute vanaf de glasvezelverbinding waar het wel goed gaat? Dan zou het verschil snel genoeg naar boven moeten komen

[Ludo_luud]

Heren wat een aandacht ! Bedankt.
Ja ik ben een leek en die kunnen ze van alles wijs maken.
Gevraagd naar een Tracert !
Die heb ik reeds een aantal gemaakt maar ik weet eerlijk gezegd (schaamrood) niet hoe ik die hier aan jullie kan laten zien. Ik kan hier geen plaatje plakken en ook geen attachment sturen....
Het gaat via 30 hops en bij poging 12 krijg een time out.
Even ter info; ik werk via UPC kabel en de remote studio werkt met glasvezel
gr Luud

[Mijzelf]

Je hebt tracert uitgevoerd in een Windows command prompt? Via het icoontje linksboven kun je Bewerken->Markeren, met de muis selecteren, en dan Bewerken->Kopiëren,

[Ludo_luud]

Microsoft Windows [versie 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Alle rechten voorbeho

C:\Users\Mariet_SSD>tracert ftp.omroepcentraal.nl

Traceren van de route naar ftp.omroepcentraal.nl [5.199.154.34]
via maximaal 30 hops:

1 <1 ms <1 ms <1 ms 192.168.0.1
2 4 ms 8 ms 5 ms 10.15.52.129
3 6 ms 7 ms 5 ms 212.142.61.1
4 11 ms 9 ms 9 ms 84.116.244.13
5 10 ms 10 ms 9 ms nl-ams04a-ri2-xe-0-0-0.aorta.ne
]
6 22 ms 21 ms 22 ms te7-1-10g.ar2.ams1.gblx.net [64
7 26 ms 25 ms 30 ms edutel-b-v.ge-3-2-0.ar9.ams2.gb
7.6]
8 18 ms 23 ms 19 ms te1-3.bb1-asd-nkh.edutel.nl [88
9 19 ms 22 ms 19 ms 88.159.2.118
10 19 ms 18 ms 19 ms 88.159.2.125
11 18 ms 17 ms 18 ms 88.159.2.126
12 * * * Time-out bij opdracht.
13 * * * Time-out bij opdracht.
14 * * * Time-out bij opdracht.
15 * * * Time-out bij opdracht.
16 * * * Time-out bij opdracht.
17 * * * Time-out bij opdracht.
18 * * * Time-out bij opdracht.
19 * * * Time-out bij opdracht.
20 * * * Time-out bij opdracht.
21 * * * Time-out bij opdracht.
22 * * * Time-out bij opdracht.
23 * * * Time-out bij opdracht.
24 * * * Time-out bij opdracht.
25 * * * Time-out bij opdracht.
26 *

[dion_b]

Ik krijg hier exact zelfde tracert. Hoeft nog niets te zeggen als 88.159.2.126 de voorlaatste hop is en de VPN-server niet op pings reageert. Ben benieuwd naar wat je vanaf andere verbinding constateert.

[Ludo_luud]

zoals door jou gevraagd bij deze een tracert uiteraard vanaf dezelfde pc naar dezelfde locatie weliswaar met glasvezel:
Microsoft Windows [versie 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Alle rechten voorbehouden.

C:\Users\Mariet_SSD>tracert office.omroep.nl
Kan naam van doelsysteem office.omroep.nl niet omzetten.

C:\Users\Mariet_SSD>tracert office.omroepcentraal.nl

Traceren van de route naar office.omroepcentraal.nl [10.0.0.5]
via maximaal 30 hops:

1 7 ms 5 ms 6 ms 5.199.144.1
2 5 ms 5 ms 5 ms 88.159.2.125
3 5 ms 5 ms 5 ms 88.159.2.118
4 * * * Time-out bij opdracht.
5 * * * Time-out bij opdracht.
6 * * * Time-out bij opdracht.
7 * * * Time-out bij opdracht.
8 * * * Time-out bij opdracht.
9 * * * Time-out bij opdracht.
10 * * * Time-out bij opdracht.
11 * * * Time-out bij opdracht.
12 * * * Time-out bij opdracht.
13 * * * Time-out bij opdracht.
14 * * * Time-out bij opdracht.
15 * * * Time-out bij opdracht.
16 * * * Time-out bij opdracht.
17 * * * Time-out bij opdracht.
18 * * * Time-out bij opdracht.
19 * * * Time-out bij opdracht.
20 * * * Time-out bij opdracht.
21 * * * Time-out bij opdracht.
22 * * * Time-out bij opdracht.
23 * * * Time-out bij opdracht.
24 * * * Time-out bij opdracht.
25 * * * Time-out bij opdracht.
26 * * * Time-out bij opdracht.
27 * * * Time-out bij opdracht.
28 * * * Time-out bij opdracht.
29 * * * Time-out bij opdracht.
30 * * * Time-out bij opdracht.

De trace is voltooid.

ik ben benieuwd en hoor graag van je; (office.opmroepcentraal.nl blijkt idem te zijn als ftp.omroepcentraal.nl) tarcert naar ftp.omroepcentraal.nl geeft al bij de 2e hop een timeout vandaar de keuze voor office.omroepcentraal.nl. Gr Luud

[dion_b]

Dit is een rare trace, kun je wat meer toelichting geven? Om te beginnen zit hop 1 in dezelfde /18 als het adres wat je van achter je eigen internet verbinding probeert te bereiken, ten tweede probeert je PC hier een privaat IP (dat met 10 begint) te bereiken...

Lijkt bijna alsof je dit in dezelfde studio aan het doen bent waar de VPN server staat. Dat is natuurlijk appels en peren vergelijken

In ieder geval weten we dat de laatste hop niet reageert op pings, dus je eerste traceroute vanuit huis lijkt gewoon volledig succesvol. In ieder geval is er geen vorm van vertraging te zien die de slechte VPN-performance zou kunnen verklaren.

Maar...

Als je andere locatie met glasvezel daadwerkelijk in de studio zit (of in ieder geval op hetzelfde netwerk), dan is de internetverbinding van de studio juist niet uitgesloten en zou dat alsnog de plek kunnen zijn waar het fout gaat

Heb je evt een derde adres waar je naartoe kunt waar geen UPC-verbinding is? Liefst een DSL-lijn oid, dat zou een heldere vergelijking zijn.

[Will_M]

Zo raar is dat routering probleem toch niet.


Die twee laatste adressen welke reageren (125 -126) zijn waarschijnlijk onderdeel van een loadbalancer?

Tracing route to 5.199.154.34 over a maximum of 30 hops

1 3 ms 3 ms 1 ms
2 21 ms 20 ms 20 ms
3 22 ms 21 ms 22 ms
4 24 ms 22 ms 23 ms bb1-asd-nkf.edutel.nl [195.69.145.65]
5 27 ms 22 ms 22 ms 88.159.2.118
6 25 ms 24 ms 24 ms 88.159.2.125
7 23 ms 25 ms 23 ms 88.159.2.126
8 * * * Request timed out.
9 * *

[Jolke]

De responstijden zijn iig prima en in orde.
Zie je een verschil in responsetijd als je op rustige/drukke momenten pingt? Dus overdag vs. 's avonds/weekend.

[dion_b]

wimmel_1 schreef op donderdag 09 januari 2014 @ 02:18:
Zo raar is dat routering probleem toch niet.

Een route van drie hops van externe host naar server? Noem ik raar...

Die twee laatste adressen welke reageren (125 -126) zijn waarschijnlijk onderdeel van een loadbalancer?

Yup, maar dat is ook niet wat er raar aan is.

Tracing route to 5.199.154.34 over a maximum of 30 hops

1 3 ms 3 ms 1 ms
2 21 ms 20 ms 20 ms
3 22 ms 21 ms 22 ms
4 24 ms 22 ms 23 ms bb1-asd-nkf.edutel.nl [195.69.145.65]
5 27 ms 22 ms 22 ms 88.159.2.118
6 25 ms 24 ms 24 ms 88.159.2.125
7 23 ms 25 ms 23 ms 88.159.2.126
8 * * * Request timed out.
9 * *

Kijk, dit is meer wat ik verwacht zou hebben, vier hops meer dan wat TS toont.

[Ludo_luud]

Geweldig die van jullie , maar zoals ik al eerder aangaf: ik ben een leek

Het wordt voor mij nu allemaal te moeilijk ivm mijn eigen onkunde. UPC heeft vandaag weer contact met me gehad; ik heb hem ook de link gestuurd naar deze topic. Hij wil nu dat een FTP upload test doe op het moment dat ik weer een traagheid probleem heb. Ga ik in ieder geval doen. Hopen dat deze heer daar wat aanwijzingen uit kan halen. gr Luud

[Will_M]

Misschien dat je je DNS eens kunt checken. Je eigen Ping via 't DNS adres levert een significant ander resultaat op dan 't pingen op een IP via reguliere DNS server.

Die trace via fiber van de buren.... leuk, maar da's een heel andere verbinding.

Dit is "JOUW" route naar de server

Microsoft Windows [versie 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Alle rechten voorbeho

C:\Users\Mariet_SSD>tracert ftp.omroepcentraal.nl

Traceren van de route naar ftp.omroepcentraal.nl [5.199.154.34]
via maximaal 30 hops:

1 <1 ms <1 ms <1 ms 192.168.0.1
2 4 ms 8 ms 5 ms 10.15.52.129
3 6 ms 7 ms 5 ms 212.142.61.1
4 11 ms 9 ms 9 ms 84.116.244.13
5 10 ms 10 ms 9 ms nl-ams04a-ri2-xe-0-0-0.aorta.ne
]
6 22 ms 21 ms 22 ms te7-1-10g.ar2.ams1.gblx.net [64
7 26 ms 25 ms 30 ms edutel-b-v.ge-3-2-0.ar9.ams2.gb
7.6]
8 18 ms 23 ms 19 ms te1-3.bb1-asd-nkh.edutel.nl [88
9 19 ms 22 ms 19 ms 88.159.2.118
10 19 ms 18 ms 19 ms 88.159.2.125
11 18 ms 17 ms 18 ms 88.159.2.126
12 * * * Time-out bij opdracht.
13 * * * Time-out bij opdracht.


De route terug loopt fout ná het ams gedeelte.

[ Voor 63% gewijzigd door Will_M op 10-01-2014 23:41 ]