Install and Configure VMS

VMS and Versa Headend Components

You can configure VMS with the following Versa headend components:

• Versa Director or Concerto—From Versa Director or Concerto, you configure user, tenant, and group orchestration.
• Versa Controller—You configure a Versa Controller to connect to VOS devices over IPsec tunnels, and you create an application delivery controller (ADC) to connect to Versa Analytics.
• Versa Analytics nodes—You configure these for logging and analytics services.

VMS can interact with the following components:

• Versa headend—VMS connects with other Versa headend components through the management plane. Over the management plane, VMS receives the configurations for tenants and services, and the configurations for connecting to and communicating with other Versa headend components through Versa Director. To configure communication between VMS and Versa Director, you configure a VMS cluster in the Director connector to establish communication between VMS and the Director node.
• External sources and agents—The VMS elastic interface interacts with external sources and agents, including AAA servers, Kafka, Panorama, and the Versa WMI agent for Active Directory (AD), to receive data.
• VOS devices—VOS devices establish long-term communication with VMS to send and receive streamed data. It is recommended that you stream logs from VOS devices to VMS using SD-WAN.

VMS is a component of the Versa headend, as shown in the following figure.

The figure above illustrates the following workflow in VMS:

• Each VOS device subscribes to VMS for a service (for example, SASE for SIM, third-party authentication, or XIP EIP), and sends and receives receives streaming data.
• External components and agents send data or stream logs to VMS.
• VMS processes the streamed data from external sources, converts it to a format for VOS devices, and streams it to the VOS devices that subscribe to a service.
• VMS streams data to subscribed VOS devices and forwards logs and exceptions to Versa Analytics nodes. VMS can also send data or logs to external components.

To configure VMS for Concerto or Director, you do the following:

• Configure a VMS connector on a Director node. For more information, see Configure VMS from Versa Director below.
• Perform tenant onboarding related to VMS from Concerto.
• Configure users and user groups for tenants on Concerto or Director nodes. These configurations then share group, tenant, IMSI (user ID), and solution tier information with VMS.

You configure VMS for Versa Analytics for logs related to entitlement, debugging, and exceptions. Versa Analytics analyzes these logs and events, and generates reports and analytics for events shared by VMS. The following are the types of VMS events:

• Activities—Start–stop events for each IMSI-to-IP address combination
• Exceptions—Errors that occur during data processing for orchestration, accounting, and Kafka

VMS uses a Versa Controller node to connect to a VOS device over an IPsec tunnel and to configure an application delivery controller (ADC) for Analytics. ADC is a component of a VOS device that accepts TCP or UDP connections from a process that initiates a connection. For more information, see Application Delivery Controllers.

VMS Deployment Overview

To deploy VMS, you install it as a node in the control plane. A control plane node is the initial node in a VMS cluster, and it controls the functioning of the VMS cluster and is the initial node in the VMS cluster. You perform the initial VMS configuration on this node, and in the process of configuring VMS< you set up the VMS cluster. The control plane node manages the VMS administration and configuration database, and it sets up the control plane and the software required for VMS deployment. The control plane node also monitor sand maintains the health of the VMS cluster.

This section describes the hardware and interface requirements to deploy a VMS node.

It is recommended that you deploy VMS on physical servers. The following table provides the minimum requirements for a VMS node.

Node Type	Control Plane Node	Worker Node
CPU	32 cores, no-hyperthreading	32 cores
Memory	64 GiB RAM	64 GiB RAM
Disk	256 GiB SSD (IOPS of 600 MBPS in mixed mode)	256 GiB SSD (IOPS of 600 MBPS in mixed mode)
Network interfaces	3	3

When you deploy VMS, it is recommended that you configure the following interfaces and links:

• Management interface for management of internal cluster communication and has one IP address.
• Interface that connects to external agents that has two IP addresses:
  • One IP address for external agents such as RADIUS accounting server, Kafka Broker, Kafka Producer, or Kafka Consumer Topic to communicate with VMS.
  • The second address is an elastic or floating IP address and is assigned to a cluster for connectivity to Versa Director and for AAA proxy servers.
• Interface for connectivity to VOS devices

To deploy VMS, you do the following:

1. Install the VMS software on a bare-metal platform. See Install VMS, below.
2. Perform initial configuration of VMS from the shell of the bare-metal platform. See Configure a VMS Server Using the CLI, below.
3. Configure VMS from Versa Director. See Configure VMS from Versa Director, below. 
4. Configure a VMS server profile for a VOS device to communicate with the VMS server. You can then enable VMS services to send or receive stream feeds. See Configure VMS Messaging Service, below
5. Repeat Steps 3 and 4 for each service that you want to enable for a tenant. 

Install VMS

To install the VMS software, you install the VMS ISO image on a bare-metal platform. The VMS image can be an AMI, an ISO, and OVA, or a QCOW2 image.

The figures in this section show VMS software installation on a Supermicro server. The screens may differ based on the server you use. 

To access the bare-metal platform remotely, configure intelligent platform management interface (IPMI) on the bare-metal server.

To install the VMS software:

1. Log in to the remote console.
   
   
2. Click anywhere in the Remote Console Preview window to launch the remote console. If the Java SE Development Kit is installed on the server, you can launch the remote console from the development kit.
   
   
3. In the Virtual Media tab, click Virtual Storage.
   
   
4. In the Virtual Storage window, select the CDROM & ISO tab. The Settings for Device2 window displays.
   
   
   1. In the Logical Drive Type field, select ISO File.
   2. Click Open Image and type the full path name of the software image. You can find the image at https://versanetworks.app.box.com/s/d7jh1z6y3kaijd3yfwil0uxchr1w9ton/folder/256571398920
   3. Click Plug In.
   4. Click OK.
5. Select the Power Control tab.
   
   
   1. Click Set Power Off to power down the device.
   2. Click Set Power On to restart the device.
6. After the device restarts, the remote console window displays the server banner.
   
   
7. To perform device setup, press the Delete key.
8. In the Setup Utility window, select the Save and Exit tab.
   
   
9. Click IPMI Virtual CDROM 3000 to run the ISO file from a local partition.
10. Press Enter.
11. Install the ISO image, and then configure the primary IP address and hostname. For example:

    [admin@versa-Msgservice: -] $ sudo vi /etc network/interfaces
    [sudo] password for admin:
    [admin@versa-msgservice: -] $ sudo vi /etc/hosts
    host.conf hostname hosts hosts.allow hosts.deny
    [admin@versa-msgservice: -] $ sudo vi /etc/hosts
    [admin@versa-msgservice: -] $ sudo vi /etc/hostname
    sudo: unable to resolve host versa-msgservice: Resource temporarily unavailable
    [admin@versa-msgservice: -] $ sudo reboot
    

    
    After the reboot completes, VMS release information, including the version, release date, and package ID display.

12. Check the status of the server by issuing the vsh status CLI command. Note that the command output may show that the status of Kubelet as inactive. For example:

================================================================================
Versa Package Info: versa-msgservice-20240412-090117-d203801-5.1.1
================================================================================
Info: SYSTEM-SERVICES-STATUS
kubelet:activating
docker:active (3945)
vms-admin:inactive
vms-db:inactive

Configure a VMS Server Using the CLI

To configure the VMS server, you do the following:

• Configure interfaces and a hostname on the VMS node.
• Generate self-signed certificates.
• Perform the initial VMS configuration, which  installs the Kubernetes control plane, creates a Docker overlay, and loads containers.
• Regenerate certificates.

You perform the initial configuration from the shell of the VMS server.

To configure VMS server:

1. Issue the sudo vi /etc/network/interfaces CLI command to configure interfaces  (here eth0 and eth1) and hostname. For example:

   [admin@versa-msgservice: ~] $ sudo vi /etc/network/interfaces
   [sudo] password for admin:
     # interfaces(5) file used by ifup(8) and ifdown(8)
     # Include files from /etc/network/interfaces.d:
     source-directory /etc/network/interfaces.d
     #auto eth0
     iface eth0 inet static
         address 10.40.2.201
         netmask 255.255.0.0
         gateway 10.40.0.1
         dns-nameserver 10.48.0.99
         dns-nameserver 8.8.8.8
         
    # auto eth1
    # iface eth1 inet static
        address 10.43.17.231
        netmask 255.255.0.0
        broadcast 172.17.2.255
        gateway 172.17.9.1

2.  Issue the sudo /opt/versa/vms/certs/vms_cert_gen.sh CLI command to generate self-signed certificates. For example:

   [admin@versa-msgservice: ~] $ sudo /opt/versa/vms/certs/vms_cert_gen.sh
   [sudo] password for admin:
   
   Domain is mandatory
       Usage:
           vms_cert_gen
       Description:
           Generate private key and certificate signing request (CSR) for CA to sign
       Example:
           sudo /opt/versa/vms/certs/vms_cert_gen.sh --domain vms01 --country US --state CA --locality SC
           --organization acme.com --organizationalunit IT --email cert-admin@acme.com --keypass acmetest123
           --validity 3650 --san vms-01.acme.com,DNS.1:vms-01,DNS.2:vms-elastic-fqdn,DNS.3:vms-02,IP.1:10.10.10.10,IP.2:10.10.10.11
       Options:
           -h, --help            Show this help message and exit.
           --domain              <Fully qualified domain name>
           --country             <Country name>
           --state               <State name>
           --locality            <Locality name>
           --organization        <Organization name>
           --organizationalunit  <Organizationalunit Name>
           --email               <email>
           --keypass             <private key password, if you want the private key is encrypted>
           [--validity]          <certificate validity in days>
           [--san]               <Fully qualified domain name for Subject Alt-Name, please refer to example for providing 
                                  multiple values, DNS: DNS name; Each DNS value should not exceed 64 characters> 
                                 Optionally provide IP addresses for SAN

The results display after you generate self-signed certificates. For example:

[admin@versa-msgservice: ~] $ sudo /opt/versa/vms/certs/vms_cert_gen.sh --domain vms-1 --country US --state CA --locality SC 
--organization mvno.com --organizationalunit QA --email admin@mvno.com --keypass versa123 --validity 3650 --organization 
=> Generating Key and CSR for request domain: vms-1, key_pass: versa123
 => Request details: [/emailAddress=admin@mvno.com/C=US/ST=CA/L=SC/O=mvno.com/OU=QA/CN=vms-1]
 => Generating Root Certificate with password encrypted keypass: versa123 and Root Certificate
 => Successfully generated Key file: /opt/versa/vms/certs//root-ca-key.pem
 => Please copy the file out of the system and maintain it
 => Successfully generated ROOT CA file: /opt/versa/vms/certs//root-ca-cert.pem
Generating RSA private key, 4096 bit long modulus (2 primes)
*******************************************************************************************************************************
*******************************************************************************************************************************
e is 65537 (0x010001)
 => Successfully generated Key file: /opt/versa/vms/certs//ca-key.pem
Ignoring -days; not generating a certificate
 => Successfully generated INTERMEDIATE_CSR_FILE: /opt/versa/vms/certs//ca-csr.pem
Using configuration from /opt/versa/vms/certs//openssl.cnf
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 4096 (0x1000)
        Validity
            Not Before: Jun  7 07:57:45 2024 GMT
            Not After : Jun  5 07:57:45 2034 GMT
        Subject:
            countryName               = US
            stateOrProvinceName       = CA
            organizationName          = mvno.com
            organizationalUnitName    = QA
            commonName                = vms-1 Intermediate Cert Authority
            emailAddress              = admin@mvno.com
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                68:D0:EA:73:6E:6A:61:13:0C:1C:42:DF:BC:60:AA:A2:7D:01:65:EB
            X509v3 Authority Key Identifier:
                keyid:51:87:05:2D:EF:E5:C1:0B:08:93:AF:4D:58:E8:94:BF:8D:5F:7F:E7

            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign, CRL Sign
Certificate is to be certified until Jun  5 07:57:45 2034 GMT (3650 days)

Write out database with 1 new entries
Data Base Updated
 => Successfully generated INTERMEDIATE CA file: /opt/versa/vms/certs//ca-cert.pem
 => Successfully verified INTERMEDIATE CA file: /opt/versa/vms/certs//ca-cert.pem
 => Successfully generated the Private CA Chain
 => Please copy the /opt/versa/vms/certs//root-ca-key.pem out of this system and store it safely
 => Please use the Password "versa123" during server and client cert generation for \'vsh configure\'

3. Issue the vsh configure CLI command to install the Kubernetes control plane, create a Docker overlay, and load containers. 
4. For the initial configuration, respond Y to the following prompt, and then enter the IP address that the VMS server uses to connect to VOS  devices. For example:

   Is the primary interface configuration finalized? (y/N) :  Y
   Management Interface IP of this VMS server
   Please Enter this VMS Server Management/Primary Interface IP Address : 10.40.2.201
   

5. Respond Y to the following prompt, and then enter the primary and secondary Versa Director IP address and FQDN or hostname. VMS uses this information to communicate with the Director node and to fetch Director certificates for TLS communication. Note that only a Director that is configured can communicate with VMS. For example:

Is the hostname of this VMS server finalized?  (y/N) :  Y

6. Enter the VMS server IP address. For example:

   FQDN/Hostname of this VMS server
   Is the hostname of this VMS server finalized?  (y/N) :  Y
   Please enter the Hostname of this VMS Server:  vms-1.mvno.com
   This may take up to 10 minutes to complete initialization
   

7. In response to the following prompt, enter Y to complete the configuration. For example:

   Adding new hosts entry.
   VMS server configuration
   Is this the 1st Control Plane Node of the cluster? (y/N) :  y
   ================================================================================
   This may take up to 10 minutes to complete initialization
   ================================================================================
   Info: Installing Kubernetes ...
   Info: Creating auto completions for kubectl
   Info: Disabling Swap ...
   Info: Creating Docker overlay ....
   disabled_plugins = []
   imports = []
   oom_score = 0
   plugin_dir = ""
   required_plugins = []
   root = "/var/lib/containerd"
   state = "/run/containerd"
   temp = ""
   version = 2
   

When the Kubernetes control plane initializes, the success message displays. For example:

[kubelet-start] Starting the kubelet
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests".
This can take up to 4m0s
[apiclient] All control plane components are healthy after 7.014799 seconds
[upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace kubelet] Creating a 
ConfigMap "kubelet-config" in namespace kube-system with the configuration for the kubelets in the cluster 
[upload-certs] Storing the certificates in Secret "kubeadm-certs" in the "kube-system" Namespace
[upload-certs] Using certificate key:
8a93eb6463d2d9d961706b16a229bd1b4330337341cdef2a85765597542e3717
[mark-control-plane] Marking the node vms-1.mvno.com as control-plane by adding the labels: [node-role.kubernetes.io/control-plane node.kubernetes.io/exclude-fr                                                               om-external-load-balancers]
[mark-control-plane] Marking the node vms-1.mvno.com as control-plane by adding the taints [node-role.kubernetes.io/control-plane:NoSchedule]
[bootstrap-token] Using token: mttojz.2pr32kh3x5e4h01j
[bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
[bootstrap-token] Configured RBAC rules to allow Node Bootstrap tokens to get nodes
[bootstrap-token] Configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstrap-token] Configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstrap-token] Configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstrap-token] Creating the "cluster-info" ConfigMap in the "kube-public" namespace
[kubelet-finalize] Updating "/etc/kubernetes/kubelet.conf" to point to a rotatable kubelet client certificate and key [addons] Applied essential addon: CoreDNSaddons] Applied essential addon: kube-proxy

Your Kubernetes control-plane has initialized successfully!
To start using your cluster, you need to run the following as a regular user:
  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config
Alternatively, if you are the root user, you can run:
  export KUBECONFIG=/etc/kubernetes/admin.conf
You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/
You can now join any number of the control-plane node running the following command on each as root:

  kubeadm join vms-1.mvno.com:6443 --token mttojz.2pr32kh3x5e4h01j \
        --discovery-token-ca-cert-hash sha256:10902b525bf71ab2d9ee1c49b27c4c06cb  b4b5cc1ac56bd26633c38f7b8ae805 \
        --control-plane --certificate-key 8a93eb6463d2d9d961706b16a229bd1b4330337341cdef2a85765597542e3717
Please note that the certificate-key gives access to cluster sensitive data, keep it secret!
As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use kubeadm init phase upload-certs --upload-certs" to reload certs afterward.
Then you can join any number of worker nodes by running the following on each as root: kubeadm join vms-1.mvno.com:6443 --token mttojz.2pr32kh3x5e4h01j \
        --discovery-token-ca-cert-hash sha256:10902b525bf71ab2d9ee1c49b27c4c06cbb4b5cc1ac56bd26633c38f7b8ae805
Info: Kube Init successful
Info: Init Flannel
namespace/kube-flannel created
clusterrole.rbac.authorization.k8s.io/flannel created
clusterrolebinding.rbac.authorization.k8s.io/flannel created
serviceaccount/flannel created
configmap/kube-flannel-cfg created
daemonset.apps/kube-flannel-ds created
readOnlyPort: 0
protectKernelDefaults: true

When all resources are allocated, the following information displays and this completes the initial set up and configuration of this VMS node:

Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests    Limits
  --------           --------    ------
  cpu                950m (7%)   0 (0%)
  memory             290Mi (1%)  340Mi (1%)
  ephemeral-storage  0 (0%)      0 (0%)
  hugepages-1Gi      0 (0%)      0 (0%)
  hugepages-2Mi      0 (0%)      0 (0%)
Events:
  Type     Reason                   Age   From             Message
  ----     ------                   ----  ----             -------
  Normal   Starting                 108s  kube-proxy
  Normal   Starting                 2m2s  kubelet          Starting kubelet.
  Warning  InvalidDiskCapacity      2m2s  kubelet          invalid capacity 0 on image filesystem
  Normal   NodeAllocatableEnforced  2m1s  kubelet          Updated Node Allocatable limit across pods
  Normal   NodeHasNoDiskPressure    2m1s  kubelet          Node vms-1.mvno.com status is now: NodeHasNoDiskPressure
  Normal   NodeHasSufficientPID     2m1s  kubelet          Node vms-1.mvno.com status is now: NodeHasSufficientPID
  Normal   NodeHasSufficientMemory  2m1s  kubelet          Node vms-1.mvno.com status is now: NodeHasSufficientMemory
  Normal   Starting                 2m    kubelet          Starting kubelet.
  Warning  InvalidDiskCapacity      2m    kubelet          invalid capacity 0 on image filesystem
  Normal   NodeHasSufficientMemory  119s  kubelet          Node vms-1.mvno.com status is now: NodeHasSufficientMemory
  Normal   NodeHasNoDiskPressure    119s  kubelet          Node vms-1.mvno.com status is now: NodeHasNoDiskPressure
  Normal   NodeHasSufficientPID     119s  kubelet          Node vms-1.mvno.com status is now: NodeHasSufficientPID
  Normal   NodeAllocatableEnforced  119s  kubelet          Updated Node Allocatable limit across pods
  Normal   RegisteredNode           109s  node-controller  Node vms-1.mvno.com event: Registered Node vms-1.mvno.com in Controller
  Normal   NodeReady                98s   kubelet          Node vms-1.mvno.com status is now: NodeReady

Info: Kubernetes component status
Warning: v1 ComponentStatus is deprecated in v1.19+
NAME                 STATUS    MESSAGE   ERROR
scheduler            Healthy   ok
controller-manager   Healthy   ok
etcd-0               Healthy   ok

Info: Kubernetes Cluster Information
Kubernetes control plane is running at https://vms-1.mvno.com:6443
CoreDNS is running at https://vms-1.mvno.com:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
Fri Jun  7 01:45:21 PDT 2024 File /opt/versa/etc/install/initial_install is (re-)created by /opt/versa/scripts/install/vms_install_helper.sh

Info: Initial Installation is completed
================================================================================                                                               
Updating existing hosts entry.

Info: Initial Setup of the node is complete
Info: Please re-run "vsh configure" to complete setup and configuration of this node
Initial set-up completed
Please copy certificates from /var/tmp/copy_certs/ directory to begin your configuration from Versa Orchestrator
================================================================================ 

8. Issue the vsh configure CLI command again to regenerate the certificates, configure interfaces, and enter the elastic IP address.  
9. Configure the FQDN of the VMS server to generate and validates certificates. The FQDN for the floating IP address of the node must be present in the SAN of the certificates. Agents use this FQDN to connect to VMS. 
10. Enter the subject alternative names (SANs) to be secured by the certificate. For example:

    Please Enter Subject ALT Name 1 used in Versa Message Service certificate file : sdwan-vms-1-elastic.mvno.com
    Please Enter Subject ALT Name 2 used in Versa Message Service certificate file : sdwan-vos.mvno.com
    

11. Respond Y to the following prompt to confirm the FQDN. For example:

    Do you want to continue with sdwan-vms-1.mvno.com as the entry?(y/N): Y
    

12. Enter a unique name for the VMS node for server identification. This is required for HA fail-over. For example:

    Please provide the below server identification information
    This Information is needed for HA fail-over
    Please Enter a unique name for this VMS node  : sdwan-vms-1
    

13. Enter the application certificate keystore password and confirm the password. For example:

    Application Certificate KeyStore Credentials
    Enter Password for Application Certificate KeyStore    :  
    RE-Enter Password for Application Certificate KeyStore : secret/default-server-secret created

14. Enter the IP address of the VMS host to which the VOS devices connect. For example:

    IP Address of VMS-Cluster where VOS/ADC will connect   
    Please Enter IP Address for this VMS Cluster where VOS/ADC will connect : 192.168.73.253
    

15. Enter the FQDN of VMS cluster to which applications connect. Note that this FQDN from SAN must be included in the server certificates. For example:

    FQDN of VMS-Cluster where applications will connect (ELASTIC/Floating FQDN/hostname)  
    ** This FQDN must exist in Server Certificates   
    Please Enter FQDN used as Entry for applications   : sdwan-vms-1-elastic.mvno.com

16. Enter the elastic floating IP address of the VMS cluster to which agents send traffic. This must be reachable from the Internet. The floating IP address is not assigned to any VMS node, the FQDN associated with this IP address is different from the VMS FQDN, and you cannot change this IP address after the configuration. For example:

    Elastic Floating IP of this VMS Cluster where agents will send traffic to VMS Cluster
    The FQDN associated with this IP is separate from VMS FQDN. This is a floating IP not assigned to any VMS node
    This IP cannot be changed after configuration
    Is the Elastic IP of this VMS Cluster finalized? (y/N) :  y
    Please enter the Elastic IP of this VMS Server: 10.40.173.25
    Updating existing hosts entry.

After the certificate regenerates, the certificate information displays after the certificate regenerates. The following example output shows some of the information that displays:

writing new private key to '/opt/versa/vms/certs/db_certs/node-key.pem'
-----
Using configuration from /opt/versa/scripts/certificates/ca-csr.conf
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number:
            76:ac:e3:5f:6a:6c:3f:a5:b5:e9:7d:89:5a:99:08:32:76:a5:47:ff
        Validity
            Not Before: May 20 17:14:40 2024 GMT
            Not After : Mar 25 17:14:40 2031 GMT
        Subject:
            countryName               = IN
            organizationName          = Versa Networks Inc.
            commonName                = node
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Key Usage:
                Digital Signature, Non Repudiation, Key Encipherment
            X509v3 Subject Alternative Name:
                DNS:sdwan-vms-1.mvno.com, DNS:localhost, DNS:127.0.0.1
Certificate is to be certified until Mar 25 17:14:40 2031 GMT (2500 days)

Write out database with 1 new entries
Data Base Updated
Converting node-cert.pem to node.crt and node-key.pem to node.key
Generating certificates for root client
Using configuration from /opt/versa/scripts/certificates/ca-csr.conf
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number:
            76:ac:e3:5f:6a:6c:3f:a5:b5:e9:7d:89:5a:99:08:32:76:a5:48:00
        Validity
            Not Before: May 20 17:14:41 2024 GMT
            Not After : Mar 25 17:14:41 2031 GMT
        Subject:
            countryName               = IN
            organizationName          = Versa Networks Inc.
            commonName                = root
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            Netscape Cert Type:
                SSL Client, S/MIME
            Netscape Comment:
                OpenSSL Generated Client Certificate
            X509v3 Subject Key Identifier:
                A7:65:D0:82:E8:AD:16:42:53:91:36:68:A1:5F:3E:FE:BC:E0:EF:71
            X509v3 Authority Key Identifier:
                keyid:44:5C:AF:E7:11:AD:B1:9D:D6:37:DC:89:59:F4:70:D4:DD:90:60:60

            X509v3 Key Usage: critical
                Digital Signature, Non Repudiation, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Client Authentication, E-mail Protection
Certificate is to be certified until Mar 25 17:14:41 2031 GMT (2500 days)

Write out database with 1 new entries
Data Base Updated
Generating certificates for versa client
Using configuration from /opt/versa/scripts/certificates/ca-csr.conf
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number:
            76:ac:e3:5f:6a:6c:3f:a5:b5:e9:7d:89:5a:99:08:32:76:a5:48:01
        Validity
            Not Before: May 20 17:14:42 2024 GMT
            Not After : Mar 25 17:14:42 2031 GMT
        Subject:
            countryName               = IN
            organizationName          = Versa Networks Inc.
            commonName                = versa
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            Netscape Cert Type:
                SSL Client, S/MIME
            Netscape Comment:
                OpenSSL Generated Client Certificate
            X509v3 Subject Key Identifier:
                32:1E:4B:31:EF:DB:26:BC:BF:EF:2D:C1:86:84:98:6C:C8:B4:44:E3
            X509v3 Authority Key Identifier:
                keyid:44:5C:AF:E7:11:AD:B1:9D:D6:37:DC:89:59:F4:70:D4:DD:90:60:60

            X509v3 Key Usage: critical
                Digital Signature, Non Repudiation, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Client Authentication, E-mail Protection
Certificate is to be certified until Mar 25 17:14:42 2031 GMT (2500 days)
Write out database with 1 new entries
Data Base Updated
Successfully generated all certificates at /opt/versa/vms/certs/db_certs/
Installing Database
cockroach-v23.1.8.linux-amd64-fips/cockroach
cockroach-v23.1.8.linux-amd64-fips/lib/libgeos.so
cockroach-v23.1.8.linux-amd64-fips/lib/libgeos_c.so
v23.1.8
Cockroach Installation/Upgrade successful !
v23.1.8
Using certificates in path: /opt/versa/vms/certs/db_certs/
Starting nodes
Starting the DB node
DB Node started.
Initilizing node
ERROR: cluster has already been initialized
Failed running "init"
DB node initilized
Loading data from SQL File: /opt/versa/vms/db/db_script.sql
CREATE DATABASE
NOTICE: schedule "core_schedule_label" already exists, skipping
SCHEDULED BACKUP 0
SET
NOTICE: relation "vms_supported_services" already exists, skipping
CREATE TABLE
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
SQL data successfully loaded!

Initial set-up completed
Please copy certificates from /var/tmp/copy_certs/ directory to begin your configuration from Versa Orchestrator

17. Copy the following server certificates from the /var/tmp/copy_certs/ directory to the first VMS node. After you have copied the certificates, you can configure VMS on Versa Director.
    • root-ca-cert.pem—This is the VMS root certificate. Upload it to the Files and Folders directory on the Director node and then associate it with a configuration template. VOS devices use this certificate to configure the VMS server.
    • server-cert.pem—Upload this certificate to the Director node when you configure the VMS connector for TLS. The Director node validates the VMS certificate.

Configure VMS from Versa Director

To configure VMS from a Director node, you create a VMS connector. In creating the VMS connection, you configure a VMS cluster that establishes a connection to a VMS node. While you can configure VMS from either the primary or secondary Director node, it is recommended that you configure the first control plane node from the primary Director node.

As part of configuring the VMS connector, you select the VMS interfaces that connects to your VOS devices and to which external agents connect; specify the Analytics controller node to which to send logs; and configure third-party authentication, XIP EIP, and the SASE-for-SIM Kafka and RADIUS services for tenants.