Tag: Aruba

Aruba AOS-10

Aruba AOS-10 at a Glance

ArubaOS 10 (AOS 10) is the distributed network operating system working with Aruba Central that controls Aruba Access Points (APs) and optional gateways. With its flexible architecture, network teams can deliver reliable and secure wireless connectivity for small offices, mid-sized branches, even large campus environments, and remote workers. Working in tandem with cloud-native Aruba Central, AOS 10 provides the WLAN management and control to deliver
greater scalability, security, and AI-powered optimization.

Key Benefits:

  • Simplify the deployment and upgrade of wireless networks using a unified operating system that meets the needs of remote workers, branch offices, and large campus environments.
  • Optimize radio frequencies operation and deliver reliable and high-performing connectivity with AI-automation and machine learning insights.
  • Provide the highest levels of security with policy enforcement across wired and wireless environments and secure segmentation.
  • Unify the management of wired, wireless, and SD-WAN using Aruba Central to create a single pane of glass as part of Aruba’s Edge Services Platform (ESP).
  • Future-proof your wireless investment using a cloud-native, microservices architectural model while leveraging existing hardware

AOS-10 Architecture:

The AOS 10 architecture consists of two layers:

  • Infrastructure layer—The infrastructure layer consists of a WLAN setup that can be either a campus setup or a branch setup. Either can consist only of APs, or APs combined with gateway clusters.
  • Cloud management layer—The cloud management layer consists of Aruba Central which is a cloud management SAAS platform.

AOS10 combines both IAP and Aruba Controller based Architecture under a single Architecture. It does it as follows:

  • Aruba Central is the Management and Control Plane for both AP only and AP + Controller (AOS10 uses keyword Gateways for Controllers) based Architecture.
  • Unlike in AOS8, where AP only Architecture (IAP) was supported by Central (Cloud), while Controller based Architecture required Onprem (AirWave). The AOS10 Architecture now supports Central for both AP only and AP + Gateway based setup.
  • The IAP setup is now AP only (Standalone AP) setup without any concept of VC as all the VC functions are now pushed to Central.
  • AOS 10 removes the limitation of the number of APs and clients in a single roaming domain compared to IAP clusters. Currently, the supported AOS 10 Bridge Mode scaling recommendations are up to 500 APs and 5000 clients. With almost four times the previous recommended maximum for 128 IAPs in a cluster, this resolves several limitations in the IAP architecture. If the setup scales over 500APs, the Gateway is recommended.
  • The Gateway are no longer WLAN Gateway only, the Gateway acts as both SDWAN and WLAN Gateway, both share same AOS software image.

The following side-by-side comparison shows an example deployment before and after upgrading from an Airwave-managed IAP cluster to AOS 10 Bridge Mode.

Although Wi-Fi client traffic is handled similarly in both AOS 10 Tunnel Mode and AOS 8 Campus Mode, several important changes require planning, as highlighted in the side-by-side diagrams below.

Step 1 Wi-Fi client traffic from the corporate laptop and guest phone is encapsulated using GRE in both platforms. The AOS 10 deployment can be configured in Central to encapsulate traffic in GRE with IPsec.

Step 2 AOS 8 Mobility Conductor and AirWave appliances are decommissioned since they are not available in AOS 10.

Step 3 AOS 10 hardware requires Aruba Central for management and monitoring.

Step 4 IPsec, AMON, and SNMP traffic sent to the Mobility Conductor and AirWave AOS 8 is replaced by HTTPS traffic sent from Aruba gateways and APs.

More details: https://www.arubanetworks.com/techdocs/VSG/docs/035-campus-migrate/esp-campus-migrate-000/

Happy Reading…

Exploring Aruba 8.x API via Postman

Exploring Aruba 8.x API via Postman

Postman is a great tool to test APIs, we can make a group of API calls known as collection in Postman. The collection could also be run from CLI via Newman.

Postman has a lot of good documentation to start and test the API function. The ArubaOS 8.x though provide the swagger interface which could be directly used to test and run APIs, however the collection function on Postman provides good automation function.

I will use Postman to take a tech support logs and export it to external tftp/ftp server.

Aruba API Guide: https://www.arubanetworks.com/techdocs/ArubaOS_83x_Web_Help/Content/PDFs/ArubaOS%208.3.0.x%20API%20Guide.pdf

Difference between Params and Body in Postman:

Params correspond to the request parameters that are appended to the request URL.they are most used with GET requests. On the other hand, Body is the actual request body (usually it defines the request payload or the data needs to be processed by the request). PUT and POST requests are usually read the data from the body of the request and not from the params.

Login to Aruba Controller via Postman:

The Aruba API Guide provides good documentation on the APIs available on the 8.x version. You can also goto the Swagger Interface for the device by logging to the MM and going to the url: https://<controller-ip>:4343/api

Please note that the port number 4343 should be open on the FW and/or allowed on the controller.

I will use the post function in postman with the username and password keys in the body of the put request to login, a successfull authentication will return a UIDARUBA which can be used as a token for all the subsequent GET/SET requests after the login attempt.

In the above example I have used collection variables to enter username and password as a variable to the post function. Postman also provides option to write test scripts to capture responses and validate the success/failure of the function. We also used this script to capture the value of UIDARUBA from the response and set it as a variable for subsequent functions.

The variables are saved as Collection variables:

I am running another request in the Postman Collection to create a logs.tar file on the Aruba Controller. The Post Params and body content requirement can be captured from the controller swagger interface.

Please set the body content format as JSON.

The final Post request would be to tftp tranfer the logs.tar.7z file from the flash: to the tftp Server.

The review of the MM audit-trail logs did confirmed the command pushed for generating the logs.tar file and the tftp transfer.

Happy Reading….

SSH Aruba MM/MD via Public Key Auth

SSH Aruba MM/MD via Public Key Auth

The support of certificate base login to the MM/MD provide a good security capability of the Aruba MM/MDs.

Aruba still don’t support importing the public key directly and thus your SSH public key can only be imported into the Aruba controller using an X509 certificate. Therefore we first need to create a certificate include you public and private key.

I would use openssl to create a public/private key pair and also to generate a final Self-Signed Cert for uploading to the Aruba Controller.

I would use a Window laptop and use putty for ssh.

Installing OpenSSL on Windows Machine:

Thanks to Shining Light Production for providing an installer version of OpenSSL for the Windows Machine:

https://slproweb.com/products/Win32OpenSSL.html

You can download the Installer (MSI) from their site and its pretty easy to Install.

Once installed modify the environmental variables of you Windows Machine to use it directly from any location.

Using OpenSSL to Generate Private Key and Cert:

Use the following command to generate the Private Key with the specified key length.

Use the following command to generate a Self Signed Cert using private key and add the required inputs as prompted.

OpenSSL Command CheatSheet: https://www.freecodecamp.org/news/openssl-command-cheatsheet-b441be1e8c4a/

Uploading the Certificate to Aruba Controller:

We need to upload the Certificate to the Aruba Controller as a Public Certificate, browse and upload the Certificate:

Adding Mgmt Account Associated to the Cert:

Create the mgmt account with required access and associate the Certificate to the mgmt-account.

Using Putty to Login to the Controller:

We need to associate the private key on the PC to login to the Controller. However Putty requires the key to be in a specific format else it would give error as follows:

We would download Puttygen to convert the Private key in the format as suited to Putty.

Open Puttygen and use the load option to load the previously created private key. Once loaded Save the private key in the .ppk format using the Save Private Key option, also better to add the keypassphrase during saving.

Now that the Private key is converted to correct format, load the private key again to putty and ssh to the Aruba Controller. Find the following on how/where to load the Private Key in Putty:

We would be prompted to username and the Passphrase that you set during the key import. Enter the username that we created on Aruba Controller and enter the passphrase set during the private key import and you should login fine.

More details on how to setup it up on the Aruba 6.x Architecture:

https://wlanimp.blogspot.com/2017/04/creating-aruba-ssh-login-keys-and.html

Happy Reading…..

Aruba DHCP Option 60

Aruba DHCP Option 60 (Vendor Class Identifier)

Almost all vendors implement the DHCP Option 60 RFC(2132) Vendor Class Identifier in their own way. The DHCP Option 60 is a string that the Access Point includes in the DHCP Discovery packet to the DHCP Server.

A DHCP server can be configured to filter on received option 60 string values and forward standard or vendor specific options (Option 43) in DHCP offer and acknowledgement packets.  Filtering using option 60 allows different types of devices that require vendor-specific information to co-exist in a common broadcast domain. (Having Cisco and Aruba AP in the same subnet, the DHCP Server should be configured with DHCP Option 43 and 60 for each Vendor).

If you do not specify an option 60 for some scope, the content of option 43 is returned to any DHCP client asking for an IP address in that subnet. In general we should try to define it in the DHCP scope as it makes sure that option 43 is returned only to APs and not other clients but it also depends upon the type of the DHCP server. For example Cisco IOS based DHCP scopes allow only one option 60 string (VCI) per scope , So you may not want to use it if you have different Vendor APs in the same subnet using IOS based DHCP.There is no such limitation on the Windows Server and hence the correct procedure is to define Option 60 for each Vendor.

The string value that is forwarded to the DHCP server is dependent on the Aruba Access Points mode.


 Aruba Access Points also requires specific option 60 values to be returned in DHCP offer and acknowledgement packets for vendor specific information to be considered. The expected option 60 value being dependent on the mode of the Access Points. If the expected option 60 value is not present in the DHCP offer or acknowledgement packet, any supplied vendor specific information is ignored. 

Vendor Specific Information (Option 43):

Aruba Access Points support vendor-specific information that can be provided in offer and acknowledgement packets. The type of vendor-specific information that is supported by an Aruba Access Point is dependent on the mode. For example Instant mode Access Points can be supplied with HTTP Proxy Server (Option 148) and/or (Option 43) AirWave Server information while Campus mode or Unified Access Points can be supplied Mobility Controller information. 

AirWave Server Discovery For IAP:

HTTP Proxy For IAP:

******Please note that both the username and password are forwarded to Instant mode Access Points in offers and acknowledgements in clear text. ******

The HTTP Proxy option can be used with Instant mode Access Points that are managed by AirWave or Central. When managed by AirWave, the HTTP Proxy option can be combined with the AirWave Server Discovery option. 

Controller Discovery For Campus/Unified AP:

Lets see the DHCP Scope Configuration for IAP and Campus/Unified APs.

Windows DHCP Server Config for Unified/Campus AP:

Windows DHCP Server Config for IAP AirWave:

Windows DHCP Server Config for IAP Http Proxy:

DHCP Server Config On Aruba OS Switch:

DHCP Server Config On Cisco Switch:

Happy Reading…..

SCP Service on Aruba Mobility Controllers

SCP Service on Aruba Mobility Controllers

The Aruba Mobility Controllers support the SCP Server feature, where you can enable SCP Service on the MMs and MDs. This feature helps to transfer files between MM and MDs without any external SCP Server requirement and also helps to transfer files to and from any device running SCP client.

The command to enable/disable the service:

(Test)[MDC] (config)#service scp
(Test)[MDC] (config)#no service scp

This feature however is not a full featured SCP support. Its only supports the native SCP protocol, SFTP/WinSCP protocols are not supported. If you try to connect to it via the WinSCP GUI interface it would not work, however you can use the SCP cli command to upload/download files to the Mobility Controllers.

If you have any SCP client installed on your device, you can use the Command line to download upload the file.

Following example where I am using the command line interface of my windows laptop to download the logs.tar file from the Aruba Controller. Here x.x.x.x is the controller ip, I need to type the root admin password when prompted before the transfer will start.

C:\Users\admin>scp admin@x.x.x.x:logs.tar.7z C:\Users\admin
The authenticity of host ‘x.x.x.x (x.x.x.x)’ can’t be established.
RSA key fingerprint is SHA256:kig0wBq0xYQKZsSi/C1zvTs9eGaDXj920VjuMLxdX38.
Are you sure you want to continue connecting (yes/no)?
Warning: Permanently added ‘x.x.x.x’ (RSA) to the list of known hosts.
admin@x.x.x.x’s password:
logs.tar.7z 100% 19MB 18.8MB/s 00:01

Similarly I can use the CLI command to upload a file to the Aruba Controller. In the following command I am upload a TEST.txt file to the Aruba Mobility Controller with IP x.x.x.x. I would be prompted for the admin password of the Controller.

C:\Users\admin>scp C:\Users\admin\TEST.txt admin@x.x.x.x:
admin@x.x.x.x’s password:
TEST.txt 100% 40 6.5KB/s 00:00

More on this feature:

https://www.arubanetworks.com/techdocs/ArubaOS_82_Web_Help/Content/ArubaFrameStyles/SCP/Secure_Copy_Protocol.htm

Happy Reading….

Moving a Client to specific UAC/MD on Aruba 8.x Cluster

Moving a Client to specific UAC/MD on Aruba 8.x Cluster

The previous post cover bucketmap and UAC computation concept of Aruba 8.x Architecture.

http://the-ethernets.com/2020/09/aruba-bucketmap-uac-computation-concept/

Many a times there are situation/requirement where we would like to have control on what MD, the APs and clients should connect. This might be needed for some validation test or other use cases.

The Cluster feature does allow option to disable loadbalancing for the APs, use ap-move command, this gives you control of pointing a specific AP to a specific controller via the LMS or static configuration. However there is no straight forward method to control the clients, the Cluster feature does not have an options to disable loadbalancing feature for the clients. Also there is no client-move command as available for the APs.

There is however a method via which you can define what UAC should a station/client index be assigned. Thus giving you control of defining the UAC for a specific client/station index.

******Please note this is not a recommended practice and should not be performed regularly. This command is also disruptive and would impact other clients as well********

This method moves the client from one UAC to another, but unfortunately, it changes the UAC and Standby UAC of all clients in the same bucket index, not a single client, because UACs and Standby UACs of clients follow the bucket index.

Following are the steps:

  1. Identify the bucket index / station index for your test client.

(Test)[MDC] #cluster-debug calc-sta-uac 5a:10:5e:5a:21:c9 TEST
STA Index:178
STA A-UAC:10.1.2.36
STA S-UAC:10.1.2.35

The above command gives the bucket index / station index 178 for the client mac 5a:10:5e:5a21:c9 connected to the TEST SSID.

2. Identify the UAC ID assigned to the MD where you want to move the test Client.

(Test) [MDC] #show aaa cluster essid-all bucketmap
Bucket map for Test, Rcvd at : Tue Sep 22 08:41:14 2020
Item Value
—- —–
Essid Test
UAC0 10.17.10.10
UAC1 10.17.10.11

From the above you can see for the Test SSID, MD 10.17.10.10 is assigned ID of 0 and MD 10.17.10.11 is assigned ID of 1.

3. Identify the Cluster Leader.

From my experience I have noticed the cluster leader is assigned the UAC ID of 0, however it always better to confirm.

(Test) [MDC] #show lc-cluster group-membership
Cluster Enabled, Profile Name = “Test_Cluster”

peer 10.17.10.10 128 L2-Connected CONNECTED (Member, last HBT_RSP 75ms ago, RTD = 1.241 ms)
self 10.17.10.11 128 N/A CONNECTED (Leader)

4. From the Cluster Leader, assign the new UAC to the bucket index/station index.

(Test)[MDC] #cluster-debug bucketmap essid Test bucketindex 178 active 1 standby 0

In the above command we are assigning the bucket/station index to a new active UAC ID and Standby UAC ID. You can check the show user-table to validate the new UAC is pushed to the client.

Please note that above command has to be executed on the Cluster Leader.

******Please note this is not a recommended practice and should not be performed regularly. This command is also disruptive and would impact other clients as well********

Happy Reading….

Aruba bucketmap, UAC Computation Concept

Aruba bucketmap, UAC Computation Concept

The Aruba 8.x architecture introduced a new feature of Cluster. The Clustering is a combination of multiple managed devices (MDs) working together to provide high availability to all clients, ensuring service continuity and load-balancing feature.

The clustering feature provides :
Seamless Roaming
Client Stateful Switchover
AP and Client Loadbalancing

Cluster bucketmap/mapping table:

The Aruba Controller creates a mapping table called the bucketmap. The mapping table/bucketmap is table that provides the mapping of the station/client index to the UAC(User Anchor Controller). This table is pre-populated even before any client/user is connected to the Aruba AP.

The bucketmap is per ssid basis, each ssid has its own bucket map. The output below shows the two bucketmap for the SSID: Test and LAB_TEST

(Test) [MDC] #show aaa cluster essid-all bucketmap

Bucket map for Test, Rcvd at : Tue Sep 22 08:41:14 2020

Item Value
—- —–
Essid Test
UAC0 10.17.10.10
UAC1 10.17.10.11
Active Map[0-31] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[32-63] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[64-95] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[96-127] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[128-159] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[160-191] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[192-223] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[224-255] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01

Bucket map for LAB_TEST, Rcvd at : Tue Sep 22 06:59:44 2020

Item Value
—- —–
Essid LAB_TEST
UAC0 10.17.10.10
UAC1 10.17.10.11
Active Map[0-31] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[32-63] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[64-95] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[96-127] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[128-159] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[160-191] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[192-223] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[224-255] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01

As you can see the bucket map include variables like: SSID, UAC. Thus this bucketmap would not change until change in cluster size or any new SSID added. We can pretty much say the bucketmap is permanent and this is what allows each client to have the same UAC wherever/to any AP it connect in the network.

Once the bucketmap is computed, the Cluster leader pushes the mapping table to all the APs.

Now that the AP has this mapping table, the AP uses this to decide what should be the UAC for the client that has connected to it. When a user connects to an AP, the AP runs the hashing algorithm on the user mac address ( the algorithm uses the last 3 bytes of the client mac address) and spits out a Station index. This station index is a value between 0 – 255 and is referred against the mapping table/bucketmap to decide the UAC for the client.

Following diagram gives a brief of the process.

In the output below you see the details for the user with mac address: 20:4c:03:62:aa:d3 and IP address 10.17.11.90.

The station/client index computed for the client is: 27. The station index was referred against the bucketmap and identified that 10.17.10.10 was the UAC for this station/client.

(Test) [MDC] #show aaa cluster essid LAB_TEST users

Active Users for ESSID : LAB_TEST

BUCKET MAC IP Active UAC Standby UAC
—— — — ———- ———–
27 20:4c:03:62:aa:d3 10.17.11.90 10.17.10.10 10.17.10.11

You can also use the following command if you are aware of the client mac address and ssid name the client is connected.

(Test)[MDC] #cluster-debug calc-sta-uac 5a:10:5e:5a:21:c9 LAB_TEST
STA Index:178
STA A-UAC:10.1.2.36
STA S-UAC:10.1.2.35

Thus to summarised as explained by David Westcott in one of the Airheads forum:

https://community.arubanetworks.com/t5/Wireless-Access/UAC-Assignment-After-Client-Leaves-User-Table/td-p/536405

When the cluster is created, the cluster leader builds a bucket map for each ESSID that is part of the cluster. The cluster leader takes the total number of cluster members and assigns a number to each one, starting with 00, 01, 02… for however many cluster MCs there are. The cluster leader then creates a bucket map for one of the ESSIDS and distributes the numbers across the bucket map. Think of the bucket map as simply two lookup tables for each ESSID with 256 positions in each lookup table. The first tables is the active or UAC pointers and the 2nd table is the standby or S-UAC pointers. (This is done for each ESSID)

When the maps are created for each ESSID, they are sent to the APs. This map will be the same, as long as you do not add an MC or remove an MC from the cluster. So the APs hold the maps. When a user tries to connect to an ESSID, the AP performs a hash on the extended unique identifier (last 6 hex digits in the MAC address) of the user MAC address, and generates an ASCII number between 0-255.

Once the AP has generated the hash for the client, it simply uses the ASCII hash value and looks up that position in both the active and standby tables in the bucket map, finds the controller number 00,01,.. and cross references it to the IP address of the MC and establishes the UAC and S-UAC tunnels for the user.

Happy Reading….