Deploying Devices

Let's start with the anterior workflow, the deployment of devices with HPE Aruba Networking Central. The example workflow illustrated below consists of four steps:

Creating a new template group
Uploading a template to the group
Adding variables for the devices
Assigning the devices to the group

🚧
Template mode is not available with AOS-10. The workflow highlighted here is for AOS-8 based devices.

👍
This is an example workflow; as such it is intentionally prescriptive and tailored to fit a certain scenario. The Ansible modules used in this workflow each provide additional capabilities to suit various deployment scenarios. Instead of following the prescribed steps, you could alternatively, for example:
i. Clone an existing template group
ii. Update an existing template
iii. Update or replace variables for devices

📘
For more information on the capabilities of each module, please look at the module documentation in our GitHub repository. The documentation for each module covers the module's capabilities in depth.

Workflow Prerequisites

HPE Aruba Networking Central Ansible Collection installed:

ansible-galaxy collection install arubanetworks.aruba_central

Devices imported beforehand into Central by Activate

Creating a Group

Firstly, we'll create a template group. This task uses the central_groups module which is used to create a template group for wired and wireless devices.

- name: Create a new group
      central_groups:
        action: create
        group_name: new-group
        group_attributes:
          group_password: admin@12345
          template_group:
            wired: True
            wireless: True

📘
The attributes wired: True and wireless: True in the template_group dictionary indicate that the created group is a template group using templates for both wired and wireless devices.

Adding a Template

Step two is to upload a template to the group. In order to do this, we'll create a template file and write an Ansible task to upload it.

An example template for an AOS-Switch device is shown below. Note that some information in the template, namely the SHA-1 hash of the admin user's password, has been redacted.

AOS-S template

%_sys_template_header%
hostname "%_sys_hostname%"
%_sys_module_command%
no cwmp enable
include-credentials
password manager user-name "admin" sha1 "xxxxxxe75asddfdaf415cxxxxxxfe21axxxx"
timesync ntp
ntp unicast
ntp server-name "time.google.com" iburst
ntp enable
time timezone -420
ip client-tracker
interface 1
   name "To_SW2"
   exit
interface 24
   name "Uplink_BGW"
   exit
snmp-server community "Aruba123" unrestricted
snmpv3 engineid "%_sys_snmpv3_engineid%"
vlan 1
   name "Management"
   untagged %_sys_vlan_1_untag_command%
%if _sys_use_dhcp=1%
   ip address dhcp-bootp
%endif%
%if _sys_use_dhcp=0%
   ip address %_sys_ip_address% %_sys_netmask%
%endif%
   ipv6 enable
   ipv6 address dhcp full
   exit
vlan 20
   name "Employee"
   tagged 1-2,5-9,24
   no ip address
   exit
vlan 30
   name "Guest"
   tagged 1-2,5-9,24
   no ip address
   exit

🚧
All non-templated, parametrized CLI text in the template must exactly match the running configuration syntax. As such, the indentation of CLI text in the template should match the indentation in the running configuration. All CLI text in the template is case-sensitive.
A recommended best practice is to perform validation of the configuration input on the device CLI prior to adding it to the template.

In addition to creating the template, we also need to create the task to upload it. This task uses the central_templates module to upload a template text file by specifying its local path:

- name: Upload a new template file and create a new template for a given device type 
    central_templates:
      action: create
      group_name: new-group
      template_name: aos-sw-temp
      device_type: ArubaSwitch
      version: ALL
      model: ALL
      local_file_path: /home/admin/sw_template.txt

👍
The examples shown for the above step apply to AOS-S devices. You can upload templates for AOS-CX switches and access points as well. Module documentation, as previously mentioned, and specifically that for the central_templates module, will provide the pertinent information.

Access Point Template

📘
Template mode is not supported with AOS-10. Sample template below is for an AOS-8 device.

As part of this workflow, we're also deploying an access point. An access point template is provided below (again, with certain values censored); it is left as an exercise to the reader to create the additional task to upload this template!

version 8.6.0.0-8.6.0
virtual-controller-country US
virtual-controller-key fdxxxxxxzzzzzzyyyyyda0542c660a35xxxxxxxxx8
name %vc_name%
terminal-access
openflow-server host internal2-ofc.central.arubanetworks.com tcp-port 443
openflow-server tls-enable
ntp-server time.google.com
clock timezone Pacific-Time -08 00
clock summer-time PDT recurring second sunday march 02:00 first sunday november 02:00
rf-band all
ams-identity xxxxxxxx689723993xxxxxxxxx5bbfaxx
report-rssi-to-central unassociated-and-associated-clients
allow-new-aps
allowed-ap aa:aa:aa:aa:aa:aa
allowed-ap bb:bb:bb:bb:bb:bb
allowed-ap cc:cc:cc:cc:cc:cc
allowed-ap dd:dd:dd:dd:dd:dd
allowed-ap ee:ee:ee:ee:ee:ee
arm
 wide-bands none
 a-channels 52,56,60,64
 g-channels 6
 min-tx-power 9
 max-tx-power 127
 band-steering-mode prefer-5ghz
 air-time-fairness-mode default-access
 channel-quality-aware-arm-disable
 client-aware
 scanning
rf dot11g-radio-profile
 max-distance 0
 max-tx-power 9
 min-tx-power 6
 disable-arm-wids-functions off
 free-channel-index 40
rf dot11a-radio-profile
 max-distance 0
 max-tx-power 18
 min-tx-power 12
 disable-arm-wids-functions off
syslog-level warn ap-debug
syslog-level warn network
syslog-level warn security
syslog-level warn system
syslog-level warn user
syslog-level warn user-debug
syslog-level warn wireless
hash-mgmt-password
hash-mgmt-user admin password hash 11111111111111111f1c4xxxxxxxxxxxxxeb2bd3f632xxf29e35xxxxxx08ezzzz
wlan access-rule default_#guest#_
 index 0
 rule alias licdn.com match tcp 443 443 permit
 rule alias twimg.com match tcp 443 443 permit
 rule alias bam.nr-data.net match tcp 443 443 permit
 rule alias js-agent.newrelic.com match tcp 443 443 permit
 rule alias symcb.com match tcp 80 80 permit
 rule alias symcd.com match tcp 80 80 permit
 rule alias digicert.com match tcp 80 80 permit
wlan access-rule default_wired_port_profile
 index 1
 rule any any match any any any permit
wlan access-rule wired-SetMeUp
 index 2
 rule any any match udp 67 68 permit
 rule any any match udp 53 53 permit
wlan access-rule %ssid_name%
 utf8
 index 5
 rule any any match any any any permit
wlan ssid-profile %ssid_name%
 enable
 index 1
 type employee
 essid %ssid_name%
 utf8
 wpa-passphrase xxxxxx1111xxxzz1111fb2bzzzzz1880ba4fxxxxx1aca2222
 opmode wpa2-psk-aes
 max-authentication-failures 0
 vlan 20
 auth-server InternalServer
 rf-band 5.0
 captive-portal disable
 dtim-period 1
 broadcast-filter arp
 openflow-enable
 dmo-channel-utilization-threshold 90
 local-probe-req-thresh 0
 max-clients-threshold 64
auth-survivability cache-time-out 24
dpi
url-visibility
wlan auth-server AS2_#guest#_
 radsec port 443
 ip naw2-elb.cloudguest.central.arubanetworks.com
 port 1812
 acctport 1813
 timeout 20
 nas-id 7xxxaaeaa1-xxcx-111z-11x1-0xxxxxx99zz
 rfc3576
wlan auth-server AS1_#guest#_
 radsec
 ip naw2.cloudguest.central.arubanetworks.com
 port 1812
 acctport 1813
 timeout 20
 nas-id 77xxxaaeaa1-zzcx-111z-11x1-0xxzzzxx99zz
 rfc3576
wlan external-captive-portal
 server localhost
 port 80
 url "/"
 auth-text "Authenticated"
 auto-whitelist-disable
 https
wlan external-captive-portal default_#guest#_
 server naw2.cloudguest.central.arubanetworks.com
 port 443
 url "/portal/scope.cust-xxxxxxxx11111111zzzzzzzzz1111111/default/capture"
 auth-text ""
 https
ids
 wireless-containment none
wired-port-profile wired-SetMeUp
 switchport-mode access
 allowed-vlan all
 native-vlan guest
 no shutdown
 access-rule-name wired-SetMeUp
 speed auto
 duplex auto
 no poe
 type guest
 captive-portal disable
 no dot1x
wired-port-profile default_wired_port_profile
 switchport-mode trunk
 allowed-vlan all
 native-vlan 1
 shutdown
 access-rule-name default_wired_port_profile
 speed auto
 duplex full
 no poe
 type employee
 captive-portal disable
 no dot1x
enet0-port-profile default_wired_port_profile
uplink
 preemption
 enforce none
 failover-internet-pkt-lost-cnt 10
 failover-internet-pkt-send-freq 30
 failover-vpn-timeout 180
airgroup
 disable
airgroupservice airplay
 disable
 description AirPlay
airgroupservice airprint
 disable
 description AirPrint
airgroupservice DIAL
 disable
airgroupservice remotemgmt
 disable
airgroupservice AmazonTV
 disable
airgroupservice allowall
 disable
airgroupservice googlecast
 disable
airgroupservice itunes
 disable
airgroupservice sharing
 disable
airgroupservice chat
 disable
airgroupservice "DLNA Print"
 disable
airgroupservice "DLNA Media"
 disable
clarity
 inline-sta-stats
 inline-auth-stats
 inline-dhcp-stats
 inline-dns-stats
cluster-security
 allow-low-assurance-devices
 per-ap-settings %_sys_lan_mac%
  hostname %hostname%
  zonename %zonename%

Setting Variables

The next step of this workflow is to upload device-specific variables so that they can be used to render the template into actual concrete running configurations to be applied to the devices.

🚧
Unlike a template, which belongs to a group, variables are associated with a device, irrespective of which group to which the device belongs.

There are two approaches to adding variables:
i. Adding variables for one device by specifying its serial number
ii. Adding variables for multiple devices using a JSON file wherein each device has a dictionary containing its variables and values.

Because this workflow performs an initial rollout for multiple devices, it makes sense that we employ the second approach to upload variables for our devices.

The example JSON file shown below is a variables file containing variable definitions for an AOS-S switch and an access point. Note that each key in the overarching dictionary is a device's serial number, and the corresponding value is a dictionary containing the device's variable definitions in a key-value format. Like with the example templates before, certain values here have been redacted.

{
  "CNXXXXXXXD": {
    "_sys_serial": "CNXXXXXXXD",
    "_sys_lan_mac": "aa:aa:aa:aa:aa:aa",
    "_sys_gateway": "",
    "_sys_hostname": "SW1",
    "_sys_ip_address": "",
    "_sys_module_command": "module 1 type jl261a",
    "_sys_netmask": "",
    "_sys_oobm_command": "",
    "_sys_snmpv3_engineid": "00:00:00:0b:00:00:b8:83:03:d5:fc:a0",
    "_sys_stack_command": "",
    "_sys_template_header": "; JL261A Configuration Editor; Created on release #WC.16.08.0003\n; Ver #14:27.6f.f8.1d.9b.3f.bf.bb.ef.7c.59.fc.6b.fb.9f.fc.ff.ff.37.ef:04\n",
    "_sys_use_dhcp": "1",
    "_sys_vlan_1_tag_command": "",
    "_sys_vlan_1_untag_command": "1-28",
    "community": "Aruba123",
    "dhcp": "true",
    "dns": "1.1.1.1",
    "gw": "10.1.1.1",
    "ip": "10.1.1.14",
    "mask": "255.255.255.0",
    "ntp_server": "time.google.com",
    "test": "0",
    "timezone_seconds": "-420"
  },
  "CNYYYYYYYD": {
    "_sys_lan_mac": "bb:bb:bb:bb:bb:bb",
    "_sys_serial": "CNYYYYYYYD",
    "ssid_name": "Employee-test",      
    "vc_name": "Instant-AP-VC",
    "hostname": "IAP-1",
    "zonename": "Ground-Floor"
  }
}

🚧
The variables _sys_lan_mac and _sys_serial are mandatory and must be included in every template and in every device's variable definitions.

In addition to defining our variables file, we'll need a task to upload the variables file. This task uses the central_variables module:

- name: Create/set template variables for all/multiple devices using a JSON file   central_variables:
    action: create_all
    local_file_path: /home/admin/variables.json

Moving Devices to a Group

Lastly, to provision our devices, we'll move them into the group that now contains the appropriate templates. The act of moving devices takes them out of one group and places them in another. When the device is placed in a template group with an applicable template, the template is automatically applied, and the variables associated with the device are used in conjunction with this template to seamlessly deploy the resultant running configuration to the device.

📘
When a device is imported into Central, it is automatically placed in the default group.

In general, it is recommended that a device is moved to a newly created group after the group contains the applicable template and all the variables parametrized in the template have been defined for the device.

This task example uses the central_devices module to move devices to a group using their serial numbers.

- name: Move devices to a group
      central_devices:
        action: move_devices
        group_name: new-group
        device_serial_list:
          - CNXXXXXXXX
          - CNXXXXXXYY

Success and Debrief!

And that's it! If you've followed this tutorial as directed, your playbook should contain five tasks.

To summarize briefly, the requisite conditions for successful device deployment are that :

a template group for the device type (i.e. wired or wireless) exists

the template group contains a template applicable to the device
the device has variables associated with it
the device is situated in the template group

🚧Template mode is not available with AOS-10. The workflow highlighted here is for AOS-8 based devices.

👍

📘

Workflow Prerequisites

Creating a Group

📘

Adding a Template

AOS-S template

🚧

👍

Access Point Template

📘

Setting Variables

🚧

🚧

Moving Devices to a Group

📘

Success and Debrief!

🚧
Template mode is not available with AOS-10. The workflow highlighted here is for AOS-8 based devices.