Access Point(s) am Switch

[Pinkman 10]

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

[Nightwalker_z 10]

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).

Der AP macht erst mal gar nichts. Der Client schickt normalerweise einen Gratuitous ARP - das hängt aber vom Supplicant ab.

 

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.

 

Richtig. Aber der Client könnte einen Gratuitous ARP schicken - der Client bekommt ja mit wenn er wechselt. Schließlich ist ja das Roaming eine reine Clientsache. Normalerweise geht aber der Verkehr vom Client aus. Sprich der Switch lernt ziemlich schnell die neue MAC am anderen Port.

 

 

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 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.

Der Client macht beim Roaming keinen neuen DHCP Request!

Natürlich müssen beide APs im selben Subnetz sein.

[Otaku19 33]

also sollte man auf den beteiligten Switches gratuitous ARP nicht deaktivieren ? das geht ja nur global für den ganzen Switch

[Pinkman 10]

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?

[blackbox 10]

Hi,

 

ein DHCP Renew löscht im gegensatz zum "Lease-Extend" die laufende IP und holt sich eine neue - im schlimmstenfall würde er eine neue bekommen und dann kannst du deine Sessions ja in den Wind schreiben. Das selbe gilt - wenn du den Access Point wechselst und der andere im anderen Segment ist - dann sind deine Sessions auch futsch (woher sollte der Server wissen das der Client nun eine andere IP hat).

 

Es wird nur über einen "Gratuitous ARP" gehen - oder der Client erzeugt "Traffic" - ich bin mir beim Roaming nicht ganz sicher was passiert wenn du einen Controller hast und über den der Traffik läuft - dann könnte es sein, das der mitbekommt - "wo" der Client sich jetzt befindet.

"

[Nightwalker_z 10]

Aber der Client ist nicht dazu verpflichtet einen Gratuitous ARP zu senden.

Natürlich ist er das nicht. Aber das könnte eine sinnvolle Implementierung sein bzw. manche Clients machen das auch. Aber selbst wenn der Client das nicht macht ist es kein Beinbruch!

 

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).

Ich mach mal die Geschichte weiter: Also ... Client wartet auf Antwort vom Server und bekommt also die Antwort nicht... was passiert? Der Client fragt erneut nach und bekommt dann die Pakete. Das ist doch grad der Sinn von TCP dachte ich.

Aus der Praxis: Ich hatte damit wirklich noch NIE irgendwelche Probleme. Hast du ein konkretes Problem oder spielst du einfach irgendwelche wilden Corner-Cases durch? Das wäre mal ganz interessant zu wissen.

 

Passiert doch bei einem Lease-Extend auch nicht! Da bleiben die TCP Verbindungen ja auch bestehen.

Was denn nun? Lease extend oder renew? Zwei paar Schuhe!

 

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?

Wie soll ein Client überprüfen ob er noch im selben Subnetz ist? Klar macht das ein Client (Ping auf DG), aber eben nicht so oft. Der Client rafft schon irgendwann, dass das DG nicht mehr erreichbar ist und triggert DHCP. Das hat dann aber nichts mehr mit Roaming / Mobility zu tun, sondern mit Kabel abziehen und wieder aufstecken, wenn man es mit wired vergleichen möchte.

 

Sei es wie es ist: Wenn du zwischen L3 Boundaries wechselst, kannst du nicht roamen - Punkt! Wie immer gibt es Ausnahmen: L3 Mobility via Tunneling bei Cisco WLC oder WDS. Aber mit diesen Technologien behält der Client seine ursprüngliche IP und wird ins alte Subnetz getunnelt.

 

also sollte man auf den beteiligten Switches gratuitous ARP nicht deaktivieren ? das geht ja nur global für den ganzen Switch

Geht das überhaupt? Der Befehl "[no] ip gratuitous-arps" auf den Switches ist doch sowieso ein Blender, oder? Wenn ich als Client ein ARP Paket auf die Broadcast Adresse haue, dann kommt das doch immer durch. Zumindest sagt das mein Labor :-)

 

@Pinkman: Worauf willst du eigentlich hinaus? Hast du ein konkretes Problem oder ist das ganze akademischer Natur?

[Pinkman 10]

Ich mach mal die Geschichte weiter: Also ... Client wartet auf Antwort vom Server und bekommt also die Antwort nicht... was passiert? Der Client fragt erneut nach und bekommt dann die Pakete. Das ist doch grad der Sinn von TCP dachte ich.

 

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.

 

 

Aus der Praxis: Ich hatte damit wirklich noch NIE irgendwelche Probleme. Hast du ein konkretes Problem oder spielst du einfach irgendwelche wilden Corner-Cases durch? Das wäre mal ganz interessant zu wissen.

 

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.

 

 

Was denn nun? Lease extend oder renew? Zwei paar Schuhe!

 

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.

 

 

Wie soll ein Client überprüfen ob er noch im selben Subnetz ist? Klar macht das ein Client (Ping auf DG), aber eben nicht so oft.

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.

 

Sei es wie es ist: Wenn du zwischen L3 Boundaries wechselst, kannst du nicht roamen - Punkt!

 

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.

 

Wie immer gibt es Ausnahmen: L3 Mobility via Tunneling bei Cisco WLC oder WDS. Aber mit diesen Technologien behält der Client seine ursprüngliche IP und wird ins alte Subnetz getunnelt.

 

Ja, ich habe die Cisco Doku dazu überflogen. Controller sind nicht im Einsatz, nur reine autonome APs.

[Nightwalker_z 10]

Dann kann ich auch nicht weiter weiterhelfen, sorry.

 

Aber noch ein paar Punkte und Wortklaubereien:

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.

Naja, ausser der Client macht einen GratArp oder einen von dir beobachteten lease-extend. Sprich das Problem hast du bei Clients mit statischer IP.

 

Ich sehe definitiv, dass die Clients, die per DHCP ihre IP beziehen, beim Roaming sofort einen DHCP Request (Lease extend) rausschicken.

Das ganze Roaming Zeug ist im 802.11 Standard nicht beschrieben. Sprich man wird im Feld mehrere Implementationen finden behaupte ich mal. Die einen Clients machen beim Roamen nichts, die nächsten machen einen GratArp und die nächsten eben deinen Lease Extend. Die letzten zwei Optionen sind eventuell sinnvoll, damit der Switch die CAM table updated.

 

Ping wäre das denkbar falsche Vorgehen

Naja, das machen halt Windows XP Clients so. Ab und zu mal ein ICMP auf das DG um zu sehen ob noch L3 Connectivity gegeben ist. Win7 macht nen regelmäßigen ARP Request auf die DG Adresse.

 

Roamen in dem Sinne den AP zu wechseln schon, natürlich gehen dann alle Sessions fliegen, wenn man in einem anderen Netz gelandet ist.

Also im WLAN ist dann nicht von Roaming oder Mobility die Rede :-)) Zumindest hab ich das in noch keinem Buch/Weblink so gelesen.

 

Sind das Cisco IOS APs? Welches Modell?