Search the Community
- Global Forums
- Airheads Channel Group - UK and Ireland
- Airheads Channel Group (German speaking)
- Airheads Channel Group - France
- Airheads Channel Groep – Nederland
- Airheads Channel Group - Italy
- Airheads Channel Group - Taiwan
- Airheads Channel Group - Singapore
- Airheads Channel Group - Malaysia
- Airheads Channel Group – Norway
- Airheads Channel Group South Africa
- Airheads Channel Group Bechtle
- ClearPass Recipe Review
- ClearPass Recipe Submission
- Admin Tool - Assign Role in Bulk
- Admin Tool - User Search
- CWNP Conf 2015
- Airheads Conference Vegas 2015
- Wlan Pro Conference 2015
- Airheads Conference Shanghai 2014
- WLAN Pro Conf EU 2014
- CWNP Conference 2014 (Sep 22 - 24)
- Airheads Local 2014
- Wireless Field Day 7 (Aug 6-8, 2014)
- Black Hat 2014 Contest
- Airheads EMEA Italy 2014 (June 9 - 13)
- Americas Airheads Conference 2014
- WLAN Professionals Summit 2014
- Airheads Roadshow 2013
- EMEA Airheads Conference 2013
- APJ Airheads Conference 2013
- Americas Airheads Conference 2013
- Americas Airheads Conference 2012
- APJ Airheads Conference 2012
- EMEA Airheads Conference 2012
- Airheads EMEA 2012 Contest: How to Enter - Contest Terms & Conditions
- Airheads EMEA 2012 Contest: Create your Entry to Win Here!
- Airheads Conferences Prior to 2012
- Americas Airheads Local Events 2012
- EMEA Airheads Local Events 2012
- Wireless Field Day 3 @ Aruba Networks
- Wireless Tech Field Day 2- Silicon Valley
- Wi-Fi Mobility Symposium- San Jose, CA USA
- SDN Apps
- Connector Translation Testing area
How can we find the cloud activation key for Aruba switches?
We can use the following command to find the cloud activation key :
Aruba# show activate provision
Configuration and Status - Activate Provision Service
Activate Provision Service : Enabled
Activate Server Address : device.arubanetworks.com
Activation Key : LKMNOPAB
The above command applies to the following switches:
Aruba 2920 Switch Series—WB.16.02.0012 or later
Aruba 2930F Switch Series—WC.16.02.0012 or later
Aruba 2540 Switch Series—YC.16.02.0012 or later
...05224 activate: Zero-touch provisioning enabled; connecting to Aruba Activate server to provision system...
I have the same problem with an 2530-24g.
1. Is the clock reflecting correct time on the switch ? -> yes
2. Do you have DNS server configured on the switch ? -> yes
3. What is the firmware running on the switch ? YA.16.04.0009
4. Attach the output for :
Keys: W=Warning I=Information M=Major D=Debug E=Error ---- Reverse event Log listing: Events Since Boot ---- I 12/18/17 11:34:11 04611 job: Job Scheduler enabled I 12/18/17 11:33:58 05101 amp-server: AMP server configuration is disabled due to first configuration. I 12/18/17 11:33:57 05226 activate: Successfully resolved the Activate server address device.arubanetworks.com to 184.108.40.206. I 01/01/90 01:00:45 05225 activate: Loading security certificates and synchronizing time with NTP. I 01/01/90 01:00:45 05224 activate: Zero-touch provisioning enabled; connecting to Aruba Activate server to provision system. I 01/01/90 01:00:45 03783 dhcp: DHCP server did not offer all the DNS parameters on Primary VLAN I 01/01/90 01:00:45 00025 ip: DEFAULT_VLAN: ip address 192.168.100.110/24 configured on vlan 1 I 01/01/90 01:00:45 05177 ip: Setting IP address 192.168.100.99 as default gateway. thank you, thomas
This article explain steps to upgrade the code on the controller.
We can upgrade the OS on the controller either through WebUI or through the CLI.
We can use the following methods to upgrade the code on the controller:
- Local File (This option is available while upgrading through WebUI)
NOTE: It is strongly recommended to go through the Release Notes available on the support site before upgrade to find out any upgrade caveats or known issues.
Environment : This article applies to all the controller models and OS versions.
- Navigate to Maintenance> Image Management
- Choose the upgrade method
- Enter the Server IP address in case TFTP, FTP or SCP is used for upgrade
- Enter the image file name
- Choose the partition to upgrade. It is always advisable to upgrade to the non-default boot partition first so that we can revert to the old code in case something unexpected occurs.
- Select if you want to reboot the controller after upgrade. Unless reloaded, the new code will not take effect
- Save the current configuration before reboot
- Click Upgrade
Execute the following commands on the CLI to upgrade the code –
(Aruba)# copy tftp: <TFTP server IP address> <image file name> system: partition <0 or 1> //for TFTP
(Aruba)# copy ftp: <TFTP server IP address> <username> <image file name> system: partition <0 or 1> //for FTP
(Aruba) #copy scp: <SCP host IP address> <username> <image file name> system: partition <0 or 1> //for SCP
Once the image is uploaded in the flash, save the configuration and reload the controller.
This will help us to enable debugging for a user/AP and for any of the process on the controller.
We enable debugging mainly for troubleshooting, this will give a syntax on how the user/AP and process debug can be done on 8.x.
From 8.x the debugging command syntax has been modified as below:
(Aruba) ^[mynode] (config) #logging user-debug <aa:bb:cc:dd:ee:ff> level debugging
(Aruba) ^[mynode] (config) #logging ap-debug <ap-name> level debugging
For process debugging:
(Aruba) ^[mynode] (config) #logging security level debugging
(Aruba) ^[mynode] (config) #logging network process dhcpd subcat dhcp level debugging
We can verify the debugging only if we give write memory:
AP/User debugging can be verified by the below command:
(Aruba) [mynode] (config) #show debug
Facility Level Debug Value Sub Category Process
-------- ----- ----------- ------------ -------
ap-debug debugging Test N/A N/A
user-debug debugging aa:bb:cc:dd:ee:ff N/A N/A
Process debugging can be verified by the below command:
(Aruba) [mynode] (config) #show logging level verbose | include debugging
network debugging dhcp dhcpd
security debugging N/A N/A
- Find more articles tagged with:
- arubaos 8.x
- Mobility controller
On upgrading to Aruba OS 8.x from 6.x, we cannot delete VLAN directly once configured on the controller.
Generally in previous codes after removing IP from the VLAN, we can delete the VLAN directly as shown below:
However with 8.0.x, we cannot remove the VLAN simply from the controller. A new interface is created as soon as we create a VLAN. If we execute the above steps, we will get an error:
Reason for this is that a different interface is created as soon as we create a VLAN. That interface needs to be removed as well before removing the VLAN ID. As shown below:
What is IP address classification feature with Aruba OS 6.5 ?
- IP classification service helps in identifying the malicious IP addresses and the origin.
- This feature once enabled will cause all L3 traffic to be classified. All the sessions shall be classified with reputation (either malicious or clean) and geolocation (as originating from a specific location, which can be either country or more specific city) information.
- When a new session is received, the source and destination IP addresses are fetched and table lookup is done for both the IP addresses to get the reputation/location information of these IP addresses.
- Aruba Networks is partnering with Brightcloud to get the IP reputation and geolocation database. These databases are updated frequently through periodic sync from the servers through SSL (aruba.brightcloud.com)
- The IP reputation database contains all the current known IP addresses associated with various malicious activities.
- The geolocation IP database will be used to determine the geographical location of the IP address from where the traffic is received or to which the traffic is sent.
Enabling IP classification enables both ip reputation and geolocation service . It’s a controller specific configuration
(config) #firewall ip-classification
Advanced Services > Stateful Firewall > Global Settings > Enable IP classification
Note: This requires Web-CC subscription license
- Find more articles tagged with:
- arubaos 6.4
- geolocation service
- ip classification
- ip reputation
- Mobility controller
We have a master-local setup running on 6.4. and another master-local setup running on 6.5. Can we have one of the controller in the 6.5. setup act as a licensing server for both the 6.4. master-local setup and 6.5. master-local setup?
No, this will not work.
In 6.4 Master-Local, Master will become default license server to the locals after enabling the centralized licensing. This can not be changed. Even configuring "license server-ip" will not take effect on Locals. Locals will be pointed to master ip and master will be pointed to configured "license server-ip". This will lead to mis configuration.
- Find more articles tagged with:
- arubaos 6.4
- arubaos 6.5.x
- Centralized licensing
- Mobility controller
Non CPSEC AP reboot behaviour from Aruba OS 6.4
When the non-CPSEC AP looses connection with the current LMS then it tries the next LMS ip address.
After 10 HELLO failures, the AP will reboot. Each HELLO failure is 10 HELLO retries and this takes approximately 30 to 40 minutes for the AP to reboot.
The HELLO messages are part of PAPI and by default, request retries of 10 and retry interval is 10 seconds.
(Aruba) #show ap system-profile default | include Request
Maximum Request Retries 10
Request Retry Interval 10 sec
If the network administrator wants to reduce the reboot time then the above two knobs can be used.
Product and Software: This article applies to all Aruba controllers and ArubaOS 3.x and later.
The following article describes the steps to configure a computer running Mac OS X Leopard (10.5) to receive syslogs from an Aruba controller. The instructions are separated into three parts. Part 1 describes the configuration on the Aruba controller. Part 2 outlines the instructions to enable the built-in syslog server to receive syslog messages from external devices. Part 3 describes how to set up automatic process to rotate saved log messages.
1. Configuring Aruba controllers to send syslogs to an external server.
The internal storage capacity on an Aruba controller is limited. Therefore, it is recommended to forward important system messages to an external server for central processing and storage. Aruba controllers use the standard BSD syslog protocol (RFC3164) to forward system messages to an external server.
1a. Set up the syslog destination.
To send syslogs to an external server, issue the following command in 'config' mode:
where a.b.c.d is the IP address of the syslog server. The syslog protocol uses udp port 514, therefore, ensure that udp/514 is allowed between the controller and the syslog server. Note that the source IP address of syslog messages is the IP address of the interface where the packet exits the controller.
Multiple syslog servers can be defined. In this case, multiple copies of syslog messages will be sent.
1b. Set up the syslog facility.
Each syslog message is tagged with a “facility” field. This field allows a syslog server receiving syslogs from multiple sources to process syslogs and save them in different files. Aruba controllers can be configured to use syslog facilities from local0 to local7.
The default facility sent by an Aruba controller is “local1”. To change the facility, enter the following configurations in config mode:
logging facility localX
where X = 0-7
logging facility local2
will tag all syslogs originating from Aruba controllers with facility = local2
1c. Syslog Severity / Logging Level
The Aruba controller also tags each syslog message with a severity. The severities are listed here in descending order of criticality.
0 Emergency system is unusable
1 Alert action must be taken immediately
2 Critical critical conditions
3 Error error conditions
4 Warning warning conditions
5 Notice normal but significant condition
6 Informational informational messages
7 Debug debug-level messages
By default, the logging level of Aruba controllers is set at “warning”. That is, all messages with severity from emergency to warning are logged and sent to the syslog server. Furthermore, Aruba controllers group syslog messages into five categories:
The logging level of each category can be set individually.
For example (from config mode):
logging level information user
logging level information security
For details, refer to the ArubaOS User Guide.
2. Configuring Mac OS X to receive syslogs from an external device.
Mac OS X is based on FreeBSD. There the server to receive syslog message is built-in to the operating system and no additional software is required. However, by default, the syslog daemon running in Mac OS X is configured to receive syslog messages only from itself.
2a. Enable syslog daemon to receive syslog messages from external sources.
To enable your Leopard system to receive network syslog submissions from other devices (such as an Aruba controller), edit the file:
and uncomment the lines specified in the comments so that the end of the file looks something like this:
Un-comment the following lines to enable the network syslog protocol listener.
2b. Configure where Aruba syslogs are stored.
By default, syslogs messages are stored in this file:
However, it is advisable to direct Aruba-specific logs to a different file. This can be done by configuration in the /etc/syslog.conf file.
In section 1b above, if the “facility” for Aruba controller is changed to “local2”, we can then redirect all syslog messages from Aruba controllers (tagged with facility = local2) to a file.
To achieve that, add the following line in the /etc/syslog.conf file as the first line:
2c. Restart the syslog daemon.
Before this new configuration take effect, the syslog daemon need to be restarted.
Issue the following commands:
sudo launchctl unload /System/Library/LaunchDaemons/com.apple.syslogd.plist
sudo launchctl load /System/Library/LaunchDaemons/com.apple.syslogd.plist
For more information, refer to the man pages of syslog(8), syslog.conf(5), launchctl(8).
3. Configuring Mac OS X to rotate logs periodically.
To prevent the log files from growing indefinitely, logs should be rotated periodically.
In Mac OS X 10.5 (Leopard), log files are rotated by the newsyslog command.
It is run every hour (at 0:00, 1:00, ..., 23:00) by launchd, as can be seen in:
The configuration file for newsyslog is /etc/newsyslog.conf, which contains something like:
# logfilename [owner:group] mode count size when flags
/var/log/system.log 640 7 * @T00 J
when=@T00 means “every night at midnight 0:00”, count=7 means keep seven recent logs, and flags=J indicates to compress old logs by bzip2.
Therefore, to rotate the log files containing syslogs from the Aruba controller (as configured in Step 2 above), the following line can be added to the newsyslog config file:
/var/log/aruba.log 640 14 * @T03 J
This means that the log file will be rotated once a day at 0300h. Old logs will be kept for 14 days. The rotated logs will be compressed with bzip2. Note that the command will run only if the computer is actually on. For example, if this is set up on a laptop, the newsyslog command will be skipped if the computer is in sleep mode at 0300h.
To get around this, a manual rotation of logs can be done with the following command:
sudo newsyslog -F /var/log/aruba.log
For additional information, refer to the newsyslog(8) and newsyslog.conf(5) man pages. The "when" field in newsyslog.conf can also specify an "interval" between rotations.