Major Features in Release 21.1.1
This document describes the major features introduced in Release 21.1.1 for Versa Analytics, Versa Director, and Versa Operating SystemTM (VOSTM) devices.
VOS Platform Features for Hardware
ADSL2+/VDSL2 NIC
You can use ADSL2+/VDSL2 NIC modules, also called xDSL NIC modules, in Versa CSG appliances. The CSG ADSL2+/VDSL2 NIC module supports a single WAN interface that allows you to connect to VDSL2 and ADSL2+ networks.
The CSG xDSL NIC provides a built-in secure and cost-effective connectivity solution directly from CSG platforms without the need to deploy a separate xDSL modem. This NIC provides high-speed digital data transmission between customer premises equipment (CPE) and the central-office DSL access multiplexer (DSLAM), located on the telco premises.
The native xDSL solution allows you to manage xDSL WAN connections from a single pane of glass, Versa Director and Versa Analytics. Native integration gives unparalleled WAN visibility and statistics on the WAN network, which allows Versa software to manage traffic dynamically for the best user and application experience.
You can now deploy a rich set of SD-WAN, Security, and Routing features directly on xDSL interfaces, driving business-class security; voice, video, data, and with differentiated classes of service (CoS); and market-leading application intelligence and network performance management features.
Versa provides a feature-rich implementation of xDSL NIC modules in hardware and in software. The hardware has built-in intelligence that autonegotiates for the best standard, encoding, and speed. In places where VDSL2/VDSL is available, xDSL NIC runs the interface in VDSL2/VDSL mode, using the best available frequency bands and encoding for maximum performance. In WAN networks where VDSL is not present, the WAN port automatically scales to ADSL2+ or its submodes, to establish connectivity and to run at the maximum possible speed.
In the Versa software, you can configure encapsulation options, DSL transport-level multiplexing details (that is, VPI.VCI values), and other features. The ADSL2+/VDSL2 NIC provides detailed statistics about line, conditions, signal qualities, xDSL profiles, and the frequency bands that are in use.
For more information, see the ADSL2/VDSL2 NIC datasheet.
CSG700 and CSG300 Management Port and vni-0/x Simultaneous Support
You can use interface 5 on CSG700, CSG355, and CSG365 models and interface 3 on CSG350 models in dual mode to serve as management Ethernet (that is, eth0) and vni-0/x (vni-0/5 and vni-0/3, respectively) interfaces simultaneously. In earlier releases, you could configure the interface in only one mode. Simultaneous support of both modes allows you to use all CSG interfaces for data path purposes while still maintaining the management Ethernet functionality of the eth0 interface.
DDM-Based SFP Monitoring and Management
The small form-factor pluggable (SFP) optical interface form factor is commonly used on networking devices. SFP interfaces were initially defined for 1-Gbps speeds, and the SFP+ standard extended the interfaces to were later extended to 10 Gbps. Versa CSG platforms, as well as certified whitebox units, support SFP and SFP+ interfaces.
SFP and SFP+ interfaces can carry optical transceivers from third-party vendors. For the current list of tested and validated optical transceivers, see the Versa Networks documentation.
SFP and SFP+ transceivers certified by Versa Networks have built-in digital diagnostics monitoring (DDM), which provides monitoring and management capabilities. (Note, however, that not all transceivers support this capability.) The DDM capabilities provide real-time information about the line, signal strength (optical input and output power levels), temperature, laser bias current, transceiver supply voltage, and other transceiver statistics, allowing you to operate your optical connections at optimum levels.
On a DDM interface, you can display diagnostics data and alarms for optical fiber transceivers, which you can use to diagnose why a transceiver optic is not working. DDM capabilities allow you to display vendor-defined thresholds that trigger high and low alarms, and high and low warnings.
T1/E1 NIC
CSG appliances support a T1/E1 NIC module. The T1/E1 NIC module supports four WAN ports, allowing you to connect to up to four T1 or E1 network connections. Each interface can configured to run PPP, HDLC, and Frame Relay encapsulations. Interfaces are software configurable to run in T1 or in E1 mode with a rich set of line and framing parameters to ensure compatibility with existing networks.
You can use the T1/E1 NIC module to connect to legacy WAN networks directly from CSG appliances without having to deploy a separate T1/E1 router. Native integration provides unparalleled WAN visibility, allowing you to manage traffic and gather statistics about the WAN network to manage traffic dynamically to provide the best user and application experience. This integrated solution allows you to manage natively terminated T1/E1 WAN connections from a single pane of glass, Versa Director and Versa Analytics.
You can deploy a rich set of SD-WAN, Security, and Routing features directly on T1 or E1 interfaces, to drive business-class security; voice, video, data, and differentiated classes of service (CoS); and market-leading application intelligence and network performance management.
The T1/E1 NIC is built on a highly capable, proven, industry-leading TDM chipset and is compatible with a wide variety of T1/E1 vendor solutions. The T1/E1 hardware and software provide a feature-rich implementation with a high degree of configurable features running at line rate.
You can configure the T1/E1 NIC module to operate in T1 networks (for North America) or E1 networks (the rest of the world). T1/E1 interfaces with built-in CSU/DSU provide sufficient power to drive signals over 200 feet, and up to 654 feet. T1/E1 interfaces support popular line coding and framing options with a very rich set of diagnostics options that are useful for testing and troubleshooting connectivity issues. You can configure PPP, Frame Relay, and HDLC encapsulations, and their associated parameters, on T1/E1 interfaces.
For more information, see the T1/E1 NIC datasheet.
VOS Platform Features for Software
CGNAT64 and DNS64
VOS devices support CGNAT64, as specified in RFC 6146, and DNS64, as specified in RFC 6147.
Stateful NAT64 provides a mechanism for IPv4-IPv6 transition and IPv4-IPv6 coexistence. IPv6 packets in the forward direction are translated to IPv4 packets, and vice versa. The IPv4 destination address in the forward direction is derived from the IPv4-embedded IPv6 address in the IPv6 destination address field. This IPv6 destination address is resolved by DNS64. The IPv6 source addresses of IPv6 hosts are translated to and from IPv4 addresses by installing mappings in the standard Network Address Port Translation (NAPT) source NAT pool. Source NAT configurations for NAPT pool are followed.
DNS64 allows an IPv6-only client to initiate communications by name to an IPv4-only server. DNS64 is a mechanism for synthesizing AAAA resource records (RRs) from Type A RRs. A synthetic AAAA RR created by DNS64 from an original A RR contains the same owner name as the original A RR, but it contains an IPv6 address instead of an IPv4 address. The IPv6 address is an IPv6 representation of the IPv4 address contained in the original A RR. The IPv6 representation of the IPv4 address is algorithmically generated from the IPv4 address returned in the A RR and from a set of parameters configured in DNS64.
You can configure basic services such as firewall, DoS, and rules using originating IPv6 addresses, zones, and other parameters. Translated IPv4 packets can be routed over SD-WAN, paired TVI, or tunnel interfaces.
Layer 2 Technology
Versa Networks introduces a carrier-class, feature-rich multitenant implementation for Layer 2 technologies. The Layer 2 bridging implementation is fully compliant with established standards and is designed to interoperate with existing Layer 2 networks. VOS devices can bridge Ethernet packets across LAN or WAN ports based on Ethernet fields.
The VOS software provides data plane–based learning and forwarding functions for bridging as well as control plane–based learning and forwarding using the Ethernet VPN (EVPN) protocol.
Virtual Switch
A Layer 2 virtual switch is a fully independent Layer 2 instance that isolates a Layer 2 instance, including its spanning-tree protocol, separate VLAN ID spaces, MAC addresses, filters, and name spaces.
Within a virtual switch instance, Layer 2 bridging is performed across member interfaces. Each virtual switch instance consists of a set of logical ports and one or more bridging domains that participate in Layer 2 learning and forwarding. A virtual switch represents a separate Layer 2 network.
Bridge Domain
A bridge domain is a Layer 2 bridging and forwarding domain that consists of a set of logical ports that share the same flooding or broadcast characteristics.
Similar to a virtual LAN (VLAN), a bridge domain spans one or more ports of multiple devices. However, unlike a VLAN, a bridge domain can serve one or multiple VLANs. In the case of multiple VLANs per bridge domain, the bridge domain normalizes the lookup based on the internal VLAN ID value of the bridge domain, while port-level VLAN IDs act simply as port significant VLAN ID tags.
Learning and forwarding decisions within a bridge domain can be summarized as follows:
- When an Ethernet frame is received on any of the ports of the bridge domain, it is processed by the Layer 2 lookup and learning and forwarding process, which examines the ingress interface, VLAN ID, and source and destination MAC address fields.
- If the MAC address is new, the source MAC address is placed into the Layer 2 table of the bridge domain with the appropriate VLAN ID and MAC address. The destination is determined based on the combination lookup of the destination MAC, VLAN ID, and bridge domain ID.
A single virtual switch instance can contain multiple bridge domains. However, a bridge domain can belong only to one virtual switch, and similarly, a logical interface can only be part of one bridge domain. While forwarding within a bridge domain happens based on Layer 2 bridging, forwarding across multiple bridge domains occurs across the IRB interface, using Layer 3 routing and forwarding. This separation allows each virtual switch to be in separate multibridge domains.
Support for the hierarchy of virtual switch → bridge domain → VLAN allows you to build Layer 2 networks that scale and perform with different degrees of separation, allows reuse of VLAN ID space, and eases the normalization of Layer 2 headers. This flexibility allows you to connect and manage Layer 2 networks across the LAN, WAN, or overlays of one or multiple organizations.
This level of implementation shows its power especially in carrier or large enterprise networks that may be serving multiple tenants who may have their own Layer 2 name spaces and who may be unwilling to change. The Versa implementation yields great results for such networks because it manages each tenant’s Layer 2 network separately by automatically learning and forwarding across different Layer 2 interfaces.
IRB
The structures described above provide the means for Layer 2 bridging. Layer 2 networks need an entry/exit point to Layer 3 for routing. Integrated routing and bridging (IRB) provides the entry/exit point for Layer 2 instances. In the Versa implementation, one IRB interface is allowed for each bridge domain instance. You use this IRB interface to route packets to another routed interface or to another bridge domain that has a Layer 3 protocol configured. The IRB interface for the bridge domain acts as the single Layer 3 routing point for all VLANs that are part of the bridge domain. The IRB interface is not tied to a particular physical interface; rather, it is tied to the specific bridge domain. For the IRB interface to come up, at least one of the member interfaces of the bridge domain must be up and operational.
If an IRB interface is configured in a bridge domain, traffic received from the member interfaces is processed by Layer 2 or Layer 3 lookups, or both. Depending on the destination MAC address in the Ethernet frame and the features configured on that interface, the lookup outcome can be one of the following:
- If the DMAC is the IRB MAC, the Ethernet frame is handed to Layer 3 for routing.
- If the DMAC is not the IRB MAC, the Ethernet frame is handed to Layer 2 for bridging.
- If the DMAC is a special (reserved) one or if it is multicast or broadcast, it can be concurrently bridged using Layer 2 functions and routed using Layer 3 functions.
The Versa Networks IRB implementation supports SD-WAN, unicast, and multicast features.
xSTP
The VOS Layer 2 implementation supports STP, RSTP, and MSTP as part of active loop detection and avoidance set of capabilities. The VOS implementation follows the IEEE 802.1w and IEEE 802.1d standards. STP, RSTP, and MSTP can be configured as part of the routing instance type layer2-control or virtual-switch. Because these protocols are configured within the routing instance, STP/RSTP/MSTP-determined protocol state is associated with all the bridge domain interfaces on this port across all the routing instances. When these protocols are configured as part of instance type virtual-switch, then all the bridge domain interfaces corresponding to that port should be present in the virtual switch only.
EVPN over SD-WAN
VOS devices provide Layer 2 connectivity across SD-WAN tunnels with an RFC standards-based Ethernet VPN (EVPN) implementation. EVPN-based Layer 2 connectivity allows use cases that involve Layer 2 connectivity over WANs when Layer 2 traffic is encapsulated within encrypted SD-WAN tunnels, including:
- Extension of the same subnet over a WAN to other sites
- Disaster recovery of data centers and data replication
- Data backup applications that use the same subnet across WANs
- Seamless Layer 2 connectivity from one branch to other branches, or to headquarters or data center sites
- Extension of an underlay-based Layer 2 network solution, such as MPLS Layer 2 VPN, to geographies using encrypted SD-WAN overlay tunnels
The VOS MP-BGP–based control plane has been extended with the address family L2VPN and subaddress family EVPN to exchange Layer 2 reachability information. In the data plane, the VOS software uses MPLS labels to encapsulate packets so as to segment Layer 2 traffic from Layer 3 and to address the traffic to specific destination branches, hubs, and datacenter sites. The standards-based EVPN implementation allows existing and prospective customers to build and operate Layer 2-over-SD-WAN solutions by leveraging your existing EVPN knowledge while allowing the technology to seamlessly operate within the SD-WAN environment.
The VOS implementation of EVPN over SD-WAN comes with various advantages of the VOS SD-WAN technology, including encrypted tunnels, diverse topology support, rapid tunnel convergence, and ZTP. These advantages are over and above the typical and more familiar MPLS PE-based EVPN implementations.
In the VOS EVPN-over-SD-WAN implementation, the same SD-WAN tunnels are shared with Layer 3 traffic, and each traffic flow is separated by MPLS label. This allows use of a consistent topology between Layer 2 and Layer 3 traffic flows, eliminating the possibility of asymmetric traffic patterns across the WAN.
The VOS selection of EVPN-based Layer 2 connectivity across WANs eliminates the need for data plane–based learning and forwarding, which creates the possibility of Layer 2 loops. The EVPN built-in control plane–based learning and information distribution eliminates Layer 2 loops over WANs, because information is exchanged proactively and because traffic forwarding across WANs is optimized with minimal to no flooding, which yields the optimum use of WAN network resources.
LLDP
The VOS software delivers a standards-based LLDP implementation on its LAN and WAN interfaces. The Link Layer Discovery Protocol (LLDP) is a vendor-neutral link layer protocol that network devices use to advertise their identity, capabilities, and neighbors on a LAN based on IEEE 802 technology, principally wired Ethernet. The VOS LLDP implementation is interoperable with other third-party LLDP implementations.
Miscellaneous
The VOS Layer 2 implementation supports access and trunk interfaces, native VLAN IDs, MAC limits, MAC move detection and loop avoidance, static MAC configuration, VLAN normalization and translation, and other features.
Tenant (Organization) Traffic Shapers
Per-tenant (per-organization) traffic shapers allow you to control the aggregate traffic of each tenant across its WAN interfaces. In multitenant deployments, you use per-tenant traffic shapers to control each tenant’s (WAN) traffic in order to prevent oversubscription of shared WAN resources of the common appliance. You define per-tenant level traffic shapers at the provider tenant level, and you apply them to each tenant. Each tenant administrator (or the common administrator) can then define and apply per-tenant QoS parameters on each WAN interface.
TPM 2.0
The VOS software TPM support is expanded to cover TPM 2.0 on Ubuntu 18.04 running on CSG and certified whitebox platforms. TPM 2.0 provides the same level of hardware-based sensitive data encryption and protection capabilities as units with TPM 1.2.
Releases prior to Release 21.1.1 and any releases based on Ubuntu 14.04, VOS devices supported TPM 1.2.
Ubuntu 18.04 (Bionic) Host OS
The VOS software is based on the Ubuntu OS, specifically Ubuntu 18.04 LTS, also called Bionic. (VOS Releases 21.1.0 and earlier are based on Ubuntu 14.04 LTS.)
With Release 21.1.1, you cannot upgrade from 14.04 LTS-based VOS software to 18.04 LTS-based VOS software. Versa Networks will provide upgrade capabilities in a future release.
SD-WAN Features
Log Export Functionality (LEF) Enhancement
You can reduce the number of firewall and SD-WAN statistics log records that CPE devices export, exporting logs only for the busiest sessions. Reducing the number of logs being exported can result in better performance.
New Probe Types for DIA and DCA (SaaS) Traffic Optimization
The VOS software provides various optimization capabilities for DIA and DCA (SaaS optimizations). In Release 20.1, the VOS software extended the capability to monitor the best paths towards cloud SaaS providers. This capability uses inline performance measurements on single-ended VOS deployments.
The VOS software estimates the performance towards an application in one of two ways:
- Passive monitoring—The VOS software monitors the TCP state to measure the RTT, Packet Loss rate, and Delay variation of the actual flow
- Active monitoring—The VOS software generates artificial probes to measure the reachability and performance of a path
In releases prior to Release 20.2.2, you could enable passive monitoring only for well-defined SaaS applications. In Releases 20.2.2 and later, you can enable passive-monitoring-based path selection for any predefined or user-defined application.
Release 20.2 SaaS optimization added support for:
- Monitoring of SaaS applications from branches and hubs
- Distribution of path performance metric between branches
- Use of ICMP-based probes to obtain response-time data from well-known cloud sites
Release 21.1 adds support for TCP and HTTP probes, to more accurately measure the response time for cloud SaaS FQDNs.
SD-WAN Circuit Tagging
You can tag WAN interfaces so that you can manage WAN-destined traffic for the best user and application experience. These custom WAN interface tags provide additional degrees of freedom and traffic management capabilities that you can use to prioritize and manage SD-WAN traffic. Examples of tag names might be Slow-Link, Link-with-Drops, and Fast-Link.
You can associate up to four circuit tags with a WAN interface. You refer to these circuit tags in the SD-WAN forwarding profile match conditions (both for local site and remote site) to steer traffic. You can configure circuit tags as a match condition option in an SD-WAN forwarding profiles.
TCP Optimization and TCP Proxy
You can enable TCP optimization for TCP flows. When you do so, the TCP connection is proxied by the VOS software. The VOS implementation of TCP proxy performs SD-WAN traffic optimization using newer TCP algorithms to make efficient use of the available bandwidth between the source and destination. The VOS TCP implementation strives to improve the goodput seen by the receiver regardless of the environmental conditions on the path between the server and client.
You can implement TCP optimization in one of the following ways:
- Peer discovery—In a topology where a VOS device is bookending the traffic, peer discovery allows the VOS instances closest to the source and destination to enable TCP proxy and start optimizing the traffic.
- Splicing—When the traffic is not bookended, yet you want to optimize only certain applications, TCP proxy is enabled upon application detection. This approach minimizes the amount of resources required for optimization. However, certain optimizations, such as TCP SACK and timestamping, cannot be enabled for these flows, because the original negotiation between server and client is not optimized.
- Default TCP proxy—Each TCP flow transiting the VOS device is proxied.
The VOS TCP proxy implementation includes the following improvements, which are described in the following sections:
- TCP SACK, window scaling, and timestamping
- TCP latency splitting
- Improved TCP loss recovery techniques
TCP SACK, Window Scaling, and Timestamping
The SACK option allows a TCP receiver to report to the sender which specific portions of the data stream are missing, thereby enabling faster loss recovery. If you disable the SACK, the entire window of data would have to be retransmitted. The timestamp option allows the round-trip time (RTT) to be better estimated.
The TCP SACK and timestamp options are negotiated during the initial three-way handshake. Because these options are relatively new, some hosts may not not implement these options or may disable them by default. With TCP optimization, SACK and timestamping are implemented by the TCP proxy, and they are enabled for all flows for which TCP optimization is enabled regardless of the capability of the end hosts.
On high bandwidth-delay product (BDP) paths, the throughput may be limited by the end hosts instead of by the network if the maximum socket buffer sizes are not large enough to accommodate the BDP. The TCP proxy can enable the window scaling option, and it can allow large buffers on the WAN side of the TCP connection
TCP Latency Splitting
The TCP congestion control algorithm allows the host to transmit data equal to the size of the congestion window for each RTT duration. For flows that traverse a path with a long RTT, the ability to scale a single flow is limited. The VOS software can achieve higher bandwidth for the same path by performing latency splitting, a method in which the end-to-end latency between the end hosts is split into one or more segments. Essentially, the flow is split into two independent legs and each leg has a smaller RTT. Because each TCP proxy segment performs loss recovery independently, the end-to-end throughput can be much better than if the latency were not split.
Improved TCP Loss Recovery Techniques
The goodput, which is the unique data packets carried between the server and the client, depends on many factors including the ability to estimate the RTT accurately and the ability to estimate whether losses are caused by congestion in the network or are just random losses. Recent research by universities and private companies has produced many advanced algorithms that perform better in the field than traditional TCP algorithms.
The VOS TCP proxy implements the following loss recovery techniques:
- BBR congestion control algorithm, which is based on a published IETF draft. BBR works in a variety of challenging network environments to provide higher throughput and reduced latency, and works better than state-of-the-art algorithms such as cubic. Specifically, BBR works well in the following environments:
- High throughput in random loss environments such as LTE network and shallow buffer environments (environments where very small shaping buffers and burst sizes make loss appear random). For example, in internal testing, on a 100-mbit, 80-ms WAN with 1% packet loss, the cubic algorithm can achieve around a 2-Mbps goodput, whereas BBR can achieve a throughput of around 60 Mbps.
- High throughput in policed environments. BBR explicitly models traffic policers and can drive the network close to the policed rate.
- Low latency in deep buffer environments. For example, if a last-mile shaper has a 1-M buffer in a 10-mbit, 40-ms WAN, the end-to-end latency with the cubic algorithm can be as high as 800-1000 ms, whereas with BBR it remains close to 40 ms.
- RACK loss detection, as published by the IETF. RACK loss detection provides better loss in the following conditions:
- Lost retransmits—Traffic policers and burst losses
- Tail losses—Losses at the end of a transmission burst
- Losses when packets are reordered
- Tail-loss probing (TLP) algorithm helps with faster recovery of tail losses.
Traffic Identification and Traffic Management Based on the First Packet
Today, a large percentage of business applications used by the enterprises are offered as a service. In this software as a service (SaaS) model, the applications are hosted in a public cloud, which results in business-critical traffic exiting to the internet.
Customers expect that configured policies, such as QoS, path selection, and forwarding policy, are applied for a flow as soon as possible, preferably on the first packet. Traditionally, application detection requires visibility into the first few packet exchanges in order to identify the application. After the application is identified, an IP address-to-application mapping is cached to ensure that application-specific policies are applied for most flows starting with the first packet. This method works well for hosted applications, because the number of IP addresses from which the application is served are limited. However, in a SaaS-delivered model, the application delivery is dynamic and can span across tens if not hundreds of IP addresses. Thus, convergence of the IP address-to-application-ID mapping may take a long time, which can result in default policies being applied to many applications until the application is being detected.
The VOS software can detect and identify the SaaS application starting with the first packet in the flow, thus ensuring that all flows are associated with the proper policies.
Many cloud SaaS providers advertise the IP address range and FQDNs that they use to serve the application. These lists are made available to VOS devices so that applications can be identified starting with the first packet. The applications that are identified are the same predefined applications that you have been using when configuring policies (for example, Office365 and Zoom), so you do not need to change your policy configuration.
The first-packet identification feature is also used to identify the applications for DNS requests. Doing this allows DNS requests to be subject to the same WAN path selection as for the data sessions.
The first-packet identification feature is used to reliably and consistently to perform WAN path selection for the given application, including DNS sessions, and to allow users to configure firewall rules to create allow lists for the SaaS applications using the published IP prefixes and domain names
The VOS software can dynamically query and download the FQDNs and IP addresses advertised by SaaS providers. These FQDNs and IP addresses are installed as part of security packages (SPacks), and they are updated dynamically.
In Release 21.1.1, the VOS software supports first-packet-based detection for Microsoft Office365 and Zoom.
Security Features
NAC with Certificate Issued by Microsoft NDES SCEP
NAC is key to authenticating and authorizing a device’s access to an environment with the right set of privileges and access control. The VOS software network access control (NAC) portfolio now allows you to use certificate-based (network) device authentication and certificate management using Microsoft Network Device Enrollment Service (NDES) and Simple Certificate Enrollment Protocol (SCEP), which are mechanisms for issuing and managing certificates. The VOS software supports the SCEP protocol, which interoperates with the Microsoft infrastructure to obtain and manage certificates to control network access in environments where Microsoft systems are used for certificate-based authentication.
NDES allows software on routers and other network devices running without domain credentials to obtain certificates based on SCEP. NDES performs the following functions:
- Generates and provides one-time enrollment passwords to administrators
- Submits enrollment requests to the certificate authority (CA)
- Retrieves enrolled certificates from the CA and forwards them to the network device
SCEP, which is a protocol defined by the IETF, is used by network equipment vendors to provide certificates to everyday users in large-scale implementations. SCEP is designed for large-scale deployments with standard knowledge requirements from the network administrator. Microsoft environments Intune to support the SCEP protocol.
In the Microsoft implementation, Intune supports uses SCEP to authenticate connections to applications and corporate resources. SCEP uses the CA certificate to secure the message exchange for the certificate signing request (CSR). Intune SCEP certificate profiles, which are a type of Intune device profile, are used to deploy the certificates on netowkr devices. When you are using an Active Directory Certificate Services Certification Authority, you must have a Microsoft Intune Certificate Connector to use SCEP certificate profiles with Intune. The connector is not required when you use third-party CAs.
When you configure SCEP on VOS devices, the VOS devices can enroll to the NDES service, which is typically running on the Domain Controller that runs Active Directory Services. Using Microsoft NDES-managed certificates obtained by SCEP, VOS devices can then manage network access for devices that may be issued by a corporation or that may be owned by individuals, such as BYOD.
Earlier VOS software releases introduced features to support network access control (NAC). Release 20.2 introduced 802.1X support, which also uses certificate-based authentication, while the backend of 802.1X deployments are typically RADIUS servers. Release 16.1R2 introduced support for Enterprise Java Beans Certificate Authority (EJBCA), which is a free and commonly used software public key infrastructure (PKI) certificate authority software package. The VOS software has been tested with EJBCA (https://www.ejbca.org/). Both the staging Controller and branch device must fetch certificates from the CA, and certificates are used to authenticate the branch device.The addition of SCEP continues the Versa Networks expansion of the VOS NAC portfolio capabilities.
NAC Passive Authentication and Versa Intelligent Message Bus
The VOS software can learn the IP address-to-user ID and IP address-to-group ID bindings from Active Directory servers to skip Active directory-backed, captive portal-based authentication that would be required if a user is moving within the network.
Regardless of who authenticates an end-user client (whether a Versa element or not), VOS nodes distributed across the network can apply the appropriate inline user-level and group-level SD-WAN and security policies to traffic originating from or destined to these IP addresses without asking for authentication via captive portal or other means.
This shared information-based access control and authentication technique is called passive authentication. Passive authentication allows users to be authenticated only once. This method avoids subsequent authenications as the user changes their location on the network when they move to a different part of the network served by another device, and it allows the user to carry their connectivity profile and security profile as they move around.
Passive authentication uses the Versa Intelligent Message Bus (VMS). VMS is Docker container-based (new) software that runs on the head-end together with Versa Director, Versa Controller, and Versa Analytics. Because it is based on a container form from the start, VMS can be deployed rapidly and easily, scales in and out easily, and can be monitored by popular container infrastructure and management tools. VMS is a control plane-based mechanism that is designed to scale to a very large number of users and VOS nodes to satisfy the requirements of the largest enterprise and service provider networks. With VMS, VOS devices can provide cutting-edge, seamless authentication and network traffic control capabilities.
VMS subscribes to the enterprise’s Microsoft Active Directory servers using a WMI plug-in. The WMI plug-in listens to user ID-to-IP address bindings while filtering out other irrelevant messages. As new user ID-to-IP address mappings are learned, this information is shared with VOS instances using the Google ProtoBuf mechanism, which is suitable for rapid streaming of high-volume data to many destinations. VOS instances deployed across the network learn the user-IP bindings and use this information, along with the user-level and group-level information learned via the VOS attachment to the customer’s Active Directory servers, to apply the correct user-level and group-level access control, security, and SD-WAN policies on the newly learned IP addresses.
Security Profile Groups
You can group individual security profiles into a security profile group and then apply the profiles to policies. Security profile groups provide the flexibility to configure the group name as a reference across multiple access policy rules rather than specifying the profiles individually.
Versa Secure Access (Formerly Remote Access VPN Concentrator)
Work from Anywhere is the new normal. Enterprises need a remote connectivity solution that allows employees to securely connect to enterprise resources from anywhere. The enterprise applications can be hosted in an enterprise data center or in public cloud environments. The remote connectivity solution should provide
- Assured application experience for remote users
- Integrated security and application access policy for users connecting to an enterprise network both internally and externally
- Secure all internet-bound application traffic for remote users
In Release 20.2.2 and Release 21.1.1, Versa Networks introduces the Versa Secure Access (VSA) solution, which consists of:
- Versa Secure Access client for Windows 10 and MacOS, which is installed on employee end devices
- Versa Secure Access server functionality on VOS devices
You can enable the VSA solution on existing Secure SD-WAN deployments. When deployed, existing hubs and branches running VOS software are converted to secure access gateways. The VSA solution minimizes the amount of additional hardware that you need to deploy, thus reducing hardware sprawl.
Because you can convert any or all existing hubs or branches to gateways, the solution is highly distributed and scalable. Users always connect to the nearest gateway, reducing the hairpinning of traffic.
VSA integrates with enterprise authentication servers. In Release 21.1.1, VSA can authenticate users using LDAP/Active Directory. VSA also supports multifactor authentication (MFA) using SMS-based authentication codes.
The VSA solution is based on portal and gateways. The portal is single point for registering the client and for downloading the client configuration. After the user authenticates with the portal, the client and its configuration, including the list of gateways, certificates, and profiles, are downloaded. The client can then connect to gateways as authorized by the administrator.
The VSA client supports IKEv2/IPsec-based private connectivity to the gateway, using industry-standard encryption algorithms for protecting traffic. When traffic arrives at the VOS VSA server, user and application-based SD-WAN and security policies are applied.
The VSA solution is managed by Versa Director and Analytics.
Versa Director Features
Active Directory and LDAP Support
Versa Director Active Directory Authentication Connectors now support secure LDAP.
Versa Director uses CA certificates to connect to Active Directory over a secure channel. For this to work, you must import into Versa Director the CA-issued certificates used by the Active Directory Domain Service.
Versa Director uses the Global Catalog (GC) server to query information about users present in other domains. Versa Director implements a secure communication channel with the Global Catalog server.
AWS Transit Gateway Network Manager Integration
AWS Transit Gateway Network Manager is a portal that provides global visibility of a private network. AWS Transit Gateway connects a VPC to on-premises routers.
In earlier releases, the VOS software created site-to-site IPsec connections to the AWS Transit Gateway. The configuration was done on the AWS portal (for the Transit Gateway) and on the Versa Director (for on-premises branches).
In Release 21.1.1, Versa Director automates the process of configuring Transit Gateway tunnels with the on-premise branches. You can configure both the Transit Gateway and the VOS branches from Versa Director. To configure the Transit Gateways, Versa Director calls the appropriate AWS portal APIs.
The VOS software now integrates with Transit Gateway Network Manager. The endpoints (branches), as well as the rest of the private network, are visible in the Network Manager portal.
Device-Level Service Templates
In earlier releases, the VOS software supported device group service templates. In Release 21.1.1, the VOS software adds support for device-specific service templates. You can add device-specific service templates to device group service templates. This feature allow you to apply a group-wide service template and then customize the configuration for individual devices.
Director Infrastructure Scaling Improvements
Versa Director has been enhanced to provide higher scaling and performance characteristics as folows:
- As part of the migration from CDB to SQL, other functions that leverage CDB had been migrated to SQL database. With Release 21.1, Workflows, organizations, and Controllers have been migrated to PSQL.
- NSO commit queues now provide multiple simultaneous configuration commit capabilities, to increase the efficiency of parallel commits to branches.
Kafka Client
Versa Director supports the Kafka client. Kafka is a TCP-based streaming protocol and API implementation. The protocol defines all APIs as request-response message pairs. The Kafka streaming protocol and API allow Versa Director to stream high volumes of data to Kafka servers.
The Versa Director Kafka implementation allows publishing and subscribing for a number of topics, such as branch reachability messages, and appliance configuration out-of-sync messages. Third-party applications can subscribe to any or all of these topics.
The Versa Director Kafka client provides real-time streaming data pipelines that reliably transfer data between systems or applications. The Kafka client supports multiple Kafka servers for both redundancy and information distribution.
Redundant Authenticator Connector Support
Versa Director support redundant connectors for authentication purposes. Redundant authentication connectors are supported for Active Directory, LDAP, RADIUS, and TACACS+.
Scheduled VOS Upgrades and Template Commits
You can schedule template commits and software upload and upgrade tasks for a future time. If a device is unreachable at the schedule time, you can configure the pending operation to be retried when the device is again reachable.
You can schedule the following tasks:
- Commit templates to one or more VOS devices at the same time.
- Download software to one or more VOS devices at the same time.
- Download and upgrade software to one or more VOS devices at the same time.
Ubuntu 18.04 Host OS
New installations of Versa Director and Versa Analytics run on the Ubuntu 18.04 LTS host operating system. Fresh installations of Versa Analytics and Versa Director can be deployed using 18.04 installations. Upgrades from older versions continue to use the Ubuntu 14.04 package.
Earlier versions of Versa Director and Versa Analytics run on Ubuntu 14.04 LTS.
Versa Analytics Features
Analytics Fusion Support with Older Versions of Versa Director and VOS Software
Prior to Release 21.1.1, Versa Analytics and Versa Analytics Fusion required that Versa Director and VOS devices run the same software release as Versa Analytics. In Release 21.1.1, Versa Analytics Fusion can run a newer release while Versa Director and VOS devices run older releases, such Release 16.1R2. This means that you can leverage latest Versa Analytics Fusion capabilities without upgrading the rest of the headend systems.
Appliance Log Activity Reporting
You can create reports for appliance activity logs. Versa Analytics keeps per-device activity logs, and you can access them from the Versa Analytics device. This allows you to drill down to device logs without leaving the Versa Analytics windows.
Versa Analytics also provides metrics and reporting for network administrators. These metrics include log counts and time distribution.
Health Check Monitor
Versa Analytics monitors the health of Analytics nodes (including disk, memory, and CPU) and reports the health in the Administrative Dashboard. In Release 21.1.1, you can query Versa Analytics for health data using REST APIs, and the API response can be processed by external tools.
Kafka Bus-Based Streaming to Third-Party Collectors
Kafka is stream-processing platform suitable for highly scalable applications. Kafka is a Sub-Pub–based protocol that is ideal for distributing data from multiple receivers to multiple listeners. Kafka has a robust queuing mechanism to distribute messages reliably. In the context of Versa Analytics, many customers host Kafka clusters to receive and process the logs for multiple services across the organization. When configuring log collector exporters, you configure Kafka Brokers as log collectors. The log collectors stream the logs in syslog format over TCP or UDP.
The log collectors support both TLS and SSL authentication, and you can configure TLS/SSL to encrypt the logs.
Licensing and License Reporting Enhancements
A number of changes have been made to licensing and license reporting:
- 3-year and 5-year licenses—You can configure the license period (1, 3, or 5 years) and the solution and bandwidth tiers in the Workflow template. The license period is reported in the entitlement reports. Prior to Release 21.1.1, the default license period was 1 year.
- License usage view—A Versa Director Administrator can view the devices that are using licenses. The screen provides a detailed view of the licenses being used, the device name, and the tenant.
- Deprecate per-tenant license in a CPE—For a multitenant CPE device, Versa Director reports the license for the appliance-owner organization only. Previously, Versa Director would report the usage and license for every tenant, a licensing mechanism that has been deprecated since 2018.
- Deprecate trial period after ZTP—The license period starts when ZTP is successful. Prior to Release 21.1.1, after the CPE device performed ZTP, it entered the Created state, which was a trial state that would last 30 days and would allow you to perform acceptance testing.
- Deprecate Suspend and Reactivate states—Versa Director no longer allows customers to suspend and reactivate a device subscription.
Log Retention Policy Enhancements
Versa Analytics receives data from branch locations, stores it, and processes it to deliver reports to the end customer. While the data received from the branches is important, customers are expected to maintain the data for limited time only, in order to improve the scalability and performance.
In earlier releases, you configured a Versa Analytics global data retention policy for different types of data, specifying how long to retain the data. This meant that in a multitenant system, every tenant had the same retention policy. However, different tenants require a longer retention time, because of regulations and the criticality of their operations, and different Analytics reports may have different retention requirements.
In Release 21.1, you can define the retention policy on a per-tenant basis. In a policy, you can define how long to retain the data for each Analytics report.
LTE Reporting Enhancements
Versa Analytics and Versa Director monitor screens now display the color codes for radio parameters along with the actual values. The color coding provides a visual cue for network administrators to understand the current state of the the LTE connection.
Multiple Collectors
You can configure primary and backup Versa Analytics collectors.
Network Prefix in SD-WAN Application Subscriber Report
An SD-WAN application subscriber report provides information about applications and their users. A username can be derived using IP address-to-user mapping schemes. If such schemes are not configured, the source IP address of the traffic flow is used as the username. In Release 21.1.1, in addition to applications and usernames, this report displays the network prefix, which is the destination address prefix of the traffic flow, if the prefix is received in the logs from the VOS devices. By default, VOS devices do not send the network prefix information.
SSL Support for Remote Collectors (TLS Support for Syslog)
Versa Analytics can export the logs it receives external servers, using TCP or UDP as the transport mechanism. In Release 21.1.1, Versa Analytics can use TLS between the log collector and remote server for exporting syslog messages in a secure tunnel.
TACACS+ Support for Authentication, Authorization, and Accounting
TACACS+-based authentication, authorization, and accounting (AAA) has been added for Versa Analytics. Versa Analytics supports the following standard AAA features, which provide detailed control and visibility into how Versa Analytics is used:
- Authentication identifies a user before they are allowed to access the network and use network services.
- After a user is authenticated, every user action must be authorized. Authorization determines what a user can or cannot do. Versa Analytics supports admin and operator roles.
- Accounting collects and sends security server information that can be used for auditing and reporting, such as user identities, start and stop times, and commands executed. Accounting allows you to track the services that users access.
Ubuntu 18.04 Host OS
New installations of Versa Director and Versa Analytics run on the Ubuntu 18.04 LTS host operating system. Fresh installations of Versa Analytics and Versa Director can be deployed using 18.04 installations. Upgrades from older versions continue to use the Ubuntu 14.04 package.
Earlier versions of Versa Director and Versa Analytics run on Ubuntu 14.04 LTS.