SD-WAN Viptela Collector Deployment / Configuration Guide
SevOne Documentation
All documentation is available from the IBM SevOne Support customer portal.
© Copyright International Business Machines Corporation 2023.
All right, title, and interest in and to the software and documentation are and shall remain the exclusive property of IBM and its respective licensors. No part of this document may be reproduced by any means nor modified, decompiled, disassembled, published or distributed, in whole or in part, or translated to any electronic medium or other means without the written consent of IBM.
IN NO EVENT SHALL IBM, ITS SUPPLIERS, NOR ITS LICENSORS BE LIABLE FOR ANY DAMAGES, WHETHER ARISING IN TORT, CONTRACT OR ANY OTHER LEGAL THEORY EVEN IF IBM HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, AND IBM DISCLAIMS ALL WARRANTIES, CONDITIONS OR OTHER TERMS, EXPRESS OR IMPLIED, STATUTORY OR OTHERWISE, ON SOFTWARE AND DOCUMENTATION FURNISHED HEREUNDER INCLUDING WITHOUT LIMITATION THE WARRANTIES OF DESIGN, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT.
IBM, the IBM logo, and SevOne are trademarks or registered trademarks of International Business Machines Corporation, in the United States and/or other countries. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on ibm.com/trademark.
About
This document describes the steps to deploy and configure the SD-WAN Viptela collector.
In this guide if there is,
- [any reference to master] OR
- [[if a CLI command (for NMS or Kubernetes or Redis) contains master] AND/OR
- [its output contains master]],
And, if there is any reference to slave or worker, it means follower or agent.
Deployment
Login Credentials & Password Change
To perform SD-WAN collector installation process, you will need to SSH into your machines using non-root credentials for the user sevone. Before continuing, you will need to SSH into each machine that you plan to run SD-WAN collector on and change the default password for this user. This applies whether you are using a SD-WAN appliance or have deployed an .ova. You will need to do this for all nodes (control plane and all agent nodes). This is important for security reasons.
Failure to change the default password presents a significant security risk. This publication includes a default password and this document has probably been made available to the public.
-
SSH into your SD-WAN collector machine and log in as sevone.
-
At the Password prompt, enter sevone.
-
Execute the following command:
$ passwd
-
At the prompt New password, enter a new password for the sevone user.
-
At the prompt Retype new password, enter the new password again.
-
Repeat the steps above for each machine that you plan to run SD-WAN collector on.
Install sevone-cli
Execute the following command to install sevone-cli using Command Line Interface.
$ sudo rpm -Uvh /opt/SevOne/upgrade/utilities/sevone-cli-*.rpm
Generate SSH Keys
As a security measure, fresh installations do not ship with pre-generated SSH keys. Execute the following command to generate unique SSH keys for your cluster.
$ sevone-cli cluster setup-keys
Single-Node Deployment
-
Please refer to SD-WAN Pre-Deployment Guide to deploy a single SD-WAN Viptela node.
-
Using ssh, log into the SD-WAN Viptela collector control plane node as sevone.
$ ssh sevone@<SD-WAN collector 'control plane' node IP address or hostname>
Example
$ ssh sevone@10.128.8.137
-
Change the hostname. For details, please refer to SD-WAN Viptela Collector Use-Cases Guide > Use-Cases > section Change Hostname.
Please make sure to set the hostname for all k3s nodes in lowercase when deploying the collector.
Multi-Node Deployment
The settings for the flow augmentor's buffer size and net.core.rmem_default values are set only on the node where the augmentor is deployed.
If the flow augmentor pod is in the agent node and the flows are streamlined to the control plane node, it will result in a spoofing issue.
During deployment, flow augmentor and collector nodes may interchange. The flows must be streamed to the correct node accordingly.
-
For a multi-node setup, repeat the steps in SD-WAN Viptela Collector Pre-Deployment Guide for each additional node in your cluster. Every SD-WAN collector node ships as a running single-node Kubernetes cluster.
-
Using ssh, log into each node and change the hostname. In order to create a multi-node cluster, you must designate one of the nodes to be your control plane node. For details on how to change the hostname, please refer to SD-WAN Viptela Collector Use-Cases Guide > section Use-Cases > subsection Change Hostname.
IMPORTANT
- Please make sure to set the hostname for all k3s nodes in lowercase when deploying the collector.
- If you have created cluster or added agent nodes using the hostname method, please skip to step 7.
- If you want to create cluster or add agent nodes using the IP address method, please perform steps 3, 4, 5, and 6.
Example
IMPORTANT
The hostnames and IP addresses mentioned in this table are used in the examples for the steps below. Please make sure to replace the hostnames and IP addresses with your machine's hostnames and IP addresses.Hostname IP Address Role sdwan-node01 10.123.45.67 control plane sdwan-node02 10.123.45.68 agent1 sdwan-node03 10.123.45.69 agent2 -
Using ssh, log into SD-WAN collector control plane node as sevone.
$ ssh sevone@<SD-WAN collector 'control plane' node IP address or hostname>
Example
$ ssh sevone@10.123.45.67
-
Add nodes.
$ sevone-cli cluster worker add <IP address for node 1>
- When adding a new agent node to your cluster, please repeat steps 4, 5, and 6 every time. Please add agent nodes using the IP address only.
- Please do not run sevone-cli cluster worker remove command when there is no k3s cluster running.
-
Stop / reset the kubernetes.
$ sevone-cli cluster down
-
The following spins up your Kubernetes cluster.
$ sevone-cli cluster up
The message FAILED - RETRYING: Wait for k3s server to be up means that k3s is trying to come up and it may take a long time. If all retries are exhausted and k3s is unable to come up, the command will fail automatically. Please contact IBM SevOne Support for help. -
Verify that your control plane and agent node(s) are Ready and have been added to the Kubernetes cluster.
$ kubectl get nodes NAME STATUS ROLES AGE VERSION <your 'control plane' hostname> Ready master 2m45s v1.27.1+k3s1 <your 'agent1' hostname> Ready <none> 2m45s v1.27.1+k3s1 <your 'agent2' hostname> Ready <none> 2m45s v1.27.1+k3s1 ... <your 'agent<n>' hostname> Ready <none> 2m45s v1.27.1+k3s1
Example
$ kubectl get nodes NAME STATUS ROLES AGE VERSION sdwan-node01 Ready master 2m45s v1.27.1+k3s1 sdwan-node02 Ready <none> 2m45s v1.27.1+k3s1 sdwan-node03 Ready <none> 2m45s v1.27.1+k3s1
Installation
using Graphical User Interface
-
Using ssh, log into SD-WAN Viptela collector control plane node as sevone.
$ ssh sevone@<SD-WAN collector 'control plane' node IP address or hostname>
Example
$ ssh sevone@10.128.8.137
-
Copy /opt/SevOne/upgrade/utilities/api.custom.yaml to /etc/sevone-guii.
$ cp /opt/SevOne/upgrade/utilities/api.custom.yaml /etc/sevone-guii
After making a copy, if you need to change the port number for the API, using a text editor of your choice, edit the .yaml file to change the setting and save the file.Example: Change port number for API
$ vi /etc/sevone-guii/api.custom.yaml main: port: 3001 # <-- change port number
If you need to change the port number for the client, create client.custom.yaml file in /etc/sevone-guii/.-
Change directory to /etc/sevone-guii/.
$ cd /etc/sevone-guii/
-
Create client.custom.yaml file.
$ touch client.custom.yaml
-
Using a text editor of your choice, edit the .yaml file to change the setting and save the file.
Example: Change port number for Client
$ vi /etc/sevone-guii/client.custom.yaml main: port: 3000 # <-- change port number
-
-
Copy SSH keys to SevOne NMS and install GUI.
$ ssh-copy-id root@<SevOne NMS IP Address> && sevone-cli guii
Example
$ ssh-copy-id root@10.168.87.203 && sevone-cli guii
Please provide the SSH password when prompted.Example: The command returns the following
╒═══════════════════════════════════════════════════════════════╕ │ SEVONE GUI INSTALLER │ ╞═══════════════════════════════════════════════════════════════╡ │ Please open https://10.128.8.137:3000 in your web browser to │ │ access the GUI Installer. │ ├───────────────────────────────────────────────────────────────┤ │ Your credentials are: │ │ - Username: admin │ │ - Password: {ab}O>lu!J │ ├───────────────────────────────────────────────────────────────┤ │ If you ever lose your credentials, they are stored in: │ │ /etc/sevone-guii/creds │ ╘═══════════════════════════════════════════════════════════════╛
You are now ready to install using the Graphical User Interface Installer.
-
Using a web browser of your choice, enter the URL the setup script has returned. For example, https://10.128.8.137:3000.
You will also need the credentials (Username and Password) that the setup script returns. These credentials are also stored in /etc/sevone-guii/creds file.Example
$ cat /etc/sevone-guii/creds | jq { "password": "{ab}O>lu!J", "tokenSecret": "erjulXqdmuWSkNQMsexSNGLsadgjtrlu", "username": "admin" }
-
Click Update Cluster to install SD-WAN Viptela Collector.
-
Enter the credentials returned to perform the Self-Service Upgrade. For example, Username: admin and Password: {ab}O>lu!J
To use the Graphical User Interface installer in dark theme, click next to SevOne logo.
For help on what each upgrade step does, click button in the upper-right corner.IMPORTANT
All the screenshots below are based on the example being used to write this document. Your total number of tasks passed (ok), skipped, failed, ignored, unreachable, or unexecuted will vary based on your setup. The tasks failed must be addressed as ansible has not ignored them. -
Enter username & password and then click Login. The graphical user interface installer checks the Current Version and allows you to proceed with the installation.
Example
Current Version is on SD-WAN Viptela Collector 6.6.0+19.
You can proceed with redeploy/install.During the Self-Service Upgrade, if you experience network connectivity issue or the upgrade has been halted for any reason, the self-service upgrade will resume from the step where it left off after the issue is resolved. However, if you are at the Deploy step and the self-service upgrade has been halted for any reason, self-service upgrade will show a message requesting you to contact IBM SevOne Support.
To resume with the Self-Service Upgrade, using a web browser of your choice, re-enter the URL the setup script has returned. For example, https://10.128.8.137:3000. -
Click the Continue to Configure button to configure SD-WAN Viptela solution. Using GUI, you can configure only basic settings for your collector. To configure the advanced settings, please refer to Configure section.
To configure advanced settings, you must click Save button.-
From Configuration drop-down, choose a configuration file from the list. The default configuration file is solutions-sdwan-viptela_custom_guii.yaml. Provide inputs for all mandatory fields.
Once you provide inputs for all mandatory fields, error messages will no longer appear. -
Collector Service
-
Credentials (All values must be base64-encoded format)
-
Controller Credentials
- Username - The username for Viptela vManage credentials with admin-level read privilege.
- Password - The password for Viptela vManage.
-
NMS Credentials
-
NMS API Credentials
- Username - The SevOne NMS user name for an administrator-level account.
- Password - The SevOne NMS password.
-
SSH Credentials
- Username - The SevOne NMS user name for ssh access to the appliance. It is recommend to set to root in base64-encoded format.
- Password - The SevOne NMS password for root user.
-
-
DI Credentials
-
DI API Credentials
-
Username - The SevOne Data Insight user name for an adminstrator-level account.
-
Password - The SevOne Data Insight password.
-
-
-
-
-
Collector Configuration
- MSP Name - The Managed Service Provider (MSP) name for this instance. MSP is a grouping of one or more tenants.
-
Log
- Log Level - Defines the log-level for the collector. Value can be info, debug, warning, or error.
-
Jaeger
- Disabled - Select the check box to disable Jaeger tracing.
-
Load Reports
- Disabled - Select the check box to not import TopN views and OOTB reports.
-
Vendor Controller Settings
-
Viptela vManage Controller Settings
-
vManage API URL - The API URL of vManage.
-
Insecure TLS - Select the check box to enable insecure TLS connection by skipping certification verification. This is necessary for servers with self-signed server certificates.
-
-
-
NMS
-
NMS API Settings
-
NMS API IP / Hostname - The hostname or IP address for SOA and REST API endpoints. i.e., targeted SevOne NMS.
-
Insecure TLS - Select the check box to enable insecure TLS connection by skipping certification verification. This is necessary for servers with self-signed server certificates.
-
-
DI
-
DI API Settings - The hostname or IP address for targeted SevOne Data Insight.
-
Insecure TLS - Select the check box to enable insecure TLS connection by skipping certification verification. This is necessary for servers with self-signed server certificates.
-
Tenant - Tenant name for this SevOne Data Insight instance. This is an internal name used to keep settings and cached data segregated by tenant. Default value is SevOne.
-
-
-
Flow Augmentor Service Settings
-
Enable - Select the check box to enable Flow Augmentor installation.
-
Flow Receiver Port - The port on which Flow Augmentor listens for inbound flows. The port number can range from 9000 - 33000.
-
-
Flow Augmentor Configuration
* Flow Augmentor Sender Configuration- Flow Augmentor Sender Buffer Size - Sender output buffer size in number of packets.
- DNC IP - IP address of the DNC, where the augmented flows are sent.
- Port No - Port of DNC, where the the augmented flows are sent.
-
-
Click Save. Configuration is saved in /opt/SevOne/chartconfs/solutions-sdwan-viptela_custom_guii.yaml.
Once the configuration is saved, click Continue button to upgrade SOA. -
Click Continue button to Upgrade SOA.
SOA version
SOA must be on the latest version on all appliances in SevOne NMS cluster. Command Line Interface (CLI) must be used to upgrade SOA on all peers as the graphical user interface (GUI) only upgrades SOA for the NMS appliance you are connected to.Add flag --all-peers if you want to install SOA on all peers in the cluster.$ sevone-cli soa upgrade \ /opt/SevOne/upgrade/utilities/SevOne-soa-*.rpm \ <enter SevOne NMS IP address> --all-peers
-
You are now ready to upgrade SOA. Click Run Upgrade SOA button. This can take a few minutes to run.
-
Click the Continue button to Pre-Check.
Pre-Check step runs various checks to ensure that SD-WAN Viptela collector cluster is healthy before the deployment. -
You are now ready to run the pre-check. Click the Run Pre-Check button.
To view the logs for a task, click for the task you need the details for. The pop-up has Copy to clipboard button which allows you to copy all the contents in the pop-up and paste it into a file. -
Click the Continue button to Deploy.
-
Click the Run Deploy button to run the upgrade. This can take a few minutes to run.
-
Click the Continue button to Post-Check.
-
Click the Run Post-Check button to run the post-check. This can take a few minutes to run.
-
Click the Continue button.
This indicates that the installation has completed successfully.
using Command Line Interface
Please execute the steps sequentially as they appear in these sections.
- Set the timeout value for the REST API to 600 seconds.
- Point to a different SevOne NMS for each agent.
- Run metadata agent twice in 24 hours. Currently, it is scheduled to run only once in 24 hours.
- Run the Metadata agent at a different time interval. For example, at noon 12:00 PM UTC and at 01:00 PM UTC. Currently, it is set to 00:00 UTC.
- Set a different time to run the Metadata agent for each tenant. For example, in the case of two tenants, if the agent for tenant A is scheduled to run at midnight 01:00 AM UTC and 12:00 PM UTC, then for tenant B, set the schedule to run this agent at midnight 02:00 AM UTC and 01:00 PM UTC. Metadata agent for these tenants can be scheduled to run at a difference of 30 minutes to 1 hour depending on the response time of vManage and SevOne NMS.
Example: Configuration for the agent to run at 1:15 and 19:15
vendor:
metadata:
schedule: "15 1,19 * * *"
vmanage_api:
url: http://10.128.11.105:5014
insecure_tls_connection: true
Upgrade SOA
Prior to linking SD-WAN Viptela Collector with your SevOne NMS, check SOA version and upgrade SOA, if necessary.
SOA must be on the latest version on all appliances in SevOne NMS cluster. Command Line Interface (CLI) must be used to upgrade SOA on all peers as the graphical user interface (GUI) only upgrades SOA for the NMS appliance you are connected to.
Execute the command to install / upgrade SOA only on NMS' Cluster Master and HSA
$ sevone-cli soa upgrade \
/opt/SevOne/upgrade/utilities/SevOne-soa-*.rpm
Execute the command to install / upgrade SOA on ALL peers in the NMS cluster
$ sevone-cli soa upgrade \
/opt/SevOne/upgrade/utilities/SevOne-soa-*.rpm \
--all-peers
Check SOA Version
-
Using ssh, log in as root to SevOne NMS appliance you are linking SD-WAN Viptela Collector with.
$ ssh root@<SevOne NMS appliance>
-
Check SOA version.
$ curl -k https://<SevOne NMS appliance IP address or hostname>/api/v3/health/version
Example
$ curl -k https://10.168.87.203/api/v3/health/version {"buildTime":"2023-06-29T20:07:53Z", "gitHash":"6a0b0975a6b8973f12f531e594f643ec0fedd24c-dirty", "goVersion":"go1.20.5", "version":"6.6.0", "nmsVersion":"6.6.0"}
6.6.0 in the example above is the SOA version.
Configure
-
Using ssh, log into SD-WAN collector control plane node as sevone.
$ ssh sevone@<SD-WAN collector 'control plane' node IP address or hostname>
SD-WAN collector runs as a helm chart deployed within the Kubernetes cluster. The helm chart is configured with a base set of configuration options that can be overwritten as needed. -
Copy /opt/SevOne/upgrade/utilities/example-solutions-sdwan-viptela_config.yaml to /opt/SevOne/chartconfs/solutions-sdwan-viptela_custom_guii.yaml.
$ cp /opt/SevOne/upgrade/utilities/example-solutions-sdwan-viptela_config.yaml \ /opt/SevOne/chartconfs/solutions-sdwan-viptela_custom_guii.yaml
-
/opt/SevOne/chartconfs/solutions-sdwan-viptela_custom_guii.yaml contains the default (basic / minimum) configuration for Viptela. To change the configuration settings, using a text editor of your choice, /opt/SevOne/chartconfs/solutions-sdwan-viptela_custom_guii.yaml file must be updated and saved. For details on variables used in the .yaml file, please refer to section Configuration.
Pre-Check Environment
Execute the following command to perform the pre-check of your environment and monitor the output. Ensure that there are no failures reported in the output.
$ sevone-cli playbook precheck
- checks if your SevOne NMS appliance and Viptela vManage are reachable.
- validates SOA and all other versions that NMS is dependent on, are valid.
- confirms port availability.
- validates checksum for the entire deployment.
- validates Viptela vManage versions.
- confirms all flow port settings are available and DNC is reachable (Flow checks are only performed if the Flow Augmentor is enabled).
- in case of multi-tenants, pre-checks are performed on all tenants.
The pre-check must complete successfully before you can continue to the next step. You will see the output similar to the following.
Example
PLAY [Perform prechecks for viptela] ***********************************************************************************
TASK [Gathering Facts] *************************************************************************************************
ok: [sevonek8s]
...
...
PLAY RECAP *************************************************************************************************************
sevonek8s : ok=47 changed=4 unreachable=0 failed=0 skipped=47 rescued=0 ignored=1
The output of the command above is based on the example being used to write this document. Your total number of tasks passed (ok) , changed, unreachable, failed, skipped , rescued or ignored will vary based on your setup. The tasks failed must be addressed as ansible has not ignored them.
If the pre-check does not complete successfully, please resolve the issue(s) before continuing or contact IBM SevOne Support.
Deploy
You are now ready to deploy the applications based on your configuration file. This applies to multi-tenant scenarios as well. Ensure that there are no failures reported in the output.
Ensure that solutions-sdwan-viptela_custom_guii.yaml file is present in /opt/SevOne/chartconfs/.
$ sevone-cli cluster up
The deployment must complete successfully before you can continue to the next step. You will see the output similar to the following.
Example
PLAY [prepare cluster] *************************************************************************************************
TASK [Gathering Facts] *************************************************************************************************
ok: [sevonek8s]
...
...
PLAY RECAP *************************************************************************************************************
sevonek8s : ok=151 changed=43 unreachable=0 failed=0 skipped=49 rescued=0 ignored=1
The output of the command above is based on the example being used to write this document. Your total number of tasks passed (ok) , changed, unreachable, failed, skipped , rescued or ignored will vary based on your setup. The tasks failed must be addressed as ansible has not ignored them.
If the deployment does not complete successfully, please resolve the issue(s) before continuing or contact IBM SevOne Support.
Post-Check Environment
After successfully applying the configuration file, execute the following command to perform the post-check. Ensure that there are no failures reported in the output.
Sometimes SSH keys for SevOne NMS are not available in the control plane node. To create SevOne NMS SSH keys, please execute the following command before proceeding with the post-check.
$ sevone-cli soa setup_keys
$ sevone-cli playbook postcheck
- copies flow views to SevOne NMS.
- flow views must be ready on SevOne NMS.
- cron jobs collect the periodic logs.
- after waiting for 2 minutes, it checks to ensure that all pods are either in Ready or Completed status and no pod(s) have restarted.
- in case of multi-tenants, post-checks are performed on all tenants.
-
Using ssh, log into the SD-WAN Viptela collector control plane node as sevone.
$ ssh sevone@<SD-WAN collector 'control plane' node IP address or hostname>
-
For each node in the cluster, copy the attached script archive-pod-logs.sh to the folder /home/sevone.
$ cp /opt/SevOne/upgrade/ansible/playbooks/roles/postchecks/files/archive-pod-logs.sh \ /home/sevone/
-
Provide execute permission to the archive-pod-logs.sh script.
$ chmod 0755 archive-pod-logs.sh
-
Create a sudo session.
$ sudo -s
-
Change directory to /etc/cron.d.
$ cd /etc/cron.d
-
Create a cronjob entry by creating the archive_pod_logs file. Using a text editor of your choice, edit archive_pod_logs and save the file.
$ vi archive_pod_logs #Ansible: Daily cron job for archiving pod logs 0 0 * * * sevone /home/sevone/archive-pod-logs.sh collector aug
The post-check must complete successfully before you can continue to the next step. You will see the output similar to the following. Restart / Crash logs are stored in /opt/SevOne/logs/restartlogs/.
Example
PLAY [Check the pod health] ******************************************************************
TASK [Gathering Facts] *************************************************************************************************
ok: [sevonek8s]
...
...
PLAY RECAP *************************************************************************************************************
sevonek8s : ok=13 changed=8 unreachable=0 failed=0 skipped=4 rescued=0 ignored=0
The output of the command above is based on the example being used to write this document. Your total number of tasks passed (ok) , changed, unreachable, failed, skipped , rescued or ignored will vary based on your setup. The tasks failed must be addressed as ansible has not ignored them.
If the post-check does not complete successfully, please resolve the issue(s) before continuing or contact IBM SevOne Support.
Configuration
Value Types
The collector configuration is defined in YAML format. Each setting may be one of the following.
Value Type | Description |
---|---|
String | String value. |
Integer | Numeric integer value. |
Boolean | Boolean true or false. |
Duration | Time duration using syntax such as,
|
Base64 | Base64-encoded string. To create it, execute the following command. Generate username 'admin' in base64-encoded format $ echo -n "admin" | base64 YWRtaW4= If the password contains an exclamation mark (!), please use any online string to base64 converter tool (other than CLI) to convert the password into base64 format. For example, https://www.base64encode.org/
|
Array of <...> | An array of one of the other value types. This is set in YAML as, YAML array my_setting: - value1 - value2 |
Schedule string | Can be either:
|
How are variable names in the tables below written in YAML file?
Example# 1: Variable names starting with 'collectorService'
collectorService:
secrets:
controller:
# vManage credentials.
username: ZGV2ZWxvcA==
password: RGV2VGVhbTEyMw==
nms:
ssh:
# NMS ssh credentials.
username: cm9vdA==
password: ZFJ1bSY1ODUz
api:
# NMS API credentials.
username: YWRtaW4=
password: U2V2T25l
di:
# DI API credentials list.
api:
- username: YWRtaW4=
password: U2V2T25l
Example# 2: Variable names starting with 'collectorConfig'
collectorConfig:
# MSP name. Short and descriptive name for the collector that becomes part
# of the generated NMS configuration, such as the "<MSP>::SDWAN" device
# group that contains all collected devices.
#
# Must be unique per tenant.
msp_name: VIPTELA
nms:
api:
# NMS server name or IP address.
host: 10.129.25.196
di:
api:
- host: 10.128.10.20 # DI server name or IP address
tenant: SevOne # DI tenant (default: SevOne)
# Tenant name for multitenant deployments. Short and descriptive internal name.
#
# Must be unique per tenant.
tenant_name: Tenant 1
Mandatory Settings
Variable Name | Value Type | Default Value | Description | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
collectorConfig.msp_name | String | The Managed Service Provider (MSP) name for this instance. MSP is a grouping of one or more tenants. The default value is ORGANIZATION. | |||||||||||||||||
collectorConfig.nms.api.host | String | The hostname or IP address for SOA and REST API endpoints. i.e., targeted SevOne NMS. | |||||||||||||||||
collectorConfig.di.api | Array of objects | An array of mapping of the following variables:
e.g. Configure SevOne Data Insight API hostname and tenant like: Example collectorConfig: di: api: - host: 10.128.26.50 tenant: SevOne |
|||||||||||||||||
collecotrConfig.di.api.tenant | String | SevOne | Tenant name for this SevOne Data Insight instance. This is an internal name used to keep settings and cached data segregated by tenant. | ||||||||||||||||
collectorConfig.tenant_name | String | SevOne | Tenant name for this collector instance. This is an internal name used to keep settings and cached data segregated by tenant. Note: Be sure that this setting is unique for each deployed tenant in a multi-tenant deployment. |
||||||||||||||||
collectorService.secrets.nms.api.password | Base64 | The SevOne NMS password. | |||||||||||||||||
collectorService.secrets.nms.api.username | Base64 | The SevOne NMS user name for an administrator-level account. | |||||||||||||||||
collectorService.secrets.controller.password | Base64 | The password for Viptela vManage. | |||||||||||||||||
collectorService.secrets.controller.username | Base64 | The username for Viptela vManage credentials with admin-level read privilege. | |||||||||||||||||
collectorService.secrets.nms.ssh.password | Base64 | The SevOne NMS password for root user. | |||||||||||||||||
collectorService.secrets.nms.ssh.username | Base64 | The SevOne NMS user name for ssh access to the appliance. Please set to root in base64-encoded format. | |||||||||||||||||
colletorService.secrets.di.api | Array of objects | An array of mapping of the following variables:
e.g. Configure SevOne Data Inisght Username and Password like: Example collectorService: secrets: di: api: - username: GCHtaW4= password: U4S2T25l |
Verification
Check Pods
Check the pods - must be Running or Completed.
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
solutions-sdwan-viptela-redis-master-0 1/1 Running 0 6d3h
solutions-sdwan-viptela-redis-replicas-0 1/1 Running 0 6d3h
solutions-sdwan-viptela-upgrade-kpbdd 0/1 Completed 0 15m
solutions-sdwan-viptela-aug-5496ccccbd-7txnt 1/1 Running 0 15m
solutions-sdwan-viptela-create-keys-2-rcbpc 0/1 Completed 0 15m
solutions-sdwan-viptela-collector-8795594c9-2v7gr 1/1 Running 0 15m
Check Services
$ kubectl get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 192.168.96.1 <none> 443/TCP 6d3h
solutions-sdwan-viptela-redis-headless ClusterIP None <none> 6379/TCP 6d3h
solutions-sdwan-viptela ClusterIP 192.168.100.137 <none> 80/TCP 6d3h
solutions-sdwan-viptela-redis-replicas ClusterIP 192.168.110.165 <none> 6379/TCP 6d3h
solutions-sdwan-viptela-redis-master ClusterIP 192.168.103.82 <none> 6379/TCP 6d3h
solutions-sdwan-viptela-flowservice NodePort 192.168.99.27 <none> 9995:9995/UDP 16m
Check Logs
-
Obtain the pod name for SD-WAN Viptela collector to check the logs for.
$ kubectl get pods NAME READY STATUS RESTARTS AGE solutions-sdwan-viptela-redis-master-0 1/1 Running 0 6d3h solutions-sdwan-viptela-redis-replicas-0 1/1 Running 0 6d3h solutions-sdwan-viptela-upgrade-kpbdd 0/1 Completed 0 15m solutions-sdwan-viptela-aug-5496ccccbd-7txnt 1/1 Running 0 15m solutions-sdwan-viptela-create-keys-2-rcbpc 0/1 Completed 0 15m solutions-sdwan-viptela-collector-8795594c9-2v7gr 1/1 Running 0 15m
The pod name for SD-WAN Viptela collector returned is solutions-sdwan-viptela-collector-8795594c9-2v7gr. -
Check the logs for solutions-sdwan-viptela-collector-8795594c9-2v7gr, for example.
Example
$ kubectl logs -f solutions-sdwan-viptela-collector-8795594c9-2v7gr
Verify Data Appears in SevOne NMS
Once the collector has been running for 15 to 20 minutes, data should appear in SevOne NMS. Perform the following steps to verify this.
-
Log into SevOne NMS.
-
From the navigation bar, go to Administration, select Object Types from Monitoring Configuration. Filter to xStats.
-
From the navigation bar, go to Devices, select Grouping, and then select Device Groups.
-
From the navigation bar, go to Devices, select Grouping, and then select Object Groups.
-
From the navigation bar, go to Administration and select Metadata Schema. Click on Add Namespace to check metadata creation.
-
If enable_flow_view_creation and flow_enabled are set to true, then the user will be able to see the created SDWAN:Viptela:AugmentedFlow view. To see the created view, from the navigation bar go to Administration, select Flow Configuration, and then select FlowFalcon View Editor.