Versa Analytics Release Notes for Release 21.2

Product Documentation

The Versa Networks product documentation is located at https://docs.versa-networks.com.

Install the Versa Analytics Software

To install the Versa Analytics software, see the Deployment and Initial Configuration articles.

Before You Upgrade

Before you upgrade the Analytics software to Release 21.2, upgrade the OS SPack on all Analytics nodes following the steps in Use OS Security Packages.

Release 21.2 requires that Analytics nodes run the Fusion database platform; the DSE database platform is not supported.

Before you upgrade, check the Analytics database platform:

1. Upgrading to Release 21.2.2 or later requires that the underlying database to be Fusion. If the database is not Fusion, upgrade to 21.2.1 and then migrate the database to Fusion. After the Fusion migration, upgrade to Release 21.2.2 or later.
2. Check whether the database is using the DSE or Fusion package. In Director view, select Analytics > Administration > Version in the left menu bar. If the string in the Database Version field ends with F, the database is Fusion. If it ends with E or does not display any character, the database is DSE.
   
   
3. If the database is DSE, SSH to any of the analytics or search nodes and issue the following command:

versa@versa-analytics:~$ dse -v
4.5.2

3. If the database is DSE 4.5.x, upgrade to DSE 4.8 using the DSE migration scripts in the Customer Support article at https://support.versa-networks.com/support/solutions/articles/23000019690
4. After you upgrade to DSE 4.8, upgrade the Analytics application to Release 21.2, as described in Upgrade to Release 21.2, below.

Upgrade to Release 21.2

You can upgrade Versa Analytics nodes to Release 21.2 from any service release of Release 16.1R2, that is, from Releases 16.1R2(Sx), and from Releases 20.2.x. Upgrading to Release 21.2.2 or later requires the underlying database to be Fusion. If the database is not Fusion, upgrade to Release 21.2.1 and then migrate the database to Fusion. After the Fusion migration, upgrade to Release 21.2.2 or later.

To upgrade to Release 21.2:

1. Copy the appropriate binary package file to the /home/versa/packages/ directory on the Analytics node. Ensure that the file has +x execute permission. Alternatively, issue the following command, which copies the file to the /home/versa/packages directory:

   versa@versa-Analytics> request system package fetch uri uri
   

2. Install the new software package:

   versa@Versa-Analytics> request system package upgrade filename.bin
   

3. Check the status of the Versa services to determine whether they have started:

   admin@versa-analytics:~$ vsh status
   

4. If the services have not started, start them:

   admin@versa-analytics:~$ vsh start
   

5. Ensure that the Analytics IP addresses are present:

• Search node IP addresses are listed under Search Hosts
• Analytics node IP addresses are listed under Analytics Hosts
• All log collector or forwarder IP addresses are listed under Driver Hosts

6. After the upgrade completes, a message may display indicating that you should reboot the system. Even if a message does not display, it is recommended that you reboot the system to account for any GRUB or kernel parameter changes. To reboot the system:

    admin@versa-analytics:~$ sudo reboot
   

   After the reboot completes, the Versa services automatically restart.

versa@versa-director:.../vnms/scripts$ ./vd-van-cert-upgrade.sh --pull
Pulling Analytics certificates to Director key store
Checking previous version config path
Changing port for [Analytics]
No modifications to commit.
Port Migration completed
VAN Clusters IPs: [ 10.48.189.23 ]
Removing previous analystics cert store
Getting Certificate for : 10.48.189.23
depth=0 C = US, ST = California, L = Santa Clara, O = versa-networks, OU = VersaAnalytics, CN = versa-analytics
verify error:num=18:self signed certificate
verify return:1
depth=0 C = US, ST = California, L = Santa Clara, O = versa-networks, OU = VersaAnalytics, CN = versa-analytics
verify return:1
DONE
Importing Certificate for : 10.48.189.23
Certificate was added to keystore
Certificates Imported... Requires restart.. Do you want to postpone restart (y/N): N
[sudo] password for versa:
Stopping VNMS service
------------------------------------
Stopping TOMCAT................[Stopped]
Stopping REDIS.................[Stopped]
Stopping NETBOX-IPAM...........[Stopped]
Stopping POSTGRE...............[Stopped]
Stopping SPRING-BOOT...........[Stopped]
Stopping SPACKMGR..............[Stopped]
Stopping NCS...................[Stopped]
* Stopping daemon monitor monit
Starting VNMS service
------------------------------------
Starting NCS...................[Started]
Starting POSTGRE...............[Started]
Starting NETBOX-IPAM...........[Started]
Starting SPRING-BOOT.......... [Started]
Starting REDIS.................[Started]
Starting TOMCAT................[Started]

New Features

This section describes the new Versa Analytics features in Release 21.2. Releases 21.2.1 and later of Versa Analytics are backward compatible with any service release of Release 16.1R2, that is, from Releases 16.1R2(Sx), of VOS software. Releases 21.2.1 and later of Versa Analytics are also backward compatible with Releases 20.2 and Releases 21.1of VOS software.

• Advanced logging service—(For Releases 21.2.3 and later.) You can configure the advanced logging service (ALS) connector, and then on-premises Analytics clusters can reference the connector for various log types. See Configure the Versa Advanced Logging Service.
• Analytics alarm settings enhancements—(For Releases 21.2.2 and later.) Versa Analytics includes new alarm types and overrides for default severity settings per alarm type. These settings allow you to:
  • Enable parameters for new alarms for CPU utilization, memory utilization, disk utilization and Versa Analytics driver stuck.
  • Configure the severity for set and clear alarms.
  • Configure overrides for threshold alarms for low-threshold and high-threshold severity alarms.
    
    
• Analytics cluster redundancy—You can configure Analytics cluster redundancy. There are two redundancy options: active-backup mode and active-active mode.

  In active-backup mode, the secondary (backup) cluster is used only when the primary cluster goes down. The application delivery controller (ADC) load balancer on the Controllers steers the log connections to the secondary cluster during data center failure. When the primary data center comes back up, the ADC switches the connections back to the primary cluster. The secondary cluster may have collected data for the duration of the time of failure. The secondary cluster may run the database or just perform the log collection function. You can use cron scripts on the secondary cluster to ship logs back to the primary cluster when it comes back up.
  
  The following components are involved for managing active-backup Analytics clusters:
  
  • Director—Director has two connectors: one pointing to the primary cluster and another pointing to the secondary cluster. Director can access Analytics data by switching to the primary or secondary cluster IP address.
  
  • Controllers—The application delivery controllers (ADC) running on the primary and backup Controllers have one virtual IP address (VIP) pointing to two pools: a primary and a backup. The primary pool contains servers of the primary data center and the backup pool contains servers of the secondary data center. See Configure an Application Delivery Controller.
  
  • Branches—Branches are configured with LEF collector groups containing LEF collectors using the VIPs of the primary and backup Controllers as their destination IP address and port.

  
  
  A configuration example for Controller1 is shown below.

admin@SDWAN-Controller1-cli(config-adc)% show
lb {
    servers {
        LEF-Collector-Analytics-1 {
            type             any;
            ip-address       192.168.95.2;
            port             1234;
            state            enabled;
            routing-instance provider-org-Control-VR;
        }
        LEF-Collector-Analytics-2 {
            type             any;
            ip-address       192.168.95.3;
            port             1234;
            state            enabled;
            routing-instance provider-org-Control-VR;
        }
        LEF-Collector-Analytics-3 {
            type             any;
            ip-address       192.168.96.2;
            port             1234;
            state            enabled;
            routing-instance provider-org-Control-VR;
        }
        LEF-Collector-Analytics-4 {
            type             any;
            ip-address       192.168.96.3;
            port             1234;
            state            enabled;
            routing-instance provider-org-Control-VR;
        }
    }
    server-pools {
        VAN-Primary-Pool {
            type any;
            member LEF-Collector-Analytics-1;
            member LEF-Collector-Analytics-2;
        }
        VAN-Secondary-Pool {
            type any;
            member LEF-Collector-Analytics-3;
            member LEF-Collector-Analytics-4;
        } 
 
    }
    virtual-services {
        VAN-VIP {
            type             any;
            address          10.0.0.0;
            port             1234;
            default-pool     VAN-Primary-Pool;
            default-backup-pool VAN-Secondary-Pool;
            fallback-to-active enabled
            routing-instance provider-org-Control-VR;
        }
       
    }
}

A similar configuration is done on Controller2.

A configuration example for Tenant1 on a branch VOS device is shown below.

[edit orgs org-service Tenant1 lef]
collectors {
    collector LEF-Collector-log_collector1 {
        destination-address 10.0.0.0; à Controller1 VIP
        destination-port    1234;
        routing-instance    provider-org-Control-VR;
        transport           tcp;
        template            Default-LEF-Template;
    }
    collector LEF-Collector-log_collector2 {
        destination-address 10.0.0.4; -> Controller2 VIP
        destination-port    1234;
        routing-instance    provider-org-Control-VR;
        transport           tcp;
        template            Default-LEF-Template;
    }
}
collector-groups {
    collector-group Default-Collector-Group {
        collectors [ LEF-Collector-log_collector1 LEF-Collector-log_collector2 ];
    }
}
profiles {
    profile Default-Logging-Profile {
        collector-group-list [ Primary-Collector-Group Secondary-Collector-Group ];
    }
}
default-profile Default-Logging-Profile;

In active–active mode, both primary and secondary clusters receive log data from VOS devices. The ADCs on the Controllers have separate VIPs for the primary and secondary clusters. There is no backup pool configured on the VIPs. During normal conditions, both clusters will have the same data. During failure, the cluster which is down may not have the data for the period of failure. Data will not be synced between the clusters. You may need to connect to both the clusters to compare the data during failure scenarios.

The following components are involved for managing active-active clusters:

• Director—Director has two connectors: one pointing to the primary cluster and another pointing to the secondary cluster. Director can access Analytics data by switching to the primary or secondary cluster IP address.
• Controllers—The ADC running on each Controller has two VIPs using only primary pools. The first VIP on each Controller points to servers in the primary cluster and the second VIP on each Controller points to servers in the secondary cluster.
• Branches—Branches are configured with two LEF collector-groups. One collector-group contains log collectors with the VIPs of primary and backup Controller pointing to the primary cluster as destination IP and port. The other collector-group contains collectors with the VIPs of primary and backup Controller pointing to the secondary cluster as destination IP and port. A collector group list containing both collector groups is configured under the LEF profile.

A configuration example for Controller1 is shown below.

admin@SDWAN-Controller1-cli(config-adc)% show
lb {
    servers {
        LEF-Collector-Analytics-1 {
            type             any;
            ip-address       192.168.95.2;
            port             1235;
            state            enabled;
            routing-instance provider-org-Control-VR;
        }
        LEF-Collector-Analytics-2 {
            type             any;
            ip-address       192.168.95.3;
            port             1235;
            state            enabled;
            routing-instance provider-org-Control-VR;
        }
        LEF-Collector-Analytics-3 {
            type             any;
            ip-address       192.168.96.2;
            port             1236;
            state            enabled;
            routing-instance provider-org-Control-VR;
        }
        LEF-Collector-Analytics-4 {
            type             any;
            ip-address       192.168.96.3;
            port             1236;
            state            enabled;
            routing-instance provider-org-Control-VR;
        }
    }
    server-pools {
        VAN-Primary-Pool {
            type any;
            member LEF-Collector-Analytics-1;
            member LEF-Collector-Analytics-2;
        }
        VAN-Secondary-Pool {
            type any;
            member LEF-Collector-Analytics-3;
            member LEF-Collector-Analytics-4;
        } 
 
    }
    virtual-services {
        VAN-Primary-VIP {
            type             any;
            address          10.0.0.0;
            port             1235;
            default-pool     VAN-Primary-Pool;
            routing-instance provider-org-Control-VR;
        }
        VAN-Secondary-VIP {
            type             any;
            address          10.0.0.0;
            port             1236;
            default-pool     VAN-Secondary-Pool;
            routing-instance provider-org-Control-VR;
        }
    }
}

A similar configuration is done on Controller2.

A configuration example for Tenant1 on a branch VOS device is shown below

[edit orgs org-service Tenant1 lef]
collectors {
    collector LEF-Collector-log_collector1 {
        destination-address 10.0.0.0; à Controller1 VIP
        destination-port    1235;
        routing-instance    provider-org-Control-VR;
        transport           tcp;
        template            Default-LEF-Template;
    }
    collector LEF-Collector-log_collector2 {
        destination-address 10.0.0.4; -> Controller2 VIP
        destination-port    1235;
        routing-instance    provider-org-Control-VR;
        transport           tcp;
        template            Default-LEF-Template;
    }
    collector LEF-Collector-log_collector3 {
        destination-address 10.0.0.0; à Controller1 VIP
        destination-port    1236;
        routing-instance    provider-org-Control-VR;
        transport           tcp;
        template            Default-LEF-Template;
    }
    collector LEF-Collector-log_collector4 {
        destination-address 10.0.0.4; -> Controller2 VIP
        destination-port    1236;
        routing-instance    provider-org-Control-VR;
        transport           tcp;
        template            Default-LEF-Template;
    }
}
collector-groups {
    collector-group Primary-Collector-Group {
        collectors [ LEF-Collector-log_collector1 LEF-Collector-log_collector2 ];
    }
    collector-group Secondary-Collector-Group {
        collectors [ LEF-Collector-log_collector3 LEF-Collector-log_collector4 ];
    }
}
profiles {
    profile Default-Logging-Profile {
        collector-group-list [ Primary-Collector-Group Secondary-Collector-Group ];
    }
}
default-profile Default-Logging-Profile;

• Analytics log collector nodes accept newer IPFIX template version—In releases prior to Release 21.2.1, Analytics log collector nodes process IPFIX logs only if they are received with a template version less than or equal to its known value. In Releases 21.2.1 and later, Analytics log collector nodes can accept logs from VOS devices running newer versions of the IPFIX template.
  
  By default, new log types sent by branches are dropped and log types recognized by Analytics nodes are accepted and parsed. You can change the default behavior from the CLI. If you disable the default values, all logs with a higher IPFIX template version are dropped. To disable the default values:

versa@versa-analytics% show log-collector-exporter settings template
backward-compatible-only false;

You can check the value using vty commands:

LCED-DBG> show lced globals
LEF Template Version: 97
Kafka Version : 0.11.4-2-g13befa-dirty
LEF template version check relaxed - false

• Analytics platform alarms—Analytics platform alarms provide real-time status about services and activities that require attention. These alarms are logged locally on the hosts, and they can also be streamed to third-party remote collectors, including Director nodes. See Configure Analytics Device Alarms.
• Analytics Secure Access > Users dashboard displays top user count by appliance, continent, city, and country—(For Releases 21.2.2 and later.) You can display the top VOS devices, continents, cities, and countries by user count.
  
  In Director view, select Analytics > Dashboards > Secure Access > Users > Summary to display the following:
  
  
  
  Drill down to display the users for each category:
  
  
   

• Analytics System dashboard displays search log activity—(For Releases 21.2.2 and later.) You can display the number of search logs per type, tenant, and appliance.
  
  Select Analytics > Dashboards > System > Search to display the following.
  
  

• Application reports for SD-WAN and DIA traffic—(For Releases 21.2.2 and later.) You can generate application usage reports for traffic sent on an SD-WAN or DIA interface as follows:
  
  
   
• Custom date and time selection widget—(For Releases 21.2.2 and later.) A new widget for custom date and time selection has been added for dashboard and reporting screens. This widget allows you to specify a custom relative date and time range in addition to an absolute date and time range.

  For example, in Director view, select Analytics > Dashboards > SD-WAN. The following screen displays:
  
  
  
  In the main pane, select Custom Range from the second drop-down menu. The Select Custom Data/Time Range window displays:

  
• Data plane availability report—The data plane availability report shows whether a branch has connectivity to any other remote branches other than Controller nodes. To display the data plane availability charts, select the Availability tab of a site, as shown below. A new service uptime report shows how long the device. You can use the information in this report to determine whether there were any local issues, such as service restarts and device reboots.
  
  
  
  
  To display information about SD-WAN health metrics over time, drill down from the data plane statistics grid:
  
  
  
  Information about the number of seconds all remote sites are down, and other SD-WAN path and site-related statistics is sent using an sdwanHealthLog. An example of an sdwanHealthLog is shown below. This log is sent to the Analytics node every 5 minutes.

2021-01-18T23:05:14+0000 sdwanHealthLog, applianceName=SDWAN-Controller2, tenantName=CVS, 
generateTime=1611011100, tenantId=7, applianceId=0, vsnId=0, duration=300000, pathsUp=0, 
pathsDown=0, pathsNoConf=0, rmtSitesUp=0, rmtSitesDown=0, allRmtSitesDown=0, allRmtSitesDownTime=0, 
svcUptime=329778, allLclCktDown=0 

• Last month time selector—In the day/time selector, you can choose the last month. The last month is the previous calendar month. For example, if today is February 15, the last month report provides data for January, from January 1 through 31.
  
  
• Local collectors for allowed tenants—(For Releases 21.2.3 and later.) You can configure local collectors on Analytics nodes to accept logs only from specified tenants to ensure that only logs from these tenants are parsed and processed by the collector.
  
  
   
• Local collectors for syslog over TLS—(For Releases 21.2.3 and later.) You can configure local collectors on Analytics nodes to receive logs that are in syslog format over TLS transport with the following configuration. When you select TLS transport, you must specify the path to certificates in the TLS Attributes group of fields.
  
  
   
• LEF collector group list—Log export functionality (LEF) on VOS devices is used to send service-specific logs, such as SD-WAN, CGNAT, security, and system logs, to a destination collector. These services refer to a LEF profile, which points to a destination collector or a collector group. A LEF collector group is a container for one or more collectors that are in active-backup mode. Logs are sent to one of the active collectors in the collector group. In Release 21.2.1, you can send logs to multiple destination collectors for high availability or for serving different applications by configuring a collector group list. A LEF profile can refer to a collector, collector group, or collector group list. A collector group list is a list of collector groups. Logs are sent to the active collector of each of the collector groups in the list.
  
  For example, the following configuration creates a collector group list containing Collector-Group1 and Collector-Group2:

[edit orgs org-services Tenant1 lef]
profiles {
    profile Default-Logging-Profile {
+        collector-group-list [Collector-Group1 Collector-Group2];
    }                
}

• Log archive management—After logs are processed on Analytics log collector nodes, the logs are compressed and stored in gzip files in the Analytics archive directory on the node on which they were received. You can restore or delete archived logs from the Director node. You can view the dates of the oldest and newest log archive file and the number of log archive files.
  
  To view, restore, and delete log files, go to the Analytics > Administration > Maintenance > Log Archives screen.
  
  

  Select Delete Archive Logs to free disk space on log collector nodes by deleting archived files for a specific tenant or VOS device and time range.

  Select Restore Archive Logs to extract the archived files for a specific tenant or VOS device and time range into a destination directory. If the destination directory is /var/tmp/log, the data is returned io the database.

  Select View Archive Log Details to determine the number of archived files and the filenames of the oldest and newest files for a tenant or VOS device and for a log collector.

• Log export from Analytics reporting tool—In the Analytics reporting tool, after you generate a report containing logs, you can export the logs to a compressed file from the GUI.
  
  For any report type containing logs, choose the number of rows and then click Add. An Export icon displays. Click to trigger the backend to export the data to a file, compress it and then make it available for download. The process may take few minutes depending on amount of data downloaded.
  
  For example, to generate a report containing traffic logs in Versa Director:
  
  
  
  A progress bar displays in place of the Export icon while the logs are exported. This changes to a Download icon once the export is complete. For example:
  
  
  
  Click the download button to download a tar.gz file to your local system. You can uncompress and extract the file using any file extraction tool.
  
  After you generate a report, you can access the exported files under Analytics > Reporting> Manage > Exported Reports. For example:
  
  
• Log collector connection eviction optimizations—The Analytics local log collector processes the logs received from client connections. By default, each local collector has a maximum connection limit set to 512. When this limit is reached, the log collector stops accepting new connections. You can increase the maximum number of connections. However, doing so can overload the log collector node, especially if all the connections are carrying active data.

  To handle more connections, you add more log collectors. For example, 1024 tenants/appliances may need 2048 connections (for active-backup mode) or four log collectors to handle the processing. You can reduce the number of connections by enabling the suspend backup collector option in the collector groups on customer premises equipment (CPE). If you enable this option, only one connection is enabled during steady-state conditions. However, during some failure conditions, there may be multiple connections from the same CPE.
  
  Releases 21.2.1 introduces connection eviction on Analytics log collector nodes. Connection eviction closes unused connections so that the Analytics log collector node can make space for active connections from CPEs. Normally, there can be multiple connections from the same CPE. However, logs are sent only on one of the connections. When you enable connection eviction, if the maximum connection limit is reached, connections may be closed. Connection eviction is done as follows:

  • If the number of connections from a tenant/appliance is greater than 1, evict the least used connection.
  • If there is only one connection from a tenant/appliance and the connection has been idle for more than 10 minutes, evict the connection.

You can configure connection eviction as follows:

versa@SDWAN-Versa-Analytics% show
collector1 {
    address             192.168.95.2;
    port                1234;
    max-connections     56;
    # By default eviction is turned on
+    connection-eviction true;
    storage {
        directory                /var/tmp/log;
        format                   syslog;
    }
}

You can use VTY commands to check eviction. A new table is maintained to map the tenant/appliance to connection list.

LCED-DBG> show lced connections local
  Local Collector   : collector1(0)
Tenant:              Tenant1  Appliance:        SDWAN-Branch3  Count:  1 FD List: 34
Tenant:         provider-org  Appliance:        SDWAN-Branch1  Count:  1 FD List: 38
Tenant:         provider-org  Appliance:        SDWAN-Branch4  Count:  1 FD List: 60
Tenant:              Tenant6  Appliance:        SDWAN-Branch4  Count:  1 FD List: 53
Tenant:              Tenant7  Appliance:        SDWAN-Branch1  Count:  1 FD List: 36
Tenant:             Tenant10  Appliance:        SDWAN-Branch2  Count:  1 FD List: 43
Tenant:              Tenant1  Appliance:        SDWAN-Branch2  Count:  2 FD List: 46 146
Tenant:              Tenant6  Appliance:        SDWAN-Branch1  Count:  1 FD List: 37
Tenant:              Tenant7  Appliance:        SDWAN-Branch4  Count:  1 FD List: 61
:
:
CPEs : 33  Conns: 34  CPEsWithRedConn: 1 

To check connection evictions:

LCED-DBG> show lced stats | grep -i evict
    Evict Unused Connection Events : 26
    Evict Unused Connection Count : 24

• Rule statistics support for DIA traffic—(For Releases 21.2.2 and later, and for Releases 21.1.3 and later.) You display DIA rule statistics as shown in the following screenshots. In earlier releases, the rule statistics on the SD-WAN site dashboard showed utilization for traffic sent on the SD-WAN overlay only.
  
  
  
  
• SD-WAN application report enhancements—The traffic type and forwarding class are new fields in logs sent from VOS devices running Releases 21.2.1 and later. The SD-WAN application drilldown displays usage per traffic type and forwarding class as shown below. Traffic type can be SD-WAN or DIA. Forwarding class can be one of the 16 forwarding classes, for example: fc_ef, fc_be, fc_nc, or fc_af.
  
  For example, from the Analytics > Dashboard > SD-WAN > Sites screen, select SDWAN-Branch4 from the drop-down. Click the Applications tab and then click the linkedin application on the Top Applications by Bandwidth graph.
  
  

  The logs corresponding to these reports are as follows:

2021-03-05T00:57:12+0000 monStatsLog, applianceName=SDWAN-Branch4, tenantName=Tenant1, 
mstatsTimeBlock=1614906000, tenantId=2, vsnId=0, mstatsTotSentOctets=535, 
mstatsTotRecvdOctets=1074, mstatsTotSessDuration=300000, mstatsTotSessCount=1, 
mstatsType=sdwan-acc-ckt-app-stats, appId=github, site=SDWAN-Branch4, accCkt=WAN3, 
siteId=106, accCktId=3, user=172.16.11.110, networkPrefix= , traffType=SDWAN, fc=fc_be, 
risk=2, productivity=3, family=general-internet, subFamily=web, bzTag=Business

• SD-WAN site tag enhancements—SD-WAN reports allow you to filter based on site tags to get reports for a subset of sites for a tenant. The same concept extends to generating reports for sites with matching tags.
  
  
• Secure access report enhancements—The secure access report under Analytics > Dashboard > Secure Access > Users > Registry provides details of the number of registered users per gateway, client OS, client OS version, client version, and location, as shown below.
  
  
  
  The logs corresponding to these reports are as follows:

2021-02-23T20:01:46+0000 secAccUserRegEventLog, applianceName=HE-DC-Branch-1, 
tenantName=Corp-Inline-Customer-1, vsnId=0, applianceId=1, tenantId=1, userName=abc@versa-networks.com, 
latitude=9.5869, longitude=76.5213, os=macos, osVersion=11.2.1, secAccClientVersion=7.2.1

• Statistics rollup—The Analytics platform receives large volumes of data every 5 minutes from VOS devices. Reports with source IP and destination IP addresses typically take up large amounts of storage and computing resources. You can configure VOS devices to send only the top-N of these types of reports to reduce the number of records sent and processed. However, there can still be a large number of unique records over an hour or a day.

  Statistics rollup provides a mechanism to reduce the volume of stored data by performing aggregation and computing the top-N for the hour and day. Releases 21.2.1 and later support rollup for firewall sources and destination statistics reports. Migration cron jobs are run automatically on the Analytics nodes to migrate existing data to new roll tables.

  Note that after you upgrade to Release 21.2.1 or later, you may not be able to display historical firewall source and destination statistics reports until the migration task is complete. This may take a few hours to a few days, depending on size of the existing tables.

• Synchronized charts for path status—A new synchronized chart option displays multiple time-series charts for SD-WAN path status for charts containing the same zoom level and time range. This helps in visualizing various metrics of the paths at the same time.

  To view a synchronized chart, choose a from site and to site under the Analytics > Dashboards > SD-WAN > Paths> Usage tab as shown below. Metrics for all paths between the branches are displayed.

  
   
• Syslog priority values in remote templates—(For Releases 21.2.3 and later.) For remote templates, you can configure a syslog priority value. For remote template for logging to third-party collectors, set the priority type value as follows:
  
  
   
• System anomalies report—You can display VOS device anomalies under Analytics > Dashboard > System> Appliance Anomalies. The appliance anomalies are:
  • CPU load exceeded
  • Memory load exceeded
  • Packet buffer depletion (running out of mbufs)
  • Session load exceeded
  • Service load exceeded
  • Worker thread busy (LCORE detection)

Drill down to display charts showing each of the anomalies over time.

The log corresponding to these reports is as follows:

2021-03-03T17:55:03+0000 systemHealthLog, applianceName=HE-DC-Branch-1, tenantName=Corp-Inline-Provider, 
generateTime=1614794100, duration=300000, applianceId=0, vsnId=0, tenantId=2, numLcoreInactivity=0, 
numMbufDepletions=0, numSvcLoadExceeded=16, numSessLoadExceeded=0, numCpuLoadExceeded=0, 
numMemLoadExceeded=0

A system health log is exported from each appliance every 5 minutes to Analytics. These logs are exported in provider organization (appliance owner) context on multitenant branches.

• Tenant usage reports—(For Releases 21.2.3 and later.) At the tenant level, you can aggregate the statistics of individual appliances for a number of reports. Analytics provides report templates for the Tenant Usage for SD-WAN and Tenant Usage for DIA report types.
  
  
   
• Threshold-based reporting—In releases prior to Release 21.2, the Analytics reporting tool provides metrics as summaries, time series, and tables. In Releases 21.2.1 and later, you can filter based on conditions that you set per report type. Some of the examples are usage reports if bandwidth exceeds certain threshold, sites or links with low availability, and sites whose violations exceed a limit. The following screen displays an example of SD-WAN access circuit usage across all sites of a tenant with session count exceeding a certain value:

  
  
  
  The following screen displays an example of a conditional report for sites with low availability:
  
  

• TWAMP reports—The Two-Way Active Measurement Protocol, defined in RFC 5357, is used to measure metrics such as delay, delay variation, and loss between two IP endpoints that support the TWAMP sender and receiver functionality. The metrics are exported to Analytics nodes. The Analytics > Dashboard > System > Measurements screen displays the TWAMP metrics per IP session for a tenant or VOS device.
  
  

  The following metrics are collected:

  • Received and transmitted packets
  • Received and transmitted packet errors
  • Two-way delay, forward delay, and reverse delay
  • Two-way delay variation, forward delay variation, and reverse delay variation

Drill down to display metrics over time:

The logs corresponding to these reports are as follows:

2021-03-03T16:22:53+0000 twampSenderSessLog, applianceName=Branch1, tenantName=ServiceProvider, 
twampSrc=70.0.1.2:50000, twampDst=70.0.2.2:50000, twampVRF=ISP-A-Transport-VR, twampDSCP=32, tenantId=6, v
snId=0, applianceId=1, twampPktSz=false|27, twampNumPkts=100000, twampNumPktLoss=0, twampNumTx=6488, 
twampNumRx=6488, twampNumTxErr=0, twampNumRxErr=1, twampFwdDelay=2307|17|80952, twampRevDelay=2390|376|31616, 
twamp2WayDelay=4699|417|92210, twampFwdDelayVar=2270|0|80914, twampRevDelayVar=2009|0|31240, 
twamp2WayDelayVar=4269|0|91793, twampStartTime=1614735029, twampEndTime=1614788573

• WiFi statistics—You can find WiFi reports under Analytics >Dashboard> System > Interfaces. For a multitenant device, these reports are part of the provider organization (appliance owner organization). The main dashboard of the WiFi Interfaces tab displays the devices and the connected clients for the specified time range.
  
  
  
  To display information about all the clients connected to the VOS device, drill down on the VOS device:
  
  
  
  To display information about client traffic usage and signal strength, drill down on a client in the grid:
  
  
  

  The logs corresponding to these reports are as follows:

2021-03-04T00:05:11+0000 wifiClientStatsLog, applianceName=CSG355-Qual, tenantName=Provider-Org, 
generateTime=1614816300, tenantId=2, vsnId=0, applianceId=0, interfaceName=vni-0/201, 
macAddr=9e:23:65:d5:0b:69, ipAddr=192.168.101.4, hostname=iPhone, ssid=Adv-5G2, band=2.437 GHz, 
recvdOctets=268001, sentOctets=20430475, duration=300000, uptime=299, rssi=-34, snr=6

Fixed Bugs

The following are the critical and major defects fixed in Release 21.2.

Behavior Changes

The following are the behavior changes in Release 21.2:

• Starting with Release 21.2.x, the Analytics software checks the the number of Apache ZooKeeper servers in the vansetup.conf script before running the script. (ZooKeeper performs internode communication among the nodes in an Analytics cluster.) If the number is even, the Analytics software changes it to an odd number. Using an odd number of ZooKeeper servers instead of an even number optimizes the internode communication. For example, if the vansetup.conf script has four ZooKeeper servers, the Analytics software changes the number to three. For the changed configuration to take effect, you must execute the vansetup.py script on each Analytics node.

Known Issues

The following are the known issues in Release 21.2.

Request Technical Support

To request technical support, visit http://support.versa-networks.com. If you are contacting support for the first time, register and create an account. You can also send email to support@versa-networks.com or contact your Versa Networks sales account team.

Revision History

Revision 1—Release 21.2.1, March 19, 2021
Revision 2—Release 21.2.2, September 12, 2021
Revision 3—Release 21.2.3, August 2, 2022