Dit document beschrijft hoe AP (Access Point)-taakverdeling en AP-back-up werken in de Cisco Unified Wireless-oplossing. Dit document legt ook uit hoe u meerdere draadloze LAN-controllers (WLAN) (WLC’s) kunt instellen voor een failover-voorwaarde. Een uitvalconditie treedt op wanneer een primaire controller op of faalt om een of andere reden. Dan neemt een tweede controller de operatie over. Failover wordt ook "controller redundantie" genoemd.
Opmerking: AP-back die in dit document wordt besproken, is alleen gerelateerd aan de versie van de controller firmware vóór 3.2.171.5. Later versies van de controller firmware gedragen zich niet op deze manier. In de nieuwste versie van firmware valt het AP terug naar de primaire controller wanneer het online komt. Als u een probleem hebt met AP-back-up, leest u dit document of upgrade van de firmware van de controller naar de nieuwste beschikbare code.
Cisco raadt kennis van de volgende onderwerpen aan:
Configuratie van lichtgewicht APs en Cisco WLCs
Lichtgewicht AP Protocol (LWAPP)
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 AP
Twee Cisco 2000 Series WLCs die firmware 3.2.78.0 uitvoeren
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 met een andere Cisco WLC en een willekeurige lichtgewicht AP worden gebruikt.
Raadpleeg WLAN-controller-failover voor lichtgewicht access points-configuratievoorbeeld voor informatie over de manier waarop u de WLC en lichtgewicht AP kunt configureren voor failover.
U kunt een taakverdeling voor AP op twee (of meer) WLCs uitvoeren als u mobiliteitsgroepen correct configureren. De LWAPP maakt dynamische redundantie en taakverdeling mogelijk. Als u bijvoorbeeld meer dan één IP-adres voor optie 43 hebt opgegeven, stuurt een AP een LWAPP-zoekaanvraag naar elk van de IP-adressen die de AP ontvangt. In de WLC LWAPP zoekrespons weergeeft de WLC deze informatie:
Informatie over de huidige AP-lading, die wordt gedefinieerd als het aantal AP's dat op het ogenblik aan de WLC wordt aangesloten
De AP capaciteit
Het aantal draadloze klanten dat op de WLC wordt aangesloten
AP probeert dan zich bij het minst geladen WLC aan te sluiten, wat de WLC met de grootste beschikbare capaciteit van AP is. Nadat een AP zich bij een WLC aansluit, leert AP de IP adressen van de andere WLCs in de mobiliteitsgroep van zijn aangesloten WLC.
Vervolgens stuurt het AP een LWAPP-verzoek tot primaire ontdekking naar elk van de WLC's in de mobiliteitsgroep. De WLC's reageren met een primaire zoekrespons op de AP. De primaire zoekrespons bevat informatie over het WLC-type, de totale capaciteit en de huidige AP-lading. Zolang de WLC de AP Fallback parameter die wordt geactiveerd heeft, kan AP besluiten om over te schakelen naar een minder geladen WLC.
Wanneer de AP start of herstelt, kent het slechts de IP-adressen van het beheer van de controller van DNS (Cisco-lwapp-controller@local_domain.com) (20 max), DHCP-optie 43 (20 max), OTAP, 255.255.255.255 en de voorheen aangesloten controller. De controllers in de mobiliteitsgroep van de voorheen aangesloten controller worden niet bij herstart behouden.
Als de AP echter connectiviteit met de controller verliest, wordt het niet opnieuw opgestart. Het beweegt rechtstreeks naar de zoekmodus en herinnert zich de leden van de mobiliteitsgroep. Het kan dan een zoekverzoek naar alle leden van de mobiliteitsgroep sturen.
Opmerking: Zodra een AP toetreedt tot een controller, wordt de momenteel aangesloten controller slechts om een beperkt aantal redenen verlaten. Een reden dat het AP de momenteel aangesloten controller niet verlaat is als de AP's niet precies over alle controllers zijn gebalanceerd. Om die reden is dit algoritme voor het taakverdeling slechts een benaderde algoritme voor het taakverdeling, tenzij u handmatig een primaire controller voor elke AP definieert.
Deze regels kunnen het best worden beschreven met enkele voorbeelden:
AP is nieuw, uit de doos, en nooit aangesloten bij een controller. Houdt dit AP belasting over 3 controllers in een mobiliteitsgroep?
Nee. AP moet alle 3 het beheer van IP-adressen van controllers ontdekken tijdens de start via OTAP, DNS (met alle 3 gedefinieerde IP-adressen van het beheer), 255.255.255 en DHCP-optie 43 (met alle 3 IP-adressen van het beheer) voor het taakverdeling. AP stuurt een zoekverzoek 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, worden de nieuwe AP’s altijd bij die controller aangesloten.
Als er 1 controller is gedefinieerd in DHCP-optie 43/DNS en er 3 controllers in de mobiliteitsgroep zijn, laadt deze dan de balans over de 3 controllers in een mobiliteitsgroep op als u het AP opnieuw start nadat het zich bij de controller in DHCP-optie 43 aansluit?
Nee. Als de AP opnieuw start of wordt gereset, sluit het zich altijd aan bij de controller in de DHCP-optie 43/DNS of de laatst aangesloten controller. Als echter het AP de hartslag aan de huidige controller verliest, wordt de computer niet opnieuw opgestart. In plaats daarvan gaat het AP rechtstreeks naar de zoekmodus. Omdat het niet opnieuw is opgestart, heeft AP nog de mobiliteitsleden en stuurt elke controller in de mobiliteitsgroep een zoekverzoek.
Waarvoor gebruikt AP mobiliteitsleden?
AP fallback (niet-geconfigureerd controller in de geconfigureerde controller [primair/secundair/tertiair]) en het leren van andere IP-adressen van de controller nadat deze zich bij een controller heeft gevoegd voor het geval dat hij contact met de huidige controller verliest. Onthoud dat AP de mobiliteitsleden over reboots vergeet.
Opmerking: Er kan een race conditie zijn op dit algoritme. Tussen de tijd dat de controller op het zoekverzoek van de AP antwoordt en de tijd dat de AP een gezamenlijk verzoek aan de AP-manager stuurt, kan het aantal AP's dat tot de AP-manager is toegetreden, zijn gewijzigd als er een groot aantal AP's is die gelijktijdig tot de controller toetreden. Bijvoorbeeld, als er een stroomuitval is en de stroom op de AP's gelijktijdig terugkeert, kunnen de AP's de balans niet gelijkmatig over de controllers laden.
In tegenstelling tot de Heet Standby Router Protocol (HSRP) stand-by, verstoort AP-back-up de draadloze service terwijl het AP faalt en dan terugvalt naar de geconfigureerde controller. Onthoud dat wanneer een AP zich bij een controller aansluit, de AP alleen geprogrammeerd is om die controller te verlaten als:
AP verliest reacties van zijn keepalives aan de controller.
De klant stelt het AP opnieuw in via de controller.
Het AP ontvangt, via de update van de mobiliteitsgroep van de huidige controller, een melding dat een geconfigureerde controller (Primair/Secundair/Tertiary) is geïnstalleerd en het AP is momenteel verbonden met een niet-geconfigureerde controller met AP-back-up.
Het is belangrijk om op te merken dat AP alleen AP-terugslag uitvoert van een niet-geconfigureerde controller naar een geconfigureerde controller (Primair/Secundair/Tertiary). Het AP valt niet terug van een secundaire controller op de primaire controller als het momenteel bij de secundaire controller wordt aangesloten. Dit komt doordat de secundaire controller een geconfigureerde controller is.
Wanneer het AP wordt aangesloten bij een niet-geconfigureerde controller en er wordt gemeld dat een geconfigureerde controller beschikbaar is via de leden van de mobiliteitsgroep, verlaat hij onmiddellijk de huidige controller en sluit hij zich aan bij de geconfigureerde controller.
Opmerking: Het gedrag dat in dit gedeelte 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 AP terug naar de primaire controller wanneer het online komt. Als u een probleem hebt met AP-back-up, upgrade dan van de controller firmware op de laatst beschikbare code.
OPMERKING: Wanneer een gloednieuwe LWAPP AP1242 voor het eerst aansluit op een WLC2006 of WLC4400 die firmware 2.3.116.21 draait, de naam van de secundaire controller (d.w.z. "DRAADLOOS"->"Detail") in GUI is niet leeg. De opdracht tonen AP configuratie algemene opdracht toont ook dat de secundaire naam van de controller niet leeg is. Dit is gemeld in Cisco bug id CSCse30514. Hoewel er geen tijdelijke oplossing is, is dit gedrag niet aanwezig in de 4.0 software release.
Opmerking: Als u 5.2 code of later op WLC's draait en AP High Availability instelt, als de wereldwijde 802.11g-configuratie tussen de controllers niet overeenkomt (schakelt vs. uitgeschakeld), kan dit AP-gerelateerde problemen veroorzaken bij een failover-gebeurtenis. Zorg ervoor dat alle WLC-instellingen identiek zijn tussen primaire/secundaire/tertiaire WLC’s.
Voor een aselecte taakverdeling hoeft geen van de primaire/secundaire/tertiaire controllers te worden geconfigureerd. Alle controllers die u wilt dat de AP-balans oplaadt, moeten echter worden gedefinieerd in DHCP-optie 43 of DNS.
Als u elke keer een perfecte taakverdeling wilt verzekeren, raadt Cisco u aan om de primaire controller op de AP handmatig te configureren en de andere twee controllers leeg te laten. Zolang de primaire controller omhoog 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 operationeel is.
Als u wilt dat AP terugvalt naar een secundaire controller op de externe site voordat u een andere controller in het WAN probeert, moeten alle 3 controllers worden gedefinieerd in DHCP-optie 43 of DNS. Echter, definieer alleen de primaire en secundaire controllers op de APs op de afgelegen plaats.
Als de WAN-controller niet is gedefinieerd in de DHCP-optie 43 of DNS, faalt AP er alleen op als de WAN-controller in de mobiliteitsgroep van de momenteel aangesloten controller zit en als de lokale controllers dalen. Als AP herstart, sluit het zich niet aan bij de WAN controller, behalve als de laatste controller waartoe het werd aangesloten de WAN-controller was, totdat een van de DHCP-optie 43 of DNS-controllers beschikbaar is om AP over leden van de mobiliteitsgroep te informeren.
Opmerking: de naam van de controller in de configuratie van het AP is hoofdlettergevoelig. Daarom moet u de exacte systeemnaam op de AP-configuratie configureren. Wanneer u dit niet doet, werkt de AP-back niet.
Zorg ervoor dat deze configuratieparameters correct zijn geconfigureerd:
APalback moet op alle WLCs worden geactiveerd. U kunt dit controleren op de pagina van de Controller GUI.
Vóór WLC versies 5.0.148.0 konden alleen de systeemnamen van de controller worden ingevoerd in de naamvelden Primair/Secundair/Tertiary Controller. Nu kunnen de IP-adressen van de controller-beheerinterface ook worden gebruikt.
AP failover en fallback vereist dat controllers in dezelfde mobiliteitsgroep worden geconfigureerd.
Gebruik de CLI mping opdracht om de communicatie van mobiliteitsgroepen te verifiëren. Gebruik de opdracht Spoelmobiliteit samenvatten om de configuratie van de mobiliteitsgroep van een controller weer te geven.
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 is tussen de WLC's of of geeft u dit protocol/deze poorten toe.
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
1.0 |
01-Aug-2008 |
Eerste vrijgave |