9
ThinClient Verbindungsabbrüche oder zuviel Last?
Hallo,
ich habe bei einigen ThinClients Abbrüche bzw. kurze Netzwerkausfälle und weiß leider nicht woher die kommen.
Das Netz ist wie folgt aufgebaut:
VLAN ThinClient
- darin sind alle ThinClient enthalten (Produktion, Büro)
VLAN RDS
- darin sind alle RDS Host enthalten, egal ob Produktion oder Büro
Die RDS Hosts sind alle virtualisiert, laufen mit 10GbE auf einem SSD Storage. Ca 170 Thinclient laufen in der Produktion, ca 60 ThinClients in den Büros.
RDS Büro: 2012R2, 2016, zum Test 2019
RDS Produtkion: 2012R2
Fehlerbild:
- Am ThinClient (Nur an den Büro ThinClients) erscheint der Fehler " RDP Connection zu Server XXXX lost", bei einigen kommt auch "warte auf DHCP"
- Das Problem wäre wohl noch nich immer...laut einigen Mitarbeitern
Der/die betroffene(n) ThinClients sind am gleichen 48 Port Switch angeschlossen wie ThinClient der Produktion. Das heißt es sind z.B. 15 ThinClients am Switch und nur bei 2 taucht die Meldung auf, aber eben nur bei Büro ThinClients.
ThinClient Hardware:
- Büro: Fujitsu Futro S720, IGEL UD3
- Produktions: ThomasKrenn LES V3 mit Igel UD Pocket, Fujitsu S720
Der CoreSwitch ist ein Netgear M4300 mit 3 Units. Die ARP Tabelle ist dort Maximal 888 groß. Es sind im Netzwerk ca. 800 Geräte + 120 VM, Ich sehe Log immer wieder ein CleanUp der ARP Tabelle
Mein Gedanke:
Bringt es was, wenn ich die RDP Hosts in der ARP Tabelle Statisch im Core eintrage?
Waurm betrifft es nur die Büro ThinClients? Warum nur ein paar ThinClients im Wechsel ? Warum nicht alle am gleichen Switch?
Die Netzwerklast kann es eigtl. nicht sein, wir erreichen nicht mal 2,5 - 5 Gigabit.
Aufbau
RDS Host -> CoreSwitch -> Aggregation Switch -> EtagenSwitch -> ThinClient
ps.: im letztn halben Jahr sind ca 50 Geröte (PC, Drucker, Etikettendrucker) dazugekommen...aber das ist ja eigentlich "nichts"
Danke & einen schönen Sonntag noch
Gruß Wuebra
ich habe bei einigen ThinClients Abbrüche bzw. kurze Netzwerkausfälle und weiß leider nicht woher die kommen.
Das Netz ist wie folgt aufgebaut:
VLAN ThinClient
- darin sind alle ThinClient enthalten (Produktion, Büro)
VLAN RDS
- darin sind alle RDS Host enthalten, egal ob Produktion oder Büro
Die RDS Hosts sind alle virtualisiert, laufen mit 10GbE auf einem SSD Storage. Ca 170 Thinclient laufen in der Produktion, ca 60 ThinClients in den Büros.
RDS Büro: 2012R2, 2016, zum Test 2019
RDS Produtkion: 2012R2
Fehlerbild:
- Am ThinClient (Nur an den Büro ThinClients) erscheint der Fehler " RDP Connection zu Server XXXX lost", bei einigen kommt auch "warte auf DHCP"
- Das Problem wäre wohl noch nich immer...laut einigen Mitarbeitern
Der/die betroffene(n) ThinClients sind am gleichen 48 Port Switch angeschlossen wie ThinClient der Produktion. Das heißt es sind z.B. 15 ThinClients am Switch und nur bei 2 taucht die Meldung auf, aber eben nur bei Büro ThinClients.
ThinClient Hardware:
- Büro: Fujitsu Futro S720, IGEL UD3
- Produktions: ThomasKrenn LES V3 mit Igel UD Pocket, Fujitsu S720
Der CoreSwitch ist ein Netgear M4300 mit 3 Units. Die ARP Tabelle ist dort Maximal 888 groß. Es sind im Netzwerk ca. 800 Geräte + 120 VM, Ich sehe Log immer wieder ein CleanUp der ARP Tabelle
Mein Gedanke:
Bringt es was, wenn ich die RDP Hosts in der ARP Tabelle Statisch im Core eintrage?
Waurm betrifft es nur die Büro ThinClients? Warum nur ein paar ThinClients im Wechsel ? Warum nicht alle am gleichen Switch?
Die Netzwerklast kann es eigtl. nicht sein, wir erreichen nicht mal 2,5 - 5 Gigabit.
Aufbau
RDS Host -> CoreSwitch -> Aggregation Switch -> EtagenSwitch -> ThinClient
ps.: im letztn halben Jahr sind ca 50 Geröte (PC, Drucker, Etikettendrucker) dazugekommen...aber das ist ja eigentlich "nichts"
Danke & einen schönen Sonntag noch
Gruß Wuebra
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 555969
Url: https://administrator.de/forum/thinclient-verbindungsabbrueche-oder-zuviel-last-555969.html
Ausgedruckt am: 25.12.2024 um 01:12 Uhr
9 Kommentare
Neuester Kommentar
Hi
Wie verteilst Du die IPS in den VLANs?
Warte auf DHCP
da würde ich ansetzenWie verteilst Du die IPS in den VLANs?
Wie verteilst Du die IPS in den VLANs?
Über Windows DHCP.IP Helper ist der Core-Switch
Meinst du nicht, dass dann noch andere Geräte "Probleme" hätten?
Schon, aber wenn die IP mal vergeben ist, bleiben die Geräte eine Weile damit. Das Problem bekommen also "selten" nur die mit, die gerade einen Renew ausführen. Wenn Du das TTL hoch schraubst, dürfen die Fehler seltner werden, und umgekehrt. Das wäre dann ein gutes Indiz.
Ok. Schau ich mal nach. Aber die Leasetime habe ich dort auf 24h und die ThinClients werden jeden Morgen neugestartet. Somit sollte doch dann kein Renew stattfinden. Oder läuft die Zeit dann trotzdem ab?
Das erkennst Du am besten, wenn Du den DHCP Server mal mit seinen Leases beobachtest, und einen Rechner neu hochfahren lässt.
Also nach derzeitigen Stand betrifft es wirklich nur die IGEL UD Geräte und die Fujitsu Futro. Ein Gerät hat heute komplett das Netzwerk verloren. Der Port blinkt zwar, aber es war wie tod. Kabel kurz ab, wieder ran....und ging sofort wieder.
Als würde die Geräte dann abschalten oder die Mac Auth am Swtich verlieren. Jemand eine Idee ?
Als würde die Geräte dann abschalten oder die Mac Auth am Swtich verlieren. Jemand eine Idee ?
Mac Auth? Vergibst Du VLAN dynamisch anhand der MAC Adresse? Stelle mal testweise ein festes VLAN für eine kurze Testphase ein.
Zitat von @NordicMike:
Mac Auth? Vergibst Du VLAN dynamisch anhand der MAC Adresse? Stelle mal testweise ein festes VLAN für eine kurze Testphase ein.
Ja genau.....bei über 800 Geräte bekommt man sonst einen Koller, wenn man das statisch macht ;)....Mac Auth? Vergibst Du VLAN dynamisch anhand der MAC Adresse? Stelle mal testweise ein festes VLAN für eine kurze Testphase ein.
Bei Statisch treten die PRobleme nicht auf, aber damit habe ich dann wieder ein Sicherheitsproblem an dem Port....da dies nur bei 1-2 Modellreihen auftritt, gehe ich bald davon aus, dass die NIC in den Geräten zu "langsam" sind bzgl. der Mac Auth.....
so etwas hänliches hatte ich mal bei Uralt Etikettedndruckern.....diese habe ich dann aller 10 Sekunden mit PRTG angepingt. Danach gings. Das werde ich auch nochmal versuchen
Zumindest hast Du es mit der festen IP schon somit eingekreist. Irgendwelche Stromsparschweinereien? Treiber auf dem Bootimage aktualisieren?
