Netzwerkgerät im Netzwerk verschwindet nach Neustart
Hallo zusammen,
ich habe ein skurriles Problem und hoffe, dass hier jemand weiterhelfen kann.
Problemstellung:
Ich nutze einen kleinen 1-Platinen-Computer (BeagleBone Black) mit Debian, auf dem eine OSGi-Anwendung läuft. Ein Node der Anwendung baut eine TCP-Verbindung zu einer RS485-Schnittstelle auf.
Eckdaten:
- BeagleBone Black (BBB): IP 192.168.1.246
- RS485: IP 192.168.1.247
- Port: TCP 502
Das Problem:
Nach einem Neustart des BBB ist die RS485-Schnittstelle für diesen PC nicht erreichbar. Wenn ich versuche, sie per `ping` zu erreichen, geht das ARP-Paket ins Leere, als ob das Gerät nicht im Netzwerk wäre. Erst nachdem ich von einem anderen Gerät (meinem Windows-PC) einmal das RS485 anpinge, kann der BBB die RS485-Schnittstelle wieder normal erreichen und die Kommunikation läuft.
Auch ein Neustart der RS485-Schnittstelle bringt nichts, die Verbindung funktioniert erst wieder, nachdem ein anderer Netzwerkteilnehmer darauf zugreift.
Vermutung:
Ich habe den Verdacht, dass die Ursache bei den drei Mikrotik-Switches liegt, die im Netzwerk verbaut sind und per Daisy-Chain miteinander verbunden sind. Die Switches laufen alle in Standardkonfiguration, da kein spezielles Management eingerichtet ist.
Hat jemand eine Idee, woran das liegen könnte oder wie ich das Problem beheben kann?
Vielen Dank im Voraus!
ich habe ein skurriles Problem und hoffe, dass hier jemand weiterhelfen kann.
Problemstellung:
Ich nutze einen kleinen 1-Platinen-Computer (BeagleBone Black) mit Debian, auf dem eine OSGi-Anwendung läuft. Ein Node der Anwendung baut eine TCP-Verbindung zu einer RS485-Schnittstelle auf.
Eckdaten:
- BeagleBone Black (BBB): IP 192.168.1.246
- RS485: IP 192.168.1.247
- Port: TCP 502
Das Problem:
Nach einem Neustart des BBB ist die RS485-Schnittstelle für diesen PC nicht erreichbar. Wenn ich versuche, sie per `ping` zu erreichen, geht das ARP-Paket ins Leere, als ob das Gerät nicht im Netzwerk wäre. Erst nachdem ich von einem anderen Gerät (meinem Windows-PC) einmal das RS485 anpinge, kann der BBB die RS485-Schnittstelle wieder normal erreichen und die Kommunikation läuft.
Auch ein Neustart der RS485-Schnittstelle bringt nichts, die Verbindung funktioniert erst wieder, nachdem ein anderer Netzwerkteilnehmer darauf zugreift.
Vermutung:
Ich habe den Verdacht, dass die Ursache bei den drei Mikrotik-Switches liegt, die im Netzwerk verbaut sind und per Daisy-Chain miteinander verbunden sind. Die Switches laufen alle in Standardkonfiguration, da kein spezielles Management eingerichtet ist.
Hat jemand eine Idee, woran das liegen könnte oder wie ich das Problem beheben kann?
Vielen Dank im Voraus!
Please also mark the comments that contributed to the solution of the article
Content-ID: 669471
Url: https://administrator.de/contentid/669471
Printed on: December 14, 2024 at 15:12 o'clock
34 Comments
Latest comment
ARP geht ins leere?
Heißt die Switches kennen die Mac nicht mehr und dann auf einmal doch wieder?
Heißt die Switches kennen die Mac nicht mehr und dann auf einmal doch wieder?
Moin,
Einfacher ist es, die beiden Geräte an einen einfachen, nicht konfigurierbaren Switch zu hängen, sonst nichts, keine Verbindung zum sonstigen Netzwerk, dann noch ggf. einen Laptop dazu, und damit testen. Sinnvoller, als an den Switchen alles mögliche zu verstellen, um danach festzustellen, dass das Problem woanders liegt.
Gruß
DivideByZero
Wenn ich das nächste mal vor Ort bin, versuche ich am Switch einige Tests.
Einer wäre die Switche neu zu starten.
Einer wäre die Switche neu zu starten.
Einfacher ist es, die beiden Geräte an einen einfachen, nicht konfigurierbaren Switch zu hängen, sonst nichts, keine Verbindung zum sonstigen Netzwerk, dann noch ggf. einen Laptop dazu, und damit testen. Sinnvoller, als an den Switchen alles mögliche zu verstellen, um danach festzustellen, dass das Problem woanders liegt.
Gruß
DivideByZero
Er muss ja nichts verstellen um zu gucken ob die Mac im Arp Cache ist und bleibt.
Ping ist noch mal ein anderes Thema.
Immer der Reihe nach.
Ping ist noch mal ein anderes Thema.
Immer der Reihe nach.
Moin,
Ich frage mal vorsichtig:
TCP 502 ist doch Modbus!?
RS485 wäre zudem Modbus RTU
Und wie soll denn die RS485 eine IP bekommen und dann obendrein ne MAC in den ARP-Tabellen der Switche anlegen?
Und dass beide Interfaces, NIC und RS485, eine IP im selben Netz haben, ist sicherlich auch nicht förderlich.
BTW: ist dieses Modul verbaut?
Was soll die Kiste inhaltlich eigentlich machen?
Eckdaten:
. - BeagleBone Black (BBB): IP 192.168.1.246
- RS485: IP 192.168.1.247
- Port: TCP 502
. - BeagleBone Black (BBB): IP 192.168.1.246
- RS485: IP 192.168.1.247
- Port: TCP 502
Ich frage mal vorsichtig:
TCP 502 ist doch Modbus!?
RS485 wäre zudem Modbus RTU
Und wie soll denn die RS485 eine IP bekommen und dann obendrein ne MAC in den ARP-Tabellen der Switche anlegen?
Und dass beide Interfaces, NIC und RS485, eine IP im selben Netz haben, ist sicherlich auch nicht förderlich.
BTW: ist dieses Modul verbaut?
Was soll die Kiste inhaltlich eigentlich machen?
Hallo,
Und was steht dann als Antwort da? Nichts? Ein Ping lebt ausschließlich von den Antworten...
Eine IP ist eindeutig und schon aufgelöst. Aufgelöster geht es nicht.
https://blog.globalping.io/how-to-read-ping-results-a-beginners-guide/
https://www.kentik.com/kentipedia/ping-command-in-network-troubleshootin ...
Gruss,
Peter
Und was steht dann als Antwort da? Nichts? Ein Ping lebt ausschließlich von den Antworten...
Ein Blick beim BBB ins ARP zeigte das er die IP nicht auflösen konnte.
Und in was soll eine IP aufgelöst werden? Eine Super-IP? In Marmelade? Oder meintest du das dein arp -a dir keine passende IP und mac (Physische Adresse) nannte?Eine IP ist eindeutig und schon aufgelöst. Aufgelöster geht es nicht.
Einer wäre die Switche neu zu starten.
Aber vorher schauen was in deren Logs drin steht, deren arp Tabellen etc. Und auch mit einen Kabelhai mal schauen. Ein Tracert hilft dir auch den weg der Pings zu klären. Evtl. ändert sich ja dort das Routing oder Knut Rupprecht schaltet dort Strom ab und Firewall ein. Welches Gerät gibt denn die letzte Meldung wenn der Ping nicht mehr Erfolgreich ist?https://blog.globalping.io/how-to-read-ping-results-a-beginners-guide/
https://www.kentik.com/kentipedia/ping-command-in-network-troubleshootin ...
Gruss,
Peter
🤷🫣
Hallo,
Wireshark zeigt es dir.
https://networkengineering.stackexchange.com/questions/77982/is-the-ping ...
Musst dann am Switch ein Port Mirror machen, dann kannste auch Pakete für andere als deine mac sehen.
https://forum.mikrotik.com/viewtopic.php?t=195968
https://www.reddit.com/r/mikrotik/comments/dghfa3/port_mirroring_for_wir ...
https://forum.mikrotik.com/viewtopic.php?t=58471
https://www.technicallyinsane.com/2015/10/mirroring-ports-on-mikrotik.ht ...
Gruss,
Peter
Wireshark zeigt es dir.
Wenn der BBB die IP nicht auflösen kann, kann er auch nichts absenden.
Du pingst die IP, der Switch dazwischen kann aber nur die mac, also schaut der in seine arp Tabelle an welchem Port er das Paket weiterleiten muss die du anpingen willst.Weiß jemand ob man den Traffic bei 2 Ports debuggen kann?
Klar kann ein Mikrotik das.Der Switch muss das an alle Ports, außer dem Source, weiterleiten:
https://networkengineering.stackexchange.com/questions/19881/pinging-bro ...https://networkengineering.stackexchange.com/questions/77982/is-the-ping ...
Heißt: mit Wireshark muss ich das ARP request auf meinem Windows PC sehen.
Nö, dein Switch gibt dir nur Pakete für deine NIC, und Broadcasts. Ein Switch ist kein Ethernet HubMusst dann am Switch ein Port Mirror machen, dann kannste auch Pakete für andere als deine mac sehen.
https://forum.mikrotik.com/viewtopic.php?t=195968
https://www.reddit.com/r/mikrotik/comments/dghfa3/port_mirroring_for_wir ...
https://forum.mikrotik.com/viewtopic.php?t=58471
https://www.technicallyinsane.com/2015/10/mirroring-ports-on-mikrotik.ht ...
Bin nimmer so up2date (nach einigen Jahrzenten): das ARP request wird als Broadcast geantwortet? oder als Unicast an die Source?
https://de.wikipedia.org/wiki/Ping_(Daten%C3%BCbertragung)* Der BBB sendet kein ARP
Wireshark sagt es dir* Der Mikrotik blockiert die ARP
Die Logs sagen es dir* das RS485 GW antwortet nicht auf die ARP
Wireshark sagt es dirIch meine die Antwort war "No Route to host".
Und wenn er die mac nicht kennt kann er auch nicht eine Route dafür anfordern. Ein Wireshark sagt es dir. Und dass so eine Antwort eher Blödsinn ist ist dir klar. Was genau ist als Antwort gekommen?Gruss,
Peter
Hallo,
https://www.elektronik-kompendium.de/sites/net/0901061.htm
https://www.security-insider.de/was-ist-arp-address-resolution-protocol- ...
https://www.fortinet.com/de/resources/cyberglossary/what-is-arp
https://en.wikipedia.org/wiki/Address_Resolution_Protocol
https://blog.it-planet.com/switch-vs-hub-vs-router-wesentliche-unterschi ...
https://www.msxfaq.de/tools/3rdparty/portmirroring.htm
Gruss,
Peter
Zitat von @Fohnbit:
Ich hoffe ich beleidige sich jetzt nicht, aber dir scheinen die Basics zu fehlen.
sich == dich, oder? NöIch hoffe ich beleidige sich jetzt nicht, aber dir scheinen die Basics zu fehlen.
https://www.elektronik-kompendium.de/sites/net/0901061.htm
https://www.security-insider.de/was-ist-arp-address-resolution-protocol- ...
https://www.fortinet.com/de/resources/cyberglossary/what-is-arp
https://en.wikipedia.org/wiki/Address_Resolution_Protocol
https://blog.it-planet.com/switch-vs-hub-vs-router-wesentliche-unterschi ...
https://www.msxfaq.de/tools/3rdparty/portmirroring.htm
Gruss,
Peter
Mit dem ARP Ablauf in einem L2 Netz hat @Fohnbit schon Recht, das ist korrekt beschrieben!
Was man sich die ganze Zeit fragt ist warum der TO nicht schlicht und einfach einmal einen Wireshark zur Hand nimmt und sich den ARP Prozess beidseitig genau ansiehst?
So klärt man im Handumdrehen wasserdicht ob der ARP Prozess sauber auf beiden Enden abläuft ohne wild herumzuspekulieren!
Sieht man sich dann noch die Mac Adress Forwarding Tabelle der beteiligten Switches an verifiziert man zusätzlich das diese die entsprechenden Endgeräte Mac Adressen kennen und die entsprechenden Forwarding Ports über welche sie diese gelernt haben.
Mit aktueller Firmware kann man zu fast 100% ausschliessen das der Switch ein Problem damit hat, denn so ein gravierender Fehler würde ja erwartungsgemäß dann alle Endgeräte im Netz betreffen!
Diese Annahme geht natürlich davon aus das die IP Adressvergabe saube rund korrekt ist und es z.B. keine Doppelvergabe durch sich überschneidende DHCP Pooladressen mit statischen oder andere grundlegende IP Adressierungsfehler im Netz gibt!
Beispiel eines Bilderbuch ARP Requests und entsprechender Antwort:
Fazit:
Wireshark zur Hand nehmen und dem Problem sinnvoll und strategisch auf den Grund gehen anstatt im freien Fall rumzuraten und zu spekulieren. Ist im Endeffekt zielführender! Kommt ein Administrator auch mit dem gesunden IT Verstand drauf...
Hilfreiche Tips für den Umgang mit dem Kabelhai:
https://www.heise.de/ratgeber/Fehler-erschnueffeln-221587.html
https://www.heise.de/ratgeber/LAN-Monitoring-Spiegelports-von-Switches-n ...
Alternativ kann man bei Mikrotik Switches auch den eingebauten Wireshark mit der Torch Funktion nutzen. Genug Tools also um alles sinnvoll und zielführend zu troubleshooten.
Im lokalen Netzwerk findet keine Kommunikation über IP statt.
Nicht ganz richtig, denn auch lokale Geräte benötigen zuallererst einmal ein gültige IP Adresse. Ohne die kann auch ARP nicht laufen. Eine korrekt vergebene IP käme also noch vor a.) ansonsten ist das alles richtig.ob die Mac im Arp Cache ist und bleibt.
Wenn es der Cache ist betrifft es ja einzig nur die Endgeräte sofern das Switchnetz eine dummes, flaches Layer 2 Netz ist.Was man sich die ganze Zeit fragt ist warum der TO nicht schlicht und einfach einmal einen Wireshark zur Hand nimmt und sich den ARP Prozess beidseitig genau ansiehst?
So klärt man im Handumdrehen wasserdicht ob der ARP Prozess sauber auf beiden Enden abläuft ohne wild herumzuspekulieren!
Sieht man sich dann noch die Mac Adress Forwarding Tabelle der beteiligten Switches an verifiziert man zusätzlich das diese die entsprechenden Endgeräte Mac Adressen kennen und die entsprechenden Forwarding Ports über welche sie diese gelernt haben.
Mit aktueller Firmware kann man zu fast 100% ausschliessen das der Switch ein Problem damit hat, denn so ein gravierender Fehler würde ja erwartungsgemäß dann alle Endgeräte im Netz betreffen!
Diese Annahme geht natürlich davon aus das die IP Adressvergabe saube rund korrekt ist und es z.B. keine Doppelvergabe durch sich überschneidende DHCP Pooladressen mit statischen oder andere grundlegende IP Adressierungsfehler im Netz gibt!
Beispiel eines Bilderbuch ARP Requests und entsprechender Antwort:
Fazit:
Wireshark zur Hand nehmen und dem Problem sinnvoll und strategisch auf den Grund gehen anstatt im freien Fall rumzuraten und zu spekulieren. Ist im Endeffekt zielführender! Kommt ein Administrator auch mit dem gesunden IT Verstand drauf...
Hilfreiche Tips für den Umgang mit dem Kabelhai:
https://www.heise.de/ratgeber/Fehler-erschnueffeln-221587.html
https://www.heise.de/ratgeber/LAN-Monitoring-Spiegelports-von-Switches-n ...
Alternativ kann man bei Mikrotik Switches auch den eingebauten Wireshark mit der Torch Funktion nutzen. Genug Tools also um alles sinnvoll und zielführend zu troubleshooten.
Ich frage mich ja immernoch, wie der TO es schaffen will, über Erhernet-Netzwerke (RJ45, 4 bzw. 8 adrig) über Switche hinweg eine RS485-Schnittstelle (2adrig) zu erreichen. Und auch, wie ich einer RS485-Schnittstelle eine IP geben kann.
Das sind doch physisch völlig verschiedene Medien.
@to welche IP versuchst du von wo nach wo zu erreichen?
Pingst du die 19.2.168.1.246?
Das sind doch physisch völlig verschiedene Medien.
@to welche IP versuchst du von wo nach wo zu erreichen?
Pingst du die 19.2.168.1.246?
Versteht man es richtig ist das vermutlich sowas wie ein Gateway. Vergleichbar z.B. mit einem Terminalserver auf dem man ein Telnet ausführt und der dann mit einer seriellen Schnittstelle weiter macht wie es z.B. HIER am Beispiel mit einem RasPi und einer seriellen RS-232 Schnittstelle beschrieben ist.
Zitat von @Fohnbit:
@em-pie Dir sind derartige Gateways nicht bekannt?: https://www.waveshare.com/wiki/RS485_TO_ETH_(B)
Dass du ein Gateway einsetzt, um von Ethernet auf RS485 umzusetzen, habe ich hier nicht aufgefasst (vielleicht auch überlesen...)@em-pie Dir sind derartige Gateways nicht bekannt?: https://www.waveshare.com/wiki/RS485_TO_ETH_(B)
Ich bin davon ausgegangen, dass du das o. g. BBB hast, bei dem unten ein Ethernet-Interface steckt und oben die 3 Pins für RS485 (Tx, Rx, Schirm) - das BBB quasi dein "Medienkonverter" ist. Und nun versuchst du, die RS485-Seite anzupingen, obwohl das Netzwerkkabel im RJ45-Port mit der IP 192.168.1.246 steckt.
Mit solchen Gateways arbeiten wir hier sehr viel - i. d. R. um von Modbus TCP auf Modbus RTU (RS485/ 232) oder MBus zu wechseln - dabei haben die Gateways (von ADFweb) "nur" eine IP über die sie aus dem Ethernet-Netzwerk erreichbar sind. das RS485/ 232 Interface hat logischerweise keine IP. Eine Software übernimmt dann das Mapping/ Umsetzen der Protokolle.
wird das ARP Broadcast request nicht mit einem ARP Unicast beantwortet?
Das ist richtig und erkennst du ja auch selber am o.a. Wireshark Screenshot! Wenn du den Kabelhai temporär nicht nutzen kannst dann nimmst du halt ein onboard Tool wie das bekannte tcpdump dafür. Auf dem BBB wird ja sicher etwas unixoides werkeln, oder?!
Ein tcpdump -i eth0 arp auf dem BBB erreicht genau das gleiche wie der o.a. Screenshot. Und...du siehst dann auch gleich den Unicast Reply ohne Mirrorport oder Snifferbridge.
Torch oder das Sniffer Tool auf dem Mikrotik kann das auch. Siehe unten...
Mikrotik kann von Haus aus sniffen
Hier mal für schnelle Debuggings auf der Konsole für einen Port/Interface und arp traffic ...
Kann man aber genauso gut auf direkt an eine offene Wireshark instanz "streamen" mit dem Streaming feature, oder auch in eine Datei capturen die du dann vom Mikrotik runterladen und mit Wireshark öffnen kannst.
Lesen und Lernen
Mikrotik - Packet Sniffer
Gruß catrell
Hier mal für schnelle Debuggings auf der Konsole für einen Port/Interface und arp traffic ...
/tool sniffer quick interface=ether3 mac-protocol=arp
Lesen und Lernen
Mikrotik - Packet Sniffer
Gruß catrell
Wireshark zeigt mir die ARP requests vom BBB an:
Hast du den Wireshark an einem Port der den Client Anschlussport oder den BBB Port spiegelt??Ohne einen Spiegelport kannst du es natürlich nicht sehen da der Reply ein Unicast ist. Den Request siehst du ja immer, egal wo, da Broadcast und der wird in der L2 Domain überallhin geflutet.
https://www.youtube.com/watch?v=Fn4jEPHYPew
oder alternativ ohne Mirror
https://help.mikrotik.com/docs/spaces/ROS/pages/8323088/Packet+Sniffer
https://mikrotik-blog.com/mikrotik-datenanalyse-mit-wireshark
Auch ohne Holländisch Kenntnisse ist das Mirrorport Setup intuitiv.
Idealerweise spiegelst du den BBB Port (Gateway) auf den Wireshark, denn dort kannst du dann sowohl den eingehenden ARP Request des Clients sehen als auch den Reply des BBB. Wenn der keinen Reply sendet hast du den bösen Buhmann. Wenn der sendet aber es kommt am Client nicht an auch. Letzteres dürfte aber ziemlich unwahrscheinlich sein.
Nur zur Sicherheit nebenbei gefragt: Denn Mikrotik hast du auf dem aktuellsten RouterOS und auch den Bootloader unter System -> Routerboard auf diese gleiche Version upgegradet??
Bootloader nicht explizit. Schau ich nochmal an.
Ein Fehler! Das sollte immer gemacht werden!Das Problem besteht auch, wenn ich einen einfachen 08/15 Switch zwischen stecke.
Oha, das schliesst dann wie erwartet deine bestehende Switch Infrastruktur aus. Du kannst das ja auch mal querchecken wenn du einen Raspberry Pi aus der Bastelschublade anschliesst. Auch der dürfte fehlerfrei funktionieren. Womit dann klar ist das der BBB der Buhmann ist.Sucht man im Internet (Englisch) nach diesen BBB Problematiken findet man eine Menge Treffer.
Zitat von @Fohnbit:
Es wäre schön wenn man physikalisch Unabhängig den kompletten Traffic eines Ports in Wireshark sehen könnte.
Einfach in Wireshark den Capture Filter auf den DST- Port setzen an den du streamst, schon ist das nur der Traffic der an dich vom Mikrotik gestreamt wird 😉.Es wäre schön wenn man physikalisch Unabhängig den kompletten Traffic eines Ports in Wireshark sehen könnte.
Jedoch kann ich diese in eine Datei speichern und dann in Wireshark öffnen?
Klar einfach nen Dateinamen am Mikrotik definieren und maximale Größe festlegen, danach das File per FTP/SFTP auf deinen Wireshark Rechner kopieren (vorher sniffer stoppen)./tool sniffer set file-name=capture.cap
/tool sniffer set file-limit=10M