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, with Layer 2–Layer 4 microsegmentation policy enforced at the access layer.
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
| Licensing Requirement | Feature Enablement |
|---|---|
| VxLAN | Group-Based Policies (GBP) |
| EVPN-VxLAN | |
| Flow Based Telemetry | |
| Firewall Microsegmentation |
Design Specific Notes/Limitations
- Layer 4 Policy Support: In addition to the Layer 3 final policy actions of Permit All or Deny All, Juniper Mist Virtual Edge Nodes enforce Layer 4 rules. Matching is performed on protocol (TCP or UDP) and destination port; source-port matching is not enforced on Juniper Mist switches. Unified Layer 2–Layer 4 enforcement at the access layer requires Junos OS 24.4R2-S3 / 25.4R1-S1 or newer.
- 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
- Permanent Flow-Based Telemetry license installed on each switch (EX4400 or EX4100). Verify with
show system license. Flow telemetry is not exported without this license. - Juniper Mist Global Region
- Juniper Mist Org ID
- Juniper Mist API Key
Connectivity Requirements
Use the primary IP address of the switch's management interface. Do not use VRRP virtual IP addresses or any non-primary or secondary address. Using a non-primary or virtual address will result in onboarding errors and unexpected Virtual Edge Node behavior.
| Direction | Required Traffic |
|---|---|
| Virtual Edge to Cloud Control Center | HTTPS (TCP/443) |
| Virtual Edge to Mist Cloud | HTTPS (TCP/443) |
| Virtual Edge Node to Virtual Edge | IPFIX Flow Data (UDP/9996) |
Design and Enforcement Considerations
Juniper Mist Virtual Edge Nodes enforce microsegmentation policy at the access layer, on the edge switch, before traffic leaves the port. On Junos OS 24.4R2-S3 / 25.4R1-S1 or newer, both inter-VLAN and intra-VLAN Layer 2–Layer 4 segmentation are supported and enforced at the access layer. Visibility and flow telemetry are collected from both intra-VLAN flows at the access ports and inter-VLAN flows.
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 to connect to network infrastructure for Identity and Policy, Elisity 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. These are applied at the organization template level and are identical on every switch — they enable Group-Based Policy (GBP) policy enforcement and define the flow-based telemetry template used to export flow records to the Virtual Edge.
Note: If Group-Based Policy (GBP) functionality (such as gbp-tag firewall filters) was not previously configured on the device, a restart of forwarding processes is required for enforcement to take effect.
- On standalone switches, committing the profile automatically reloads the Packet Forwarding Engine (PFE).
- On Virtual Chassis (VC) deployments, a full chassis reboot is required to ensure GBP enforcement is correctly applied across all member switches.
This behavior is due to how JunOS initializes filter processing pipelines at boot. GBP filters applied post-boot will not fully propagate or function until the appropriate restart has occurred.
# Group: Elisity GBP Policy Enforcement
set chassis forwarding-options gbp-pure-l2-profileNOTE: The gbp-pure-l2-profile command shown above reloads the forwarding engine if GBP was not previously configured on the device. On a standalone switch this reload occurs when the configuration is committed and causes approximately 10 seconds of traffic disruption; on a Virtual Chassis (stack) it requires a full chassis reboot. Subsequent GBP configuration changes do not require a restart.
In the same CLI Configuration section, add the flow-based telemetry template. These commands are applied at the organization template level and are identical on every switch. They define the inline monitoring template, the collector, and the ethernet-switching filter that exports per-flow records to the Virtual Edge. The collector's source-address and destination-address are intentionally omitted here — they are added at the site and switch level in the following steps, and the configuration commits only once all three are present.
# 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 destination-port 9996 # Ethernet-switching (L2) filter definition set groups elisity_monitor_template firewall family ethernet-switching filter eth_ingress term rule1 then accept set groups elisity_monitor_template firewall family ethernet-switching filter eth_ingress term rule1 then inline-monitoring-instance i1 set apply-groups elisity_monitor_template
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: Set the Virtual Edge IP for each site. Navigate to Organization > Site Configuration, select the site, and under Switch Configuration > Additional CLI Commands add one line with that site's Virtual Edge IP, then select Save. The Virtual Edge is the on-premises flow collector for the site.
Note: Mist site variables ({{var}}) are not substituted in the Additional CLI Commands field — always enter a literal IP address. Apply the Virtual Edge IP at the site level and the flow source IP at the switch level (Step 7); the configuration commits only once the organization template, the site Virtual Edge IP, and the per-switch source address are all present.
set groups elisity_monitor_template services inline-monitoring instance i1 collector c2 destination-address <Virtual Edge IP>
Step 6: 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 7: On the per-switch override, in the CLI Configuration section under the Additional CLI Commands subsection, add the flow source address for this switch and attach the telemetry filter to the access port profiles, then select Save:
Note:
- The configuration uses JunOS set groups syntax, the recommended best practice for Mist-managed switches.
- Group and instance names such as elisity_monitor_template, template_1, and i1 are example names — rename them to match your organization's conventions, keeping them consistent with the organization template from Step 3.
- Replace the Flow Source IP placeholder with the primary IP address of the switch's management interface. Do not use VRRP virtual IPs or secondary addresses.
- Replace Wired_Data and Wired_Voice with your organization's Mist port profile names — add one line per access port profile that should export telemetry. Your environment may have more or fewer than two access profiles; uplink and trunk profiles are excluded by not listing them.
# Per-switch flow source address set groups elisity_monitor_template services inline-monitoring instance i1 collector c2 source-address <Flow Source IP> # Attach the telemetry filter to access port profiles set interfaces interface-range Wired_Data unit 0 family ethernet-switching filter input eth_ingress set interfaces interface-range Wired_Voice unit 0 family ethernet-switching filter input eth_ingress # set interfaces interface-range <Additional_Profile> unit 0 family ethernet-switching filter input eth_ingress
Note: Referencing an interface-range that has no member ports on a switch creates an empty range and causes the commit to fail. If a port profile is not present on every switch, apply these filter-attachment lines only on the switches that use the profile (device level) rather than in the organization template.
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:
- Log in to the Juniper Mist portal.
- Copy the URL from the address bar.
- 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.
| Field | Description |
|---|---|
| Management IP | The management IP address of the switch to onboard as a Virtual Edge Node. |
| Serial Number | The serial number of the switch to onboard as a Virtual Edge Node.
|
| Cloud Controller | Select the previously created Cloud Controller configuration. |
| Description | A user-defined description for the Virtual Edge Node. This field is optional. |
* 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.
| Field | Description |
|---|---|
| Site Label | Site labels can be applied to Virtual Edge Nodes for policy distribution and analytics purposes. Site labels are used to assign Virtual Edges and Virtual Edge Nodes to Policy Sets. Read more about Site Labels and Policy Sets here. |
| Distribution Zone | Select to inherit the Distribution Zone from the parent Virtual Edge, assign an Access or Core Distribution Zone, or create an Isolated Distribution Zone. If you are unfamiliar with the concept of Distribution Zones, read here. |
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.
| Setting | Description |
|---|---|
| Enable Policy Enforcement | Controls whether policy enforcement is configured on the Virtual Edge Node. This setting is enabled by default. When enabled, IP-to-tag mappings and policy configurations are programmed to the switch through Juniper Mist, and the Virtual Edge Node operates as a full enforcement point. When disabled, the Virtual Edge Node operates in discovery-only mode: device discovery and flow telemetry remain active, but no policy or tag-mapping configurations are pushed to the switch. Discovery-only mode is suitable for environments with restrictive change windows, for visibility-first deployments, or where policy enforcement is not yet required. This toggle is also available from the Virtual Edge Node detail page under Advanced Settings after onboarding. |
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.
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. Endpoint Discovery is enabled on all ports by default and can be enabled or disabled manually per switchport, or globally on a per-VEN basis, using the Manual configuration option described below.
Flow Telemetry provides valuable insights into your network's traffic patterns. Flow Telemetry is enabled on all ports by default and can be enabled or disabled manually per switchport, or globally on a per-VEN basis, using the Manual configuration option described below.
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.
Automatic UNI/NNI port classification is not yet available for Juniper Mist Virtual Edge Nodes. All switch ports are currently classified as User Network Interfaces (UNI) by default, with Endpoint Discovery and Flow Telemetry enabled on every port. Support for automatic classification of Network-to-Network Interfaces (NNI) is planned for an upcoming release.
Because automatic NNI classification is not yet available for Juniper Mist Virtual Edge Nodes, disabling Endpoint Discovery and Flow Telemetry on NNI-type interfaces (such as uplinks, distribution links, or management ports) requires switching those ports to Manual configuration.
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.
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.