Elisity supports onboarding Aruba CX switches as Virtual Edge nodes for policy enforcement and identity-based segmentation. This integration allows Aruba switches to be directly managed by the Elisity Cloud Control Center (CCC) without requiring Aruba Central or external network controllers.
Before onboarding Aruba switches as Virtual Edge Nodes with Elisity, the following requirements must be met:
Supported Switch Platforms
- Supported Aruba switch platforms: Aruba 6200, 6300 and 6400 CX series.
- Aruba switch must be running ArubaOS-CX version 10.11 or later.
Please refer to the Hardware Compatibility Matrix for the complete list of validated switch models and minimum recommended code versions.
Design Specific Notes/Limitations
- In some network designs, VxLAN must be configured and routable between the switch and VE.
Notes for All Switches
- Switch must be reachable from the Elisity Virtual Edge using SSH (IPv4 only).
- SSH must be enabled on the Aruba switch and configured with valid credentials.
- Switch must not be managed by an active Aruba Central template that overrides CLI configurations.
- All required ports must be open between the switch and Elisity Cloud Control Center or local controller.
- The current integration supports policy enforcement using layer 3 rules; Layer 4 enforcement is not available for Aruba platforms at this time.
Deployment Considerations
Before onboarding an Aruba CX switch as a Virtual Edge Node, review the following operational and architectural considerations to ensure compatibility and successful enforcement.
Aruba Central can be used with Elisity as long as there are no conflicts between the Aruba Central template and the configuration that Elisity pushes to the switch. Ensure that template-enforced configurations do not override or block required CLI-based enforcement, telemetry, or identity tracking settings applied during onboarding.
Management Mode: The switch must be managed directly via SSH. Aruba Central-managed switches with enforced templates are not supported.
Policy Group Assignment: Policy Groups are assigned dynamically based on MAC address. Static Policy Groups are not supported due to Aruba platform limitations.
Policy Scope: Only Layer 3 (IP-based) policies are supported on Aruba switches. Layer 4 enforcement is currently disabled.
Identity Tracking: Elisity uses Aruba’s client tracking mechanism (client track ip) to discover and monitor connected endpoints. Syslog is not used for identity updates.
UNI/NNI Detection: UNI and NNI port roles are determined automatically based on interface naming, LLDP/CDP data, and interface configuration. Ports in routed mode or with non-default VRFs are treated as NNI.
Telemetry: Flow telemetry is exported via IPFIX using a standard flow monitor and record configuration pushed by the VE. NetFlow and syslog are not supported.
Adding Virtual Edge Nodes in Cloud Control Center
Select the Virtual Edge Node tab in the bottom menu, and select Add Virtual Edge Node then select Add Single Virtual Edge Node. Note that adding a VEN from this screen requires you to select a Virtual Edge or VE Group as a parent.
When deploying new Virtual Edge Nodes, you can select standalone Virtual Edges or VE Groups to manage the Nodes you are onboarding. Click + Add Virtual Edge Node as normal.
Virtual Edge Node Deployment Wizard
After clicking the Add Single Virtual Edge Node option, you will being the Virtual Edge Node Deployment Wizard.
Step 1 - Choose a Virtual Edge
First, a selection pane will appear with options for selecting a VE Group, Standalone VE, Switch-hosted VE, or Cloud-hosted VE (ie. Juniper VE) for managing the VEN or VENs that you are attempting to deploy. Note that Standalone Virtual Edges are not currently supported when onboarding multiple VENs.
Step 2 - Choose the Virtual Edge Node Type
After selecting your VE or VE Group and clicking save, you will be directed to select the Virtual Edge Type. Select Switch as the Virtual Edge Node type. See the following guides for onboarding Palo Alto Firewalls or Panorama, and Onboarding Wireless LAN controllers.
- Palo Alto Networks Firewall Integration - Policy Group Derived Dynamic Address Groups (DAG)
- Palo Alto Networks Panorama Integration - Policy Group Derived Dynamic Address Groups (DAG)
- Onboarding Catalyst 9800 Wireless Controller
Step 3 - Virtual Edge Node Configuration
Provide basic configuations for the switch in this section.
| Field | Description |
|---|---|
| Switch Management IP | This is the management IP of the switch you wish to onboard as a Virtual Edge Node for policy enforcement. This IP must be reachable by the previously deployed Virtual Edge container. Use only the primary IP address of the switch's management interface. Do not use HSRP, VRRP, GLBP, or any secondary/virtual IP address. |
| Description | This allows a user-defined description to be configured for the VEN. This field is optional. |
| Switch Credentials | Administrators can use Global Credentials to securely store and reuse switch credential sets for deployments. Global credentials can be created on the fly during VEN onboarding with the appropriate permissions, or created centrally in Settings > Global Credentials here. If not using global credentials, the admin username of the switch you wish to onboard as a Virtual Edge Node can either be local or TACACS/RADIUS. Privilege 15 is required. This field is mandatory. Username should be alphanumerical and may contain only permitted special characters (_, +, \, /, -). If not using global credentials, the admin password of the switch you wish to onboard as a Virtual Edge Node can either be local or TACACS/RADIUS. Privilege 15 is required. Password cannot contain whitespaces. This field is mandatory. |
Less commonly used Advanced Settings are available in the dropdown menu.
The following chart provides details about each field in this step.
| Field | Description |
|---|---|
| Enable Endpoint Discovery | Selecting this option enables the active collection of identifying data for endpoints discovered behind a VEN, gleaned from access switch telemetry. This feature actively tracks assets for updates in identifying data. (Recommended) This setting is autoconfigured per switchport if enabled during this onboarding. You can choose to enable autoconfiguration or manually configure after onboarding by leaving this box unchecked. The logic for this autoconfiguration is discussed later in this article. |
| Enable Flow Telemetry | Selecting this option enables the collection of flow data and network traffic analytics that are sent to Cloud Control Center. (Recommended) This setting is autoconfigured per switchport if enabled during this onboarding. You can choose to enable autoconfiguration or manually configure after onboarding by leaving this box unchecked. The logic for this autoconfiguration is discussed later in this article. If the switch is already leveraging AVC FNF configuration via DNAC, please contact your Elisity technical contact before enabling this feature. |
| Enable Policy Enforcement | When enabled, the Virtual Edge Node receives configuration to support policy enforcement, including IP and tag mappings, policy ACLs, CTS commands, and SXP peering. This setting is enabled by default during onboarding. Disable this option to remove policy enforcement configuration from the VEN. When disabled, no policy elements are programmed on the switch, allowing the VEN to operate in a discovery-only mode. The Virtual Edge Node must be decommissioned before policy enforcement can be disabled. This setting is mutually exclusive with Enable SXP Peer-Only Mode. Only one of these options can be active at a time. |
| Enable SXP Peer-Only Mode | Configure this Virtual Edge Node to function only as an SXP peer for identity exchange, without CTS enablement or policy enforcement. When enabled, the Virtual Edge only programs the required SXP peer statement on the switch. No other CTS commands are added or removed during normal operation. This setting is disabled by default and is intended for environments where the switch is already peering with ISE through SXP and only requires identity-based IP-to-SGT mappings from Elisity. Disabling SXP Peer-Only Mode does not automatically remove the existing SXP configuration; it must be manually removed from the device. This setting is only applied for Cisco Switch and Cisco WLC Virtual Edge Node types. This setting is mutually exclusive with Enable Policy Enforcement. Only one of these options can be active at a time. |
| Enable Aggregation Role | Enables the Virtual Edge Node to act as an aggregation role for any downstream Cisco IOS switches which will be leveraged as Visibility-Only Virtual Edge Nodes. This includes the automatic discovery of compatible downstream switches for device visibility and enrichment functionality which are presented in Cloud Control Center for adoption. |
| Enable NAT Support | Enables the configuration of an inside and outside management IP for NAT Support. Read the Virtual Edge Node NAT Support article to learn more about this configuration. |
| Select Exporter | Custom flow exporters allow organizations to integrate Elisity's flow telemetry with existing network monitoring solutions. For customers who already rely on third-party tools for network analytics and traffic visibility, this feature provides a way to direct flow data from Virtual Edge Nodes (VENs) to an external monitoring system. Read here for more information on configuring flow exporters for Virtual Edge Nodes. |
**NOTE: If you would prefer to manually configure switchport configurations, or enable autoconfiguration at a later time, leave Endpoint Discovery and Flow Telemetry settings disabled.
Step 4 - Site Label and Distribution Zone
In this step, you can choose to inherit Site Label and Distribution Zones from the parent Virtual Edge, or you can choose to assign a Site Label and Distribution Zone directly to each indivual Virtual Edge Node. Virtual Edge Nodes managed by a single Virtual Edge can belong to various Distribution Zones with varying Site Labels. You can also choose to structure your VE/VEN relationships so that you never have to assign a Site Label or Distribution Zone to a switch. This is primarily decided by how you decide to structure Virtual Edges and which switches they will manage.
| Field | Description |
|---|---|
| Site Label | Site labels can be applied to Virtual Edge Nodes for policy distribution and for analytics purposes. Site labels are used to assign Virtual Edges and Virtual Edge Nodes to Policy Sets. Read more about Site Labels and Policy Sets here. |
| Distribution Zone | Here we can select to inherit the Distribution Zone from the parent Virtual Edge, or we can assign an Access Distribution Zone or create an Isolated Distribution Zone. For more information on creating and assigning Access/Isolated DZs or to learn about DZs as a concept, click on one of the following links. Creating and Assigning Distribution Zones to Virtual Edge Nodes Click here to learn more about Distribution Zones |
Step 5 - Review the Summary
After filling out all the required fields, click Next to go to the summary page. Here you can review and edit all configurations made in the wizard. Clicking Edit on any section will take you back to that section, where you can then modify the configuration. Once you have reviewed the configuration summary, click finish. The Virtual Edge Node onboarding process will begin immediately.
NOTE:
If the switch fails to onboard as a VEN, it will not automatically retry. To resolve this, delete the VEN, make the necessary configuration adjustments, and attempt the onboarding process again.
Checking the Status of a VEN Onboarding
In the top right of your Cloud Control Center dashboard, you will see a notification icon. After beginning the VEN onboarding, a blue dot will indicate that the status of your VEN onboarding has an update.
Clicking on this icon will reveal the status of your VEN onboarding. As each step of the onboarding is completed successfully, that item is marked with a green check mark and a "Success" status.
If any errors are encounter during onboarding, a red error indicator will appear on that item, with a brief description of the issue. In this case, we can surmise that the reason this onboarding has failed is because the switch is unreachable. We need to then check for errors and confirm that our Virtual Edge Node can reach both CCC and our VE.
Once the onboarding is complete, your VEN will show green in Cloud Control Center and information about the switch is now visible such as hostname, switch model, number of discovered devices, and more.
Decommissioning and Deleting a Virtual Edge Node
Decommissioning a VEN takes the enforcement point out of service by removing the configurations from the switch, but retains the configuration in Cloud Control Center so that you can easily put the VEN back in service with a single click.
Open the details view of your Virtual Edge Node and then select Decommission in the top right. The Virtual Edge Node status will say Decommissioned.
You can also decommission from the main VEN dashboard by clicking the three dots to the right and selecting Decommission Virtual Edge Node.
If you want to decommission multiple VENs simultaneously, select the VENs using the check boxes on the left and click Bulk Actions. Here you can perform various bulk actions such as restart Restonf, Decommission, and Delete.
In any case, you will be presented with a confirmation request to finalize the decommission action with warnings or errors where applicable.
After decommissioning, the Activity Panel will show the status of the decommission process. The Activity Panel is accessible through the notification icon in the top right corner of Cloud Control Center.
After completing the decommission process for the VENs, you can then delete them from Cloud Control Center, or leave as decommissioned for easily recommissioning at a later time. Clicking the more options button under the actions panel to the right of the VENs will show the delete or recommission options for each VEN. These options are also available in the bulk actions menu as seen earlier. Deleting a VEN requires no further action.
Virtual Edge Nodes can be recommissioned in th same way that they are decommissioned. Recommissioning a VEN will also provide a status feedback in the activity panel for tracking the step by step recommissioning process.