This article summarizes how to onboard your Juniper access layer switches as Virtual Edge Nodes for policy enforcement. This can only be done after deploying a Virtual Edge.
Prerequisites
Supported Platforms
Direct onboarding is supported for Juniper EX4100 and EX4400 switches running JunOS 22.4R1 or later.
Feature Enablement and Licensing
Feature Enabled | Group-Based Policies (GBP) |
Licensing Requirement | VxLAN |
EVPN-VxLAN | |
Flow Based Telemetry | |
Firewall Microsegmentation |
Network Accessibility
- The Virtual Edge must have IP reachability to the management interface of the Juniper switch.
- SSH must be enabled and accessible on TCP port 22.
- User Credentials: Onboarding requires a user with super-user privileges. This can be a local account or one authenticated via TACACS or RADIUS.
- Time Synchronization: The switch should be synchronized with a trusted NTP source to ensure correct timestamping and correlation with directory-based identity systems.
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.
Additional Topology Guidance
- Onboard access switches (EX4400s) in conjunction with a supported L3 boundary switch (e.g., EX4100).
- Ensure trunk links between access switches and the L3 boundary include all VLANs subject to policy enforcement. Ensure every VLAN has a VNI mapped - If a single VLAN in the trunk does not have a VNI, this will result in an error.
- Plan policies with awareness of where the enforcement boundary exists for each traffic path (Intra-VLAN or Inter-VLAN)
Onboarding Steps
Before onboarding some base configuration needs to be set to enable GBP based discovery and policy enforcement. The following commands enable Group-Based Policy (GBP) in the EVPN-VXLAN fabric. All IP addresses and interface names shown are examples only. You must update them to match your environment and review the configuration carefully before applying.
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, issue the following command to restart the Packet Forwarding Engine (PFE):
restart 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.
set forwarding-options evpn-vxlan gbp ingress-enforcement
set chassis forwarding-options vxlan-gbp-l3-profile
set interfaces lo0 unit 0 family inet address 1.2.3.4/32
set routing-options router-id 1.2.3.4
set protocols evpn encapsulation vxlan
set protocols evpn extended-vni-list all
set switch-options vtep-source-interface lo0.0
set switch-options route-distinguisher 1.2.3.4:100
set switch-options vrf-target target:1:10
set vlans VLAN601 vxlan vni 601
set vlans VLAN602 vxlan vni 602
set vlans VLAN601 vlan-id 601
set vlans VLAN602 vlan-id 602
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
Next, provide some basic information about the switch and make a few configuration selections. See the list below for details.
The following chart provides details about each field in this step.
Enable NAT Support | Enables the configuration of an inside and outside management IP for NAT Support. Read the Virtual Edge Node NAT Support article to learn more about this configuration. |
Switch Management IP | This is the management IP of the switch you wish to onboard as a Virtual Edge Node for policy enforcement. This can be an IP as long as it is reachable by the previously deployed Virtual Edge container. This field is mandatory. |
Description | This allows a user-defined description to be configured for the VEN. This field is optional. |
**Enable Endpoint Discovery |
Selecting this option enables the active collection of identifying data for endpoints discovered behind a VEN, gleaned from access switch telemetry. This feature actively tracks assets for updates in identifying data. (Recommended) This setting is autoconfigured per switchport if enabled during this onboarding. You can choose to enable autoconfiguration or manually configure after onboarding by leaving this box unchecked. The logic for this autoconfiguration is discussed later in this article. |
**Enable Flow Telemetry |
Selecting this option enables the collection of flow data and network traffic analytics that are sent to Cloud Control Center. (Recommended) This setting is autoconfigured per switchport if enabled during this onboarding. You can choose to enable autoconfiguration or manually configure after onboarding by leaving this box unchecked. The logic for this autoconfiguration is discussed later in this article. If the switch is already leveraging AVC FNF configuration via DNAC, please contact your Elisity technical contact before enabling this feature. |
Select Exporter | Custom flow exporters allow organizations to integrate Elisity's flow telemetry with existing network monitoring solutions. For customers who already rely on third-party tools for network analytics and traffic visibility, this feature provides a way to direct flow data from Virtual Edge Nodes (VENs) to an external monitoring system. Read here for more information on configuring flow exporters for Virtual Edge Nodes. |
Switch Credentials |
Administrators can use Global Credentials to securely store and reuse switch credential sets for deployments. Read here to learn more about configuring and using Global Credentials. If not using global credentials, the admin username of the switch you wish to onboard as a Virtual Edge Node can either be local or TACACS/RADIUS. Privilege 15 is required. This field is mandatory. Username should be alphanumerical and may contain only permitted special characters (_, +, \\\\, /, -).'} If not using global credentials, the admin password of the switch you wish to onboard as a Virtual Edge Node can either be local or TACACS/RADIUS. Privilege 15 is required. Password cannot contain whitespaces. This field is mandatory.
|
**NOTE: If you would prefer to manually configure switchport configurations, or enable autoconfiguration at a later time, leave these 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.
Site Label | Site labels can be applied to Virtual Edge Nodes for policy distribution and for 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 |
Here we can select to inherit the Distribution Zone from the parent Virtual Edge, or we can assign an Access Distribution Zone or create an Isolated Distribution Zone. For more information on creating and assigning Access/Isolated DZs or to learn about DZs as a concept, click on one of the following links. Creating and Assigning Distribution Zones to Virtual Edge Nodes |
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.
Port Configurations on Virtual Edge Nodes
Port configurations for endpoint discovery and analytics can be manually configured or automated based on the following logic.
Elisity offers the ability to automate the configuration process for switch ports to selectively enable or disable the collection of device and analytics data. This automation is enabled during Virtual Edge Node onboarding where administrators have the option to enable Enhanced Endpoint Discovery, Flow Telemetry, and Passive Endpoint Discovery upon onboarding. This automation is designed to enhance network security and operational efficiency by focusing on relevant data collection and minimizing unnecessary endpoint discovery and telemetry on specific ports. This prevents discovery and analytics of devices that are not in the scope of an organizations microsegmentation efforts, such as upstream networking equipment or daisy chained access switch designs.
Endpoint Discovery and Telemetry Mechanisms
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.
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 Port Settings Globally for Virtual Edges
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.
- Select Virtual Edges>Settings>Advanced Settings.
Toggle Enable Discovery and Telemetry and enter keywords to designate the port as UNI.
- Toggle Disable Discovery and Telemetry and enter keywords to designate the port as NNI.
- Click Save Changes.
Note: If system-level environment variables for UNI and NNI are set, they will override any configuration entered through the Settings page. Check with your Elisity engineer for any configured environment variables in your environment if you are having issues with this feature.
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.
To do this, select your VEN, navigate to Port Configurations, and click Edit Port Configuration. This will take you to the port configuration editor for all three settings, regardless of which port configuration setting you are currently viewing.
If you have not yet configured any port configurations, simply click on Add Port Configuration as seen below.
The port configuration editor is very straightforward. For each setting, you can globally enable or disable for the selected VEN. Just below the global setting, you can choose automatic or manual port configurations for the selected setting. For manual configuration, you can select specific ports or select all ports by clicking the top check box. After selecting ports, use the arrows between the two columns to move ports into the Disabled Ports or Enabled Ports tables.
Selecting Automatic Configuration will overwrite any manually configured ports, and will disable the ability to select switchports for each table as this process will be handled according to the logic defined earlier in this article.
After reviewing these port configs and making any adjustments, click Submit and your configurations will be immediately pushed to the VEN. Within 24 hours you should begin to see discovery data and analytics.
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.