Past Posts

Aruba Wireless LAN Training

I recently completed the Aruba Networks Partner technology training, and thought I’d post some of my notes here, which may be useful for others who also completed the course to refer back to, and for those who want to get a quick overview of the areas covered by the Aruba Mobility solutions.  This isn’t meant to be a comprehensive technology brief, more of a brain-dump :-)

The Partner Technology Training course is a four day instructor led course, which is heavily lab-based.  At the end of the course we sat the ACMA (Aruba Certified Mobility Associate) exam. This course is similar to Implementing Aruba WLANs.  I highly recommend attending either of these courses, as they do provide a great (hands-on) introduction to Aruba technologies.

Mobility controllers and Access Points

Mobility controllers have one of three roles:
1. Master Controllers
  • Manage Profiles
  • Adaptive radio management
  • IDS
2. Local Controllers
AP termination (GRE tunnel from AP)
User traffic
Firewall rules
VLAN tagging
3. Standalone Controllers
Combined master & local
Popular Access Point Models
AP105 2×2 internal antenna (built-in)
AP125 3×3
AP124 3×3 external antenna
Default Controller DHCP IP address is 172.16.0.254
Eval license = 30 days, can be entered 3 times = 90 days
Permanent license = never expires
Controller Access Point Configuration:

  • AP Groups (contain:)
    • VAP (Virtual Access points, contain:)
      • SSID
      • AAA Profiles
Access points maintain two connections to controllers:
1. PAPI
  • PAPI protocol (AP control plane) = UDP/8211 (Provisioning API)
2. GRE Tunnel for user data
Control plane security is PAPI inside IPsec tunnel
AP Boot troubleshooting commands:
  • print    (show the AP config)
  • purge    (erase all the AP config)
  • save      (save configuration and boot)
  • reset     (reboot)
AP Boot Controller Discovery Process:
0. Static (set master-controller (ip address) = x.x.x.x
(set ip-address x.x.x.x)
1. AP Discover controller = DHCP Option #43 Master IP
2. ADP Multicast (UDP8200)
3. ADP Broadcast
4. DNS = aruba-master.domain.com     (domain.com is whatever DNS domain is set to)
Useful troubleshooting commands on controller:
  • show ap active
  • show ap data base
  • show ap essid (shows only VAPs that are currently broadcasting)
  • show datapath tunnel
  • show log network 100 (# of lines)
  • show log errorlog 100
AAA
Authentication/authorisation using Internal database (controller) or external RADIUS, enabling 802.1x, server-derived user roles (based on attributes passed to controller)
  • show aaa authentication-server all
  • show user
  • show aaa state user <ip>
PEF = Policy Enforcement Firewall
Stateful Firewall security policies implemented within the AP/Controller according to a Wireless user’s role
Licensed on the controller, per AP
Troubleshooting Firewall:
  • show datapath session
Roles
  • show user-table
  • show rights
  • show rights <rolename>
  • show datapath session table <ip address>
Adaptive Radio Management is Aruba’s RF Spectrum Management technology
Band steering encourages 5Ghz clients to connect using 5Ghz only by not replying to 2.4Ghz probes, and only replying to the 5GHz probes
Band steering in 6.0 has more features and is more effective
Spectrum load balancing manages client-to-AP loading by sending clients error codes blocking association with AP#1 so the client associates with AP#2 instead
Number of spatial streams affects bandwidth capacity
• 1 spatial stream = 150mb/s
• 2 spatial stream = 300mb/s
• 3 spatial stream = 450mb/s
• 4 spatial stream = 600mb/s
Interference index => changes channels
Coverage index => changes power levels
Useful ARM commands:
  • Show rf arm-profile default
  • Show ap arm scan-times ap-name <NAME>
  • Show ap arm rf-summary ap-name <NAME>
  • Show rf arm-profile default
  • Show ap arm history ap-name <NAME>
  • Show ap bss-table
Guest Access
Guest access is implemented through ‘Captive Portal’. User redirected to web page to login (either with guest username/password or email address – configurable)
Role based, credentials authenticated and user’s role determines access, firewall rules etc
Guest provisioning allows internal staff to have dedicated access to provision new guest accounts, without requiring administrative access to controller.
Captive Portal can be provided by an external web server, which passes attributes through to controller (e.g. API)
Useful guest access commands:
  • show local-userdb-guest
  • show local-userdb-guest verbose
Remote AP (RAP)
Access points connect to controller over Internet, via VPN, providing corporate and split-tunnel access including firewall policies
All traffic is NAT-T UDP/4500 (inside IPSec tunnel = authenticated L2TP, GRE (User Data) or PAPI)
Modes of operation:
  1. Standard – must have connection to controller
  2. Always – always up regardless of controller connection, config in flash (bridge mode only)
  3. Backup – SSID is on only when controller is down (used as a secondary SSID which provides local Wifi when connection to HO is down, switch back to other SSID when controller connection comes back up)
  4. Persistent – SSID up when controller up, stays up if controller connection goes down (bridge mode only), config from controller
Troubleshooting Remote AP
  • show datapath session table | include 4500
  • show crypto isakmp sa peer <ip>
  • show crypto ipsec sa peer <ip>
  • logging level security process localdb
  • logging level security process l2tp
  • logging level security process authmgr
  • logging level security process crypto
Demo Kit
Available to borrow from Distributors & Aruba SEs (maybe)
Partners can buy kit at heavily discounted rates, includes full solution (Controllers, APs, WiFi Cameras & Phones)
Airwave
Very powerful Wireless management solution with historical data and reporting down to user device level
Resource intensive – requires lots of RAM
Installed with Linux OS, run on dedicated server hardware or VM
For Airwave assistance contact Patrick Smith – Aruba APAC SE for Airwave
AWMS license includes Visual RF & RAPIDS
License count includes Wired Switches that are managed/monitored
That’s it! I hope my notes are useful to someone else.  I’ve also added the command-line tips to our Quick Reference section for Aruba.  Feel free to contact me if you think I should change or add something I’ve missed.

Expanding the Community

Yep, we’ve started off slowly, with only a few posts here and there, but we’re still here.  And we’ve got more to share.

And even better we’re expanding the IT Experience community, with consultants from Datacentric joining us to share their experience, knowledge and insights.  So stay tuned, there’s some great stuff on the way.

A very warm welcome to:

Evan Lewis, James Dalziel, Tracey Davis and Ron van Moorsel

from datacentric.co.nz

Recovering from SecurePlatform Boot Failure

We recently assisted a client that had a failure with one of two Check Point SecurePlatform Security Gateway cluster nodes where after applying a license the machine failed to boot. The issue was that the machine sat at a “Loading” prompt after attempting to boot from CDROM (unsuccessfully), and then booted from C:.  It would appear the boot loader ‘grub’ was not starting correctly, and likely the MBR was corrupted.  The machine never got past the “Loading” message.

As we have seen this once before recently we thought it would be worthwhile posting a quick ‘how to’ to recover from this.  Note: This issue was encountered on an HP ProLiant DL380G6 platform.

To fix you need to boot into a rescue mode of sorts and re-install the boot loader/MBR:

  • Boot from the SPLAT R70 ISO and allow the install to continue to the first installer “welcome” screen [at the ‘press any key after 90 seconds’ – press a key].
  • Press Alt+F2 to change to the “install shell” – basically a bash shell that runs with the installer.
  • At the command prompt, make a temporary directory to mount the real disk partitions:
    • mkdir /splat
    • mkdir /splat/boot
    • mkdir /splat/tmp
  • Mount the real disks:
    • mount /dev/cciss/c0d0p7 /splat
    • mount /dev/cciss/c0d0p1 /splat/boot
    • mount /dev/cciss/c0d0p5 /splat/tmp
  • Copy the ‘dev’ entries into the /splat/dev directory [needed to reinstall the MBR]
    • cp -r /dev/cciss /splat/dev/
  • Run up a chroot
    • chroot /splat /bin/bash
  • Run the ‘grub’ utililty
    • grub
  • This will run up a management interface for use in editing the boot loader config – grub is the bootloader.
  • Configure grub to use the correct root disk, enter:
    • root (hd0,0)
    • setup (hd0)
  • Reboot and that should do it.

Note: For reference, “hd0” maps to a physical disk in the /boot/grub/device.map file, e.g. below, so should be possible to transpose over to another box, such as Dell or IBM [which don’t use the cciss disk driver]

[Expert@FIREWALL01]# cat /boot/grub/device.map

# this device map was generated by anaconda
(fd0)     /dev/fd0
(hd0)     /dev/cciss/c0d0


Vendor Support – a critical ingredient

Recently we had the misfortune of being involved in a system issue that required vendor support for a local integrator.

The integrator’s system, which provides security services to multiple customers of the integrator, became unstable during a routine change. While the system remained in operation with no immediate impact to customers utilising it, the issue meant that no further changes could be made to the system, impacting the integrator’s ability to deliver contracted services to its own customers.

The issue was investigated by the integrator’s resources and a decision was made to escalate the issue to the vendor utilising the integrator’s vendor support contract.

And this is where the real problem started…

Over the next two weeks the case was passed amongst various vendor engineers (overseas) each asking the same questions – when did the issue start, what have you done so far etc etc all of which was described in painful detail in the case notes (over 65 entries and 37 A4 pages in the end). The case was escalated within the vendor by the integrator several times expressing their frustration at the lack of progress, but to no avail. The issue was identified and resolved with the help of the vendor’s local sales engineer assisting in his spare time. The assistance received from the vendor TAC was extremely poor and very disjointed.

Vendor support is a critical factor to consider when choosing products that form key elements within your environment. All too often products are chosen without much regard to the vendor’s ability to support the product locally or via a technical assistance centre. The product may be the best for your situation however if the vendor support is lacking or poor when something does go pear shaped, the cost and impact of a sustained outage or impaired service will not be a pleasant one.

We recently received the standard “Your case is now closed. Please tell us how we performed” survey email from the vendor – it may to take a while to fill this one out…