The prerequisites for installing the CEE are:

1. Installing the SMI Cluster Manager.

2. Storing the CEE and associated product tarballs in the local repository.

3. Applying the necessary cluster configuration for bringing the Kubernetes Cluster on the target nodes.

All the versions of CEE.

The following components are used for installing the CEE:

1. The SMI Cluster Manager.

2. The SMI CEE.

You can install the CEE using the SMI Cluster Manager CLI. To install CEE, use the following configurations:

1. Login to the SMI Cluster Manager CLI (using the ingress URL) and enter the configuration mode.

   
   https://cli.smi-cluster-manager.<IP_address>.<customer_specific_domain_name> 
   

2. Use the following configuration to install the CEE in offline mode.

   configure 
     software cnf software_name 
       url HTTP_HTTPS_File_URL 
       user username 
       password password 
       sha256 sha256_hash 
       exit 

   Note	For offline installation, you must download the CNF software package from the repository.

   Use the following configuration to install the CEE in online mode.

   configure 
     repository repo_url 
     username username 
     password password 
     sha256 sha256_hash 
     exit 

3. Link the CEE into the desired cluster in the ops-centers .

   configure 
     clusters cluster_name ops-center app_name instance_name 
     repository repo_url 
     username username 
     password password 
   
     secrets docker-registry <docker_secret_registry> 
     docker-server docker_server_name 
     docker-username docker_username 
     docker-password docker_password 
     docker-email <email_id@domain.com> 
     namespace <namespace> 
     exit 
     sync-default-repository true 
     netconf-ip <ipv4address> 
     netconf-port <portnumber> 
     ssh-ip <ipv4address> 
     ssh-port <portnumber> 
     ingress-hostname <ipv4address>.nip.io 
     initial-boot-parameters use-volume-claims true 
     initial-boot-parameters first-boot-password password 
     initial-boot-parameters auto-deploy true 
     initial-boot-parameters single-node true 
     initial-boot-parameters image-pull-secrets <secret_name> 
     exit 
   exit 

4. Run the cluster synchronization to deploy the CEE Ops Center and wait for the synchronization to complete.

   clusters cluster_name actions sync run 

5. Verify the cluster synchronization through cluster sync status or log commands.

   clusters cluster_name actions sync status 
   clusters cluster_name actions sync logs 

   NOTES:

   • customer_specific_domain_name - Specifies the customer's domain name.

   • software cnf software_name - Specifies the Cisco's Cloud Native software. software_name is the name of the Cloud Native software.

     • url HTTP_HTTPS_File_URL - Specifies the repository URL.

     • user username - Specifies the username for HTTP/HTTPS authentication.

     • password password - Specifies the password used for downloading the software package.

     • sha256 sha256_hash - Specifies the SHA256 hash of the software download.

   • repository repo_url - Specifies the CNF repository.

   • clusters cluster_name actions sync run - Synchronizes the committed changes to the cluster.

   • clusters cluster_name actions sync status - Displays the status of the cluster synchronization.

   • clusters cluster_name actions sync logs - Displays the logs generated during the cluster synchronization process.

Cisco Software Central (CSC) enables the management of software licenses and Smart Account from a single portal. The interface allows you to activate your product, manage entitlements, and renew and upgrade software. A functioning Smart Account is required to complete the registration process. To access the Cisco Software Central, see https://software.cisco.com.

A Smart Account provides a single location for all Smart-enabled products and entitlements. It helps speed procurement, deployment, and maintenance of Cisco Software. When creating a Smart Account, you must have the authority to represent the requesting organization. After submitting, the request goes through a brief approval process.

A Virtual Account exists as a sub-account withing the Smart Account. Virtual Accounts are a customer-defined structure based on organizational layout, business function, geography or any defined hierarchy. They are created and maintained by the Smart Account administrator.

See https://software.cisco.com to learn about, set up, or manage Smart Accounts.

At present, the Smart Licensing feature supports application entitlement for online and offline licensing for CEE. The application usage is unrestricted during all stages of licensing including Out of Compliance (OOC) and expired stages.

Note	A 90 day evaluation period is granted for all licenses in use. Currently, the functionality and operation of the CEE is unrestricted even after the end of the evaluation period.

Tags for the following software and entitlements have been created to identify, report, and enforce licenses.

Software Tags

Software tags uniquely identify each licenseable software product or product suite on a device. The following software tags exist for the CEE.

Entitlement Tags

The following entitlement tags identify licenses in use:

Note	The license information are retained during software upgrades and rollback.

You can configure Smart Licensing after a new CEE deployment.

You can use the following show commands to display information about Smart Licensing in the CEE Ops Center.

show licesne [all | UDI | displaylevel | reservation | smart | status | summary | tech-support | usage] 

NOTES:

• all – Displays an overview of Smart Licensing information that includes license status and, usage, product information and Smart Agent version.

• UDI – Displays Unique Device Identifiers (UDI) details.

• displaylevel – Depth to display information.

• reservation – Displays Smart Licensing reservation information.

• smart – Displays Smart Licensing information.

• status – Displays the overall status of Smart Licensing.

• summary – Displays a summary of Smart Licensing.

• tech-support – Displays Smart Licensing debugging information.

• usage – Displays the license usage information for all the entitlements that are currently in use.

To upgrade the CEE Ops Center, use the following configurations:

1. Use the following configuration to modify the CEE Ops Center to point it to the new tarball.

   
   configure 
        cluster cluster_name 
            ops-centers app_name instance_name 
            repository repo_url 
            username username 
            password password 
            initial-boot-parameters auto-deploy true 
            exit 
        commit 
   

2. Run the cluster synchronization to upgrade the CEE Ops Center.

   Note	Ensure that you enable auto deploy for the CEE products that are being updated.

   clusters cluster_name actions sync run 
   

3. Verify whether the helm charts have been updated through the CEE Ops Center.

   show helm charts 
   

   A sample output is shown below:

   CHART         INSTANCE                          STATUS    VERSION     REVISION RELEASE                                   NAMESPACE 
   ------------------------------------------------------------------------------------------------------------------------------------------- 
   cee-ops-center         cee-global-ops-center             deployed  2023.02.1.d249  1   0.7.0-2023-02-1-0513-230331051211-dec612f  cee-global 
   cnat-monitoring        cee-global-cnat-monitoring        deployed  2023.02.1.d249  1   0.7.0-2023-02-1-0031-230331183330-58ec41c  cee-global 
   product-documentation  cee-global-product-documentation  deployed  2023.02.1.d249  1   0.8.0-2023-02-1-0131-230321085503-2699cb5  cee-global 
   pv-manager             cee-global-pv-manager             deployed  2023.02.1.d249  1   0.3.0-2023-02-1-0029-230320155437-e484272  cee-global 
   smi-autoheal           cee-global-smi-autoheal           deployed  2023.02.1.d249  1   0.2.0-2023-02-1-0030-230330084451-99684bf  cee-global 
   smi-show-tac           cee-global-smi-show-tac           deployed  2023.02.1.d249  1   0.4.0-2023-02-1-0189-230331050005-81130f1  cee-global 
   storage-provisioner    cee-global-storage-provisioner    deployed  2023.02.1.d249  1   0.3.0-2023-02-1-0120-230320160505-1597fdb  cee-global 
   telegraf-monitoring    cee-global-telegraf-monitoring    deployed  2023.02.1.d249  1   0.1.0-2023-02-1-0048-230330084426-9b02da0  cee-global 

4. Verify the status of the system.

   show system status 
   

   A sample output is shown below:

   system status deployed true 
   system status percent-ready 91.3 

   NOTES:

   • cluster cluster_name - Specifies the name of the cluster. For example, aio.

   • ops-centers app_name instance_name - Specifies the installation of the Ops Center. app_name is the name of the application. For example, cee.The instance_name is the name of the instance. For example, global.

   • username username - Specifies the username used for logging in to the repository.

   • password password - Specifies the password used for logging into the repository.

   • repository repo_url - Specifies the product chart repository URL.

   • initial-boot-parameters auto-deploy true – Deploys the product chart automatically.

   • commit - Commits the configuration changes.

   • show helm status - Displays the status of the system.

   • clusters cluster_name actions sync run - Synchronizes the committed changes to the cluster.

To upgrade the CEE products, use the following configurations:

1. Access the CEE Ops Center through the ingress URL.

   
   https://cli.cee-global-ops-center.<ipv4_address>.<customer_specific_domain_name> 
   

   NOTES:

   • customer_specific_domain_name - Specifies the name of the domain specific to the customer.

2. Use the following configuration to update the CEE products chart URL.

   configure 
               helm default-repository repo_name 
               helm repository repo_name 
               url cee_product_chart_url 
               username username 
               password password 
               exit 
            commit 
   

   NOTES:

   • customer_specific_domain_name - Specifies the name of the domain specific to the customer.

   • helm default-repository repo_name - Specifies the default helm repository name.

   • helm repository repo_name - Specifies the name of the helm repository to update.

   • url cee_product_chart_url - Specifies the product chart URL. For example, http://charts.<ipv4address>.<domain_name>/cee-2019-09-13/

   • username username - Specifies the user name.

   • password password - Specifies the password.

   • commit - Commits the configuration changes.

For configuring alerts:

1. The CEE product must be installed and running.

2. The CEE Ops Center must be accessible.

Use the following configuration to configure the alert rules.

configure 
   alerts rules group alert_group_name 
   interval-seconds seconds 
   rule rule_name 
      expression promql_expression 
      duration duration 
      severity severity_level 
      type alert_type 
      annotation annotation_name 
      value annotation_value 
      exit 
exit 

NOTES:

• alerts rules – Specifies the Prometheus alerting rules.

• interval-seconds seconds – Specifies the evaluation interval of the rule group in seconds.

• group alert_group_name – Specifies the Prometheus alerting rule group. One alert group can have multiple list of rules. alert_group_name is the name of the alert group. The alert-group-name must be a string in the range of 0 through 64 characters.

• rule rule_name – Specifies the alerting rule definition. rule_name is the name of the rule.

• expression promql_expression – Specifies the PromQL alerting rule expression. promql_expression is the alert rule query expressed in PromQL syntax. The promql_expression must be a string.

• duration duration – Specifies the duration of a true condition before it is considered true. duration is the time interval before the alert is fired.

• severity severity_level – Specifies the relative level of urgency for the operator's attention. severity_level is the severity level of the alert. The severity levels are: critical, major, minor and warning.

• type alert_type – Specifies the type of the alert. alert_type is the user-defined alert types. For example, Communications Alarm, Environmental Alarm, Equipment Alarm, Indeterminate Integrity Violation, Operational Violation, Physical Violation, Processing Error Alarm, Quality of Service Alarm, Security Service, Mechanism Violation, or Time Domain Violation.

• annotation annotation_name – Specifies the annotation to attach to the alerts. annotation_name is the name of the annotation.

• value annotation_value – Specifies the annotation value. annotation_value is the value of the annotation.

The following example monitors the success rate of SMF session creation by configuring Prometheus alert rule to report if session creation is less than threshold.

cee# configure terminal
  alerts rules group SMFProcStatus
  interval-seconds 300
  rule PDNSessCreate
  expression "sum(increase(smf_service_stats{app_name=\"SMF\",procedure_type=\"pdn_sess_create\",status=\"success\"}[5m]))  / sum(increase(smf_service_stats{app_name=\"SMF\",procedure_type=\"pdn_sess_create\",status=\"attempted\"}[5m])) < 0.95"
  severity   major
  type       "Communications Alarm"
  annotation summary
  value "This alert is fired when the success percentage of pdn_sess_create procedure is lesser threshold”
  exit

In the following example, a alert is sent as SNMP Trap to receiving agent when a snmp-trapper is configured.

cee# configure terminal
  snmp-trapper enable true v2c-target 172.16.181.41 community public port 161
  exit

The following example configures an alert, which is fired when the percentage of UDM responses is less than the specified threshold limit.

Example:

cee# configure terminal
		alerts rules group SMFUDMchk_incr
		interval-seconds 300
		rule SMFUDMchk_incr
		expression "sum(increase(smf_restep_http_msg_total{nf_type=\"udm\", message_direction=\"outbound\", response_status=~\"2..\"}[3m])) /  sum(increase(smf_restep_http_msg_total{nf_type=\"udm\", message_direction=\"outbound\"}[3m])) < 0.95"
		severity major
		type "Communications Alarm"
		annotation summary
		value "This alert is fired when the percentage of UDM responses is less than threshold“
		exit
	exit
exit

You can view the configured alert using the show running-config alerts command.

Example:

The following example displays the alerts configured in the running configuration:

cee# show running-config alerts
               interval-seconds 300
               rule SMFUDMchk_incr
               expression "sum(increase(smf_restep_http_msg_total{nf_type=\"udm\", message_direction=\"outbound\", response_status=~\"2..\"}[3m])) /  sum(increase(smf_restep_http_msg_total{nf_type=\"udm\", message_direction=\"outbound\"}[3m])) < 0.95"
               severity major
               type "Communications Alarm"
               annotation summary
               value "This alert is fired when the percentage of UDM responses is less than threshold“              
	   exit
      exit
exit

The ETCD runs on separate nodes in a multi-node environment as opposed to a container within Kubernetes environment. A Node-Exporter runs on each of the ETCD nodes to obtain host level metrics. Also, the CEE Prometheus starts scrapping the metrics automatically after deployment.

You can create alerting rules based on the ETCD Node-Exporter metrics. To configure alerting rules based on ETCD Node-Exporter metrics, use the ETCD Node IP as the instance label instead of the Pod name in the expression.

Important

The Node-Exporter on ETCD is not running as a Kuberenets Pod.

The following examples configure alerting rules based on ETCD Node-Exporter metrics.

Example:

The following expression configures alerts based on the availability of host memory (less than 30%):

((node_memory_MemAvailable_bytes{{{instance="<ETCD-Node-IP>:9100"}}} / node_memory_MemTotal_bytes{{{instance="<ETCD-Node-IP>:9100"}}}) < 30

The following expression configures alerts based on the average CPU usage for five minutes. (greater than 70%):

sum(avg without (cpu)(irate(node_cpu_seconds_total{instance="<ETCD-Node-IP>:9100",mode!="idle"}[5m]))) * 100 > 70

The CEE Ops Center comes equipped with a built-in alert rule - helm_deploy_failure - to indicate the failure status of helm chart deployment. This alert rule comes by default as a Prometheus alerting rule during CEE deployment.

The following is an alert rule definition for helm_deploy_failure alert in Prometheus:

- alert: helm-deploy-failure
    annotations:
      type: Processing Error Alarm
      description: 'Helm chart {{$labels.chart}}/{{$labels.namespace}} deployment failed'
      summary: 'Helm chart failed to deploy for 5 minutes'
    expr: |
      helm_chart_deploy_success < 1
    labels:
      severity: critical
    for: 5m

The following example shows an alert generated when helm chart deployment fails.

alerts active helm-deploy-failure 3edde79a3f86
state active
severity critical
type "Processing Error Alarm"
startsAt 2020-04-17T17:55:57.084Z
source tfchan-dev
labels [ "chart: smi-show-tac" "chartVersion: 0.1.0-helmfail-0108-200310183805-6888120" "component: ops-center" "exported_release: cee-smi-show-tac" "instance: 192.168.190.28:8082" "job: kubernetes-pods" "namespace: cee" "pod: ops-center-cee-ops-center-5ccddd5d9f-6rffw" "pod_template_hash: 5ccddd5d9f" "release: cee-ops-center" ]
annotations [ "description: Helm chart smi-show-tac/cee deployment failed" "summary: Helm chart failed to deploy for 5 minutes" ]

Note	If SNMP Trapper is configured, this alert goes to the external SNMP receiver as an SNMP trap. For instance, when there is already a conflict of resources, the Helm deployment fails.

The Alert Logger stores all the generated alerts by default. You can view the stored alerts using the following show commands.

show alert history { detail | summary }

show alert active { detail | summary }

You can narrow down the result using the following filtering options:

• annotations – Specifies the annotations of the alert.

• endsAt – Specifies the end time of the alert.

• labels – Specifies the additional labels of the alert.

• severity – Specifies the severity of the alert.

• source – Specifies the source of the alert.

• startsAt – Specifies the start time of the alert.

• type – Specifies the type of the alert.

You can view the history of configured alerts using show alerts history command.

The following examples displays the history of the alerts configured in the system:

cee# show alerts history summary
NAME UID SEVERITY STARTS AT DURATION SOURCE SUMMARY
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
k8s-pod-crashing-loop 13218bfedfb7 critical 11-02T19:42:40 3m50s upf-cm-tb16-2-cm1 Pod cee-global/alert-logger-56f85f54df-wdpbp (alert-logger) is restarting 1.01 times / 5 minutes.
k8s-pod-crashing-loop bf8f6b0e167c critical 11-02T19:42:40 3m50s upf-cm-tb16-2-cm1 Pod cee-global/pgpool-5cc9d4b44f-4kklz (pgpool) is restarting 1.01 times / 5 minutes.
k8s-pod-crashing-loop 840f362e970e critical 11-02T19:42:40 3m50s upf-cm-tb16-2-cm1 Pod cee-global/grafana-5b9779c7d6-hmptk (grafana) is restarting 1.01 times / 5 minutes.
k8s-pod-crashing-loop 40f4de09d667 critical 11-02T19:42:30 3m50s upf-cm-tb16-2-cm1 Pod cee-global/pgpool-5cc9d4b44f-gwdpp (pgpool) is restarting 1.01 times / 5 minutes.
k8s-pod-not-ready 3ade1624bfa8 critical 11-02T19:40:40 40s postgres-0 Pod cee-global/postgres-0 has been in a non-ready state for longer than 1 minute.

The following examples displays a detailed history of the alerts configured in the system:

cee# show alerts history detail
alerts history detail k8s-pod-crashing-loop 13218bfedfb7
severity critical
type "Processing Error Alarm"
startsAt 2020-11-02T19:42:40.400Z
endsAt 2020-11-02T19:46:30.400Z
source upf-cm-tb16-2-cm1
summary "Pod cee-global/alert-logger-56f85f54df-wdpbp (alert-logger) is restarting 1.01 times / 5 minutes."
labels [ "alertname: k8s-pod-crashing-loop" "cluster: upf-cm_cee-global" "component: kube-state-metrics" "container: alert-logger"
 "hostname: upf-cm-tb16-2-cm1" "instance: 192.168.211.203:8080" "job: kubernetes-pods" "monitor: prometheus" 
"namespace: cee-global" "pod: alert-logger-56f85f54df-wdpbp" "pod_template_hash: db7bf9f7" 
"release: cee-global-cnat-monitoring" "replica: upf-cm_cee-global" "severity: critical" ]
annotations [ "summary: Pod cee-global/alert-logger-56f85f54df-wdpbp (alert-logger) is restarting 1.01 times / 5 minutes."
 "type: Processing Error Alarm" ]

You can view the active using the show alerts active command.

show alerts active summary
NAME UID SEVERITY STARTS AT SOURCE SUMMARY
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
server-alert 02232d49cccd minor 10-29T06:09:04 upf-4 PS_RDNDNT_MODE: Power Supply redundancy is lost or non-redundant: Check Redundancy Policy or reseat/replace Power Supply
server-alert f97ec27bc318 minor 10-29T06:09:04 cm-2 PS_RDNDNT_MODE: Power Supply redundancy is lost or non-redundant: Check Redundancy Policy or reseat/replace Power Supply
watchdog 0dbfe73527ad minor 10-29T06:07:58 System This is an alert meant to ensure that the entire alerting pipeline is functional. This alert is always firing, therefore it should always be firing...

show alerts active detail
alerts active detail server-alert 359fe8fd1dd8
severity warning
type "Equipment Alarm"
startsAt 2020-10-29T06:09:04.243Z
source cm-2
summary "Storage Virtual Drive 0 Degraded: please check the storage controller, or reseat the storage drive"
labels [ "alertname: server-alert" "cluster: tb16-2" "description: Storage Virtual Drive 0 Degraded: 
please check the storage controller, or reseat the storage drive" "fault_id: sys/rack-unit-1/board/
storage-SAS-MRAID/vd-0/fault-F1008" "id: 3523411968" "monitor: prometheus" "replica: tb16-2" 
"server: cm-2" "severity: warning" ]
annotations [ "dn: tb16-2/cm-2/sys/rack-unit-1/board/storage-SAS-MRAID/vd-0/fault-F1008/3523411968" 
"summary: Storage Virtual Drive 0 Degraded: please check the storage controller, or reseat the 
storage drive" "type: Equipment Alarm" ]

Use the following configuration to enable the SNMP Traps.

configure 
   snmp-trapper enable true 
   snmp-trapper { v2c-target target | v3-target target | v3-engine-id source_engine_id }  
      community [ community_string ] 
      port [ port ] 
      exit 
   snmp-trapper source-ip-routes [ vip_options ] 
   exit 

NOTES:

• snmp-trapper enable true – Enables the snmp-trapper parameters

• v2c-target|v3-target [ target ] – Specifies the list of SNMP v2c and v3 trap receivers.

• community [ community_string ] – Specifies the SNMP Trap receiver community.

• v3-engine-id source_engine_id – Specifies the source engine ID for the v3 traps. source_engine_id must be an hexagonal string. For instance, 80004f.

• port [ port ] – Specifies the SNMP Trap receiver port. port must be an integer in the range of 0 through 65535. The default value is 162.

• source-ip-routes [ vip_options ] – Enables binding to source IP for SNMP routing. vip specifies the virtual IP (VIP) address. The different options for virtual IP addresses include:

  • default-external-vip – Specifies the default external VIP for source IP routing.

  • internal-vip – Specifies the internal VIP for source IP routing.

  • source-external-vips -Specifies the external VIP per namespace.

Use the following configuration to disable SNMP Traps.

configure 
   no snmp-trapper enable 
   exit 

NOTES:

• no snmp-trapper enable - Disables SNMP Traps.

You can access Grafana login page through Ingress using any of the standard web browsers. For instance, using Google Chrome navigate to the Grafana login page with the following Ingress URL:

https://grafana.<ipv4_address>.<customer_specific_domain_name>

NOTES:

• customer_specific_domain_name - Specifies the customer's domain name.

Important

Authentication to Grafana happens through the CEE Ops Center since Grafana is associated with it. If the CEE Ops Center is configured with Lightweight Directory Access Protocol (LDAP), Grafana authenticates through LDAP.

Important

Third-Party Software Vulnerability - The Content Security Policy support in Grafana uses the unsafe-eval version of script-src because AngularJS is not fully migrated in Grafana.

The Grafana home page lists the dashboards bundled with CEE. The dashboards provide an overall status of the system.

To view the dashboards, perform the following steps:

1. Navigate to the Grafana Login page using any standard web browser.

2. Login to Grafana to view the home page.

   

3. Click icon on the left pane.

4. Click Dashboards.

   1. By default, you can view the following dashboards.

      1. Host Summary – This dashboard provides an overview of CPU, Memory, Disk I/O Utilization, Filesystem Fullness and Filesystem Fill UP time. You can choose the machine from Machine drop-down list to view the host summary of individual machines available in the clusters.

      2. Host Details – This dashboard provides a detailed view on each of the following categories:

         - Basic CPU/ Mem / Disk Gauge

         - Basic CPU/ Mem / Disk Info

         - Basic CPU / Mem Graph

         - Basic Net / Disk Info

         - CPU Memory Net Disk

         - Memory Detail Meminfo

         - Memory Detail Vmstat

         - Memory Detail Vmstat Counters

         - System Detail

         - Disk Detail

         - Filesystem Detail

         - Network Traffic Detail

         - Network Sockstat

         - Network Netstat

         - Network Netstat TCP

         - Network Netstat TCP Linux MIPs

         - Network Netstat UDP

         - Network Netstat ICMP

         - Node Exporter

You can create new Dashboards or Data Sources in Grafana through settings tab.

Important

The bundled dashboards are provisioned statically and cannot be modified. However, you can copy or clone the dashboards before saving the changes.

The following example imports custom Grafana dashboard from a Git repository.

cee# configure terminal
  grafana dashboards sample
  git-url https://wwwin-github.cisco.com/mobile-cnat-sample/sample-dashboards.git
  exit

Persistent Grafana Dashboards

The custom Grafana dashboards are made persistent so that the dashboards are not lost during pod restart, node shutdown or any upgrade. The Grafana dashboards are stored in the /mnt/stateful_partition/data/cee-global/data-postgres-x directory.

The Grafana pod has built-in APIs to manipulate the dashboard resources. These APIs will allow the user to perform the following functions:

• Export or backup all Grafana dashboards as files

• Restore Grafana dashboards from backup

• Create a new Grafana dashboard

• Modify the existing Grafana dashboard

• Authenticate API using basic authentication

The valid users of the dashboards are either local users or TACACS users who have access to CEE Ops Center. You can configure the grafana enable-basic-auth { true | false } CLI in CEE Ops Center to enable or disable basic authentication. When enabled, you can perform all CRUD operations on the dashboards with the existing Grafana HTTP API.

You can create and manage the local users and user groups through the CEE Ops Center as described in the Provisioning Local Users section.

SMI allows a Kubernetes ingress resource with basic authentication to be added to Prometheus using Grafana. This allows SMI metrics to be used as a data source by an external Grafana instance.

1. Login to Grafana User Interface.

2. Select Configuration Data Sources.

3. Click Add data source.

4. Enter a name for the data source in the Name field.

5. Select Type Prometheus.

6. Enter the new ingress URL (e.g. prometheus-xxx) in the URL.

7. Enable and configure Basic Auth

8. Provide the same credentials as configured via the SMI Ops Center in the User and Password fields under Basic Auth Details.

9. Enable Skip TLS Verify and keep the remaining options as it is.

10. Click Save &Test. The result should be successful and the data source is ready to use.

This chapter describes how to create and manage local users using the Ops Center CLI (for both the products and SMI Cluster Manager Ops Center).

Important

Users with administrator privileges can add, modify, and delete other users and groups. All the other users only have privileges to change their own password.

This chapter describes how to create and manage user groups using the Ops Center CLI (of both the products and SMI Cluster Manager).

You can enable Log Forwarding in CEE to forward log entries to the external collectors. You must ensure that the K8s cluster is installed in the CEE before enabling Log Forwarding.

The following are the requirements for enabling Log Forwarding:

Fluent-x

1. The target endpoint must be a Fluentbit or FluentD instance or cluster with the Forward protocol input plugin enabled.

2. The endpoint must be hosted within the Kubernetes clusters or a remote system with network reachability.

Enabling Log Forwarding on Fluent-x

This section describes the procedure involved in enabling Log Forwarding on Fluent-x and Splunk.

This section describes the procedure involved in enabling Log Forwarding on Fluent-x.

Use the following configuration to enable Log Forwarding on Fluent-x.

configure 
logging fluent host fluentbit/fluentd_endpoint_fqdn/ipv4_address port endpoint_port 

NOTES:

• logging fluent – Specifies the Fluent forwarding parameters.

• host fluentbit/fluentd_endpoint_fqdn/ipv4_address – Specifies the Fluentbit or Fluentd instance host information.

• port endpoint_port – Specifies the Fluentbit or Fluentd instance port information.

The log forwarding to an external Fluent-D or Fluent-Bit instance, where logs can be streamed to supporting application such as ElasticSearch.

cee# configure terminal
  logging fluent host 172.16.181.41 port 8001
  exit

Enabling Log Forwarding on Splunk

Use the following configuration to enable Log Forwarding on Splunk.

configure 
	   logging splunk host splunk_endpoint_fqdn/ipv4_address port hec_port auth-token splunk_configured_token 

NOTES:

• logging splunk – Specifies the Splunk endpoint.

• host splunk_endpoint_fqdn/ipv4_address – Specifies the Splunk host information.

• port hec_port – Specifies the Splunk port information.

• auth-token splunk_configured_token – Specifies the Splunk Authentication Token for the HTTP Event Collector interface.

The following example configures log forwarding to an external Splunk server.

cee# configure terminal
  logging splunk host 172.16.181.41 port 8001
  exit

Use the following configuration to enable Log Forwarding from StarOS.

configure  
  logging 
    syslog cee_ops_center_listener_ip_address 
    facility local5  
    msg-format rfc5424  
    commit 
    

NOTES:

• syslog - Specifies the syslog messages.

• cee_ops_center_listener_ip_address - Specifies the CEE Ops Center Listener IP address.

• facility local5 - Specifies the syslog facility values.

• msg-format rfc5424 - Specifies the syslog message format.

You can configure the CEE Ops Center to listen to the logs from StarOS.

Use the following configuration to configure CEE Ops Center as listener:

configure  
  logging 
    listener enable 
    external-ip cee_ops_center_listener_ip_address 
    commit 
  

NOTES:

• listener enable - Enables the CEE Ops Center to listen to the logs from StarOS.

• external-ipcee_ops_center_listener_ip_address - Specifies the CEE Ops Center Listener IP address.

You can configure Fluent-Bit to send logs to Fluent-D. When the Fluent-D receives the logs, it forwards the receibed logs to Splunk.

To configure Fluent-D to support Splunk, use the following configuration:

configure 
   logging splunk host splunk_host 
   logging splunk port splunk_port 
   logging splunk auth-token auth_token 

NOTES:

• logging splunk host splunk_host —Specify the Splunk host information.

• logging splunk port splunk_port—Specify the Splunk port information.

• logging splunk auth-token auth_token—Specify Splunk Authentication Token for the HTTP Event Collector interface.

You can configure Fluent-Bit to send logs to Splunk. This configuration is applicable only when you configure the local cluster as the as the Listener and the remote cluster in remote forwarding mode.

When you configure Fluent-Bit to support Splunk, the local logs are sent to Splunk using Fluent-Bit and the remote logs are sent to the fluent listener (Fluent-Bit). The Fluent-Bit in turn forwards the remote logs to Splunk.

To configure Fluent-Bit to support Splunk, use the following configuration:

configure 
   logging splunk listener enable 
   logging splunk listener external-ip external_vip_ip 
   logging splunk host splunk_host 
   logging splunk port splunk_port 
   logging splunk auth-token auth_token 

NOTES:

• logging splunk listener enable —Enable Fluent-Bit to send logs to Splunk.

• logging splunk listener external-ip external_vip_ip —Specify the external virtual IP address of the local cluster.

• logging splunk host splunk_host —Specify the Splunk host information.

• logging splunk port splunk_port—Specify the Splunk port information.

• logging splunk auth-token auth_token—Specify the Splunk Authentication Token for the HTTP Event Collector interface.

You can configure Fluent-Bit to send logs to the remote cluster.

To configure Fluent-Bit to support remote forwarding, use the following configuration:

configure 
  logging fluent host remote_cluster_ip 
  logging fluent port remote_cluster_port 
  logging fluent protocol forward 

NOTES:

• logging fluent host remote-cluster-ip —Specify the Fluent-Bit host information.

• logging fluent port remote-cluster-port —Specify the Fluent-Bit port information.

• logging fluent protocol outbound_protocol —Specify the outbound protocol.

You can configure Fluent-Bit to receive logs from the remote cluster.

To configure Fluent-Bit to support remote listening, use the following configuration:

configure 
  logging splunk listner enable 
  logging splunk listner external-ip external_vip_ip 

NOTES:

• logging splunk listner enable —Enable Fluent-Bit to support remote listening.

• logging splunk listner external-ip external_vip_ip —Specify the external virtual IP address of the remote cluster

You can configure Fluent-Bit to send logs to Grafana Cloud.

configure 
   logging grafana-cloud host grafana_cloud_host 
   logging grafana-cloud port grafana_cloud_port 
   logging grafana-cloud http-user http_user 
   logging grafana-cloud http-password http_password 

To configure Fluent HTTP proxy, use the following configuration:

configure 
   logging proxy http-proxy proxy_url 
   logging proxy https-proxy proxy_url 
   logging proxy no-proxy comma_seperated_url 

NOTES:

• logging grafana-cloud host grafana_cloud_host —Specify the host logs.

• logging grafana-cloud port grafana_cloud_port —Specify the host port. The default port is set to 443.

• logging grafana-cloud http-user http_user —Specify the HTTP user information.

• logging grafana-cloud http-password http_password —Specify the HTTP user password.

• logging proxy http-proxy proxy_url —Specify the HTTP proxy URL.

• logging proxy https-proxy proxy_url —Specify the HTTPS proxy URL.

• logging proxy no-proxy comma_seperated_url —Specify the comma-separated domain name.

Labels and Label Keys

To configure the label, use the following configuration:

configure 
   logging grafana-cloud labels key value 
   exit 

To configure the label keys, use the following configuration:

configure 
   logging grafana-cloud labels-keys [ $KEY1,$KEY2 ] 

NOTES:

• By default, the labels for the stream are set to job=fluent-bit, log_source=cndp, hostname={nodeName}.

• You can configure K8s label keys for the log stream such as container name ($k8s_container_name) and namespace ($k8s_namespace_name). The label keys must start with $.

You can configure Fluent-Bit to send logs to the Syslog server. The Syslog messages are sent over UDP, TCP, or TLS in RFC3164 or RFC5424 format.

To configure log forwarding to the Syslog server, use the following configuration:

config 
   logging syslog host server_host  
   logging syslog mode server_mode 
   logging syslog port server_port 
   logging syslog syslog_format syslog_format 
   logging syslog_maxsize syslog_maxsize 
   end 

NOTES:

• logging syslog host server_host —Specify the domain or IP address of the remote Syslog server.

• logging syslog mode server_mode —Specify the TCP, TLS or UDP transport type.

• logging syslog port server_mode —Specify the TCP, TLS or UDP port of the remote Syslog server.

• logging syslog syslog_format syslog_format —Specify the rfc3164 or rfc5424 Syslog protocol format to use.

• logging syslog_maxsize syslog_maxsize —Specify the maximum size allowed per message. The value must be an integer representing the number of bytes allowed.

To enable CEE log forwarding for Fluent worker pods, use the following configuration.

The filters on Fluent worker pods that intake the logs from each node reduce the volume of logs being forwarded.

configure 
   logging worker drop-namespace-logs namespace_names 
   logging worker drop-pod-logs pod_names 
   logging worker exclude-logs-with-annotation true 
   logging worker keep-pod-logs pod_names 
   logging worker keep-namespace-logs namespace_names 
   logging worker drop-os-service-logs service_names 
   logging worker remove-keys [ keys ] 

NOTES:

• logging worker drop-namespace-logs namespace_names —Specify to drop logs by namespaces. namespace_names must be a regex string with selected namespace names inside double quotes.

• logging worker drop-pod-logs pod_names —Specify to drop logs by pods. pod_names must be a regex string with selected pod names inside double quotes.

• logging worker exclude-logs-with-annotation true —Specify to exclude logs from selected pods using annotation.

  Note	After adding or removing annotation from any pod, it is required to restart the fluent-worker pod for the changes to take effect.

• logging worker keep-pod-logs pod_names —Specify to retain logs by pods. pod_names must be a regex string with selected pod names inside double quotes.

• logging worker keep-namespace-logs namespace_names —Specify to retain logs by namespaces. namespace_names must be a regex string with selected namespace names inside double quotes.

• logging worker drop-os-service-logs service_names —Specify to drop logs from selected OS services. The currently supported values for services_names are audit, kernel, or kubelet.

• logging worker remove-keys [ keys ] —Specify to remove keys from log entries. The log entry keys to be dropped are case sensitive.

You must enable the Loki (Grafana) to view all the logs the CEE Ops Center was listening.

Use the following configuration to enable the Loki:

configure  
  logging 
    loki enable 
    retention-period retention_period_in_hours 
    commit 
  

NOTES:

• loki enable - Enables Loki to view to the logs.

• retention-periodretention_period_in_hours - Specifies the retention period of the logs in hours.

You can verify the external collectors for the log entries received. The logs are specific to the external collector. For example, you can use Kibana to verify the entries in ELK stack.

This section provides information on the common issues encountered while enabling log forwarding.

To resolve the issues related to Log Forwarding, verify if:

• The configured endpoint IP/FQDN and port number are correct.

• The external endpoint is reachable from the all Kubernetes nodes (both control plane and worker).

• The Forward protocol plugin is enabled at the endpoint.

• The logs are generated from any of the nodes.

• The external endpoint is configured to dump the logs into a file for verifying the incoming entries.

This section describes the basic principle used in rate limiting log messages in SMI Logging functionality.

Using the Gather TAC function, you can collect logs from the coredump, Kubernetes, Kernel, Kubelet, and container logs. The collected files are compressed and stored in an internal Apache server.

You can configure the Cluster Manager to monitor the remote clusters for alerts. The remote clusters act as a server.

To configure the Cluster Manager for monitoring the remote clusters, use the following configuration:

configure 
  prometheus query-mode server 
    prometheus server-settings external-ip external_vip_ip 
      server-settings ssl-key ssl_eky 
      server-settings ssl-crt ssl_crt 
      server-settings ssl-ca  ssl_ca 

NOTES:

• prometheus query-mode server —Configure the Cluster Manager to monitor the remote clusters for alerts.

• prometheus server-settings external-ip external_vip_ip —Configure the server settings for the specified remote cluster.

• server-settings ssl-key ssl_eky —Specify the SSL key.

• server-settings ssl-crt ssl_crt —Specify the SSL certificate.

• server-settings ssl-ca ssl_ca —Specify the SSL certificate authority.

You can configure the Cluster Manager to monitor the remote clusters. The Cluster Manager acts as a client in this scenario.

To configure the Cluster Manager to collect the alerts from remote clusters:

1. Configure the remote cluster.

   configure 
     prometheus query-mode client 
       federation remote-cluster-certs remote_cluster_IP 

   Example:

   cee# config terminal
   cee(config)# prometheus query-mode client federation remote-cluster-certs 10.84.114.218
   
   name          bxbpod
   
   # SSL multiline raw certificates
   ssl-key       "ssl-key"
   ssl-crt       "ssl-crt"
   ssl-ca        "ssl-ca"

2. Add all the remote clusters to the federation.

   configure
     prometheus federation subordinates remote_cluster_IPs 

NOTES:

• prometheus query-mode client - Configures the Cluster Manager to monitor the remote clusters.

• federation remote-cluster-certs remote_cluster_IP - Configures the specifies remote cluster with SSL certificates.

• prometheus federation subordinatesremote_cluster_IPs - Add all the remote clusters to the federation.

It is possible to configure a cluster with a cluster of CIMC devices. This enables the CIMC devices to receive alerts from the configured CIMC cluster. The CIMC exporter periodically polls the configured CIMC clusters and exports the received alerts through Prometheus.

You can configure the Cluster Manager to monitor the remote clusters for alerts. The remote clusters act as a server.

To configure the Cluster Manager for monitoring the remote clusters, use the following configuration:

configure 
   prometheus query-mode server 
      prometheus server-settings external-ip external_vip_ip 
         server-settings ssl-key ssl_eky 
         server-settings ssl-crt ssl_crt 
         server-settings ssl-ca ssl_ca 

NOTES:

• prometheus query-mode server —Configure the Cluster Manager to monitor the remote clusters for alerts.

• prometheus server-settings external-ip external_vip_ip —Configure the server settings for the specified remote cluster.

• server-settings ssl-key ssl_key —Specify the SSL key.

• server-settings ssl-crt ssl_crt —Specify the SSL certificate.

• server-settings ssl-ca ssl_ca —Specify the SSL certificate authority.

If the UCS server is powered down or non-accessible, an alert will be set up to report and notify the UCS server availability status.

The SMI metrics track and report faults on the UCS server. The cimc_server_not_reachable_alert metric tracks the availability status of the UCS server. To establish an HTTP connection during login, this metric is set to 1 or 0 based on success (response) or failure.

To monitor CIMC reachability, log on to the CEE CLI Ops Center. You can enable CIMC, define a cluster, and add configuration for server IP and credentials using the commands in the Configuring CIMC section.

When CIMC is not reachable, the value for the cimc_server_not_reachable_alert metric will be set to 1 and exposed for Prometheus. These values can be tracked in the Grafana dashboard.

After sometime, the server-not-reachable-alert alert will be created in CEE. If the CIMC becomes reachable, the exposed metric will be deleted from the Prometheus client to prevent it from firing any longer, and the alert will be moved to history.

In this feature, the CEE provides you the option to backup the local data stored in Prometheus to a remote storage object, for example, Amazon Web Services (AWS) S3, by using Thanos.

This feature provides the following two deployment models:

• Thanos Sidecar

• Thanos Receive

Thanos with Sidecar

This section describes how to configure the Sidecar deployment with AWS S3.

Prerequisites

• S3 bucket in AWS

  Note	For more information about how to create an AWS S3 bucket, refer to the original product documentation.

Configuring the Sidecar

Use the following sample CLI commands in the CEE Ops-Center to set up the Sidecar deployment.

prometheus thanos-s3-object-store bucket zx-thanos-test
prometheus thanos-s3-object-store endpoint s3.us-east-1.amazonaws.com
prometheus thanos-s3-object-store access-key
prometheus thanos-s3-object-store secret-key

Thanos with Receive

This section describes how to configure the Remote-write target including the Receiver URL and enable TLS support for the same using the CEE Ops-Center for the Receive deployment with AWS S3.

Prerequisites

• S3 bucket in AWS

• Deploy Thanos Recieve

  Note	For more information about how to create an AWS S3 bucket, refer to the original product documentation.

Configuring the Remote Write Target with Receiver URL

Enter the URL of the Thanos Receiver in the CEE Ops-Center CLI.

A sample configuration for Prometheus to work with Thanos Receive with an HTTP endpoint is shown below.

[user/global] cee# config
Entering configuration mode terminal
[user/global] cee(config)# prometheus remote-write target demo
[user/global] cee(config-target-demo)# url http://thanos-receive-hi-res:10000/api/v1/receive
[user/global] cee(config-target-demo)# commit
Fri Dec  10 04:28:29.838 UTC+00:00
Commit complete.
[user/global] cee(config-target-demo)#
Message from confd-api-manager at 2021-12-10 04:28:31...
Helm update is STARTING.  Trigger for update is CHANGE.

Configuring the Remote Write Target with TLS Enabled

Remote write to Thanos Receive or any other target with TLS enabled is also supported. You can input the necessary ca/cert/key file by using the CEE Ops-Center CLI.

A sample configuration about how to configure remote-write target with TLS enabled is shown below. This configuration enables you to configure Prometheus to work with Thanos Receive with an HTTPS endpoint.

Assume the target remote server has a self-signed server and user has the CA certificate for it.

[user/global] cee(config)# prometheus remote-write target demo
Fri Dec  3  20:58:39.735 UTC+00:00
[user/global] cee(config-target-demo)# url https://thanos-receive-hi-res:10908/api/v1/receive
Fri Dec  3  20:58:51.609 UTC+00:00
[user/global] cee(config-target-demo)# tls-config tls-
Possible completions:
  tls-ca     CA certificate to validate API server certificate with.
  tls-cert   Certificate file for client cert authentication to the server.
  tls-key    Key file for client cert authentication to the server.
[user/global] cee(config-target-demo)# tls-config tls-ca
Fri Dec  3  20:59:05.384 UTC+00:00
(<AES encrypted string>):
[Multiline mode, exit with ctrl-D.]
> ***************************
> ****************************************************************
> ****************************************************************
> ****************************************************************
> ****************************************************************
[user/global] cee(config-target-demo)# tls-config skip-verify
Possible completions:
  false  true
[user/global] cee(config-target-demo)# tls-config skip-verify false
Fri Dec  3  20:59:40.188 UTC+00:00
[user/global] cee(config-target-demo)# commit
Fri Dec  3  20:59:42.797 UTC+00:00
Commit complete.

After the configuration, the Prometheus remote_write is configured as follows and the CA certificate from user input is created on the shown path in the Prometheus container.

remote_write:
- tls_config:
    ca_file: /etc/remote-write-certs-shared/demo-ca
    insecure_skip_verify: false
  url: https://thanos-receive-hi-res:10908/api/v1/receive

The CEE leverages the existing remote-write feature to support the following functionalities:

• Push the Prometheus server metrics to Grafana Cloud

• Enable the following Prometheus parameters for CNDP Grafana Cloud integration:

  • Remote Timeout

    The remote-timeout-seconds command sets the timeout for requests to the remote write endpoint, in seconds. Default: 30 seconds.

  • Queue Configuration

    The queue-config command configures the queue used to write to remote storage.

  • Relabel Configuration

    The relabel-configs command defines a list of relabel configurations before the metrics are written to remote storage. The relabeling feature in Prometheus rewrites the label set of a target dynamically.

Configuring Remote Write to Push Prometheus Metrics

To push the Prometheus metrics to Grafana Cloud using remote-write, use the following sample configuration:

prometheus remote-write target demo
   url https://prometheus-us-central1.grafana.net/api/prom/push
   basic-auth username 725569
   basic-auth password $8$ntCDRl2FkMDlm8mj9FohYwTuy/jo+7Cka0msfP2qW3Y=
   proxy-url http://proxy-wsa.esl.cisco.com:80
   exit

NOTES:

• url —Specify the target URL of Grafana Cloud.

• basic-auth username —Specify the username in Confd.

• basic-auth password —Specify the password in Confd. The password is encrypted in Confd and passed to the metrics helm chart.

• proxy-url —Specify the optional proxy URL to access Grafana Cloud in Confd.

Configuring Prometheus Parameters

To configure the Prometheus parameters to Grafana Cloud using remote-write, use the following sample configuration:

• Remote Timeout—The remote-timeout-seconds command sets the timeout for requests to the remote write endpoint, in seconds. Default: 30 seconds.

  The following is a sample configuration:

  prometheus remote-write target demo
     remote-timeout-seconds 60
     exit

• Queue Configuration—The queue-config command configures the queue used to write to remote storage.

  The following is a sample configuration:

  prometheus remote-write target demo
     ...
     queue-config capacity 500
     queue-config max-shards 100
     queue-config min-shards 2
     queue-config max-samples-per-send 300
     queue-config batch-send-deadline-seconds 10
     exit

  NOTES:

  • queue-config capacity : Specify the number of samples to buffer per shard. Default: 2500.

    It is recommended to have adequate capacity in each shard to buffer several requests. The adequate capacity can maintain the throughput while processing occasional slow remote requests.

  • queue-config max-shards : Specify the maximum number of shards. Default: 200.

  • queue-config min-shards : Specify the minimum number of shards. Default: 1.

  • queue-config max-samples-per-send : Specify the maximum number of samples per send. Default: 500.

  • queue-config batch-send-deadline-seconds : Specify the maximum time in seconds that a sample will wait in buffer. Default: 5 seconds.

• Relabel Configuration—The relabel-configs command defines a list of relabel configurations before the metrics are written to remote storage. The relabeling feature in Prometheus rewrites the label set of a target dynamically.

  The following is a sample configuration:

  prometheus remote-write target demo
   ...
   relabel-configs test1
      target-label test1_label
      regex        (.+);(.+)
      replacement  ${1}@${2}
      action       replace
      source-labels container
      source-labels pod
      exit
   exit

NOTES:

• target-label : Specify the label to which the resulting value is written in a replace action.

• regex : Specify the regular expression against which the extracted value is matched.

  Default = (.*)

• replacement : Specify the replacement value against which a regex replace is performed if the regular expression matches.

  Default = $1

• action : Specify the replace, keep, or drop action to perform based on regex matching.

  Default = replace

• source-labels : Specify the source label to select values from existing labels.

• Multiple relabeling steps can be configured per scrape configuration. The steps are applied to the label set of each target in order of appearance in the configuration file.

• Note that Prometheus will drop any label with empty value, hence use the labels with caution.

In kubeadm v1.21.0, client certificates generated by kubeadm expire after 1 year. The root certificates expires in 10 years. This feature enables monitoring and automatic renewal of kubeadm certificates before the expiry date from the CM or CEE. The CEE triggers an alert to notify the user of any certificate that is going to expire in 30 days.

The smi-cluster-maintainer pod monitors the k8s certificates and automate the renewal process, regardless of the cluster sync.

This section describes the sequence of operation for the feature.

1. The certificates in CM managed K8s clusters, control planes, workers, and external ETCD nodes is checked every 12 hours.

2. If any certificate is expiring in 60 days on the nodes, then the auto-renew process is triggered.

   • If the renewal is successful, then the following checks shows all the certificates as valid.

   • If the renewal is unsuccessful, then the auto-renew process is re-initiated for the next cycle or iteration of validating the certificates.

3. If any certificate is expiring in 30 days on the nodes, then the auto-renew process is triggered along with sending an alert to the user.

   In such cases, a manual intervention might be required to renew the certificates, which are nearing their expiry date.

   The kubernetes certificate expiry alert is show below.

   Rules:

   • Alert: kube_certificate_expiring

     • Annotations:

       • Type: Kubernetes Certificate Expiring Alarm

       • Summary: "Kubernetes certificate {{ $labels.cert_path }} on host: {{ $labels.node_name }} is expiring in {{ $labels.days_to_expiry }} days."

     • Expression:

        | 

             kube_certificate_expiring != 0 

     • Labels:

       • Severity: critical

Note	The certificate auto-renewal process must restart the api-server. You might experience a temporary k8s API downtime during the certificate auto-renewal process.

The SMI Ops Center provides an external authentication using LDAP support. The LDAP configuration can be configured in the SMI Ops Center using CLI or the RESTCONF APIs.

This feature enables you to validate a new LDAP configuration before adding it to the system or an existing LDAP configuration.

This section describes how the feature works.

How to Validate a New Configuration

The steps to validate a new LDAP configuration are as follows.

1. Login to the SMI Ops Center.

2. Provide the LDAP new configuration inputs to validate (see the following example ).

   [pv/global] cee# smildap validate-security-config validate-new-security-config { ?
   Possible completions:
     base-dn                LDAP Base DN
     bind-dn                LDAP Bind DN
     group-attr             Group attribute
     group-mapping          LDAP group to application security mapping
     ldap-filter            LDAP Filter - use %s to sub username
     ldap-server-url        LDAP Server URL (https://tools.ietf.org/html/rfc2255)
     ldap-username-domain   LDAP Username Domain
     password               Password
     username               Existing User name in LDAP server

3. Validate the LDAP new configuration (see the following example configuration).

   cee(config)# smildap validate-security-config validate-new-security-config 
   { base-dn dc=smi-lab,dc=com bind-dn cn=%s,ou=people,dc=smi-lab,dc=com group-attr 
   memberOf group-mapping { group admin ldap-group group1 } username user5 password 
   Passwd@123 ldap-filter cn=%s ldap-server-url ldap://209.165.200.224 }
   Mon Jun  20 05:02:24.635 UTC+00:00
   message accept "admin" external-user-group 1117 1117 /tmp

How to Validate an Existing LDAP Configuration

Use the following example configuration to validate an existing LDAP configuration.

cee# smildap validate-security-config validate-current-security-config
 
Mon Jun  20 05:07:41.765 UTC+00:00
 
Value for 'username' (<string>): user5
 
Value for 'password' (<string>): ********
 
message accept "admin" external-user-group 1117 1117 /tmp