Skip to main content
Versa Networks

Major Features in Release 20.2.0

FlexVNF Infrastructure Changes

Host OS Upgrade to Ubuntu 14.04.5

With Release 20.2, Versa FlexVNF runs on the Ubuntu 14.04.5 LTS host OS. (Earlier versions run on Ubuntu 14.04.2 LTS.) The host OS update delivers OS fixes, driver updates, and security vulnerability patches to Ubuntu OS since 14.04.2 LTS. The Ubuntu 14.04.5 EOL date is April 2022.

DPDK Upgrade

The Intel DPDK code library has been upgraded from version 16.04 to version 17.11 LTS. The DPDK update allows FlexVNF to recognize newer Ethernet controllers. The updated DPDK is fully backwards-compatible.

DPI Engine Upgrade

The FlexVNF DPI engine has been upgraded to improve how it recognizes applications. The DPI engine use more elaborate techniques to recognize more sophisticated applications and also recognizes existing applications more efficiently.

QinQ Support

Versa adds support for dual VLAN tags, also known as QinQ. QinQ is specified by IEEE 802.1ad, which defines QinQ as a service that provides bridging technology in which  the service provider uses the outer VLAN tag (S-VLAN tag) to identify the tenant across the Layer 2 network (instance), and the enterprise uses the inner VLAN tag (C-VLAN-tag) to connect geographically dispersed VLANs.

While this QinQ service provided a useful multitenant Layer 2 VPN connectivity solution across the service provider’s shared Layer 2 transport, it failed to scale to the actual needs of many large service providers and enterprises, because each one could only use 4K of space. This solution also constrained many of the routing and forwarding decisions to one label type, for example, with the service provider outer labels.

The Versa implementation of QinQ addresses the issues with the version defined in IEEE 802.1ad, providing full flexibility with none of the restrictions. In the Versa QinQ implementation, you define inner and outer VLAN tags without having to reference service provider or enterprise tags, such as S-VLAN and C-VLAN. Instead, Versa uses these dual tags as a means to identify a logical interface, in a way that is not much different than other tagged interfaces, such as MPLS.  This design allows Versa to use the full VLAN space (4096 x 4096) as a single addressing and segmentation space, and it also allows Versa to classify and forward packets using any QinQ VLAN values.

In Release 20.2, Versa supports only Layer 3 (IPv4 and IPv6) on QinQ interfaces.

uCPE Performance Enhancements

vHost User Space and Virtio Interface Support

In releases prior to Release 20.2, Versa uCPE used kernel-based OVS to steer traffic into and out of guest VMs over any customer-configured service chain topology. However, because the virtualized interface is an OVS bridge interface, the packet path from FlexVNF to the VM required copying the packet multiple times, from the FlexVNF to kernel space and then from kernel space to the QEMU address space. In the reverse direction, the packet would originate in the VM, be copied to the kernel OVS, and then be copied again to the FlexVNF. Each packet copy required multiple context switching across the FlexVNF, kernel OVS, and QEMU processes, and the copying and context switching affected uCPE performance.

In addition, the Unix kernel is not optimized for high-performance packet processing, so DPDK and the Versa data path implementation run in user space.

To maximize the performance of uCPE service chaining and to further optimize the data path, Versa has moved all uCPE service-chaining data path functions to user space and has eliminated any intermediaries in the process.

In Release 20.2, Versa introduces the following changes to maximize uCPE performance:

  • Move the vhost-net interface implementation from the kernel to a user space FlexVNF process, thereby eliminating the kernel’s involvement in the packet path and service chaining.
  • Through the process, make OVS optional, to support VMs that may not support virtio interfaces.
  • Allow the FlexVNF vhost-user interface to be multiqueued and do flow-based load balancing on the receive side of the guest VM so that all data path cores in the Flex VNF are used effectively.

Let’s explain these changes bit more.

In Release 20.2, Versa chose to leverage virtio interfaces that reside in user space. The virtio network driver shares a number of virtual queues with the QEMU process that hosts the guest VM. Using the virtio interfaces that are in user space allows QEMU process to receive network traffic from the guest and forward it to the host network. However, this design implies that all guest traffic must be handled by the QEMU process before it can be processed further by the host's network stack, which could create another bottleneck.

A solution to this problem is vhost, which allows a user space process to share a number of virtual queues directly with a kernel driver. The transport mechanism in this case is the ability of the kernel to access user space application memory. In this model, a vhost-net driver passes guest network traffic to the network device directly from the kernel side. However, serving packets via the kernel is not a high-performance solution.

The Unix domain socket-based mechanism allows shared virtual rings between two user space processes via shared memory. This mechanism allows the setting up of resources used by a number of virtual rings that are shared between two user space processes, which are placed in shared memory.

To leverage this capability, Versa moved vhost-user into its user space process so that it could  pass packets directly to another user space process (in this case, to a VM) by implementing a virtio backend outside QEMU. This design allows direct communication between the FlexVNF and a QEMU guest VM. The result is that the Versa uCPE can deliver very high performance and low-latency service-chaining capabilities.

While Release 20.2 offers vhost-user net- and virtio-based service chaining, OVS-based service chaining is still available as an option for cases where guest VMs do not support virtio interfaces. During the uCPE configuration process, the network administrator can choose the desired service-chaining method and FlexVNF builds the service chain accordingly.

Multiqueue (MQ) Support

To increase the performance of guest VMs, it may be necessary to assign multiple CPU cores to each guest VM. While assigning additional cores leverages more of the compute and processing power, bottlenecks can still happen at the host OS (that is, FlexVNF) network queues that serve packets to the guest VM. In other words, network performance may not scale as the number of vCPUs increases, because the virtio-net has only one transmit and receive queue, and so the guest VM cannot receive packets in parallel.

To address this bottleneck, Release 20.2 introduces support for multiple queues within FlexVNF to serve each vCPU core of the guest VM separately. In addition, Versa introduces built-in flow-based load-balancing capabilities across separate queues to maximize use of the multiqueue-based architecture.

In Release 20.2, the FlexVNF has built-in intelligence to dynamically identify the VNF’s active receive and transmit virtio queues, to perform effective flow-based load balancing on the receive side (from the FlexVNF to the VM) across vhost-user transmit queues, and to receive packets only from the active vhost-user receive queues on the transmit side (VM to FlexVNF). FlexVNF allows the VNF to dynamically change the receive and transmit queue configuration, for example, to dynamically identify and rebuild its active vhost-user receive and transmit queue lists, and to do flow-based load balancing based on the new queue list.

Multiqueue capabilities combined with load balancing allows the entire stack of guest VMs to work in parallel across vCPU instances to process packets at maximum performance.

The Versa implementation uses multiple threaded vhosts to serve as the backend of a multiple queue-capable virtio-net adapter, and it uses multiple queue-aware virtio interface drivers to send and receive packets to and from each queue.

CPU Pinning

Release 20.2 introduces CPU pinning intelligence for guest VMs and for FlexVNF. CPU pinning means that a VM or FlexVNF get a CPU time only from a specific CPU or a set of CPUs. Pinning is performed between each of the guest VM’s logical CPUs and each core ID in the host system.

Versa uCPE allows the user to configure the following host CPU pool types, providing the flexibility to bind and unbind a VNF’s logical cores to and from these physical cores:

  • Exclusive---A VNF that requires dedicated CPU resources has a 1:1 binding with the host physical cores.
  • Shared---Physical cores that are shared across multiple VNFs.
  • Manual---VNF logical cores (either exclusive or shared) can manually bind to these physical cores.

CPU pinning makes the performance predictable, eliminates jitter, and increases the quality of service from the guest VM.

Intel QAT Support for Skylake-D Processors

Starting in FlexVNF Release 20.1, Versa supports Intel QAT on Rangeley, Denverton embedded QAT blocks, and Coleto Creek cards that have dedicated QAT processors. Release 20.2 extends support to include built-in QAT functions of the select Skylake-D processors. In both Release 20.1 and Release 20.2, if FlexVNF finds a QAT block, it leverages it automatically. This seamless implementation means that you can upgrade to Release 20.2 or downgrade from Release 20.2 without having to make configuration changes .

As  with Release 20.1, Versa FlexVNF in Release 20.2 offloads IPsec encryption and decryption to QAT. Release 20.2 does not support offloading of SSL to QAT.

Multicast Enhancements

Multicast is typically used by online streaming video and gaming, financial, and broadcasting applications that distribute information from one to many or from many to many. Different multicast networking protocols have been developed to allow more efficient use of network resources for these types of applications.

Before Release 20.2, Versa supported the following multicast protocols:

  • IGMP, Versions 1, 2, and 3
  • PIM SM, including supports for neighbors on LAN, WAN and SD-WAN overlay; rendezvous point, bootstrap RP, and static RP
  • PIM SSM

Releases 20.2 adds the following features and capabilities for multicast traffic:

  • PIM Anycast RP, as specified in RFC 4610
  • Multicast RIB
  • Cluster list

Anycast RP is used for geographically dispersed deployments, in which a geographical area can have one or more RPs, and to provide fast convergence of the RPs when a  router fails. Versa FlexVNF can be configured as a RP, and a set of routers can be statically configured as RP routers. The RP in a set that receives the PIM Register message from a source forwards the message to the other RPs in the set, thus forming a multicast tree with multiple RPs. If one of RP nodes fails, the other RPs in the set take over the RP role seamlessly. 

Before Release 20.2, unicast and multicast traffic shared a common RIB and hence  a common topology. However, unicast and multicast traffic have different requirements and constraints. For example, for multicast traffic, hubs can be designated routers, which utilize higher performance CPUs for packet replication.

Release 20.2 supports an independent RIB for multicast, allowing you to define a multicast topology that is independent of the unicast topology. For example, when the unicast topology is a full-mesh topology, you can define the multicast topology as multiple groups of hub-and-spoke nodes to reduce number of replications at any given site. In such scenario, a cluster list helps to restrict PIM neighborship within a group of hub-and-spoke nodes on overlay tunnels.

The Versa Multicast implementation performs software-based packet replication. This architecture provides flexibility for deploying multicast networks over COTS hardware, because no special hardware capabilities are required. However, software-based replication is limited by the packet copies in memory. To overcome this limitation, Versa Director has defined the concept of a cluster. Each branch CPE is associated with a cluster, and PIM neighborship is limited to only the members of a cluster. A node can be part of more than one cluster. This mechanism allows an administrator to define the PIM tree and how packet replication is performed.

Data-Driven SLA Management

Versa supports a variety of topologies, including hub and spoke, full mesh, partial mesh, and spoke-hub-hub-spoke (SHHS). SLA management allows a Versa FlexVNF to monitor the performance of the path between pair of branches. The SLA management protocol is proprietary protocol that optimizes the overhead between the pair of branches by using a combination of artificial probes and data packets. Before Release 20.2, the SLA path was monitored on every path between a pair of branches that are configured to communicate directly with each other. The SLA management overhead thus increases when a large number of branches forms a mesh, even when direct communication between the branches is infrequent. This limits the number of branches that can be connected in a full-mesh topology.

With Release 20.2, customers can define data-driven SLA management between the branches. Data-driven SLA management is enabled dynamically only if traffic is actively being exchanged between the two CPEs. Data-driven SLA measurement applies to full-mesh and partial-mesh (spoke-to-spoke direct) topologies.

When you use data-driven SLA management in a full-mesh topology, a few high-performance nodes are selected as hubs. This ensures reachability between the two CPEs. When a device on the branch LAN segment starts communicating with a device on the LAN segment of another branch, the first few packets of the flow are routed over the hub node. The direct path between the two branches is established along with SLA management. After ensuring reachability over the direct path, the data then takes the direct path between the branch.

With data-driven SLA management, there is no limit to number of devices added to a full-mesh topology.

DIA and DCA (SaaS) Traffic Optimization Enhancements

Versa offers various optimization capabilities for DIA and DCA (SaaS optimizations). In Release 20.1, Versa extended the capability to monitor best paths towards loud SaaS providers. This capability uses inline performance measurements on single-ended FlexVNF deployments.

In SD-WAN deployments, there can be multiple paths to reach SaaS providers. Some of the paths may involve breaking out to the internet locally at the branch where traffic originates, while other paths may be through the hub site using the SD-WAN overlay.

Advanced enterprise architecture can deploy hubs in collocated data centers with high-performance connections to certain SaaS applications (for example, Direct Connect and ExpressRoute). Enterprises also recognize that the performance over a path varies over time. Thus it is important not only to define per-SaaS application policy to configure the preferred path for breakout, but also to monitor the performance of the application over the alternate paths.

Release 20.2 SaaS optimization adds support for:

  • Monitoring of SaaS applications from branches and hubs
  • Distribution of path performance metric between the branches

With this SaaS optimization, Versa monitors performance towards configured SaaS applications. The monitoring uses ICMP messages to measure the performance metrics towards the SaaS cloud.

Additionally, the measured performance for reaching each configured SaaS application from each site is advertised over the SD-WAN overlay to the peer sites. Each branch calculates the expected performance for reaching SaaS applications not only directly, but also when relayed over other sites. Thus a branch can make decision to route the application either locally or via the hub to get the best performance as defined by the policy.

Take, for example, a CPE that has two ISP links and that is also connected to a hub in the data center. Both the branch CPE and the hub monitor the performance towards configured SaaS applications. In addition, the hub advertises the performance measurement to all its SD-WAN peer nodes. The branch CPE makes the routing decision based on the performance monitored over the local links and the hub link.

DNS Security Feeds and Filtering

Release 20.2 adds DNS security feeds and filtering functionality to the Versa comprehensive security set of functions. You can add DNS security feeds and filtering of DNS proxy, which was added in Release 20.1, or you can operate it in DNS server mode.

DNS filtering provides advanced network configuration options for parental controls, company compliance, and online safety. It delivers protection from threats such as DNS hijacking attempts, phishing attacks, malware, ransomware, and botnets, and it offers protections to block access to compromised websites.

DNS filtering effectively allows you to configure advanced network security for a  specific domain. If you try to visit a website and the domain is found to be malicious. DNS filtering can block or redirect that request to a safe page, depending on the configuration.

The Versa DNS filtering implementation is feature rich. You can apply DNS filtering to zones, IP addresses, geographic location, user, and group, or to a combination of these criteria. This level of granularity allows you to finely tune DNS security policies based on business needs and company security policies.

DNS filtering provides protection against DNS attacks, such as DNS anomaly (injection), DNS reflection, and DNS amplification attacks.

DNS filtering is lightweight, fast, and scalable and, with premium and enterprise-level offerings, offers advanced flexibility for policy management and customization. Each organization operates differently and has unique requirements and cultural norms as well as web browsing habits. DNS filtering allows IT teams to support custom-tailored configurations with peace of mind.

Using the security functions of DNS filtering also requires regular maintenance and upkeep. Hackers use intelligent techniques, such as using short-lived domains, to upload viruses or malicious code to compromised machines. These techniques allow them to bring up domains that can be highly mobile over the internet. To keep DNS entries up to date and to block malicious or suspicious domains or domains that may have just arrived, DNS feeds come into play. DNS feeds are provided by global DNS threat Intelligence from hundreds of sensors spread over the internet. Terabytes of DNS query data (from a passive DNS database) are processed and only domains that are believed to be safe or that have a proven track record are provided access. This service not only makes the maintenance task very easy, but also provides an added level of security by using cloud-provided, secure, and sanitized DNS feeds.

If you use DNS feeds and filtering in combination with URL feeds, categories, and filtering, the efficacy of DNS feeds and filtering is increased further. DNS feeds and filtering is a powerful resource for communications providers, ISPs, MSPs, and CASBs, as well as for enterprises who choose to deploy Versa NGFW locally.

HTTP Proxy for Traffic Steering

Many customers have networks that include a proxy in the data center. With the advent of SaaS-based applications, this architecture faces scaling challenges, because every internet-bound packet has to traverse the link from the branch to the data center. Customers want to offload trusted traffic typically going towards SaaS applications while still using the data center-based proxy to scan the rest of the traffic. Customers also want to ensure the availability of the service when the LBO path for the application is down or underperforming. SaaS application traffic should be routed through the hub or data center.

In Release 20.2, you can configure the customer network to intercept or terminate the proxy connection, route the traffic (including DNS requests) based on SD-WAN policy, do proxy chaining (or LBO) for destinations specified by SD-WAN policy, and monitor the reachability and performance over various links to ensure application delivery to the branch. You can integrate DNS proxy, HTTP forward proxy, DIA and SaaS optimizations, and SD-WAN policy to configure and apply complex customer business policies

Secure HTTP/HTTPS Proxy and Proxy Chaining

A forward proxy forwards outgoing requests from a private network or intranet to the internet, usually through a firewall. The main goal of a forward proxy is to provide a level of security by funneling all requests through a security filter and applying traffic control functions such as firewalls. For example, you can configure a web browser to make all requests through the proxy, which in turn applies firewall rules and functions.

In the case of forward proxy, connections coming from the client do not need to be terminated, because it is a transparent proxy. Forward proxy transparently decrypts HTTPS traffic so that it can process and redirect the traffic as needed. The server still sees the addresses of the clients, provided no NAT is involved subsequently in the data path.

Here are common uses of forward proxy:

  • Control the outgoing traffic originated from a client in an internal network and ensure the security of the internal network by directing the traffic to a local or remote firewall (such as a security-as-a-service site)
  • Control access to content or manage access by user or group
  • Act as a single point of access and control for clients in the internal network by providing administrative control over content that is being relayed.
  • Help bypass state or institutional browsing restrictions by serving those requests to a proxy, which then funnels the traffic through a secure tunnel to a traffic breakout point that is located outside the restricted traffic zone.

A reverse proxy is a server that typically sits in front of web servers and forwards client (for example, web browser) requests to those web servers. Reverse proxies are typically implemented to help increase security, performance (that is, ADC/LB), and reliability.  Currently, Versa FlexVNF does not support reverse proxy.

You can chain proxy servers across your network or across multiple networks. You can assign a specific number of clients to each proxy within the chain, and you can forward traffic from one proxy to another proxy that may be implementing different security or traffic control functions.

In Release 20.2, Versa FlexVNF provides forward proxy and proxy chaining functions. Forward proxy supports DIA and DCA use cases as well as proxy chaining use cases. Forward proxy supports HTTP- and HTTPS-based sessions. For HTTPS sessions, Versa FlexVNF uses SSL proxy.

The HTTP/HTTPS proxy actually has more capabilities than forward or reverse proxy functions, and could better be defined as a secure proxy. The secure proxy includes the following functions:

  • Capabilities to handle different HTTP transaction types
  • Support for transparent and explicit modes
  • Appropriate SNAT (pools) and DNAT functions
  • Integrated DNS resolution, DNS proxy, and DNS security functions
  • Full security functions including NGFW, URL-based traffic management, and UTM-type comprehensive traffic and application security functions
  • SSL proxy to process HTTPS traffic
  • Certificate-based encryption and decryption
  • Integration with Active Directory for user- and group-level authentication and traffic management
  • HTTP cookie-based identification and authorization
  • Token-based authentication
  • Multitenancy via organization and tenant structure, and support for VRFs and routing instance
  • Logging and reporting functions, including LEF logs

This rich and market-leading secure proxy implementation allows Versa to insert its on-prem, on-DC (private cloud), or public cloud-based services flexibly as customer business requirements dictate. Versa secure proxy combined with the SD-WAN functions provides an unmatched scope in the current market .

802.1X Support

Versa is continuously expanding its network access control (NAC) features, and 802.1X is the latest addition to this.

IEEE 802.1X is a standard for network access control (NAC). It is part of the IEEE 802.1 group of networking protocols, and provides an authentication mechanism to devices wishing to attach to a LAN or WLAN.

802.1X authentication involves three parties: a supplicant, an authenticator, and an authentication server. The supplicant is a client device (such as a laptop) that wishes to attach to the LAN/WLAN. The term supplicant is also used interchangeably to refer to the software running on the client that provides credentials to the authenticator. The authenticator is a network device that provides a data link between the client and the network and that can allow or block network traffic between the two, such as an Ethernet switch or wireless access point. The authentication server is typically a trusted server that can receive and respond to requests for network access, that can tell the authenticator whether to allow the connection, and that can tell the authenticator of any settings that should apply to that client's connection. Authentication servers typically run software that supports the RADIUS protocol. In some cases, the authentication server software may be running on the authenticator hardware.

The authenticator acts like a security guard to a protected network. The supplicant (that is, the client device) is not allowed access through the authenticator to the protected side of the network until the supplicant's identity has been validated and authorized. With 802.1X port-based authentication, the supplicant must initially provide the required credentials to the authenticator. These credentials are specified in advance by the network administrator and can include a MAC address or a permitted digital certificate. The authenticator forwards the credentials to the authentication server, which decides whether to grant access. If the authentication server determines the credentials are valid, it informs the authenticator, which, in turn, allows the supplicant (that is, the client device) to access resources located on the protected side of the network.

While the authenticator provides the access control of the client machine, the user using that machine is likely to go through an additional level of authentication, which typically involves captive portal and Active Directory based user- and group-level authentication and authorization. Versa has supported  Active Directory (backed by SAML and Kerberos)-based user- and group-level authentication for some time, and in Release 20.2 Versa adds 802.1X to its list of supported protocols.

The Versa implementation of 802.1X in Release 20.2 includes certificate-based and MAC-based authentication  locally as well as via a RADIUS server backend.

On the client side, Versa FlexVNF supports the EAP and EAP-TLS protocols, which are commonly used commonly in conjunction with 802.1X to authenticate client devices.

It is recommended that you use certification-based authentication as the default mode of supplicant authentication; when this is not possible, apply MAC-based authentication. Currently, it is relatively easy to overwrite MAC addresses, so you should use it with discretion. Versa has seen that most current mobile and desktop devices support certificate-based authentication . However, some simple or legacy devices (for example, printers) may not support it, so you should consider MAC-based authentication for those devices.

For certificate-based authentication, you first install an X.509-compliant certificate on the supplicant machine. The certificate should be associated with a user or with a group if you want user-level and group-level authentication at the same time. To install valid client and server certificates on FlexVNF, you configure the FlexVNF with a properly signed X.509-based certificate obtained from a  legitimate certificate authority (CA) server. Then Versa FlexVNF can use the certificate to locally authenticate the supplicant device. When the supplicant provides a device certificate as part of the response to the 802.1X authentication challenge, the device certificate is validated against the certificate of the trusted CA that is configured on the Versa FlexVNF.

Versa has tested interoperability with commonly used CA servers, such as EJBCA.

On the backend side, RADIUS is a popular method to authenticate and authorize client access . It is recommended that you first authenticate the client device using certificate-based authentication, followed by RADIUS server-based authentication, to provide authorization for network access along with more specific data (such as, authorized VLAN to access , time of the day, and other parameters to be added in the future).

As a last resort, MAC-based local authentication is possible, but it is recommended that you use it only to cover exception situations, such as when the backend server is down or not accessible.

You can configure each authenticator port to authenticate one or more supplicant (client) devices.

The Versa 802.1X implementation is designed and implemented as a multitenant implementation and provides flexibility to separately manage each tenant with its own RADIUS servers.

Device Identification and Fingerprinting Enhancements

In Release 20.1, Versa introduced device identification, and fingerprinting and logging capabilities. In this release, an HTTP/HTTPS user agent header analysis technique was used to fingerprint a device.

In Release 20.2, Versa FlexVNF adds support for MAC address-based fingerprinting.

To implement this functionality, Versa uses the IEEE organizationally unique ID (OUI). The first three bytes of the MAC address are assigned for OUI. The OUI is a 24-bit number that uniquely identifies a vendor, manufacturer, or other organization. To interpret OUI information, Versa FlexVNF includes an OUI database that contains the OUI information of common vendor brands and types of client devices.

Note that MAC address-based identification technique has some limitations. One is that if the client device is behind an IP router, the client device’s MAC address is not visible to the FlexVNF device. As a result, the Versa FlexVNF uses the MAC address of the router. Despite this, adding MAC address-based identification provides additional value, especially for deployments that have Layer 2 switches or WiFi APs that forward the packet without changing the Layer 2 packet headers. In such cases, the MAC address of the client can be used as an additional means to identify and log the device.

The fingerprinted device and its associated information can be logged to Versa Analytics. These device log’ include the device’s MAC address, IP address, device type, browser information, and information obtained from other network headers. This information can then be stored and analyzed at a base level by Versa Analytics. This information can also  be forwarded to third-party systems for deeper analysis.

In a later release, Versa will provide the ability to categorize and control the access by applying security policies to enforce security measures. The categorization and policy application enables the operator to isolate certain types of vulnerable devices to prevent them from becoming the means for security threats.

FIPS 140-2 Level 1 Compliance

Federal Information Processing Standards (FIPS) are a set of standards that describe document processing, encryption algorithms, and other information technology standards for use within U.S. and Canadian non-military government agencies and by government contractors and vendors who work with these agencies.

FIPS 140-2 is the benchmark for validating the effectiveness of cryptographic hardware and software. Although FIPS has been defined and verified by the U.S. and Canadian governments, it has been adopted widely across the globe as a practical security benchmark and realistic best practice.

The FIPS 140-2 standard has several levels:

  • Level 1: Covers production grade and externally tested encryption algorithms.
  • Level 2: Adds requirements for physical tamper evidence and RBAC. Software implementations must run on an OS approved by the common criteria.
  • Level 3 and Level 4 have even stricter requirements.

In Release 20.2, Versa delivers an encryption implementation supports FIPS 140-2 Level 1 for all encryption-capable software modules. Within FlexVNF, the FIPS cryptographic boundary is drawn around each cryptographic module, and within this boundary only FIPS-approved cryptographic algorithms are used. No critical security parameters, such as passwords and keys, can cross a module’s cryptographic boundary.

The FlexVNF cryptographic modules include IPsec, SSL (that is, SSL Proxy), and other applications that use cryptography, such as the SSH, SCP, NTP, DNS, SNMP, AV, IPS, file filtering, and device identification modules .

In Release 20.2, Versa FlexVNF operates in FIPS compliant and non-compliant modes across all cryptographic modules. To enable FIPs compliance, you configure the FlexVNF to enter the FIPS-compliant mode, and then you reboot the device. After the reboot, FlexVNF starts running in FIPS-compliant mode and it cannot revert to non-compliant mode. A FlexVNF device operating in FIPS mode is a nonmodifiable operational environment within the FIPS boundaries .

FIPS operation mode disables cryptographic standards that are perceived to be weaker standards, such as DES and MD5, and it allows only strong cryptography modes through the use of FIPS-compliant software libraries.

When FIPS mode is first enabled, the cryptographic officer enables FIPS operation mode and sets up keys and passwords for the system and for other FIPS users who can view the configuration. Both types of users can perform normal configuration tasks on the device (such as modifying interface types) as the individual user configuration allows.

Versa highly recommends that you enable FIPS mode operation on hardware platforms that are designed for FIPS compliance, such as Versa CSG700 Series platforms. Versa CSG700 platforms are designed from the ground up to be FIPS compliant: they are resistant to tampering, and they come with tamper-evident stickers on appropriate screw heads. CSG700 units do not allow external probing through gaps or holes, and they are designed and built to be a resilient and trustworthy hardware platform.

In a later release, Versa plans to complete the common criteria scope and to apply for FIPS 140-2 Level 2 certification for the CSG700 Series platforms.

Cloud-Based URL Lookups

Versa provides a highly effective, easy-to-use URL feeds and filtering function that allows Versa FlexVNF to classify and manage traffic destined for hundreds of millions of web addresses. Versa preclassifies these URL addresses into 83 categories based on the types and risks of URLs.

In release before Release 20.2, Versa FlexVNF provided URL lookups based on its local database, which is populated with the BrightCloud URL database (provided on a given version). The local FlexVNF database was kept up to date with URL feeds and with service acks (spacks).

In Release 20.2, FlexVNF implements cloud-based URL lookup, which extends the scope of the URL feeds and filtering function by leveraging an omnipresent, fully comprehensively populated, and always up-to-date URL database located in the cloud.

This capability is helpful when a URL class or risk cannot be determined and so further cloud lookup is warranted, when near real-time up-to-date malicious web site information is needed, or when the network administrator wants to reduce the footprint of the URL database on the branch appliance so as to share compute and memory across a larger set of functions.

The cloud-based URL lookup executes according to the default or user-defined execution order. By default, the cloud-based URL lookup is executed after all the local lookups (the local cache and local database lookups) complete. This default execution order is chosen to provide an optimum balance between the breadth of cloud-based lookups and the latency of local lookups.

Cloud-based lookups help populate the local cache with the most recent entries, which can be used when next looking up the same URL without reaching to the cloud.

 

SNMP Inform Support

SNMP Inform messages address the best effort, unacknowledged, and asynchronous nature of UDP-based SNMP traps, which can leave the sender not knowing whether the receiver received an SNMP trap that may be carrying important alert or event information.

SNMP Inform messages do not change the transport mechanism, but rather they provide a simple acknowledgement process for SNMP traps in SNMPv2 and SNMPv3. Each time an SNMP Inform PDU is sent, the receiver sends an acknowledgement message back via an SNMP Response PDU, informing the sender that the trap was successfully received. This synchronous communication happens at the SNMP application layer.

Note that if you configure  firewall on the FlexVNF, you may want to open pinholes in the firewall to allow SNMP Response packets to return to the FlexVNF, to ensure proper operation of the SNP Inform messages.

Spoke-Hub-Hub-Spoke Topology Support

Versa SD-WAN supports various topologies to scale and to meet our customer’s deployment needs.  Versa FlexVNF supports the following SD-WAN topologies:

  • Hub and spoke
  • Full mesh
  • Partial mesh
  • Controller behind branch
  • Branch behind branch
  • Dynamic spoke to spoke with hub
  • Custom topologies
  • Spoke hub hub spoke, new in Release 20.2

The Versa control plane provides the flexibility to define and establish different VPN topologies at the VRF and the tenant levels. Although the default Versa SD-WAN model provisions a full forwarding mesh through IP prefix advertisement in MP-BGP, you can configure other VPN topologies using Versa Director workflows.

One such topology, new in Release 20.2, is called spoke-hub-hub-spoke (SHHS). An SHHS topology consists of islands of branch routers that are interconnected with hub sites. Large networks that have regional SD-WAN networks (such as U.S. west coast and a U.S. east coast region networks interconnected via hub sites) utilize this type of topology

While many SD-WAN vendors may offer support on the surface for such a topology support, the scope consists of separate SD-WAN islands, which is complex for the network operator for the following reasons:

  • SD-WAN islands must be interconnector with IPsec or other forms of connectivity options that must be provisioned and managed outside the SD-WAN domain.
  • With separate SD-WAN islands, each SD-WAN domain operates within itself, with no visibility or information about the other domains.
  • The separation prevents the control planes of each SD-WAN island from exchanging information with each other.
  • Controller placement for each SD-WAN domain adds additional resource requirements.
  • Tenant creation across SD-WAN islands become an even more complex task. For example, consider the stitching complexities on the boundary node that act like NNI points.
  • Service template management across SD-WAN islands become a complex task.

The Versa SHHS solution tackles this problem, providing a solution that is highly scalable, compartmentalized, fully automated, and easy to deploy and operate. SHHS is made possible by the following enhancements:

  • Changes in the MP-BGP-based Versa control plane to accommodate new community attributes for each SD-WAN island.
  • Introduction of a hierarchical controller structure to interconnect the control planes of SD-WAN islands that may be using their own controller instances, for example, in today’s existing deployments.
  • Enhancements to service templates, spoke templates, and provisioning Workflows to support SHHS operations.
  • Ability to consolidate controller and hub functionalities onto one node, called a hub-controller node (HCN), to preserve resources in the control side of the network. HCN nodes exchange information with spokes, and they implement the data plane functions of hub nodes.
  • HCN can be deployed in fully redundant mode, maximizing uptime and ease of serviceability.
  • Multitenancy is preserved across the topology using the organization and suborganization structure.
  • Spoke groups can be connected to select hubs based on their tenant descriptions.

To have spoke-to-spoke connectivity across two islands, the network administrator first needs to convert existing hub sites to HCN or needs to install a hierarchically higher controller node using controller Workflows. Doing this allows the establishment of a common control plane under the control of the same Versa Director instance or instances that oversee multiple regions. This process assigns separate community values to represent each SD-WAN island. The network administrator then provisions tenants and services starting from the spokes of one SD-WAN island to the other SD-WAN island using the expanded templates for SHHS deployment.

As these tasks are completed at the underlying data plane, SD-WAN paths are automatically established between Spoke-1 and Hub-1, Hub-1 and Hub-2, and Hub-2 and Spoke-2 in a hop-by-hop manner, in both directions. These paths can be separate SD-WAN tunnels or shared SD-WAN tunnels that may already be present between spoke and hub routers. Traffic is separated with MPLS tags from other tenants or from other topologies. All data plane operations are handled automatically, requiring no manual involvement from the network administrator. After the end-to-end data paths are set up, the users can start communicating between the spokes of separate SD-WAN islands. This communication is seamless thanks to the Versa established advanced routing and SD-WAN capabilities.

As it can be seen in this example, the Versa architecture and our implementation choices are based on standards-based protocols, and encapsulations, and they are scalable and resilient solutions that are proven on service provider and large enterprise networks. The use of such advanced routing and standards-based technologies allows our customers to adopt our solutions with minimal learning requirements, and to deploy and operate these solutions quickly.

Versa Director Performance and Scaling Improvements

The Versa Director CDB has moved to MySQL database for faster performance and better scaling. This enhancement is fully backwards compatibility with field-installed FlexVNF devices that may be running different versions of FlexVNF software. All configuration and other persistent data is preserved during the transition.

While this change is not visible to customers, you will notice improved scaling and performance of Versa Director.

OS Security Pack Update Management

In Release 20.2, you can manage OS security pack updates through Versa Director, easing the OS pack update management tasks. Before Release 20.2, network administrators needed to update the host OS of the FlexVNF via the FlexVNF command line. This was a time-consuming effort that required the network administrator to log in to each FlexVNF and administer the update one by one. The new Versa Director-based OS security update and patching process is greatly simplified. The network operator can use the appropriate OS security update GUI to administer security packs across a number of FlexVNF instances in the network.

Versa Director Azure vWAN Integration

Microsoft Azure Virtual WAN (vWAN) uses the Microsoft-empowered network backbone to optimize and accelerate path routing between on-premises or virtualized devices and the workloads placed in Microsoft Azure using secure IPsec tunnels. You can also leverage the Azure backbone to connect branches and to provide branch-to-VNet connectivity.

The service is provided over an IPsec tunnel created between the branch CPE (in this case, Versa FlexVNF) and the virtual hub VPN gateway residing in vWAN. Every branch in the network creates a site-to-site IPsec tunnel between the CPE and the virtual hub VPN gateway residing in the vWAN. The “allow branch to branch traffic” property in the vWAN enables traffic between branch CPEs via the virtual hub.

Traditionally, configuring the vWAN tunnels consists of two steps:

  • Create the VPN site with IPsec tunnel information and BGP configuration (optional) under the Azure vWAN.
  • Manually download the VPN device configuration from Azure, and replicate it on the branch CPE using Versa Director.

In Release 20.2, Versa Director automates the configuration of the site-to-site tunnel by eliminating the need for manual configuration. Versa Director uses Azure APIs to automatically create the VPN site on Azure and to then download the relevant branch configuration and push it to the branch.

A customer with hundreds of sites can now easily configure VPN sites per branch on Azure. Versa Director automatically pulls the branch’s configuration and configures the site-to-site tunnel automatically.

URL-Based ZTP Support for PPPoE

With URL-based ZTP, a site administrator activates a FlexVNF device after receiving an email that includes a link to the staging and post-staging Controller. The administrator connects to the device using a laptop or mobile phone and clicks the link, and then the Controller completes the device activation.

The administrator configures the parameters required by the CPE for communicating with the controller and getting authenticated (for example  IP address configuration, Controller IP address, and PSK for authentication ) in Versa Director, and these parameters are encoded and encrypted in the URL parameters.

In Release 20.2 , Versa Director can be configured with PPPoE authentication and configuration parameters, and these parameters are encoded in the URL. When the administrator connects to the device and clicks the link, the device decodes the PPPoE parameters and uses them to authenticate with the ISP.

The following parameters c configured in the URL:

  • PPPOE_USER
  • PPPOE_PASSWORD
  • PPPOE_SERVICE (optional)
  • PPPOE_ACCESS_CONCENTRATOR (optional)

Versa Analytics Voice and Video Traffic Class Data Aggregation and Reporting

Currently, enterprises use more than one kind of communication appliance in their network. For example, for voice traffic it is quite common to have desk phones from Polycom, Zoom audio, Skype for business for one-to-one calling, and Microsoft Teams.. Thus audio traffic in the enterprise networks consists of multiple applications. In such an deployment, tracking the network usage of all voice traffic is a tedious process, because rules for all the individual applications need to be added.

In Release 20.2, we simplify the process by providing predefined application categories. A new report added to the Applications tab of the Site Dashboard displays the share of application throughput per application category. The data packets from applications that match a particular category of application (such as voice, video, and SaaS) are counted by category.

This feature allows customers to compare the network usage for predefined categories without having to configure tens of applications for each category. Customers can drill down on a particular type of traffic or on a per-application basis to display time series data.

Alarm Correlation and Historical Reporting

In Release 20.2, Versa Analytics provides reports that show the aggregated view of both current and historical alarms. The reports provide useful information, such as detailed statistics, trends, and correlations between alarm events and sources.

The time series data provides both a high-level and detailed graphical view of the alarms generated in the network. You can drill down for more detailed information about a time slot or appliance.

Map View Enhancements

Release 20.2 provides new options to view network, traffic, connectivity, alarms, and threats on the map. These options are available only for Google Maps.

  • Traffic View: Shows site-to-site traffic for the specified interval.
  • Connectivity View: Shows site-to-site connectivity status based on SLA for the specified interval.
  • Alarm View: Shows sites with alarms. Drilling down on the site shows the top alarms for that site.
  • Threat View: Shows sites with security threat events. Drilling down on the site shows the top threats for that site.

Support for Regex in Log Filtering

In Release 20.2, when you apply filters to logs, you can specify standard regex filters.

  • Was this article helpful?