All right. Hopefully, that gave you a line-by-line run through. Let's see that in action now on at Aruba, AOS using an automation example in the next demo. In this demonstration, we will be logging into Python and going into a demo folder. I've installed Paramiko! with the same libraries, modules, classes, functions, and the same logic that we saw on the Aruba OS switch demonstration. We can go ahead and try and run it using Python 3 and mc_paramiko.py. The results display the show command that was set up in a configs folder file called test.txt. If you open this file to edit it, you can see that we're only applying the show VLAN command, but you could add more. Editing the original Python script. You can see where the call to the file was applied and the results are presented in the same way that a Aruba switch would display them. So not the best way if you want to parse the results easily as for example, like what using JSON or dictionary results that you would get from a rest API call, but it does get the job done. Let's take a look at the MC requests Python script. This script sends a different set of codes that are divided into different functions. Instead of the slide example where is all one large function and this is going to be sparced out. We have a login and logout function using the same examples we saw earlier in the slide. We also have a command function when we want to send a command to the controller or mobility conductor. When you're setting up automation, you typically send commands to collect information and then capture the output results as different variables. These variables about your wireless setup could be their devices, the device IP addresses, or the status. This could be used for routing or host appearing for example and based upon the results, you can then perform additional actions to automate your network. In this example, we are creating a new MC1 object that uses the API underscore base function. This is setup using all these parameters like IP address, username, and password to login to the device. Then we send the command function using a get method in order to collect information from the device. We could use a post method if we wanted to create additional objects on the controller, like for example, adding additional VLANs. But in this example, we're just simply collecting the VLAN information into a variable called result and then print the result variable in a JSON format before logging out. We already tried the mc_paramiko script. Now, let's go ahead and try the mc_requests script that we just examined. The result is successful. The output for the only VLAN that we had, 200 is printed in JSON and can easily be parsed for dictionaries. Now, let's go to Ansible and run the demo2.yml playbook for the Aruba controller. The first task we will call get host name to describe what we want to do. This uses the Aruba networks.aos.wireless LAN role instead of the Aruba CX switche's role. We want to get the host name so we're using the AOS API config available from the role above. We'll use the GET request with the API object being the host name found in the config_path/mobility master/my node. Lastly, we registered the output into var 1 as a variable. The next task, which is named GET host name, we'll start by using debugs to display to screen the values in var 1 dot response in order to parse and show the host name. The third task, we'll call get VLAN. This will issue the command show VLAN and register the output as variable var 2. Next task show VLAN, displays the var 2 variable as a message. Below that, we have a task configured new VLAN and SPI. That uses the AOS API config plugin, like we did for our first task. But instead of a get method will use the post method in the same config path in order to create VLAN 45 and a SPI interface, VLAN 45. Under that interface will add an IP address and mask. So you can see that with just one task, we can create multiple objects when using the AOS API config plugin. This plugin is included in the Aruba AOS WLAN role. In a task down below, we have added new wireless LAN. This is using the same AOS API config plug-in in order to use any rest API call on our controllers. We're using the post method to create a wireless LAN with the data of the ssid_profile to specify the profile name. SSID name is going to be test to WPA passphrase of Aruba 123 with the WPA 2 operation mode enabled. This example shows you how you can create a pre-shared key. But you could change that to dot1x enterprise mode. With dot1x auth profile, we're going to set that to test2_dot1x, under the AAA profile we'll name it test 2 AAA profile. Then you can assign your previously created a dot1x auth profile that was just created. Finally, you'll create a virtual_ap profile called a test2_vap. To tie the above AAA profile and the SSID profiles together. Commit will apply the configuration change to the mobility controller. This is the complete process to create a new wireless LAN. But before we run this playbook, let's take a moment and look at how you can follow the controller wireless LAN wizard to see what configurations and profiles are normally used. First, we log in to the controller using the GUI, and then a second connection will set up to the controller using the controller console. Notice that we start at the minute level. This is going to be the same starting level on the GUI as well. From the GUI, click through the configuration to the wireless LANs. Test 1 is already configured, so we're going to create a new wireless LAN and we can follow the wizard setup as SSID test 3 for employees. Leaving VLAN 1 alone, set the security to use a pre-shared key, Aruba 123. We'll change it back to WPA 2 for now. Then click Finish. Now, before we commit and apply the changes, we can go back to the controller console using Show Configuration pending, you can see commands that would normally be pushed to configure the controller. These are the same steps that we are pushing through our [inaudible] tasks in the playbook. You can see the same steps. It will create a Virtual AP profile and assign your AAA profile and an SSID profile, both of which were created above. This will create the new Virtual AP profile and assign it under the default AP group. This time, we will clear the pending configuration going back to the gooey on the controller and refreshing shows that the test three wireless LAN is no longer pending. Now, back to the Ansible playbook. Before we try and run it, we can look at the group_vars variables that are defined under the wireless group. You can see here the ansible username and password, that connection type using HTTP API, ports and SSL, although we're not validating the labs certificate. Now, we're ready to run it using the command Ansible hyphen playbook, referencing the inventory device file or devices.yml and the playbook itself demo2.yml. We didn't use the vault option for the password encryption, so no additional flags are needed. We can see the results showing the host name and some other output we'll wait while it finishes. At the bottom we should see successes for all six tasks. The host name is shown collecting VLANs and showing available VLAN configuration. We see VLAN 1, 45, 149. There is a task for creating the new VLANs and new wireless LAN. Back to the playbook, we created a new Virtual AP with a name test 2. Checking back to the controller GUI, we don't see it added there yet. On the console, however, we can see that it was configured but was not connected to an access point group. If we added that, that would complete the config. But that's good for now. Over this demo, we showed going through Ansible to automate configuration on your controllers and conductors. You should try to get familiar with the different file names in Ansible and the different options connecting via HTTP API and using Python scripts in addition to the traditional methods of using CLI and GUI options when it comes to your wireless LANs.
