This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

The release notes cover the following topics:

About VMware Telco Cloud Operations

VMware Telco Cloud Operations is a real-time automated service assurance solution designed to bridge the gap between the virtual and physical worlds. It provides holistic monitoring and network management across all layers for rapid insights, lowers costs, and improved customer experience. Powered by machine learning (ML) capabilities, VMware Telco Cloud Operations automatically establishes dynamic performance baselines, identifies anomalies, and alerts operators when abnormal behavior is detected.

VMware Telco Cloud Operations simplifies the approach to data extraction, enrichment, and analysis of network data across multi-vendor environments into actionable notifications and alerts to manage the growing business needs of Telco in an SDN environment.

For information about setting up and using VMware Telco Cloud Operations, see the VMware Telco Cloud Operations Documentation.

What's New in this Release

The VMware Telco Cloud Operations v1.1 introduces the following enhancements:

  • Multi Tenant Reporting Support:

    • Managed Service Providers (MSP) can now provide multi-tenant reporting portal.
    • Enhanced featured to filter metric data on Grafana.
    • Authentication and Authorization support for multi-tenancy.
    • Onboarded MSP and Tenant users, based on LDAP authentication provider.
    • Enhanced access control to implement role-based access control (RBAC) for the users and resources in the organization.

  • High availability at container level:

    • Important containers like Kafka and ElasticSearch offers high availability, managed by Kubernetes.

  • Deployment on VMC Azure:

    • VMware Telco Cloud Operations virtual appliance including Smarts components are now deployable on VMC platform.

  • Support for two-phase deployment process:

    • The two-phase process provides for enhanced flexibility and efficiency in the deployment process.
      • Manual : The VM deployment is uses vCenter and Cluster deployment using an Administration UI.
      • Automated: Both phases in the two-step process use the Deploy-Tool.
      • Semi-automated: The VM deployment uses the Deploy-Tool and cluster deployment using the Administration UI.

  • Proxy support for SDWAN data collectors:

    • Increases collector flexibility by supporting proxy.
      • HTTP(s) Proxy configuration support for VeloCloud topology, monitoring and performance collectors.
      • HTTP(s) Proxy configuration support for Viptela topology, monitoring and performance collectors.

  • RHEL 8 support Network Configuration Manager:

    • Enables current customers to deploy NCM 10.x on RHEL 8.x.

  • User Interface Enhancements:

    • SDWAN Connectivity map type created for VGateway.

  • Velocloud RCA improvement

    • The Edge Down problem definition is improved to consider the aliveness of both the data and (VCO) management links. The earlier behavior was to consider only the status of the management link. The VCO exposes the status of the data link for an Edge for MSP user only from VCO 4.0.0. version. So, for MSP user deployment the VCO has to be 4.0.0 (or later) to use the data link status. For prior VCO version only the management link status is used.

  • Enable discovery of ping disabled Viptela vManage:

    • ​The ICMP ping disabled vManage does not end up in pending list and the discovery continues with REST based probe.

  • VeloCloud v4.0 Support:

    • VeloCloud 4.0.0 is supported. All functionalities used in earlier versions are supported in the VeloCloud 4.0.0 version. 

  • MnR 7.0 Support:

    • MnR Core version is upgraded to 7.0. All features used in version 6.8u5 are supported in 7.0.

For information about system requirements, hardware requirements, patch installation, and sizing guidelines, see the VMware Telco Cloud Operations Deployment Guide.

Resolved Issues

  • VMware Telco Cloud Operations v1.0 does not support integration to SAM server that has the CAS authentication setup for EDAA API.

    Workaround: Install a new SAM on a different path and start a new EDAA instance (Tomcat server) on a different port (port 1), without CAS authentication. The new EDAA instance points to the same SAM presentation server that the MnR integrates with using EDAA on a default port with CAS authentication.

    VMware Telco Cloud Operations connects to SAM-PRES using EDAA:port-1 without CAS authentication and MnR connects to the same SAM-PRES using EDAA:portdefault with CAS authentication.

    Note:
    You must modify the following lines in the server.xml file of the new SAM installation, to point to the new server ports.

    a. Server port="9005" shutdown="SHUTDOWN"
    b. Connector port="8090" protocol="HTTP/1.1"

    And, to start the Tomcat server, run the command ./sm_tomcat --output &

  • The time stamp displayed for the Notifications in the Notification Log View and in the Notification Browse > Details are different.

    The time stamp displayed for the Notifications  (for example: Last Notify, Last Clear, etc) are different in the Notification Log View when compared to the displayed in the Notification > Browse Detail > Details windows.

Known Issues

  • A possible cause for the deployment to fail is when you use the automated deployment tool.

    When you deploy VMware Telco Cloud Operations using the automated deployment tool, the deployment of the worker node may fail with the error: Failed to send data.

    Workaround: Modify the VCENTER_IP configuration parameter in the deploy.settings file to use the fully qualified domain name (FQDN). For more information about modifying the deploy.settings file, see the VMware Telco Cloud Operations Deployment Guide.

  • When the number of hops of connectivity is increased, you may experience performance issues in the topology maps.

    There might be performance issues in the rendering of  Redundancy Group, MPLS, Metro-E, and SDN connectivity map types in the Map Explorer view. This issue is observed on deployments with a complex topology where the topology maps may stop working when the number of hops of connectivity is increased.

  • When you create a Metrics Collector with incorrect inputs for Smart Assurance, it indicates that the collector is running, even though the connection is not established.

    When you provide an incorrect input during collector configuration, the collector appears to have started but it does not start. Verify the log to check the actual collector status.

  • VMware Telco Cloud Operations v1.0 does not support the SAM server with broker authentication, Edge Kafka authentication, and Smarts EDAA authentication. However, it exposes database ports for debugging purpose.

    For a workaround, see the Security Recommendation section in the VMware Telco Cloud Operations Deployment Guide.

    Note: EDAA related operations including the Acknowledge, Ownership, Server Tools, Browse Details > Containment and Browse Details > Domain Manager are not supported when Smarts Broker is configured in secure mode.

  • The Containment, Browse detail, Notification Acknowledge/Unacknowledge does not work when the primary Tomcat server fails in a Smart Assurance HA environment.

    In a Smart Assurance Failover deployment, when the primary Tomcat fails, the UI operations including the Notification Acknowledgement, Containment, Browse Detail, and Domain Managers fail.

    Workaround: When the primary Tomcat instance fails in a Smart Assurance failover environment, then you can manually point the VMware Telco Cloud Operations to a secondary Tomcat instance.
    Procedure:

    1. Go to https://IPaddress of the Control Plane Node.
    2. Navigate to Administration > Configuration > Smarts Integration
    3. Delete the existing Smarts Integration Details.
    4. Re-add the Smarts Integration Details by editing the EDAA URL and pointing it to the secondary Tomcat Instance.
  • Broker failover is not supported in VMware Telco Cloud Operations v1.0.

    Primary Broker fails in the Smart Assurance failover environment.

    Workaround: Currently when a Broker (multi-broker) failover happens in Smart Assurance, then it requires a manual intervention where you need to log in to VMware Telco Cloud Operations and change the Broker IP address to point to the new Broker IP.
    Procedure:

    1. Go to https://IPaddress of the Control Plane Node.
    2. Navigate to Administration > Configuration > Smarts Integration
    3. Delete the existing Smarts Integration Details.
    4. Re-add the Smarts Integration Details by pointing it to secondary Broker.
  • The deployment will fail when a node uses an IPv6 address rather than an IPv4 address.

    An error message appears when a deployment fails.

  • Any notifications in VMware Telco Cloud Operations have the serial number column with one empty row under the Audit Log tab.

    In an Elasticsearch database, a zero value is not saved and displays an empty row.

  • VeloCloud notifications are not appearing in the SDWAN Notification panel of SD-WAN Dashboard without enrichment.

    Workaround:

    1. Select Edit from the drop-down, in the SDWAN Notification panel.
    2. In the next page edit the query which has the AND to OR.
    UserDefined20.keyword:$Tenant AND ((ElementClassName.keyword:VEdge) OR (ClassDisplayName.keyword:"VGateway" OR ClassDisplayName.keyword:"Tenant" OR ClassDisplayName.keyword:"vEdge" OR ClassDisplayName.keyword:"Orchestrator" OR ClassDisplayName.keyword:"VEdge" OR ClassDisplayName.keyword:"Tunnel") OR (InstanceName.keyword:vSmart OR InstanceName.keyword:vBond OR InstanceName.keyword:vManage))​

  • Statistics - Tunnel reports for SDWAN displays unknown elastic error, if the specific device is not selected in Edge filter.

    Workaround: To avoid the error, remove ALL option for Edge.

    Procedure to disable the ALL option: Statistics Tunnel > Dashboard Settings > Variables > Edge > Disable Include All option.

  • When Smarts is restarted without repos for multiple times, the Viptela ControlNode controller status is going to OTHER/UNKNOWN state.

    Workaround: Use below command in control plane node to delete the respective Viptela stale collectors:

    kubectl delete deployments.apps <viptela deployment app instance>
     

  • VMware Telco Cloud Operations Health Status Pod report displays empty value for some pods. They indicate that some pods ran for sometime, consumed some CPU and Memory resources, but no longer exist.

    Workaround: To select a small range, you can go to the Gear icon on the top right of the reports and uncheck the option Hide time picker and go back to the reports.

  • In VMware Telco Cloud Opeartions HA environment, import-ldap-cert.sh is failing to import LDAP certificates. If the keycloakserver is switched to different node(from CPN to kafkaworker or kafkaworker to CPN)during script execution for the first time

    Workaround : Re-import LDAP certificates to keycloak using import-ldap-cert.sh, if pod switch happens to different node:

    1.Ensure that, which node keycloak is running before and after importing LDAP certificates using import-ldap-cert.sh

    kubectl get pods -o wide | grep keycloak

    2.If node is different, then verify if the LDAP cert is actually imported:

    ./import-ldap-cert.sh  -l -s <store password>

    3.If it does not display the truststore information, re-import the certificates.

  • Weekly indexes are not displayed while creating custom reports, only daily and hourly index are shown part of reports.

    Workaround:

    1. Select  Configurations > Data Sources from the left side menu bar
    2. Click Add Data Source.
    3. Select Elasticsearch.
    4. Enter relevant name based on the metric-type for which the weekly index needs to be created (for example: Week-Network-Interface) and the Elastic http url as  http://elasticsearch:9200, refer any other VMware Telco Cloud Operations data sources
    5. Enter Index Name based on the metric type for which the weekly index needs to be create ([vsametrics-week-networkinterface-]YYYY.MM) and select Pattern "Monthly"
    6. Enter the Time Field Name timestamp and Version 7+.
    7. Keep the rest of the fields to default  value.
    8. Click Save & Test.

  • Notification count mismatch between SAM and VMware Telco Cloud Operations UI due to non-filtering of notification with Owner field set to SYSTEM​. By default in VMware Telco Cloud Operations there are no filters set. ​

    Workaround: Manually apply the filter to remove notifications with Owner field not containing SYSTEM in VMware Telco Cloud Operations Notification Console window by following below steps:

    1. Go to Default Notification Console.
    2.  Click Customize View.
    3. Go to Filters and provide Filter Set Name, for example Filterout SYSTEM Notifications.
    4. Filter Section Add Attribute with below condition:

      Property = Owner

      Expression = regex

      Value = ~(SYSTEM+)

    5. Click Update.

    Verify the Default Notification Console has only those notifications whose owner not set to SYSTEM. The default notification count must match between SAM and VMware Telco Cloud Operations UI.

  • When Multitenancy is configured, currently Data Enrichment also has to be configured in order for the Admin dashboards to display any data. 

    Regardless of whether Enrichment is configured, the default behavior is that all data is shown on the Admin dashboard views. When a customer desires multi-tenancy, the configuration can be changed to facilitate the dashboard's relevant to multi-tenancy tags.

  • Netflow-9 Statistics, Netfow-9 Trends, Netflow-5 Statistics, and Netflow-5 Trends reports display error message - Failed to parse query with the Default Time interval of 3 hours.

    Workaround: You need to select smaller time intervals. For example: 15 minutes, 30 minutes, 1 hour, etc.

  • When the Kafka server is configured to a wrong IP or the Kafka node goes down during discovery, then the Velocloud discovery hangs for 20 minutes before exiting the discovery. This is the case even when the messagePollTimeout of the VCO Access setting is set to a lower value.

    Workaround: In the esm-param.conf file add the below line replacing the <kafka ip address> and <time in seconds>, and restart the server.

    MessagePollTimeoutPeriodInSeconds-<kafka ip address> <time in seconds>

check-circle-line exclamation-circle-line close-line
Scroll to top icon