Lightweight Access Points (LAPs) können die Management-IP-Adresse des Controllers mittels OTAP-Technologie (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, dass Sie Grundkenntnisse über LWAPP/CAPWAP haben.
Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.
Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).
Während des LAP-Bootvorgangs verwendet die LAP verschiedene Mechanismen, um Controller zu erkennen, denen sie beitreten kann. Die LAP speichert jeden Controller, dessen IP-Adresse sie über die verschiedenen Methoden ermittelt hat, in verschiedenen Listen, um zu verdeutlichen, wie die LAP von ihnen erfahren hat. Beispielsweise kann der LAP die Management-IP-Adressen mehrerer Controller über den DNS-Eintrag für CISCO-LWAPP-CONTROLLER.localdomain, DHCP-Option 43, über Broadcasts im lokalen Subnetz, die lokal gespeicherte Erkennung der Controller-IP-Adresse und über OTAP abrufen. Sobald der Access Point die LWAPP WLC-Erkennungsschritte abgeschlossen hat, wählt er einen WLC aus der Kandidatenliste für den WLC aus und sendet diesem WLC eine LWAPP-Join-Anforderung.
Bei der Lightweight AP (LAP)-Registrierung bei einem Wireless LAN Controller (WLC) werden die verschiedenen Methoden erläutert, die LAP zur Erkennung von Controllern verwendet.
Dieses Dokument enthält Informationen zum OTAP-Prozess.
Die OTAP-Funktion wird in der Controller-GUI über die Seite General (Allgemein) des Controllers oder über die CLI mit dem Konfigurationsnetzwerk otap-mode {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 der LAP die Funkschnittstellen vorübergehend vor der Discovery-Phase aktiviert und die verschiedenen RF-Kanäle scannt, die auf RRM-Nachbarpakete warten. Es ist möglich, dass die LAP beim ersten Start ein RRM-Nachbarpaket empfängt oder nicht. Dies hängt ab von:
Anzahl der LAPs in der Area (je größer die Anzahl der LAPs in der Area, desto größer die Chance, dass die LAP ein RRM-Nachbarpaket empfängt)
Anzahl der von Auto-RF genutzten Kanäle (je mehr Kanäle, desto unwahrscheinlicher ist es, dass das LAP ein RRM-Nachbarpaket empfängt)
Wie lange der LAP die RF-Kanäle während des OTAP-Prozesses scannt (die typischen Abtastzeiten vor dem Eintritt des AP in die Erkennungsphase betragen für alle Kanäle 18 bis 35 Sekunden)
Wenn der LAP in die Discovery-Phase eintritt, sendet er Discovery-Anfragen über seine primäre Schnittstelle an die einzelnen Controller in den Listen, je nachdem, wie er von ihnen erfahren hat. Für die Controller, die über OTAP abgefragt werden, sendet das LAP dem Controller ein Discovery Request-Paket mit dem OTAP-Bit-Set. Dies zeigt dem Controller an, dass der WAP seine Management-IP-Adresse über OTAP bezogen hat. Andere Erkennungsmethoden, wie DNS oder DHCP-Option 43, werden im Discovery Request-Paket nicht unterschieden, da sie über kabelgebundene Verbindungen erfasst werden.
Dieser Controller kann Erkennungsanforderungen aus folgenden Gründen ablehnen:
Das OTAP-Bit wird im Discovery Request-Paket festgelegt, und OTAP wird auf dem Controller deaktiviert.
Das Ermittlungsanforderungspaket ist zu groß.
Das Discovery-Anforderungspaket wird auf der Verwaltungsschnittstelle nicht 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-Wiederherstellung nicht unterstützt. Das LWAPP-Wiederherstellungs-Image wird werkseitig ausgeliefert und mit dem Upgrade-Tool geladen. Die Recovery-Images (cXXXX-rcvk9w8-mx), die mit neuen, sofort einsatzbereiten LAPs geliefert werden, enthalten keine Radio-Firmware und stellen während des Bootvorgangs keine Funkschnittstellen bereit. Daher ist OTAP nicht mit sofort einsatzbereiten LAPs kompatibel. Ausnahmen sind standardmäßig 1510 und 1520 APs, bei denen ein vollständiges Image im Flash-Speicher installiert ist.
Hinweis: OTAP, das auf dem Controller aktiviert ist, gibt dem Controller an, ob er auf Erkennungsanforderungen mit dem OTAP-Bit reagieren soll oder nicht. Er verhindert nicht, dass die bereits mit dem Controller verbundenen LAPs die Management-IP-Adresse des Controllers in den unverschlüsselt in RRM-Nachbarpaketen übertragen. Wenn Sie also OTAP auf dem Controller deaktivieren, wird es nicht auf dem Access Point deaktiviert. OTAP kann auf dem Access Point nicht deaktiviert werden.
OTAP verwendet RRM-Nachbarpakete. Dieser Abschnitt liefert 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. Alle LAPs müssen alle 60 Sekunden ein Neighbor Discovery-Paket auf jedem der konfigurierten Auto-RF-Kanäle für 802.11b/g und 802.11a senden. Die RRM-Nachbarpakete werden wie andere RF-Management-Pakete, wie z. B. Anfragen und Antworten auf Anfragen, ohne Verschlüsselung übertragen. Die RRM-Nachbarpakete enthalten Nachbarsteuernachrichten. Weitere Informationen finden Sie im Abschnitt RRM Neighbor Packet for 802.11a (RRM-Nachbarpaket für 802.11a). Jede Nachbar-Kontrollnachricht besteht aus:
Funk-ID
Gruppen-ID
Management-IP-Adresse (des Controllers)
Kanalanzahl
Antennenmuster (Omni, links, Diversity, rechts)
Messintervall
Wichtigste
Kanäle
Stromversorgung
Die LAPs kapseln alle empfangenen RRM-Nachbarpakete ein und leiten sie an den Controller weiter. Dadurch kann der Controller RF-Gruppen für die Anpassung der Leistung und der Kanäle zwischen den LAPs bilden, die sich gegenseitig sehen können. LAPs, die booten, können diese RRM-Nachbar-Pakete verwenden, um den Controller zu ermitteln, mit dem die Nachbar-LAPs bereits verbunden sind.
Nachfolgend finden Sie ein Beispiel-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 werden hervorgehoben.
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
14-Jan-2008 |
Erstveröffentlichung |