Onboarding HPE Aruba CX Switches as Virtual Edge Nodes

This article summarizes how to onboard your HPE Aruba CX switches as Virtual Edge Nodes for endpoint discovery, traffic visibility, and policy enforcement. Aruba CX enforcement uses Access Policy, which is configured on the source Policy Group rather than between a source and destination pair. Applies to Elisity 26.7.0 and later.

Overview

Elisity supports HPE Aruba CX switches as Virtual Edge Nodes for endpoint discovery, traffic visibility, and policy enforcement. Endpoint identity and Policy Group classification continue to use the standard Elisity model. Aruba CX uses a platform-specific policy configuration that Elisity translates into Aruba user roles and port-access policies. In Cloud Control Center, we use Access Policy to configure these platform-specific policies. Access policy is configured separately but alongside microsegmentation policies in the Policy Matrix - see Enable Access Policy Support for steps to enable and configure. 

Aruba Central is not supported for this integration. A Virtual Edge VM connects directly to the Aruba CX switch to configure the switch, receive endpoint authentication and accounting messages, and collect IPFIX telemetry.

Prerequisites

Review the Hardware Compatibility Matrix before beginning deployment. The Hardware Compatibility Matrix is the source of truth for supported Aruba CX switch models and required AOS-CX software versions. Complete the following before onboarding a switch:

• Deploy a Virtual Edge VM running Elisity 26.7.0 or later. Aruba CX Virtual Edge Nodes cannot be managed by a switch-hosted Virtual Edge. See the Virtual Edge Hypervisor Deployment Guide for VM requirements and deployment instructions.
• Configure a reachable NTP source for the Virtual Edge VM and the Aruba CX switches. Accurate time is required for RADIUS accounting and endpoint session correlation. See Switch Preparation Commands.
• Enable IPv4 SSH access to the Aruba CX management address, using credentials with sufficient privileges to read and modify the switch configuration.
• Confirm that applicable access ports can use MAC Authentication Bypass (MAB), and that external configuration-management systems will not remove or overwrite Elisity-managed configuration. See Aruba CX Technical Reference for detailed switch configurations managed by Elisity.
• Ensure that every Virtual Edge in the selected VE Group can reach every Aruba CX Virtual Edge Node that may be assigned to the group.
• Enable Access Policy globally in Settings > System > Advanced before onboarding an Aruba CX switch. If the setting is disabled, the Virtual Edge Node onboards in a degraded state. See Enable Access Policy Support.

Connectivity Requirements

Configure routing and firewall policy to permit the following communication. Review the Platform Connectivity Requirements for general Elisity connectivity requirements.

Switch Preparation Commands

Apply the following configuration to each Aruba CX switch before onboarding it. Replace the bracketed values with those for your environment.

Time synchronization

clock timezone <timezone>
ntp server <ntp-server> minpoll 4 maxpoll 4 iburst
ntp enable

SSH management access

Enable the SSH server on the default VRF. The Virtual Edge reaches the switch through the global routing table, so the switch must be reachable on an IP in the default VRF.

ssh server vrf default

Switch credentials for Elisity

Create a dedicated administrator account for the Virtual Edge rather than reusing an operator account. This keeps Elisity-initiated changes attributable in the switch audit log.

user <username> group administrators

Verify Prerequisites

Confirm switch readiness before onboarding:

show ntp status
show ssh server
show ip interface brief
show running-config | incl "ssh"
show running-config | incl "ntp"

From the switch, confirm that it can reach every Virtual Edge in the VE Group that will manage it:

ping <ve-ip>

Migration from the Deprecated Aruba GBP Implementation

Understand Aruba CX Policy Configuration

Standard Elisity policy is configured between a source Policy Group and a destination Policy Group. Aruba CX uses a source-oriented role model. Each source Policy Group receives one Access Policy configuration that defines the destinations, services, and actions available to devices in that group.

Each rule in an Access Policy rule set can define a protocol, source port, destination port, destination Static Policy Group or destination IP address, and an allow or deny action. Rule order is significant. Elisity translates the rule set into an Aruba access list, so the rule set permits the traffic it explicitly allows and drops all other traffic.

Deployment Design Recommendations

Deployments containing both Aruba CX switches leveraging Access Policy and switches which support microsegmentation policies should be onboarded to the same Policy Set in most cases, but several designs are supported for possible permutations of mixed environments.

See Policy Sets and Site Labels to create and assign the Policy Set and Site Label, and Virtual Edge Groups to create the VE Group and assign its Site Label.

Ensure that the Policy Set contains every Policy Group required by devices at the Aruba CX deployment. A device can match a global Policy Group that is not present in the selected Policy Set, which would leave that device without the intended Access Policy assignment.

Deploy the Virtual Edge and Onboard the Switch

Deploy the Virtual Edge VM by following the Virtual Edge Hypervisor Deployment Guide, and assign the Virtual Edge to the dedicated VE Group created for the Aruba CX deployment. Before onboarding a switch, confirm that the production RADIUS shared secret has been configured and that all communication listed in the connectivity requirements table succeeds in both directions.

Navigate to Edge Management > Virtual Edge Nodes, select the Virtual Edge Nodes tab, and click 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.

Selecting Edge Management > Virtual Edges displays the Summary panel, which reports the current Virtual Edge and Virtual Edge Node counts by status.

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 configurations for the switch in this section. 

Less commonly used Advanced Settings are available in the dropdown menu. 

The following chart provides details about each field in this step.

Note: If you would prefer to manually configure port 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 individual 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.

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.

After onboarding, open the Virtual Edge Node details page and review Endpoint Discovery and Flow Telemetry configuration. Confirm that access-facing ports are enabled for Endpoint Discovery and Flow Telemetry and that uplinks or other network-facing interfaces are disabled. 

Port Configurations on Virtual Edge Nodes

Port configurations determine how each switch port on a Virtual Edge Node (VEN) participates in Endpoint Discovery, Flow Telemetry, and Access Policy enforcement. Elisity classifies each port as a User Network Interface (UNI), a Network-to-Network Interface (NNI), or Ignored, then programs configuration only on the ports where it belongs. Interfaces that cannot accept port-access configuration, such as routed and VSF stacking ports, are ignored and never appear in Cloud Control Center.

By default, Elisity applies Automatic configuration to all switch ports. In this mode the Virtual Edge evaluates each port using interface type, interface state, port description, and LLDP or CDP neighbor data to decide whether the port is UNI or NNI. This classification process is described in Criteria for Automatic Port Configuration below.

Automatic configuration keeps Elisity off the wrong interfaces. Enabling client tracking and flow telemetry on an uplink, a distribution link, or a management interface produces discovery of upstream infrastructure and collection of unrelated traffic flows. Automatic classification prevents this by leaving NNI interfaces unconfigured while maintaining visibility on UNI interfaces.

You can change any port from Automatic to Manual configuration at any time to explicitly enable or disable Endpoint Discovery and Flow Telemetry for that port, and you can return a port to Automatic so that Elisity resumes managing it.

During onboarding, the Endpoint Discovery and Flow Telemetry checkboxes enable or disable each feature globally for the VEN. These global toggles control whether Elisity activates the feature at all; they do not change how individual ports are classified. The same controls are available afterward from the Port Configuration view in Cloud Control Center. See Modifying Port Configurations for a VEN below.

Configuration Applied to a UNI Port

When a port is classified as UNI and the corresponding features are enabled, the Virtual Edge programs the following on that interface. Interfaces are configured in batches of ten.

interface 1/1/15
    aaa authentication port-access auth-priority mac-auth dot1x
    aaa authentication port-access client-limit 254
    aaa authentication port-access critical-role elisity_default_role
    aaa authentication port-access preauth-role elisity_default_role
    aaa authentication port-access mac-auth
        enable
    client track ip enable
    ip flow monitor ElisityFlowMonitor in

An NNI interface receives none of this configuration.

Endpoint Discovery and Flow Telemetry

Endpoint Discovery uses embedded switch functionality to learn and track devices connected to the switch. On Aruba CX, identity is learned primarily from RADIUS accounting during MAC authentication, with client track ip polling as a fallback source of IP-to-MAC bindings.

Flow Telemetry provides insight into traffic patterns between endpoints. On Aruba CX, the Virtual Edge programs a flow record, a flow exporter, and a flow monitor globally, then applies the monitor to each UNI interface. IPFIX is the only supported export protocol, and the monitor is applied in the ingress direction only; egress flow monitoring is not supported on AOS-CX.

Aruba CX cannot pin a source interface for flow export. The Virtual Edge therefore collects every routing-interface IP address on the switch and accepts exported flows from any of them.

Existing Flow Telemetry Configurations

In environments where flow export is already configured, the Virtual Edge does not remove or overwrite the existing configuration. Customer-defined flow records, exporters, and monitors remain in place until they are removed manually or by the configuration-management platform that owns them.

The Elisity global flow configuration coexists with a customer flow configuration in most cases. At the interface level, however, AOS-CX accepts a single ingress flow monitor per interface. Where a customer monitor already occupies the ingress direction, the Virtual Edge cannot apply ip flow monitor ElisityFlowMonitor in. It retries on a regular interval, and the interface begins reporting once the existing monitor is removed.

Criteria for Automatic Port Configuration

The Virtual Edge classifies ports by parsing show interface brief, show interface mgmt, show lacp aggregates, show vrf, and the running configuration, combined with neighbor data from show lldp neighbor-info detail and show cdp neighbor-info.

Classification produces one of three outcomes: UNI, NNI, or Ignored. An Ignored interface is dropped before or at classification and is never reported to Cloud Control Center. It appears in neither the Endpoint Discovery nor the Flow Telemetry interface list, and no aaa authentication port-access, client track ip enable, or ip flow monitor configuration is ever pushed to it.

Only physical ports named x/y/z are parsed. Interface names containing vlan, mgmt, or vxlan are filtered out before classification. For every remaining interface, the rules below are evaluated in order and the first matching rule wins. An interface that matches no rule is classified as UNI.

1. Ignored — VSF stacking links, where Mode is VSF in show interface brief. VSF ports reject aaa authentication port-access configuration.
2. NNI — the interface name contains Tunnel, Loopback, or Lag, or the interface is a member of a link aggregation group.
3. Ignored — routed (Layer 3) interfaces, where Mode is routed, that is, a port with no switchport. This rule is evaluated before the description, admin-status, and neighbor rules, so a UNI keyword in a routed port's description cannot short-circuit it to UNI. Routed ports reject port-access configuration the same way VSF ports do.
4. UNI — the interface description matches a UNI keyword configured in Cloud Control Center, or the port has been classified explicitly in Cloud Control Center.
5. NNI — the interface description matches an NNI keyword. The default keywords are Router, Firewall, and NNI, matched without regard to case.
6. NNI — the interface is administratively disabled.
7. UNI or NNI — based on LLDP or CDP neighbor capability. A host or server neighbor is UNI, an IP phone is UNI, and a neighbor advertising only wireless access point capability is UNI. A neighbor advertising router or switch capability is NNI.
8. NNI — the interface is in trunk mode.
9. UNI — all remaining interfaces.

Classification is re-evaluated approximately every five minutes. The underlying LLDP and CDP neighbor tables are polled on a longer interval of approximately thirty minutes, so a newly connected uplink or phone can take up to that long to be reflected in port classification.

Configuring Interface Auto-Detection Using Description Keywords

You can configure UNI and NNI port rules directly for Virtual Edges in the Cloud Control Center by entering keywords that describe each port type.

1.  Select Virtual Edges>Settings>Advanced Settings.

   

2. Toggle Enable Discovery and Telemetry and enter keywords to designate the port as UNI.

3. Toggle Disable Discovery and Telemetry and enter keywords to designate the port as NNI.
4. Click Save Changes.

Modifying Port Configurations for a VEN

After onboarding, you can review the port configurations in Cloud Control Center for each port and modify them according to your network design and the scope of your microsegmentation efforts. If you chose to leave these options disabled during onboarding, now is the time to either enable autoconfiguration or manually configure each port for each setting. After onboarding, port configurations can be viewed and modified for each Virtual Edge Node directly in Cloud Control Center.
 

To modify port configurations, select your VEN and navigate to Port Configurations by clicking the more options button on the right.

Click Edit Configuration. This will take you to the port configuration editor.

If you have not yet configured any port configurations, you must first enable Endpoint Discovery or Flow Telemetry before configuring auto or manual configurations per port. 

The configurations will not be pushed to infrastructure until you select Save Changes, so there is no risk in pushing configurations to undesired ports.

The port configuration editor is very straightforward. Simply select the configuration type per interface: Automatic or Manual. If you choose Manual, select Enabled or Disabled. If you choose Automatic (default) the port configuration will be displayed in this place and cannot be changed unless configuration type is changed.

After reviewing these port configs and making any adjustments, click Save Changes and your configurations will be immediately pushed to the VEN. 

Enable Access Policy Support

Access Policy is enabled on the Policy Set assigned to the Aruba CX deployment. Enabling it adds an Access Policy column to the Policy Matrix for that Policy Set. Because the setting is scoped to the Policy Set, Access Policy Virtual Edge Nodes and standard-policy Virtual Edge Nodes can coexist in the same tenant.

Step 1. Enable Access Policy Globally

Navigate to Settings > System > Advanced and enable Enable Access Policy in the Access Policy Support card. This setting is tenant-wide and must be enabled before Access Policy can be used on any Policy Set.

The global setting cannot be disabled while any Access Policy is configured or any Access Policy Virtual Edge Node is connected. Remove all Access Policies and disconnect the Access Policy Virtual Edge Nodes before disabling the feature.

Step 2. Enable Access Policy for the Policy Set

Navigate to Policy > Policy Sets, edit the Policy Set assigned to the Aruba CX deployment, enable Access Policy Security Controls, and save the Policy Set. The same control is available when you create a new Policy Set, so Access Policy can be enabled at creation time instead of in a later edit.

Step 3. Display the Access Policy Column

Open the Policy Matrix, select the Policy Set assigned to the Aruba CX deployment, and confirm that the Access Policy Group control is enabled. It is enabled by default and can be disabled at any time. The matrix displays an Access Policy column next to the source Policy Groups. This column is used to assign the Access Policy configuration for each source group.

Create an Access Policy Rule Set

Create the ordered rules that will be assigned to a source Policy Group.

Step 1. Open the Access Policy Security Profiles Tab

Navigate to Policy > Security Profiles, select the Access Policy Security Profiles tab, and select Create Security Profile.

Step 2. Define the Security Rules

Enter a profile name and description, then add the required security rules. Each rule uses the following values:

Arrange the rules in the required evaluation order, review the configuration, and select Create.

The completed rule set appears in the Access Policy Security Profiles list.

Assign Access Policy to a Policy Group

Step 1. Select the Access Policy Cell

Open the Policy Matrix, select the Policy Set assigned to the Aruba CX deployment, and enable the Access Policy Group control. Locate the source Policy Group on Side A and select its Access Policy cell.

Step 2. Select Custom Policy

Select Custom Policy from the Access Policy menu.

Step 3. Attach the Access Policy Rule Set

Enter a policy name and description. Select Existing Security Profile and choose the Access Policy rule set created previously. You can also select Create New Security Profile to define the rules during this workflow. 

Step 4. Select the Enforcement Mode

Select Create As, then choose the enforcement mode. Simulated Policy evaluates the assignment without programming the active Aruba role, and matching devices continue to use the default allow role. Active Policy programs and enforces the assigned Aruba role and policy.

After creation, select or hover over the Access Policy cell to review the assigned rule set. 

Validate the Deployment

Cloud Control Center Validation

Confirm that the Aruba CX Virtual Edge Node status is Online, that applicable access ports are classified as UNI, and that Endpoint Discovery and Flow Telemetry are enabled where required. Connected devices should appear in IdentityGraph and match the expected Policy Groups, the source Policy Group should show the intended Active Access Policy, and Traffic Analytics should receive flow records from the Virtual Edge Node.

Review the Assets tab of the source Policy Group to confirm that the expected devices have been classified into the group.

Aruba CX Validation

Use the following commands to review the switch state:

show port-access clients
show client ip
show running-config
show ip interface brief
show interface brief

Confirm that the Elisity RADIUS server and server group are present, that RADIUS accounting and dynamic authorization are enabled, and that the Elisity default role and allow policy are present. The expected elisity_ classes and port-access policies should exist, the source Policy Group should have a corresponding Aruba port-access role associated with the expected port-access policy, and the endpoint session should carry the role associated with its Policy Group. Applicable UNI interfaces should have MAC authentication, client tracking, and the IPFIX flow monitor enabled.

Elisity-generated policy configuration follows this general relationship:

class ip elisity_<profile>_rule_<number>
port-access policy elisity_<profile>
port-access role <policy-group-role>
    associate policy elisity_<profile>

Operational Behavior and Limitations

Initial Default Role

MAC authentication normally occurs before a newly connected endpoint receives an IP address and is classified by Cloud Control Center. The switch initially assigns the Elisity default allow role. After the endpoint is identified and assigned to a Policy Group, the Virtual Edge sends a Change of Authorization to apply the correct Aruba role.

Policy Configuration Is Programmed When Required

The default allow role is programmed during Virtual Edge Node onboarding. Other Access Policy roles and rule sets are programmed only when at least one device on that Virtual Edge Node matches the associated source Policy Group. When the last device leaves the role, Elisity can remove the unused role and policy configuration if it is no longer referenced.

Policy Rule Updates

Aruba CX can briefly interrupt traffic when an active port-access policy is modified in place. To avoid this behavior, Elisity builds a temporary policy, changes the role association, rebuilds the canonical policy, and then restores the canonical role association. This updates the rule set without requiring endpoint reauthentication.

Change of Authorization is used when an endpoint changes Policy Groups or when the endpoint role must be corrected. It is not required for a rule-only update to the policy already associated with the role.

Port Classification Changes

Changing the classification of a port between UNI and NNI interrupts traffic on that port while the change is applied. A port that repeatedly changes classification drops traffic each time. Automatic classification derives its result from interface state, interface mode, LAG membership, CDP and LLDP neighbor information, and interface descriptions, so an unstable input can produce repeated reclassification. Where automatic classification does not produce a stable result, configure the port manually so that its classification remains fixed.

Virtual Edge Failover

A VE Group provides management redundancy for the Aruba CX Virtual Edge Nodes. When the active configuration leader becomes unavailable, another Virtual Edge in the group assumes management of the Aruba CX Virtual Edge Nodes. Allow time for the replacement leader to update the switch RADIUS configuration and reconstruct endpoint sessions before evaluating endpoint role assignments.

Existing Aruba Roles

Elisity identifies its managed policies by the elisity_ naming prefix. Roles and policies not owned by Elisity, including customer-managed 802.1X, voice, or ClearPass roles, are not removed solely because they are not present in Cloud Control Center. Review overlapping authentication and role configuration before deployment to prevent policy conflicts.

VXLAN

VXLAN is not required for Aruba CX Access Policy enforcement. Access Policy can coexist with an existing VXLAN deployment, but the customer network design and any existing role or policy automation must be reviewed before onboarding.

Staging Access Policy Before Enforcement

Clear Enable Policy Enforcement during onboarding to bring the switch into service for endpoint discovery and flow telemetry without configuring enforcement. Enable the setting when you are ready to enforce policy on the switch.

To stage an individual Access Policy on a Virtual Edge Node that already has enforcement enabled, create the Access Policy as Simulated Policy. Devices that match a Simulated Policy keep the Elisity default allow role while the assignment is evaluated.

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 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.

The Activity Panel is where Virtual Edge Node lifecycle operations, including decommissioning, report their progress. You can open it 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. The Actions menu also offers Force Delete for a Virtual Edge Node that is in the Decommission Started or Decommission In Progress state, which gives you a way to clear a decommission that has stalled. Force Delete opens a confirmation dialog and permanently removes the Virtual Edge Node from Cloud Control Center. Because it halts an in-progress decommission, configuration may remain on the switch. Force Delete is offered whether the managing Virtual Edge is online or offline. Deleting a VEN requires no further action.

The Bulk Actions menu described earlier in this section offers Force Delete as well, enabled when at least one selected Virtual Edge Node is in the Decommission Started or Decommission In Progress state. A confirmation lists the Virtual Edge Nodes that will be permanently removed; any selected Virtual Edge Nodes that are not eligible are skipped.

A Virtual Edge Node can be recommissioned from the Decommissioned state in the same way that it is decommissioned. Recommission is also available to retry from the Recommission Failed and Decommission Failed states. Recommissioning a VEN provides status feedback in the Activity Panel for tracking the step-by-step recommissioning process. 

Related Articles

• Aruba CX Technical Reference
• Hardware Compatibility Matrix
• Virtual Edge Hypervisor Deployment Guide
• Virtual Edge Groups
• Policy Sets and Site Labels
• Policy Groups
• Policy Matrix
• Platform Connectivity Requirements