RDP hangt af en toe

[Red-Front]

Hallo,

Bij het bedrijf waar ik werk loggen er een aantal (30-40) mensen remote in om te werken. We hebben meerdere terminal servers (server 2012) en de gebruikers loggen in over een RDS (server 2012).

Het probleem is dat deze mensen soms een hangend beeld (duurt soms tot 30 seconden lang) hebben of een "Connection attempt: 1 of 20" melding krijgen. Daarna werkt de verbinding weer:



We hebben een zakelijke FTTO verbinding, met daarop een ZyXEL USG 310. We hebben al een nieuwe geplaatst om uit te sluiten dat het probleem niet in de router zit.

Daarnaast heb ik vanaf een andere locatie een ping gestart naar een WAN IP van de ZyXEL USG en in 1 weekend had ik 28 mislukte pings naar ons toe en vanuit ons netwerk 17 mislukte pings naar buiten toe.. maar vanuit mijn eigen FTTH verbinding thuis op mijn thuis computer had ik ook 16 mislukte pings over het hele weekend heen. Dus of die uitgaande packet loss wat zegt, ik weet het niet.

Sinds vanmorgen ook nog even opnieuw gestart en opnieuw af en toe packet loss:

Klik voor vergroting

Vanuit de provider heb ik ook regelmatig een RAS check gedaan, waarbij de total drops telkens oploopt. Vanmorgen stond deze bijvoorbeeld nog op 32000 en inmiddels op 34000+.

code:

 Virtual-Access2.1922 
 
 SSS session identifier 3581 - 
  Service-policy output: 102400K
    Class-map: clas
s-default (match-any)  
      468457945 packets, 275724898905 bytes
      30 second offered rate 4549000 bps, drop rate 0000 bps
      Match: any 
      Queueing
      queue limit 417 packets
      (queue depth/total drops/no-buffer drops) 0/343763/0
      (pkts output/bytes output) 468076298/275417565127
      shape (average) cir 104800000, bc 419200, be 419200
      target shape rate 104800000

Nu weet ik dus eigenlijk niet waar het in zit. Het gaat (zoals uit de RAS check op te maken) om een 100 Mbit verbinding. Ik heb al traffic shaping toegepast en de totale verbinding ook beperkt tot 96% van de 100 Mbit.

Ook weet ik niet echt waar ik verder moet kijken met trouble shooting... provider wilt niet tijdelijk de verbinding omzetten naar 200 Mbit of meer, ook niet tegen kosten.. moet gelijk een contract aan vast zitten van 12 maanden of een compleet nieuwe EVC (met ook een contract van 12 maanden).

Nu kan het dus in de RDS zitten of in de verbinding lijkt mij...

Iemand enig idee hoe ik hier beter / verder op kan gaan trouble shooten?

[MAX3400]

Meer bandbreedte aanvragen (al dan niet of de provider het kan), is natuurlijk geen oplossing voor packetloss.

Op laten lossen door ISP, lijkt me. Ervanuitgaande dat je code-tabelletje op je "WAN-device" gemeten is, kan er dus een issue zijn met de stabiliteit van de lijn of het device.

Andersom; als je van buiten naar binnen ping loss hebt, lijkt me dat ook een aanwijzing dat het in de lijn of WAN-device zit (aangenomen dat je ICMP aan de buitenkant toelaat).

[Starck]

Als je vanaf intern de terminal server(s) benaderd dan heb je nooit problemen met de RDP connectie?

En hoe verbinden de thuiswerkers? Zitten ze op WIFI, hebben ze eerst een VPN open? Hoe weet je dat het probleem niet bij de thuiswerker zelf zit?

[Red-Front]

Starck schreef op maandag 16 juli 2018 @ 16:46:
Als je vanaf intern de terminal server(s) benaderd dan heb je nooit problemen met de RDP connectie?

En hoe verbinden de thuiswerkers? Zitten ze op WIFI, hebben ze eerst een VPN open? Hoe weet je dat het probleem niet bij de thuiswerker zelf zit?

Vanuit binnenshuis werken we niet op de TS.. de computers werken bekabeld zonder VPN en hebben ook zakelijke glasvezel verbindingen van KPN (in de meeste gevallen).

MAX3400 schreef op maandag 16 juli 2018 @ 16:40:
Meer bandbreedte aanvragen (al dan niet of de provider het kan), is natuurlijk geen oplossing voor packetloss.

Op laten lossen door ISP, lijkt me. Ervanuitgaande dat je code-tabelletje op je "WAN-device" gemeten is, kan er dus een issue zijn met de stabiliteit van de lijn of het device.

Andersom; als je van buiten naar binnen ping loss hebt, lijkt me dat ook een aanwijzing dat het in de lijn of WAN-device zit (aangenomen dat je ICMP aan de buitenkant toelaat).

Goed om te weten dat dat sowieso niet de oplossing is. De packetloss is vanuit buitenaf met ICMP gemeten inderdaad. WAN device houd je dan nog over qua configuratie.. maar fysiek gezien hebben we al een nieuwe geplaatst. Helemaal opnieuw instellen is vrij ingewikkeld i.v.m. 30+ VPN's en bijbehorende policy's.

[MAX3400]

@Red-Front kan je emergency maintenance afkondigen op een avond/weekend? Het is zeker de moeite waard om je huidige config veilig te stellen, je device een factory-reset te geven en "puur" internet te serveren (dus geen forwards, VPN, DMZ, whatever er staat ingesteld).

Als er dan ook losses zijn, is het dus lijn (grondwerk), "binnenkomende aansluiting" of device.

[prakka]

Ik heb ook weleens dit probleem gehad en toen kon ik het oplossen om tcp autotuning uit te schakelen.

Je kan dit via een cmd commando uitvoeren.

[ElCondor]

Hmmja, maar "Ik heb dit ook wel eens gehad". Waarmee dan? Met exact dezelfde hardware en Internet abbo?
Dat is net zoiets als, ohw, je hebt ergens pijn? Ik heb nog medicijnen voor mijn nieren. Die gaan je op zeker helpen...

[Verwijderd]

prakka schreef op maandag 16 juli 2018 @ 16:55:
Ik heb ook weleens dit probleem gehad en toen kon ik het oplossen om tcp autotuning uit te schakelen.

Je kan dit via een cmd commando uitvoeren.

Dat kan alleen helpen als je een kut router hebt of een slechte firewall. Niet uitzetten.

[tolleburker]

Heb momenteel bij een klant het zelfde probleem gehad , bleek dat het glasmodem te warm werd,

100-100 glas met vigor 2860
1% packet loss