Auto-Provisioning Policy

This topic summarizes the auto provisioning policy commands in the CLI command structure.

Wireless devices can adopt and manage other wireless devices. For example, a wireless controller can adopt multiple access points. When a device is adopted, the device configuration is provisioned by the adopting device. Since multiple configuration policies are supported, an adopting device uses auto provisioning policies to determine which configuration policies are applied to an adoptee based on its properties. For example, a configuration policy could be assigned based on MAC address, IP address, CDP snoop strings, etc.

Auto provisioning or adoption is the process by which an access point discovers controllers in the network, identifies the most desirable controller, associates with the identified controller, and optionally obtains an image upgrade, obtains its configuration and considers itself provisioned.

At adoption, an access point solicits and receives multiple adoption responses from controllers available on the network. These adoption responses contain loading policy information the access point uses to select the optimum controller for adoption. An auto-provisioning policy maps a new AP to a profile and RF Domain based on various parameters related to the AP and where it is connected. By default a new AP will be mapped to the default profile and default RF Domain. Modify existing auto-provisioning policies or create a new one as needed to meet the configuration requirements of a device.

An auto-provisioning policy enables an administrator to define rules for the supported access points capable of being adopted by a controller. The policy determines which configuration policies are applied to an adoptee based on its properties. For example, a configuration policy could be assigned based on MAC address, IP address, CDP (cisco discovery protocol) snoop strings, etc. Once created an auto provisioning policy can be used in profiles or device configuration objects. The policy contains a set of rules (ordered by precedence) that either deny or allow adoption based on potential adoptee properties and a catch-all variable that determines if the adoption should be allowed when none of the rules is matched. All rules (both deny and allow) are evaluated sequentially starting with the rule with the lowest precedence. The evaluation stops as soon as a rule has been matched, no attempt is made to find a better match further down in the set.

For example,

rule #1 adopt ap505 10 profile default vlan 10 
rule #2 adopt ap510 20 profile default vlan 20 
rule #3 adopt ap505 30 profile default serial-number
rule #4 adopt ap505 40 p d mac aa bb

AP505 L2 adoption, VLAN 10 - will use rule #1

AP505 L2 adoption, VLAN 20 - will not use rule #2 (wrong type), may use rule #3 if the serial number matched, or rule #4

If aa<= MAC <= bb, or else default.

With the implementation of the HM hierarchically managed network, the auto-provisioning policy has been modified to enable controllers to adopt other controllers in addition to access points.

The new HM network defines a three-tier structure, consisting of multiple wireless sites managed by a single Network Operations Center (NOC) controller, The NOC controller constitutes the first and the site controllers constitute the second tier of the hierarchy. The site controllers in turn adopt and manage access points that form the third tier of the hierarchy.

All adopted devices (access points and second-level controllers) are referred to as the ‘adoptee‘. The adopting devices are the ‘adopters‘.

A controller cannot be configured as an adoptee and an adopter simultaneously. In other words, a controller can either be an adopter (adopts another controller) or an adoptee (is adopted by another controller). Therefore, a site controller, which has been adopted by a NOC controller, cannot adopt another controller.

A controller should be configured to specify the device types (APs and/or controllers) that it can adopt. For more information on configuring the adopted-device types for a controller, see controller.



The adoption capabilities of a controller depends on:
  • Whether the controller is deployed at the NOC or site
    • A NOC controller can adopt site controllers and access points
    • A site controller can adopt access points only
  • The controller device type, which determines the number and type of devices it can adopt

Use the (config) instance to configure auto-provisioning-policy. To navigate to the auto-provisioning-policy configuration instance, use the following command:

<DEVICE>(config)#auto-provisioning-policy <POLICY-NAME>
nx9500-6C8809(config)#auto-provisioning-policy test
Auto-Provisioning Policy Mode commands:
  adopt                     Add rule for device adoption
  auto-create-rfd-template  When RF Domain specified by the matching rule
                            template does not exist create new RF Domain
  default-adoption          Adopt devices even when no matching rules are
                            found. Assign default profile and default
  deny                      Add rule to deny device adoption
  evaluate-always           Set the flag to evaluate the policy everytime,
                            regardless of previous adoption status
  no                        Negate a command or set its defaults
  redirect                  Add rule to redirect device adoption
  upgrade                   Add rule for device upgrade

  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
  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