SD-WAN Viptela Collector Use Cases Guide

Using ssh, log into SD-WAN collector control plane node as sevone.

$ ssh sevone@<SD-WAN Viptela 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 overridden as needed. A new file, /opt/SevOne/chartconfs/solutions-sdwan-viptela_custom_guii.yaml, must be created to contain only the settings you want to override.

Create /opt/SevOne/chartconfs/solutions-sdwan-viptela_custom_guii.yaml file

$ touch /opt/SevOne/chartconfs/solutions-sdwan-viptela_custom_guii.yaml

To bind the augmentor / collector to specific nodes (as flows are directly routed to worker nodes), add the following variables in your configuration file.

• collectorService.nodeAffinity.values
• flowAugmentorService.nodeAffinity.values

Example: To run collector on host 'sdwan-node02' and augmentor on 'sdwan-node03'

collectorService:
  nodeAffinity:
    values:
      - {hostname}

Example

collectorService:
  nodeAffinity:
    values:
      - sdwan-node02

.

flowAugmentorService:
  nodeAffinity:
    values:
      - {hostname}

Example

flowAugmentorService:
  nodeAffinity:
    values:
      - sdwan-node03

To enable the AlarmStatAgent, perform the following steps.

1. 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>

2. Navigate to /opt/SevOne/chartconfs directory.

   $ cd /opt/SevOne/chartconfs

3. Add a valid filter for the AlarmStatAgent by adding the following configuration in /opt/SevOne/chartconfs/solutions-sdwan-viptela_custom_guii.yaml file.

   $ vi /opt/SevOne/chartconfs/solutions-sdwan-viptela_custom_guii.yaml
   
   collectorConfig:
     vendor:
       alarm_stat:
         filter:
           filter_on: vmanage_severity
           filter_value:
             - Major
             - Medium
             - Minor
             - Critical

4. Remove AlarmStatAgent from the exclude list by adding the following configuration in /opt/SevOne/chartconfs/solutions-sdwan-viptela_custom_guii.yaml file.

   $ vi /opt/SevOne/chartconfs/solutions-sdwan-viptela_custom_guii.yaml
   
   collectorConfig:
     agent:
       exclude:
         - None

5. Apply the changes made in the configuration (solutions-sdwan-viptela_custom_guii.yaml) file.

   $ sevone-cli solutions reload

Viptela Collector supports IPv4 flow monitoring only. The SD-WAN Viptela Augmentor currently supports the following flow fields.

• IP_SRC_ADDR – Source IP address
• IP_DST_ADDR – Destination IP address
• IP_DSCP – IP DSCP
• L4_SRC_PORT – Layer 4 source port
• L4_DST_PORT – Layer 4 destination port
• PROTOCOL – Protocol type
• BYTES – Bandwidth consumption
• PKTS – Packet count
• INPUT_SNMP – Ingress interface

Enhanced Flow Visibility with Additional Fields support in Flow Augmentor

As of SD-WAN 6.8.12, the Flow Augmentor supports additional flow fields to improve data flow visibility in the Viptela collector. For details on these additional flow fields, please refer to the Cisco Documentation corresponding to the device version you are using for accurate flow field details.

By default, certain vManage fields are excluded, but they can now be enabled, if needed. To activate these fields, configure the values to the specified array in the .yaml configuration file.

Example: The optional array list in the .yaml file consists of entries where fieldID corresponds to the Cisco field Id (element Id in the Flow fields), length is derived from Cisco documentation, and enterpriseID is fixed as 0.

 
flowAugmentorConfig:
  sender:
    ip: 10.49.xx.xxx
    port: 9996
    buffer: 100000
  optional_fields:
    - fieldID: 48
      enterpriseID: 0
      length: 1
    - fieldID: 95
      enterpriseID: 0
      length: 4
 

vi /opt/SevOne/chartconfs/solutions-sdwan-viptela_custom_guii.yaml

The following are the default IP ranges used by Solutions.

Execute the following steps to install SD-WAN 6.8 Viptela Collector on SD-WAN < 6.8 virtual machine.

1. 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: Currently on SD-WAN Viptela Collector < 6.8

   $ ssh sevone@10.128.11.150

2. Navigate to /opt/SevOne/upgrade directory.

   $ cd /opt/SevOne/upgrade

3. Remove all files present in directory /opt/SevOne/upgrade.

   $ rm -rf /opt/SevOne/upgrade

4. Download the following (latest) files from IBM Passport Advantage (https://www.ibm.com/software/passportadvantage/pao_download_software.html) via Passport Advantage Online. However, if you are on a legacy / flexible SevOne contract and do not have access to IBM Passport Advantage but have an active Support contract, please contact IBM SevOne Support for the latest files. You must place these files in /opt/SevOne/upgrade directory.
   1. sevone_solutions_sdwan_viptela-v6.8.0-build.44.tgz
   2. sevone_solutions_sdwan_viptela-v6.8.0-build.44.tgz.sha256.txt
   3. signature-tools-<latest version>-build.<###>.tgz

      For example, signature-tools-2.0.2-build.1.tgz

   4. signature-tools-<latest version>-build.<###>.tgz.sha256.txt

      For example, signature-tools-2.0.2-build.1.tgz.sha256.txt

5. Extract the latest build.

   $ tar xvfz $(ls -Art /opt/SevOne/upgrade/sevone_*.tgz | \
   tail -n 1) -C /opt/SevOne/upgrade/ ./utilities

6. You are now ready to deploy SD-WAN 6.8 collector. Please refer to SD-WAN Viptela Collector Deployment / Configuration Guide for details on how to perform the deployment.

After moving necessary devices from source peer to destination peer(s) in SevOne NMS UI (Device Mover), perfrom the following steps to make sure that the destination peer(s) is/are added in the collector config.

1. 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.11.150

2. Change directory to /opt/SevOne/chartconfs/.

   $ cd /opt/SevOne/chartconfs/

3. Using a text editor of your choice, update the flag distribution_peers_list with all peer IDs in /opt/SevOne/chartconfs/solutions-sdwan-viptela_custom_guii.yaml file and then save the file.

   $ vi /opt/SevOne/chartconfs/solutions-sdwan-viptela_custom_guii.yaml

4. Redeploy the collector.

   $ sevone-cli solutions reload

In a multi-node cluster, if one of the nodes is faulty, ensure that the deployed image matches the same release version as the existing nodes in the collector configuration.

Execute the following steps to add a new node in the SD-WAN collector cluster using the .ova file. Please refer to section Deploy OVA in SD-WAN Viptela Collector Pre-Deployment Guide for details.

1. Run the kubectl command to retrieve the node information from the cluster.

   $ kubectl get nodes

2. Remove the faulty node from the cluster.

   $ sevone-cli cluster worker remove <IP address of worker node>
    

3. Add a new node to the cluster.

   $ sevone-cli cluster worker add <IP address of worker node>
    

4. Reset the Kubernetes cluster.

   $ sevone-cli cluster down
    

5. Spin up the Kubernetes cluster.

   $ sevone-cli cluster up
    

6. Verify that the new agent node is Ready and has been added to the Kubernetes cluster.

   $ kubectl get nodes
    

During SD-WAN solution upgrade, the k3s service automatically rotates certificates that are due to expire within 90 days. In the event that they expire before k3s is able to rotate them, you will need to rotate manually. In other words, If you are seeing error message, x509: certificate has expired, when running kubectl commands, your certificates have expired and need to be rotated manually.

$ kubectl get pods

Unable to connect to the server: x509: certificate has expired or is not yet valid

The collector allows the agent to run on demand. In other words, collector allows the agent to run manually without waiting for the collector's scheduler to run it automatically based on the crontab. To run the agent on demand, execute the following command in your environment where the collector is running.

$ sevone-cli solutions run_agent [--deployment_name] DEPLOYMENT_NAME \
[--agent_name] AGENT_NAME [--log_level LOG_LEVEL]

Examples

Example-1

$ sevone-cli solutions run_agent --deployment_name solutions-sdwan-viptela-1 \
--agent_name InstallerAgent --log_level debug

Example-2

$ sevone-cli solutions run_agent --deployment_name solutions-sdwan-viptela-1 \
--agent_name InstallerAgent

Example-3

$ sevone-cli solutions run_agent solutions-sdwan-viptela-1 InstallerAgent debug

Example-4

$ sevone-cli solutions run_agent solutions-sdwan-viptela-1 InstallerAgent

1. To set the Object Rule for an Object type user needs to identify and block undesired Interface Objects or Tunnel Objects by using Regex expression.

   Example for Regex Expression: Assume interface or tunnels are named as Tunnel10, Tunnel092, 01Tunnel1456. In this case user can block .*Tunnel.* and then click on Save. Please refer to images shown below.

   Note: .* means Match any alpha numeric characters.

   Example: for Interface Objects

   

   Example: for Tunnel Objects

   

2. Once the rules are saved, user can manually rediscover devices if there are only a few devices, or wait for 24 hours for automatic device discovery.
3. After device rediscovery, execute the steps as shown below in SevOne NMS database i.e., master and all peers (if any).
   • Using ssh, login to SevOne NMS appliance as root.

     $ ssh root@<SevOne NMS appliance IP address>

   • For a list of containers and its ids, run the following command.

     $ podman ps

   • Enter SevOne NMS container.

     
     $ nms

   • Run the following command to login to MySQL database.

     
     $ mysqldata
      

   • Delete the object name from the local.device_object table where the is_visible=0.

     
     $ delete from local.device_object where name like '%objectname%' and is_visible=0;
      

     Example

     
     $ delete from local.device_object where name like '%Tunnel%' and is_visible=0;
      

4. After running the above command, the user must wait for 24hrs for the count to decrease from net.netflowplugin map table in the database.

This ensures that flow reports in SevOne Data Insight continue to function properly and provide useful insights into network traffic patterns and performance.

This section contains information about the pros and cons of deploying standalone and multi-tenant clusters.

• Add a new vManage as a tenant in the existing cluster

  Pros	Cons
  No need to provide additional resources to k3s.	If the k3s cluster encounters any issues, it will impact the data collection process for tenants.
  No need to setup a standalone cluster for the new vManage.	Cannot use SSU for deployment.
  Adding a new tenant is easy as compared to creating a standalone cluster.

• Standalone cluster for a new vManage

  Pros	Cons
  Any issues with one tenant's data collection due to k3s cluster problems will not affect the other tenant.	Need to provide additional resources to k3s.
  Deploying the augmenter on a separate node will be easier due to the smaller number of nodes.	Need to setup a standalone cluster for the new vManage.
  Can use SSU for deployment

Execute the following steps.

1. To stop collecting data for a particular tenant, execute the following command.

   $ helm uninstall <helm_deployment_name>

   where, <helm_deployment_name> is the name of the helm deployment related to a particular tenant you want to stop collecting data for.

2. After stopping the collection of data for the tenant, manually cleanup to remove the tenant specific data from the NMS. To purge the flows data, from the navigation bar, go to Administration, select Flow Configuration, and then select Flow Interface Manager. Select the devices from the list specific to the tenant, click on the wrench icon, and Purge Device Flows.

   

3. To finally delete the data, select the devices specific to the tenant from the list on the Flow Interface Manager, click on the Delete Device Rules button.

   

4. To delete the tenant device group, from the navigation bar, go to Devices, select Grouping, and then select Device Groups. Hover over the tenant device group and click on the icon. Click on OK to confirm.

   

5. To delete the tenant object groups, from the navigation bar, go to Devices, select Grouping, and then select Object Groups. Hover over the tenant object group and click on icon. Click on OK to confirm.

   

6. To delete the devices for this tenant, from the navigation bar, go to Devices and then select Device Manager. Select the devices for this tenant and click on Delete Selected. Then click on OK to confirm.