WiNG 5.X How-To Guide
Auto-Provisioning Policies & Wildcards
Part No. TME-01-2013-01 Rev. C
MOTOROLA, MOTO, MOTOROLA SOLUTIONS and the Stylized M Logo are trademarks or registered
trademarks of Motorola Trademark Holdings, LLC and are used under license. All other trademarks are
the property of their respective owners.
© 2013 Motorola Solutions, Inc. All Rights Reserved.
Table of Contents
Table of Contents ............................................................................................................................ 3
1.
Overview .................................................................................................................................. 4
1.1
2.
3.
Auto-Provisioning Function .............................................................................................. 4
Configuration............................................................................................................................ 5
2.1
GUI Configuration............................................................................................................. 5
2.2
CLI Configuration ............................................................................................................. 8
Wildcards ................................................................................................................................. 9
3.1
Wildcard Function........................................................................................................... 10
3.1.1
4.
Wildcard Example ................................................................................................... 10
Troubleshooting ..................................................................................................................... 12
WiNG 5.X How-To Guide – Auto-Provisioning Policies & Wildcards
1. Overview
One of the features that make Motorola stand out from others is our capability for true zero-touch
deployments. This is accomplished by way of Auto-Provisioning policies. Auto-provisioning policies use
various metrics learned from an access point requesting adoption to determine which hardware profile
and rf-domain the inquiring access point will have applied to it. With proper planning, this means that for a
large, multi-site distributed network access points could simply be drop-shipped to each location, plugged
into their cable runs and within a few minutes have a full configuration and be placed appropriately with
no further interaction from the administrator.
The default action for a WiNG 5 controller, when adopting access points is to – unless otherwise
configured – apply the “default” hardware profile and “default” rf-domain to the device. In a simple,
standalone site with little more than a single WLAN this is sufficient, but leads to a more manual and
complicated process with a distributed network.
1.1 Auto-Provisioning Function
The policies are much like an access control list (ACL) in which rules are configured that either permit or
deny adoption based on various match criteria. These match criteria are presented to the controller by the
access point during the adoption process; the criteria WiNG 5 can match against are:
Auto-Provisioning Match Criteria
MAC Address / Range
IP Range / Subnet
VLAN
Serial Number
Model Number
DHCP Option
FQDN
CDP
LLDP
Any
When creating an auto-provisioning policy, the default action is to disable default-adoption so that unless
a requesting device matches an existing rule, it will not be adopted.
Figure 1.1 – Auto-Provisioning Policy
Page 4
WiNG 5.X How-To Guide – Auto-Provisioning Policies & Wildcards
2. Configuration
Auto-provisioning policies are applied to controllers either at the device level and an override or at the
profile level, which might be used in a clustering scenario. They can be configured either in the WiNG GUI
or at the CLI; both methods will be covered next.
2.1 GUI Configuration
Navigate to Configuration  Devices  Auto-Provisioning Policy to create a new or modify an
existing policy. Click Add:
Page 5
WiNG 5.X How-To Guide – Auto-Provisioning Policies & Wildcards
You must enter a name for the policy and click Continue to activate the policy for configuration.
Once you click Continue, the policy window for adding rules is presented; click Add to begin
adding your rules. The sections are explained below:
Page 6
WiNG 5.X How-To Guide – Auto-Provisioning Policies & Wildcards

Rule Precedence: the general rule of thumb, as with access control lists, is to count by 5’s or
10’s. Why? – because rule-based features are read from top down, until a match is found, at
which point action is taken. If an error is made in configuring the rules and you need to go back
and add an entry prior to another, you then have room to do so if you start your list at 5 or 10.

Auto-Provisioning Policy: As we are creating a new match rule, “Allow” is selected, which
means that if a rule match is made, the device reques ting adoption will be adopted and have the
specified profile and rf domain applied. If you wish for access point not to be adopted if a match is
not made, uncheck this box.

Device: Since the policy will be applying a profile and may match on factors such as “Model
Number”, you must select the type of device each rule applies to.

Match Parameters: The dropdown allows you to choose from the list of match criteria listed
before in section 1.1.

Map to Profile / RF Domain: The dropdowns allow selection of the desired hardware profile and
rf domain for the device.
As stated before, once your provisioning policy is created, it must be mapped / applied to a controller
device either as an override or to a profile used by the controller(s).
To apply to a specific controller, navigate to Configuration  Devices and select the desired
controller, then Edit. Then in the Device pane, navigate to Profile Overrides  Adoption and select
the provisioning policy from dropdown under Auto-Provisioning Policy.

Note – In the GUI you must select b oth profile and rf domain for the rule b efore the OK b utton b ecomes
active. However, these may b e applied individually at the CLI. This will b e important during the Wildcards
section.
Page 7
WiNG 5.X How-To Guide – Auto-Provisioning Policies & Wildcards
2.2 CLI Configuration
CLI Auto-Provisioning Options
nx9000-1# configure terminal
Enter configuration commands, one per line.
End with CNTL/Z.
nx9000-1(config)# auto-provisioning-policy TME-PROVISIONING
nx9000-1(config-auto-provisioning-policy-TME-PROVISIONING)# show context include-factory
auto-provisioning-policy TME-PROVISIONING
no default-adoption
nx9000-1(config-auto-provisioning-policy-TME-PROVISIONING)# ?
Auto-Provisioning Policy Mode commands:
adopt
Add rule for device adoption
default-adoption
Adopt devices even when no matching rules are found.
deny
Add rule to deny device adoption
no
Negate a command or set its defaults
clrscr
Clears the display screen
commit
Commit all changes made in this session
do
Run commands from Exec mode
end
End current mode and change to EXEC mode
exit
End current mode and down to previous mode
Assign default profile and default rf-domain
help
Description of the interactive help system
revert
Revert changes
service
Service Commands
show
Show running system information
write
Write running configuration to memory or terminal
nx9000-1(config-auto-provisioning-policy-TME-PROVISIONING)# adopt ap71xx precedence 10 profile
<profile_name> rf-domain <rfdomain_name> cdp-match <cisco_switch_hostname>
The basic CLI configuration is straight forward and similar in logic to the GUI configuration. However, as is
usually the case with CLI’s, there are more powerful options available that allow for more flexibility to
auto-provisioning policies.
Rules at the CLI level can be applied separately for profile and rf-domain. That is to say, a rule could be
created to apply a profile based on a CDP match and then a second rule could apply the rf-domain based
on a different factor, such as FQDN. An example is shown below:

Note – The ab ility to specify only one policy parameter (either profile or rf-domain) at the GUI level is in
progress as of this writing and will b e availab le in a future release.
Page 8
WiNG 5.X How-To Guide – Auto-Provisioning Policies & Wildcards
This ability to separate out the elements adds flexibility and becomes almost necessary when discussing
the next powerful capability of auto-provisioning policies.
CLI Auto-Provisioning Options
nx9000-1(config-auto-provisioning-policy-TME-PROVISIONING)# adopt ap71xx precedence 10 profile
<profile_name> cdp-match <cisco_switch_hostname>
nx9000-1(config-auto-provisioning-policy-TME-PROVISIONING)# adopt ap71xx precedence 20 rf-domain
<rfdomain_name> fqdn <domain_name>
3. Wildcards
Before release 5.1.2, auto-provisioning could potentially require a large number of entries depending on
various scenarios. However, In WiNG 5.1.2 and later we have a wildcard feature that will make autoprovisioning of AP’s much more flexible. This now gives the user the ability to provision devices based on
a partial match of match criteria and a commonality in naming convention between the match criteria and
the profile or rf-domain to be applied.
In a WiNG 5 deployment for a large, distributed customer network, there is the potential to have many
auto-provisioning entries to manage the placement of AP’s for all the sites or for different parameters
applied to the access points themselves. The idea of the wildcards is to limit the number of entries
needed, making the configuration shorter and the deployments quicker. This embodies WiNG 5’s “Less is
More!” tag-line.
However, not all of the match criteria tags are available for the wildcard function. The currently supported
match tags for wildcards are listed:
Auto-Provisioning Wildcard Tags
$CDP
$LLDP
$DHCP
$FQDN
$SN
$MODEL
The tags are to be used as shown with all capital letters.
Page 9
WiNG 5.X How-To Guide – Auto-Provisioning Policies & Wildcards
3.1 Wildcard Function
There are three sections of the wildcard, as shown below:

Indicator – The “$” indicates the start of a wildcard for matching against

Method – The match-criteria method to be used

Portion – What portion, from a character count perspective of the match criteria to be analyzed.
In this example, the 1st – 4th characters of the hostname, as reported in CDP would be the
portion we match upon.
There are no spaces between these elements, so the above example appears as “$CDP[1:4]” (without
quotations) when typed out; this makes up our “wildcard” and it is used in place of the unique portion of
our criteria. The use of wildcards suggests that a portion of our criteria is unique, yet this portion wi ll be
common with what is used in naming either the profile or the rf-domain.
3.1.1
Wildcard Example
Take a look at the logical diagram below of a distribution center network. The two layer-2 access switches
are in different DC buildings and are used for access point connectivity to the network.
Figure 3.1.1 – Example Topology
Page 10
WiNG 5.X How-To Guide – Auto-Provisioning Policies & Wildcards
The customer wished to have the access points in DC01 trunked, with VLAN’s u,v,w applied to their trunk
ports, while the access points in DC02 are also trunked, but have VLAN’s x,y,z appl ied to their trunk
ports. The access points are being plugged into Cisco switches, so we know we can use CDP for our
match criteria. Additionally, each DC may be considered separate rf-domains. If we use our wildcard
example to configure the auto-provisioning rules, we would have something like the following:
CLI Auto-Provisioning Wildcard Example
nx9000-1(config-auto-provisioning-policy-TME-PROVISIONING)# adopt ap71xx precedence 10 profile
$CDP[1:4]-aps any
nx9000-1(config-auto-provisioning-policy-TME-PROVISIONING)# adopt ap71xx precedence 20 rf-domain
$FQDN[1:4]-rfdomain any
Now, notice the “any” at the end of our rule. This is the actual match method and we use the “any”
keyword because the wildcard itself is going to specify the method.
Wildcards are useful in many scenarios. For example, there might be multiple profiles for different
functions (sensor vs. AP) based on $MODEL (model number of the access point) or different rf-domains
to be assigned, as in our example above. In some customer scenarios, the use of provisioning wildcards
may greatly reduce the number of auto-provisioning entries that are needed.
To continue with our example, we have two different profiles created – one each for DC01 and DC02 as
well as the respective rf-domains. See below:
Profiles / RF Domains used with wildcards
!
profile ap71xx dc01-aps
interface ge1
switchport mode trunk
switchport trunk native vlan u
switchport trunk allowed vlans add u,v,w
..
..
!
profile ap71xx dc02-aps
interface ge1
switchport mode trunk
switchport trunk native vlan x
switchport trunk allowed vlans add x,y,z
..
..
!
rf-domain dc01-rfdomain
country-code us
!
rf-domain dc02-rfdomain
country-code us
Page 11
WiNG 5.X How-To Guide – Auto-Provisioning Policies & Wildcards
Notice that within our profile and rf-domain names, the first four characters ([1:4]) in the names match the
first four characters of the CDP hostname of the switches. This “common” portion is how we determine
what profile / rf-domain devices will be applied to. The remainder of the profile / rf-domain name can be
prepended or appended within the rule, as seen in our rule with the “-aps” portion. So from this one
gathers that it is necessary to have at least part of the name of our profile and / or rf-domain the same as
the part of the match criteria that we want to take action on.

Note – Presently it is not possib le to create wildcard rules in the GUI, b ecause specifying the profile and rfdomain names is done b y way of a dropdown of existing names. This is an advanced feature that can only
b e configured in CLI. However, once auto-provisioning has b een configured using wildcards, those wildcards
will b e seen in the auto-provisioning configuration screens of the GUI.
4. Troubleshooting
When access points are not adopting as expected, troubleshooting of the adoption process can be done
at the GUI or CLI. Navigate to Statistics  System  Pending Adoptions to see a list of devices that
have queried the controller and are waiting for adoption. Below we see that the adoption of this specific
access point has been denied due to a rule in the auto-provisioning policy:
In this case, there were no matching rules, so the default action of “no default-adoption” takes
precedence and the AP is denied.
Page 12
WiNG 5.X How-To Guide – Auto-Provisioning Policies & Wildcards
At the CLI, issue the following commands to monitor the adoption process:
CLI Auto-Provisioning Options
nx9000-1# logging monitor debugging
nx9000-1# debug cfgd join
nx9000-1#Jan 07 07:47:59 2013: USER: cfgd: rx LOAD_INFO_REQ from (19.5D.63.00, 51560, ('i',
24576, '192.168.243.4'))
Jan 07 07:47:59 2013: USER: cfgd: tx LOAD INFO_RSP with load-factor 0x00002800 to (19.5D.63.00,
51560, ('i', 24576, '192.168.243.4')) [mac: B4-C7-99-5D-63-00]
Jan 07 07:48:00 2013: USER: cfgd: rx JOIN_REQ from (19.5D.63.00, 51560, ('i', 24576,
'192.168.243.4'))
Jan 07 07:48:00 2013: USER: cfgd: Debug str: Known controllers: (12.07.45.FD, 18)
replies:sw 12.07.45.FD pref:False load 10240
Load info
Jan 07 07:48:00 2013: USER: cfgd: adoption_mode = IP - 192.168.243.4:96
Jan 07 07:48:00 2013: USER: cfgd: Rejecting JOIN from AP6522[B4 -C7-99-5D-63-00] based on autoprovisioning policy
Jan 07 07:48:00 2013: USER: cfgd: Adoption denied, sending join failure to (19.5D.63.00, 51560,
('i', 24576, '192.168.243.4'))
Above we can see the load inquiry from the access point to the controller, the load response and
eventually followed by the rejection and the reason; that is “based on auto-provisioning policy”.
Page 13
WiNG 5.X How-To Guide – Auto-Provisioning Policies & Wildcards
Page 14