In dit document wordt besproken hoe taakverdeling en terugvalmogelijkheden van het toegangspunt (AP) werken in de Cisco Unified Wireless-oplossing. Dit document legt ook uit hoe u meerdere Wireless LAN (WLAN)-controllers (WLC’s) kunt instellen voor een failover-voorwaarde. Een failovervoorwaarde komt voor wanneer een primaire controller uitvalt of om welke reden dan ook uitvalt. Vervolgens neemt een tweede controller de operatie over. failover wordt ook wel controllerredundantie genoemd.
Opmerking: AP-fallback die in dit document wordt besproken, heeft alleen betrekking op de controller-firmware-versie vóór 3.2.171.5. Latere versies van controller-firmware gedragen zich niet op deze manier. In de nieuwste versie van firmware valt het toegangspunt terug naar de primaire controller wanneer het online komt. Als u een Fallback-probleem met AP hebt, lees dan dit document of upgrade uw controller firmware naar de nieuwste beschikbare code.
Cisco raadt kennis van de volgende onderwerpen aan:
Configuratie van lichtgewicht AP’s en Cisco WLC’s
Lichtgewicht AP-protocol (LWAP)
Configuratie van een externe DHCP-server
DNS-server
De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:
Cisco Aironet 1000 Series lichtgewicht access point
Twee Cisco 2000 Series WLC’s waarop firmware 3.2.78.0 wordt uitgevoerd
Microsoft Windows Server 2003 DHCP-server voor ondernemingen
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u de potentiële impact van elke opdracht begrijpen.
Deze configuratie kan ook worden gebruikt met elke andere Cisco WLC en elke lichtgewicht AP.
Raadpleeg WLAN Controller-failover voor lichtgewicht access points Configuration Voorbeeld voor informatie over hoe u WLC en lichtgewicht AP voor failover kunt configureren.
U kunt AP load balancing uitvoeren op twee (of meer) WLC's als u mobiliteitsgroepen goed configureert. De LWAPP maakt dynamische redundantie en taakverdeling mogelijk. Als u bijvoorbeeld meer dan één IP-adres voor optie 43 specificeert, stuurt een AP LWAP-detectieverzoeken naar elk van de IP-adressen die de AP ontvangt. In de WLC LWAPP ontdekkingsreactie, neemt de WLC deze informatie in:
Informatie over de huidige AP lading, die als het aantal APs wordt gedefinieerd die aan WLC tegelijkertijd worden aangesloten
De AP capaciteit
Het aantal draadloze clients dat is aangesloten op de WLC
De AP probeert dan om zich aan te sluiten bij de minst geladen WLC, die de WLC is met de grootste beschikbare AP capaciteit. Nadat een AP zich bij een WLC aansluit, leert de AP de IP-adressen van de andere WLC's in de mobiliteitsgroep van zijn aangesloten WLC.
Vervolgens stuurt de AP LWAPP primaire detectieverzoeken naar elk van de WLC's in de mobiliteitsgroep. De WLC's reageren met een primaire detectierespons op de AP. De primaire ontdekkingsreactie omvat informatie over het type WLC, totale capaciteit, en huidige AP lading. Zolang WLC de AP Fallback parameter ingeschakeld heeft, kan de AP beslissen om over te schakelen naar een minder geladen WLC.
Wanneer het AP opstart of opnieuw instelt, kent het alleen de IP-adressen van het controllerbeheer van DNS (Cisco-lwapp-controller@local_domain.com) (max. 20), DHCP-optie 43 (max. 20), OTAP, 255.255.255.255, en de eerder aangesloten controller. De controllers in de mobiliteitsgroep van de eerder aangesloten controller worden niet behouden bij reboots.
Als het toegangspunt echter de verbinding met de controller verliest, wordt het niet opnieuw opgestart. Het beweegt zich direct naar de discovery mode en herinnert de leden van de mobiliteitsgroep. Het kan vervolgens een ontdekkingsverzoek sturen naar alle leden van de mobiliteitsgroep.
Opmerking: Zodra een AP zich aansluit bij een controller, verlaat hij de momenteel aangesloten controller alleen om een beperkt aantal redenen. Eén reden dat de AP de momenteel aangesloten controller niet verlaat is als de AP's niet precies zijn taakverdeling over alle controllers. Om die reden is dit algoritme voor taakverdeling alleen een benaderend algoritme voor taakverdeling, tenzij u handmatig een primaire controller voor elke AP definieert.
Deze regels kunnen het best worden beschreven met enkele voorbeelden:
De AP is nieuw, uit de doos, en nooit aangesloten bij een controller. Verdeelt deze AP belasting over 3 controllers in een mobiliteitsgroep?
Neen. AP moet alle 3 controllerbeheer IP-adressen tijdens het opstarten ontdekken via OTAP, DNS (met alle 3 beheer ip-adressen gedefinieerd), 255.255.255.255, en DHCP-optie 43 (met alle 3 beheer ip-adressen inbegrepen) voor taakverdeling. De AP stuurt een detectieaanvraag naar alle bekende controllers en sluit zich aan bij de controller met de meest overtollige AP-capaciteit. Als slechts 1 controller is gedefinieerd in DHCP-optie 43/DNS, dan voegen de nieuwe AP's zich altijd bij die controller.
Als er 1 controller is gedefinieerd in DHCP-optie 43/DNS en er 3 controllers zijn in de mobiliteitsgroep, is er dan een taakverdeling over de 3 controllers in een mobiliteitsgroep als u de AP opnieuw opstart nadat deze zich bij de controller aansluit in DHCP-optie 43?
Nee. Als het toegangspunt opnieuw wordt opgestart of opnieuw wordt ingesteld, wordt de controller altijd gekoppeld aan de DHCP-optie 43/DNS of de laatst aangesloten controller. Als het toegangspunt echter de hartslag van de huidige controller verliest, wordt het niet opnieuw opgestart. In plaats daarvan gaat het toegangspunt direct over op de detectiemodus. Omdat het niet opnieuw is opgestart, heeft de AP nog steeds de mobiliteitsleden en stuurt elke controller in de mobiliteitsgroep een ontdekkingsverzoek.
Waarvoor gebruikt de AP mobiliteitsmedewerkers?
AP fallback (niet-geconfigureerd controller naar geconfigureerd controller [primair/secundair/tertiair]) en het leren van andere controller IP-adressen nadat het zich bij een controller heeft aangesloten voor het geval het contact met de huidige controller verliest. Vergeet niet dat de AP de mobiliteitsleden over reboots vergeet.
Opmerking: er kan een race-omstandigheid zijn op dit algoritme. Tussen het tijdstip waarop de controller reageert op de detectieaanvraag van de AP en het tijdstip waarop de AP een aanvraag voor samenvoeging verstuurt naar de AP-manager, kan het aantal AP's dat is aangesloten bij de AP-manager zijn veranderd als er een groot aantal AP's is die zich tegelijkertijd bij de controller aansluiten. Bijvoorbeeld, als er een stroomuitval is en de macht op APs gelijktijdig terugkomt, zouden APs niet gelijk over de controlemechanismen kunnen laden.
In tegenstelling tot de Hot Standby Router Protocol (HSRP)-stand-by, onderbreekt AP-fallback de draadloze service terwijl de AP-failover wordt uitgeschakeld en valt dan terug naar de geconfigureerde controller. Onthoud dat zodra een AP zich aansluit bij een controller, de AP alleen geprogrammeerd is om die controller te verlaten als:
AP verliest reacties van zijn keepalives aan de controller.
De klant stelt het toegangspunt opnieuw in via de controller.
AP ontvangt bericht, via de update van de leden van de mobiliteitsgroep van de huidige controller, dat een geconfigureerd controller (primair/secundair/tertiair) is ingesteld, en de AP is momenteel aangesloten bij een niet-geconfigureerd controller met AP-fallback ingeschakeld.
Het is belangrijk om op te merken dat AP slechts AP reserve van een niet gevormd controlemechanisme aan een gevormd controlemechanisme (Primair/Secundair/Tertiair) uitvoert. De AP valt niet terug van een secundaire controller naar de primaire controller als het momenteel is aangesloten op de secundaire controller. Dit komt doordat de secundaire controller een geconfigureerde controller is.
Wanneer het toegangspunt is aangesloten op een niet-geconfigureerd controller en wordt meegedeeld dat een geconfigureerd controller is geïnstalleerd en beschikbaar is via de leden van de mobiliteitsgroep, verlaat het onmiddellijk de huidige controller en sluit het zich aan bij de geconfigureerde controller.
Opmerking: Het gedrag dat in deze sectie over AP-fallback wordt uitgelegd, is van toepassing op controllers die versie 3.2.171.5 of eerder uitvoeren. Latere versies van controller firmware hebben deze problemen niet. In de nieuwste versie van firmware valt het toegangspunt terug naar de primaire controller wanneer het online komt. Als u een probleem heeft met de fallback van het toegangspunt, dient u de firmware van uw controller te upgraden naar de meest recente beschikbare code.
Opmerking: Wanneer een gloednieuwe LWAPP AP1242 eerst wordt aangesloten op een WLC2006 of WLC4400 die firmware 2.3.116.21 uitvoert, de secundaire controller-naam (d.w.z. "DRAADLOOS"->"Detail") in GUI is niet leeg. De algemene opdracht AP Config toont ook aan dat de naam van de secundaire controller niet leeg is. Dit is gemeld in Cisco bug id CSC30514. Hoewel er geen tijdelijke oplossing is, is dit gedrag niet aanwezig in de softwarerelease 4.0.
Opmerking: Wanneer u 5.2-code of later op WLC's uitvoert en AP High Availability instelt, als de wereldwijde 802.11g-configuratie tussen de controllers niet overeenkomt (inschakelen vs. uitgeschakeld), kan dit ervoor zorgen dat AP problemen samenvoegt bij een failover-gebeurtenis. Zorg ervoor dat alle WLC-instellingen identiek zijn tussen primaire/secundaire/tertiaire WLC's.
Voor het in evenwicht brengen van willekeurige belasting hoeft geen van de primaire/secundaire/tertiaire controllers te worden geconfigureerd. Echter, alle controllers die u wilt dat de AP-load balans over moet worden gedefinieerd in DHCP-optie 43 of DNS.
Als u elke keer voor perfecte taakverdeling wilt zorgen, raadt Cisco u aan de primaire controller handmatig op het toegangspunt te configureren en de andere twee controllers leeg te laten. Zolang de primaire controller actief en functioneel is en de mobiliteitsgroep is gedefinieerd over elke controller waar de AP zich bij kan aansluiten, probeert de AP zich bij de primaire controller aan te sluiten wanneer deze actief is.
Als u wilt dat de AP terugvalt naar een secundaire controller op de externe site voordat u een andere controller probeert over het WAN, moeten alle 3 controllers worden gedefinieerd in de DHCP-optie 43 of DNS. Bepaal echter alleen de primaire en secundaire controllers op de AP's op de externe site.
Als de WAN-controller niet is gedefinieerd in de DHCP-optie 43 of DNS, kan de AP alleen failover naar de controller als de WAN-controller zich in de mobiliteitsgroep van de momenteel aangesloten controller bevindt en als de lokale controllers dan omlaag gaan. Als de AP reboots, het zich niet bij de WAN controller, behalve als de laatste controller die het aangesloten is de WAN controller was, tot een van de DHCP optie 43 of DNS controllers beschikbaar is om de AP te vertellen over de leden van de mobiliteitsgroep.
Opmerking: de controllernaam in de AP-configuratie is hoofdlettergevoelig. Zorg er daarom voor dat u de exacte systeemnaam in de AP-configuratie configureert. Het nalaten om dit te doen resulteert in de AP reserve die niet werkt.
Zorg ervoor dat deze configuratieparameters correct worden geconfigureerd:
AP-fallback moet worden ingeschakeld op alle WLC’s. U kunt dit verifiëren op de Controller GUI pagina.
Vóór WLC versies 5.0.148.0, konden slechts de namen van het controllersysteem in de de naamvelden van de AP Primaire/Secundaire/Tertiaire Controller worden ingevoerd. Nu kunnen de IP-adressen van de controller-beheerinterface ook worden gebruikt.
AP-failover en fallback vereisen dat controllers worden geconfigureerd in dezelfde mobiliteitsgroep.
Gebruik de opdracht CLI mping om de communicatie over het lidmaatschap van de mobiliteitsgroep te verifiëren. Gebruik het bevel van de showmobiliteitssamenvatting om de informatie van de de mobiliteitsgroep van een controlemechanisme te tonen.
Controllers configured in the Mobility Group MAC Address IP Address Group Name Status 00:0b:85:44:36:e0 192.168.240.10 Wireless Up 00:1f:9e:9b:08:20 192.168.251.250 Wireless Control Path Down
Als u de status als Control Path Down ziet, controleert u of er geen firewall tussen de WLC's is, of controleert u of u deze protocollen/poorten hebt toegestaan.
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
1.0 |
01-Aug-2008
|
Eerste vrijgave |