148829
19.06.2021, aktualisiert um 09:04:09 Uhr
1807
17
0
Kassen freezen ohne ersichtlichen Grund
Hallo Zusammen,
ich schreibe heute zum ersten Mal in diesem Forum. Also weißt mich bitte auf etwaige Fehler meinerseits hin.
Wie ich in anderen Beiträgen gelesen habe, sind kurze Texte mit viel Inhalt gewünscht, deshalb gleich zur Sache.
Mein Kunde hat 5 Kassen gekauft.
OS: Windows 10
Kassensoftware: AmadeusII (läuft glaube ich auf Javabasis)
3 dieser Kassen sind an verschiedenen Standorten im Gebäude aufgestellt.
Diese Kassen funktionieren ohne Probleme.
Die 2 anderen Kassen sind zusammen an einer weiteren Verkaufsstelle im Gebäude.
Diese beiden frieren immer wieder ein.
Beim Tippen auf Artikel passiert dann gar nichts. Und nach ein paar Sekunden rattern dann alle getippten Artikel durch auf die Rechnung.
Alle Kassen kommunizieren bei jedem Tippen auf einen Artikel mit einem Server, der ebenfalls neu ist.
Virtualisierung: ESXi
OS der VM: WindowsServer2019 STD
Netzwerkkarte im gleichen VLAN wie Kassen.
Die 3 funktionieren Kassen sind wie folgt angeschlossen:
Server
Switch 1
Switch x
(Switch x)
Kasse
Die 2 fehlerhaften haben folgenden Weg:
Server
Switch 1
Medienkonverter LWL
LWL
Medienkonverter LWL
Switch 2
Switch 3
Kasse
Troubleshooting und Ergebnisse:
- Funkbrücke anstatt Medienkonverter und LWL
- Dauerping mit Log 2 Tage (1ms oder <1ms)
- 1GB Daten hin und zurück ohne Probleme
- Switches 2 & 3 getauscht
- Switch 1 anderer Port genommen
- LWL mit Medienkonverter ohne Switch 2 & 3 an Kasse angeschlossen
- Funkbrücke ohne Switch 2 & 3 direkt an Kasse angeschlossen
- Tausch der Kassenhardware
- Neuinstallation der Kassensoftware (Client)
- Wireshark (kein Flooding oder sonstiger auffälliger Verkehr)
Besonderheiten bei den Problemkassen:
- einzige Kassen zu zweit an einer Verkaufsstelle
- einzige Kassen per LWL angebunden
- einzige Kassen mit größerer Entfernung zum Server
- Probleme lassen sich nicht gezielt Triggern (z.B. durch Tippen auf ein bestimmtes Produnk), sondern treten 'random' auf
- Kassen können nicht mit funktionierenden Kassen getauscht werden, da unterschiedliche Artikel an verschiedenen Verkaufsstellen
Anmerkung:
Meine Rolle bei dem Ganzen ist die Bereitstellung/Konfiguration von:
- Switches
- ESXi-Server + VMs mit OS
- APs mit WLAN für EC-Geräte
- Sonstige Netzwerkinfrastruktur, wie Firewall, DHCP, DNS, ...
Weder kenne ich mich mit den Kassenclients, noch dem Kassenserver aus.
Diese Installation hat ein Dienstleister, der sich nur auf Kassensysteme spezialisiert hat, vorgenommen.
Folgende Unterstützung erhalte ich von diesem Dienstleister:
"Nein, sowas hatten wir noch nie. Muss ein Netzwerkproblem sein."
Und ja, ich kann absolut nachvollziehen, dass es sehr nach Netzwerk klingt, wenn es nur zwei Kassen betrifft, die einen anderen Pfad gehen, als alle anderen Kassen, aber ich finde keinen Fehler und komme nicht mehr weiter.
Meine Kollegen sind wie ich zu dem Schluss gekommen, dass es ein inhaltliches Problem bei der Kommunikation mit der Datenbank geben muss. Da ich das aber nicht prüfen kann, mache ich eben mit meiner Suche im Netzwerk weiter. Was übersehe ich? Wie kann ich noch ansetzen?
Ich freue mich auf eure Unterstützung und entschuldige mich für den Roman.
Liebe Grüße Ronic
ich schreibe heute zum ersten Mal in diesem Forum. Also weißt mich bitte auf etwaige Fehler meinerseits hin.
Wie ich in anderen Beiträgen gelesen habe, sind kurze Texte mit viel Inhalt gewünscht, deshalb gleich zur Sache.
Mein Kunde hat 5 Kassen gekauft.
OS: Windows 10
Kassensoftware: AmadeusII (läuft glaube ich auf Javabasis)
3 dieser Kassen sind an verschiedenen Standorten im Gebäude aufgestellt.
Diese Kassen funktionieren ohne Probleme.
Die 2 anderen Kassen sind zusammen an einer weiteren Verkaufsstelle im Gebäude.
Diese beiden frieren immer wieder ein.
Beim Tippen auf Artikel passiert dann gar nichts. Und nach ein paar Sekunden rattern dann alle getippten Artikel durch auf die Rechnung.
Alle Kassen kommunizieren bei jedem Tippen auf einen Artikel mit einem Server, der ebenfalls neu ist.
Virtualisierung: ESXi
OS der VM: WindowsServer2019 STD
Netzwerkkarte im gleichen VLAN wie Kassen.
Die 3 funktionieren Kassen sind wie folgt angeschlossen:
Server
Switch 1
Switch x
(Switch x)
Kasse
Die 2 fehlerhaften haben folgenden Weg:
Server
Switch 1
Medienkonverter LWL
LWL
Medienkonverter LWL
Switch 2
Switch 3
Kasse
Troubleshooting und Ergebnisse:
- Funkbrücke anstatt Medienkonverter und LWL
- Dauerping mit Log 2 Tage (1ms oder <1ms)
- 1GB Daten hin und zurück ohne Probleme
- Switches 2 & 3 getauscht
- Switch 1 anderer Port genommen
- LWL mit Medienkonverter ohne Switch 2 & 3 an Kasse angeschlossen
- Funkbrücke ohne Switch 2 & 3 direkt an Kasse angeschlossen
- Tausch der Kassenhardware
- Neuinstallation der Kassensoftware (Client)
- Wireshark (kein Flooding oder sonstiger auffälliger Verkehr)
Besonderheiten bei den Problemkassen:
- einzige Kassen zu zweit an einer Verkaufsstelle
- einzige Kassen per LWL angebunden
- einzige Kassen mit größerer Entfernung zum Server
- Probleme lassen sich nicht gezielt Triggern (z.B. durch Tippen auf ein bestimmtes Produnk), sondern treten 'random' auf
- Kassen können nicht mit funktionierenden Kassen getauscht werden, da unterschiedliche Artikel an verschiedenen Verkaufsstellen
Anmerkung:
Meine Rolle bei dem Ganzen ist die Bereitstellung/Konfiguration von:
- Switches
- ESXi-Server + VMs mit OS
- APs mit WLAN für EC-Geräte
- Sonstige Netzwerkinfrastruktur, wie Firewall, DHCP, DNS, ...
Weder kenne ich mich mit den Kassenclients, noch dem Kassenserver aus.
Diese Installation hat ein Dienstleister, der sich nur auf Kassensysteme spezialisiert hat, vorgenommen.
Folgende Unterstützung erhalte ich von diesem Dienstleister:
"Nein, sowas hatten wir noch nie. Muss ein Netzwerkproblem sein."
Und ja, ich kann absolut nachvollziehen, dass es sehr nach Netzwerk klingt, wenn es nur zwei Kassen betrifft, die einen anderen Pfad gehen, als alle anderen Kassen, aber ich finde keinen Fehler und komme nicht mehr weiter.
Meine Kollegen sind wie ich zu dem Schluss gekommen, dass es ein inhaltliches Problem bei der Kommunikation mit der Datenbank geben muss. Da ich das aber nicht prüfen kann, mache ich eben mit meiner Suche im Netzwerk weiter. Was übersehe ich? Wie kann ich noch ansetzen?
Ich freue mich auf eure Unterstützung und entschuldige mich für den Roman.
Liebe Grüße Ronic
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: 744440718
Url: https://administrator.de/contentid/744440718
Ausgedruckt am: 22.11.2024 um 00:11 Uhr
17 Kommentare
Neuester Kommentar
Hi
Wireshark traffic capture vom Auftreten des Problems vorhanden? Am Besten an verschiedenen Messpunkten entlang des Weges aufgenommen, vor allem aber an den Kassen.
Gruß
Wireshark traffic capture vom Auftreten des Problems vorhanden? Am Besten an verschiedenen Messpunkten entlang des Weges aufgenommen, vor allem aber an den Kassen.
Gruß
Hey,
habe ich nicht gespeichert.
Ich schneide nochmal mit und stelle es hier bereit.
Gruß
habe ich nicht gespeichert.
Ich schneide nochmal mit und stelle es hier bereit.
Gruß
Interessant wäre ja der Wireshark Trace von Kassenclient und Server. Das solltest du dir parallel mit 2 zeitgleichen Traces ansehen. Kollege @marinux hat es oben schon richtig gesagt.
Wenn du damit nachweisen kannst das z.B. der Server nicht zeitnah antwortet ist es nicht mehr das Netzwerk.
Im Grunde hast du ja schon bilderbuchmäßig alles getestet was die Netzwerk Infrastruktur betrifft und ausgeschlossen.
Das Einzige was man als rückständig anmerken könnte ist die Verwendung von vorsintflutlichen LWL Medienwandlern. Sowas erledigt man schon seit langem mit Switches die entsprechend integrierte SFP Glasfaserports haben und mit preiswerten SFP Optiken arbeiten.
Externe Medienwandler schaffen wieder mögliche Autonegotiation Probleme usw. und sind eine weitere potentielle Fehlerquelle die bei Verwendung der richtigen Switch Hardware mit SFP Ports eigentlich komplett überflüssig ist.
Die fehlerfreien Dauerpings schliessen sie aber als Fehlerquelle auch aus.
Mit den 3 obigen Messungen kannst du aber dem SW Dienstleister ggf. explizit Fehler nachweisen um deinen Verantwortungsbereich als Ursache sicher auszuschliessen.
- Sendet die Kasse Daten an den Server und wenn ja kommen die zeitgleich bzw. zeitnah am Server an ?
- Wie reagiert die abgesetzte Kassensoftware (Server) aus diese Kassendaten ? Kommt eine zeitnahe Antwort ?
- Erreicht diese Antwort auch zeitnah wieder die Kasse selber ?
Wenn du damit nachweisen kannst das z.B. der Server nicht zeitnah antwortet ist es nicht mehr das Netzwerk.
Im Grunde hast du ja schon bilderbuchmäßig alles getestet was die Netzwerk Infrastruktur betrifft und ausgeschlossen.
Das Einzige was man als rückständig anmerken könnte ist die Verwendung von vorsintflutlichen LWL Medienwandlern. Sowas erledigt man schon seit langem mit Switches die entsprechend integrierte SFP Glasfaserports haben und mit preiswerten SFP Optiken arbeiten.
Externe Medienwandler schaffen wieder mögliche Autonegotiation Probleme usw. und sind eine weitere potentielle Fehlerquelle die bei Verwendung der richtigen Switch Hardware mit SFP Ports eigentlich komplett überflüssig ist.
Die fehlerfreien Dauerpings schliessen sie aber als Fehlerquelle auch aus.
Mit den 3 obigen Messungen kannst du aber dem SW Dienstleister ggf. explizit Fehler nachweisen um deinen Verantwortungsbereich als Ursache sicher auszuschliessen.
Herzlich willkommen Ronic
So wie Du es schilderst, ist es kein Netzwerkproblem sonder eher ein Problem auf der Kasse oder auf dem Server (sagt meine Kristallkugel).
Passiert dieses "einfrieren" auch mit anderen Programmen außer der Kassensoftware oder nur mit der Kassensoftware?
kann man während dem einfrieren im Taskmanager irgendwas erkennen oder auf andere Programme wechseln (Notfalls eine normale Tastatur zum Testen anschließen, wenn nur die Kassentastatur vorhanden sein sollte)
Passiert der Fehler auch nocht, wenn Du Kassen tauscht?
Sind die Kassen alle identisch? oder unterscheiden die sich in der Hardware/Software?
lks
So wie Du es schilderst, ist es kein Netzwerkproblem sonder eher ein Problem auf der Kasse oder auf dem Server (sagt meine Kristallkugel).
Passiert dieses "einfrieren" auch mit anderen Programmen außer der Kassensoftware oder nur mit der Kassensoftware?
kann man während dem einfrieren im Taskmanager irgendwas erkennen oder auf andere Programme wechseln (Notfalls eine normale Tastatur zum Testen anschließen, wenn nur die Kassentastatur vorhanden sein sollte)
Passiert der Fehler auch nocht, wenn Du Kassen tauscht?
Sind die Kassen alle identisch? oder unterscheiden die sich in der Hardware/Software?
lks
@aqui
Hallo,
danke für deine ausführliche Anleitung!
Das mache ich direkt so. Hätte ich ja auch selbst mal draufkommen können die Traces zu vergleichen..
Zu den Wandlern:
Du hast natürlich vollkommen Recht.
Wir haben den Kunden gerade frisch übernommen und ziehen gerade alles nach und nach hoch.
Und die Dinger gehören natürlich ersetzt.
Anbei noch der Netzwerkschrank, wie ich ihn vorgefunden habe bei der ersten Sichtung. P.S.: Der steht mit den Servern im Papierlager *wtf*..
[image unavailable]
Hallo,
danke für deine ausführliche Anleitung!
Das mache ich direkt so. Hätte ich ja auch selbst mal draufkommen können die Traces zu vergleichen..
Zu den Wandlern:
Du hast natürlich vollkommen Recht.
Wir haben den Kunden gerade frisch übernommen und ziehen gerade alles nach und nach hoch.
Und die Dinger gehören natürlich ersetzt.
Anbei noch der Netzwerkschrank, wie ich ihn vorgefunden habe bei der ersten Sichtung. P.S.: Der steht mit den Servern im Papierlager *wtf*..
[image unavailable]
@Lochkartenstanzer
Hey,
die Geräte an sich lassen sich noch bedienen. Also ich kann (weil der Kioskmodus) das Windows-InfoCenter seitlich reinziehen und mir da über das Öffnen der Einstellungen die Taskleiste hochholen. Und ab da geht dann alles.
Im Taskmanager ist auch zu sehen, dass das Kassengerät nicht ausgelastet ist.
Tauschen kann ich die Kassen wie beschrieben nicht, da unterschiedliche Artikel angeboten werden und der Fehler eben nur sporadisch bei der Bedienung auftritt.
Grüße
Hey,
die Geräte an sich lassen sich noch bedienen. Also ich kann (weil der Kioskmodus) das Windows-InfoCenter seitlich reinziehen und mir da über das Öffnen der Einstellungen die Taskleiste hochholen. Und ab da geht dann alles.
Im Taskmanager ist auch zu sehen, dass das Kassengerät nicht ausgelastet ist.
Tauschen kann ich die Kassen wie beschrieben nicht, da unterschiedliche Artikel angeboten werden und der Fehler eben nur sporadisch bei der Bedienung auftritt.
Grüße
Hallo Ronic,
ich kann hier auch nur Vergleiche anstellen, ich vermute die Clients schreiben in eine Datenbank (SQL?).
Da du hier einen Server virtualisiert hast, wie sind hier die Energieeinstellungen?
Vermutlich auf Ausbalanciert stelle mal auf Höchstleistung um, weiters auch in ESXi und im Bios ev. Sparmaßnamen deaktivieren.
Ich habe dieses Verhalten (Frieren und Laggen) bei einigen SQL so abstellen können.
ich kann hier auch nur Vergleiche anstellen, ich vermute die Clients schreiben in eine Datenbank (SQL?).
Da du hier einen Server virtualisiert hast, wie sind hier die Energieeinstellungen?
Vermutlich auf Ausbalanciert stelle mal auf Höchstleistung um, weiters auch in ESXi und im Bios ev. Sparmaßnamen deaktivieren.
Ich habe dieses Verhalten (Frieren und Laggen) bei einigen SQL so abstellen können.
@schicksal
Danke für deinen Ansatz.
BIOS/iLO sind auf Virtualisierung-Höchstleistung
Wie es auf der Windows-VM aussieht muss ich prüfen.
Die Datenbank kenne ich leider nicht, aber ich vermute auch SQL.
Interessant wäre wegen der Energieeinstellungen nur, warum die Probleme dann nur bei den beiden Kassen und nicht bei allen auftreten.
Die Kassen stehen alle auf Höchstleistung.
Grüße
Danke für deinen Ansatz.
BIOS/iLO sind auf Virtualisierung-Höchstleistung
Wie es auf der Windows-VM aussieht muss ich prüfen.
Die Datenbank kenne ich leider nicht, aber ich vermute auch SQL.
Interessant wäre wegen der Energieeinstellungen nur, warum die Probleme dann nur bei den beiden Kassen und nicht bei allen auftreten.
Die Kassen stehen alle auf Höchstleistung.
Grüße
Moin,
Wenn man mal zwischen Netzwerk und Kassenfrontend schaut:
Welche AV-Software läuft da auf den Systemen? Nicht dass die zum Zeitpunkt des Stockens "irgendein" Update fahren. Wobei das dann vermutlich auch wieder alle füne Kassen betreffen dürfte.
Habt ihr - mit dem Hersteller - die Möglichkeit, mal die Software auf einem Notebook o.ä. zu installieren, mit dem du dann wandern kannst? oder die Kasse nach Ladenschluss mal an einen anderen Ort zu verschieben?
Wobei ein Test dann natürlich nur dann valide ist, wenn man das Verhalten reproduzieren kann, was bei einem sporadischen auftreten ja schwierig ist.
Zum Schrank: ich mag keine Leute, die sich keine Mühe beim Patchen geben. Und dann auch noch Knoten in die Kabel einarbeiten
Kannst du, statt der Medienkonverter, den obigen HP einbinden? Der sieht ja (noch) ungenutzt aus.
Bei denen Ausschlüssen, was die Netzwerk-Infrastruktur betrifft: hast du da auch mal andere Patchkabel genutzt?
Die flachen Dinge sehen mir so ungeschirmt aus, kann mich aber auch täuschen.
Und passen die LWL-Patchkabel zu den LWL-Verlegekabel? Sprich alles durchgängig OM3 (türkis) bzw. OM1/2 (orange)?
Gruß
em-pie
Zitat von @schicksal:
ich kann hier auch nur Vergleiche anstellen, ich vermute die Clients schreiben in eine Datenbank (SQL?).
Das wäre ja ein doofes Design, wenn auch nicht unüblich. Kenne zwar selbst keine Kassensysteme aus IT-Sicht, sondern nur aus der Sicht eines kaufwilligen Kunden, aber ich hoffe ja, dass Hersteller solcher Systeme auf eine 3-Tier-Architecture aufbauen, sprich:ich kann hier auch nur Vergleiche anstellen, ich vermute die Clients schreiben in eine Datenbank (SQL?).
- Data-Layer
- Business-Layer
- Presentation-Layer
Da du hier einen Server virtualisiert hast, wie sind hier die Energieeinstellungen?
Vermutlich auf Ausbalanciert stelle mal auf Höchstleistung um, weiters auch in ESXi und im Bios ev. Sparmaßnamen deaktivieren.
Ich habe dieses Verhalten (Frieren und Laggen) bei einigen SQL so abstellen können.
Was dagegen spricht: er hat fünf Clients, von denen nur zwei herumzicken.Vermutlich auf Ausbalanciert stelle mal auf Höchstleistung um, weiters auch in ESXi und im Bios ev. Sparmaßnamen deaktivieren.
Ich habe dieses Verhalten (Frieren und Laggen) bei einigen SQL so abstellen können.
Wenn man mal zwischen Netzwerk und Kassenfrontend schaut:
Welche AV-Software läuft da auf den Systemen? Nicht dass die zum Zeitpunkt des Stockens "irgendein" Update fahren. Wobei das dann vermutlich auch wieder alle füne Kassen betreffen dürfte.
Habt ihr - mit dem Hersteller - die Möglichkeit, mal die Software auf einem Notebook o.ä. zu installieren, mit dem du dann wandern kannst? oder die Kasse nach Ladenschluss mal an einen anderen Ort zu verschieben?
Wobei ein Test dann natürlich nur dann valide ist, wenn man das Verhalten reproduzieren kann, was bei einem sporadischen auftreten ja schwierig ist.
Zum Schrank: ich mag keine Leute, die sich keine Mühe beim Patchen geben. Und dann auch noch Knoten in die Kabel einarbeiten
Kannst du, statt der Medienkonverter, den obigen HP einbinden? Der sieht ja (noch) ungenutzt aus.
Bei denen Ausschlüssen, was die Netzwerk-Infrastruktur betrifft: hast du da auch mal andere Patchkabel genutzt?
Die flachen Dinge sehen mir so ungeschirmt aus, kann mich aber auch täuschen.
Und passen die LWL-Patchkabel zu den LWL-Verlegekabel? Sprich alles durchgängig OM3 (türkis) bzw. OM1/2 (orange)?
Gruß
em-pie
@em-pie
Da muss ich mich nochmal mit dem Hersteller auseinandersetzen.
Zum Netzwerkschrank:
Der sieht längst nicht mehr so aus. Keine Flachbandkabel von Wish mehr. Keine Knoten, kein Chaos. Zumindest fast.
Ich weiß echt nicht, was sich der vorherige Dienstleister gedacht hat.
Aber da liefen auch so Geschichten wie: Der Dienstleister hat das root Passwort für den ESXi verloren/vergessen. Also kauft man zusätzlich noch einen Server mit HyperV, weil man ja keine VMs mehr auf dem ESXi anlegen kann.
Leider habe ich keine Infos über die verlegten LWL.
Ich weiß nicht mal wo die liegen...
Grüße
Da muss ich mich nochmal mit dem Hersteller auseinandersetzen.
Zum Netzwerkschrank:
Der sieht längst nicht mehr so aus. Keine Flachbandkabel von Wish mehr. Keine Knoten, kein Chaos. Zumindest fast.
Ich weiß echt nicht, was sich der vorherige Dienstleister gedacht hat.
Aber da liefen auch so Geschichten wie: Der Dienstleister hat das root Passwort für den ESXi verloren/vergessen. Also kauft man zusätzlich noch einen Server mit HyperV, weil man ja keine VMs mehr auf dem ESXi anlegen kann.
Leider habe ich keine Infos über die verlegten LWL.
Ich weiß nicht mal wo die liegen...
Grüße
Da muss ich mich nochmal mit dem Hersteller auseinandersetzen.
Die Jungs und Mädels an der Front können ja mal auf einem A4-Zettel kurz die Zeiten aufschreiben, an denen es hakt. Dann hast du Zeitpunkte, um dDiv. Logs am Client/ Server/ Switch auszuwerten.Ggf. div. DInge mal auf einem zentralen Syslog mitlaufen lassen. Setzt aber voraus, dass alle Geräte korrekte Zeiten haben -> NTP einrichten, sofern noch nicht vorhanden.
Zum Netzwerkschrank:
Der sieht längst nicht mehr so aus. Keine Flachbandkabel von Wish mehr. Keine Knoten, kein Chaos. Zumindest fast.
👍Der sieht längst nicht mehr so aus. Keine Flachbandkabel von Wish mehr. Keine Knoten, kein Chaos. Zumindest fast.
Ich weiß echt nicht, was sich der vorherige Dienstleister gedacht hat.
Schnelles Geld machen wollen - etwas anderes fällt mir da auch nie ein...Leider habe ich keine Infos über die verlegten LWL.
Ich weiß nicht mal wo die liegen...
Wenn du eines der beiden Seitenteile am Schrank öffnen kannst: mit etwas Glück stehen da Bezeichnungen an den Abgängen der LWL-Patchfelder dran.Ich weiß nicht mal wo die liegen...
Grüße
Anbei noch der Netzwerkschrank, wie ich ihn vorgefunden habe bei der ersten Sichtung.
Und wie man ja deutlich sieht auf den ersten Blick mit einem Switch der 4 ! SFP Ports hat und zusätzliche LWL Medienwandler damit dann völlig überflüssig macht. Kollege @em-pie hat es oben schon zu Recht angesprochen ! 
Ein Tausch mit SFP Optiken direkt vom Switch statt überflüssiger Medienwandler ist hier also dringenst anzuraten.
Diese gruseligen Flachkabel als Patchkabel zu verwenden ist auch eher kontraproduktiv wegen deren miserablem Übersprechverhalten. Solltest du auch auf die ToDo Liste packen und dort wenigstens saubere Cat5e oder höher Kabel verwenden.
Leider habe ich keine Infos über die verlegten LWL.
Sehr schlecht ! 
Wenigstens das absolute Minimum solltest du wissen ob es 50µ Multimode (OM2, 3 oder 4) ist oder 9µ Singlemode. Wenn du mit falschen Optiken auf dem falschen Kabel werkelst wäre das fatal.
Falls du die Verlegekabel am Schrank sehen kannst sieht dir die mal an. Die Kabelspezifikationen sind immer aufs Kabel gedruckt !
Allerdings ist hier der (Netzwerk) Teufel manchmal ein Eichhörnchen. Bei kleinen Paketen, wie du sie ganz sicher mit einem simplen Standardping gemacht hast, tritt das häufig nicht zutage. Mit größeren Paketen aber sehr wohl.
Zu den parallelen Sniffer Traces solltest du also um sicher zu gehen nochmal generell ein iPerf3 oder NetIO Test mit größeren Paketen über den LWL Link fahren:
https://web.ars.de/netio/
http://www.nwlab.net/art/netio/netio.html
Hoi,
tritt das Problem denn immer gleichzeitig auf, bei beiden Kassen? Oder ist das mal an der Kasse und dann an der anderen? Oder sind die nie gleichzeitig in Betrieb?
Gruß
tritt das Problem denn immer gleichzeitig auf, bei beiden Kassen? Oder ist das mal an der Kasse und dann an der anderen? Oder sind die nie gleichzeitig in Betrieb?
Gruß
Unregelmäßig an beiden oder einzeln..
Weiteres Indiz das es (vermutlich) NICHT das Netzwerk ist !
Moin Ronic,
ich hatte bei einem Kunden mal ein ähnliches Problem.
Das hilft dir bei deinem Problem vielleicht nicht wirklich, da bei dir alles im LAN ist, zeigt aber, dass es Ursachen geben kann, die man nicht vermutet.
ich hatte bei einem Kunden mal ein ähnliches Problem.
- SQL-Server basierte ERP-Lösung (MyFactory)
- keine Clientinstallation, da über Browser nutzbar
- alles im lokalen Netzwerk lief stabil und zuverlässig
- über WAN (auch VPN) verbunden Clients (Außendienst, Filiale, Monteure) haben unregelmäßig aber sehr häufig Freezes gehabt. Zwischen 30 Sekunden bis zu 30 Minuten hing dann der Browser
- unendlich erscheinende Wireshark-Tests haben nichts ergeben, außer dass die ERP-Lösung hing
- Übeltäter war der Vodafone Business Kabelanschluss
- nach Hinzufügen eines VDSL-Anschlusses und Einwahl über diesen war das Problem behoben. Testweise hatte der Kunde einen 1&1-Anschluss, der dann zu einem TCOM Business Anschluss umgezogen wurde.
- Seither ist das Problem nicht mehr aufgetreten
Das hilft dir bei deinem Problem vielleicht nicht wirklich, da bei dir alles im LAN ist, zeigt aber, dass es Ursachen geben kann, die man nicht vermutet.
Hallo Zusammen,
vielen Dank für eure zahlreichen Ratschläge und Hinweise!
Selten habe ich so ein nettes und hilfreiches Forum erlebt.
Die Probleme sind nun (hoffentlich) Geschichte. Nachdem der Kassendienstleister den Sync zwischen ERP-Server, Kassenserver und Kassen von "alle 10 Minuten" auf "alle 12 Stunden" angepasst hat.
So einfach kann es sein. *hust*
Vorallem wenn Dienstleister so gut zusammenarbeiten.
Danke nochmals und bis bald vielleicht.
Grüße Ronic
vielen Dank für eure zahlreichen Ratschläge und Hinweise!
Selten habe ich so ein nettes und hilfreiches Forum erlebt.
Die Probleme sind nun (hoffentlich) Geschichte. Nachdem der Kassendienstleister den Sync zwischen ERP-Server, Kassenserver und Kassen von "alle 10 Minuten" auf "alle 12 Stunden" angepasst hat.
So einfach kann es sein. *hust*
Vorallem wenn Dienstleister so gut zusammenarbeiten.
Danke nochmals und bis bald vielleicht.
Grüße Ronic
