Pinkman
-
Gesamte Inhalte
3 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von Pinkman
-
-
Richtig. Aber der Client könnte einen Gratuitous ARP schicken - der Client bekommt ja mit wenn er wechselt.
Aber der Client ist nicht dazu verpflichtet einen Gratuitous ARP zu senden.
Normalerweise geht aber der Verkehr vom Client aus. Sprich der Switch lernt ziemlich schnell die neue MAC am anderen Port.
Normalerweise ja, wenn der Client aber nun auf eine Antwort vom Server wartet, und der Server aus anderen Gründen erst nach mehreren Sekunden mit seiner Verarbeitung fertig ist, dann kann dieses Szenario auftretten, TCP Session ist Established, alle Packete sind ACK, Client wartet auf Antwort vom Server, Client wechselt AP, Switch bekommt es nicht mit (wie auch).
Das ist ganz falsch. Das wäre ja für das Layer-2 Roaming tödlich, wenn der Client einen DHCP renew machen würde. Dann würden ja alle bestehenden TCP Verbindungen sowas von abbrechen.
Passiert doch bei einem Lease-Extend auch nicht! Da bleiben die TCP Verbindungen ja auch bestehen. :)
Der Client macht beim Roaming keinen neuen DHCP Request!
Natürlich müssen beide APs im selben Subnetz sein.
Dies deckt sich nicht mit meinen Beobachtungen. Ich sehe in DHCP Logs wie die Clients ihre Lease verlängern. Der Client muss doch überprüfen, ob er noch im gleichen Subnetz ist, und ob seine bisherige IP-Adresse weiterhin
gültig ist. Die APs wissen nichts von Layer 3, oder?
-
Hallo,
ich habe eine grundsätzliche Frage zum "Zusammenspiel" von AP(s) die an einem/mehreren Switch(en) angeschlossen sind. Leider konnte ich bisher nichts hierzu finden.
Wann kriegt der Switch mit (update der CAM-Table), dass sich am AP ein neuer Client angemeldet hat? Erst wenn der Client von sich aus Daten verschickt (z.B. DHCP, arp), oder forwardet der AP automatisch die MAC Adresse des neuen Clients zum Switch (gehe ich nicht von aus).
Hintergrund der Frage:
Annahme wir haben einen WLAN Client mit fest vorgegebener IP (kein DHCP),
und der Client wechselt den AP von AP1 zu AP2 (auf dem Switch von Port 1 auf Port2) und es fand in dieser Zeit kein IP Traffic vom Client zu einem Server statt, müsste die MAC Adresse des Clients auf dem Switch nicht immer noch dem Port 1 zugewiesen sein? Wenn der Server nun Daten zum Client senden möchte, würde der Switch die Daten zum falschen (alten ) Port forwarden.
Wenn der Client DHCP aktiviert hätte, dann würde er nach dem Roaming zum AP2 ein DHCP Request rausschicken, und der Switch meldet MAC Flapping...
Das ist zumindest mein Verständnis bisher.
Weiss jemand genaueres hierzu?
Vielen Dank
Access Point(s) am Switch
in Cisco Forum — Allgemein
Geschrieben
Ich spreche nicht von TCP Timeouts und Retransmissions. Der Fall sieht so aus, dass nach TCP alle bisher übertragenen Packete vollständig von beiden Seiten bestätigt worden sind. Es gibt also keinen Grund, dass der TCP-Stack des Clients eine Art TCP Keep-Alive macht. Der Client könnte also nur dann nachfragen, wenn die Applikation diese Logik implementiert hätte. Nach dem Motto ich warte nun schon so lange auf meine angeforderten Daten, da klopfe ich beim Server nocheinmal an was nun Sache ist. Ist aber hier nicht implementiert. Der Client verhält sich also still und wartet mit seiner offenen Verbindung auf Anweisungen vom Server.
Der Server ist immer noch mit seiner Verarbeitung beschäftigt (warum auch immer). Wenn der Client nun in dieser Zeit zu einem anderen AP wechselt,
und dabei immer noch von sich aus nichts verschickt hat, dann ist der Switch dahinter immer noch der Meinung, dass der Client auf dem alten AP zu erreichen ist. Jetzt schickt der Server aber Daten an eben diesen Client, aber sie können nicht zugestellt werden so lange seine MAC-Adresse immer noch dem falschen Switchport, alter AP, zugeordnet ist. Bei einer default mac table aging-time von 300sec ist das schon recht lang.
Ja das ist konkretes Problem. Ich habe leider keinen direkten Zugriff auf die Infrastruktur des Standortes. Die wird von einem anderen Dienstleister betreut. Ich betreue die Infrastruktur des Kunden an einem anderen Standort, wo wir solche Probleme nicht beobachten.
Bei uns sind die Clients mit DHCP konfiguriert, bei dem anderen Standort sind die Clients fest eingestellt.
Hey, Du hast mit DHCP Renew angefangen ;)
Ich sehe definitiv, dass die Clients, die per DHCP ihre IP beziehen, beim Roaming sofort einen DHCP Request (Lease extend) rausschicken.
Der Trace des Clients mit fester IP zeigt ausser dem Roaming mit den APs keine Aktivitäten bezüglich TCP/IP.
Ping wäre das denkbar falsche Vorgehen. Es ist im Prinzip so ähnlich wie ein Rechner der bootet. Der schickt ja auch, wenn seine Lease-Time noch nicht abgelaufen ist, eine Anfrage an den DHCP-Server ob seine alte IP-Adresse immer noch gültig ist, sprich bin ich immer noch im gleichen Subnetz, wie vor dem Herunterfahren. Das ist im Prinzip ein Lease-Extend. Genau das scheint auch beim Roaming stattzufinden. Zumindest mit den Geräten die bei uns im Einsatz sind.
Roamen in dem Sinne den AP zu wechseln schon, natürlich gehen dann alle Sessions fliegen, wenn man in einem anderen Netz gelandet ist.
Ist doch so ähnlich wie bei GSM, wenn ich in Grenznähe telefoniere und mein Telefon sich plötzlich doch lieber beim Anbieter des Nachbarlandes anmeldet.
Das überlebt auch kein aktives Gespräch.
Ja, ich habe die Cisco Doku dazu überflogen. Controller sind nicht im Einsatz, nur reine autonome APs.