Configure Microsegmentation for SD-LAN

Last updated
Save as PDF

For supported software information, click here.

The Versa Networks microsegmentation solution for SD-LAN networks takes a comprehensive, security-focused approach to enabling access to network segments dynamically, pairing the use of software to define the microsegments with the continuous monitoring of zero-trust attributes implemented on edges of the network. This approach enables greater flexibility, easier configuration, and allows you to create smaller sub-segments across network environments, each with its own policies, security functions, and controls. By tightly controlling access to sensitive data, applications, and devices from potentially compromised or unauthorized entities on an ongoing basis, this approach provides much needed layers of security.

Traditional network security models primarily rely on securing the network perimeter, using methods such as firewalls to protect the entire network. With SD-LAN microsegmentation, you can restrict lateral movement (east-west traffic) within an SD-LAN network by dividing the network into smaller segments and then applying security controls at a more granular level. You can define the microsegments based on both network-based elements such as IP address, MAC address, and VLAN, and also on security-based elements such as device posture, fingerprinting, and device risk score.

Microsegmentation is implemented through policies in two planes: control plane (what microsegment is associated with a particular IP address) and data plane. The control plane policy is the same for both hardware ASIC-based forwarding and software-based forwarding. Data plane policy is implemented through NPU ACL policies or NGFW policies based on the source scalable group tag (SGT) or the destination SGT.

The Versa Networks microsegmentation solution for SD-LAN networks provides the following benefits:

Zero-trust everywhere—AI-driven, standards-compliant, and software-defined networking and security converged stack with single pane-of-glass operations, uniform policy language, and entry scans for Enterprise Assets at every edge, including LAN, WAN, cloud, and compute.
Open hardware
EVPN VXLAN fabric—Based on EVPN VXLAN, which itself is based on BGP, making it highly scalable with no restrictions based on topologies. Since the fabric is standards-based, it can operate with third-party vendor devices seamlessly in many deployment scenarios, including both greenfield and brownfield deployments.
Integrated security available on all Versa SD-LAN switches.
The same headend controls LAN switches as well as SD-WAN devices and the SSE cloud fabric.
Versa Analytics can monitor all devices (SD-WAN, SD-LAN, and cloud devices).
Zero-trust network access on-premises (ZT-Prem)—Most other vendors offer zero-trust network access (ZTNA) primarily through the cloud. Versa Networks offers ZTNA on-premises and in the cloud, including switching.

Zero-Trust LAN

Versa zero-trust LAN (ZT-LAN) is security-focused and uses the same Versa Operating Software^TM (VOS^TM) software for all form factors. ZT-LAN is enabled in the switch and the access layer using two paths:

Switched path in the hardware NPU ASIC.
Secure path in software, with the same service chain available on SD-LAN switches that are available on SD-WAN devices.

Versa ZT-LAN fits into existing campus architectures as an overlay on the existing underlay. Most of the time, traffic flows through the switched path at line rate. If some device or user appears to be compromised, the the device/user is dynamically moved to the secure path and sent through the VOS service chain for inspection. Traffic can then be dropped if needed, or sent back through the switched path and forwarded. 802.1x authentication is used to authenticate intelligent devices and place them into the appropriate VLANs, while MAC bypass is used to authenticate headless devices and place them into the appropriate VLANs.

The following table compares the capabilities of Versa ZT-LAN with legacy campus switching.

Versa ZT-LAN	Legacy Campus
Security using Versa ZT-Prem and Versa's security complex within the switch provides Layer 2 to Layer 7 security.	Security using NAC (VLAN, ACL, 802.1x, port, IP Source Guard, Private VLANs etc.) results in decreased risk posture.
Single headend for all networking and security layers.	Multiple management consoles, with limited or no management integration between them, results in increased operating expenses (opex).
Single software-defined unified data plane for wired, wireless, and IoT devices. Consistent policy enforcement.	Multiple data planes, multiple places to manage policies, inconsistent policy enforcement, and decreased risk posture.
Adaptive microsegmentation based on continuous assessment of device posture, inline signatures, and device risk score (DRS).	Static segmentation based on VLANs and VRFs, leading to increased blast surface and decreased risk posture.
Layer 2 through Layer 7 advanced security enforced both for Layer 2 and Layer 3 traffic at the source to minimize the blast radius.	No built-in security for east-west traffic flows, leading to increased blast surface and decreased risk posture.
Distributed, standards-based EVPN VXLAN fungible fabric.	Complex, failure-prone virtual chassis and multichassis LAG (MC-LAG) solution.
Predictive AI/ML based Secure Campus, Branch, WAN Edge Networking Natural Language Processing (NLP) Engine Anomaly detection engine Prediction engine	Reactive Secure Networking Results in increased opex Poor user experience
Advanced visibility, User Entity Behavior Analytics (UEBA). Every VOS device receives information on every user and all endpoints.	Limited or no visibility results in increased opex and poor user experience.

For more information, see ZT-LAN Overview.

Versa ZT-Prem

Versa offers ZT-Prem using three modes:

802.1x network access control (NAC)
Device fingerprinting
User and group access control

When a device connects to the network, the RADIUS authentication server assigns a VLAN and an initial microsegment to the device. Then, if the device is a headless device, device fingerprinting identifies a microsegment that corresponds to the device's fingerprint and reassigns the device to that microsegment. If the device is an intelligent device, it is reassigned to a microsegment based on user and group policies, device posture, or device risk score.

Adaptive Microsegmentation for Intelligent Devices

Intelligent devices typically access the network using the Versa SASE client application. The VOS software also supports third-party device-management applications, such as Palo Alto Global Protect and Crowdstrike, as well as Microsoft Intune-managed devices.

The client application periodically collects hundreds of parameters about the end device and automatically sends this information to the nearest gateway. Note that in an SD-LAN network, the SD-LAN switch can act as the first-hop gateway.

Then, based on the device posture, the microsegmentation policy that is running on the device identifies the microsegment that corresponds to the device, and dynamically places the device in that microsegment. The information about the device is sent to the Versa Messaging Service (VM), which distributes the information to all the VOS devices in the network, even though the device is connected to only one switch. In Releases 22.1.4 and later, EVPN has been enhanced so that it can also distribute the device information to all VOS devices.

Adaptive Microsegmentation for IoT, Headless, and Agentless Devices

Every Versa SD-LAN switch can fingerprint devices, which allows the switch to identify a device based on the attributes present in the imported packets. Normally, all traffic is switched in hardware. However, all important traffic, such as DHCP, LLDP, and TCP syn/syn-ack packets, is sent to the CPU for device identification. Then, the microsegmentation control-plane policy is dynamically applied, and the device is assigned to the appropriate microsegment.

The attributes considered for device identification include:

Device MAC address
DHCP
DHCP vendor
DHCP hostname
DNS packets/ destination host
TCP syn packets
TCP syn-ack packets
SSL client, server hello packets (JA3 signatures)
HTTP headers (user-agent)
Multicast DNS (MDNS) packets
LLDP fingerprint

The device information returned by the fingerprinting analysis includes the following information:

Vendor—Device vendor name, for example, Apple
Model—Device model, for example, iPad
OS—Device operating system, for example, Microsoft Windows Kernel 6.0
Parent OS—Parent operating system, for example, Windows OS
Family—Device family, for example, computer
Subfamily—Device subcategory, for example, desktop
Prod—Productivity value of the device (low to high), for example: 5 (high productivity device)
Risk—Risk of the device (low to high), for example, 1 (low risk device)
Score—Response confidence score, for example, 60/100

Adaptive Microsegmentation Based on Risk Score and Device Posture

Continuous monitoring of devices enables dynamic computation of their risk scores and device postures. When devices are fully compliant and have high confidence scores, you can apply microsegmentation policies without restrictions. If a device is partially compliant, for example, if disk encryption is disabled, the device can be placed in a more restrictive microsegment. If a device is completely out of compliance, for example, if the anti-virus software is disabled, the device can be moved to a highly restrictive microsegment and is sent through a secure CPU path, where inline security services perform advanced scanning. The inline security services for LAN environments include deep packet inspection, antivirus scanning , file filtering, and URL filtering. If a device is suspicious due to its risk score and device posture, and the device tries to send traffic to any microsegment, the traffic can be dropped or undergo further analysis.

SGT ID Distribution for SD-LAN

Scalable group tags (SGTs) are labels used to classify network traffic and enforce access control policies, enabling microsegmentation and simplifying network management. SGTs are assigned to traffic sources and distributed throughout the network, so that all devices in the network can make access control decisions based on the tag.

An SGT is specified as a value between 0 and 4094. Note that an SGT with tag 0 will be reserved or used for "Unknown SGT" and not for any other purpose. When detected, Unknown SGTs can be sent through a secure CPU path for further analysis. For information about configuring SGTs, see Create an SGT Object.

In releases prior to Release 22.1.4, ingress policies are filtered based on the source SGT alone, and egress policies are filtered based on both source and destination SGTs. In Releases 22.1.4 and later, support has been added to export SGT to other remote nodes via Versa Messaging Service (VMS) and EVPN.

When a microsegmentation cache table is updated, the update is published to remote nodes through VMS, EVPN, or both, if they both exist. When remote nodes receive these entries, they create a software cache with a host-type of VMS or EVPN. To preserve hardware space, the clients in remote nodes do not download and install these cached entries to the hardware unless they receive actual packets. The only exception is with EVPN-MH, in which the entry is installed in hardware immediately without waiting for any real traffic to reach that client. These VMS and EVPN entries are called External cache entries.

If a packet is received having a source IP address of this External cache entry, then it is assumed that the client has moved to a new switch, in which case it is treated as a local device. The host type is converted to Client and this entry is published to other nodes through VMS and EVPN. If a packet is received with the destination IP address of this External cache entry, then the software entry is downloaded to the NPU and the host type is retained.

Similarly, if nodes receive the same locally-learned client through VMS or EVPN, then it is assumed that the local client has moved to some other switch, which triggered the publish operation. As a result, the cache entry is deleted and the External entry is created with type VMS or EVPN, as appropriate.

Among these two types, EVPN takes the higher priority. If a node receives a VMS entry for an existing EVPN entry, the SGT sent by VMS is ignored, but it is stored in the database.

These remotely-learned entries can only be published by the source node. The receiving node must not publish the entries.

At any given moment, a client could be either one of the following, but not both:

An External entry storing an SGT received through VMS or EVPN.
A local entry storing an SGT received through a MACSEC or a policy.

You can distribute SGT tags to all devices in a network in two ways, using VMS or using EVPN, as described in the following sections.

SGT Export Through VMS

VMS is a scalable, high-performance messaging service for streaming dynamically changing, high frequency, low latency data between Versa Networks products. For detailed information about installing and configuring VMS, see Install and Configure VMS.

Once VMS is installed and configured, you enable and configure VMS services by configuring a VMS server profile and enabling stream feeds for the microsegmentation VMS service, as follows:

In Appliance view, select the Configuration tab.
Select Others > Organization > Messaging Service > VMS Service in the left menu.
In the Microsegmentation section, click the Edit icon.
In the Edit Microsegmentation VMS Service screen, enter the required information. For detailed information, see Enable and Configure VMS Services.

Once you have enabled and configured VMS services, the VOS device sends cache updates for a particular service to the VMS server, which forwards the update to all switches that are subscribed to the microsegmentation service.

To export a VMS cache entry, you must configure the global VRF ID both for a virtual router and a virtual switch in all the participating switches. This global VRF ID is carried in the VMS messages. Based on this global VRF ID, the corresponding virtual router or virtual switch is derived in remote switches. For multiple switches to receive the VMS updates, they must all have the same global VRF ID.

Tp configure the global VRF ID:

In Appliance view, select Configuration in the top menu, then select Networking > Virtual Switches in the left menu.
Click an existing virtual switch or click the Add icon to add a virtual switch.
On the Virtual Switch Details tab, enter the Global VRF ID number.

For information about configuring virtual switches, see the Configure a Virtual Switch with Bridge Domains and Bridge Interfaces section in Configure Layer 2 Forwarding.

SGT Export Through EVPN

Releases 22.1.4 and later support the exporting of segment details to peers through BGP EVPN. Segment information is tagged in the Extended community of a BGP EVPN Type 2 route, as shown below.

The remote node processes this segment information. When the first packet is received for this particular client, NPU rules are created, which are similar to VMS processing. Since this is achieved through the Type-2 route, ARP suppression becomes mandatory for this BGP EVPN microsegmentation support. For information about configuring ARP suppression, see the Configure a Virtual Switch with Bridge Domains and Bridge Interfaces section in Configure Layer 2 Forwarding.

Ingress Kill

Ingress kill refers to an SD-LAN switch dropping packets at the ingress port based on a configured policy. In a standard VXLAN data path, when a packet ingresses the network, the source SGT ID is embedded in the VXLAN header of the packet. The SGT ID information is distributed to all devices in the LAN using VMS, EVPN, or both, so the SGT binding for both the source and the destination is available at the ingress port. Based on this information, the switch can enforce a policy that drops the packets at the ingress node rather than at the egress port. Ingress kill helps conserve resources by not sending the packets to the egress port and applying the policy there.

To configure ingress kill:

In Appliance view, select Configuration in the top menu.
Select Others > System > Configuration > Configuration in the left menu.
In the Parameters section, click the Edit icon. The Edit Parameters screen displays.
Select the Microsegmentation tab, then click the checkbox labeled Punt Unknown Dest Entries to CPU.
Click OK.

Multihoming Support for Microsegmentation

SGT ID distribution through EVPN enables support for microsegmentation in networks that are configured for multihoming. When traffic from a multihomed host arrives at the ingress port of the first SD-LAN switch, the VOS software computes the SGT ID information and sends it to EVPN or VMS, along with VLAN information, the Ethernet segment ID (ESID) and the IP address. EVPN or VMS then distributes the information to all other VOS devices in the multihomed network. Since all VOS devices have the same ESID as the first switch, the VOS software immediately programs the hardware without waiting for the first packet to arrive. Note that if EVPN is running in active-standby mode, the VOS software does not program the hardware with the entries that were learned through EVPN.

In this way, VOS applies microsegmentation policies without waiting for the software to download the information to the hardware.

Note: Multihoming support for microsegmentation is supported in active-standby mode only.

For further information, see Configure EVPN Multihoming for Hosts Using ZT-LAN.

ML/AI-Based Insights with Versa Analytics

The Versa Networks microsegmentation solution provides visibility and big-data, ML/AI-based analytics at the switching, SD-WAN, and SSE layers. Risk scores for users and devices are computed based on their behavior. The users and devices can then be moved to the appropriate microsegment based on the computed risk score.

Versa Analytics has been extended to include support for SD-LAN networks and devices. SD-LAN devices export interface statistics, virtual switch statistics, virtual router statistics, alarm, and events to Versa Analytics, so that you can see everything that is happening in the SD-LAN network from a single monitor screen.

The SD-LAN information exported to Versa Analytics includes:

Application and application performance traffic breakdown
Big-data ML/AI-based analytics
IPFix and Netflow-based traffic flow reporting
Near real-time traffic information
Traffic breakdown by user and by group
Reporting of SD-LAN topologies
Support for strong multitenancy and role-based access control (RBAC)

For debugging and troubleshooting, the tcpdump tool has been extended to include Enet interfaces to capture packets from the NPU and display them in the control plane. Previously, tcpdump was only available for VNI ports. For more information, see Use Network Monitoring Tools.

Supported Software Information

Releases 22.1.4 and later support all content described in this article.

Additional Information

Configure EIP-Based Microsegmentation for SD-LAN
Configure EVPN Multihoming for Hosts Using ZT-LAN
Configure IoT Security
Configure Layer 2 Forwarding
Configure Microsegmentation
Enable and Configure VMS Services
Install and Configure VMS
Use Network Monitoring Tools
ZT-LAN Features and Capabilities
ZT-LAN Overview