What Aruba Excursions Actually Is
Aruba Excursions is an integration framework built into Aruba OS 8.x and 9.x that lets you push custom logic directly onto the device. Instead of running external scripts from a server, the controller itself executes short programs written in Lua. These programs respond to events like a client associating, a port changing state, or a timer firing. The result is real-time automation that doesn't depend on outside polling. People tend to discover this after they've already set up SNMP traps and syslog forwarding to some central system, only to find that 30-second delays make automated responses feel sluggish. With Excursions, the logic lives on the device where the event happens. That cuts response time from whatever your external collector can manage down to sub-second execution. I spent about three years working with these controllers before I really understood the deployment model. Here's how the pieces fit together in practice.
Core Components
Every Excursion setup involves three things: the Lua script itself, an excursions configuration block that registers the script and defines triggers, and an event dispatcher on the controller that handles the runtime environment. The controller ships with a default script library, but most useful integrations require custom code you write yourself. The scripts are stored in the controller's flash file system. You can upload them through the web UI, SCP, or TFTP. Once uploaded, you reference them from the excursions config. The controller then compiles them into its virtual machine on the next reload or when you issue the appropriate commit command. Here's a basic structure that most people start with:
event script — the Lua file containing your logic. This is where API calls like cli.execute(), snmp.send(), and json.encode() live. You can send HTTP requests to external APIs, query the controller CLI, manipulate local variables, and read event data. excursions registration — the configuration block that tells the controller which script to load, what events to listen for, and how to map incoming event data to script variables. You declare this under excursions > registered-script or similar, depending on your OS version. timer and trigger definitions — not every Excursion is event-driven. Some are purely time-based. You can schedule scripts to run at intervals, which is useful for periodic cleanup jobs or status polling that doesn't need real-time responsiveness.
Get the Full Details
Common Use Cases
Automated rogue AP detection escalation is one of the more common deployments. Instead of relying on the controller's built-in rogue AP alerts alone, you can write a script that enriches the event with additional context and pushes it to an external ticketing system or SIEM. The built-in alerting is adequate for basic notifications, but when you need structured data sent to a specific API endpoint with authentication, custom logic becomes necessary. Custom AAA integration is another frequent use case. Organizations running non-standard authentication backends sometimes find the native RADIUS and LDAP support insufficient for their specific workflow. Excursions lets you intercept authentication events and call custom endpoints or query internal databases before allowing or denying access. This is particularly common in environments where user attributes live in a legacy system without standard protocol support. Health check automation rounds out the typical applications. Rather than waiting for an operator to notice a degraded AP or switch port, you can configure periodic scripts that probe device health and generate alerts when thresholds are crossed. The difference between this and SNMP polling is that Excursions has direct access to the controller's internal state, so you're reading authoritative data instead of inferred metrics.
How to Deploy One
Start by enabling the excursions feature on your controller. In ArubaOS 8.10 and later, this is generally available without special licensing, but earlier versions may require a feature key. Check your current release with the show version command before investing time in a deployment that won't function on your hardware. Next, write your first script. I recommend starting with something trivial that just logs a message. This confirms your upload path works and your configuration syntax is correct before you add real logic. A blank script that only outputs a timestamp when triggered is worth more than a broken script that does something complex. Upload the script to flash using scp root@[controller-ip] /mnt/flash/ or through the web interface under Management > Scripts. The file needs to be in UTF-8 encoding with a .lua extension. Binary or improperly encoded files will fail silently during compilation, and debugging that can cost you several hours.
Configure the excursions block. Here's a minimal example for a login event trigger: excursions registered-script my-first-script.lua
event-trigger login script-arguments username $username end
Commit the configuration and verify with show excursions status. This command displays whether your script compiled successfully, which events are registered, and the last execution timestamp. If the status shows an error, check the controller log with show logging for the actual compilation failure reason. Test with a controlled event. Trigger the event manually if possible, or wait for a natural occurrence. Monitor the execution in real-time using show excursions statistics to see whether the script ran, how long it took, and whether it returned any errors.
Pitfalls and Limitations
The biggest limitation most people hit is the script execution timeout. Each Excursion script has a hard timeout, typically around 10 seconds depending on your controller model and OS version. If your script makes external API calls or CLI queries that hang, the controller kills it and logs a timeout error. This is intentional — a stuck script blocks the event dispatcher and can cause cascading delays across other Excursions. I learned this the hard way during a deployment where I wrote a script that queried an external REST API for user information. The API endpoint had intermittent latency spikes, and during one incident a request hung for 45 seconds. The Excursions timeout fired, but the controller also flagged the event handler as stalled. Other legitimate events queued behind it started experiencing delays. The workaround was straightforward but easy to miss: always wrap external calls in a timeout check and implement a fallback path. I ended up adding a 3-second timeout wrapper around every external call and configured the script to proceed with cached or default data when the call failed. This kept the event dispatcher from choking. Another issue is the lack of persistent memory between script invocations. Each script execution starts with a clean variable space unless you explicitly store data in flash or use the controller's global variable store. This means you can't maintain state across events without saving and loading from external storage. For simple tasks this is fine. For anything that requires cross-event context, you need to design around it from the start.
Lua version compatibility is also a concern. Different ArubaOS releases ship with different Lua versions, and the available standard library modules vary between them. A script that works on OS 8.10 may fail on OS 8.8 because certain string or table functions don't exist yet. Always test your scripts on the exact OS version your production controllers are running, not just the latest lab build. Debugging is genuinely difficult. The error messages from the Excursions compiler are often terse, and there's no interactive debugger. Your primary tools are print statements that write to the controller log and the show excursions output. I found that adding detailed logging at each logical step in my scripts reduced debugging time significantly, but it also increases log volume. Balance verbosity against operational noise.
When Excursions Isn't the Right Tool
For large-scale automation across many controllers, Aruba Central's integrated automation features or a dedicated orchestration platform like Python with Netmiko may be more appropriate. Excursions shines when you need device-local, real-time responses that can't tolerate network latency or external system dependencies. If your automation requirements involve multi-device coordination, complex data transformation, or integration with external workflows, the overhead of maintaining Lua scripts on each controller probably isn't worth it. Similarly, if your organization already has an SIEM or orchestration platform that can collect syslog and respond to events, adding Excursions creates a parallel automation layer that duplicates effort and complicates troubleshooting. Use it where it adds value, not as a general-purpose automation solution.
Final Notes
Aruba Excursions is a practical tool when you understand its constraints. The real-time execution model is genuinely useful for time-sensitive local automation. The trade-off is that you're embedding code on network infrastructure, which means your change management process needs to cover script updates the same way it covers configuration changes. Version control for your Lua scripts isn't optional — keep them in a repository with change history. The community documentation is sparse compared to other networking automation frameworks. Most of what you'll find is scattered across Aruba's official forums, community posts, and vendor documentation that assumes familiarity with both Lua and Aruba CLI concepts. Don't expect a comprehensive tutorial to exist. Build your knowledge incrementally through small, tested deployments. If you're evaluating whether to adopt this, start with a single non-critical controller in a test environment. Deploy a simple health-check script, observe how the controller handles it under load, and assess whether the operational overhead matches your expected benefit. The technology works. It just requires careful scoping to avoid becoming a maintenance burden.
