Cisco Nexus Dashboard Insights Analysis Hub, Release 6.5.1 - For Cisco ACI

Compliance

Compliance enables user to define set of rules to enforce communication and configuration standards or expectations of the user.

Navigate to Manage > Rules > Compliance Rules > Create Compliance Rule.

An alternate way to get to the rule creation page, is to click the Create Compliance Rule button in Compliance in Analysis Hub. This will take you to rule creation.

The state of any rule can be changed after they have been created. If the rule is in Enabled state, the rule will be used to generate the Compliance Report, the next time it gets generated. If the rule is in Disabled state, it will not be used.

Go to Configure > Rules and enable or disable the specific rule from the Rule State column in the table. Click the Actions menu for the row and click Edit to open Edit Compliance Rule. In the State field, change the state to Enabled and click Save.

{
  "fvTenant":
  {
    "attributes":
    {
      "SELECT(name)": "EXACT(tenantABC)"
    },
    "children":
    [
      {
        "fvBD":
        {
          "attributes":
          {
            "MATCH(type)": "EXACT(regular)",
            "SELECT(name)": "REGEX(.*ABC.*)"
          }
        }
      },
      {
        "fvBD":
        {
          "attributes":
          {
            "MATCH(type)": "EXACT(fc)",
            "SELECT(name)": "REGEX(.*XYZ.*)"
          }
        }
      }
    ]
  }
}

Guidelines and limitations for compliance

Create compliance communication rule

You can view/edit Direction based traffic settings from the Direction settings column.

Create compliance rule with snapshot selection

Create import configuration compliance

Create compliance rule with manual configuration

For BDs in context to VRFs, an extra requirement is needed. The EPG association requirement is to be added which requires an EPG association count. This can be equal to/at least/at most. However you can choose to add either the EPG Association Requirement or the Name and Attribute Requirement for BD. You cannot have all the attributes selected. See Manual configuration compliance.

Create template-based compliance

For more information about template syntax, see Templates to configure object selectors. For information on how to configure object selectors for the template, see Templates to configure object selectors.

Trigger a compliance analysis

The Compliance Analysis will internally trigger assurance analysis and generate compliance anomalies.

Templates to configure object selectors

When you create a configuration rule using manual configuration, only a few specific object selectors are supported (such as BD, EPG, VRF). By using a template, you can select any object and apply match criteria on its attributes.

An object can be any managed object from Cisco APIC, and its selection is based on the distinguished name of the object. If you prefer to have a different attribute as the selection criteria, you can use any valid attribute of that object. You can configure object selectors for selection and match criteria and based on tags and annotations.

Selection, status, and match criteria

For naming compliance, the compliance rules are on the name and nameAlias fields that are indicated by MATCH.

• STATUS defines the state of the specific object in the template, whether an object exists or does not exist. The STATUS criteria can be defined using one of the following keywords.

  • MUST_EXIST

  • MUST_NOT_EXIST

    The following is a syntax example:

  {
  "vzBrCP":
   {
  "attributes":
    {
  "STATUS": "(<status selected>)",
  "SELECT(name)":"<KEY_WORD>(<value>)",
  "MATCH(nameAlias/name)":"<KEY_WORD>(<value>)"
    }
   }
  }

• The SELECT and MATCH criteria can be defined using one of the following keywords. The MATCH criteria is used to define the Compliance rule. SELECT allows to define a criteria to select group of objects and MATCH allows to define attributes and values that those selected objects must have. These compliance rules will be applied on objects that are selected using the SELECT criteria.

  • STARTS_WITH

  • ENDS_WITH

  • EXACT

  • OR

  • REGEX

    Syntax for SELECT:

    SELECT(<attribute_name>): KEY_WORD(<value>)

    Syntax for MATCH:

    MATCH(<attribute_name>): KEY_WORD(<value>)

    

    ---

    Attribute_name can be any attribute of the object. REGEX(<value>) - where the value must follow the standard regex expression syntax "SELECT(name)": "REGEX(Ctrct_[1-3])". For more details about keyword regular expressions, see Summary of Regular-Expressions Constructs.

    ---

    The following is a syntax example:

    {
       "<object>":
       {
          "attributes":
          {
             "SELECT(dn)":"<KEY_WORD>(<value>)",
             "MATCH(nameAlias/name)":"<KEY_WORD>(<value>)"
          }
       }
    }

  If SELECT is not specified for an attribute, then rn and dn will be considered as SELECT by default.

The following is a syntax example where if the KEY_WORD is not defined, the default behavior is EXACT. When you use MATCH(dn) and MATCH(rn), they are defined as match criteria.

---

If an attribute (other than dn and rn) does not have MATCH or SELECT specified, it will be considered as MATCH by default.

---

{
  "fvAEPg":
  {
    "attributes":
    {
      "SELECT(dn)": "uni/tn-aepg_vzanycons_imd_ctx_pass_7/ap-CTX1_AP1/epg-CTX1_BD1_AP1_EPG7",
      "MATCH(isAttrBasedEPg)": "EXACT(no)",
      "prio": "OR(unspecified, prio1)"
    }
  }
}

In the above example, by default, "prio" will be a MATCH.

Example template to configure a Naming Compliance to match selected objects to name or nameAlias:

{
   "vzSubj":
   {
      "attributes":
      {
         "SELECT(dn)":"EXACT(subj1)",
         "MATCH(nameAlias)":"STARTS_WITH(ABC)"
      }
   }
}

As the attribute dn is always considered as SELECT by default and any other attribute is always considered as MATCH, the above template can be simplified as displayed in the example below. Additionally, if the keyword is not defined, the default behavior is EXACT.

{
   "vzSubj":
   {
      "attributes":
      {
         "dn":"subj1""nameAlias":"STARTS_WITH(ABC)"
      }
   }
}

---

In the above template, you can use any object instead of "vzSubj", and you can use any attribute instead of "dn".

---

• Template Syntax for {}

  The following is a syntax example of a generic template where the KEY_WORD is {}. You can use this template to customize your requirements, select attributes, regular expresssions.

  The KEY_WORD values can be as follows:

  • STARTS_WITH

  • ENDS_WITH

  • EXACT

  • OR

  • REGEX

  {
    "<MO type>":
    {
      "attributes":
      {
        "SELECT(<attribute>)": "KEY_WORD(<expression>)",
        "MATCH(<attribute>)": " KEY_WORD (<value>)"
      },
      "children":
      [
        {
          "<MO type>":
          {
            "attributes":
            {
              "SELECT(<attribute>)": " KEY_WORD (<value>)",
              "MATCH(<attribute>)": " KEY_WORD (<value>)"
  
            },
            "children":
            [
              {
                "<MO type>":
                {
                  "attributes":
                  {
                    "SELECT((<attribute>)": " KEY_WORD (<value>)",
                    "MATCH(<attribute>)": " KEY_WORD (<value>,<value>)"
  
                  }
                }
              }
            ]
          }
        }
      ]
    }
  }

• Template With Attribute Value NULL or EMPTY

  The following are examples of templates where the attribute value is null or empty.

  "REGEX(^.{0}$)"
  "EXACT()"
  "OR(test, )" <— use space

  {
    "fvTenant":
    {
      "attributes":
      {
        "MATCH(annotation)": "OR(orchestrator:msc, )",
        "SELECT(name)": "REGEX(aepg_aepg_imd_tnt_pass_[0-9]+)",
      }
    }
  }

For the procedure to configure Object Selectors for Naming Compliance using the above template, see Create template-based compliance.

Tags and annotations

As an APIC user, you can create tags on managed objects (MOs) that result in creating child objects of type tagInst or tagAnnotation (based on which APIC version is in use).

Therefore, if you select objects based on a tag created in APIC, you can follow the templates provided in this section to configure object selectors on tags and annotations.

Example that displays the child object as type tagInst:

{
   "<object>":
   {
      "attributes":
      {
         "MATCH(<attribute_name>)":"<KEY_WORD(<value>)"
      },
      "children":
      [
         {
            "<tagInst>":
            {
               "attributes":
               {
                  "SELECT(<attribute_name>)":"<KEY_WORD(<value>)"
               }
            }
         }
      ]
   }
}

Example that displays the child object as type tagAnnotation:

{
   "<object>":
   {
      "attributes":
      {
         "MATCH(<attribute_name>)":"<KEY_WORD(<value>)"
      },
      "children":
      [
         {
            "<tagAnnotation>":
            {
               "attributes":
               {
                  "SELECT(<key or value>)":"<KEY_WORD(<value>)"
               }
            }
         }
      ]
   }
}

An object can be any valid APIC object with tagAnnotation or tagInst as a child. Object selection is defined in the tagInst or tagAnnotation object using SELECT on the name in the case of tagInst, and key or value in the case of tagAnnotation.

The selection criteria can be any of the following keywords:

• STARTS_WITH

• ENDS_WITH

• EXACT

• OR

• REGEX

Compliance rules are defined at the parent object level using MATCH and the criteria can be defined using any KEY_WORD. tagInst or tagAnnotation do not participate in compliance rules as they only provide the selection criteria.

Example template where you SELECT all the fVBDs where the tag is “BDs_in_cisco”, and those BDs must have name as BD or app1BD.

{
   "fvBD":
   {
      "attributes":
      {
         "MATCH(name)":"OR(BD, app1BD)"
      },
      "children":
      [
         {
            "tagInst":
            {
               "attributes":
               {
                  "SELECT(name)":"EXACT(BDs_in_cisco)"
               }
            }
         }
      ]
   }
}

For the procedure to configure object selectors based on Tags and Annotations using a template, see Create template-based compliance.

---

When using the steps to Create template-based compliance, to configure object selectors for tags and annotations, you must perform an additional step. Before you click Save, in Create New Rule, you must check the checkbox for the field Enable Object Selection Based on tagAnnotation/tagInst. Therefore, if any object has a tag annotation or tagInst, the parent based on the selection criteria in these two objects will be selected.

---

Communication compliance

Manual configuration compliance

Matching criteria

Define matching criteria objects

Matching Criteria Object Type 1	How to define
Tenant	tn - operator value Object type 2 (Could be either VRF or BD) If you select VRF, the rule is further defined as tn - operator value ctx - operator value If you select BD, the rule is further defined as tn - operator value bd - operator value
VRF	tn - operator value ctx - operator value
BD	tn - operator value bd - operator value
EPG	tn - operator value ap - operator value epg - operator value
App Profile	tn - operator value ap - operator value
L3 Out	tn - operator value out - operator value
L3 InstP	tn - operator value out - operator value instp - operator value
L2 Out	tn - operator value l2out - operator value
L2 InstP	tn - operator value l2out - operator value instp - operator value
Contract	tn - operator value brc - operator value
Subject	tn - operator value brc - operator value subj - operator value
Filter	tn - operator value flt - operator value

---

operator and value can be set to anything.

---

Conformance Report

Conformance report enables you to visualize and understand the lifecycle of your hardware and software in the network. This assists you in planning upgrades and hardware refresh. Conformance Report is generated everyday for each fabric for hardware and software conformance and weekly for each fabric for scale conformance. In the report you can view the conformance status of software, hardware, combination of both software and hardware, and scale conformance status for fabrics.

You can use Conformance Report to view current and project the future status of software and hardware inventory in your network against known EoS and EoL notices to ensure conformance. You can also monitor scale conformance status for onboarded fabrics.

Conformance Report displays the summary of conformance status for software, hardware, and scale for selected fabrics.

In the Conformance report, for hardware and software conformance switches are classified into 3 severities based on the software release or hardware platform EoL dates and end of PSIRT dates. The severities include:

The End of SW Maintenance Releases Date in the End-of-Sale and End-of-Life Announcement and the end of PSIRT date is used as reference milestone to classify the inventory into a category of Critical, Warning, or Healthy.

In the Conformance report, the scale conformance status for fabrics is based on Cisco’s Verified Scalability Guidelines for the software version running in switches and controllers when applicable. The severities include:

Access Conformance Report

Navigate to Analyze > Analysis Hub > Conformance.

Choose a fabric from the drop-down list.

OR

Navigate to Manage > Fabrics.

Choose a fabric.

In the General section, click Conformance.

Click View Report.

View Conformance Report

You can save conformance report as a PDF with the browser print option (Only supported on Chrome and Firefox).

About Policy CAM

The Policy CAM feature determines how and where resources in the fabric are used. Policy CAM provides information about the resource utilization in the network, and the amount of policy content-addressable memory (Policy CAM) utilization.

Navigate to Analyze > Analysis Hub > Policy CAM.

After you get to Policy CAM, choose a fabric, choose the appropriate snapshot of time within which to view the resource utilization, and click Apply.

Within the time range you chosen, the last snapshot is considered for each of the fabrics included in the fabric. Therefore, you get the latest state of the application within the chosen time range.

Policy CAM Analyzer displays the following information:

In Nexus Dashboard Insights release 6.3.1.15, Policy CAM is not supported on Cisco Nexus 9000 FX3 switches. In Nexus Dashboard Insights release 6.3.1.40 and later, Policy CAM is supported on Cisco Nexus 9000 FX3 switches.

Connectivity Analysis

Connectivity Analysis allows you to analyze flows between two different endpoints, provide insight into how your endpoints are connected, and helps you spot where problems might be occurring.

Connectivity Analysis detects and isolates offending nodes in the network for a given flow and includes the following functionalities:

Guidelines and Limitations

Create Connectivity Analysis.

OR

View Connectivity Analysis

Manage Connectivity Analysis

Filtering Information

In some cases, you might be able to filter results to find information more easily.

For example, you might have a situation where there a large number of endpoints under a single leaf switch, but you are only interested in endpoints that have a certain VLAN value.

You could filter the information to show only those specific endpoints in this situation.

Use the following operators for the filter refinement:

Log Collector

The Log Collector feature enables you to collect and upload the logs for the devices in your network to Cisco Intersight Cloud. It also enables Cisco TAC to trigger on-demand collection of logs for devices on the fabric and pulls the logs from Cisco Intersight Cloud.

The Log Collector has two modes:

Log Collector Dashboard

Navigate to Analyze > Analysis Hub > Log Collector.

The Log Collector Dashboard displays a graph of Logs by Job status for a particular fabric and displays the latest log collections.

The filter bar allows you to filters the logs by Status, Name, Node, start time, and end time.

Use the following operators for the filter refinement:

The page also displays the log collection jobs in a tabular format. The jobs are sorted by status. Choose the log collection job in the table to view additional details.

General

This displays the status of the job along with a graph showing the number of devices by status.

Details

The following information is listed:

Selected Nodes

This displays the list of nodes in a tabluar form along with the status of each job and the upload status for the files uploaded.

Upload All Files allows you to upload all the files.

TAC Initiated Log Collector

The TAC initiated log collector enables Cisco TAC to trigger on-demand collection of logs for specified user devices in the Cisco Intersight Cloud to the Device Connector.

When the TAC assist job is complete, the new job appears in the Log Collector table. Choose the log collection job in the table to display additional details. Log Collection status displays information such as status, general information, and node details.

You can save TAC assist job details as a PDF with the browser print option (Only supported on Chrome and Firefox).

Upload logs to Cisco Intersight Cloud

Choose Analyze > Analyze Hub > Log Collector > New Log Collector.

Traffic Analytics

Traffic Analytics enables you to monitor your network’s latency, congestion, and drops.

Traffic Analytics automatically discovers services running in your network by matching well-known TCP Layer 4 ports to their corresponding service endpoint categories. Nexus Dashboard Insights then assesses service performance based on thresholds for the following metrics:

An anomaly is raised if there is any deviation in the performance metrics such as latency, congestion, and drops. The performance score is calculated for each conversation and aggregated to the service endpoint or endpoint level to raise anomalies.

The performance score is calculated based on the following:

Using Traffic Analytics you can:

Guidelines and limitations for Traffic Analytics

Configure Traffic Analytics

View Traffic Analytics

Manage Service Endpoint Categories

In the Manage Service Endpoint Categories area, you can view the ports that have been assigned to categories based on standard networking defaults and any categories you may have created. If a port has not been assigned to a category, you can assign it to one of the existing categories or create a new category. This helps you to organize and manage your network ports more efficiently.

View Traffic Analytics for Endpoints

Flow Troubleshoot Workflow

The flow troubleshoot workflow enables you to collect all the flow records between two endpoints. Nexus Dashboard Insights allows you to specify the duration for flow collection and then collect records between specific endpoints for the specified duration. As a result you can view the path visualization, 5-tuple flow information, and any issues seen on individual flows.

Flow troubleshoot may not show all the switches through which packet traverses for each record in the following scenarios:

Sustainability Report

The Cisco Nexus Dashboard Insights sustainability report helps you monitor, predict, and improve your network’s energy usage, its related carbon emissions, and its total energy cost. The sustainability report enables you to get insights on energy utilization, CO2 emissions, and energy cost for all your fabrics on a monthly basis.

The report is generated by calculating the monthly values for Power Consumption and by summing the usage data across all of your devices at each of your fabrics for every single day in the chosen month. This data is then combined with the Cisco Energy Manager to provide greater insight into what that usage means in terms of energy cost, estimated emissions, and estimated switch power consumption. For more information about the Cisco Energy Manager, see Cisco Energy Manager.

The summary area of the report contains information such as estimated cost, estimated switch power consumption, sources of emission, and estimated emissions.

If you have Panduit PDUs onboarded to Nexus Dashboard, you can use the Data Source toggle to see two different electricity values on the sustainability report: one for switches only, and one for PDUs.

Depending on which value you choose in the Data Source toggle, the values calculated for your other metrics, including estimated cost and emissions, will vary.

The retention time for the sustainability report in Nexus Dashboard Insights is 12 months.

View the sustainability report for switches

View the sustainability report for PDUs

Delta Analysis

Nexus Dashboard Insights performs analysis of sites at regular intervals and the data is collected at an interval depending on the number of nodes.

At each interval, Nexus Dashboard Insights captures a snapshot of the controller policies and the fabric run time state, performs analysis, and generates anomalies. The anomalies generated describe the health of the network at that snapshot.

Delta analysis enables you to analyze the difference in the policy, run time state, and the health of the network between two snapshots.

Create Delta Analysis enables you to create a new delta analysis and manage existing analysis. See Create Delta Analysis.

Guidelines and Limitations for Delta Analysis

Create Delta Analysis

For ACI Assurance Group users, APIC admin writePriv privileges allow information collection on the APIC host and leaf switches. You must have APIC admin writePriv privileges to configure the APIC Configuration Export Policy.

Choose Analyze > Analysis Hub > Delta Analysis > Create Delta Analysis.

You can perform one delta analysis at a time. To perform another delta analysis, you must stop the current delta analysis and then start the another delta analysis.

If there are any errors in the creation of a delta rule, it will be displayed on the summary of the rule creation as a banner.

View Delta Analysis

The page displays the analysis in a tabular form. The analysis are sorted by status. The Create Delta Analysis button lets you create a new delta analysis.

The status of analysis can be either Aborted, Pending, Scheduled, Stopped, Stopping, Success, Failed, Partially Failed, Queued, Completed or In progress.

The filter bar allows you to filters the analysis by the following factors:

The delta analysis dashboard displays the general details of the analysis along with the health and policy delta.

View Health Delta Analysis

Health Delta analyses the difference in the health of the fabric across the two snapshots. The results are displayed in the following areas:

The toggle for 'Include Acknowledged Anomalies' allows you to filter out the acknowledged anomalies from the results displayed if enabled. If it is disabled, manually acknowledged anomalies are included in the Anomaly Count.

The first count represents the anomalies found only in the earlier snapshot. The second count represents the anomalies common in both the snapshots. The third count represents the anomalies found only in the later snapshot.

The table displays count delta and health delta. Count delta includes both healthy and unhealthy resources. Healthy resources prob won’t have any anomalies associated with it if filtered Health delta shows only unhealthy resources and should return anomalies if filtered by

The Anomalies can be listed for the following kinds of snapshots:

The anomalies are displayed in a tabular form with the following fields:

You can filter the results based on the following attributes:

Choose an anomaly to view the anomaly details.

View Policy Delta Analysis

Click Policy Delta to view the policy changes across the two snapshots. Policy Delta includes three sections: Changed Policy Object, Policy Viewer, and Audit Log.

A correlated view of what has change in the data center is displayed in the Audit Log panel. When you choose a particular object in the Changed Policy Objects panel, the relevant difference is highlighted in the Policy Viewer panel and the relevant audit log is highlighted in the Audit Log panel. APIC audit logs are records of user-initiated events such as logins and logouts or configuration changes that are required to be auditable. For every snapshot, the audit log history is limited to last 24 hrs.

Pre-Change Analysis

Navigate to Analyze > Analysis Hub > Pre-Change.

Pre-Change Analysis allows you to change a configuration for a fabric, to model the intended changes, perform a Pre-Change Analysis against an existing base snapshot in the fabric, and verify if the changes generate the desired results.

After you model the changes for a Pre-Change Analysis job, you can choose Save or Save And Analyze. By choosing Save, you can save the Pre-change Analysis job without having to start the analysis right away. You can return to the job later, edit the changes if required, and then run the analysis later. The Save option is supported only for a Pre-Change Analysis job with manual changes.

If you choose Save And Analyze, the job gets scheduled and an analysis is provided. The changes are applied to the chosen base snapshot, the analysis is performed, and results are generated. For every pre-change analysis job listed in the table, a delta analysis is performed between the base snapshot and the newly generated snapshot.

In Pre-Change Analysis, to see the details of a completed Pre-Change Analysis job, click that job in the table. This opens a new page that displays the following information:

General Information shows the following data:

In case of Manual Changes, you see list of changes that were modeled for that job(Change type, Object type, name alias, Priority, Description, App profile) and in case of JSON/ XML file upload you see the Change Simulation.

As the job is complete, the severity area displays the anomalies that are generated for these changes. To understand the data displayed under Delta Analysis, view Delta Analysis.

To understand the data displayed under Compliance Analysis, view Compliance.

The …​ button allows you to perform the following actions:

If anomalies are raised in the analysis, make the required modifications based on the results and re-run the analysis until you obtain satisfactory results. The download option in a Pre-Change Analysis job allows you to download a JSON file that can be uploaded to Cisco APIC. However, if you choose the file upload approach, you can upload a JSON or an XML Cisco APIC configuration file to run a Pre-Change Analysis job.

Once the analysis starts, the status of the job will be shown as Running. During this time, the specified changes will be modeled on top of the base snapshot, and complete logical checks will be run, including Policy Analysis and Compliance. No switch software or TCAM checks will be performed. The status of the Pre-Change Analysis job is marked Completed when the entire analysis including Delta Analysis completes. The Delta Analysis is automatically triggered and the associated Pre-Change Analysis job is displayed as running during that time. The Delta Analysis is performed only on checks supported in Pre-Change Analysis job.

You can view changes applied by a user to a specific Pre-Change Analysis job by clicking the job in the table. If the changes are applied manually, you can view the different changes chosen by the user. If the job is created using a JSON file, the Change Definition field displays the name of the JSON file from where the changes were imported.

Pre Change Analysis lists all the analyses performed in a tabular form with the following fields:

Pre-Change Analysis Options

The following list specifies the options you can choose on your pre-change analysis job. Only the objects listed are supported.

For Fabric Access Policies, you can choose to add the following to your pre-change analysis job:

Guidelines and Limitations for Pre-Change

When using Pre-Change Analysis follow these guidelines and limitations:

Support for Multiple Objects in Pre-Change Analysis

In addition to multiple tenants, you can also add multiple infrastructure objects as part of a Pre-Change Analysis JSON or XML job. The Pre-Change Analysis upload path allows you to add, modify, and delete multiple objects across the policy universe. There are no additional configurations required to use this feature. Your Pre-Change Analysis job for multiple objects will run, based upon the files you upload.

The following file upload formats are accepted:

Known Issues for Pre-Change Analysis

Create Pre-Change Analysis Job

General

Change

Depending upon your selection, the relevant fields are displayed for you to populate.

Complete the selections as appropriate, and click Save or Save & Run.

After a Pre-Change Analysis job is completed, the Pre-Change Analysis table displays the status for the job as completed.

Click the Pre-Change Analysis Name for which you want to view the details. In a sidebar to the right, the details are displayed in a column including the general information such as the name of the job, snapshot, and change definition type. The list of changes modeled for the job are also available. If you are viewing a completed job, the anomalies that were generated as a result of the changes are displayed at the top of this page.

For completed jobs, click the icon on the top right of the sidebar to navigate to the results page. Further details about the job are available here under the specific tabs for Dashboard, Delta Analysis, Compliance Analysis.

Download Pre-Change Analysis Job

You can download an existing Pre-Change Analysis as follows:

In the downloaded file, you can view all the attributes which include attributes that are modified and those that are not modified. If desired, the downloaded file can be uploaded to your Cisco APIC.

Collecting information on bugs that might affect your network using Bug Scan

Nexus Dashboard Insights collects technical support information from all the devices and runs them against known set of signatures, and flags the corresponding defects and PSIRTs. Nexus Dashboard Insights also generates advisories for PSIRTs and anomalies for defects. See Anomalies and Advisories to learn more about Metadata support.

The Bug Scan feature collects technical support logs from devices in a fabric and scans them for bugs that could have been hit. If the CPU and memory usage is below the set threshold of 65% then the tech support logs are collected and the Bug Scan is carried out for the devices. If the CPU and memory usage is above the set threshold, the devices are excluded from the Bug Scan and eventually will be reconsidered for the next default Bug Scan or when you run an on-demand Bug Scan for that device.

If the node interaction is not healthy on the device, you cannot choose the device for Bug Scan to collect logs. The device cannot be chosen to configure a job.

You can also run an on-demand Bug Scan for a fabric. For more information, see the On-Demand Analysis section in Getting Started.

Default Bug Scan

Bug Scan is run for all the fabrics onboarded to Nexus Dashboard Insights and is auto-scheduled every 7 to 14 days for each device, depending on the number of nodes and fabrics on the Nexus Dashboard cluster. This schedule is fixed and is not customizable.

Bug Scan is run on devices contained in a fabric either based on the last Bug Scan or the onboarding time if a Bug Scan has not been run before. Priority is given to devices with a longer time elapsed since the last Bug Scan. After a Bug Scan is run on a device, regardless of whether it succeeds or fails, another Bug Scan will not be run for the same device for the next 7 days.

Bug Scan is auto-scheduled to run on devices only if the CPU and memory metrics for the devices are streamed and the percentage usage is less than 65%.

However, on-demand Bug Scan is an exception and is prioritized over any auto-scheduled runs and does not consider the CPU and memory metrics as it is user-initiated. If auto-scheduled Bug Scan is in progress and on-demand Bug Scan is initiated, based on the available resources in the Nexus Dashboard nodes the on-demand Bug Scan will start while the current Bug Scan is in progress or after the current Bug Scan is completed.

Only one Bug Scan at the time can run on a specific device. However, if you have one set of devices where Bug Scan is already in progress, a second (auto-scheduled or on-demand) Bug Scan can run only if Nexus Dashboard Insights has enough resources available. Otherwise it will be put on hold and started as soon as resources are available.

---

A Bug Scan is triggered automatically in the following scenarios:

• Node upgrade or downgrade

• Node reloads

---

View Active and Susceptible Bugs

The Bug Scan feature collects technical support logs from devices in a fabric and scans them for bugs that could have been hit. You can view the active and susceptible bugs affecting your network after the Bug Scan is completed.