CCIE Wireless Lab Training Video :: AP Failover and High Availability

hi there I'm Jeff Rancic I'm the wireless instructor over at IP expert and in today's be lecture we're going to be talking about controller high availability and the access point failover process so the high-level topics that's going to be encompassed with this be lecture then is going to be what is high availability with wireless LAN controllers and what are the different high availability options and models we have to work with in the wireless world when we have ApS during a controller how can we advertise other controllers for those ApS to failover to what methods do we have for that third how can we make those ApS failover in somewhat of a deterministic fashion is it positive more of a random fashion of failover and then throwing on top of those core things we'll throw on some extra options and features on top of the core failover and high availability features of the controllers so to kind of set a scope around the feature set and things that were going to be talking about for our purposes today high availability equals controller redundancy now there are other things that can be considered high availability for instance a tree purflex connect ApS operating with local switching and local authentication they can survive an outage of a controller and continue to serve clients so that is high availability in itself but for our purposes of this conversation is going to be controller redundancy as high availability the other thing is we're going to be specifically showing you code level seven zero one one six so I'm in demonstrating a lot of these h:a features that's the code we're at or you might hear refer to that seven seven zero mr one I'm kind of locked into that because we are certification focused company the CCIE the CCNP Wireless CCNA wireless they're all using that code level so that's what we're going to be showing you but I will talk about what we do have also available today in newer code as well I just won't be able to show you that stuff so with that in mind let's go ahead and start talking about h.a models that we have available to us okay so with redundancy models is we have I guess probably four main models of redundancy so as we talk about redundancy basically what we're saying is if an AP is associated up to a wireless LAN controller and that controller goes away we want to have that ap move over to a different wireless LAN controller as opposed to just sitting there and twiddling its thumbs until you know someday that original controller comes up so we want to have the AP move over to some other controller and continue to serve clients in the meantime until we get that original controller back on line so in order to have that work we're going to need more than one controller all right so we're going to see models the first one that we have they'll talk about is high availability pairing now this is a newer feature and this is one thing that I won't be able to show you in action today but what this is we actually have two controllers that operate in an active standby pairing so if I were to draw this this is something that was originally brought out in 7.3 code if I remember right we'll have one active controller and one controller that's in a standby but it's a hot standby so typically these guys would be probably plugging into two different switches for physical redundancy sake on the switching side and they actually do have a physical connection directly between them either directly between them you know no switches in between nuoc row it actually allows for you know it true this standby this hot standby connection to actually Traverse which is depends on what code that you're in but they do have a cable directly connecting the two and this is using that little or I guess never used pretty much I believe the RP port you know as the port that's been sitting there that no one used for forever on these 55 hundreds now they're using them so what's happening here is that the active controller is basically has all of the APS associated up to it so I have ap down here it's formed a cap web tunnel up to the active controller and the active controller is telling the standby controller all the time you know okay what are my client sessions one of my ApS joined up to me all the information that the standby would need to take over so in the event that the active fails the standby is going to take over it's going to take over actually everything it's going to take over you know IPS so basically what happens is this ap had a cap web tunnel terminated to an AP manager on the active controller well now the standby controller just takes over the IP address of that ap manager so from the appease perspective it's tunnel is just flowing over here but the town stays up because it's still sending to the same IP address that it was you know from a switch standpoint it just looks like the MAC address for that IP address moved from over here to switch number two so nothing really changes the AP never drops its association depending on the code clients may either have to reallocate themselves originally that was the way I believe in New York code that the clients don't even need to reallocate themselves so very great in terms of a user experience you know the AP is never dropped the clients never drop they may have to re-authenticate themselves just hang on code but from a client perspective you know it's great outages are extremely minimal maybe they lost a couple packets that was probably about it so very great in terms of user experience now the downside is these do have to be deployed in pairs so if I needed three controllers to support all the APS in my environment I would have to buy three standby controllers now at least the good news about buying those standby controllers Cisco does allow you to buy a high availability skewed controller so if I had three 5508 s-- that have 500 licenses on them I wouldn't have to buy three more 55 OS with 500 licenses that would have to buy 350 508 with the a chase queue which are close priced closer I believe to like a 25 license 5508 so I want to buy extra licenses that I don't need anymore which is great so very excellent method for high availability very little if any notice from the clients when things go wrong so a great option but only available in newer code as well as only specific controller models for instance I couldn't do this on 2500 I can do this on 5500 or 7500 just check documentation release notes to see you know which controllers this feature is available on so that's number one great option h8 pairing let's go and get into more the classic redundancy models that we've used in the past number two n plus 1 and the end part is just however many controllers you need to support your APs and then the plus one is I have one controller just sitting off on its own not doing anything waiting for one of these n controllers to fail so in this model I might let's say I have three controllers wll see one and these are supporting all the access points in my environment and then I just have WLC 4 sitting over here we have this cloud of ApS all using controllers 1 2 & 3 controller 4 is just sitting off on its own just waiting so with this if controller 2 goes away for whatever reason all the APS of controller 2 would then join up to controller for as the back of controller so some pluses and minuses with this one you know can this compare to an H a pairing we need fewer controllers so I only need one extra controller to be able to survive an outage now I can only survive one controller outage in this instance but I do have to buy less hardware to make this work the APS will you know suffer an outage during this process so eventually you know controller 2 goes out the APS that we run controller to eventually timeout their connection to controller - and then so there's that time the timeout portion and then the time it takes for the APS to join up - controller for get provisioned with you know any iOS or OS changes as well as gate configurations pushed out to them so that time clients on those ApS are out of luck so to help with that anytime we do this H a type stuff absolutely in the H a pairing but even without it we always want to be running the same code everywhere otherwise anytime an AP moves from one controller to the other it's got to upgrade or downgrade its OS and that takes a long time - we want to make sure our configurations are the same so all the same w lands are everywhere they're configured the same you know we should be using the same radius servers on the back end all that good stuff it's going to make things as smooth as possible during these failover processes so benefits to this yet we only need one extra controller pay attention to licensing so on older older code reps you know prior to seven for this WLC four had to have at least as many licenses as the biggest controller of one through three so for some let's say the controller one had a 50 license controller two at 100 license and controller three had a 50 ap license for whatever reason controller for should have at least a hundred licenses otherwise it wouldn't be able to backup controller to fully now if it does have a hundred licenses technically both controller one and three could go down and controller for can still pick up the slack so you have to kind of game your licensing to okay how many controllers am I going to be able to support going down at one time and that's going to be solely based off of the number of licenses you have on that backup controller now with seven four code and we talked about those H a skewed controllers with the H a pairing before and 7/4 they actually allowed this n plus one type model you could have controller for B an H a skewed controller in that way you know if these were 500 licensed controllers over here I can just buy an H a skewed controller for you know controller for here it doesn't have any licenses it just allows you know pretty much up to maximum Licensing which is five hundred and fifty five hundred and that way it can serve as strictly a backup controller it couldn't be a primary controller if it's the H a skewed one but it could definitely be a backup controller and you wouldn't have to buy all those excess licenses so depending on your code revs you can get away with a cheaper option of this n plus one you know once we start talking bigger numbers of Licensing by using that a chase cube but prior to that we have to have enough licenses on controller for here to support failures of you know one or more of these controllers on the left hand side there but that's kind of the classic model that most people tend to use it arises the line between you know providing full backup for you know any controller that goes down but not costing too much money you know if we want have a one-for-one backup we're basically doubling the cost you know historically because we'd have to buy double the licensing so I'll just kind of pay attention to your code Rev and you know what this going to mean in terms of costs number three we have an N plus n so with n plus n you know similar kind of concept to the n plus one except here all controllers are always serving access points at all times so if we just look at two controller example and we would have some ApS over here on controller one ApS here on controller two so a real basic example with just two controllers but what would say here is maybe there was you know 25 ApS on controller 125 ApS on controller 2 but we bought enough licenses to support all ApS so we bought 50 licenses for each they're essentially half utilize so if controller one goes down of controller ones 25 ApS go to controller to controller who has enough licenses and it you know all the APS survived the controller one failure now this model you know gets a little more tricky as we start adding more and more controllers so if we had you know two more controllers and for let's say we want to continue to buy you know 50 licenced controllers you know maybe there's our 25 hundreds or whatever it's going to be now what we do is you know we can control how many eight controllers can fail over just based off of you know how much access licensing do we have so with this I technically have purchased 200 licenses if I want to be able to survive a controller failover I need to have 50 spare licenses so I just need to make sure that as I divvy up my APS across these controllers here I just leave enough room so that if one goes down we have enough licenses spread throughout our n plus n design so that we can handle it so we could do something like you know 35 35 35 and so now I've got you know aggregate 140 ApS EPS I have 200 licenses so I have 60 so you know more than enough I could you know continue to bump this up you know higher and higher you know if there's 40s then it'd have 40 I think would be the max that could support and still have a failover right no this would be right because once I fail over I would have 140 ApS to divvy up across 150 licenses yeah do the math right so gets a little bit more complex now some benefits of this you know we're still paying about the same amount and we still have to buy these excess licenses we don't get the benefit of just having that back up a che skewed so once we start talking big license numbers this option does become more expensive because we're buying excess licenses for running older code we don't really have any option otherwise anyways but to me one other key benefit of this over just an N plus 1 redundancy is that every controller is always in use which means we're always validating that every controller is operating correctly if there's a problem on the controller you know maybe a misconfigure but w land compared to the rest of them you're going to know about it you know pretty darn quick because we always have clients on every single controller now in an N Plus have run one redundancy one of the key weaknesses I guess I would say of that one is that we have this controller just stand sitting by itself and we hope it's configured correctly but unless we test it we don't know so pretty much what happens is if it's if there's something wrong there one of the controllers that was working just fine fails all the APS move over to it and now we discover you know once these ApS move over to the other controller that something's wrong you know it was a different code Rev and we weren't paying attention to all my AP is changed code or you know something's wrong in the W land or I'm missing a W land or whatever it's going to be so if you don't have a really good config auditing you can run to a point where all sudden during a failure scenario things are breaking and then now you have nowhere else to send them so you're stuck with it until you get that original controller back line or you can figure out and fix what the issue is so some benefits and negatives for each of these different models here that would be the N plus N and finally the last one back black is n plus n plus 1 and this is really a hybrid of n plus 1 and n plus n so it looks like n plus n but in addition to that we have yet another controller that's just sitting off by itself so the idea being that ok if n plus n allows one controller to go down and plus n plus 1 allows two controllers to go down so technically is just adding additional controllers that can fail during the process here so those are the different redundancy models that we have I typically recommend you know if you can h a pairing is awesome you know that's the it's pretty much the way to go especially if you need minimal disruptions due to failures you know if you have a voyeur core you know Wireless is very critical to your business processes you know you can't go down at least as much as a wireless network can't go down you can't go down H a pairing that's the one to use outside of that I would either go with an N plus one or an N plus M type model and it's just going to be based off of you know how big is your scope what code you're using you know for instance with the n plus one we can use those H a skewed controllers as your plus one controller to save yourself some money especially we start talking very large numbers of licenses so n plus n plus one I asked I don't know that that's as useful but yeah n plus 1 n plus on H a pairing whatever kind of makes sense just based off of your budget and your needs in terms of you know fail overs how fast is going to happen things like that so those are there for models that we have all right now how do we actually kind of make this these different models work well in order for AP is to failover from one controller to another they have to learn about other controllers to failover to now if you've seen you know some of the other V lectures I did you know I kind of went through the whole AP discovery process and then the AP join process so basically once an AP has joined up to a controller all that stuff that happened during the initial discovery when it booted up and learned about a whole bunch of different controllers that it could join up to and then finally did join up to a controller all those controllers that dynamically learn you know DHCP option 43 or DNS or you know layer three broadcast things like that let's go out the window you know the AP pretty much just forgets about those and starts fresh with a new list of controllers that it can use for failover purposes you know once it has joined up to a different to a controller now what are those different methods we have to learn about failover controllers since we've forgotten all that dynamically learn stuff from the discovery process and also you know another note failover technically what we're trying to do is teach the APS other controllers to learn before has to essentially totally give up and start the discovery process all over again so we're trying to prevent essentially the AP from starting from square one like it just booted up so the different ways we have to to learn about these failover controllers so failover controller discovery so we have three main methods of telling ApS about other controllers to failover to number one and this one actually kind of goes back to the discovery phase it's a dual purpose method and that is with a static primary secondary tertiary controller configuration and that is per ap so on the on every individual AP you can configure a primary controller a secondary controller and a tertiary controller now these controllers are remembered forever until you wipe out the APS memory so it survives reboots it survives moving from one controller to another it stays with the AP so this method is honestly one of the the primary methods that we should that we use or at least I always use to have Mike ApS know of other controllers to failover to and the way that we can clear that let's actually get onto some controllers now alright so I have four different controllers peepees kind of spread all over so for instance LA p1 is on controller one right now so you would go into the controller or sorry into the access point and I guess if I went too fast it's on the wireless menu up on top and we automatically get this ap list but otherwise this would be the all ApS link on the left hand side here click into your individual ap go to the high availability tab and here's our primary secondary tertiary config so I could say WL c1 is my primary so I give it the name and IP address now technically the IP address is optional but I would always put this in old old old code you didn't actually get the IP address option but I would on any code that you should be running today put the IP address in and this is the management IP address and then I can say WL c2 is my secondary and wc4 is my tertiary so now this ap knows three different controllers to possibly failover to now it's currently on one so it knows two additional controllers to failover to and I'll stay with the AP until I wipe out its configuration which is something I would explicitly have to do it one and accidentally or anything like that so that's method number one method number two is we can have a back up primary and secondary controllers and it's globally let's call it global per controller so every single controller can be configured with a global back up primary and backup secondary controller so that any AP that joins to a controller with is configured will learn about - you know up to two different controllers to possibly failover - so where is this configured if we go to wireless on top and then on the left side under access points global configuration it's going to be over on the right hand side here so we have this back up primary both IP and name again I would put both of them in so we'll go ahead and say WL I'm on controller one so I'll say IP address 10.10 do so controller two and controller 4 is my backup secondary and apply so once I configure this any access points that joins controller one is going to dynamically learn about WL c 2 and WL c 4 as options to failover - if it ever loses its connection to wireless LAN controller 1 now this is a dynamic advertisement to the APS when the AP actually fails over to one of these guys anytime an AP joins up to a new controller it relearn's these two values so if it joined you know right now it knows two of them but let's say it failed over to controller - if I don't configure anything on controller 2 for a backup primary backup secondary then when the AP joins controller 2 is going to forget about these two that it learned from controller one when controller two pushes configuration to the AP the AP will just not have a backup primary backup secondary learn to anymore so every single time an AP joins a controller these values are overwritten based off of what's configured on the controller that it just joined up to okay so globally per controller learned every new every single time an AP joins up to a controller so this will not be remembered across controller joins it won't be remembered across reboots it's just kind of a one-time shot once it joins up to a controller it learns about that alright last method we have to learn about other controllers and this is through mobility group membership and this is technically it's per controller but it's usually more per Mobility group since most every controller in mobility group are configuring each other as mobility group members so how does this one work I'll go back to my controllers here so every controller is a member of some mobility group name so you might see it referred to as different oftentimes people think of the group name but in your think of it referenced as the group name so I know this is WL see one is the name in the GUI see it's actually referenced as the domain name just depending on where you read I you see it referred to as both as domain name group name basically if it's a name this is what we're talking about so typically when we want controllers to work together in terms of having clients roam from ApS on controller one to control or two we add them in to each other group list so if we go from controller on top on the left hand side mobility management mobility groups here is controller ones mobility group list at the moment it's just itself in there now if I want I can start adding other controllers into here and this is how we're going to be able to advertise additional controllers to our APs now the requirement though is that I'm only going to advertise other controllers in my mobility group list as long as they share the same group name now I can have you know other controllers in the list with the same group name different group name doesn't matter in terms of roaming we can still allow roaming between controllers that use different group names as long as they're in each other's lists and that works fine but in terms of advertising these controllers to other ApS they do have to use the same group name so let's go ahead and get controller to working in this fashion first let's see what controller 2 is using for its group name so I'll go to controller and under general we see it's using WLC 2 so I just need to give them the same subs say it's group name as WL c1 so then it matches up with controller ones and then we need to add them into each other's Mobility group list so I like the edit all option but there's a few different ways to do it base efficient need to call out each other's MAC address management IP address and group name and just make sure that we have it added on both sides I could also add these onesie twosie s at a time and with the new button and I could just type it in each individual box it's a little bit more work so I like the kind of copy/paste method ok so now I have controller 2 and it's using the same group name now any ApS on controller 1 will learn about controller 2 as possible failover options if I add it in say I added in controller 4 will do this just for illustrative purposes here so controller 4 is in group WLC 4 let's leave that in WC 4 so we can kind of see how it differentiates between same group name different group name so again we'll go into mobility groups and I'm going to add controller forward to controller 1 and controller 1 to controller forks we're always you need to add them in both directions here I'll take controller 1 put it into controller for and controller 4 and put it into controller 1 now typically takes a little bit of time for the stats to come up but honestly in terms of the safety failover process it never even needs to come up just the fact that's on the list what I actually allow to advertise it to the AP so these are the different ways we have to configure it how can we verify that the AP actually is learning these different methods well the easiest way for that is actually get into the console or the CLI of the AP itself and we can see some good show commands there I think that's typically the way I've done it so if I go to AP to see what ApS do I have on controller one first and we'll check that okay so let's go to LA p1 and see what we see there all right login Cisco Cisco is the default username password capital cm bulb okay so two of these methods can be verified with the show cap web client config so these static primary secondary tertiary entries are these m-more name and more IP address entries here so primary secondary tertiary so we can see the verification of what Ison figured in the GUI this is an easy one to validate in the GUI itself as well you just go into the AP and go to that high availability tab you'll see the same information here the other ones not so easy so if I keep scrolling down I'll get just before it starts talking about the interface is a list of configured switches so it's always going to have at least one on there and that's the controller that's currently on but this is where we're going to see any other controllers with that mobility group advertisement method so here I see here's controller one which is the one that's on it learned about controller two because controller two uses the same mobility group name now I also add controller four but we use a different group name so we see I did not learn controller four so that can become kind of an important thing as we configure our controllers and we are picking those mobility group names you know keep this in mind that if I use the same names I could have a peas failing over between this now maybe that's good maybe that's not when would be an instance where that's not good well here's something I actually saw at a customer site one time very simple design they had an internal WLC just a single controller all the APS were on that but the internal controller was tunneled up to a DMZ controller for guest connectivity classic design but they happen to use the same mobility group name so what happened was they wanted to do an upgrade of you know the internal controller so during the upgrade process it reboots the AP is dropped their connection look for another controller to join up to and they said oh we have this DMZ controller that we learned about through mobility group membership so you know a bunch of ApS joined up to the DMZ and when the internal controller came back they didn't do anything else else special to make the APS flow back so all sudden they had a whole bunch of ApS stuck on the DMZ controller and what happened was so you know this guy had just 12 licenses of the 5508 12 licenses we don't need that many let's say that this one had 50 I can't remember the exact number so what would happen is that you know we reboot the AP they would reboot the APS the APS would remember the controller that they were on before and they would learn about the the internal controller as well and what's the tiebreaker when we have two different controllers and you know they're not doing a primary secondary tertiary they're not doing master controller mode well it's the least loaded controller so all sudden the DMZ controller was the least loaded controller because the internal controller had a bunch of ApS on it and so we kept getting ApS going back to that DMZ controller so you know that's a good example as you know what we named our mobility groups matter so you might think well why don't I just name all my mobility groups different everywhere if I wanted if I don't want to use this method well sometimes we have to name it the same and usually the main reason we would ever have some a on the same is for CC km fast roaming with CC k and fast roaming when we add controllers to each other's mobility group list C's cam fast-growing only works between controllers on that list with the same name so anytime we need to do C's km there's no way around around it ApS will learn about you know these other controllers to failover to but we have many methods to control you know deterministically how the failover should happen and we'll get to that just a short second so there's a verification of the stack primary secondary tertiary there's a verification of what we've learned through mobility group membership options and the last one number two they're at the backup primary backup secondary that one you can see on the AP if i give back to it through the show camp web client h a command and here is the backup primary backup secondary the IP address is converted into hex so this is a hex equivalent of excuse me 10 10 - 10 sorry 10 10 1 12 10 + 10 10 1 1220 not sure why they do that but that's how they did it and we also see the the name as well so that's how we can validate that indeed an access point actually did learn about this back up primary backup secondary controllers okay so we have these different methods now I ate PS you know have multiple different ways to know about other controllers to failover to in the event that they're currently connected controller fails how can we control you know a priority of okay if I lose connection to my current controller this is the one I want to fail over to next and then this one and on down the line so basically each of these three methods has a priority to it and the priority is pretty much as I listed here so highest priority always goes to a statically configured primary secondary tertiary controller directly configured the AAP itself so if I'm on my primary controller and that one goes away I'm going to try to join up to my secondary controller next if that one's unavailable and I'll try to go on to the tertiary controller so that's always top of the hill next is the back up primary back up secondary so if I don't have any hard-coded primary secondary tertiary controllers or they're just all unavailable then I'm going to try to first join the back up primary controller globally configured on the controller I guess I technically was previously joined too and then the secondary if that's not configured or neither those are available then lastly I'm going to attempt to join you know one of the controllers in this mobility group membership list and if we want deterministic failover we never want to make our way down to option number three there we always want to rely on either option one and possibly option two now my recommendation is pretty much everything should use hard-coded primary secondary tertiary controllers or just primary secondary just depend on how many controllers you have that way we always always know what the order is in terms of our failover and we control it it does matter where the control where the AP currently is it always has the same hierarchy in terms of where it wants to be what's the next priority and what's the next priority after that because typically what we want to avoid is you know normally we want to avoid kind of salt pepper style ap deployments where we have you know 100 ApS on a floor of a building and they're all mixed up between five different controllers we don't want that because every single time someone's walking around we're having inter controller roams left and right and that's you know not ideal from a performance standpoint typically we go on you know all the APS on a given floor to be on one single controller and the only way to control that really is with primary secondary tertiary static assignments on the AP now if you want you know the backup primary backup secondary that can be a worthwhile play let's say you only had two controllers and so you could have a design where on WLC one you configure backup pry of WLC two and then on WLC two you configure a backup prime primary controller of WLC one so in ApS that joint controller one will learn about controller - is there a backup primary they failover to controller - they learn about controller one is their backup primary so that you know eventually controller one comes back online if controller 2 goes away they'll flow back over to controller one so excuse me that's a real easy way in just a to controller environment if you didn't want to have to do / AP static configurations or anything like that you know if you just have pairs of controllers you want failing over back and forth between that's a really easy way to configure it and you might just you know do the same thing if we had four controllers essentially we just deploying them in sort of high availability pairs but not actually doing the H a pairing feature ApS are just flowing back and forth between pairs of controllers back a primary backup second really great way to do that but my personal preference again primary secondary tertiary static configurations that way I always know if controller one's not down my ApS are you mean controller to you know for what goes from controller one to controller to controller three you know that's the progression so I always know exactly where the EPS are going to be and you know the APS are always staying clustered with each other so that way I'm avoiding you know as much as possible the salt pepper type deployments and lots of entry controller rooms things like that okay so that's how we can control the progression of failover in terms of priority you know deterministic fail failing over to less and less desirable controllers but typically you know if we have this you know for instance controller one goes down everyone moves over to controller two generally if I'm trying to be real deterministic about things once controller one comes back up I want my EPS that were there to get back to it otherwise then controller ones just sitting there and no ap will ever join up to it until you know AP's reboot or controller two goes down or you know something happens that kicks the APS off of the controller that they were currently on so if I want that the APS to proactively get back to you know a more preferred controller then my only option with that is hard-coded primary secondary tertiary controllers no other option will allow me to fail back to a more preferred controller I can only fail down to you know progressively less and less preferred controllers with my backup primary secondary with my mobility group advertised controllers static primary secondary tertiary is the only way to get back to a more preferred controller now in order for this to work this process of failing from a less conferred controller to a more preferred controller is referred to as ap fallback so in order to make this work the controller's all need to have this ap fallback feature turned on so let's show you where that is good news is it's turned on by default but you never know sometimes stuff gets turned off so if you go to the controller general configuration AP fallback make sure that's enabled if you disable it what that means is that you know I'm on controller 1 right now so if I disable it on controller 1 any ApS currently on controller 1 will never be able to leave controller 1 to go to a more preferred controller so whatever controller they're on they're stuck there until they reboot the controller fails you know some other event that kicks them off of the controller they can't preemptively leave the controller of their own volition so generally just make sure that this is turned on everywhere but if it does accidentally get turned off that sort of the scope of the feature it's only affects APs currently associated to the controller that is on it wouldn't prevent other you know if WLC one was the more preferred controller of an AP on controller - even if I have a turn off on controller one controller - ap could move to controller one it's just you can't move off of controller one to a more preferred controller so the AP fallback feature definitely make sure that you have that turned on some other rules in terms of moving from a less preferred controller to a more preferred controller I can move from an any unconfigured controller to any configured controller now technically what that means is a configure controller is a primary secondary tertiary controller configured on the AP itself so if I failed all the way down to you know at the back a primary backup secondary or one of these mobility group advertised controllers I can move up to a primary my secondary or my tertiary whichever one becomes available first I'll move over to that one once I'm on a configured controller I will only ever move up to the primary controller and the only time this really comes into play is if I'm on the tertiary controller and my secondary controller becomes available I will not move from a tertiary to a secondary I will only move from the tertiary all the way up to my primary once that primary comes back and the idea there is just to prevent too many controller moves because that is disruptive to the clients when an AP moves from one controller to another essentially stop serving all clients associates up to the new control of the new controller without its config to the access point at that point then the access point can start serving clients again but it's disruptive it has to kick off all clients up to prevent that happening too many times we will only move from tertiary to primary not tertiary to secondary to primary so those are kind of the rules in terms of getting back on to a more preferred controller one other feature that we'll talk about here with this whole high availability thing is going to be AP priority so let's say that you know we're failing stuff over and I didn't buy enough licenses for everything so I can't support you know every AP you know failing over between controller 1 2 controller - let's just draw this out so you can kind of see it visually so let's say I had two controllers servicing clients and then I had a backup controller sitting over here let's say I bought 50 licenses on the backup controller controller 1 and we have a hundred micro or one controller - and everything's fully maxed out on these guys so if controller ones goes down I have a hundred ApS failing over to controller three I can only support 50 of them so 50 ApS are out of luck now under normal circumstances it's just going to be the first 50 ApS that join up to controller 3 or pay ok and the rest of the 50 tough luck you should have been faster well as you know that might not be very desirable maybe I have ApS in specific locations in my building that are very critical you know so I always want them up as opposed to others you know if I don't have enough licenses for everyone some are going to be more important than others that's where we can say ok certain ApS are higher priority than other ApS so that if I have I'm full up you know controller 3 is full up with 50 ApS and a new AP says hey I want to join it can say I'm a high priority ap WLC three you can see okay do I have any lower priority ApS yep boom I'm going to kick off one of the lower priority ones allow this higher priority AP to join so this feature is turned off by default configure it it's going to be under wireless global configuration same place we're doing the backup primary secondaries and the global AP failover priority so once I turn this on hit apply now if I did this on controller one if controller one is full up and it receives a higher priority join request they can kick off a lower priority ap okay so how do we configure this priority on the ApS it's going to be a / ap configuration and it's going to be under the high availability tab same place we configured that primary secondary tertiary everything starts off at a low priority by default so we see we have low medium high critical the higher you know the further down the list you go the higher the priority is one thing that automatically gets a critical priority if you ever put an AP in mesh mode it automatically in here it's a critical priority so we always have mesh ApS you know at the top of the food chain automatically you have to do anything special for those mesh APs so you would have to do this on a per ap basis and you'll say this one's high over and over and over through all of my access points so failover priority one last setting will kind of talk about to kind of round out the discussion here is timers so you know how does an AP know when it needs to failover from controller 1 and controller 2 and house I know that controller 1 went away and it's no longer just you know there well it's going to be with you know a heartbeat so the AP is sending a heartbeat to the controller and regular basis if the controller stops responding those heartbeats it knows something went wrong it's time to move on to a different controller so by default we have 30 second heartbeat timers if we want we can manipulate these we also have a newer feature as fast heartbeat timers so we can enable these for both either local mode or a treat mode so I could say local mode APs you know one second so faster failure detection of course just make sure that you don't put it too low especially if you're going across like a weigh-in or something like that that might be inducing some latency or you might have to suffer a couple a little bit of packet loss but definitely if it's just going across the land you know one second probably would be fine so this is how it can you know determine you know how fast of a failover are we going to get to spread these heartbeat timers most of the time unless things are super critical a lot of people just leave the 30-second timer on there because in addition to that we have the joining process and configuration so unless you're doing H a pairing there's really nothing superfast about wireless fail or is even when we are dropping these these timers down it's still going to be a noticeable outage to the clients and once you'd have a noticeable outage is a ten-second outage compared to a 40 second knowledge is it that big of a deal now I guess certain customers would say yes some say no but this is how we can kind of control how long it takes to detect that there's have been a failure on the controller okay so we've seen you know a lot of configurations a lot of configurations that recommend kind of stem around using these you know primary secondary tertiary hard configured settings on the APS one hurdle to doing that is that we have to go into every single access point and configure it on a per ap basis so if you were to pretend that I had 500 ApS on here going into okay here's an AP high availability type all this stuff in hit apply go back to the list find the next ap and these are in a massive unsorted list so I have to scroll down and try remember okay it was the last one I did it's a mess so we need a better method to get these you know primary secondary tertiary configs out to all my EPS and then what happens if I need to change it later so there's two route decent ways I would say of addressing this problem once we start scaling to some larger numbers one use the CLI of your controller so I could go into one of your controllers I'll open up controller one here and you would do the line of config let's see if I can find it fig ap and let's see so primary base secondary base tertiary base to configure it so if we want to configure all three it would take three lines of config / ap meri base and then the name and what the name of my ap is so LA p1 and then finally optionally the IP address so obviously if I was just typing this in you know that you're saying wow this isn't any better so what you would do is you would you know basically just use some spreadsheet magic or a little bit of scripting magic dump the output of a show ap summary copy all the ap names and basically shove those into the Cu like a fig if you can use a little bit of scripting or a little bit of you know regex matching magic or something like that you know excel you know working with excel might be a way to do this you can get the output of the CLI and then just copy it paste it in to the CLI and that's a decent way to do it if you have no other option but if you have something like prime or WCS you know whatever the Cisco management platform that you're using that's the way to go let's go ahead and take a look at how we can do it in that so if I go into WCS get logged in what we want to use is a lightweight ap configuration template so you may be familiar with the controller configuration templates but we also have configuration templates for the lightweight ApS themselves they're actually very powerful much more so than the controller configuration templates in my opinion so to get to it we would go to configure ap configuration templates lightweight ap obviously in prime be a little bit different method to get to it but once you get there and you add a template the look feel is going to be the same between w CS and prime give it a name online price actor and then basically this is just about anything you could possibly configure on a lightweight ap you're going to see in here so basically any setting you want to push out you just find it check its box and then go ahead and put in the values so here I could say controller 1 controller to controller for for my primary secondary tertiary and I also want to get the IPS in there that's in a little different section so here's the IP it's telling you that this is only supported since controller version 6 so yeah we'll just ignore these since I am using newer code and I final type it in first and then I'll type the IPS associated with the controller's 10th and one one one a 10 there we go and we can save the template if I want to apply it all I need to do is select my EPS so I can select all APs you know by controller so I could target all the ApS on a specific controller so if I said WLC one search here's all the APS on controller one so very easily targeting you know specific controllers I could target you know if I have maps and different things like that can target it by floor areas lots of different things but let's just go ahead and I'll just shoot it out to all five of the ApS that I have across all of my controllers here apply there to just configure it all five in you know just a single second there now if I go to some my other ApS like la p3 I'll see it on there there we go and now that I have configured as long as I have you know ap fall back and able down all these places I should actually start seeing all my AP s flow over to wireless LAN controller one so controller three I see two ApS there high availability tab there they are so very very easy to configure this primary secondary tertiary across all of your ApS or a specific subset of your ApS very powerful tool in my opinion cell one of the to me one of my favorite tools in WCS or prime we're actually the lightweight configuration templates because I could do this across a massive amount of ApS with very little work and then this becomes really easy to let's say I wanted to I wanted to do an upgrading controller one but I didn't want to suffer you know the failover timers or things like that so I could preemptively configure all the ApS on controller one to prefer you know controller to and they would just on their own and move over there and once they're all over I could do whatever I needed or one so it's a little bit less disruptive that way see if we have anything failing over yet we're preemptively moving over okay yep four and five have preemptively moved over it's because I had that ap fallback enabled so from their mind four and five we're actually moving from an unconsidered controller to a configure controller because they were on controller three now the AP on controller for maybe that already moved that was moving from the tertiary controller over to the primary controller so that was just fine it didn't you know if this was down it would not have moved to controller two because it won't go from tertiary to secondary but we'll go from tertiary to primary so there's an example of you know in action how to get controllers or EPS to always be on a specific controller if that controllers available and usually that's the the function that they're the behavior that I want to be seeing in my environments so there we have it high availability with the wireless LAN controllers we talked about the different high availability models from HEA peering and plus 1 n plus n how do we advertise different controllers to failover to to our ApS with the primary secondary tertiary backup primary backup secondary and our mobility group advertisements you know how we control you know the priority of the failover process and you know getting controller or ApS to move back to more preferred controllers as well as a few of the other just miscellaneous configs that go along with h a so thank you guys for tuning in and we'll hopefully see you next time on our next be lecture

Channel: IPexpertInc

Views: 22,286

Keywords: CCIE Wireless, CCIE Wireless Lab, AP Failover and High Availability

Id: -zD_7kV6m4k

Length: 62min 0sec (3720 seconds)

Published: Fri Jan 31 2014