[gelöst] Netzwerkproblem: Wiederkehrende TCP-Retransmissions

[heisenberg]

Hallo zusammen,

ich habe hier ein Netzwerkproblem. Grundsätzlich ist das, was zur Fehlersuche notwendig ist, viel mehr, als was in einem Forum möglich ist. Insofern geht es mir darum, hier idealerweise an paar gute Ideen für Richtungen zu bekommen, wo die Wahrscheinlichkeit hoch ist etwas zu finden.

Zu den Tatsachen:

• Es geht um ca. 10 Systeme, die mit dem Modbus-Protokoll zusammen kommunizieren - genauer gesagt: Modbus/TCP (Port 502)
• Es gibt in unregelmässigen Abständen Aussetzer von immer ziehmlich genau 9 Sekunden. Das ca. 10-30 Mal am Tag. Aussetzer heisst: Ein Gerät meldet, dass es die Verbindung zu einem anderen verloren hat.
• Alles befindet sich im gleichen logischen IP-Segment (192.168.12.0/24).
• Mit Wireshark sehe ich da im Netzwerk zu den Zeiten 3 x TCP-Retransmit und dann einen TCP-Reset (Siehe: gallery/image/5034/source)
• Aktuell habe ich auf alle Statitionen mal einen sekündlichen nmap auf Port 502 aller Stationen am Laufen. Erfolgsrate: 100% seit 24 Stunden. (Script: 42224)
• Die Switchportauslastung habe ich noch nicht geprüft, da ich noch nicht die genauen Switche und Ports der Stationen habe.

Die Problemfelder, die ich mir so vorstelle sind:

1. defekte Netzwerkhardware (Kabel, Switch, Netzwerkkarten)
2. temporäre Beeinträchtigung oder Überlastung des Netzwerkes (z. B. durch Fehlkonfiguration im Netzwerk oder Prozesse, die hohen Traffic verursachen)
3. Software, die das Modbus-Protokoll auf den einzelnen Systemen spricht reagiert ab und an nicht, bzw. mit genannten 9 Sekunden Verzögerung.

So grundsätzlich würde ich vermuten, dass a) und b) eigentlich eher unwahrscheinlich ist, weil es nur um sehr wenig Daten geht und auch weil der nmap-Scan absolut fehlerlos ist. Insofern würde wäre eher c) mein Favorit.

Die Gründe für TCP-Retransmissions sind ja fehlerhafte Checksummen (=Datenfehler) oder nicht rechtzeitige TCP-Acks von der Gegenstelle. Also Ursachen wären hier für mich wieder die Anwendung, die nicht auf Anfragen schnell genug antwortet, oder eben wieder Das Netzwerk, das aus irgendeinem Grund die Daten nicht, nicht korrekt oder nicht schnell genug überträgt.

Um fehlerhafte Checksumen zu identifizieren überlege ich mir nochmal einen ping mit Datengröße 1500 Bytes im Sekundentakt an alle Stationen zu übertragen. Bewerte ich das richtig, dass ping (icmp) prüft, ob die Daten die er schickt und wieder bekommt auch auf Integrität prüft? Sprich sind genau die Daten angekommen, die auch geschickt wurden? Falls ja: Falls es einen Fehler im Netzwerk gäbe, dann müssten ja irgendwann mal bei mehreren 100.000 Paketen pro Tag mal Fehler auftreten.

Weitere Überlegung wäre für mich auch sekündliche checks mit dem Modbus-Protokoll zu fahren. Auf die Art und Weise müsste ich ja sehen, dass die Anwendung irgendwann mal nicht mehr reagiert, wenn ich in einen Timeout bekomme.

Habe ich irgendwelche groben Denkfehler? Was denkt Ihr dazu?

Nachtrag: Zwei Protokolle für Nichterreichbarkeiten

Die beiden relevanten Hosts sind 192.168.12.200 und 192.168.12.211. Die Tests wurde von einem anderen lokalen Netz aus durchgeführt.

a) sekündliche Ping checks mit 1400 Bytes

Code: Alles auswählen

192.168.12.211

Thu Sep 26 18:57:26 CEST 2024 : new state for host 192.168.12.211: UP
Thu Sep 26 22:39:29 CEST 2024 : new state for host 192.168.12.211: DOWN
Thu Sep 26 22:41:46 CEST 2024 : new state for host 192.168.12.211: UP

192.168.12.200

Thu Sep 26 18:57:26 CEST 2024 : new state for host 192.168.12.200: UP
Thu Sep 26 22:39:29 CEST 2024 : new state for host 192.168.12.200: DOWN
Thu Sep 26 22:41:46 CEST 2024 : new state for host 192.168.12.200: UP
Fri Sep 27 01:43:30 CEST 2024 : new state for host 192.168.12.200: DOWN
Fri Sep 27 01:43:31 CEST 2024 : new state for host 192.168.12.200: UP
Fri Sep 27 11:33:30 CEST 2024 : new state for host 192.168.12.200: DOWN
Fri Sep 27 11:33:31 CEST 2024 : new state for host 192.168.12.200: UP
Fri Sep 27 11:48:03 CEST 2024 : new state for host 192.168.12.200: DOWN
Fri Sep 27 11:48:04 CEST 2024 : new state for host 192.168.12.200: UP

a) sekündliche Nmap - checks auf Port 502/tcp

Code: Alles auswählen

192.168.12.211

Fri Sep 27 02:01:10 CEST 2024 : new state for host 192.168.12.211: UP
Fri Sep 27 10:17:16 CEST 2024 : new state for host 192.168.12.211: DOWN
Fri Sep 27 10:17:37 CEST 2024 : new state for host 192.168.12.211: UP
Fri Sep 27 10:26:37 CEST 2024 : new state for host 192.168.12.211: DOWN
Fri Sep 27 10:26:57 CEST 2024 : new state for host 192.168.12.211: UP
Fri Sep 27 12:18:17 CEST 2024 : new state for host 192.168.12.211: DOWN
Fri Sep 27 12:18:37 CEST 2024 : new state for host 192.168.12.211: UP

192.168.12.200: Immer erreichbar

[Livingston]

Zu Ping:
ICMP ist zwar in erster Linie nicht verbindungsorientiert wie z.B. TCP, aber das Programm ping selbst wartet auf Antworten. Standardmäßig schickt es ein ICMP-Paket mit Typ 8 (Echo Request, "ping") an eine Destination-Adresse und wartet auf ein ICMP-Paket von dieser Adresse mit Typ 0 (Echp Replay, "pong"). Ein Echo Request muss nicht zwangsläufig ein kleines Paket sein, Du kannst mit der Option -s packetsize an dieser Schraube drehen.
Für echten Inhalt in ICMP-Paketen gibt's auch ein kleines Tool, aber ich komme grad nicht drauf. Hat noch jemand im Kopf, welches das sein könnte?

[heisenberg]

ICMP ist zwar in erster Linie nicht verbindungsorientiert wie z.B. TCP, aber das Programm ping selbst wartet auf Antworten. Standardmäßig schickt es ein ICMP-Paket mit Typ 8 (Echo Request, "ping") an eine Destination-Adresse und wartet auf ein ICMP-Paket von dieser Adresse mit Typ 0 (Echp Replay, "pong"). Ein Echo Request muss nicht zwangsläufig ein kleines Paket sein, Du kannst mit der Option -s packetsize an dieser Schraube drehen.

Soweit so bekannt. Ich nutze aktuell eine Paketgröße von 1450 Bytes.

Für echten Inhalt in ICMP-Paketen gibt's auch ein kleines Tool, aber ich komme grad nicht drauf. Hat noch jemand im Kopf, welches das sein könnte?

Das geht definitiv in die richtige Richtung. Ist das vielleicht hping3 ? (Da bekomme ich keine Antwort, wenn ich über eine Firewall hinweg pinge (Traffic komplett für den Sender erlaubt))

Damit geht es:

Code: Alles auswählen

hping3 -c 1 -d 1470  --icmptype 8 192.168.12.12

Wenn ich das so richtig verstehe, dann vergleicht hping3 auch nicht die gesendeten mit den empfangenen Daten. Aber auch icmp-checksummen sind vorhanden und wenn die checksumme nicht stimmt, dann wird das Paket vom Linux-Kernel verworfen. D. h. Paketverlust beim ping. Das ist ja so brauchbar.

[debra]

Ich halte a für nicht ausgeschlossen. Es gibt mittlerweile ein Haufen dumm Layer 2 Hardware, die Syns in irgend einer weise priorisiert optimiert.
Tippe aber eher auf irgend eine Firewall/NAT etc. Gibt es da was oder ist das wirklich ein reines geswitchtes Netzwerk ohne iptables etc. auf den Endpunkten?

[letzter3]

Ggf. ist die ModBUs-IP-Leitung schlecht -> in der Nähe von Stromleitungen platziert?
Und jedesmal, wenn stromseitig eine Spitze gefahren wird, die ein einzelnes Bit im ModBus kippen lässt.

[heisenberg]

Tippe aber eher auf irgend eine Firewall/NAT etc. Gibt es da was oder ist das wirklich ein reines geswitchtes Netzwerk ohne iptables etc. auf den Endpunkten?

Das 192.168.12.0/24 ist ein Segment eines größeren LANs, dessen Firewall ich ich (aus der Ferne) administriere. D. h. grundsätzlich auch eine professionelle Verkabelung. In dem Segment sollten selbst keine Firewalls sein. Anwendungsbereich dieses Netzwerkes bzw. der Stationen dort drin ist die Steuerung eines kleinen Blockheizkraftwerkes.

Die Symptome sprechen für mich aber eher nicht für ein Firewallthema: Seltene, kurze Aussetzer. Wäre es ein typisches Firewallthema, würde ja eher überhaupt nichts gehen.

Ich habe im ersten Beitrag nochmal die konsolidierten Logs des Ping/nmap-Checks des letzten Tages angefügt.

[heisenberg]

Tippe aber eher auf irgend eine Firewall/NAT etc. Gibt es da was oder ist das wirklich ein reines geswitchtes Netzwerk ohne iptables etc. auf den Endpunkten?

Das 192.168.12.0/24 ist ein Segment eines größeren LANs, dessen Firewall ich ich (aus der Ferne) administriere. D. h. grundsätzlich auch eine professionelle Verkabelung. In dem Segment sollten selbst keine Firewalls sein. Anwendungsbereich dieses Netzwerkes bzw. der Stationen dort drin ist die Steuerung eines kleinen Blockheizkraftwerkes.

Die Symptome sprechen für mich aber eher nicht für ein Firewallthema: Seltene, kurze Aussetzer. Wäre es ein typisches Firewallthema, würde ja eher überhaupt nichts gehen.

Ich habe im ersten Beitrag nochmal die konsolidierten Logs des Ping/nmap-Checks des letzten Tages angefügt.

Ggf. ist die ModBUs-IP-Leitung schlecht -> in der Nähe von Stromleitungen platziert?
Und jedesmal, wenn stromseitig eine Spitze gefahren wird, die ein einzelnes Bit im ModBus kippen lässt.

Da es eine professionelle LAN-Verkabelung in einer Firma ist, würde ich es eher nicht vermuten. Aber das wird demnächst wohl auch nochmal jemand prüfen.

[heisenberg]

Ich habe jetzt nochmal einen dritten sekündlichen Check, der via modbus (mbpoll) einfach mal ein Register abfragt. Modbus scheint da ja ein extrem einfaches Protokoll zu sein. Sehr wenige binäre Daten. Keine Authentifizierung.

Das ist ein Beispielbefehl:

Code: Alles auswählen

mbpoll -1 -a 1 -r 1 -t 3:hex 192.168.12.210

-1 : Nur einmal versuchen.
-a 1: Modbus-Slave-Identifier (ist üblicherweise 1)
-r 1 : Beginn mit Register 1
-t 3:hex : Ein 16Bit Eingaberegister lesen und als hex interpretieren

[debra]

Die Symptome sprechen für mich aber eher nicht für ein Firewallthema: Seltene, kurze Aussetzer. Wäre es ein typisches Firewallthema, würde ja eher überhaupt nichts gehen.

Es geht nicht darum, dass die falsch konfiguriert ist. Sondern darum, dass a) eventuell kaputt sein könnte oder dass die nach irgend ner Heuristik Verbindungen vergisst um platz in den passenden Tabellen frei zu machen. Das ist übliches vorgehen von Hardware-Firewalls. Deswegen hast du keepalives etc, in der Hoffnung dass das die Heuristik beeinflusst. Tippe, dass da ein Bug oder eine komische Heuristik drin ist, die irgend wann nicht mehr merkt dass die Verbindung schon läuft und dann syn/ack für noch nicht etablierte Verbindungen weg schmeißt.

[heisenberg]

Ich habe mittlerweile drei verschiedene Checks im Sekundentakt laufen:

• nmap
• ping (~1500 Bytes)
• modbus request

Aktuelle Erkenntnis ist, dass Zeiten fehlgeschlagener Modbus-Requests mit denen fehlgeschlagener NMAP-Checks korellieren, während es sehr wenige Ping-Verluste gibt.

Hier mal eine konsolidierte Ausgabe von allen Downtimes größer 5 Sekunden des letzten Tages:

Code: Alles auswählen

*** Modbus Poll Timeouts ***

Sep 27 20:00:56 - Sep 27 20:01:25 192.168.12.230 Downtime 29 Sekunden
Sep 27 20:01:43 - Sep 27 20:04:48 192.168.12.206 Downtime 185 Sekunden
Sep 27 21:08:39 - Sep 27 21:09:22 192.168.12.230 Downtime 43 Sekunden
Sep 27 23:01:28 - Sep 27 23:02:17 192.168.12.200 Downtime 49 Sekunden
Sep 28 03:23:15 - Sep 28 03:24:18 192.168.12.200 Downtime 63 Sekunden
Sep 28 03:52:51 - Sep 28 03:53:09 192.168.12.230 Downtime 18 Sekunden
Sep 28 10:14:36 - Sep 28 10:15:19 192.168.12.230 Downtime 43 Sekunden
Sep 28 12:21:38 - Sep 28 12:22:11 192.168.12.200 Downtime 33 Sekunden
Sep 28 15:48:41 - Sep 28 15:49:15 192.168.12.200 Downtime 34 Sekunden
Sep 28 19:23:38 - Sep 28 19:24:48 192.168.12.200 Downtime 70 Sekunden

*** NMAP Timeouts auf TCP Port 502 ***

Sep 27 16:20:08 - Sep 27 16:20:29 192.168.12.230 Downtime 21 Sekunden
Sep 27 20:00:56 - Sep 27 20:01:24 192.168.12.230 Downtime 28 Sekunden
Sep 27 20:01:46 - Sep 27 20:04:49 192.168.12.206 Downtime 183 Sekunden
Sep 27 21:08:40 - Sep 27 21:09:22 192.168.12.230 Downtime 42 Sekunden
Sep 27 23:01:28 - Sep 27 23:02:18 192.168.12.200 Downtime 50 Sekunden
Sep 28 03:23:16 - Sep 28 03:24:19 192.168.12.200 Downtime 63 Sekunden
Sep 28 03:52:52 - Sep 28 03:53:09 192.168.12.230 Downtime 17 Sekunden
Sep 28 10:14:38 - Sep 28 10:15:20 192.168.12.230 Downtime 42 Sekunden
Sep 28 12:21:38 - Sep 28 12:22:12 192.168.12.200 Downtime 34 Sekunden
Sep 28 15:48:42 - Sep 28 15:49:16 192.168.12.200 Downtime 34 Sekunden
Sep 28 19:23:39 - Sep 28 19:24:47 192.168.12.200 Downtime 68 Sekunden

*** Ping Timeouts ***

Sep 27 20:02:04 - Sep 27 20:02:25 192.168.12.206 Downtime 21 Sekunden
Sep 27 20:02:31 - Sep 27 20:02:49 192.168.12.206 Downtime 18 Sekunden
Sep 27 20:03:14 - Sep 27 20:03:28 192.168.12.206 Downtime 14 Sekunden
Sep 27 20:03:50 - Sep 27 20:04:04 192.168.12.206 Downtime 14 Sekunden

Die Tatsache, dass die fehlgeschlagenen NMAP-Timeouts dann eine Ausgabe "502/tcp filtered" ergeben (bei gleichzeitigem Host-up), spricht für Deine Vermutung @debra. Ich selbst kenne so ein Phänomen noch überhaupt nicht.

[slu]

Ist vermutlich ein anderes Problem:
viewtopic.php?t=188227

Aber ich habe auch schon meine Erfahrung mit TCP Retransmissions sammeln dürfen.

[heisenberg]

Ist vermutlich ein anderes Problem:
viewtopic.php?t=188227

Aber ich habe auch schon meine Erfahrung mit TCP Retransmissions sammeln dürfen.

Ich sehe in dem verlinkten Beitrag nur Fragen aber keine Lösung, die das Problem dort irgendwie behoben hätte. Inwiefern soll das hier helfen?

Als Gründe für die Retransmissions schätze ich das so ein, dass irgendwann mal - ohne den Grund dafür zu kennen (hier im Thema wurde ja das eine oder andere genannt) - die Pakete einfach für eine kurze Zeitspanne gefiltert werden. Nachdem dann halt gar nix zurück kommt (Firewall "filtered" eben) kommen halt ein paar Retransmits, bevor die Verbindung abgebrochen wird.

[slu]

Ich sehe in dem verlinkten Beitrag nur Fragen aber keine Lösung, die das Problem dort irgendwie behoben hätte. Inwiefern soll das hier helfen?

Diese Kritik ist berechtigt!

Ich wollte damit eigentlich sagen das ich auch schon Tage mit der Fehlersuche verbracht habe und es bis heute nicht gefunden habe weil
einfach zu viele Komponenten und Treiber vorhanden sind.

Sorry OT, ich weiß.

Konntest Du dein Problem noch weiter eingrenzen?

[heisenberg]

Ich habe die Scripte noch etwas länger laufen lassen. Aber jetzt ist es eigentlich klar, dass es ein Geräte Problem ist, wenn der TCP-Port 502 der Geräte ab und einfach nur mit filtered unerreichbar ist, bei gleichzeitiger Erreichbarkeit via Ping.

Also entweder der Dienst stürzt einfach nur ab und wird dann neu gestartet oder es ist das embedded Firewall-Problem wie von debra angemerkt. In beiden Fällen also ein Problem des Gerätes selbst.

[florit]

Wenn ich das Thema „Traffic Shaping“ mal einwerfen darf?

Vielleicht ist es auch nur eine Bandbreiten Verschmälerung

Paket 1Mb Bandbreite 500Kb

Ist das möglich?

[heisenberg]

Traffic Shaping? Mit an Sicherheit genzender Wahrscheinlichkeit nicht.

Modbus ist ein sehr bandbreitensparsames Protokoll. Das ganze findet innerhalb eines separaten Netzwerksegment statt, das mit 1 GbE verkabelt ist. Das geht um wenige KB/s, die da über's Netzwerk gehen.

Für mich ist das Thema jetzt gelöst. In meinem Bericht benenne ich HW-/SW-Fehler der getesteten Geräte als Ursache.