CCIE Wireless v3.1 Lab- Troubleshooting AP Controller Discoveries and Joins- Part 1

network dojo this topic right here ap controller discoveries and joins is one of the most common pieces of troubleshooting that you'll need to do you will always no matter what have to join a ps2 controller and I would say 99% of the time something will go wrong somewhere and during this process and you're gonna need to find it and fix it so if it's that big of a guarantee pretty much you're gonna want to show that you're good at this because what are the ramifications if you're not good at this so worst case your ApS aren't joining at all and I don't know how you pass you know if you have a good like a controller that won't allow ApS to join to it you will lose so many points that I don't think that there's any way to get over that that's worst case now you know what if it takes you you know 25 minutes to get your ApS joined that's a lot of wasted time that you're gonna run into there early on in the lab so it's like you're already dug yourself a big hole that you need to get out of here now conversely what if you're really good at this you find in fix that error within a couple of minutes you're off and on your way and you know you're yep you don't lose any momentum going on and that's what you want for sure so let's talk about the process here so remember ApS they first sort of really the order of operations they they boot they pull an IP address pretty much exclusively through DHCP they then tried to do discovery discovery they use all the different methods possible send up discovery requests hopefully get discovery responses from their controllers they build a list and put that in a priority prioritized order then we move to the join phase so join doesn't start until all of the discovery methods have been attempted once we have our list we move to join phase pick the first controller on the list attempt to join that if we're unable to eventually we give up move to the next most preferred controller on the list and so on down the line until we've either joined a controller or we give up usually we release our IP address and we start the whole process all over again so as we try to figure out why our AP is not joining a controller what we want to first you're out is is the problem with discovering the controller or is a problem with joining the controller because if we can immediately realize oh it's trying to join the controller we can continue you know completely eliminate all of that discovery troubleshooting and just focus on the joint process whereas if we don't ever see it attempting to join a controller you know it's kind of all on the table here so we are worried about discovery and then potentially there might be joint issues following up on that so usually one of the things I'll be looking at I'm looking at AP logs often times give us very helpful information as well as the AP join stats on the controller give us very helpful information so in the AP join stats if you don't see your AP on the list in the AP join stats that means that the controller has never received a discovery request from that AP in question so that's one way to know ok has my AP least God discovery request up to the controller if the answer is no then absolutely we definitely need to troubleshoot the discovery process but if we do see an entry in there we can click into it and see ok did the controller send back a discovery response if so discovery should be good now we would then focus in on troubleshooting joins the other thing that we would be able to look for in terms of did is the AP attempting or did it discover the controller is just look at the logs of an AP so for instance here's an AP e that is actually coming out of a reboot actually it did join up so let's let's just scroll back through the logs ok let's go to where it finds its IP address ok so I pulled its IP address again that's the first step now it's gonna do all the discovery processes we're gonna see logs for you know some discovery related things you know translating controller that the dns name option 43 but right here on an iOS based AP meaning our 3700 s in the lab as opposed to our 1800 series APs this is the first log to say ok we're about to start trying to join a controller and then the next log should be the DTLS log and this is going to have an IP address and so right here this shows us that this ap is started the process of trying to join to 10.0 4.11 hence we can assume it has discovered 10.0 4.11 so if you do if you never see this DTLS connection request sent to whatever IP address you know it hasn't discovered it if you see it we can assume discovery it was trying to join a controller that you didn't anticipate it trying to join we don't know yet if it's discovered the controller that you wanted it to join maybe it did maybe it didn't but again we can we can validate at least on the controller side again against loes AP join stats so it be under monitor statistics AP join he is it on the list here if the answer is yes click into it and what we want to see is that well we will see request received if it's on the list the question is do we send responses back if the answer is no there's usually only one explanation for that but we'll talk about that later but if we send it back we have to assume for the most part that the AP should have discovered the controller and again then we would focus on troubleshooting and join so sort that out first because that can drastically reduce the amount of things that you need to care about as we troubleshoot okay so if we have determined you know what it hasn't discovered the controller that we want to discover yet now we need to validate and troubleshoot those discovery mechanisms now in the lab we have a number of possible discovery mechanisms now and there's there's ones that are definitely more more used but what we'll talk about them on how to validate them so that first discovery method broadcast on the v4 side or multicast on the v6 side really this normally just requires the AP to be on the same VLAN as the management VLAN of the controller now for the broadcast method we do have the IP helper trick it unfortunately does not work on our 36 50 s due to a bug in the in the 3.6 code that we're running in the lab I believe it does work on a 4500 so if you're trying to get the broadcast method to work using the IP helper trick you just need to make sure that you configure the IP helper trick appropriately so again we're assuming that we didn't see discovery request received and so we didn't get it to the controller so let's show you that the two lines of config that we would need for that so let's let's pretend that this is a a forty five hundred series ap so we would say IP forward protocol UDP fifty two forty six cap web port and then we would go to the SVI that the ap lives on so if my apu is on say VLAN want to wait IP helper address in the management IP address of our controller now any broadcasts for UDP 52 46 will be leveraged through the IP helper command the IP helper command will then forward it on to the controller if we need to discover multiple controllers using this method we just add IP helper commands one for each management IP address and always remember we just got with we get we need to get that discovery request to the management IP address that's where we're sending the discovery but so that's that would be the broadcast method if that does happen to show up again it's only gonna work on our 4500 s that IP helper trick and joining our 55 hundreds it is almost never the case that our ApS are on the same VLAN as our controllers and so we don't use it unaided it always has to be in context of the IP helper command alright next method is DNS so it's trying to resolve Cisco - cap wife - controller dot domain whatever the local domain is and then it's going to send that dns resolution up to DNS server the DNS server if it has a DNS entry will respond back with one or more IP addresses pretty basic so the only way that this is going to break is if our ap can't resolve DNS so that the DNS server in this case would be a hundred percent pre-configured there's there's no expectation that you would need to add a DNS entry there's no expectation that you would need to fix a DNS entry so that's all taken care of so our responsibility is that our ap knows about the DNS server and knows the property and s suffix if that's the case and as long as there's layer three connectivity it should be able to resolve so my test here is I try to ping Cisco - cap wife - controller from the AP now we can look at logs to see did something resolve and in this case you know it would look something like this so this is all very good this is what we want to see when we are using this method so we see that we've we have a DNS domain suffix appended to the end of Cisco - cap Y potential controller if we didn't have the suffix I would know okay I need to update my DCP scope add the DNS suffix we have also learned the IP address of a DNS server if this was all 255 s I would know ok go into the DSP scope for this ap add a DNS server and then the ok means that it was there was actually a response received from this resolution the only thing we don't know is what was that response you know if we ever - needed to try to figure out ok what IP address are we actually learning when we resolve this well that's why I do the pain test so while the log is helpful and definitely it points out any wrong configurations that we might have our missing configurations it doesn't tell us what IP address that we learned so usually I can type the password right there we go Vytas ping Cisco - cap wife - controller don't put a suffix on let it do its own suffix we should see that it's able to resolve and that it pings and then now I know here's the IP address that it actually resolved to now the interesting thing with with DNS is I can send a DNS lookup to the ipv4 address of a DNS server and receive an ipv6 IP address in response and vice versa I could send a DNS lookup to the ipv6 address of a DNS server and receive an ipv4 address and response so it does it'll do both you know so if we learn you know v4 DNS server information and v6 DNS server information ill result you know it'll reach out to both the only questions okay well what's the response going to be is it gonna be a v4 response or a v6 response you know one's not necessarily right or wrong it's just as long as we can talk to the controller via the IP address given we should be able to discover it so that's how we validate DNS and as long as we you know we have this we should be pretty confident that you know it's gonna send it a discovery request for you to discover a response all right dhcp option 43 and or option 60 these are our v4 DSP options the one that we really use is option 43 again we're never expected to configure anything on the windows 2012 server and that's the only server that can configure option in 60 correctly in according to what we have available to us our switches as far as I can tell cannot I've never been able to make it work and it's almost impossible to find a document that tries to claim that it works and the one that I found doesn't work so option 43 is really all that we would ever be responsible for ourselves configuring so that's the only one that we should really ever have to troubleshoot so we'll focus on troubleshooting option 43 but validating them is the same either way so number one we just look at the AP logs do we have any logs for option 43 and so do we have the appropriate number of IPs learn and are the IPS correct if not we go in we fix our option 43 strength so again looking back at these a flaw are these logs here on the AP it's usually right after the translating Cisco cap why have controller log is where we would see the option 43 logs if we get any so in this case I got one option 43 locks I learned one IP address and the IP address I learned is 10.0 to 4.11 if there's anything wrong here like I should have been learning two IP addresses or that's not the right IP address then we just need to know okay we go to the DCP pool we fix the string and then move along with our business so but but the fact that I learned anything means that lease option 43 is has been at least you know somewhat configured if I don't see any lines then either option 43 is not added at all or it's like so insanely mangled that it has no idea what the heck it's talking about but again I always need to go to the DSP pool to show run section deep speed and we would either add or fix the option 43 the statement so you just need to know how to format that option 43 hex string I talked about that and video series one I'm not going to rehash that here hopefully you know how to do that by this point in your studies okay if we're doing Viet dhcpv6 option 52 if you really wanted to validate that you have to do a debug thing is again this is this would have to be configured on the windows 2012 server there should be no expectation of troubleshooting that one okay primary secondary tertiary we might be asked to on a per ap basis configure a primary secondary we really don't do tertiaries because we don't have that many controllers and so I just need to verify okay are the controllers properly added to the AP show cap web client config is our command for that so let's see if le p1 has one show camp web client config show there we go and in this case I actually do I have a primary so this these mo are names and more IP addresses are the primary secondary tertiary controllers in order there you want to make sure that the appropriate IP address and the appropriate system name are in there if that's the case we'll send it a discovery because you get a discovery response and life should be good if anything's missing if anything's wrong you would do cap web sorry cap went ap primary base cc1 1004 11 cap womp AP secondary base and so on tertiary base would be the last one if you ever got into that which we don't so that's a pretty easy one and you get as long as we have layer 3 connectivity the discovery request you get their response should come back the final discovery method that we have is usually not something that we trouble shoot although it can cause us to join controllers that maybe we didn't anticipate joining and that's the last known controller list the thing here is that you know we don't have this until we've already joined up to a controller so usually what you're troubleshooting is at the beginning of the lab trying to get those ap join ApS join for the first time and if that's the case well you know we don't really have a last known controller list because we've never joined now what about if let's say that we wanted to discover and join controller one but our ap somehow learned about control or two and is joining controller two and now we maybe we fix the discovery process that was making it not learn about controller one so it is learning about controller one but it has controller two and it's last known controllers list and controller two seems to be more preferred for whatever reason so it still keeps going to controller too even though it is now discovering controller one in that case we can clear the cap why private config to forget about that list so that the next time it comes up it doesn't know about controller - and it should hold hopefully only learn about and join controller one but we can see this in show cap web client config show cap web client config same fan command that we did for the primary secondary but to keep on going down we look at for this configured switch list this is the list that you would see on an AP for its last known controllers and so it will send these controllers discovery requests if you need to get rid of that it would just be a clear cap web private config enter reboot and then it should come back up it won't have known that just be aware that this will you know wipe out you know this configuration as well and so if you have this configuration that this should've been a problem to begin with but just know that it does wipe that out so those are all of our different methods of discovery how to validate if those methods of discovery are actually working and then you should be able to figure out how to fix whatever config issue was was making things wrong or add whatever you need to add so at this point we should be able to realize okay yes discovery is working and again if these discovery methods are configured but you're still not learning the the controller you're not seeing your your ap attempting to join the controller maybe there's a layer three issue you know where we yeah we know where to send the request but the request can't get there their request can't give back so if if we know the methods are good but we still don't see our ap trying to join you know look for ACLs on the network on the wired network that probably is look for you know routing issues default gateways you know anything that would explain why we're not you know getting that information back from the controller or getting it to the controller so at this point we we complete the discovery phase and again we use all the methods we might get multiple responses back we might get one response back but whatever list of responses we get we're gonna put it in an ordered list and then try to join the most preferred controller first if that doesn't work we work our way down the list now what if we see one of the next problems that we might run into is that our AP is not trying to join the control that we wanted to join us trying to join some other controller and so it's either going to be because we didn't discover the controller that we wanted to discover or that these other controllers are just more preferred and so again we already looked at validating discovery so we should be able to sort of sort that out and then make sure that the in the AP join stats you can bet out did the the did the controller send a discovery response back if not usually the the reason for that is that there's no ap manager interface on the controller let's make sure to sent a discovery response back and then we want check just the the preference processes here so if you if you're supposed to discover more than one controller but prefer to join one over the other that one that we prefer either has to be a primary secondary tertiary apparate P primary secondary tertiary or it has to be a master controller there really is no other deterministic way for us to control which controllers are joined because we can never really control how many ApS are on each controller at any given moment that's the last method so it's a simple verification of you know is the controller configured as a primary secondary tertiary and the AP maybe I don't know if they they would do this but maybe they pre-configured a primary secondary tertiary controller on your AP so you didn't really think to look there because you didn't configure it but it's already there so choke a pipeline config would validate if there's a primary secondary tertiary but outside of that look to see if the controller in question that's you know bringing your your ap over to it as opposed to the control you want to join see if that other controller is a master controller and we can see this in the CLI we can see it in the GUI in the GUI it's under controller advanced master controller mode if that box is checked it's a master controller and it's going to want to suck all the APS over to it in the CLI it would be under a show networks summary I believe but it's sort of buried Cisco aap default master is is the the output there so if it is you just and it should not be a master controller you turn it off if it needs to be a master controller but you still need to join to a different controller you either need to not discover that controller or you need to configure the preferred controller to be a primary secondary tertiary on your ap those are really the only options available to us

Channel: Network Dojo

Views: 1,751

Keywords:

Id: aHjafKJkC9U

Length: 21min 54sec (1314 seconds)

Published: Tue Jan 08 2019