Kann man dieselbe SSID mehreren WiFi APs geben?
Ein GuteFrage.net Benutzer meinte gestern, dass es Unfug sei, wenn man dieselbe SSID (und Verschlüsselung und Passwort) für verschiedene APs verwendet. Ich nehme einmal an, dass die APs unterschiedliche Kanäle bekommen. Außerdem haben die APs ein 40Gigabit Ethernet (fiber) Anschluss und einen Ethernet Switch für Kabelverbindungen in die Wohnungen...
Ich stelle mir vor, dass man so ein mehrstöckiges Haus mit minimaler Sendeleistung und maximaler Bandbreite mit Internet versorgen könnte. Man kann sogar von ganz oben nach ganz unten gehen, ohne dass die Internetverbindung abreißt, und ohne dass man vom DHCP eine andere IP bekommt, weil der DHCP gar nichts davon mitbekommt... Also wenn WiFi geschickt entworfen wurde, dann müsste es doch gehen... Oder?
Das Ergebnis basiert auf 4 Abstimmungen
4 Antworten
Natürlich geht das.
Für dein beschriebenes Szenario wäre es zwar optimal, wenn die APs ein s.g. "Mesh" unterstützen, aber zur Not geht's auch so.
P.S.: Wer auch immer der besagte Nutzer gewesen sein mag, er hat offensichtlich keine Ahnung wovon er redet...
die APs haben alle ein 40gigabit Ethernet... mit Glasfaser...
Ein GuteFrage.net Benutzer meinte gestern, dass es Unfug sei, wenn man dieselbe SSID (und Verschlüsselung und Passwort) für verschiedene APs verwendet.
Dieser sogenannte Unfug ist gängige Praxis. So wechselt das Endgerät selbstständig die Funkzelle (Roaming), ohne dass der Benutzer interagieren muss. Jedes vernünftige Netzwerk, welches mehr als einen AP verwendet, ist so aufgebaut - es sei denn, triftige Gründe sprechen dagegen.
Ich nehme einmal an, dass die APs unterschiedliche Kanäle bekommen.
Richtig, das ist ein Muss. In Unternehmensumgebungen verwendet man Controller, die die APs steuern. Dann passiert das automatisch.
Außerdem haben die APs ein 40Gigabit Ethernet (fiber) Anschluss
Ich kenne keinen AP mit derartigen Anschlüssen. Die meisten APs haben Kuperanschlüsse, damit man sie per PoE mit Strom versorgen kann. Neben Gigabit-Anschlüssen kommt zunehmend Multigigabit-Ethernet zum Einsatz, hier hat man in der Regel 2,5, 5 oder 10 Gbit/s auf der bestehenden Twisted-Pair-Verkabelung zur Verfügung.
und ohne dass man vom DHCP eine andere IP bekommt, weil der DHCP gar nichts davon mitbekommt...
Ja, möglich ist das. Wobei man in größeren Umgebungen durchaus auch mit mehreren IP-Subnetzen und einer SSID arbeitet. Hier gibt es durchaus Möglichkeiten für sogenanntens Layer-3-Roaming.
Ich kenne keinen AP mit derartigen Anschlüssen.
ja... stimmt... wenn man ganz genau hinsieht, dann sind switch und AP unterschiedliche Geräte, die mit nem kurzen „B.2 CAT7“ Kabel verbunden sind...
Kann man natürlich (auf verschiedenen Kanälen) aber
- die APs müssen in einem gemeinsamen Netz sein. Sie brauchen eine entsprechende Konfiguration, um Roaming zu unterstützen
- IP-Adressen vergibt ein gemeinsamer DHCP (-Server)
- die Anmeldung erfolgt nicht auf den einzelnen APs, sondern auf einem gemeinsamen RADIUS-Server
Sobald man da anfängt, etwas zu "basteln" zieht man sich u.U. merkwürdige Effekte ins Netz obwohl es auf den ersten Blick aussieht, als wäre alles Ok.
die APs müssen in einem gemeinsamen Netz sein. Sie brauchen eine entsprechende Konfiguration, um Roaming zu unterstützen
Nein, nicht zwingend. Das kann auch IP-Netz-übergreifend funktionieren.
Das genau ist es, was ich meine mit "nicht basteln". Wenn das Netz wie oben beschrieben aufgebaut ist, dann ergibt das kein Problem, weil die Verbindung zwischen den APs sozusagen "gepingpongt" wird. Die Switche machen da das wenigste Problem.
Du scheinst etwas tiefer drinzustecken:
Die Verbindungen zu den Servern werden nicht auf der Switch/Hub-Ebene abgehandelt, sondern so ähnlich wie ein Gateway (eben die APs). Daher müssen sie Switche nicht umlernen (und ARP ist nicht erforderlich). Alle APs bekommen über den RADIUS die Anmeldedaten, daher erfolgt keine zusätzliche Anmeldung also ist auch das kein Problem. (Vielleicht etwas weniger verworren: der Pc verwendet den AP an dem er angemeldet ist als Gateway ins Netz). Deshalb ist es eben wichtig dass alle im gleichen Kontext (LAN) ohne Tricks liegen.
ok... also nehmen wir einmal an, dass da nur ein einziger Switch wäre, an dem AP1, AP2 und S (S ist z. B. ein WWW Server) hängen...
P wechselt von AP1 zu AP2...
wie lernt der switch, dass er die Antwort von S an den Port von AP2 schicken soll?
bekommt der switch also von AP1 einen Hinweis, dass P nicht mehr an AP1 hängt, sondern woanders? Dann bräuchte man doch ARP.... oder?
was meinst du mit „gepingpongt“?
mit einem Hub wäre es ganz leicht, weil dann ja AP1 und AP2 denselben traffic sehen und sich das rauspicken können, worum es geht...
ich gehe dabei davon aus, dass AP1 und AP2 wie eine bridge sind... sich nehmen also, was sie kriegen können, und leiten es dann weiter... ganz ohne routing Regeln... oder muss man die APs wie router sehen?
Ich zerlege die Frage mal
Teil 1: Muss der Switch umlernen, wenn P zwischen den APs wechselt. Antwort Nein
(übrigens: in diesem Beispiel ist es egal, ob Hub oder Switch verwendet wird)
P(an AP1) sendet ein IP-Paket an S(am Switch). Der Switch lernt die Route AP1<->S
P wechselt an AP2 und sendet wieder ein Paket
P(an AP2) sendet an S. Der Switch lernt (oder hat) die Router AP2<->S
P geht wieder zurück an AP1 => der Switch nimmt wieder die alte Route P-AP1.
Ein bisschen tiefer (wenn es dich interessiert):
wovon ich rede, sind IP Pakete auf Schicht 3 (ISO-OSI) die mal über den einen AP und mal über den anderen verschickt werden. Die IP-Pakete werden immer versandt SenderIP => EmpfängerIP
Du redest in diesem Fall von der Switch-Ebene, der arbeitet aber (erstmal) auf Schicht 2. Da laufen keine IP-Pakete, sondern Ethernet-Frames. Daher verwendet man da auch ARP/RARP, um die IP-Adressen einer MAC-Adresse zuzuordnen. Ich mache mal weiter unten was rein zum erklären (passt hier nicht). MAC-Pakete laufen immer SenderMAC => EmpfängerMAC.
Teil 2: Muss man AP wie Router / Bridges / Gateways sehen. Antwort: Ja. Die WLAN-Seite arbeitet eigentlich ähnlich einem Switch, während die IP-Seite ein Gateway ist.
Wenn man es ganz genau nähme, könnte man vielleicht den AP auch ein bisschen als WLAN-Switch sehen. Kannste mal ein bisschen dran kniffeln. Da kommen dann auch Themen wie CSMA/CA noch zum Tragen. Hat hier aber nix zu suchen.
P meldet sich an AP1 an. Dann hat er eine Schicht 2-Verbindung (daher auch z. B. MAC-Filter auf den APs). Genauso als wenn du ein Kabel reinstecken würdest (ist halt ein WLAN-Kabel).
Jetzt geht P an AP2 => du ziehst das WLAN-Kabel aus AP1 raus und steckst es in AP2 rein. Das fasst man unter dem WLAN-Roaming zusammen. Damit geht das nächste IP-Paket (NICHT MAC) über den AP2
Das Routing (ohne Regeln) wie du es nennst gibt es also. Allerdings ist da in den großen APs noch so eine Art Firewall mit Regeln drin (Beispiel Lancom) und die vermittelt nochmal. Bohre da nicht tiefer - das Handbuch zu Lancoms / Ciscos oder so hat jeweils über 1000 Seiten.
Teil 3: der PingPong - was ist das
Wenn ein PC Verbindung mit einem WLAN aufnimmt, bekommt er bei der Anmeldung einen Parameter ab (nicht Fritz oder so - die großen APs), der dem Client sagt, bis zu welcher Feldstärke er am AP "kleben" soll (wie lange er also nicht wechseln darf. Bekommt er da z. B. "80%", dann wird der PC versuchen, einen stärkeren AP (im gleichen Netz) zu finden, wenn er nur noch 80% Feldstärke empfängt. Je tiefer die Schwelle liegt, umso länger "klebt" er an seinem AP.
Warum ist das wichtig? Das hängt mit der Sende-(und Empfangs-) geschwindigkeit zusammen (NICHT MIT DER SENDELEISTUNG).
Kann ich zwar aufschreiben, aber ich glaube das ist nicht das Thema.
Wie versprochen Teil 4: das MAC-IP-Ding: stell dir einfach vor, das MAC-Paket ist ein Bus der feste Haltestellen abfährt (die Netzwerkkarten via Switche). Wenn ein Männchen (IP-Paket) von S zu P will, muss es IN einen Bus steigen (das MAC-Paket), wird dann vom Switch (Busbahnhof) verteilt und an die MAC von P gesendet und dort steigt das IP-Paket aus dem MAC-Paket AUS.
Ich hoffe, ich habe mich nicht verschrieben.
ok... noch 2 Sachen:
Und in dem kurzen Zeitraum, wo P nicht mehr an AP1 hängt: Was ist wenn S in dem Moment ein Paket an P abschickt? Was macht der switch dann? Merkt der das überhaupt, dass AP1 damit nichts mehr anfangen kann? Muss S seine Sendung also wiederholen?
Wieso Gateway, wenn der AP doch über Schicht 3 gar nicht hinauskommt? Besonders wenn er DHCP gar nicht macht, was na klar über Schicht 3 hinaus ginge...
Hi Luke - du gehst aber ganz schön ran - das ist jetzt aber tief
Teil A: Gateway: der AP ist kein echtes Gateway (das man z.B. mit ipconfig auslesen könnte). Er ist ein Gerät mit zwei Füßen: einer steht im LAN und einer im WLAN. Ich nenne mal die Schnittstellen eth0 und wlan0. Wenn da ein Paket durch soll, liegt da natürlich ein Routing innerhalb des AP vor, das wirst du von außen aber nicht sehen. Kommt also ein Paket auf wlan0 an, das ins LAN soll, dann wird es einfach auf die Schnittstelle eth0 geleitet (praktisch wie statisches Routing, ist aber nur eine Paket-Weiterleitung). Umgekehrt natürlich genauso.
Man muss das so sehen: eth0 und wlan0 (egal, welche Technik dahintersteht) sind Netzwerkschnittstellen auf Schicht 2 (Ethernet-Frames). Und da gibt es eben Weiterleitungstabellen. Das eigentliche Routing findet natürlich auf Schicht 3 (IP-Pakete) statt - das ist nicht die Aufgabe des AP.
Wenn der AP also ein Paket aus dem WLAN für S bekommt, leitet er das von wlan0 auf eth0 weiter und dann steht natürlich die MAC des AP im LAN als Absender-MAC drin. Das ist der Bus von vorhin. Innendrin sitzt das IP-Männchen mit der IP von P als Absender und der IP von S als Empfänger. Daran braucht also der AP nix mehr machen, als auszulesen (aus dem Männchen), an welche IP das Paket geht, und die setzt er dann (per ARP) um als Empfänger-MAC.
Nochmal bohren: jetzt sendet P ein Paket an Google. Natürlich hat auch der AP ein Standard-Gateway. Findet er also beim vorigen Mechanismus die IP nicht im lokalen Netz (liest er aus per Netzmaske). Er bekommt also das (Ethernet) Paket, packt das darin enthaltene IP-Paket aus, bastelt daraus ein neues MAC-Paket mit dem AbsenderMAC von eth0 und der EmpfängerMAC des Gateways und packt da das IP-Paket rein.
Teil B: DHCP: ist ein Protokoll, das für Schicht 2 und 3 zuständig ist.
Bildlich: P stellt sich auf eine Bierkiste und schreit "Ich will ne IP" (ARP-Broadcast). Das hören vielleicht mehrere DHCP-Server und antworten jeweils "Ich hab eine". Einen davon sucht sich P raus und schickt die Aufforderung zur Übergabe der IP-Adresse an den DHCP. Dann kommt ein bisschen Handshake usw., bei dem der DHCP aus seinem Pool an IP-Adressen eine der MAC des P zuweist. Die bleibt dann erstmal gesperrt (kein anderer kriegt sie). Deshalb: DHCP verwendet Schicht 2 um Schicht 3 Infos auszutauschen.
Ich verwende in den ganzen Beispielen explizit IPV4, weil IPV6 an dieser Stelle keinen solchen DHCP braucht - andere Baustelle.
Der Satz "Wieso Gateway.." muss ein bisschen anders formuliert werden: der AP leitet Schicht 2 Pakete zwischen seinen Schnittstellen, aber die enthalten innendrin als Payload eben IP-Pakete. Es stimmt schon: der AP ist kein Gateway, weil das eben auf Schicht 3 (und sonst nirgends) ist. Das sind eben die Transporttabellen auf Schicht 2 usw. die hier arbeiten.
Teil C: Jetzt wirds ein bisschen technisch ;-)
Wir reden über einen Zeitpunkt, an dem eines oder mehr Pakete verlorengehen in dem Moment, wo der AP gewechselt wird.
Nochmals ISO-OSI:
Schicht 2: Ethernet-Frame: wenn einer fehlt, dann ist er weg. Eine Hardware (MAC) redet mit einer anderen (MAC). Wenn was fehlt - Sorry
Schicht 3: IP-Paket: wenn eines fehlt, ist es auch weg. Hier werden einzelne Pakete zwischen zwei IP-Adressen ausgetauscht
jetzt kommt
Schicht 4: TCP-Paket (nicht verwechseln mit UDP - da geht das nicht, was jetzt kommt)
Hier geht es nicht darum, Pakete von A nach B zu schicken, sondern es werden Sitzungen (Sessions) aufgebaut.
Die TCP-Pakete werden IN die IP-Pakete verpackt, diese wiederum sind die Nutzlast (Payload) von Ethernet-Frames, die zwischen den Hardware-Schnittstellen laufen.
In den TCP-Paketen ist ein Zähler enthalten, der immer weiter hochzählt, also hat jedes Paket eine eindeutige Nummer. Und jetzt wird ein Schuh draus: wenn der Empfänger feststellt, dass ihm eines fehlt, dann fordert er es vom Absender NEU AN, sortiert es in der Reihenfolge der Paketzähler ein und dann reicht er es weiter an die höheren ISO-OSI-Schichten.
Heißt für das Beispiel: wenn dem Empfänger eines fehlt, fordert er es einfach wieder an. (retransmit)
Tief Luftholen: Wenn UDP verwendet wird (Streaming evtl und solche Sachen) dann gibt es den Zähler eben nicht.
Der Switch bekommt vom fehlenden Paket überhaupt nichts mit.
Ich hoffe, ich konnte helfen.
ok - soweit verstehe ich es...
allerdings: das mit DHCP und ISO/OSI ist nicht ganz so leicht... es ist ja eine Applikation und geht deswegen sogar bis rauf in die Schicht 7... wegen UDP aber mindestens bis Schicht 4... https://de.wikipedia.org/wiki/OSI-Modell
Lass dich nicht abschrecken - schau dir mal Mesh-WLAN an. Da hat man einen Weg gebaut, das ganze Werk, das du gerade gelesen hast, zu verstecken, damit die User nicht so tief ins Detail müssen. Die Basis ist eigentlich gleich, aber der RADIUS wird rausgelassen und der DHCP müsste auf dem Mesh-Master sitzen, dafür muss man ggf DHCP-Relays einsetzen. Viele WLAN-Kabel.
Anscheinend kostet das zwar einige Flocken, aber deutlich weniger als die großen WLANs (unseres ist in allen Niederlassungen in Europa verfügbar).
PS: Plag dich nicht in ISO-OSI rein, wenn du keinen fragen kannst - du kriegst graue Haare.
was passiert, wenn mein phone P von AP1 zu AP2 wechselt, während es mit server S redet, und dann antwortet S, bevor die switches gelernt haben, dass P jetzt an AP2 hängt...
Dann geht im schlimmsten Fall ein Päckchen verloren. Das merkst Du nicht.
oder löst AP1 dann eine ARP (who-has) Anfrage für die gleich gebliebene IP von P aus?
Dein, dafür gibt es keinen Anlass.
Es gibt aber auch die Möglichkeit, dass der Traffic zentral über einen Controller läuft. So sind die Clients, egal an welchem AP assoziiert, über genau einen Punkt zu erreichen, nämlich über den Controller. Der Controller weiß jederzeit, welcher Client an welchem AP hängt.
Wenn das Netz wie oben beschrieben aufgebaut ist, dann ergibt das kein Problem, weil die Verbindung zwischen den APs sozusagen "gepingpongt" wird.
Das kommt immer auf die Art der Implementierung an. Da gibt es viele Möglichkeiten, jeder Hersteller hat da so sein Konzept.
wie lernt der switch, dass er die Antwort von S an den Port von AP2 schicken soll?
Die Zeitspanne, in der ein PC keine Daten schickt, ist nicht allzu lang. Die Zeitspanne, in der der PC also am falschen Switchport bekannt ist, ist sehr kurz, wenn sie überhaupt messbar vorhanden ist. Ja, dann geht halt in dem Moment ein Paket verloren. Das ist überhaupt kein Problem. Die Zeitspanne für den Wechsel der Funkzelle ist unter Umständen länger. Auch da kann mal ein Paket verloren gehen. Am längsten benötigt in der Regel eine Authentisierung. Die muss in der WLAN-Umgebung durch bestimmte Mechanismen wie 802.11r minimiert werden.
oder muss man die APs wie router sehen?
Nein, der AP ist eine Bridge.
Teil 1: Muss der Switch umlernen, wenn P zwischen den APs wechselt. Antwort Nein
(übrigens: in diesem Beispiel ist es egal, ob Hub oder Switch verwendet wird)
Lass doch mal das Gerede vom Hub. Das interessiert nun wirklich niemanden. Die Dinger sind ausgestorben, seit Jahren. Im Szenario, wie LUKEars es beschrieben hat, ist die Frage erst einmal mit Ja zu beantworten. Der Switch sieht, wenn man Pech hat, für eine minimale Zeitspanne den PC an dem Port, an dem der initiale AP angeschlossen ist. Erst in dem Moment, wo der PC seinen ersten Frame aus der neuen Funkzelle gesendet hat, ist er für den Switch wieder erreichbar.
Aber ja, es gibt Implementierungen, wo der "neue" AP dem initialen AP mitteilt, dass er jetzt den PC bedient. Dann kann der initiale AP Daten, die er noch für den PC erhält, zum "neuen" AP senden.
Es gibt aber auch Implementierungen, wo der "neue" AP die Daten erst einmal über einen wie auch immer gearteten Tunnel zum initialen AP sendet, sodass der PC effektiv im Netz erscheint, als würde er immer noch am initialen AP assoziiert sein.
P(an AP1) sendet ein IP-Paket an S(am Switch).
Der AP sendet kein IP-Paket. Der AP senden einen Frame. Der AP interessiert sich nicht für IP.
Der Switch lernt die Route AP1<->S
Der Switch lernt keine Route. Routing ist Layer 3, wir reden hier von Layer 2 und MAC-Adressen.
P wechselt an AP2 und sendet wieder ein Paket
P(an AP2) sendet an S. Der Switch lernt (oder hat) die Router AP2<->S
Du hast das Szenario nicht verstanden: P an AP1 sendet an S. Jetzt wechselt P zu AP2. Erst jetzt sendet S die Antwort. Der Switch weiß deshalb noch nicht, dass P jetzt an AP2 hängt.
Teil 2: Muss man AP wie Router / Bridges / Gateways sehen. Antwort: Ja. Die WLAN-Seite arbeitet eigentlich ähnlich einem Switch, während die IP-Seite ein Gateway ist.
Ein AP hat keine "IP-Seite".
Da kommen dann auch Themen wie CSMA/CA noch zum Tragen.
CSMA/CA kommt nur im WLAN zum Tragen. Das ist hier nicht das Thema. Thema ist nicht die WLAN-Seite, sondern die Ethernet-Seite.
Jetzt geht P an AP2 => du ziehst das WLAN-Kabel aus AP1 raus und steckst es in AP2 rein. Das fasst man unter dem WLAN-Roaming zusammen. Damit geht das nächste IP-Paket (NICHT MAC)
Wie schaffst Du es, von "IP-Paket (nicht MAC)" zu reden? Jedes IP-Paket ist in einem WLAN-Frame (802.11) auf der Funkseite und in einen Ethernet-Frame (802.3 bzw. Ethernet II) eingepackt. Das kann man nicht trennen.
Allerdings ist da in den großen APs noch so eine Art Firewall mit Regeln drin (Beispiel Lancom) und die vermittelt nochmal. Bohre da nicht tiefer - das Handbuch zu Lancoms / Ciscos oder so hat jeweils über 1000 Seiten.
Mindestens die Ciscos vermitteln nicht, sie machen kein Routing. Das sind APs. Auch, wenn da eine Firewall integriert ist, wird daraus kein Router. Da wird nicht vermittelt, allenfalls gefiltert.
Wenn ein PC Verbindung mit einem WLAN aufnimmt, bekommt er bei der Anmeldung einen Parameter ab (nicht Fritz oder so - die großen APs), der dem Client sagt, bis zu welcher Feldstärke er am AP "kleben" soll (wie lange er also nicht wechseln darf.
Welchen Parameter/welchen Standard meinst Du da? Und meinst Du nicht, dass der Client das auch unterstützen muss?
Bekommt er da z. B. "80%",
80 Prozent von was?
dann wird der PC versuchen, einen stärkeren AP (im gleichen Netz) zu finden, wenn er nur noch 80% Feldstärke empfängt.
Zu diesem Mechanismus hätte ich gerne nähere Angaben. Die Benennung des Standards genügt mir.
Warum ist das wichtig? Das hängt mit der Sende-(und Empfangs-) geschwindigkeit zusammen (NICHT MIT DER SENDELEISTUNG).
Du verwechselst Geschwindigkeit mit Datenrate.
Wie versprochen Teil 4: das MAC-IP-Ding: stell dir einfach vor, das MAC-Paket
MAC Frame. Pakete sind IP. Ich bin da jetzt mal genau bis kleinlich, weil Du meiner Meinung nach einiges verwechselst.
allerdings: das mit DHCP und ISO/OSI ist nicht ganz so leicht... es ist ja eine Applikation und geht deswegen sogar bis rauf in die Schicht 7.
Da hast Du vollkommen Recht.
Lass dich nicht abschrecken - schau dir mal Mesh-WLAN an. Da hat man einen Weg gebaut, das ganze Werk, das du gerade gelesen hast, zu verstecken, damit die User nicht so tief ins Detail müssen.
Mesh hat mit Roaming nichts zu tun. Mesh ist lediglich der Aufbau eines Wireless-Backbones, wo keine Kabelverbindungen möglich sind oder unerwünscht sind. Natürlich muss im Mesh auch Roaming stattfinden. Roaming benötigst Du aber auch in einem Nicht-Mesh-WLAN, wo die APs klassisch per Kabel am Distribution System angebunden sind.
Die Basis ist eigentlich gleich, aber der RADIUS wird rausgelassen und der DHCP müsste auf dem Mesh-Master sitzen, dafür muss man ggf DHCP-Relays einsetzen.
Ein Relay benötigst Du nur, wenn der DHCP hinter einem Router steht und deshalb die Broadcasts nicht empfängt. Das Gateway in jedem IP-Netz wird deshalb als Relay konfiguriert. Da wir uns beim WLAN über eine Layer-2-Struktur unterhalten, ist das Thema DHCP-Relay davon völlig unabhängig.
PS: Plag dich nicht in ISO-OSI rein, wenn du keinen fragen kannst - du kriegst graue Haare.
Gut, dass ich die schon habe. Und gut, dass ich das ganze Zeug schon 25 Jahre verinnerlicht habe.
Dein, dafür gibt es keinen Anlass.
AP1 könnte den switch durch ARP/who-has zwingen, den neuen Port zu lernen und dann schickt AP1 eine Kopie des unzustellbaren Pakets erneut an den switch... oder geht das mit ARP nicht? man müsste irgendwie dem switch sagen, dass er in seiner ARP Tabelle diese eine MAC löschen soll...
@norbertk62 schrieb:
bastelt daraus ein neues MAC-Paket
Ist es normal, dass mein Phone mit der MAC seines wlan0 in meinem ganzen LAN auftaucht? Dann braucht der AP gar nicht auf Schicht 3 zu arbeiten und die IPs anzugucken... stimmt's?
AP1 könnte den switch durch ARP/who-has zwingen
Ja, das könnte man so machen. Ich kenne aber keine Implementierung, die so arbeitet. Die Frage ist auch, ob das so viel bringt. Die Zeitspanne zwischen "AP1 macht einen gratitious ARP" und "PC sendet nach dem Roaming seinen ersten Frame" ist äußerst kurz.
den neuen Port zu lernen und dann schickt AP1 eine Kopie des unzustellbaren Pakets erneut an den switch...
Wäre möglich. Ich kenne keine solche Implementierung, schließe aber nicht aus, dass es sie gibt. Das sind alles Dinge, die nicht standardisiert sind und proprietär von den Herstellern gelöst werden.
oder geht das mit ARP nicht? man müsste irgendwie dem switch sagen, dass er in seiner ARP Tabelle diese eine MAC löschen soll...
Der Switch hat keine ARP-Tabelle, sondern eine MAC-Adress-Tabelle. Wird eine MAC-Adresse auf einem anderen Port gesehen, wird sie vom ursprünglichen Port gelöscht.
Ist es normal, dass mein Phone mit der MAC seines wlan0 in meinem ganzen LAN auftaucht?
Ja, das ist normal. Das Phone sendet einen WLAN-Frame über die Luft. Dort steht seine eigene MAC-Adresse als Absender, die Ziel-MAC-Adresse und die MAC-Adresse des APs drin. Ein WLAN-Frame kann bis zu 4 MAC-Adressen enthalten, Minimum ist 3. Der AP bastelt aus dem WLAN-Frame (802.11) einen Ethernet-Frame. Dort steht die MAC-Adresse des Phones als Absender und die Ziel-MAC-Adresse drin.
Dann braucht der AP gar nicht auf Schicht 3 zu arbeiten und die IPs anzugucken... stimmt's?
Richtig. Ein AP arbeitet auch nicht auf Schicht 3. Die Ausführungen von norbertk62 sind schwerlich nachvollziebar.
WLAN Roaming oder Mesh https://www.elektronik-kompendium.de/sites/net/1407081.htm
was passiert, wenn mein phone P von AP1 zu AP2 wechselt, während es mit server S redet, und dann antwortet S, bevor die switches gelernt haben, dass P jetzt an AP2 hängt...
diese Antwort geht dann ja an AP1, weil dort die IP zuletzt gesehen wurde... ist dieses Paket dann verloren, oder löst AP1 dann eine ARP (who-has) Anfrage für die gleich gebliebene IP von P aus?