Nach dem Umzug einer Raspi an einen anderen Switch ist kein Zugriff moeglich

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Bei mir im Keller werkeln ein paar Raspis 7/24 vor sich hin. Sie sind an einen Switch angeschlossen der wiederum an mein HomeNetzwerk angeschlossen ist.

    Wenn mal groessere Aenderungsaktionen notwendig sind nehme ich die Raspi und connecte sie an einen anderen Switch der in meinem Arbeitszimmer steht. Danach kann ich nicht mehr an die Raspi connecten. Erst wenn ich den Switch im Keller neu starte kann ich ihn accessen. Ist nicht schlimm - ich weiss was ich beim Umzu tun muss - aber irgendwie moechte ich doch mal verstehen warum ich den Switch restarten muss :conf:

    Der Switch im Keller scheint die Mac der Raspi zu cachen und bei Anfragen zu adverticen. Somit muss ich den Cache durch einen Neustart des Switches loeschen und irgendeine Netzwerkanfrage landet dann auch beim neuen Switch und wird korrekt beantwortet.

    Kann mir jemand in 3 Saetzen erklaeren was da auf Netzwerkprotkollebene abgeht oder auch nur die Stichworte zum Suchen im Netz geben? Irgendwie bin ich nicht fuendig geworden :(

  • Nach dem Umzug einer Raspi an einen anderen Switch ist kein Zugriff moeglich? Schau mal ob du hier fündig wirst!

  • Danach kann ich nicht mehr an die Raspi connecten.

    Wie ist der arp- oder der neighbor-cache des Gerätes, mit dem Du auf den Raspi connecten willst?

    Der Switch im Keller scheint die Mac der Raspi zu cachen und bei Anfragen zu adverticen. Somit muss ich den Cache durch einen Neustart des Switches loeschen und irgendeine Netzwerkanfrage landet dann auch beim neuen Switch und wird korrekt beantwortet.

    Das verstehe ich jetzt nicht. Wie genau, ist diese Konstellation?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Kommt auf deine Hardware an.
    Bei Cisco ist die default mac-address-table aging time 300sec.
    Dein Switch im Keller sollte die MAC eigentlich direkt löschen wenn das Interface down geht.
    Ein Problem kann das geben wenn du mehrere Switche oder Geräte hast.

    So etwa :

    Switch1 ---- Switch3 ---- Switch2

    Wenn du nun den PI am Switch2 aus dem Interface ziehst löscht dieser die MAC Adresse. Der Switch3 jedoch nicht,
    Hängst du nun den PI an Switch1 wird dort das MAC-Table aktualisiert, nicht aber auf Switch3.
    Da musst du warten bis das mac-aging auf Switch 3 zuschlägt.

    In deinem Fall geht das Interface auf Switch 3 down sobald du Switch2 neu startest, damit verwirft Switch3 alle MAC die er auf dem Interface zu Switch2 kennt.

    Du bist wohl einfach zu schnell vom Keller im Arbeitszimmer :)


    EDIT : Ist ein wenig komplizierter, und es passiert viel mehr, aber ich wollte die Erklärung recht flach halten.

    Offizieller Schmier und Schmutzfink des Forum.
    Warum einfach wenn's auch schwer geht ?

    Kein Support per PN !
    Fragen bitte hier im Forum stellen. So hat jeder etwas davon.

  • Anbei mal eine Uebersicht was wo ueber einen Switch verbunden ist:

    Die Aktion ist: Umzug des Pi [1] vom UG in das OG [2]. und Zugriff vom Desktop [3]. Wenn ich den Switch [4] kurz vom Netz nehme kann ich mich auf auf die umgezogene Raspi [2] von Desktop [3] connecten.

    Vorher habe ich

    Code
    ip -s -s neigh flush all

    auf [3] eingegeben aber kein Erfolg gehabt.

    Wie Ihr seht sind da noch zwei weitere Switches involviert im OG: Ein 1G und ein 100M Switch.

    Ich weiss mittlerweile dass ich immer den Switch [4] Restarten muss wenn ich die Raspi ins OG umziehe. Somit ist das ganze kein Problem fuer mich. Nur dachte ich wenn ich den ARP Cache am Desktop [3] loesche reicht das aus. Aber leider offensichtlich nicht.

  • Hast du bei deinem PIs die IP-Adressen im PI fest vergeben?

    Denn eigentlich sollte der PI, wenn er ans Netz kommt, und die IP per DHCP bekommt,, 'laut' schreien "Her mit einer IP", was dann auch dem alten Switch zeigen sollte, dass er diese MAC aus seinem Cache löschen sollte.

    (Was für Switche setzt du ein? hast du eine Einstellung, die z.B. sicherstellen soll, dass kein fremdes System sich bei dir einschummelt?)

    Computer ..... grrrrrr

  • In dem Moment wo du den Pi vom Switch 4 trennst löscht dieser den PI aus seinem Mac Table.

    In Switch 3 zeigt die MAC jedoch noch auf das Interface zu Switch 4, hier fängt jetzt der Timer an zu laufen.

    Jetzt bootest Switch 4 du neu und das Interface auf Switch 3 zu 4 geht down, damit werden alle MAC gelöscht welche auf dem Switch 3 nach Switch 4 zeigen.

    Jedoch, in dem Moment wo du in Switch 2 den PI einsteckst und dieser einen Broadcast (z.B. Arp Request) raus schickt sollte auch Switch 3 mit bekommen das die MAC nicht mehr auf Switch 4 sondern jetzt auf Switch 3 zu finden ist.
    Keine Ahnung was da bei deiner Hardware schief läuft. Hast du VLAN konfiguriert und die nicht durchgehend auf allen Switchen ?



    Ich weis nicht was du für Hardware verwendest, aber die Aging Time bei Cisco und Aruba ist per default 5 min (300sek), danach wird die MAC aus dem MAC Table gelöscht wenn sie nicht aktualisiert wurde.

    EDIT : Deinem Linux Desktop sollte das egal sein, dort sollten alle MAC auf das IF zum Switch zeigen. (Anschauen mit Befehl : ip n)

    Offizieller Schmier und Schmutzfink des Forum.
    Warum einfach wenn's auch schwer geht ?

    Kein Support per PN !
    Fragen bitte hier im Forum stellen. So hat jeder etwas davon.

    Einmal editiert, zuletzt von Der_Imperator (24. Januar 2023 um 09:40)

  • und die IP per DHCP bekommt,

    Alle Raspis die im Keller am Switch [4] haengen sind Server und haben deshalb eine statische IP.

    Was für Switche setzt du ein?

    Consumer Switches von Netgear. [4] ist ein 1G 5 Port Switch, [3] ist ein 1G 8 Port Switch und Switch [2] zu den Raspis ist ein 100M 5 Port Switch. Falls die exakten Typen notwendig sein sollten kann ich die natuerlich nachliefern. Ich denke aber das ist wohl unnoetig. Da muesste ich erst in dunkle Ecken robben :lol:

    in dem Moment wo du in Switch 2 den PI einsteckst und dieser einen Broadcast (z.B. Arp Request) raus schickt

    Passiert das auch wenn eine statische IP genutzt wird?

    Ich weis nicht was du für Hardware verwendest, aber die Aging Time bei Cisco und Aruba ist per default 5 min (300sek), danach wird die MAC aus dem MAC Table gelöscht wenn sie nicht aktualisiert wurde.

    Solche edlen Teile habe ich nicht. Aber gehen wir mal davon aus dass es ebenso bei Netgear ist dann muesste ich mich also nur 5 Minuten gedulden und dann sollte mein Desktop zur umgezogenen Raspi finden? Ich haette aber gedacht dass ich das nicht machen muss und TCP/IP das automatisch erledigt. Deshalb meine Nachfrage hier in dem Thread.

  • Consumer Switches von Netgear. [4] ist ein 1G 5 Port Switch, [3] ist ein 1G 8 Port Switch und Switch [2] zu den Raspis ist ein 100M 5 Port Switch. Falls die exakten Typen notwendig sein sollten kann ich die natuerlich nachliefern. Ich denke aber das ist wohl unnoetig. Da muesste ich erst in dunkle Ecken robben

    Könntest du, wenn der/die PIs an Netz kommen, nicht ein skript starten, welches alle IPs im Netz einmal anpingt?

    Damit sollte dann jedem Switch bekannt sein, dass dieser PI wo anders hängt ;)

    (Methode Erlkönig: Und bist du nicht willig, dann brauch ich Gewalt ;) )

    Computer ..... grrrrrr

  • Könntest du, wenn der/die PIs an Netz kommen, nicht ein skript starten, welches alle IPs im Netz einmal anpingt?

    Wo ist der Unterschied zu dem:

    Zitat

    ... nehme ich die Raspi und connecte sie an einen anderen Switch der in meinem Arbeitszimmer steht. Danach kann ich nicht mehr an die Raspi connecten.

    ?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Danach kann ich nicht mehr an die Raspi connecten.

    Die IP-Adresse und die MAC-Adresse (d. h. deren Zuordnung) des PI ändern sich ja nicht und sind unabhängig davon an welchem Switch der PI verbunden/connected ist. Wenn Du den PI nicht per icmp und nicht per tcp erreichen kannst, dann versuch mal mit arp. Z. B.:

    Code
    sudo arp-scan -I <Interface> <IP-Adresse-PI>
    sudo arp-scan -I <Interface> -l # kleines L
    sudo arping -c 3 -I <Interface> <IP-Adresse-PI>

    EDIT:

    BTW: Der Unterschied zwischen arp-scan und arping ist der: Beim arp-scan kann auch ein evtl. vorhandener/erreichbarer arp-Server antworten, dem die Zuordnung von IP-Adresse und MAC-Adresse bekannt ist und beim arping wird nur das Gerät selber antworten.

    Es geht auch zu schauen, ob einer deiner Switches evtl. als "arp-Server" fungieren kann/darf.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    2 Mal editiert, zuletzt von rpi444 (24. Januar 2023 um 10:47)

  • dann versuch mal mit arp.

    Mache ich wenn ich die Raspi wieder nach unten bringe. Soweit ich mich erinnern kann passiert dasselbe auch auf diesem Weg. Ansonsten werde ich das noch mal testen wenn ich sie wieder nach oben umziehe.

    (Methode Erlkönig: Und bist du nicht willig, dann brauch ich Gewalt ;) )

    Das Script kann ich natuerlich fix schreiben falls die Befehle von rpi444 nicht die gewuenschte Wirkung zeigen :)

    Allerdings habe ich auch kein Problem den Switch einfach kurz zu restarten :lol:

    Mich interessiert primaer ob das works as designed ist von TCP/IP oder ein HW Problem meiner Consumer Switches ist.

  • Wo ist der Unterschied zu dem:

    ?


    Der Unterschied ist das im ersten der PI Pingt. Im zweiten der Linux desktop.

    So lange der PI durch die feste IP keine Verbindung mit einem anderen Netzwerkgerät aufnimmt sind wir noch auf Layer 2
    Da kennt halt nur der Switch an dem der PI direkt angeschlossen ist die MAC. Alle anderen haben die MAC noch im Mac-table gecached, und die zeigt eben auf das falsche Interface.

    Wenn der PI jetzt z.B. die FB pingt dann springen wir auf den Layer3, dann sollten alle Switche die MAC aktualisieren.
    Dann laufen ARP Requests.

    Sind so typische Fallen in Netzwerken wo man sich einen Wolf sucht.

    Offizieller Schmier und Schmutzfink des Forum.
    Warum einfach wenn's auch schwer geht ?

    Kein Support per PN !
    Fragen bitte hier im Forum stellen. So hat jeder etwas davon.

  • Mich interessiert primaer ob das works as designed ist von TCP/IP oder ein HW Problem meiner Consumer Switches ist.


    Das ist einfach ein Konstrukt aus den Funktionen des MAC Caching auf dem Switch und einem "stillen" host der angeschlossen wird.
    Stell den mal auf DHCP und schau ob es immer noch das Problem gibt. Ich denke nicht.

    Offizieller Schmier und Schmutzfink des Forum.
    Warum einfach wenn's auch schwer geht ?

    Kein Support per PN !
    Fragen bitte hier im Forum stellen. So hat jeder etwas davon.


  • Der Unterschied ist das im ersten der PI Pingt. Im zweiten der Linux desktop.

    OK, aber da gibt es was besseres als den Ping. Z. B. ein nicht angeforderter arp-reply vom PI:

    Code
    arping -q -c 2 -b -A -I <Interface> <statische-IP-Adresse>

    der allen erreichbaren Geräten , die MAC-Adresse und die IP-Adresse (d. h. deren Zuordnung mitteilt).

    So lange der PI durch die feste IP keine Verbindung mit einem anderen Netzwerkgerät aufnimmt sind wir noch auf Layer 2
    Da kennt halt nur der Switch an dem der PI direkt angeschlossen ist die MAC.

    Das ist von der Konfiguration des PI abhängig. Wenn er sich nach dem booten bzw. nach dem anschließen an einen Switch, immer mit einem arp-reply (gratuitous arp) meldet, sollten alle anderen Geräte/Switches Kenntnis vom PI (d. h. dessen MAC und IP) bekommen.

    Da kennt halt nur der Switch an dem der PI direkt angeschlossen ist die MAC.. Alle anderen haben die MAC noch im Mac-table gecached, und die zeigt eben auf das falsche Interface.

    Das verstehe ich jetzt nicht. Wie schaut so eine Mac-table aus und welches Interface ist der MAC-Adresse zugeordnet?

    EDIT:

    Gibt es evtl. ein "mac address based"-Routing, in einer Konstellation mit mehreren Switches? Dann ist evtl. immer ein Switch das gateway (... gekennzeichnet durch die MAC-Adresse dieses gateway-Switch?) für ein Gerät (hier der PI) an diesem Switch?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    Einmal editiert, zuletzt von rpi444 (24. Januar 2023 um 11:18)

  • Ok, Vielen Dank fuer Eure Kommentare.

    D.h. wenn ich das naechste Mal die Raspi umziehe werde ich folgende Dinge mal testen:

    1) 5 Minuten warten

    2) Die Befehle von rpi444 in #11auf dem Desktop

    3) Umgezogene Pi pingt die FB

    4) Die Raspi auf DHCP umstellen

    Ich ziehe jetzt nicht staendig die Raspi um. D.h. es wird ein wenig dauern bis ich die Testergebnisse hier berichten kann.

  • 1) 5 Minuten warten

    2) Die Befehle von rpi444 in #11auf dem Desktop

    BTW: Beim _übernächsten_ Mal/"Umziehen des PI", dann die Befehle arp-scan/arping ohne die 5 Minuten warten (d. h. sofort) ausführen.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Das verstehe ich jetzt nicht. Wie schaut so eine Mac-table aus und welches Interface ist der MAC-Adresse zugeordnet?


    Das ist ein MAC Table.
    Hier steht drin an welchem Interface sich die MAC befindet.
    So lange kein Update von irgendwoher kommt, zeigt die MAC halt auf das Interface bei Framp zum Switch im Keller und nicht zu dem Switch mit den PI.

    Offizieller Schmier und Schmutzfink des Forum.
    Warum einfach wenn's auch schwer geht ?

    Kein Support per PN !
    Fragen bitte hier im Forum stellen. So hat jeder etwas davon.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!