Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Anomalies (Service)

This section covers service anomalies. For analytics anomalies see IBA Anomalies.

Discovery Anomalies

To demonstrate anomalies during the discovery phase, cabling errors have been deliberately configured in the example below to trigger alarms.

To see the list of the cabling anomalies, click the Cabling gauge on the dashboard.

To see the anomalies in the topology view, click Active.

To see the topology view of the anomalies affecting spine1, click Spine1 in the topology.

You can see the cabling violations on spine1. In the right panel, click the red status indicator for All Services to see a comparison of expectations vs. actual. If other anomalies existed in addition to the cabling anomalies, they would be shown in this list as well.

To see additional details specific to LLDP only, click LLDP.

To see how to resolve these cabling issues, see Fetching Discovered LLDP Data.

Configuration Deviation

Running configurations on devices are continuously compared with the Golden Config. If a config deviation is found, a configuration anomaly is raised. Typically such deviations are seen when changes were made outside of Apstra (from the device CLI), or attempting to deploy configuration on a switch that is not able to take the change. These anomalies remain active until either the anomalous configuration is removed from the device or the anomaly is suppressed.

  1. From the blueprint dashboard, any configuration deviations are displayed in the Deployment Status section.
  2. Click Config Dev. to see the list of node(s) with anomalies.
  3. Click a node name to see the device telemetry page, then click Config to see a side-by-side comparison of the actual config to the golden config. (The difference is not shown in the image below.)
  4. To keep the configuration difference, click Accept Changes. This suppresses the configuration anomaly, and does not affect "Intended" or Apstra-rendered config. the primary purpose of "Accept Changes" is to mitigate cosmetic configuration anomalies.
    Note:

    Out-of-band (OOB) changes to the fabric are not supported. Do not Accept Changes to attempt to add OOB changes. For custom changes, use configlets.

    CAUTION:
    • Depending on the change, Apstra may overwrite out-of-band changes. There is no way to avoid this. As such, always avoid OOB changes in the Apstra environment.
    • Using Accept Changes does not make the OOB change persistent. In the event of a full config push or Apstra writing to the same config, all OOB changes are discarded.
  5. To make the actual configuration conform to the intended configuration, click Apply Full Config, then click Confirm. Applying the full config erases the device's current (unintended) configuration before re-applying the complete intended configuration. A full configuration push does not include any OOB changes, and therefore erases them, regardless of their "Accepted" state.
    CAUTION:

    Applying a full config is a disruptive operation and results in a temporary loss of service to the device.

    CAUTION:

    Never directly modify any Apstra-rendered config that affects routing and connectivity. Doing so can potentially impact the network's operation. When in doubt, contact Juniper Support.

  6. After resolving the config deviation anomaly (accept changes or apply full config) the actual config matches the golden config and the anomaly is cleared.

Config Deviation and Configlets

If an improperly-configured configlet causes Apstra deployment errors (when the device rejects the command), a service config deployment failure occurs. In this case, follow the steps below to resolve the anomaly.

  1. From the blueprint, navigate to Staged > Catalog > Configlets and delete the configlet.
  2. Click Uncommitted and commit the change. The configuration deviation remains because the golden config is empty. The golden config is the running config of the device after successful deployment of Apstra-rendered config. If deployment fails there is no golden config, thus causing the config deviation.
  3. Click Dashboard, then click Config Dev. (in the Deployment Status section).
  4. Click the node name, then select Accept Changes to notify Apstra that the failure can be ignored.