The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
RRM RF Grouping is a central function for RRM. RF Grouping forms the basis for two management domains within the RF Network - the administrative and the physical.
Administrative domain–For RRM to work properly it must know which APs and controllers are under our administrative control. The RF Group name is an ascii string that all controllers and APs within the group will share.
Physical RF Domain–In order for RRM to calculate channel plans and power settings it is essential that RRM be aware of the RF Location of our APs and their relation to one another. Neighbor messaging uses the RF Group Name in a special broadcast message that allows the APs in the RF group to identify one another and to measure their RF Proximity. This information is then used to form RF Neighborhoods (A group of AP’s that belong to the same RF Group that can physically hear one another’s neighbor messages above -80 dBm) within the RF Group.
Each RF Group must have at least one RF Group Leader per band. The RF Group Leader is the physical device responsible for:
There will be a minimum of two RF Group Leaders, one for each band 802.11b and 802.11a (2.4 and 5 GHz) respectively. While RF Group Leaders for different bands can coexist on the same physical WLC, they often do not. It's also not uncommon for there to be more than one group leader per band in larger systems that have geographic diversity.
Two modes of RF grouping algorithm exist in the system today. RF Group Leaders can be selected automatically (legacy mode) or assigned statically. Both methods of assignment were overhauled with the addition of static RF Grouping in version 7.0 of the CUWN code.
When the WLC initializes as new, it creates a unique Group ID using the IP address of the WLC and a Priority Code. The Priority Code is assigned based on the controller model and MAX license count (hardware limit) to create a hierarchical model and ensure that the controller with the most processing capacity is assigned the job of GL (Group Leader). The Group ID and the RF Group Name will be used together in messages to other WLC's and AP's to identify them. Devices having the same RF Group Name will interoperate as members of the same RF Group.
The current controller hierarchy is as such:
8500 > 7500 > vWLC(large) > 5520 > 5760 > WiSM2 > 5508 > vWLC(small) > 3850 > 2500
Note | See full table below along with RF group scalability numbers below. |
When comparing Group IDs for leader election, the priority code is primary criteria and IP address is secondary. For instance, if there are 3 other controllers, none of which has the same or higher priority code than myself - I become the Group Leader. If all 3 have the same priority code as myself, then the one with the highest IP address wins and assumes the GL role.
For two WLCs to form an RF Group there is an infrastructure as well as OTA (Over The Air) component:
WLCs must be reachable to one another on the distribution network
They must each also have at least one AP that can hear the other’s NDP messages above -80 dBm
The distribution network communicates over unicast UDP:
|
Source Port |
Destination Port |
---|---|---|
RRM Manger 11b(11a) |
12134(12135) |
12124(12125) |
RRM Client 11b(11a) |
12124(12125) |
12134(12135) |
The OTA component relies on two functions NDP - Neighbor Discovery Protocol and collection of off channel metrics. Think of NDP as the Off Channel TX cycle, and monitoring of off channel metrics as the off channel RX cycle. Both NDP and monitoring are critical to the topic of RF Grouping and RRM in general, so we'll discuss them here before going any deeper.
One of the most unique things about Cisco's RRM implementation is that it uses Over The Air (OTA) messages and runs centralized even in large deployments. This gives us the advantage of being able to monitor and manage all APs and their RF experience from a single point in the network. Not only manage - but understand how every AP relates to any other AP in the RF Group/Neighborhood. This is unique in the industry as most other implementations run AP to AP at the edge in a distributed fashion with only configuration elements being managed centrally.
Neighbor Discovery Protocol or NDP, is sent from every AP/Radio/Channel every 60 seconds or less. The NDP packet is a special broadcast message that APs all listen for and it allows us to understand how every radio on every channel hears every other radio. It also gives us the actual RF path loss between APs.
Neighbor messages are sent to a special Multicast address of 01:0B:85:00:00:00, and are done so:
For 802.11b this means that the message is sent at power level 1 (always the highest power for a particular radio) at 1 Mbps, and for 5 GHz radio's 6 Mbps. This function is hard coded into the radio firmware, there is no user control. NDP power and modulation is not changed by user configured data rates or power levels.
For 802.11b this means that the message is sent at power level 1 (always the highest power for a particular radio) at 1 Mbps, and for 5 GHz radio's 6 Mbps. This function is hard coded into the radio firmware, there is no user control. NDP power and modulation is not changed by user configured data rates or power levels.
An NDP message contains the following information:
Field Name |
Description |
---|---|
Radio Identifier |
Slot ID for the sending radio |
Group ID |
IP Address and Priority code of senders WLC |
Hash |
RF Group name converted to a hash for authentication |
IP Address |
The IP address of the sending AP's RRM Group Leader |
Encrypted ? |
Are we using Encrypted NDP ? |
Version |
Version of NDP |
APs Channel |
The operating channel of the sending radio |
Encryption Key Length |
Key Length |
Encryption Key Name |
Key Name |
Message Channel |
The channel the NDP was sent on |
Message Power |
The power (in dBm) the message was sent at |
Antenna |
Antenna pattern of the sending radio |
The forwarded message is added to the neighbor database, which in turn is forwarded to the RF group leader periodically. For each AP, each radio can store up to 34 neighbors ordered by RSSI high to low.
Post processing of this information develops 2 distinct measurements:
Neighbor entries on the controller are pruned every 60 Minutes. If a new neighbor is discovered the list is flushed and refreshed in its entirety to capture what the new neighbor can contribute.
Note | Be mindful of the pruning interval. Before version 8.2, if you disable an AP it could be up to 60 Minutes before you see it disappear from any of the displays that use the information to provide a list of neighbors for a particular AP. After 8.1 it is 5 times the channel scan interval (default 180 seconds = 15 minutes). ( Wireless>802.11a/b>general>monitor intervals>Channel Scan Interval ) |
You can observe neighbor messages over the air using a packet capture tool and filtering on the multicast address 01:0B:85:00:00:00.
Caution | Unless you use the AP sniffer mode to capture the packets the RSSI values you see in your capture tool will likely be different from what is recorded in the neighbor lists - AND - the neighbor list will quite likely have more entries than you can hear simply because the APs radio sensitivity and position are generally favorable (on the ceiling) to a mobile tool's. |
NDP is transmitted on all regulatory channels selected under monitor channels list. However DFS channels represent a special case as in order to transmit on a DFS channel a station must either be a Master, or in the case of the client - associated directly to a legal Master. In order to become a Master, an AP must monitor the channel for 60 seconds to verify that no Radar is present before transmitting on that channel. A client hearing a beacon on a DFS channel can infer that the channel is owned by a master and transmit to that Master. In order for us to transmit NDP on a channel in the DFS bands that we are not the Master of, we need to first hear either a Beacon or a directed Probe from a client in order to mark that channel as clear, then we can follow up with a transmitted NDP packet within 5 seconds. If there are no other AP's, and there are no clients on other DFS channels, we will never send an NDP on any DFS channel except the one on which we are the Master.
NDP forms the foundation for our understanding of the RF Propagation domain and inherent path losses encountered within the deployment. NDP is very important to RRM, and as such it should go without saying then that if NDP is broken, RRM is broken. NDP is used first by the RF Grouping algorithm, but also by:
TPC (Transmit Power Control) - third neighbor opinion of our NDP or the basis for calculation as in TPCv2
Rogue Detection–any AP that is either not sending NDP, or sends an unintelligible NDP is considered a rogue
CleanAir Merging and PMAC functions–CleanAir uses neighbor relations to understand if interference reports are coming from AP’s that are close enough to all hear the same interference device
All of these things require a detailed understanding of where the APs are in relation to each other in RF. And, that's what NDP does.
You can see neighbor relations in several places within the system, on the WLC select Monitor=>Access Points=>802.11a/b=>details=> RX Neighbors Information
(Cisco Controller) show ap auto-rf 802.11a/b {AP_Name}
Now that we've discussed the components, lets have a look at what happens when a brand new controller is initialized and an RF group is formed. We'll cover automatic Grouping first, and then identify how this differs with Static Grouping assignment last. See the flow chart below for RRM state machine initialization:
When a WLC is initialized for the first time the only WLC that its aware of is itself. The WLC generates the GroupID and initially assumes the roll of Group Leader taking the RF Group name entered during initial startup configuration and passing this to any connected AP's for use in their neighbor string. The new leader will have itself as a member. The WLC initializes the hello timers and begins sending over the wire to other WLCs that it knows about. The Hello message is a unicast that is sent to all WLCs stored in the RF Group History. If Auto Grouping, having just been initialized, this list is empty. If Static configuration, then the list is or will be populated by manual assignment.
For Auto Grouping, the received OTA NDP message contains the sender's WLC Group ID and RF Group Hash as well as the IP address of the senders RF Group leader. The new WLC compares all received Group IDs, and any one having a larger value than our own then becomes our Group Leader. RF Grouping completes and the election process ends. Every 10 seconds we'll receive a hello message from our Group Leader that serves as a heartbeat for the RF group. If the Hello messages stop coming - we'll assume that the RF Group has changed - and the election process begins again. By this time we'll normally have a list of WLCs to send Hello packets.
Once the Group Leader is established, neighbor lists from all members will be sent to the GL and APs in the group will be formed into RF Neighborhoods or groups of APs that are close enough to require RF Power and channel be calculated together. For another AP to belong in our neighborhood we'll need to see that APs neighbor message at -80 dBm or above. Once an AP is added to a neighborhood, as long as we see the neighbor message at or above -85 dBm it remains part of the neighborhood. Any neighbor message below -85 dBm is dropped. The neighbor list purges every 60 minutes up through version 8.0 code. In 8.1 the neighbor retention time was adjusted to match 3x the scan interval (so at default 180 seconds, the neighbor list will be purged every 15 minutes). Any AP that remains consistently below -85 dBm will be purged from the list and the neighborhood. In this way, we identify groups of APs that are in the same geographic location.
RF Neighborhoods can span multiple controllers, or a single controller can be managing multiple neighborhoods, some examples are presented here.
The default mode of RF grouping is the legacy method of forming RF Groups. You can view the current status of the RF grouping algorithm, learn the identity of the Group Leader and members, and on the RF Group leader WLC see a count of current WLC's and AP's contained in the group on the WLC:
Wireless=>802.11a/b=>RRM=>RF Grouping =>group mode
In version 7.0 a static method of selecting an RF group leader was introduced. This allows a more deterministic outcome to the grouping process. The Group ID is not needed here (Priority Code and IP address of the WLC) but the Priority Code will be compared to members; this prevents a lower capacity WLC from becoming the group leader of a higher capacity WLC.
Note | You cannot assign a 2504 to be the group leader and have a 5508 added as a member. |
Static grouping allows the user to designate a particular WLC as the Static leader, and manually add the members to be managed. Members must be in auto mode, and running a compatible version of RRM. Once the Static leader is assigned, members are assigned to it and a special join message is sent to prospective members that overrides the automatic function and provides the member with a new Group leader assignment.
Under Wireless=>802.11a/b=>RRM=>RF Grouping
Changing the group mode to leader, and hitting apply opens the member assignment dialogue. You then assign members and when complete select restart to re-initialize group leader elections for the new assignments. In order for a member to be added, the prospective member must be in Auto grouping mode - else it assumes it is it's own leader. The new Group Leader controller is automatically added as the first member. Additional members can be added manually at any time. Member controllers should stabilize within 10 minutes or so once the RF Group is restarted.
There are no rules on spectrums, meaning leaving 5 GHz in Auto, and 2.4 GHz as Static is just fine. Or do both static, but on different controllers, your choice. The sky is the limit as both interfaces are different RF Group instances. However, and this is always good advice, Cisco best practice is keep it simple.
The maximum size for an RF Group is dependent on the model of the controller and the number of APs physically connected. The maximum sizes for RF groups can be calculated using the following rules. An RF Group can contain up to 20 WLCs, and have the noted Maximum APs.
Group Leader WLC |
Maximum APs |
Maximum AP per RF Group |
---|---|---|
2500 |
75 |
500 |
WLCM2 |
50 |
500 |
3850 |
50 |
500 |
vWLC (small) |
200 |
1000 |
5508 |
500 |
1000 |
WiSM2 |
1000 |
2000 |
5760 |
1000 |
2000 |
vWLC (large) |
2000 |
2000 |
7500 |
6000 |
6000 |
8500 |
6000 |
6000 |
What happens if I exceed the RF group size? A popular question, relax, the world does not come to an end, please read on.
If you exceed the maximum allowed number of APs for a given RF Group, the group simply splits and creates a new RF Group Leader using the same RF Group Name on the controller that the AP joined to create the condition. This sounds a lot worse than it is, and in practice most folks are generally not even aware of it until they look for the RF Group Leaders and notice that there is more than one per band.
What's the downside of having two or more RF Groups? There are now more RF group leaders that have to be addressed when you want to make configuration changes (additional GLs for both 802.11a and 802.11b assuming dual radio APs). This adds some complexity, but is easily managed with controller templates and configuration audit tools. Two AP's belonging to two different RF groups will not see one another as neighbors as they have different hashes of the same RF Group name. For this reason, some planning of which AP's go to which controllers is important. It is best to plan for AP's that are co-located to be on the same controller or under the same RF Group Leader.
The RF Group Leader stores the global RRM parameters for the RF Group and if a new Group Leader is created, that new WLC's RRM configurations will govern the global group settings. If you've not taken advantage of config audit features under Monitor=>RRM in NCS or Prime Infrastructure, it is possible that you have different configurations on the new GL (the worst case scenario). This could be quite disruptive if the configurations are seriously out of synch. However if the configurations are matching, DCA and TPC will mitigate the boundary quite seamlessly.
Groups of APs that are close enough to hear one another as neighbors (above -80 dBm) should reside in the same RF Group.
If you have multiple controllers, geographically group your AP’s on like RF Groups of controllers – depending on your configuration static assignment of GL’s and members may be the best approach.
Two otherwise diverse groups of APs only require a single AP in common to join together and form a neighborhood.
If you have two groups of APs that are joined together by only a few APs, you can force a split by creating a second RF group. This will change the RF group advertised in NDP messages and separate the two groups.
In version 7.2 RF Profiles where introduced. This represented a major change to how RRM operated. RF Profiles assigned to AP groups could be configured differently from the global RF Group. Versions from 7.2 and forward are not compatible in an RF Group with older versions. About the same time Converged Access was introduced, and feature parity (RF Profiles) was not achieved immediately. Check the Cisco Wireless Solutions Software Compatibility Matrix Inter Release Controller Mobility table to ensure compatibility for mixed release integrations. Pay attention to the notes. From version 7.5 on, there are feature differences, however all can be successfully included in a single RF Grouping.
One of the great additions to make if you own a 3 series AP (3600, 3700, 3800) and can install a module is the Wireless Security Module which contains radios strictly dedicated to monitoring. There are two models of this module now, but both operate with respect to RRM in the same way - they off load the off channel functions of the serving radios to the module. This allows the serving radios to remain dedicated to the channel they are serving and increases the dwell time on each channel based on the role of the dwell (i.e. off channel, location, wIPS, CleanAir). This offloading is a benefit in almost every situation in that it brings a higher resolution to the data that is being collected with longer and more frequent dwells driving the collection. The module relies on it's own internal antenna's for collection and the antenna pattern is matched with that of an internal antenna AP model.
One caveat to this approach however is external highly directional antennas used in High Density designs (most omni patch antenna's are just fine and this does not apply to them). The data that is being collected relies on the over the air results matching what the AP and serving interfaces actually see. In a High Density solution using the Stadium antennas, this will differ significantly. For this reason, achieving a good channel plan for the antennas used in the design requires shutting down the module and collecting over the air metrics using the AP's native interfaces and antenna to develop a good channel solution. Once this has been done, freezing DCA will allow the module to continue driving benefit without negatively impacting the channel and power solution.
Data Collection at the AP level can be viewed using debugs.
debug capwap rm measurements–the output should be self explanatory. This is useful to compare the intervals of different intervals at the AP.
AP44d3.ca42.30aa#deb capwap rm measurements CAPWAP RM Measurements display debugging is on AP44d3.ca42.30aa# *Jan 14 11:36:57.403: CAPWAP_RM: Timer expiry *Jan 14 11:36:57.403: CAPWAP_RM: Interference onchannel timer expired, slot 1, band 0 *Jan 14 11:36:57.403: CAPWAP_RM: Starting rx activity timer slot 1 band 0 *Jan 14 11:36:57.419: CAPWAP_RM: RRM measurement completed. Request 2003, slot 1 status TUNED *Jan 14 11:36:57.483: CAPWAP_RM: RRM measurement completed. Request 2003, slot 1 status SUCCESS *Jan 14 11:36:57.483: CAPWAP_RM: noise measurement channel 48 noise 93 *Jan 14 11:37:06.355: CAPWAP_RM: Timer expiry *Jan 14 11:37:06.355: CAPWAP_RM: Interference onchannel timer expired, slot 1, band 0 *Jan 14 11:37:06.355: CAPWAP_RM: Starting rx activity timer slot 1 band 0 *Jan 14 11:37:06.423: CAPWAP_RM: RRM measurement completed. Request 2004, slot 1 status TUNED *Jan 14 11:37:06.487: CAPWAP_RM: RRM measurement completed. Request 2004, slot 1 status SUCCESS *Jan 14 11:37:06.487: CAPWAP_RM: noise measurement channel 52 noise 92 *Jan 14 11:37:08.711: CAPWAP_RM: Timer expiry *Jan 14 11:37:08.711: CAPWAP_RM: Neighbor interval timer expired, slot 0, band 0 *Jan 14 11:37:08.711: CAPWAP_RM: Scheduling neighbor request on ch index: *Jan 14 11:37:08.711: CAPWAP_RM: Sending neighbor packet #2 on channel 11 with power 1 slot 0 *Jan 14 11:37:08.823: CAPWAP_RM: Request id: 4011, slot: 0, status 1
For a granular look at the neighbor activity at the AP specifically: Debug capwap rm neighbors.
*Jan 14 17:29:36.683: LWAPP NEIGHBOR: NDP Rx: From 64d9.8946.7fb0 RSSI [raw:norm:avg]=[-37:-39:-38] Channel [Srv:Tx]=[1 :6 ] TxPower [Srv:Tx]=[4 :22 ]
This debug is about the NDP received from a neighbor.
NDP RX from x.x.x.x RSSI (raw:norm:avg)=(n:n:n) Channel (Srv:Tx) SRV = the channel the sending AP is serving clients on, TX= the channel the message was sent on. TxPower (Srv:Tx) Srv= the power in dBm that the AP is currently serving clients at Tx = the power in dBm that the NDP message was sent at.
*Jan 14 17:29:37.007: LWAPP NEIGHBOR: NDP Tx: Channel [Srv:Tx]=[64 :64 ] TxPower [Srv:Tx]=[2 :17 ]
NDP TX-this sends a NDP message, channel (Srv:Tx) Srv - the channel we are serving clients on, Tx - the channel we sent the NDP message on. TxPower (Srv:Tx) Srv - power in dBm we are serving clients at, Tx - the power in dBm that we sent the message at.
*Jan 14 17:29:40.007: LWAPP NEIGHBOR: skipping chan 100; not clear for DFS *Jan 14 17:29:43.007: LWAPP NEIGHBOR: skipping chan 104; not clear for DFS *Jan 14 17:29:46.007: LWAPP NEIGHBOR: skipping chan 108; not clear for DFS
Channels not clear for transmit for DFS:
*Jan 14 17:29:48.299: LWAPP NEIGHBOR: Updating existing neighbor 34a8.4eba.194f(1), rssi -51 on channel: 48 with encryption: 0 *Jan 14 17:29:48.299: LWAPP NEIGHBOR: Neighbor update 34a8.4eba.194f(avg -45), new rssi -45, channel 48
An update of a change in a neighbor's information being sent to the controller and ultimately the RF Group Leader.
Neighbor messaging issues are pretty easy to spot, if NDP is broken, then APs that are next to one another will not have a relationship.
Often the reason for trouble with RF groups is simply compatibility. Since version 7.0 of code and the introduction of Static Grouping, there have been many changes to RRM and how it behaves. Backward compatibility has been preserved where it could be, however, changes in the RRM header were required to implement some of these changes and the header version number is checked on grouping.
RRM Header version 30.0 was used through version 7.0, version 30.1 was introduced with release 7.2 and RF Profiles. 7.3 added more structure to RF Profiles and also saw the introduction of Converged Access Architecture, the header version changed to 30.2. This is the last change required for the foreseeable future.
CUWN Service |
4.2x |
5.0x |
5.1x |
6.0x |
7.0x.x |
7.2.x.x |
7.3.x.x |
CA10.1 |
7.4.x.x |
Radio Resource Management (RRM) |
X |
– |
– |
X |
X |
-1 |
-2 |
-3 |
-2 |
RF Grouping functions can be observed on the controller using the "sh advanced 802.11a/b group" command.
(controller) > show advanced 802.11b group Radio RF Grouping 802.11b Group Mode............................. STATIC 802.11b Group Update Interval.................. 600 seconds 802.11b Group Leader....................... GRP_Leader (1.2.3.4) 802.11b Group Member..................... GRP_Member (1.2.3.4) 802.11b Group Member..................... GRP_Member (1.2.3.5) 802.11b Last Run............................... 594 seconds ago
You can view the status on the WLC GUI at Wireless=>802.11a/b=>RRM=>RF Grouping:
For Automatic RF Grouping, if a WLC that you feel certain should be in an RF Group somehow will just not join, it is either because:
The RF Group size is above capacity
The RF Group Name assigned to the WLC is different
There is no network path for Hello Messages
For Static RF Grouping, if an assigned member will not join the statically assigned group leader - the most common reason is version compatibility, RF Group Name and Controller Hierarchy are high on the list to evaluate.
Useful Debugs from the WLC console
debug airwave-director error–displays all errors for RRM and RF Grouping
debug airwave-director group–shows RF Grouping activities in a steady state network, this equates to a split calculation ensuring that the RF Group still meets the criteria on size and neighbor relations.
You can force a re-grouping to occur by selecting the reset button on the Wireless=>802.11a/b=>RRM=>RF Grouping menu
Watch the RF group form
*emWeb: Jan 16 18:46:49.717: Airewave Director: Group 802.11bg attempting to remove entry C0.A8.0A.14.00.4B, IP Addr 192.168.10.20 *emWeb: Jan 16 18:46:49.717: Airewave Director: removing entry C0.A8.0A.14.00.4B from 802.11bg group *emWeb: Jan 16 18:46:49.719: Airewave Director: Group 802.11bg attempting to remove entry C0.A8.0A.1E.00.32, IP Addr 192.168.10.30 *emWeb: Jan 16 18:46:49.719: Airewave Director: removing entry C0.A8.0A.1E.00.32 from 802.11bg group
Deleting the current members
*RRM-MGR-2_4: Jan 16 18:46:49.746: Airewave Director: adding entry C0.A8.0A.08.01.F4 (500) to 802.11bg group
Current group Leader-adding itself as a member
*RRM-MGR-2_4: Jan 16 18:49:03.614: Airewave Director: Group received Join Request from 802.11bg group C0.A8.0A.14.00.4B(63131), IP addr 192.168.10.20
RF Group Leader receives a Join Request
*RRM-MGR-2_4: Jan 16 18:49:03.614: Airewave Director: Deny join request from IP addr 192.168.10.20 to 802.11bg group C0.A8.0A.14.00.4B(63131) with reason Non matching group ID
Join Denied, non matching group ID
*RRM-MGR-2_4: Jan 16 18:51:07.651: Airewave Director: Group received Join Request from 802.11bg group C0.A8.0A.14.00.4B(63131), IP addr 192.168.10.20
Second Join Request received
*RRM-MGR-2_4: Jan 16 18:51:07.651: Airewave Director: Member in join request from source IP addr 192.168.10.20 to 802.11bg group, member IP 192.168.10.20 our Id 500 srcType 75 *RRM-MGR-2_4: Jan 16 18:51:07.651: Airewave Director: adding entry C0.A8.0A.14.00.4B (75) to 802.11bg group
The request is honored and we add the WLC to the group
*RRM-MGR-2_4: Jan 16 18:56:59.958: Airewave Director: Group received Join Request from 802.11bg group C0.A8.0A.1E.00.32(63131), IP addr 192.168.10.30
The second WLC sends it's join request
*RRM-MGR-2_4: Jan 16 18:56:59.958: Airewave Director: Member in join request from source IP addr 192.168.10.30 to 802.11bg group, member IP 192.168.10.30 our Id 500 srcType 50 *RRM-MGR-2_4: Jan 16 18:56:59.958: Airewave Director: adding entry C0.A8.0A.1E.00.32 (50) to 802.11bg group
And it is added to the group–complete
*RRM-MGR-2_4-GRP: Jan 16 18:57:20.909: Airewave Director: prep to join 802.11bg group C0.A8.0A.65.03.E8(63126) due to rssi -8 *RRM-MGR-2_4: Jan 16 18:57:36.839: Airewave Director: Group 802.11bg attempting to join group IP Address 192.168.10.101, ctrl count 3
Now our group leader attempts to join another WLC whose Group ID is higher than ours - with a controller count of 3 (himself and the two new additions)
*RRM-MGR-2_4: Jan 16 18:57:36.857: Airewave Director: Group received join failure from 802.11bg C0.A8.0A.65.03.E8(63126) (192.168.10.101) for reason Not a configured static member *RRM-MGR-2_4: Jan 16 18:57:36.857: Airewave Director: Group validated join failure from 802.11bg C0.A8.0A.65.03.E8(63126) for reason Not a configured static member
But we are denied access - 192.168.10.101 is configured as a static Group leader, and we are not configured as members under that group.
Invalid IP: This suggests that the controller IP is invalid or doesn’t match against the controller system name.
Group Size exceeded: When the operational limits of a leader controller has reached either because of AP numbers or number of member controllers additions, the leader rejects addition of more controllers and display this reason for rejection.
Invalid Group order: If the grouping order is not in the way they have been formulated for reasons such as memory corruption or if the data-structures have been corrupted while transmission or a unknown controller type is attempting to join –Then this error msg is displayed.
Source Not Included: No valid source identification.
Weak Signal Strength: (Not applicable to static RF grouping) nearest neighbor is not close enough
Join Pending: When a member controller is waiting to complete and exit one RRM state to another, when it can join as a member.
Not a Manager: An unlikely scenario, When a RF group member is wrongly being acknowledged as a RF leader.
RRM Assigning: in progress
Grouping disabled: When RF grouping is switched “OFF” at the configured member
Invalid Protocol Version: If the RF member controller image is of an incompatible version or if there’s a version mismatch.
Country code mismatch: Configured country mismatch
Invalid hierarchy: if lower priority controller is trying to add higher priority controller.
Already a static leader: If trying to add a member who’s already been manually configured to be a static leader.
Already Static Member: When trying to add a member who’s already been accepted a static member of another RF leader.
Non-Static Member:
Not Intended:
Member Deletion Error: If error is specifically known to occur due to improper memory allocation of de-allocation.
RF-domain mismatch: If the RF domain of the configured member and the RF leader is different.
Split for invalid-state request: An error state if there’s a member split because of an RRM state transition that was not expected.
Transitioning to static from auto: While moving from auto to static state.
Split due to user action: When there’s a user triggered transition because of reset while modifying country code, sys-name change or other
Switch Size Exceeded: