Lightweight Access Points (LAPs) können die Management-IP-Adresse des Controllers mithilfe des OTAP-Verfahrens (Over-the-Air Provisioning) ermitteln. Diese Funktion wird von den Cisco Controllern der Serien 5500 und 4400 unterstützt. In diesem Dokument werden einige Details dieses Prozesses erläutert.
Cisco empfiehlt, über grundlegende Kenntnisse von LWAPP/CAPWAP zu verfügen.
Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt.
Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps zu Konventionen von Cisco).
Während des LAP-Bootvorgangs verwendet die LAP verschiedene Mechanismen, um Controller zu ermitteln, denen sie beitreten kann. Die LAP behält jeden Controller, der die IP-Adressen über die verschiedenen Methoden erfasst hat, in verschiedenen Listen bei, um anzuzeigen, wie die LAP sie erfasst hat. Beispielsweise kann die LAP über den DNS-Eintrag für CISCO-LWAPP-CONTROLLER.localdomain, die DHCP-Option 43, über Broadcasts im lokalen Subnetz, die IP-Adresserkennung lokal gespeicherter Controller und OTAP IP-Adressen Management-IP-Adressen von mehreren Controllern erfassen. Wenn der Access Point die LWAPP WLC Discovery-Schritte abgeschlossen hat, wählt er einen WLC aus der Liste der geeigneten WLC-Teilnehmer aus und sendet diesen WLC und eine LWAPP-Join-Anforderung.
Die Lightweight AP (LAP)-Registrierung für einen Wireless LAN Controller (WLC) behandelt die verschiedenen Methoden, mit denen die LAP Controller erkennt.
Dieses Dokument enthält Informationen zum OTAP-Prozess.
Die OTAP-Funktion ist auf der Controller-GUI von der Seite "Controller General" oder über die CLI mit dem Konfigurationsnetzwerk-Tap-Mode aktiviert {enable} | disable}-Befehl.
Hinweis: Diese Funktion ist standardmäßig deaktiviert und sollte deaktiviert bleiben, wenn alle Access Points installiert sind.
Der OTAP-Prozess beginnt, wenn die LAP die Funkschnittstellen vor der Erkennungsphase vorübergehend hochbringt und die verschiedenen RF-Kanäle überprüft, die RRM-Nachbarpakete abhören. Es ist möglich, dass die LAP beim ersten Start ein RRM-Nachbarpaket empfängt oder nicht empfängt. Dies hängt von Folgendem ab:
Anzahl der LAPs im Bereich (je mehr LAPs im Bereich vorhanden sind, desto größer ist die Wahrscheinlichkeit, dass die LAP ein RRM-Nachbarpaket empfängt)
Wie viele Kanäle werden von der automatischen RF-Instanz verwendet (je mehr Kanäle, desto unwahrscheinlicher ist es, dass die LAP ein RRM-Nachbarpaket empfängt)
Legt fest, wie lange die LAP die Funkkanäle während des OTAP-Prozesses scannt (die üblichen Abtastzeiten, bevor der AP in die Erkennungsphase eintritt, betragen für alle Kanäle 18 bis 35 Sekunden)
Wenn die LAP in die Discovery-Phase eintritt, sendet sie über ihre primäre Schnittstelle Erkennungsanfragen an jeden Controller in den Listen, basierend darauf, wie er davon erfahren hat. Für die Controller, die über OTAP erfasst werden, sendet die LAP dem Controller ein Discovery Request-Paket mit dem OTAP-Bitsatz. Dies weist den Controller darauf hin, dass der AP seine Management-IP-Adresse über OTAP bezogen hat. Andere Discovery-Methoden, wie die DNS- oder die DHCP-Option 43, werden im Discovery Request-Paket nicht differenziert, da sie über kabelgebundene Verbindungen abgerufen werden.
Dieser Controller kann Discovery-Anfragen aus folgenden Gründen ablehnen:
Das OTAP-Bit wird im Discovery Request-Paket festgelegt, und OTAP ist auf dem Controller deaktiviert.
Das Discovery Request-Paket ist zu groß.
Das Discovery Request-Paket wird nicht auf der Management-Schnittstelle empfangen.
LAPs unterstützen OTAP nur, wenn sie über ein vollständiges LWAPP Cisco IOS-Image verfügen. OTAP wird vom Cisco IOS-Image für die LWAPP Recovery nicht unterstützt. Das LWAPP Recovery Image wird werkseitig geliefert und vom Upgrade-Tool geladen. Die Wiederherstellungs-Images (cXXXX-rcvk9w8-mx), die mit neuen, sofort einsatzbereiten LAPs ausgeliefert wurden, enthalten keine Funkfirmware und rufen während des Bootvorgangs keine Funkschnittstellen auf. Daher funktioniert OTAP nicht mit sofort einsatzbereiten LAPs. Bei den Ausnahmen handelt es sich um sofort einsatzbereite Access Points der Serien 1510 und 1520, bei denen ein vollständiges Bild im Flash-Speicher installiert ist.
Hinweis: OTAP, das auf dem Controller aktiviert ist, gibt dem Controller an, ob er auf Erkennungsanfragen mit dem OTAP-Bitsatz antworten soll oder nicht. Sie verhindert jedoch nicht, dass die LAPs, die bereits mit dem Controller verbunden sind, die Management-IP-Adresse des Controllers in den Clear in RRM Neighbor-Paketen übertragen. Wenn Sie also OTAP auf dem Controller deaktivieren, wird es auf dem Access Point nicht deaktiviert. OTAP kann auf dem Access Point nicht deaktiviert werden.
OTAP verwendet RM-Nachbarpakete. Dieser Abschnitt enthält einen kurzen Hintergrund zu RRM-Nachbarpaketen. LAPs, die bereits mit einem Controller verbunden sind, übertragen RRM-Nachbarpakete an die RRM-Multicast-Adresse 01:0b:85:00:00:00. Jede LAP muss ein Neighbor Discovery-Paket einmal alle 60 Sekunden auf jedem der konfigurierten Auto-RF-Kanäle für 802.11b/g und 802.11a übertragen. Die RRM-Nachbarpakete werden ohne Verschlüsselung übertragen, ähnlich wie andere RF-Managementpakete, z. B. Anfragen und Sonde-Antworten. Die RRM-Nachbarpakete enthalten Nachbar-Kontrollnachrichten. Weitere Informationen finden Sie im Abschnitt zum RRM Neighbor Packet für 802.11a. Jede Nachbarsteuerelementnachricht besteht aus:
Radio-ID
Gruppen-ID
Management-IP-Adresse (des Controllers)
Anzahl der Kanäle
Antennenmuster (Omni, Links, Diversity, Rechts)
Messintervall
Schlüssel
Kanäle
Stromversorgung
Die LAPs kapseln alle empfangenen RRM-Nachbarpakete ein und leiten diese an den Controller weiter. So kann der Controller RF-Gruppen bilden, um die Leistung und die Kanäle zwischen LAPs, die sich gegenseitig sehen können, einzustellen. LAPs, die hochfahren, können diese RRM-Nachbarpakete verwenden, um den Controller zu ermitteln, dem die benachbarten LAPs bereits angeschlossen sind.
Hier sehen Sie ein Beispiel für ein RRM-Nachbarpaket für 802.11a:
No. Time Source Destination 8313 23:39:20.169855117 00:14:1b:5a:40:10 01:0b:85:00:00:00 Protocol Info LLC U, func=UI; SNAP, OUI 0x000B85 (Unknown), PID 0xCCCD Frame 8313 (80 bytes on wire, 80 bytes captured) [Protocols in frame: wlan:llc:data] IEEE 802.11 Data Rate: 6.0 Mb/s Channel: 60 Signal Strength: 0% Type/Subtype: Data (32) Frame Control: 0x0308 (Normal) Version: 0 Type: Data frame (2) Subtype: 0 Flags: 0x3 DS status: Frame part of WDS from one AP to another AP (To DS: 1 From DS: 1) (0x03) .... .0.. = More Fragments: This is the last fragment .... 0... = Retry: Frame is not being retransmitted ...0 .... = PWR MGT: STA will stay up ..0. .... = More Data: No data buffered .0.. .... = Protected flag: Data is not protected 0... .... = Order flag: Not strictly ordered Duration: 0 Receiver address: 01:0b:85:00:00:00 (01:0b:85:00:00:00) Transmitter address: 00:14:1b:5a:40:1f (00:14:1b:5a:40:1f) Destination address: 01:0b:85:00:00:00 (01:0b:85:00:00:00) Fragment number: 0 Sequence number: 487 Source address: 00:14:1b:5a:40:10 (00:14:1b:5a:40:10) Frame check sequence: 0x84bab9b3 [correct] Logical-Link Control DSAP: SNAP (0xaa) SSAP: SNAP (0xaa) Control field: U, func=UI (0x03) 000. 00.. = Command: Unnumbered Information (0x00) .... ..11 = Frame type: Unnumbered frame (0x03) Organization Code: Airespace (0x000b85) Protocol ID: 0xcccd Data (38 bytes) 0000 08 03 00 00 01 0b 85 00 00 00 00 14 1b 5a 40 1f .............Z@. 0010 01 0b 85 00 00 00 70 1e 00 14 1b 5a 40 10 aa aa ......p....Z@... 0020 03 00 0b 85 cc cd 01 1b 00 1a 6c 91 80 80 00 04 ..........l..... 0030 0a 01 00 0f 3c 01 01 3c 04 ff ff 00 4e 40 fd ec ....<..<....N@.. 0040 a7 4a f4 c4 d3 7b 19 be 10 92 50 91 84 ba b9 b3 .J...{....P.....
Die Multicast-Adresse des RRM-Nachbarn und die Management-IP-Adresse des Controllers sind hervorgehoben.