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.Code
Display MoreUSUYQ01-STA003# sh arp IP ARP table IP Address MAC Address Type Port --------------- ----------------- ------- ---- 10.241.xxx.xxx 001b17-xxxxxx dynamic Trk2 USUYQ01-STA003# sh mac-address Status and Counters - Port Address Table MAC Address Port VLAN ----------------- ------------------------------- ---- 001b17-xxxxxx Trk2 100 2cea7f-363846 Trk112 100 2cea7f-36386b Trk102 100 381428-72cfee Trk2 100 381428-aa9d20 Trk2 100 908d6e-3eaa1c Trk2 100 98e743-de0c8c Trk2 100 a0cec8-ff9c7a Trk2 100 a0cec8-ff9cbc Trk32 100 d8d090-5abf03 Trk2 100 001b17-xxxxxx Trk2 101 005056-b78b70 Trk2 101 245ebe-3c5d6f Trk2 101 4cd98f-cb2385 Trk2 101 4cd98f-cc9741 Trk2 101 001b17-xxxxxx Trk2 150 9c32ce-01aa86 Trk2 150 001b17-xxxxxx Trk2 300 14f6d8-dde208 Trk2 300 2c6dc1-44e0c1 Trk2 300 4a44d9-65204f Trk2 300 50eb71-5a2733 Trk2 300 68545a-5de9b3 Trk2 300 72c819-4fe82a Trk2 300 965f58-4c6d25 Trk2 300 a6e576-9957d5 Trk2 300 c8cb9e-072f88 Trk2 300 d203c9-3ee8fc Trk2 300 de7c79-1c47e8 Trk2 300 001b17-xxxxxx Trk2 400 001b17-xxxxxx Trk2 500 005056-b73430 Trk2 500 005056-b739af Trk2 500 005056-b752d5 Trk2 500 005056-b7c2c9 Trk2 500 001291-374c06 Trk112 501 001291-374c0c Trk112 501 001291-374c39 Trk112 501 001291-374c48 Trk112 501 001291-374c69 Trk112 501 001b17-xxxxxx Trk2 501 00d861-825a0a Trk112 501 00d861-825a12 Trk112 501 00d861-825a32 Trk123 501 00d861-825a50 Trk112 501 00d861-825a5e Trk112 501 00d861-825a6e Trk112 501 00d861-825a7a Trk2 501 00d861-825a8c Trk123 501 00d861-825a98 Trk123 501 00d861-825ab0 Trk112 501 00d861-825ab2 Trk112 501 00d861-825ab6 Trk112 501 00d861-825ab8 Trk123 501 204c03-565342 Trk2 501 001291-374c0f Trk82 502 001291-374c36 Trk82 502 001b17-xxxxxx Trk2 502 00d861-825a0d Trk82 502 00d861-825a24 Trk82 502 00d861-825a72 Trk82 502 00d861-825a78 Trk82 502 00d861-825ac4 Trk2 502 001291-374c09 Trk93 503 001291-374c12 Trk93 503 001291-374c15 Trk93 503 001291-374c18 Trk81 503 001291-374c2d Trk32 503 001291-374c33 Trk32 503 001b17-xxxxxx Trk2 503 003064-375612 Trk91 503 0050d6-11cf41 Trk93 503 00d861-825a20 Trk91 503 00d861-825a28 Trk101 503 00d861-825a2a Trk93 503 00d861-825a34 Trk31 503 00d861-825a3c Trk101 503 00d861-825a4a Trk102 503 00d861-825a66 Trk91 503 00d861-825a8a Trk102 503 00d861-825a90 Trk31 503 00d861-825a9e Trk93 503 00d861-825aa4 Trk102 503 00d861-825abc Trk2 503 00d861-825ac0 Trk81 503 00d861-825ac2 Trk93 503 00d861-825ace Trk32 503 204c03-565342 Trk2 503 88da1a-f95e1c Trk2 503 88da1a-fc1ba0 Trk2 503 001b17-xxxxxx Trk2 504 001b17-xxxxxx Trk2 900 204c03-565342 Trk2 900 c468d0-16a5f0 Trk32 900 c468d0-16ab4b Trk32 900 00005e-000101 Trk2 999 001b17-xxxxxx Trk2 999 004e35-c7af4a Trk101 999 004e35-c7b84a Trk82 999 004e35-c7bf68 Trk112 999 004e35-c7cb2c Trk123 999 004e35-c7d734 Trk102 999 204c03-565342 Trk2 999 204c03-56cac2 Trk2 999 883a30-3289a0 Trk93 999 883a30-360fa0 Trk102 999 883a30-365ee0 Trk101 999 883a30-366e80 Trk81 999 883a30-369da0 Trk123 999 883a30-36aea0 Trk112 999 883a30-36bca0 Trk31 999 883a30-36be40 Trk82 999 883a30-36ddc0 Trk112 999 883a30-36ecc0 Trk32 999 883a30-36ee00 Trk93 999 883a30-c22920 Trk91 999 883a30-c24960 Trk121 999 883a30-c259e0 Trk123 999 USUYQ01-STA003#
-
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
Code:~# cat /usr/local/bin/sendxarping #!/bin/sh -e # /usr/bin/arping -q -c 1 -b -A -I eth0 -s 192.168.178.13 255.255.255.255 > /dev/null 2>&1 # exit 0
Code
Display More:~# systemctl cat sendyarping # /etc/systemd/system/sendyarping.service [Unit] Description=send gratuitous arping Wants=network-online.target Requires=sys-subsystem-net-devices-eth0.device After=sys-subsystem-net-devices-eth0.device [Service] Type=oneshot WorkingDirectory=/usr/local/bin ExecStart=-/usr/local/bin/sendxarping RemainAfterExit=no StandardOutput=inherit StandardError=inherit LogLevelMax=0
Code
Display More:~# systemctl cat sendyarping.timer # /etc/systemd/system/sendyarping.timer [Unit] Description=send gratuitous arping [Timer] OnActiveSec=15 OnUnitActiveSec=5min [Install] WantedBy=multi-user.target
-
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