13.11.2024, aktualisiert um 18:35:19 Uhr

899

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!

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 669471

Url: https://administrator.de/contentid/669471

Ausgedruckt am: 14.11.2024 um 01:11 Uhr

18 Kommentare

Neuester Kommentar

ARP geht ins leere?
Heißt die Switches kennen die Mac nicht mehr und dann auf einmal doch wieder?

Das hatte ich nicht überprüft. Am BBB konnte ich die IP nimmer pingen. Ein Blick beim BBB ins ARP zeigte das er die IP nicht auflösen konnte.

Nachdem ich die Weboberfläche oder einen Ping von meinem Windows PC machte, konnte der BBB die IP wieder erreichen.

Aber da ich vom Windows PC das RS485 Gateway erreichen konnte, muss der Switch ja die MAC davon kennen.

EDIT: Ich habe 2 dieser RS485 Gateway mit dem selben BBB bei mir am laufen und kann es nicht nachstellen. Meine Vermutung geht eben in die Richtung der Switche.

Wenn ich das nächste mal vor Ort bin, versuche ich am Switch einige Tests.
Einer wäre die Switche neu zu starten.

Ein Neustart des BBB und RS485 GW brachte ja keinen Erfolg

Moin,

Wenn ich das nächste mal vor Ort bin, versuche ich am Switch einige Tests.
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.

Moin,

Eckdaten:
. - 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?

Hi!

Es ist an sich ein ModBus RTU Gateway, aber Protokoll ist off. Dadurch reines RS485.

Das RS485 ist natürlich ein Gateway. Hat also einen Ethernet Anschluss und einen RS485 Anschluss.

Ist ein Connect für ekey Fingerprint

Und dass beide Interfaces, NIC und RS485, eine IP im selben Netz haben, ist sicherlich auch nicht förderlich.

Wie?

BTW: ist dieses Modul verbaut?

Nein, kein cape. Der BBB ist Standalone und das RS485 ist von WaveShare

Zitat von @DivideByZero:

Moin,

Wenn ich das nächste mal vor Ort bin, versuche ich am Switch einige Tests.
Einer wäre die Switche neu zu starten.

Ist auch eine Möglichkeit und schnell die Switche auszuschließen. Da alle IPs statisch sind, werde ich das testen.

Hallo,

Zitat von @Fohnbit:
Am BBB konnte ich die IP nimmer pingen.

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

Grundsätzlich wäre es praktisch zu wissen, wo die ARP Auflösung scheitert.
Wenn der BBB die IP nicht auflösen kann, kann er auch nichts absenden.

Hatte danach beide Geräte auf einen Mikrotik Switch gehängt. Weiß jemand ob man den Traffic bei 2 Ports debuggen kann?

Der BBB muss ja nach dem Neustart den ARP absenden. Der Switch muss das an alle Ports, außer dem Source, weiterleiten: Heißt: mit Wireshark muss ich das ARP request auf meinem Windows PC sehen.

Bin nimmer so up2date (nach einigen Jahrzenten): das ARP request wird als Broadcast geantwortet? oder als Unicast an die Source?

Ich meine es kann ja nur 3 Fehlermöglichkeiten geben:

Der BBB sendet kein ARP
Der Mikrotik blockiert die ARP
das RS485 GW antwortet nicht auf die ARP

Man sollte die Antwort eigentlich aus den Zeilen rauslesen können:
Natürlich das er die MAC Adresse nicht ermitteln kann. Geprüft via arp -a

aufgelöst ersetze mit MAC ermitteln. Das soll der Satz auch für dich wieder passen

🤷🫣

Zitat von @Pjordorf:
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?

Die Pings sind an sich egal. Das Problem ist das er die MAC Adresse nicht ermitteln kann. Also schlägt die ARP fehl.
Ich meine die Antwort war "No Route to host".

Ich bin morgen nochmal vor Ort und checke das genauer.

Aber solange er die MAC nicht ermitteln kann, erfolgt keinerlei Kommunikation im Ethernet. Kein Ping, HTML request oder was auch immer.

Man kann wohl den Mikrotik sniffen:
https://tojaj.com/packet-capture-from-mikrotik-to-wireshark/

Dann müsste ich ja sehen, wie die ARP zwischen den beiden Ports ablaufen.

Hat das schon einmal jemand am laufen gehabt?

Hallo,

Zitat von @Fohnbit:
Grundsätzlich wäre es praktisch zu wissen, wo die ARP Auflösung scheitert.

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 Hub
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 ...

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 dir

Ich 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

Zitat von @Pjordorf:
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.

Da liegst du aber weit daneben. Der Ablauf am Ethernet istt:
a) Bevor ein Host überhaupt eine Kommunikation startet, sendet er eine ARP raus, wenn ihm die MAC noch nicht bekannt ist
b) Der sich angesprochene Host antwortet auf das ARP request und sendet seine MAC retour
c) der host kennt nun die MAC und adressiert das Netzwerkpaket mit der MAC Adresse
d) der Switch kennt ebenso die MACs und leitet es entsprechend weiter

Im lokalen Netzwerk findet keine Kommunikation über IP statt. Das ist L3. Wir befinden uns auf L2

Zitat von @Pjordorf:
Was genau ist als Antwort gekommen?

Das habe ich dir geschrieben. Wenn ich es noch exakt wüsste, könnte ich es besser zitieren.
Morgen am Abend kann ich es erneut testen

Zitat von @Pjordorf:

Heißt: mit Wireshark muss ich das ARP request auf meinem Windows PC sehen.

Ich hoffe ich beleidige sich jetzt nicht, aber dir scheinen die Basics zu fehlen.

Natürlich sehe ich die ARP request von jedem Host im Netzwerk. Dieser werden als Broadcast gesendet und jeder bekommt die!