Onboarding Juniper Switches as Virtual Edge Nodes (Juniper Mist)

This article walks through the steps to onboard, configure, and manage access switches managed by Juniper Mist as Virtual Edge Nodes in the Elisity Platform.

Supported Switch Platforms

• The following Juniper Access switch models have been validated: EX4100 and EX4400

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

Licensing Requirements

Design Specific Notes/Limitations

• IRB Requirement: For each VLAN where enforcement is desired, an IRB must be configured.

• Layer 3 Policy Only: Layer 4 policy is not supported, only the final policy action of Permit All or Deny All will take effect.
• Flow Collection: You can configure a collector only within the same routing instance as the data. You cannot configure a collector within a different routing instance.

Prerequisites

• Licensed Juniper Mist Instance and Switches
• Juniper Mist Global Region
• Juniper Mist Org ID
• Juniper Mist API Key

Connectivity Requirements

Design and Enforcement Considerations

Policy enforcement on the Juniper switches operate separately at layer 2 and layer 3.  
To provide policy coverage for all traffic flows, both the access layer switch and the layer 3 gateway switch must be onboarded and in activated policy sets.

Visibility and Telemetry data is only collected from Inter-VLAN flow on the L3 Interfaces (IRBs) on Juniper switches.

Key Enforcement Implications

Intra-VLAN Traffic

• Policy is enforced at the access layer directly on the EX4400 for hosts in the same VLAN. The switch uses GBP-based policy that leverages MAC Address to enforce communication rules between ports on the same VLAN.

Inter-VLAN Traffic

• Policy must be enforced at the Layer 3 boundary, typically at the distribution or aggregation layer.
• The switch at the Layer 3 boundary must be supported as a Virtual Edge Node and onboarded to Elisity for enforcement to occur.
• All VLANs trunked to the L3 boundary MUST have mapped VNIs.
• The L3 enforcement point MUST have shared device group tag mappings from the VENs where assets are discovered. This can be done using a Core Distribution Zone configured to import appropriate Access DZs, as seen in the example diagram. This can also be accomplished using Intelligent Tag Distribution in various design models, or using a single Distribution Zone.

In the illustrated deployment model, an onboarded EX4100 (Core DZ) enforces traffic between VLANs 31 and 32. 

Deploying Juniper Mist Virtual Edge in Cloud Control Center

The integration between Elisity and Juniper is a departure from our other method of onboarding Cisco and Arista switching infrastructure. Instead of deploying an Elisity Virtual Edge on premise for Identity and Policy, Elisity instantiates a cloud hosted Virtual Edge that integrates with Juniper Mist via API in order to onboard Juniper access switches, collect device identity data, and manage microsegmentation policies. 

A Virtual Edge is deployed on-premises and functions as a flow collector for the Mist-managed switches.

This architecture is detailed in the following diagram. 

Enabling Juniper Mist Integration

Creating an Elisity Switch Template

Step 1: Log into Juniper Mist and navigate to Organization > Switch Templates. 

 

Step 2: Either edit an existing template or create a new one. 

Step 3: In the CLI Configuration section add the following commands which enables Group-Based Policy (GBP) in the EVPN-VXLAN fabric. 

# Group: Elisity VXLAN Base
set groups elisity_evpn forwarding-options evpn-vxlan gbp ingress-enforcement**
set groups elisity_evpn chassis forwarding-options vxlan-gbp-l3-profile**
set groups elisity_evpn interfaces lo0 unit 0 family inet address 1.2.3.4/32
set groups elisity_evpn routing-options router-id 1.2.3.4
set groups elisity_evpn protocols evpn encapsulation vxlan
set groups elisity_evpn protocols evpn extended-vni-list all
set groups elisity_evpn switch-options vtep-source-interface lo0.0
set groups elisity_evpn switch-options route-distinguisher 1.2.3.4:100
set groups elisity_evpn switch-options vrf-target target:1:100
set apply-groups elisity_evpn

Step 4: If the template is not already assigned to a site, assign it to a site. Select Assign to Sites.

Select the site you wish to apply the template to and click Add and Apply.

Step 5: The next step is to override the template on a per switch basis in order to configure additional CLI commands that are specific to that switch. Navigate to Switches, select the site, and then select the switch you wish to configure. At the top of the screen, click the hostname of the switch to enter switching configuration mode. 

Step 6: In the CLI Configuration section and under the Additional CLI Commands subsection add the following commands and select Save:

The following is only an example. 

# Group: VXLAN VLAN and IRB Provisioning
set groups elisity_vxlan interfaces irb unit 601 family inet address <VLAN601 IP/Mask>
set groups elisity_vxlan interfaces irb unit 602 family inet address <VLAN602 IP/Mask>
set groups elisity_vxlan vlans VLAN601 l3-interface irb.601
set groups elisity_vxlan vlans VLAN602 l3-interface irb.602
set groups elisity_vxlan vlans VLAN601 vxlan vni 601
set groups elisity_vxlan vlans VLAN602 vxlan vni 602
set groups elisity_vxlan vlans VLAN601 vlan-id 601
set groups elisity_vxlan vlans VLAN602 vlan-id 602
set apply-groups elisity_vxlan

# Group: Monitoring Template and Flow Export
set groups elisity_monitor_template services inline-monitoring template template_1 template-refresh-rate 30
set groups elisity_monitor_template services inline-monitoring template template_1 observation-domain-id 25
set groups elisity_monitor_template services inline-monitoring template template_1 template-id 32768
set groups elisity_monitor_template services inline-monitoring template template_1 flow-inactive-timeout 10
set groups elisity_monitor_template services inline-monitoring template template_1 template-type ipv4-template
set groups elisity_monitor_template services inline-monitoring instance i1 template-name template_1
set groups elisity_monitor_template services inline-monitoring instance i1 collector c2 source-address <Flow Source IP>
set groups elisity_monitor_template services inline-monitoring instance i1 collector c2 destination-address <Virtual Edge IP>
set groups elisity_monitor_template services inline-monitoring instance i1 collector c2 dscp 21
set groups elisity_monitor_template services inline-monitoring instance i1 collector c2 destination-port 9996
set groups elisity_monitor_template firewall family inet filter ipv4_ingress term rule1 then inline-monitoring-instance i1
set apply-groups elisity_monitor_template

# Group: Apply Monitoring Filter to Interfaces
set groups elisity_monitor_enable interfaces irb unit 601 family inet filter input ipv4_ingress
set groups elisity_monitor_enable interfaces irb unit 602 family inet filter input ipv4_ingress
set apply-groups elisity_monitor_enable

Generating Juniper Mist API Token

Step 1: Log into Juniper Mist and navigate to Organization > Settings. 

Step 2: Copy Organization ID to a notepad as this information will be used later in the deployment guide. 

Step 3: In the API Token section, select Create Token

Give the token a name, set the Access Level to Super User and the Site Access to All Sites and then select Generate. 

Step 4: After generating the token, Copy the Key as it will be used in the next section of the integration guide.

Configuring a Juniper Mist Cloud Controller

Step 1: Navigate to Virtual Edges > Settings.

Step 2: Select Cloud Controllers > Add Controller.

Step 3: Add the following details for the cloud controller and click Add.

• Name - Enter a name for the cloud controller.
• URL - Enter the URL for the Juniper Mist portal as follows:
  1. Log in to the Juniper Mist portal.
  2. Copy the URL from the address bar.
  3. Change https://manage.ac2.mist.com/... to https://api.ac2.mist.com/...
• Org ID - Enter the Organization ID which is available in Juniper Mist under Organization>Settings>Organization Settings>Organization ID.
• API Key - Enter the key generated during token creation.
• Description - Enter a description for the cloud controller.

Adding Virtual Edge Nodes in Cloud Control Center

Step 1 - Launch the Virtual Edge Node Deployment Wizard

Select the Virtual Edge Nodes tab and click + Add Virtual Edge Node, then select Add Single Virtual Edge Node. This launches the Virtual Edge Node Deployment Wizard.

Step 2 - Choose a Virtual Edge

Select Virtual Edge Group or Switch Hosted to determine how the Virtual Edge Node will be managed. For Juniper Mist deployments, select a Virtual Edge Group that contains a cloud-hosted Virtual Edge configured for Juniper Mist integration.

Step 3 - Choose the Virtual Edge Node Type

Select Cloud Managed as the Virtual Edge Node type.

Step 4 - Virtual Edge Node Configuration

Provide the required information about the switch. See the table below for details on each field.

* Note: Depending on which Mist cloud region is in use, the onboarding identifier may be the serial number of the primary device or the device ID in a virtual switch stack (e.g., api.eu.mist.com — serial number was successful in registering).

Step 5 - Site Label and Distribution Zone

Choose to inherit Site Label and Distribution Zone from the parent Virtual Edge, or manually assign them directly to the Virtual Edge Node.

Step 6 - Advanced Settings

Expand the Advanced Settings section to review optional configuration controls for the Virtual Edge Node before completing onboarding.

The following table provides details about each setting in this section.

Step 7 - Review the Summary and Click Finish

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