4
Thin Client geht mit Verzögerung ins Netz
Hallo zusammen,
wir benutzen in der Firma im Verkauf Igen Thin Clients der neusten Generation. Konfiguriert haben wir die Igel über die Management Suite von Igel.
Auf den Igel wird eine Terminalsession und halt der Internetzugang per Firefox genutzt (Linux Igel).
Nun ist es so, wir haben 3 Standorte Hauptstandort ist Standort A. Standort B und C sind mit einer S DSL Leitung mit Standort A vernetzt (VPN). B & C gehen also immer über Standort A ins Internet.
Seit 2 Tagen haben wir nun das Problem, wenn wir die Igel morgends hoch fahren, dass sie zum einen sehr lange brauchen um sich mit dem Lan zu verbinden und dann erst nach ca. 5 Minuten eine Verbindung zur Terminalsession und ins Internet herstellen. Solange ist alles so zu sagen Tot.
Wenn sie sich dann verbunden haben geht alles wie immer. Das Merkwürdige ist das ganze passiert nur in Standort B in allen anderen Standorten ist das nicht.
Wir haben schon bei Versaltel (die stellen uns die Leitung) angerufen die Leitung soll aber ok sein. Dann haben wir selbst Rechner von Standort B nach A angepingt was auch funktionierte nur von Standort A auf B konnte kein Ping gemacht werden.
Ich bin im Moment ratlos woher kommt das? Hat jemand von euch eine Idee?
Zu testzwecken, da wir im Moment keine Server im Netz haben allerdings in einigen Wochen welche einführen möchten habe ich im Büro einen Testserver mit windows 2003 stehen allerdings läuft der schon einige Tage bevor das Problem aufgetaucht ist. Ich kann mir nicht denken, dass es an dem Server liegt.
Hat vielleicht jemand von euch eine Idee???
wir benutzen in der Firma im Verkauf Igen Thin Clients der neusten Generation. Konfiguriert haben wir die Igel über die Management Suite von Igel.
Auf den Igel wird eine Terminalsession und halt der Internetzugang per Firefox genutzt (Linux Igel).
Nun ist es so, wir haben 3 Standorte Hauptstandort ist Standort A. Standort B und C sind mit einer S DSL Leitung mit Standort A vernetzt (VPN). B & C gehen also immer über Standort A ins Internet.
Seit 2 Tagen haben wir nun das Problem, wenn wir die Igel morgends hoch fahren, dass sie zum einen sehr lange brauchen um sich mit dem Lan zu verbinden und dann erst nach ca. 5 Minuten eine Verbindung zur Terminalsession und ins Internet herstellen. Solange ist alles so zu sagen Tot.
Wenn sie sich dann verbunden haben geht alles wie immer. Das Merkwürdige ist das ganze passiert nur in Standort B in allen anderen Standorten ist das nicht.
Wir haben schon bei Versaltel (die stellen uns die Leitung) angerufen die Leitung soll aber ok sein. Dann haben wir selbst Rechner von Standort B nach A angepingt was auch funktionierte nur von Standort A auf B konnte kein Ping gemacht werden.
Ich bin im Moment ratlos woher kommt das? Hat jemand von euch eine Idee?
Zu testzwecken, da wir im Moment keine Server im Netz haben allerdings in einigen Wochen welche einführen möchten habe ich im Büro einen Testserver mit windows 2003 stehen allerdings läuft der schon einige Tage bevor das Problem aufgetaucht ist. Ich kann mir nicht denken, dass es an dem Server liegt.
Hat vielleicht jemand von euch eine Idee???
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 113687
Url: https://administrator.de/forum/thin-client-geht-mit-verzoegerung-ins-netz-113687.html
Ausgedruckt am: 10.04.2025 um 21:04 Uhr
4 Kommentare
Neuester Kommentar
Es gibt eigentlich nur 2 mögliche Ursachen:
1.) Leitungsüberlast
2.) Ausfall der Leitung oder des VPNs
Zu Punkt 2 kann man leider nicht viel sagen da du rein gar nichts Detailiertes zu dieser Infrastruktur mitteilst.
Nur soviel:
Vom Standort A aus muss der VPN Router bzw. das lokale LAN Interface dort permanent pingbar sein. (ping -t)
Ist es das nicht ist das VPN oder der SDSL Anschluss gestört....keine Frage.
Zu Punkt 1 kann man auch nur raten.... Die Igel TS booten vermutlich selber ein Image aus dem ROM und booten nicht das BS übers Netz...??
D.h. es geht lediglich die TS Session übers Netz.
Wenn nun der Server oder anderes Last auf der VPN Verbindung erzeugt dann kann es zu diesen Wartezeiten und Ausfall der TS Session kommen, keine Frage.
Normalerweise priorisiert man dann TC Traffic auf dem Router was aber vermutlich bei dir nicht gemacht wurde.
Letztlich löst es auch das kausale Problem nicht, wenn es denn eine Traffic Überlast ist.
Du solltest also mal einen Sniffer wie den Wireshark an den VPN Router in den Stanort anschliessen und solltest mal nachsehen WAS da na Traffic vom Standort kommt und ob die Überlast Theorie haltbar ist.
Ohne Sniffer sagen dir das auch schn die Paket Statistiken am Router oder Switchport.
Auch ein Test des möglichen Durchsatzes des VPN Tunnels mit den Tool netio
http://www.nwlab.net/art/netio/netio.html
ist hilfreich und zeigt dir die tatsächlich verfügbare Bandbreite des VPN Tunnels. Auch ein Indiz für ggf. mögliche Störungen..
Die banalste Möglichkeit ist mal den Server auszuschalten und zu sehen was passiert.... ggf. sendet der fröhlich Daten durch den Tunnel und blockiert so die Bandbreite für die TS Clients....
Damit solltest du dem Problem eigentlich im Handumdrehen auf die Schliche kommen !!
1.) Leitungsüberlast
2.) Ausfall der Leitung oder des VPNs
Zu Punkt 2 kann man leider nicht viel sagen da du rein gar nichts Detailiertes zu dieser Infrastruktur mitteilst.
Nur soviel:
Vom Standort A aus muss der VPN Router bzw. das lokale LAN Interface dort permanent pingbar sein. (ping -t)
Ist es das nicht ist das VPN oder der SDSL Anschluss gestört....keine Frage.
Zu Punkt 1 kann man auch nur raten.... Die Igel TS booten vermutlich selber ein Image aus dem ROM und booten nicht das BS übers Netz...??
D.h. es geht lediglich die TS Session übers Netz.
Wenn nun der Server oder anderes Last auf der VPN Verbindung erzeugt dann kann es zu diesen Wartezeiten und Ausfall der TS Session kommen, keine Frage.
Normalerweise priorisiert man dann TC Traffic auf dem Router was aber vermutlich bei dir nicht gemacht wurde.
Letztlich löst es auch das kausale Problem nicht, wenn es denn eine Traffic Überlast ist.
Du solltest also mal einen Sniffer wie den Wireshark an den VPN Router in den Stanort anschliessen und solltest mal nachsehen WAS da na Traffic vom Standort kommt und ob die Überlast Theorie haltbar ist.
Ohne Sniffer sagen dir das auch schn die Paket Statistiken am Router oder Switchport.
Auch ein Test des möglichen Durchsatzes des VPN Tunnels mit den Tool netio
http://www.nwlab.net/art/netio/netio.html
ist hilfreich und zeigt dir die tatsächlich verfügbare Bandbreite des VPN Tunnels. Auch ein Indiz für ggf. mögliche Störungen..
Die banalste Möglichkeit ist mal den Server auszuschalten und zu sehen was passiert.... ggf. sendet der fröhlich Daten durch den Tunnel und blockiert so die Bandbreite für die TS Clients....
Damit solltest du dem Problem eigentlich im Handumdrehen auf die Schliche kommen !!
hi aqui
Den Server hatten wir sofort nachdem die Thin stehen geblieben waren ausgeschlatet bzw. vom Netz genommen. Allerdings wurde es dadurch nicht besser. Das merkwürdige ist ja auch, dass die Rechner im Netz sofort eine Verbindung aufnehmen und alles funktioniert. Nur die Thins wollen nicht.
Am Vortag bevor die Thin endgültig weg waren hatten wir für ca. 10min. einen "stillstand" dananch ging alles wieder. Am nächsten Morgen dann der komplette Stillstand aller Thins bis auf die Desktop PC´s.
Den Server hatten wir sofort nachdem die Thin stehen geblieben waren ausgeschlatet bzw. vom Netz genommen. Allerdings wurde es dadurch nicht besser. Das merkwürdige ist ja auch, dass die Rechner im Netz sofort eine Verbindung aufnehmen und alles funktioniert. Nur die Thins wollen nicht.
Am Vortag bevor die Thin endgültig weg waren hatten wir für ca. 10min. einen "stillstand" dananch ging alles wieder. Am nächsten Morgen dann der komplette Stillstand aller Thins bis auf die Desktop PC´s.
Nimm dir einen Sniffer (Wireshark) schleif ihn bei der Thin Station ein und check was da genau im Netzwerk abgeht...alles andere ist Spekulation !
Ggf. liegt das aber auch am anderen Ende sprich dem Terminal Server selber... Da sollte dir aber ein Sniffer Trace schnell Klarheit schaffen...
Ggf. liegt das aber auch am anderen Ende sprich dem Terminal Server selber... Da sollte dir aber ein Sniffer Trace schnell Klarheit schaffen...
