Versa Operating System (VOS) Release Notes for Release 21.1

Licenses and Entitlement

• Subscription lifecycle updates—(In Releases 21.1.1 and later.) A number of changes have been made to the subscription lifecycle, including the following. See Subscription Lifecyle.
  • Licenses are valid for 1, 3, or 5 years.
  • License subscriptions do not support the Created and Suspended states
  • A license is immediately activated after the device performs ZTP.
  • Manual license activation is not required.

Platform

• ADSL2+/VDSL2 NIC modules—(In Releases 21.1.1 and later.) You can use ADSL2+/VDSL2 NIC modules, also called xDSL NIC modules, in Versa Cloud Services Gateway (CSG) appliances. The CSG ADSL2+/VDSL2 NIC module supports a single WAN interface that allows you to connect to VDSL2 and ADSL2+ networks. See Configure Interfaces.
• AWS transit gateway integration—(In Releases 21.1.1 and later.) Versa Director automates the process of configuring AWS transit gateway tunnels with on-premise branches. You can configure both the transit gateway and the VOS branches from Versa Director. See Configure Site-to-Site Tunnels.
• Configuration validation—(In Releases 21.1.1 and later.) The configuration validation feature provides a cross-check and misconfiguration-highlighting mechanism for deployments that include an interchassis HA pair (active-standby stateful HA). When enabled, it cross-verifies interchassis HA-relevant configuration changes on both interchassis HA pairs and highlights if there are any differences between the two that affect the runtime function of a given inter-chassis HA branch deployment. It also allows the configuration to be changed on the active and standby devices in any order, and prevents the services from being impacted by a misconfiguration.
• CSG300 series appliances—(In Releases 21.1.1 and later.) The Versa Cloud Services Gateway (CSG) 300 series appliances deliver highly secure site-to-site data connectivity to small businesses and to home offices. See Cloud Services Gateway 300 Series.
• Device template workflow enhancements—(In Releases 21.1.1 and later.) Adds support for the Solution Add-On Tier and License Period fields in the Create Template > Basic tab; Switching tab (for Layer 2 interfaces) in the Create Template window; and, Service Bandwidth and License Period fields in the Add Device window > Basic tab. See Configure Basic Features.
• Encrypt sensitive information—(In Releases 21.1.1 and later.) Versa Director encrypts all sensitive information in configurations before pushing them to VOS devices. See Commit Template Modifications.
• Global session logging control updates—(In Releases 21.1.1 and later.) Changes have been made to the allowable range and adds default values for the Firewall Source IP Count and Destination IP Count fields, and for the SD-WAN Application User Count field. See Configure Firewall and SD-WAN Usage Monitoring Controls.
• IP SLA monitoring enhancement—(In Releases 21.1.1 and later.) You can select a forwarding class to override the default forwarding class for an IP SLA monitor. See Configure IP SLA Monitor Objects.
• Layer 2 forwarding—You can configure Layer 2 forwarding, including virtual switches, bridge domains, bridge interfaces, integrated routing and bridging (IRB) interfaces, media access control (MAC) functions, and STP/RSTP. See Configure Layer 2 Forwarding.
• Layer 2 forwarding additions and enhancements—(In Releases 21.1.1 and later.) Release 21.1.1 adds support for the following Layer 2 features and enhancements. See Configure Layer 2 Forwarding.
  • EVPN over SD-WAN
  • Multiple Spanning-Tree Protocol (MSTP)
  • VLAN Translation
  • Enhanced support for MAC-related features, such as MAC aging, MAC learning, MAC move, and MAC limit.
  • Introduces different ways of determining the state of an IRB.
  • Support for configuring paired TVI interfaces (paired-tvi) as family bridge interfaces
• LLDP—(In Releases 21.1.1 and later.) The Link Layer Discovery Protocol (LLDP) allows network devices to discover a neighbor device’s identity and capabilities on a LAN using a set of attributes, as defined in IEEE 802.1AB. See Configure LLDP.
• Log export functionality (LEF) enhancements—You can reduce the number of firewall and SD-WAN statistics log records that CPE devices export, exporting logs only for the busiest sessions. See Configure Firewall and SD-WAN Usage Monitoring Controls.
• Match alarm subtypes in exporter rules—(In Releases 21.1.1 and later.) You can match alarm subtypes in exporter rules. See Configure VOS Device Alarms.
• Multiple tenants and multiple VRFs in a service chain template—(In Releases 21.1.1 and later.) You can configure multiple tenants and multiple VRFs in a service chain template. See Configure uCPE on a VOS Device.
• Secure option with the Versa Analytics cluster installation script—(In Releases 21.1.1 and later.) You can use the secure option when running the Versa Analytics cluster installation script. See Perform Initial Software Configuration.
• Service-chain template enhancement—(In Releases 21.1.1 and later.) You can service-chain multiple tenants and multiple VRFs. See Configure uCPE on a VOS Device.
• SFP monitoring and management—(In Releases 21.1.1 and later.) VOS devices support digital diagnostics monitoring (DDM) monitoring and management capabilities for SFP and SFP+ interfaces. DDM provides information about the line, signal strength (optical input and output power levels), temperature, laser bias current, transceiver supply voltage, and other transceiver statistics in real time. Monitoring and management capabilities for Versa-certified SFP and SFP+ transceivers are built in. See Monitor the SFP Module.
• Signature verification for software package uploads—(In Releases 21.1.1 and later.) You can use digital signature verification to verify Versa Director and VOS software packages that are uploaded using a Director node. See Configure Signature Verification for Software Package Uploads.
• T1/E1 NIC module—(In Releases 21.1.1 and later.) 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. See Configure Interfaces.
• TPM 2.0—(In Releases 21.1.1 and later.) VOS devices support TPM 2.0 on Ubuntu 18.04 running on CSG and certified whitebox platforms. TPM 2.0 is enabled by default.
• WAN propagation—(In Releases 21.1.1 and later.) You can automatically copy the WAN networks of a parent organization and propagate them to the suborganizations under the parent. See Configure Transport Domains and WAN Networks.
• Zscaler site-to-site tunnels—(In Releases 21.1.1 and later.) You can create secure IPsec and GRE tunnels between a VOS CPE device and a device hosted by Zscaler to optimize the connectivity between the VOS device and cloud peer devices. See Configure Site-to-Site Tunnels.

SD-WAN

• DIA and DCA (SaaS) traffic optimization—VOS devices support ICMP monitor probes to track next hops for a given SaaS application, and they now also support TCP and HTTP monitor probes. TCP and HTTP monitor probes are often more reliable probes for determining the optimal path for internet traffic. See Configure SaaS Application Monitoring.
• NetBox IP address management (IPAM) service—(In Releases 21.1.1 and later.) Versa Director uses the NetBox IP address management (IPAM) service to allocate the IP addresses from the configured overlay prefixes. See Configure the Overlay Addressing Scheme.

• SaaS application detection using endpoints—For SD-WAN edge devices, detecting applications starting with the first packet is critical for optimum path selection. If an application is not known with the first packet and a non-optimal path is selected for the TCP session, the session's performance will be degraded. In earlier software releases, the VOS software used an application cache to cache the application detected for a session associated with a specific IP address and port. However, the application cache cannot assist the first session to a given destination. Because SaaS vendors are now using many IP addresses to serve applications, this limitation has become an issue. The first-packet identification feature addresses this limitation. It allows the SaaS application to be identified starting with the first packet of a session. First-packet identification is also used to identify applications that are making DNS requests, which means that DNS requests can use the same WAN path selection as data sessions.
  
  The first-packet identification feature performs WAN path selection for specific applications, both for the DNS sessions and the data sessions, and it allows users to configure firewall rules to create allow lists of SaaS applications using the published IP prefixes and domain names.
  
  Several SaaS providers publish the IP prefixes and domain name patterns for their service endpoints, and these lists are available to VOS devices so that they can identify applications on the first packet. The latest application endpoint information is updated in Versa Security Package (SPack) updates. VOS devices map the IP prefixes and domain names to the predefined applications for the SaaS application. For example, Microsoft Office 365 endpoints are mapped to the application OFFICE365. The applications are the same predefined applications that you use to configure policies (for example, Office 365 and Zoom), so you do not need to modify the policy configuration. The following are examples of endpoint information published by SaaS providers:
  
  • Microsoft Office 365—https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges
  • Zoom—https://support.zoom.us/hc/en-us/articles/201362683-Network-Firewall-or-Proxy-Server-Settings-for-Zoom
  
  SaaS application detection using endpoints includes the following features:
  • Identify applications for DNS requests and data sessions—For DNS sessions, the database containing the published domain names is used to resolve the domain name and published IP prefixes are used to identify the application for data sessions. Note that the applications that are identified are the same predefined applications that you use when configuring policies. For example, the published Microsoft published Office365 endpoints include the following: outlook.office.com, outlook.office365.com, and 13.107.6.152/31, 13.107.18.10/31, and 13.107.128.0/22 (and more) with TCP ports 80 and 443. Using this information, a DNS request for outlook.office365.com and a TCP session destined to 13.107.128.1 is mapped to the application OFFICE365.
  • WAN path selection—To select a WAN path for applications, you need to configure SD-WAN policy rules. Because both the DNS requests and the data sessions are mapped to the same applications (on the first packet of session) using the published endpoint information, they both receive the same path selection treatment. To use path selection for DNS requests, you must enable DNS proxy on the VOS device.
  • Allow lists for applications using endpoint information—You can create allow lists (sometimes called whitelists) for the SaaS applications using the predefined applications. Identifying applications on the first packet of the session helps to finalize the firewall policy to use for the session without waiting for the application to be detected by deep-packet inspection. In the application for which application identification is to be finalized (for the purpose of firewall policy) based on the published endpoint-based match, the application-specific app-final-with-endpoint option must be set to TRUE.
• SaaS endpoint definitions in SPacks—(In Releases 21.1.1 and later.) VOS devices 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. See Use Security Packages.
• SD-WAN traffic-steering forwarding profile enhancements—(In Releases 21.1.1 and later.) SD-WAN forwarding profiles are enhanced to support circuit tag–based path priorities and path list–based path priorities (path-name-list, path-type-list, path-media-list and path-tags-list), last-resort priority, and unmatched-priority.
  • Circuit tags—You can label each SD-WAN interface with up to four circuit tags, which are user-defined free-form strings. You can use circuit tags, just as you do circuit names and circuit media, as match conditions in forwarding profiles in order to define path priorities.
  • Path list–based path priorities—You can define priorities using an exact match for local and remote circuits, which removes the ambiguity in grammar around when to use AND versus OR in match conditions. The new path list–based priorities and the existing circuit priorities model are mutually exclusive at a specific priority level. That is, if you select path list–based priorities, the current circuit priorities model is not allowed, and vice versa. However, you can select both types of priority levels at different priority levels.
  • Last-resort priority—Paths that you configure with this priority are used when all other paths go down, thus allowing you not to use LTE paths when other paths are available.
  • Unmatched priority—You can define the priority of the paths that are not configured explicitly. For example, if the unmatched priority is set to priority 2, any path that is not configured in the forwarding profile is considered as priority 2.
    See Configure SD-WAN Traffic Steering.
• TCP optimizations—TCP optimizations mitigate the effects of high latency and packet loss on the performance of TCP-based applications. In Releases 21.1.1 and later, the maximum send and receive buffer sizes are increased from 8M to 16M, and you can configure forward proxy and reverse proxy TCP optimization modes.See Configure TCP Optimizations.

Security

• Caching of the URL filtering history—(In Releases 21.1.1 and later.) You can configure the caching of the URL filtering history. See Configure URL Filtering.
• FIPS 140-2 Level 1 compliance—(In Releases 21.1.1 and later.) You can run VOS devices in FIPS mode in VOS images that are FIPS 140-2 Level 1 compliant. FIPS 140-2 Level 1 compliance covers production-grade and externally tested encryption algorithms. See FIPS Compliance.
• Microsoft NDES and SCEP network access control—A VOS device can use certificate-based network device authentication and certificate management using Microsoft Network Device Enrollment Service (NDES), which is based on Simple Certificate Enrollment Protocol (SCEP) and which provides certificate-based network device authentication and certificate management. See Configure Certificate Servers.
• Remote access server (RAS) support—A VOS device can act as a remote server, allowing remote users to connect to the VOS device by establishing a VPN connection. See Configure the Versa Secure Access Service.
• TLS/SSL for remote collectors—Transport Layer Security (TLS) has been added to the existing connection mechanisms (TCP and UDP) to enable you to stream logs securely. See Configure Log Collectors and Log Exporter Rules.
• URL filtering enhancement—(In Releases 21.1.1 and later.) You can enable or disable the caching of the URL filtering history. See Configure URL Filtering.
• Versa Secure Access Service—(In Releases 21.1.1 and later.) Versa Secure Access Client for Windows 10 and MacOS, which are installed on end devices, Versa Secure Access Server functionality developed on Versa OS. See Configure the Versa Secure Access Service.

Fixed Bugs in Release 21.1

Fixed Bugs in Release 21.1.1

Fixed Bugs in Release 21.1.2

show route multicast-rpf {{ipv4_addr | ipv4_prefix} | 
routing-instance name {ipv4_addr | ipv4_prefix}}

Fixed Bugs in Release 21.1.3

Fixed Bugs in Release 21.1.4

Limitations and Behavior Changes in Release 21.1

• TCP optimization is designed for WANs with bottleneck bandwidth up to 300 Mbps that also experience high latency (> 50 ms) and some degree of packet loss. Using TCP optimization in other environments, such as low-latency networks or in networks with high latency but no packet loss, may be counterproductive and may instead decrease performance.
• With TCP optimization, peer discovery, or automode, is currently limited to an SD-WAN network, even though the optimization is designed to also work on Versa appliances in a non SD-WAN network.
• On Windows remote access clients connecting to a VOS RAS server, you must add static routes for remote access. Routes are not automatically installed on the Windows RAC client when it connects to the VOS RAS server.
• A VOS device does not configure a RAC client with the DNS server address. You must manually configure it on the Windows RAC client.
• You cannot configure IRB as an inter-HA link.
• The maximum number of IRB interfaces is 64.
• For bridging, you must configure Layer 2 interfaces in promiscuous mode.
• Versa Director monitor screens are not available for Layer 2 show commands.
• Class of service (CoS) and access lists are not supported for Layer 2.
• IRB interfaces support family inet only. These interfaces currently do not support IPv6.
• You should ensure that the Layer 2 interface MTU matches the IRB interface MTU to avoid any packet drops caused by MTU mismatch.
• Previously, by default, FEC sent the parity on the same link and the duplicate parity on an alternate link.This has changed. Now, the parity packet is sent on alternate link and the duplicate parity packet is disabled. This was done to reduce the overhead on already congested lists. You can enable the duplicate parity packet through configuration.
• In Releases 20.2 and later, the BGP AS path loop check behavior has been changed to prevent BGP routes that contain the local AS number of the BGP instance from being installed even when they are received from IBGP peers. (In software releases prior to Release 20.2, an AS loop check was performed only for routes received from EBGP peers). This change was made to comply with RFC 4271, to prevent loops in all cases. When you upgrade a VOS devices from Release 16.1R2 to Release 21.1, if the VOS device is configured the overlay AS number in the BGP AS path to the Controller node, the Controller node no longer installs these routes and therefore does not propagate the routes to other branches. As a result, you might encounter one the following situations:
  • The local AS number configured in the branch VRF BGP group or neighbor may be same as the overlay control VR. If so, do one of the following as part of upgrade:
    • Ensure that the local AS number configured for the group or neighbor in the VRF is different from the overlay BGP AS number in the control VR. If the AS numbers are different, the controller node does not receive its own overlay AS number in the AS path, and the route is installed.
    • Check whether the default local AS mode to mode-2, which adds the configured local AS in the BGP group or neighbor level to the AS path when the route is imported. If so, change the mode to mode-4, which does not add the AS number to the AS path. As a result, this route passes the AS loop check on the Controller node and is installed.
    • Configure the loops ;option in the BGP group corresponding to the branches in the Controller’s control VR as well as in the control VR in the branches. This option allows routes with as many loops as specified in the configuration to be installed.
  • The AS path received from the BGP peers in the VRF may already contain the overlay AS number. If so, do one of the following as part of upgrade:
    • Ensure that the customer network does not use the overlay BGP AS number in the control VR, with the result that the controller will not receive its own overlay AS number in the AS path and the route will be installed.
    • Configure the loops option in the BGP group corresponding to the branches in the Controller’s control VR as well as in the control VR in the branches. This option allows routes with as many loops as specified in the configuration to be installed.
• In Releases 20.2.3 and earlier, when BGP detects that a neighbor is going down, the Controller nodes reruns the best path selection for Layer 3 VPN routes, selects an alternate route from another active neighbor, and announces the route to other BGP route-reflector clients so that they can use the new route. In Release 20.2.4 and Releases 21.2.2, and later, the Controller node reruns the best path selection only for Versa private routes. This means that a stale Layer 3 VPN route from the neighbor that has gone down still remains as the best path, and subsequent best path selection for Layer 3 VPN routes occurs only if the Controller node receives an update for the route. This behavior change can cause issues when route distinguisher (RD) values are the same on different VOS devices and they are advertising the same route for the purpose of redundancy or failover. It is recommended that the route distinguisher values for a tenant LAN virtual router (tenant-LAN-VR) be unique for each VOS device so that the Controller node can reflect the same route received from multiple clients, ensuring faster failover if a client that is sending the best route fails. In Releases 21.x, during the workflow deployment, the Director node generates unique route distinguisher values for each VOS device, in the format global-vrf-idL:site-id, for both standalone and HA deployments. In Releases 20.2.3 and earlier, the route distinguisher values were not unique for standalone VOS devices.

Limitations and Behavior Changes in Release 21.1.1

• Starting with Release 20.2.x, VOS software requires the underlying Intel CPU to have RDRAND capability. To check the CPU's capability, issue the following command:

# cat /proc/cpuinfo | grep rdrand

• When you change the maximum number of tenants, you must commit the change separately, and a service restart occurs. After the restart, make any other configuration changes.
• Whenever you configure a SD-WAN or policy-based forwarding (PBF) rule to override routing (by enforcing a next hop), you must configure a source zone in addition to other match criteria in the rule in order to prevent traffic not intended for the rule from matching it inadvertently. An example of this is when you use an SD-WAN or PBF policy rule for application-based DIA. This requires a rule to identify traffic originating from the LAN (typically, some Intf-<>-LAN-zone), and then using the rule to send the traffic into the required transport VR, where a second session gets created. CGNAT rules are used to source-NAT this traffic. If the source zone is omitted in the SD-WAN/PBF rule's match condition, the second session also matches it and causes a packet loop. By adding the source zone Intf-<>-LAN-zone as a match condition, you prevent the second session from matching the PBF rule.

Limitations and Behavior Changes in Release 21.1.2

• When you change the maximum number of tenants, you must commit the change separately, and a service restart occurs. After the restart, make any other configuration changes.
• When you configure an SD-WAN or a policy-based forwarding (PBF) rule to override routing (by enforcing a next hop), you must configure a source zone in addition to other match criteria in the rule, to prevent traffic not intended for the rule from matching it inadvertently. An example of this is when you use an SD-WAN or a PBF policy rule for application-based DIA. This requires a rule to identify traffic originating from the LAN (typically, some Intf-<>-LAN-zone), and then using the rule to send the traffic into the required transport VR, where a second session gets created. CGNAT rules are used to source-NAT this traffic. If you omit the source zone n the SD-WAN/PBF rule's match condition, the second session also matches it and causes a packet loop. By adding the source zone Intf-<>-LAN-zone as a match condition, you prevent the second session from matching the PBF rule.
• For the DHCP server to provide an IP address, there must be at least one matching rule in the DHCP service profile. In earlier releases, DHCP provided an IP address even when there were no matching rules.

Limitations and Behavior Changes in Release 21.1.3

• When you change the maximum number of tenants, you must commit the change separately, and a service restart occurs. After the restart, make any other configuration changes.
• Whenever you configure an SD-WAN or a policy-based forwarding (PBF) rule to override routing (by enforcing a next hop), you must configure a source zone in addition to other match criteria in the rule in order to prevent traffic not intended for the rule from matching it inadvertently. An example of this is when you use an SD-WAN or PBF policy rule for application-based DIA. This requires a rule to identify traffic originating from the LAN (typically, some Intf-<>-LAN-zone), and then using the rule to send the traffic into the required transport VR, where a second session gets created. CGNAT rules are used to source-NAT this traffic. If the source zone is omitted in the SD-WAN/PBF rule's match condition, the second session also matches it and causes a packet loop. By adding the source zone Intf-<>-LAN-zone as a match condition, you prevent the second session from matching the PBF rule.

Known Issues in Release 21.1

Known Issues in Release 21.1.1

• In multicast routing, when you enable the Anycast-RP mechanism on a first-hop router, the source information is not shared between Anycast-RP peers through PIM register packets. As a workaround, ensure that you do not enable the Anycast-RP mechanism on a first-hop router.
• If a VOS node is a part of interchassis HA pair (for active-standby stateful HA), you must first upgrade it to Release 16.1R2S11 before you upgrade it to Release 21.1.1. If the interchassis HA pair is running Release 16.1R2S9 or later, you must increase the HA probe miss threshold to 3600 seconds during the upgrade. If the interchassis HA pair is running Release 16.1R2S8 or earlier, you must set the probe type to none on both the nodes before performing the upgrade. Otherwise, the standby device restarts continuously after the upgrade. After the upgrade, you can return the HA probe miss threshold value to the originally configured value. To upgrade an interchassis HA pair from Release 20.2.2 to Release 21.1.1, it is recommended that you first upgrade the VOS device from Releases 20.2.2 to Release 20.2.3 and then upgrade to Release 21.1.1.
• Device identification may not fully identify all end devices in the network. It is recommended that you use this feature only in labs, POCs, and trials.
• A tenant-based traffic shaper expects the shaper on the physical interface to be configured on the provider organization. If this is not the case, you must perform the commit in two steps. First, delete the shaping configuration from the non-provider organization, and commit the configuration. Then, configure the shaping, and commit the configuration. You can, for instance, configure the shaper on the provider organization and the provider limit on the customer organization. This limitation applies only to multitenant CPE or hub VOS instances.
• If you want to upgrade a VOS device on which uCPE is enabled (hypervisor installed) from Release 16.1R2 to Release 21.1.1, contact Versa Network Customer Support. Also see https://support.versa-networks.com/a...es/23000021050
• If you enable information validation on a stateful HA branch deployment, and if there is a long delay in bringing up interfaces in the global VRF, the information validation client may fail to register with information validation server on the peer VNF. As a workaround, restart the versa-vmod service alone on the affected VOS device.
• The rollback x command might not work properly.
• The show commit changes x command might not show the actual CLI changes.

Known Issues in Release 21.1.2

• Device identification may not be able to fully identify all end devices in the network. It is recommended that you use this feature only in the lab, POCs, and trials.
• In multicast routing, the source information is not shared between anycast-RP peers through PIM register packets when you enable the anycast-RP mechanism on a first-hop router. As a workaround, do not enable anycast-RP on a first-hop router.
• If a VOS node is part of an inter-chassis HA pair (active-standby Stateful HA), you must first upgrade it to Release 16.1R2S11 before upgrading to Release 21.1.2. When an interchassis HA pair is running Release 16.1R2S9 or later, you must set the probe-type to none on both the nodes before the upgrade. Otherwise, the standby device continuously restarts after the upgrade. After the upgrade, you can revert the HA probe-type value to the originally configured value.
  To upgrade an interchassis HA pair from Release 20.2.2 to 21.1.2, it is recommended that you upgrade VOS from Release 20.2.2 to Release 20.2.3, and then upgrade to Release 21.1.2.
• A tenant-based traffic shaper expects the shaper on the physical interface to be configured on the provider organization. If this is not the case, you need to perform the commit in two steps. First, delete the shaping configuration from the non-provider organization and commit the configuration. The second commit could have the shaper configured on the provider organization and provider-limit configured on the customer organization. This limitation only applies to multitenant CPE or hub VOS instances.
• You cannot upgrade a VOS device on which uCPE enabled (hypervisor installed) from Release 16.1R2 to Release 21.1.2. Please contact the support team if you are considering the upgrade. For more information, see https://support.versa-networks.com/a/solutions/articles/23000021050
• When you enable the info-validation feature in a stateful HA branch deployment, a huge delay might occur in bringing up of interfaces in the global VRF, and the info-validation client may fail to register with the info-validation server on the peer VNF. As a workaround, restart only the versa-vmod service on the affected VOS device.
• If you configure an SLA profile at the next-hop level in conjunction with configuration application monitors, the SLA profile options to select a path based on the lowest latency and on the lowest packet loss are ignored. To utilize these best-path selection features, configure the SLA profile at the global level.

Known Issues in Release 21.1.3

• Device identification may not be able to fully identify all end devices in the network. It is recommended that you use this feature only in the lab, POCs, and trials.
• In multicast routing, when you enable the anycast-RP mechanism on a first-hop router, the source information is not shared between anycast-RP peers through PIM register packets. As a workaround, do not enable anycast-RP on a first-hop router.
• If a VOS device is part of an interchassis HA pair (active-standby stateful HA), you must first upgrade it to Release 16.1R2S11 before upgrading to Release 21.1.3. When an interchassiss HA pair is running Release 16.1R2S9 or later, you must set the probe type to none on both the nodes before the upgrade. Otherwise, the standby device continuously restarts after the upgrade. After the upgrade, you can return the HA probe-type value to the originally configured value. To upgrade an interchassis HA pair from Release 20.2.2 to 21.1.3, it is recommended that you upgrade VOS from Release 20.2.2 to Release 20.2.3, and then upgrade to Release 21.1.3.
• A tenant-based traffic shaper expects the shaper on the physical interface to be configured on the provider organization. If this is not the case, you need to perform the commit in two steps. First, delete the shaping configuration from the non-provider organization and commit the configuration. The second commit could have the shaper configured on the provider organization and provider-limit configured on the customer organization. This limitation applies only to multitenant CPE devices or hub VOS instances.
• You cannot upgrade a VOS device on which uCPE enabled (hypervisor installed) from Release 16.1R2 to Release 21.1.3. Please contact the support team if you are considering the upgrade.
  https://support.versa-networks.com/a/solutions/articles/23000021050
• When you enable info-validation in a stateful HA branch deployment, a large delay might occur in bringing up interfaces in the global VRF, and the info-validation client may fail to register with the info-validation server on the peer VNF. As a workaround, restart only the versa-vmod service on the affected VOS device.