Onboarding Cisco Switches as Virtual Edge Nodes

This article summarizes how to onboard your Cisco Catalyst and Industrial Edge access layer switches as Virtual Edge Nodes for policy enforcement. This can only be done after deploying a Virtual Edge.

Prerequisites

Most switches which support TrustSec capabilities are supported as Virtual Edge Nodes, including the Catalyst 3650/3850, many switches in the Catalyst 9000 series, and several IEM3400 switch models.

Please refer to the Hardware Compatibility Matrix for the complete list of validated switch models and minimum recommended code versions.

Licensing Requirements

Model Specific Notes/Limitations

If the Catalyst 9410 being onboarded is hosting a Virtual Edge using the Application Hosting functionality, it is mandatory to disable Elisity identity on GigabitEthernet4/0/48. See this step for instructions. 

For Catalyst 9600 series switch: If Cisco StackWise Virtual (SVL/DAD) is configured, Passive Endpoint Discovery must be disabled during onboarding.

For IE3400 switches, only IEM3400 switch modules are supported.

Notes for All Switches

• To ensure accurate user and device attachment data, onboarded switches and Active Directory Domain Controllers must be time-synced using NTP. Ideally, both should use the same NTP source, but a public server like time.google.com is also acceptable.
• SSH access must be enabled on the switches you wish to onboard. Follow this article to enable SSH. 
• The IP address used to onboard the switch must be reachable within the same VRF as the VLAN interfaces being configured by Elisity. 
• Using a management IP that resides in a separate VRF (such as mgmt-vrf) is not supported.
• Use the primary IP address of the switch's management interface. Do not use HSRP, VRRP, GLBP, or any secondary IP address. Using a non-primary or virtual address will result in onboarding errors and unexpected Virtual Edge Node behavior.

• For syslog-enabled Virtual Edge Nodes (default), ensure the following configuration is present to accurately track attach and detach events in Cloud Control Center:

  logging level informational

Connectivity Requirements

Onboarding Steps 

Step 1:  You should either have a user account with privilege 15 configured or TACACS login configured to provide privilege 15 level access. This is needed for the Virtual Edge to authenticate with the switch. Execute the following command under global configuration mode if a local account is being used and is not already configured:

switch(config)# username <username> privilege 15 secret 0 <password>

Depending on AAA/TACACS configuration, it may be required to add the following configurations to the switch for the Virtual Edge (VE) to successfully onboard the switch.

   Change the following TACACS+ config:

aaa authorization exec default if-authenticated

   to the following:

aaa authorization exec default group <ise-tacacs> if-authenticated

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. 

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

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.

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. 

Port Configurations on Virtual Edge Nodes

Port configurations define how each switch port on a Virtual Edge Node (VEN) participates in Endpoint Discovery and Flow Telemetry. These configurations control where Elisity collects device identity and traffic flow data and ensure that discovery and telemetry are applied only to the appropriate interfaces within the access layer.

By default, Elisity applies Automatic configuration to all switch ports. In this mode, Elisity evaluates each port using discovery protocol data, interface type, and topology to determine whether the port should included in device discovery and traffic analytics collection. This classification process is described in detail in the Criteria for Automatic Port Configuration section.

Automatic configuration ensures that Endpoint Discovery and Flow Telemetry operate only where appropriate. Enabling these features on NNI interfaces - such as uplinks, distribution links, or management ports - can result in the discovery of upstream infrastructure devices and the collection of unrelated traffic flows. Elisity’s automatic port evaluation prevents these conditions by disabling discovery and telemetry on NNI interfaces while maintaining visibility on UNI interfaces.

Administrators can change any port from Automatic to Manual configuration at any time to explicitly enable or disable Endpoint Discovery and Flow Telemetry for that specific port. Manual configuration is typically used in environments where certain interfaces require behavior different from Elisity’s automatic classification logic. Ports can also be switched back to Automatic configuration if Elisity should resume management of their behavior.

During onboarding, the checkboxes for Endpoint Discovery and Flow Telemetry enable or disable each feature globally for the VEN. These global toggles determine whether Elisity activates each feature at the VEN level and for all applicable switchports; they do not change how ports are classified or configured. The same global enable and disable controls are available later from the Port Configuration view in Cloud Control Center. For step-by-step instructions on editing port configurations after onboarding, including switching between Automatic and Manual configuration modes, see Modifying Port Configurations for a VEN.

Endpoint Discovery and Flow Telemetry

Endpoint Discovery leverages embedded switch functionality to learn and track devices connected to the switch directly or through a trunk to a downstream switch. With automatic configuration, Flow Telemetry will be disabled on the specified port types but can still be enabled or disabled manually per switchport, or globally on a per-VEN basis as required.

Flow Telemetry (Cisco Netflow or equivalent per vendor) provides valuable insights into your network's traffic patterns. With automatic configuration, Flow Telemetry will be disabled on the specified port types but can still be enabled or disabled manually per switchport, or globally on a per-VEN basis as required.

Existing Flow Telemetry Configurations 

In order to gather flow telemtry from infrastructure, Elisity configures flow exporters on switches with the Virtual Edge as the destination for flow telemetry, and configures switch interfaces with the Elisity-generated flow configuration. 

In some customer environments, existing flow exporter configurations may already be configured both in the global configuration and for each applicible interface. In these scenarios, existing flow exporter configurations and interface configurations are not removed by Elisity. These configurations will not be overwritten, and will remain until the customer removes them manually or via the hardware configuration platform. 

The Elisity Flow Exporter global configuration will successfully be programmed by the Virtual Edge in most cases and can exist alongside any customer-configured flow exporter configurations. The VE will attempt to configure interfaces with Flow Telemetry port configuration on a regular interval, however, flow telemetry interface configurations cannot be programmed by the Virtual Edge until existing configurations are removed. 

For Flow Telemetry to be enabled, Elisity must leverage the primary flow configuration on each interface where the feature is enabled. You can replace existing flow configurations by leveraging a custom flow exporter, which will send all flow data to a second receipient (alongside the Virtual Edge). This is configured in Cloud Control Center and can be configured for each onboarded Virtual Edge Node. Read this article for details on how custom secondary flow exporters are configured on Cisco, as an example.

Criteria for Automatic Port Configuration

Elisity leverages Cisco Discovery Protocol (CDP) and Link Layer Discovery Protocol (LLDP), along with a set of rules based on interface types and network topology, to classify switch ports as either User Network Interfaces (UNI) or Network-to-Network Interfaces (NNI). This classification determines where Endpoint Discovery and Flow Telemetry are enabled, ensuring accurate network visibility while preventing redundant data collection.

UNI and NNI Port Detection and Endpoint Discovery Configuration

By default, all ports are classified as UNI unless they meet NNI criteria. Elisity evaluates multiple factors, including CDP/LLDP neighbor data, VRF configurations, port descriptions, and interface types, to make this determination.

A port is classified as NNI if:

• It has a CDP/LLDP neighbor that is identified as a router, switch (bridge for LLDP), or IGMP device. Exceptions include WLANs and Hosts, which remain classified as UNI.
• Its interface name contains keywords such as Router, Firewall, or NNI.
• It is listed as an interface in any VRF instance.
• It is administratively down.
• It is not a switchport.
• It is a Stackwise Virtual Link.
• For Port-Channel interfaces: If any of its member interfaces meet NNI criteria, the Port-Channel itself is classified as NNI. However, member interfaces are ignored for Endpoint Discovery.

Ports that do not meet any of the above conditions remain classified as UNI, meaning Endpoint Discovery is enabled to track directly connected devices.

Flow Telemetry Configuration

Flow Telemetry is configured differently from Endpoint Discovery. Unlike Endpoint Discovery, which is disabled on Port-Channel interfaces and their members, Flow Telemetry is enabled on individual Port-Channel members for more granular traffic visibility.

Flow Telemetry is disabled on:

• VLAN, AP, LOOP, TUNNEL, and CHANNEL interfaces.
• Management interfaces such as GigabitEthernet0/0 (most models) and TenGigabitEthernet0/1 (Cisco 9600).
• Stackwise Virtual Links.

CDP/LLDP for Uplink Detection

Elisity periodically scans CDP/LLDP neighbor tables to detect topology changes. If a port connects to another switch or router, Endpoint Discovery and Flow Telemetry are automatically disabled to prevent redundant infrastructure visibility. These updates occur every five minutes, ensuring configurations remain accurate as the network evolves.

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 switchport 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, selected Enabled or Disabled. If you choose Automatic (default) the port configuration will be displayed in this place and cannot be changed unless configutation type is changed.

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

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.