Genau das sehe ich auch als Ursache weshalb die Pi nicht erreichbar ist.
Nach dem Umzug einer Raspi an einen anderen Switch ist kein Zugriff moeglich
- framp
- Thread is marked as Resolved.
Registriere dich jetzt, um exklusive Vorteile zu genießen! Als registriertes Mitglied kannst du Inhalte herunterladen und profitierst von einem werbefreien Forum.
Mach mit und werde Teil unserer Community!
Mach mit und werde Teil unserer Community!
-
Schau mal ob du hier fündig wirst!
-
Das ist ein MAC Table.
Hier steht drin an welchem Interface sich die MAC befindet.OK, stellt sich die Frage, wie schnell ändern (passen an) die Switches ihre MAC-table wenn der PI jetzt an einem anderen Switch angeschlossen ist und sofort nach dem anschließen ein arp-reply raus sendet?
ich habe so einen arp-reply (gratuitous arp), der nur an die broadcast-MAC-Adresse (d. h. er wird von allen Geräten gesehenempfangen) gesendet wird, gesnifft:
Quote:~ #tcpdump -c 10 -vvveni urtwn0 arp and host 192.168.178.13
tcpdump: listening on urtwn0, link-type EN10MB
11:25:14.739730 b8:27:eb:62:3c:ae ff:ff:ff:ff:ff:ff 0806 60: arp reply 192.168.178.13 is-at b8:27:eb:62:3c:ae (b8:27:eb:62:3c:ae)
EDIT:
BTW Die source-MAC-Adresse die mit tcpdump gesehen wird, ist das immer die des PI oder bei Benutzung von Switches, die des Switches an dem der PI gerade angeschlossen ist?
-
Sobald ein Update kommt. Die MAC Einträge haben ja einen Timestamp. Kommt jetzt die MAC über einen anderen Port rein und die Zeit ist neuer wie der Timestamp aus dem Cache wird das gleich aktualisiert.
Macht der das zu oft dann hast du ein MAC ADDRESS FLAPPING im Log der Switche. Passiert öfters mal wenn ein Wifi Client sich nicht für einen AP entscheiden kann und zwischen zwei AP permanent wechselt,
Die MAC siehst du dann jeweils auf dem Port wo der AP angeschlossen ist.
Kann aber auch eine Fehlerhafte Netzwek Config sein, mit einem Loop über unterschiedliche VLAN.
Dann bekommt das Spanningtree das nicht mehr geregelt weil das nur in einem VLAN arbeitet. -
Gut erklärt, Unterschied zwischen Frames ( Layer2) und Paketen (Layer3)
Ethernet-Frames oder Ethernet-Pakete (netzpalaver.de) -
Gut erklärt, Unterschied zwischen Frames ( Layer2) und Paketen (Layer3)
ich meinte schon konkret in dem Fall (mit arp-reply), denn arp ist ein Schicht-2-/Layer2-Protokoll.
-
Ja, in dem Link ist aber auch die MAC gut erklärt.
Der Arp-Reply ist die Antwort auf ein Gratuitous ARP.
Da es als L2 Broadcast gesendet wird sollten jetzt alle Devices ihren ARP Cache und die MAC Tables aktualisieren.
Macht normalerweise jedes Gerät beim Booten.
Kann man manuell mit arping machen, hast du oben ja schon beschrieben.
Wenn du also im Layer2 bleibst, ist die Source MAC immer die des Client. Die wird durch einen Switch nicht verändert. -
Der Arp-Reply ist die Antwort auf ein Gratuitous ARP.
Nein, der "gratuitous arp" ist ein _nicht_ angeforderter gesendeter arp-reply und darauf wird nicht geantwortet, er wird nur zur Kenntnis genommen (d. h. die Zuordnung von IP-Adresse zu MAC-Adresse wird zur Kenntnis genommen, oder warum auch immer nicht zur Kenntnis genommen).
Ein "gratuitous arp" (d. h. ein nicht angeforderter aber gesendeter arp-reply) kann aber auch dazu führen, dass manche Geräte die "Interesse" am Gerät das den "gratuitous arp" gesendet hat, haben, werden dann evtl. noch von sich aus einen gezielten arp-request senden und nach der IP-Adresse des Gerätes fragen.
Macht normalerweise jedes Gerät beim Booten.
Ja, ... nur ganz selten kommt trotzdem (nach dem bzw. beim booten) auch mal ein _unvollständiger_ arp-cache (neighbor-cache) zustande.
EDIT:
BTW: Wenn man Redundanz will/braucht kann man in seiner Konstellation/Subnetz, auch einen arp-Server betreiben/benutzen. Der antwortet zusätzlich bzgl. Zuordnung von IP zu MAC, wenn die Anfrage (arp-request) an die broadcast-MAC-Adresse gesendet wird. Z. B.:
Code192.168.178.22 48:02:2a:17:62:b4 (b8:27:eb:75:36:60) B-Link Electronic Limited 192.168.178.22 48:02:2a:17:62:b4 B-Link Electronic Limited (DUP: 2)Die erste Antwort ist vom arp-Server und die 2. Antwort (DUP: 2) ist vom Gerät selber.
Aber hier geht es nicht um das Booten. Das source-Gerät ist schon länger gebootet und das destination-Gerät kann mal am Switch-X bzw. mal am Switch-Y sein und soll vom source-Gerät trotzdem immer sofort gefunden werden bzw. erreichbar sein.
-
Was willst du jetzt eigendlich ?
Was fragst du wenn du schon alles weißt ?
Geht es um Diskreditierung ?
Du wirfst hier auch etwas durcheinander, und zwar MAC Tables und ARP Cache, das sind zwei verschiedene Schuhe.
Die MAC Tables zeigen welche MAC auf welchem Interface zu finden ist, der ARP Cache welche IP zur MAC gehört
Das ARP Requests ein Update des MAC Table anstoßen ist klar, das macht jedes Paket und auch jeder Frame welcher in einen Switchport einläuft.
Ein "Gratuitous arp" ist kein Arp Reply sondern ein Arp Request, und zwar von der Sender IP welcher nach seiner eigenen IP fragt.
Normalerweise gibt es darauf keinen Reply, wenn doch dann ist die IP schon vergeben und du bekommst "Duplicate IP" Meldungen am Host und in den Logs vom Router.
Wird also zur Probe gemacht ob es die IP schon gibt und damit die MAC/IP im Netzwerk announced wird.
Einen Arp Reply wird als Antwort auf einen Arp Request gesendet.
Dieser auch nicht mehr als Broadcast sondern direkt an die MAC.
Das passiert wenn ein Device die IP eines anderen wissen möchte.
.
Wenn du Redundanz in den MAC Tables haben willst musst du die Aging Time herunter setzen oder bei HSRP/VRRP Routern wird durch Tracking die beteiligten Interfaces UP/Down genommen.
Also wenn R1 und R2 im HSRP/VRRP laufen und WAN an R1 ausfällt das wird auch das LAN an R1 down genommen, getracked, damit R2 die IP auf der WAN und LAN Seite übernehmen kann. Ob nun physisch oder nur das Line Protocol für das VLAN ist egal.
In dem Fall, Oh Wunder, sendet R2 auch Arp Requests, bzw Gratuitous ARP damit die ganze Layer2 Welt weis das die Virtuelle RouterIP jetzt hinter der MAC von RT2 und nicht mehr RT1 ist.
Dein ARP Server erreicht hier gar keine Redundanz!
Dem MAC Table des Switch ist dein Arp-Server scheiß egal.
Der Switch lernt das MAC-Table nur durch die Frames welche IN seine Interfaces laufen (und nur IN nicht OUT).
Im Spoiler mal das ARP und das MAC Table eines L2-Switch, den ARP Eintrag gibt es auch nur weil es ein gemanagter Switch ist. -
Was fragst du wenn du schon alles weißt ?
Ich weiß es eben nicht bzw. habe es aus deinen Beiträgen auch nicht richtig verstanden, und deshalb frage ich.
-
Das war keine Frage, du hast mir Widersprochen und erklärst es dann nicht korrekt und wiederholst den Fehler noch.
(Arp-Reply statt Arp-Request)
Also, was soll ich denken ?QuoteNein, der "gratuitous arp" ist ein _nicht_ angeforderter gesendeter arp-reply und darauf wird nicht geantwortet, er wird nur zur Kenntnis genommen (d. h. die Zuordnung von IP-Adresse zu MAC-Adresse wird zur Kenntnis genommen, oder warum auch immer nicht zur Kenntnis genommen).
Ein "gratuitous arp" (d. h. ein nicht angeforderter aber gesendeter arp-reply) kann aber auch dazu führen, dass manche Geräte die "Interesse" am Gerät das den "gratuitous arp" gesendet hat, haben, werden dann evtl. noch von sich aus einen gezielten arp-request senden und nach der IP-Adresse des Gerätes fragen.
-
Das war keine Frage, du hast mir Widersprochen und erklärst es dann nicht korrekt und wiederholst den Fehler noch.
(Arp-Reply statt Arp-Request)BTW: Das mit dem arp-reply ist so wie ich es geschildert habe, korrekt, ... denn ich habe so etwas hier im Einsatz.
Diese Diskussion hat sich ja nur als Alternative zum "Ping vom PI an alle Geräte in der Konstellation", entwickelt/ergeben und ist nicht die Kardinalfrage des Threads.
Es geht doch darum wie und ob man bei mehreren Switches, ein Gerät das an einen anderen Switch umgezogen ist, ohne das abwarten des mac-aging bzw. ohne die anderen Switches neu starten zu müssen, sofort erreichen kann?
-
BTW: Das mit dem arp-reply ist so wie ich es geschildert habe, korrekt, ... denn ich habe so etwas hier im Einsatz.
Diese Diskussion hat sich ja nur als Alternative zum "Ping vom PI an alle Geräte in der Konstellation", entwickelt/ergeben und ist nicht die Kardinalfrage des Threads.
Es geht doch darum wie und ob man bei mehreren Switches, ein Gerät das an einen anderen Switch umgezogen ist, ohne das abwarten des mac-aging bzw. ohne die anderen Switches neu starten zu müssen, sofort erreichen kann?
1. Ich diskutiere nicht mehr über das arp-reply. Du hast Recht, ich meine Ruhe.
2. Wenn das nicht sofort funktioniert muss es einen Grund haben.
Den Grund kennen wir hier nicht, die Switche haben keine Logs. Black-Box. Also in die Kristallkugel schauen.
Erfahrung sagt woran es liegen könnte und erklärt es auch logisch.
Framp will beim nächsten mal berichten, hat er noch nicht.
Also Abwarten.
Und damit beende ich diese Off Topic Diskussion und warte auf Framps input. -
Framp will beim nächsten mal berichten, hat er noch nicht.
Werde ich definitiv. Aber ich habe auch geschrieben es wird ein wenig dauern
Eigentlich wollte ich die Ergebniss von allen 4 Tests zusammen berichten.
Vielleicht doch schon mal kurz das Ergebnis von (4) (DHCP Nutzung):
Ich hatte einmal die Raspi von oben nach unten und wieder von unten nach oben umgezogen und beide Male musste ich nichts ausstoepseln. Das wunderte mich - bis ich feststellte dass der neue Server den ich mit neuem OS aufsetzen will per DHCP konfiguriert war. Muss er auch da der upzugradene Server eine statische IP hat und nicht beide Systeme mit derselben IP aktiv sein koennen. Somit stimmt Eure Vermutung dass der DHCP Request des umgezogenen Systems dafuer sorgt dass alle Systeme im Netz von dem neuen Standort wissen. Das ist fuer mich aber keine Option da ich normalerweise den Server von unten nach oben bringe denn unten ist er headless und in gewissen Faellen braucht man doch mal einen Bildschirm und eine Tastatur. Aber so wissen wir dass das Problem nur bei einer statischen IP auftritt.
-
Merkwuerdig
Ich habe jetzt eine andere Raspberry mit einem RaspbianOS lite befruchtet und eine statische IP konfiguriert. Dabei war sie oben angeschlossen. Dann runtergefahren und unten angeschlossen. ssh Zugriff funktioniert sofort vom Desktop. Dasselbe umgekehrt: ssh Zugriff funktioniert wieder sofort 
Ich werde denslben Test noch mal mit der Raspi durchfuehren mit der ich das Problem entdeckt habe. Offensichtlich ist sie irgendwie anders konfiguriert
-
2. Wenn das nicht sofort funktioniert muss es einen Grund haben.
Den Grund kennen wir hier nicht, die Switche haben keine Logs. Black-Box. Also in die Kristallkugel schauen.
Erfahrung sagt woran es liegen könnte und erklärt es auch logisch.Der Grund ist, dass der PI eine feste IP hat und sich deshalb beim Anstöpseln ins Netz nicht um eine IP-Adresse bemühen muss.
So ist er, bis er irgend ein Paket aussendet, für alle Switche (bis auf dem, an dem er hängt) 'noch' unsichtbar.
-
Im Worst Case einfach im Crontab @reboot ein ping -c 30 fritz.box>/dev/null
das sollte für den gewünschten Traffic sorgen.
Das kannst du evtl. auch über ein ifup Script machen. Hätte den Vorteil das es jedes mal startet wenn das Interface up geht.Nur damit hab ich mich das letzte mal vor Jahren beschäftigt, da gab es nix anderes als die /etc/network/interfaces und das init system.
Vielleicht jetzt über den systemd, aber da hab ich zu wenig Ahnung von.
Alternativ avahi installieren. Dieser ganze Bonjour Krempel sollte auch das gewünschte Ergebnis bringen.
PS: Hatte hier heute morgen einen Printserver, der hat per Default auch eine feste IP.
Das Ding war auch ganz ruhig wenn es gebootet hat, da war noch nicht mal eine MAC auf dem Switchport zu sehen obwohl der Switchport UP war.
Auch ein Kabel rein/raus entlockte dem nix, erst als ich die IP angesprochen hatte war die MAC auf dem Switchport zu sehen. -
Ich habe gerade den Server wieder unten angeschlossen. Morgen ziehe ich ihn wieder hoch. Ich hoffe dann tritt das Problem wieder auf denn mit dem anderen Server mit statischer IP hat ja alles geklappt. Schon komisch
Erst dann kann ich noch (1)-(3) testen. -
Ich hoffe dann tritt das Problem wieder auf ...
BTW: Mit einer timer-unit kann man ziemlich genau, nach dem Booten wenn das Interface gerade up ist, ein Paket aussenden lassen:
(tcpdump)
Code15:14:43.595359 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.178.13 is-at b8:27:eb:62:3c:ae, length 46(dmesg)
Code[Thu Jan 26 15:14:34 2023] bcmgenet fd580000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx -
Jetzt habe ich mal wieder Treppentiger gespielt und den Server umgezogen. Ich kann sofort wieder vom Desktop auf die Pi zugreifen
Mindestens 3 Mal ist es mir passiert dass ich ihn umgezogen habe - dann versucht habe vom Desktop auf die Pi zuzugreifen - und wieder in den keller gerannt bin um den Switch dort kurzzeitg zu restarten. Ich habe also nicht getraeumt. Warum ich das jetzt ploetzliche nicht reproduzieren kann ist mir schleierhaft
Ich koennte mir vorstellen dass meine parallelen OS Upgradebemuehungen vielleicht irgendwas in meinem Netz/den Switches oder der Fritzbox bewirkt haben. Ich hatte im OG eine andere Raspi mit einer anderen Mac Adresse, demselben Hostnamen und einer anderen dynamischen IP gestartet
Vermutlich muss ich mal einen Netzwerkreset durchfuehren und sowohl meine Fritzbox und alle drei Switches restarten damit saemtliche Caches geloescht sind um das Problem zu reproduzieren.
Das wird natuerlich wieder etwas dauern bis ich einen passenden Moment dafuer finde ...
-
Da ich den Server jetzt in mein DMZ umstoepseln will habe ihn zum Testen wieder nach oben umgezogen.
ETH Kabel eingesteckt und gebootet. An der Raspi leuchteten die ETH Lampen - am Switch nicht
Kabel am Switch noch mal rausgezogen und wieder reingesteckt - dann blikende Lampen - und es war sofort Zugriff per ssh moeglich Das ganze ist weiterhin mysterioes - eber ich gebe es jetzt auf die Ursache zu finden. Mir ist noch aufgefallen dass ich iptable Rules auf dem Server aktiv habe. Ist ein Server der im Internet haengt und per iptables Zugriff auf mein Homenetz unterbindet. Das sind aber Layer3 und nicht Layer2 Rules und sollten fuer mich keinen Einfluss haben.
Anyhow - es war fuer mich und hoffentlich auch fuer Euch eine interessante Threaddiskussion. Vielen Dank fuer Eure Workaroundvorschlaege und Hilfe bei der Ursachenforschung
