Hello, We just cutover to AOS 8 (Mobilty Master, Backup MM and Local 7240XM controllers). We had our new controllers setup in a lab / test environment and put them into production yesterday. (So we did not use the migration tool on our old environment). The cutover is complete and went well. Only issue we really saw were some WAPs (all different models that we have, all different locations, no commonality that we could tell) not establishing their *seconday* tunnels. Not a show stopper, so we opened a TAC case and are monitoring the new enviornment today. We are running 220.127.116.11 Today I was updating my notes on useful commands and ran the command: show mon-serv-lc-table from the Mobility Master, all 3 of our local controllers is showing Bootsrap Status: Micro_Bootsrap_ongoing (we have them in a cluster). The uptime on the controllers and WAPs is as expected, so they aren't rebooting in the traditional sense. No user complaints. But it doesn't seem right. Has anyone else seen this behaviour? I've looped TAC in but figured I could check with the community too.
I am not familiar with this exact issue.
You mention the uptime looks correct which is good. Bootstrapping will not affect the uptime that is shown. Bootstrapping is where the radios turn on and off to try and reconnect to the controller. The higher the bootstrap count the higher the issue. - this is for access points.
I would imagine it is similar to the controllers. Obviously not turning off their radios, but if there is packet loss for more than 8 heartbeats this COULD POTENTIALLY be the issue.
I am not sure if this is relevant to your issue but I hope it helps.
TAC says we were under sized on the number of controllers. That we didn't have enough controllers to accomodate standby tunnels for each WAP. ... They said " Once we take care of the AP capacity with the additional hardware, micro_bootstrap state will also be taken care."
APparently when you go to AOS8, standby controllers COUNT towards capacity, in AOS 6 they did not count.
So... we addded a couple additional controllers AND we upgraded to 18.104.22.168 (dashboard display problem that was supposed to be fixed in 22.214.171.124). But we are still seeing the micro bootstrapping.
So the ball is back in TAC's court for analysis.
This is what TAC came back with b/c we still see micro bootstrapping when we do show mon-serv-lc-table
"Here is the update from our end on the “MICRO_BOOTSTRAPPING” status.
As indicated earlier, this is not an issue. This means that we keep the sockets open in case we are receiving AMON feeds from the MDs for which we need to boot strap data. In case we get all the data we close it after 3 mins.
This is because AMON is UDP data which is unreliable. Stats can come late or never reach MM at all for which we then bootstrap data.
So, the “MICRO_BOOTSTRAPPING” status can be ignored. "
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2020 Hewlett Packard Enterprise Development LPAll Rights Reserved.