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
© Copyright 2024