Onboarding Aruba Switches as Virtual Edge Nodes

This article summarizes how to onboard your HPE Aruba CX and Aruba AOS-S switches as Virtual Edge Nodes for endpoint discovery, traffic visibility, and policy enforcement. Aruba enforcement uses Access Policy, which is configured on the source Policy Group rather than between a source and destination pair. The switch configuration commands are in the companion article Aruba Configuration Commands for Virtual Edge Node (VEN) Onboarding.

Overview

Elisity supports HPE Aruba CX (AOS-CX) and Aruba AOS-S (ArubaOS-Switch) switches as Virtual Edge Nodes for endpoint discovery, traffic visibility, and policy enforcement. The Virtual Edge detects the platform automatically from the switch, so no vendor selection is required during onboarding. Endpoint identity and Policy Group classification continue to use the standard Elisity model. Enforcement uses Access Policy, a platform-specific policy configuration that Elisity translates into Aruba user roles and policies. Access Policy is configured separately from, but alongside, microsegmentation policies in the Policy Matrix. See Configure Access Policy.

Aruba Central is not supported for this integration. A Virtual Edge VM connects directly to each Aruba switch. See How It Works.

How It Works

The Virtual Edge VM manages each Aruba switch directly over SSH. It discovers the switch, programs the Elisity configuration, and polls operational state. The switch sends MAC authentication requests and RADIUS accounting to the Virtual Edge, which terminates RADIUS for the switches it manages. When an endpoint is classified into a Policy Group, the Virtual Edge sends a Change of Authorization to apply the matching Aruba role. The switch exports flow telemetry to the Virtual Edge, which sends it to Cloud Control Center.

Endpoint Discovery and Flow Telemetry

Endpoint Discovery uses embedded switch functionality to learn and track devices connected to the switch. Flow Telemetry provides insight into traffic patterns between endpoints. The two switch families collect this data differently.

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 the Elisity flow monitor. It retries on a regular interval, and the interface begins reporting once the existing monitor is removed.

Customer-managed sFlow receivers are also left untouched.

Configuration Applied by the Virtual Edge

The Virtual Edge programs the Elisity RADIUS server with RADIUS accounting and dynamic authorization, the Elisity default role and allow policy, MAC authentication on UNI ports, and flow telemetry: IPFIX on Aruba CX and sFlow on Aruba AOS-S. Interface configuration is applied only to ports classified as UNI, and an NNI interface receives none of it. On Aruba CX, interfaces are configured in batches of ten.

The initial role, elisity_default_role, keeps unclassified devices online. On Aruba AOS-S, the Virtual Edge creates it before it enables MAC authentication. Do not remove or rename it.

For the exact commands the Virtual Edge sends on each platform, see the Aruba CX or Aruba AOS-S section of Aruba Configuration Commands for Virtual Edge Node (VEN) Onboarding. The full Aruba CX configuration programmed by the Virtual Edge is also described in Aruba CX Switch Onboarding - Technical Reference.

Access Policy Model

Standard Elisity policy is configured between a source Policy Group and a destination Policy Group. Aruba switches use 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.

Elisity translates each Access Policy rule set into the platform objects below.

Editing a rule set does not interrupt traffic on either switch family; see Operational Behavior and Limitations. On Aruba AOS-S, changing a rule set's assignment does not interrupt traffic either, and the roles do not assign a VLAN, so endpoints remain on the untagged VLAN of their port.

Supported Platforms

Elisity supports the following Aruba switch families as Virtual Edge Nodes. The Hardware Compatibility Matrix is the source of truth for supported models and minimum switch software, so check it before deployment.

The 6200 and 6400 Series are supported because the switch vendor provides the functionality Elisity requires on those models; Elisity has not tested or validated them. Both families can be managed only by a Virtual Edge VM.

Prerequisites

Complete the following before onboarding a switch:

• Deploy a Virtual Edge VM. See the Virtual Edge Hypervisor Deployment Guide for VM requirements and deployment instructions.
• Configure a reachable time source, such as NTP, for the Virtual Edge VM and the Aruba switches. Accurate time is required for RADIUS accounting and endpoint session correlation.
• 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.
• Ensure that every Virtual Edge in the selected VE Group can reach every Aruba Virtual Edge Node that may be assigned to the group.
• Confirm that Elisity Support has configured the RADIUS shared secret on the Virtual Edge. The Virtual Edge uses one shared secret for every Aruba switch it manages, so Aruba CX and Aruba AOS-S switches on the same Virtual Edge share it.
• Enable Access Policy globally in Settings > System > Advanced, and on the Policy Set assigned to the deployment, before onboarding an Aruba switch. If the global setting is disabled, the Virtual Edge Node onboards in a degraded state. See Enable Access Policy Support.

SSH, a time source, and the Elisity service account must be configured on each switch before onboarding, along with DHCP snooping on Aruba AOS-S. For the commands, including the command list to allow when the Elisity account is subject to TACACS+ command authorization, see the Aruba CX or Aruba AOS-S section of Aruba Configuration Commands for Virtual Edge Node (VEN) Onboarding.

Platform Requirements

Use a dedicated account rather than a reused operator account, so that changes made by Elisity stay attributable in the switch audit log, and enter the same credentials when you add the switch as a Virtual Edge Node in Cloud Control Center.

Migration from the Deprecated Aruba GBP Implementation (Aruba CX)

Connectivity Requirements

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

The following diagram shows the connections for an Aruba CX switch. Aruba AOS-S switches use the same connections. The table lists the flow telemetry protocol for each platform.

Deploy the Virtual Edge and Onboard the Switch

Policy Set and VE Group Design

Deployments containing both Aruba 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 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 VM by following the Virtual Edge Hypervisor Deployment Guide, and assign the Virtual Edge to the dedicated VE Group created for the Aruba 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. The + Add Virtual Edge Node menu offers Add Single Virtual Edge Node and Add Multiple Virtual Edge Nodes.

Virtual Edge Node Deployment Wizard

Selecting Add Single Virtual Edge Node opens the Virtual Edge Node Deployment Wizard.

Step 1 - Choose a Virtual Edge

Select the VE Group or standalone Virtual Edge that will manage the switch. Aruba switches can be managed only by a Virtual Edge VM, not by a switch-hosted or cloud-hosted Virtual Edge. Standalone Virtual Edges are not supported when onboarding multiple Virtual Edge Nodes.

Step 2 - Choose the Virtual Edge Node Type

Click Next, then select Switch as the Virtual Edge Node type.

Step 3 - Virtual Edge Node Configuration

Enter the basic configuration for the switch.

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

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

Enable Aggregation Role, Enable Additional Flow Exporters, and Enable External Endpoint Discovery Management (Cisco Only) do not apply to Aruba switches and are ignored.

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

Inherit the Site Label and Distribution Zone from the parent Virtual Edge, or assign them directly to the Virtual Edge Node. Virtual Edge Nodes managed by one Virtual Edge can belong to different Distribution Zones with different Site Labels, and you can structure Virtual Edge relationships so that no switch needs its own assignment.

Step 5 - Review the Summary

Click Next to open the summary. Click Edit on any section to return to it and change the configuration. When the summary is correct, click Finish. Onboarding begins immediately, and the Virtual Edge Node and its status appear in Edge Management > Virtual Edge Nodes.

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. 

Platform Onboarding Notes

For Management IP, enter a routed in-band IP address in the default VRF on Aruba CX (never the out-of-band mgmt address; see Prerequisites), and the primary in-band management IP address on Aruba AOS-S.

Enabling MAC authentication on a port briefly interrupts each connected endpoint once while its authentication session is established. It is not a sustained outage. On Aruba CX, disabling Endpoint Discovery on a port does not drop traffic.

If a switch does not come online, check reachability, SSH access, and the Elisity administrator credentials. On Aruba CX, also confirm that it was onboarded on a routed in-band IP address in the default VRF; if it was onboarded on the out-of-band mgmt address, delete it and re-onboard it. On Aruba AOS-S, also confirm that DHCP snooping is operational (see Prerequisites).

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) or a Network-to-Network Interface (NNI), then programs configuration only on the ports where it belongs. On Aruba CX, Endpoint Discovery also controls enforcement; see Platform Differences below.

By default, Elisity applies Automatic configuration to all switch ports. In this mode the Virtual Edge evaluates each port to decide whether the port is UNI or NNI. The criteria for each platform are described in Platform Differences below.

Automatic configuration keeps Elisity off uplinks, distribution links, and management interfaces, where client tracking and flow telemetry would discover upstream infrastructure and collect unrelated traffic flows. NNI interfaces stay unconfigured while UNI interfaces keep full visibility.

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.

The Endpoint Discovery and Flow Telemetry checkboxes in the onboarding wizard enable or disable each feature globally for the Virtual Edge Node. They do not change how individual ports are classified. The same controls are available afterward in the Port Configuration view; see Modifying Port Configurations for a VEN below.

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, review the configuration of each port in Cloud Control Center and adjust it to your network design and the scope of your microsegmentation effort. If you left Endpoint Discovery and Flow Telemetry disabled during onboarding, enable automatic configuration or configure each port manually here.

To modify port configurations, click the more options button in the Actions column of the Virtual Edge Node row and select Port Configuration.

The Port Configuration view has an Endpoint Discovery tab and a Flow Telemetry tab. Each tab lists the switch ports with their Configuration Type, Status, and Source.

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.

In the port configuration editor, 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. 

Platform Differences

NNI ports receive no MAC authentication or flow telemetry. On Aruba AOS-S, a port that is tagged in one VLAN and untagged in another, such as an access port with a voice VLAN, looks the same as an uplink. It is treated as NNI, and receives no MAC authentication, until you classify it as UNI in Port Configuration.

Criteria for Automatic Port Configuration (Aruba CX)

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 Elisity 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. VSF ports reject 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, that is, ports that are not switchports. 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, and an IP phone is UNI. A neighbor advertising router, switch, or wireless access point capability is NNI. When Access Port Discovery Protection is enabled, an access-mode port with a router or switch neighbor remains UNI. See Aruba CX Switch Onboarding - Technical Reference for the full exception rules.
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.

Configure Access Policy

Configure Access Policy in three tasks: enable Access Policy, create an Access Policy rule set, and assign the rule set to a source Policy Group. The workflow is the same for Aruba CX and Aruba AOS-S.

Enable Access Policy Support

Access Policy is enabled on the Policy Set assigned to the Aruba 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 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. In the Create Policy Set panel it appears in the Access Policy Configuration section, where it is labeled Enable Access Policy.

Step 3. Display the Access Policy Column

Open the Policy Matrix, select the Policy Set assigned to the Aruba 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 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

Review the prefilled policy name and enter a description. In Security Profile, select the Access Policy rule set created previously.

To define a new rule set during this workflow, select Create Security Profile at the end of the list. In the Create Access Policy Security Profile dialog, enter a Profile Name, add the rules, and select Create. The new rule set is selected in the drawer automatically.

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

To confirm the configuration on the switch itself, see the Aruba CX or Aruba AOS-S section of Aruba Configuration Commands for Virtual Edge Node (VEN) Onboarding. The switch should hold the Elisity RADIUS configuration, RADIUS accounting, dynamic authorization, and elisity_default_role, along with the Elisity classes, policies, and roles described in Access Policy Model. Each endpoint session should carry the role for its Policy Group, applicable UNI interfaces should carry the configuration described in Configuration Applied by the Virtual Edge, and on Aruba AOS-S, DHCP snooping should remain enabled with the uplink trusted.

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.

Virtual Edge Failover

A VE Group provides management redundancy for the Aruba Virtual Edge Nodes. When the active configuration leader becomes unavailable, another Virtual Edge in the group assumes management of the Aruba 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

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.

Staging Access Policy Before Enforcement

Enable Policy Enforcement does not gate enforcement on Aruba switches. Clearing it during onboarding does not bring the switch into service as a discovery-only node: Access Policies configured on the Policy Set are still programmed on the switch.

Create the Access Policy as Simulated Policy to stage it before enforcement. Devices that match a Simulated Policy keep the Elisity default allow role while the assignment is evaluated.

Access Policy Disabled

A Virtual Edge Node onboarded while Access Policy is disabled registers and then reports a Degraded status, with a Policy Status message in its status details. On Aruba AOS-S, endpoint discovery and flow telemetry continue, and no traffic is blocked.

Platform Differences

On both switch families, Change of Authorization is also sent when an endpoint moves to a different Policy Group. Elisity marks the policies it creates with the elisity_ prefix and changes or removes only objects it created. Customer-managed RADIUS servers, roles, and policies are left untouched.

Port Classification Changes (Aruba CX)

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.

VXLAN (Aruba CX)

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.

Rule Capacity (Aruba AOS-S)

Access Policy rules share the rule resources of the switch, and smaller models such as the 2530 hold fewer rules, so keep rule sets compact.

Decommissioning and Deleting a Virtual Edge Node

Decommissioning a Virtual Edge Node removes the Elisity configuration from the switch but keeps the Virtual Edge Node in Cloud Control Center, so you can return it to service with a single click.

Open the Virtual Edge Node details view and select Decommission in the top right. The status changes to Decommissioned.

You can also decommission from the Virtual Edge Node list: click the three dots in the row and select Decommission Virtual Edge Node.

To decommission several Virtual Edge Nodes at once, select them with the check boxes on the left, click Bulk Actions, and select Decommission. The menu also offers Recommission, Change Group, Change Credentials, Delete, and Force Delete, and actions that do not apply to the current selection are unavailable.

Each method opens a confirmation dialog, with warnings or errors where applicable.

The Activity Panel is where Virtual Edge Node lifecycle operations, including decommissioning, report their progress. Open it through the notification icon in the top right corner of Cloud Control Center and select the Activity tab of the Notifications panel. Filter events by Complete, Error, or In Progress, or click View All Activity for earlier events.

After decommissioning, delete the Virtual Edge Nodes from Cloud Control Center, or leave them decommissioned to recommission later. The more options button in the Actions column shows the Delete Virtual Edge Node and Recommission Virtual Edge Node options for each Virtual Edge Node. Options that do not apply to the current state of the Virtual Edge Node are unavailable. The Actions menu also offers Force Delete Virtual Edge Node for a Virtual Edge Node in the Decommission Started or Decommission In Progress state, 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 decommissioned Virtual Edge Node 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.

Recommission a Virtual Edge Node from the Decommissioned state the same way you decommission it. Recommission is also available to retry from the Recommission Failed and Decommission Failed states, and the Activity Panel tracks each recommissioning step.

On Aruba AOS-S, decommissioning removes MAC authentication from the access ports, which re-authenticates each connected endpoint once. Settings that can only be reset rather than removed, such as the MAC address format and the per-port address limit, return to platform defaults, and custom values that existed before onboarding are not restored. elisity_default_role remains on the switch, and DHCP snooping is not changed.

Recommissioning restores the full Elisity configuration and re-enables MAC Authentication Bypass on applicable access ports on both switch families, so recommission during a planned change window.

Related Articles

• Aruba Configuration Commands for Virtual Edge Node (VEN) Onboarding
• Aruba CX Technical Reference
• Hardware Compatibility Matrix
• Configuring Access Port Discovery Protection for Virtual Edge Nodes
• Virtual Edge Hypervisor Deployment Guide
• Virtual Edge Groups
• Policy Sets and Site Labels
• Policy Groups
• Policy Matrix
• Platform Connectivity Requirements
• Bulk Onboarding Virtual Edges and Virtual Edge Nodes