---
# This title is used for search results
title: Ansible Collection Role anta_runner
---
<!--
  ~ Copyright (c) 2024-2026 Arista Networks, Inc.
  ~ Use of this source code is governed by the Apache License 2.0
  ~ that can be found in the LICENSE file.
  -->

# anta_runner

## Overview

**anta_runner** is a role leveraged to validate Arista EOS devices' operational states using the [Arista Network Test Automation (ANTA)](https://anta.arista.com) framework.

By default, the role generates a per-device test catalog based on the AVD structured configurations. It executes the ANTA tests against the devices defined in the Ansible inventory.

It can also be used to execute user-defined ANTA test catalogs in conjunction with the Ansible inventory, providing similar functionality and options as the [ANTA CLI](https://anta.arista.com/stable/cli/overview/) while benefiting from Ansible's inventory management capabilities.

Results are reported in various formats, including JSON, CSV, and Markdown.

## Requirements

Requirements are located in the AVD [installation](../../../../../docs/installation/collection-installation.md#python-requirements-installation) documentation.

## Basic Example

This example will generate a per-device test catalog based on the AVD structured configurations and execute the ANTA tests against all devices in the inventory group `FABRIC`:

```yaml title="playbook.yml"
---
- name: Run ANTA
  hosts: FABRIC # <-- Targeted devices
  connection: local
  gather_facts: false
  tasks:
    - name: Run ANTA on EOS devices
      import_role:
        name: arista.avd.anta_runner
```

The artifacts generated by the role, including results from ANTA, will be stored in the `anta` folder in the inventory directory.

The `Run ANTA on EOS devices` task will fail if any of the following conditions occur:

- **No tests executed:** If no tests were run against any device (and it's not a `dry_run`).
- **Execution errors:** If errors arise during the role execution, originating from Ansible, PyAVD, or ANTA.
- **Test failures or errors:** If any ANTA test reports a failure or error status.

!!! tip
    To continue running the playbook when `anta_runner` fails, use Ansible `ignore_errors`. For more details, refer to the [Ansible documentation](https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_error_handling.html).

## Understanding ANTA Catalogs

The `anta_runner` role works with two types of test catalogs:

1. **AVD-generated catalogs:** These are automatically created based on structured configurations. They contain tests tailored to both device-specific configurations and the network design.
2. **User-defined catalogs:** These are custom ANTA test catalogs you can create and provide to the role. They allow you to add any tests that are available in the ANTA framework.

Different filtering mechanisms are used depending on the catalog type, explained in the [Test Filtering](#test-filtering) sections.

## Role Inputs and Outputs

Figure 1 below provides a visualization of the role's inputs, outputs executed by the role.

![Figure 1: Ansible Role anta_runner](../../../../../docs/_media/anta_runner_light.svg#only-light)
![Figure 1: Ansible Role anta_runner](../../../../../docs/_media/anta_runner_dark.svg#only-dark)

**Inputs:**

- Only the structured configuration files generated by `eos_designs` will be parsed to render test catalogs. Variables from the Ansible inventory will **not** be considered. Any `raw_eos_cli` configuration will also **not** be considered. See [Integration with eos_designs](#integration-with-eos_designs) for details on which `eos_designs` inputs affect test generation.
- User-defined custom tests may also be defined. For test definitions, please see the test catalog on [anta.arista.com](https://anta.arista.com/stable/api/tests/).

**Outputs:**

- Test reports in either CSV, Markdown, or JSON formats.
- Optional: Saves a copy of the AVD-generated tests per device.

## Role Configuration and Options

By default, this role will generate the AVD-generated catalog and execute the ANTA tests against all hosts targeted by the Ansible "play".

```yaml title="playbook.yml"
---
- name: Run ANTA
  hosts: FABRIC # <-- Targeted devices
  connection: local
  gather_facts: false
  tasks:
    - name: Run ANTA on EOS devices
      import_role:
        name: arista.avd.anta_runner
```

This playbook targets the Ansible inventory group `FABRIC`, so all devices under this group will be targeted for the catalog generation and test execution.

!!! tip
    Only a subset of this group can be tested by supplying the `--limit <hostname or group>,<hostname or group>` flag to the `ansible-playbook` command.

You can also manually supply a list of devices:

```yaml
# Run ANTA for these devices.
# Defaults to all hosts in the play.
# This means the role must be imported/included in a play targeting only the
# relevant EOS devices - *not* CloudVision.
anta_devices: [ DC1-LEAF1A, DC1-LEAF1B ]
```

!!! note
    The device name is used directly to find the EOS structured configuration files.
    This means the device names are case sensitive and must match the file names.

Devices with `is_deployed: false` set as part of `eos_designs` inputs will automatically be ignored. See [Device Deployment Status](#device-deployment-status) for more details.

!!! note
    When devices are excluded from a run, whether by using `--limit` or `anta_devices`, tests that rely on the excluded devices will not be executed. For example, if a test requires information from a device that is not included, the test will be skipped. The same behavior applies to `is_deployed: false` devices.

### Connection Options

The role connects to EOS devices via eAPI using HTTP/HTTPS, so the devices must be accessible from the Ansible control node.
The connection is managed by ANTA HTTP client. For flexibility, connection parameters can be defined using `anta_`
prefixed variables, which take precedence over standard Ansible connection variables.

```yaml
# The IP/name of the target host to use instead of inventory_hostname.
ansible_host: <str>

# The username to log in with.
# Precedence: `anta_user` -> `ansible_user`.
anta_user: <str>
ansible_user: <str>

# The password to use for the connection.
# Precedence: `anta_password` -> `ansible_password` -> `ansible_httpapi_pass` -> `ansible_httpapi_password`.
anta_password: <str>
ansible_password: <str>
ansible_httpapi_pass: <str>
ansible_httpapi_password: <str>

# Some tests require elevated privileges to run (enable mode).
# Precedence: `anta_enable` -> `ansible_become` -> false.
anta_enable: <bool>
ansible_become: <bool; default=false>

# The password for privileged (enable) mode.
# Precdence: `anta_enable_password` -> `ansible_become_password`.
anta_enable_password: <str>
ansible_become_password: <str>

# eAPI SSL verification.
# Precedence: `anta_use_ssl` -> `ansible_httpapi_use_ssl` -> true.
anta_use_ssl: <bool>
ansible_httpapi_use_ssl: <bool; default=true>

# eAPI port.
# Precedence: `anta_port` -> `ansible_httpapi_port` -> 80 or 443 depending on SSL.
anta_port: <int>
ansible_httpapi_port: <int; default=80 or 443 depending on anta_use_ssl or ansible_httpapi_use_ssl>
```

### Directory Configuration

The EOS device AVD structured configurations are read from files generated by `arista.avd.eos_designs` role.

The directories are configured with the same variables as for the other AVD roles:

```yaml
# Root directory.
root_dir: "{{ inventory_dir }}"

# Main output directory used in AVD.
output_dir_name: "intended"
output_dir: "{{ root_dir }}/{{ output_dir_name }}"

# Output for structured configuration files.
structured_dir_name: "structured_configs"
structured_dir: "{{ output_dir }}/{{ structured_dir_name }}"

# Structured configuration file format. Supported formats: yml, yaml, json.
avd_structured_config_file_format: "yml"
```

The ANTA-related directories for the role are configured as follows:

```yaml
# Main directory for the ANTA-related files.
anta_dir_name: "anta"
anta_dir: "{{ root_dir }}/{{ anta_dir_name }}"

# Directory for ANTA user-defined catalog files. These are the catalogs created by the user.
# The role will search for valid ANTA catalogs in this directory
# and merge them with each device's AVD-generated catalog.
user_catalogs_dir_name: "user_catalogs"
user_catalogs_dir: "{{ anta_dir }}/{{ user_catalogs_dir_name }}"

# Directory for AVD-generated ANTA catalogs. Per-device catalogs will be stored here.
avd_catalogs_dir_name: "avd_catalogs"
avd_catalogs_dir: "{{ anta_dir }}/{{ avd_catalogs_dir_name }}"

# Directory for ANTA reports.
anta_reports_dir_name: "reports"
anta_reports_dir: "{{ anta_dir }}/{{ anta_reports_dir_name }}"

# Paths for the generated reports. Supports JSON, CSV, and Markdown.
anta_report_json_path: "{{ anta_reports_dir }}/anta_report.json"
anta_report_md_path: "{{ anta_reports_dir }}/anta_report.md"
anta_report_csv_path: "{{ anta_reports_dir }}/anta_report.csv"
```

### Test Filtering

Optional filtering mechanisms are available to control which tests are executed.

#### Tag-Based Filtering

`anta_runner_tags`: When using user-defined catalogs, tags can be used to filter which tests to run on which devices. These tags are used in conjunction with the `anta_tags` variable assigned to devices in the Ansible inventory.

```yaml
# In the inventory file
all:
  children:
    FABRIC:
      hosts:
        DC1-LEAF1A:
          anta_tags: [ leaf ]  # <-- Tag this device with 'leaf'
        DC1-SPINE1:
          anta_tags: [ spine ] # <-- Tag this device with 'spine'

# In a user-defined catalog
anta.tests.vxlan:
  - VerifyVxlan1Interface:
      filters:
        tags: [ leaf ] # <-- Tag this test with 'leaf'

# In the playbook
- name: Run ANTA
  hosts: FABRIC
  connection: local
  gather_facts: false
  tasks:
    - name: Run ANTA on EOS devices
      import_role:
        name: arista.avd.anta_runner
      vars:
        avd_catalogs_enabled: false  # <-- Disable AVD-generated catalogs to use only user-defined catalogs
        anta_runner_tags: [ leaf ]   # <-- Only run tests tagged with 'leaf' on devices with 'leaf' tag
```

!!! warning
    Tests in the AVD-generated catalogs are tagged with the device's hostname only. This means using `anta_runner_tags` with tags other than any device's hostname will skip all AVD-generated tests. To run/skip tests from the AVD-generated catalogs, use the `avd_catalogs_filters` variable described below.

#### Test-Based Filtering

`avd_catalogs_filters`: Filters are used to run or skip tests from the AVD-generated catalogs. These filters do **not** apply to user-defined catalogs, use `anta_runner_tags` for that. See the [AVD test index](#avd-generated-catalog-test-index) section for the available tests.

```yaml
# In the playbook
- name: Run ANTA
  hosts: FABRIC
  connection: local
  gather_facts: false
  tasks:
    - name: Run ANTA on EOS devices
      import_role:
        name: arista.avd.anta_runner
      vars:
        avd_catalogs_filters:
          # Skip VerifyNTP for all devices targeted by the run
          - skip_tests: [ VerifyNTP ]
          # Skip VerifyReachability for all devices in the DC1 Ansible inventory group
          - device_list: "{{ groups['DC1'] }}"
            skip_tests: [ VerifyReachability ]
          # Only run VerifyLLDPNeighbors for DC2-LEAF1A and DC2-LEAF1B
          - device_list: [ "DC2-LEAF1A", "DC2-LEAF1B" ]
            run_tests: [ VerifyLLDPNeighbors]
```

By default, filters apply to all devices targeted by the run. `device_list` can be used in a filter to target a subset of devices only. Filters are not cumulative for a device. If a device matches multiple filters, the last filter (appearing later in the list) wins independently for both `skip_tests` and `run_tests`.

!!! note
    `skip_tests` takes precedence over `run_tests`. If the same test is in both lists, it will be skipped, and other tests will be run.

### Report Options

These settings control the format and content of the generated reports.

#### Report Filtering

`anta_report_exclude_statuses`: A list of test result statuses to exclude from the generated reports. The available statuses are `error`, `failure`, `skipped`, `success`, and `unset`.

```yaml
# In the playbook
- name: Run ANTA
  hosts: FABRIC
  connection: local
  gather_facts: false
  tasks:
    - name: Run ANTA on EOS devices
      import_role:
        name: arista.avd.anta_runner
      vars:
        # Do not show success and skipped tests in the reports.
        anta_report_exclude_statuses: [ success, skipped ]
```

#### Report Sorting

`anta_report_status_priority`: A list of test statuses that defines the primary grouping order of the test results. Tests with statuses listed here appear at the top in the specified order. Any status not listed is pushed to the bottom of the reports and grouped alphabetically.

- **Available values:** `error`, `failure`, `skipped`, `success`, `unset`
- **Default:** `['error', 'failure', 'skipped', 'success', 'unset']`

`anta_report_sort_fields`: A list of result attributes used to sort tests **within** each status group.

- **Available values:** `categories`, `custom_field`, `description`, `device`, `test`
- **Default:** `['device', 'categories', 'test', 'description', 'custom_field']`

!!! note
    `anta_report_status_priority` defines the primary grouping order. Within each status group, tests are sub-sorted using the attributes defined in `anta_report_sort_fields`.

```yaml
# In the playbook
- name: Run ANTA
  hosts: FABRIC
  connection: local
  gather_facts: false
  tasks:
    - name: Run ANTA on EOS devices
      import_role:
        name: arista.avd.anta_runner
      vars:
        # Prioritize success, then skipped tests. Unlisted statuses like 'error' falls to the bottom.
        anta_report_status_priority: [ success, skipped ]

        # Within each status group, sort by device, then test name.
        anta_report_sort_fields: [ device, test ]
```

#### Report Granularity

`anta_report_expand_results`: Controls the granularity of the Markdown report. When enabled, test entries are expanded to show the individual status of every check performed.

!!! warning
    Not all ANTA tests currently support expanded results. For tests that do not support this feature yet, the report will display the standard aggregated result regardless of this setting.

`anta_report_custom_field`: Controls whether the `custom_field` column is generated in the Markdown report.

!!! info
    ANTA test definitions can include an arbitrary string in the `custom_field` input that will be added to the test result.

```yaml
# In the playbook
- name: Run ANTA
  hosts: FABRIC
  connection: local
  gather_facts: false
  tasks:
    - name: Run ANTA on EOS devices
      import_role:
        name: arista.avd.anta_runner
      vars:
        # Expand results in the Markdown report
        anta_report_expand_results: true
        # Generate the custom_field column in the Markdown report
        anta_report_custom_field: true
```

### Extra Fabric Validation

By default, the AVD-generated catalog includes tests that validate individual device configurations and their direct peers. When `avd_catalogs_extra_fabric_validation` is enabled, additional fabric-wide validation tests are generated to verify end-to-end connectivity and routing across the entire fabric.

```yaml
# Enable extra fabric-wide validation tests.
avd_catalogs_extra_fabric_validation: true
```

!!! warning
    Enabling this setting can generate many additional test inputs, especially in large fabrics. Validation may take longer as a result.

#### Tests Enabled by Extra Fabric Validation

The following tests are only generated when `avd_catalogs_extra_fabric_validation: true`:

| Test | Description |
| :--- | :--- |
| **VerifyReachability** (VTEP Underlay) | Verifies reachability from each VTEP device Loopback0 to all other fabric devices Loopback0 addresses. WAN routers are excluded from this test. |
| **VerifyReachability** (WAN DPS) | Verifies reachability between DPS interfaces (VXLAN source interfaces) of WAN routers. |
| **VerifyReachability** (Inband Management) | Verifies reachability from devices with inband management SVIs to all other fabric devices Loopback0 addresses. |
| **VerifyReachability** (BGP Neighbors) | Verifies reachability to BGP neighbors across all VRFs. |
| **VerifyRoutingTableEntry** | Verifies that Loopback0 and VTEP IPs from all fabric devices are present in the routing table of VTEP devices. WAN routers are excluded from this test. |

#### Excluding Devices from Extra Fabric Validation

Some devices may need to be excluded as destination targets for extra fabric validation tests. This can be configured using the `exclude_as_extra_fabric_validation_target` setting in a validation profile. See the [Validation Profiles](#validation-profiles) section for configuration details and examples.

### Advanced Settings

These settings control the execution behavior of the role.

```yaml
# Enable AVD catalogs generation. Can be disabled if only user-defined catalogs are used.
avd_catalogs_enabled: true

# Enable user-defined catalogs. When enabled, the role will search for valid ANTA catalogs
# in `user_catalogs_dir` and merge them with each device's AVD-generated catalog.
user_catalogs_enabled: false

# Global timeout (in seconds) for each ANTA test. Depending on the scale this can be adjusted.
anta_runner_timeout: 30

# ANTA runner batch size. This controls the number of devices that will be processed in parallel.
# 5-10 is a good starting point.
anta_runner_batch_size: 5

# Run ANTA in dry-run mode. This will generate the tests but not execute them.
anta_runner_dry_run: false
```

!!! tip
    The role automatically respects the `ansible_forks` setting to determine the maximum number of worker processes in conjunction with `anta_runner_batch_size`. Consider adjusting these settings for large deployments with many devices to optimize performance while managing resource usage.

## Integration with `eos_designs`

The `anta_runner` role leverages structured configuration files generated by the `eos_designs` role to create ANTA test catalogs. These structured configurations contain the device configuration and metadata that `anta_runner` uses to generate appropriate tests.

The `eos_designs` role automatically generates metadata based on the network design. Additionally, several `eos_designs` input keys allow you to influence which tests are generated and how they behave.

### Device Deployment Status

The `is_deployed` key controls whether a device is included in validation. When `false`, the device is excluded from ANTA runs and tests from other devices targeting it are skipped.

```yaml
l3leaf:
  nodes:
    - name: DC1-LEAF1A
      is_deployed: false  # Exclude from validation
```

### Validation Profiles

Validation profiles define reusable validation rules applied to devices. Profiles support single-level inheritance using `parent_profile`.

```yaml
validation_profiles:
  - name: datacenter_default
    hardware:
      min_power_supplies: 2
      min_fans: 4
    logging:
      validate_no_errors_period: 60

  - name: spine_profile
    parent_profile: datacenter_default
    hardware:
      min_supervisors: 2

spine:
  defaults:
    validation_profile: spine_profile
```

#### Hardware Validation

Hardware settings control `VerifyInventory` and `VerifyTransceiversManufacturers` tests. Set any `min_*` value to `0` to skip validation for that component.

```yaml
validation_profiles:
  - name: modular_chassis
    hardware:
      min_power_supplies: 4
      min_supervisors: 2
      min_line_cards: 8
      min_fabric_cards: 6
      transceiver_manufacturers: [ "Arista Networks", "Arastra, Inc." ]
```

#### Logging Validation

The `validate_no_errors_period` setting controls how far back `VerifyLoggingErrors` checks for error-level logs (in minutes).

```yaml
validation_profiles:
  - name: strict_logging
    logging:
      validate_no_errors_period: 60  # Check last 60 minutes
```

#### Excluding Devices from Extra Fabric Validation

The `exclude_as_extra_fabric_validation_target` setting prevents a device from being used as a destination in `VerifyReachability` and `VerifyRoutingTableEntry` tests from other devices.

```yaml
validation_profiles:
  - name: border_leaf
    exclude_as_extra_fabric_validation_target: true

l3leaf:
  nodes:
    - name: DC1-BORDER-LEAF1
      validation_profile: border_leaf
```

!!! note
    This setting only applies on tests generated when `avd_catalogs_extra_fabric_validation` is enabled.

### Interface Validation

Interface-level settings control LLDP and interface state validation on connected endpoints and network ports.

#### validate_state

When `false`, excludes the interface from `VerifyInterfacesStatus`, `VerifyLLDPNeighbors`, and `VerifyPortChannels` tests.

```yaml
servers:
  - name: server01
    adapters:
      - switch_ports: [ Ethernet5 ]
        switches: [ DC1-LEAF1A ]
        validate_state: false
```

#### validate_lldp

Controls LLDP validation independently from interface state. Set to `true` for non-AVD managed peers, or `false` to skip LLDP validation.

```yaml
servers:
  - name: external-device
    adapters:
      - switch_ports: [ Ethernet10 ]
        switches: [ DC1-LEAF1A ]
        validate_lldp: true  # Force LLDP validation for non-AVD peer (outside of AVD inventory)
```

### BGP Peer Validation

The `validate_bgp_peers` key under `<network_services_keys.name>[].vrfs[]` generates `VerifyBGPPeerSession` inputs to validate BGP peers in that VRF.

```yaml
tenants:
  - name: TENANT_A
    vrfs:
      - name: VRF_A
        validate_bgp_peers: true
        bgp_peers:
          - ip_address: 10.10.1.2
            peer_group: EXTERNAL_PEERS
            nodes: [ DC1-BORDER-LEAF1 ]
```

### Platform-Specific Settings

Hardware validation tests can be disabled for platforms that don't support hardware commands.

```yaml
custom_platform_settings:
  - platforms: [ custom_virtual_platform ]
    feature_support:
      hardware_validation: false
```

!!! note
    By default, AVD does not generate hardware validation tests for known virtual platforms (vEOS, cEOS, etc.).

## AVD-generated Catalog Test Index

Below are the ANTA tests currently generated by AVD. We focus on integrating tests that are most relevant to AVD-generated designs, so not all tests from the ANTA library will be included.

!!! note
    If you believe a valuable test is missing, please let us know by raising a GitHub issue or submitting a pull request.

The table below shows which parts of the AVD structured configuration are used to generate the inputs for each ANTA test. Tests without a specific configuration source run checks that don't require variable inputs (e.g., checking for coredumps or generic system states).

| Test Class | Description | AVD Configuration Source for Inputs |
| :--- | :--- | :--- |
| [**VerifyAgentLogs**](https://anta.arista.com/stable/api/tests/system/#anta.tests.system.VerifyAgentLogs){:target="_blank"} | Verifies that there are no agent crash reports on the device. | *None* |
| [**VerifyAPIHttpsSSL**](https://anta.arista.com/stable/api/tests/security/#anta.tests.security.VerifyAPIHttpsSSL){:target="_blank"} | Verifies the SSL profile for the eAPI HTTPS server is valid and attached. | `management_api_http.https_ssl_profile` |
| [**VerifyAVTSpecificPath**](https://anta.arista.com/stable/api/tests/avt/#anta.tests.avt.VerifyAVTSpecificPath){:target="_blank"} | Verifies the status of specific AVT paths in the routing table. | <ul><li>`router_adaptive_virtual_topology.vrfs`</li><li>`router_path_selection.path_groups`</li><li>`static_peers`</li></ul> |
| [**VerifyBGPPeerSession**](https://anta.arista.com/stable/api/tests/routing.bgp/#anta.tests.routing.bgp.VerifyBGPPeerSession){:target="_blank"} | Verifies that BGP peer sessions are in an 'established' state. | **Sources:**<ul><li>`router_bgp.neighbors`</li><li>`router_bgp.neighbor_interfaces`</li><li>`router_bgp.vrfs[].neighbors`</li><li>`router_bgp.vrfs[].neighbor_interfaces`</li></ul>**Filters:**<ul><li>`router_bgp.neighbors[].shutdown == False`</li><li>`peer_group` → `router_bgp.peer_groups[name=peer_group].shutdown == False`</li><li>`metadata.peer` → `is_deployed == True`</li><li>`metadata.validate_state == True`</li></ul> |
| [**VerifyCoredump**](https://anta.arista.com/stable/api/tests/system/#anta.tests.system.VerifyCoredump){:target="_blank"} | Verifies that there are no coredump files in `/var/core`. | *None* |
| [**VerifyEnvironmentCooling**](https://anta.arista.com/stable/api/tests/hardware/#anta.tests.hardware.VerifyEnvironmentCooling){:target="_blank"} | Verifies the status of all fans and the overall environment cooling. | *None*,  default states=["ok"] |
| [**VerifyEnvironmentPower**](https://anta.arista.com/stable/api/tests/hardware/#anta.tests.hardware.VerifyEnvironmentPower){:target="_blank"} | Verifies the status of all power supply units (PSUs). | *None*,  default states=["ok"] |
| [**VerifyEnvironmentSystemCooling**](https://anta.arista.com/stable/api/tests/hardware/#anta.tests.hardware.VerifyEnvironmentSystemCooling){:target="_blank"} | Verifies the overall system cooling status is 'ok'. | *None* |
| [**VerifyFileSystemUtilization**](https://anta.arista.com/stable/api/tests/system/#anta.tests.system.VerifyFileSystemUtilization){:target="_blank"} | Verifies that no partition is utilizing more than 75% of its disk space. | *None* |
| [**VerifyIllegalLACP**](https://anta.arista.com/stable/api/tests/interfaces/#anta.tests.interfaces.VerifyIllegalLACP){:target="_blank"} | Verifies that no interfaces have received illegal LACP packets. | *None* |
| [**VerifyInterfaceDiscards**](https://anta.arista.com/stable/api/tests/interfaces/#anta.tests.interfaces.VerifyInterfaceDiscards){:target="_blank"} | Verifies that the interfaces packet discard counters are equal to zero. | *None* |
| [**VerifyInterfaceErrDisabled**](https://anta.arista.com/stable/api/tests/interfaces/#anta.tests.interfaces.VerifyInterfaceErrDisabled){:target="_blank"} | Verifies that no interfaces are in an `errdisabled` state. | *None* |
| [**VerifyInterfaceErrors**](https://anta.arista.com/stable/api/tests/interfaces/#anta.tests.interfaces.VerifyInterfaceErrors){:target="_blank"} | Verifies that interface error counters are not increasing. | *None* |
| [**VerifyInterfaceUtilization**](https://anta.arista.com/stable/api/tests/interfaces/#anta.tests.interfaces.VerifyInterfaceUtilization){:target="_blank"} | Verifies that interface utilization is below a defined threshold. | *None* |
| [**VerifyInterfacesStatus**](https://anta.arista.com/stable/api/tests/interfaces/#anta.tests.interfaces.VerifyInterfacesStatus){:target="_blank"} | Verifies the operational status of enabled network interfaces. | <ul><li>`ethernet_interfaces`</li><li>`port_channel_interfaces`</li><li>`vlan_interfaces`</li><li>`loopback_interfaces`</li><li>`dps_interfaces`</li><li>VXLAN interface, if the device is a VTEP</li></ul> |
| [**VerifyInventory**](https://anta.arista.com/stable/api/tests/hardware/#anta.tests.hardware.VerifyInventory){:target="_blank"} | Verifies the physical hardware inventory of the device. | `metadata.hardware_requirements` |
| [**VerifyLLDPNeighbors**](https://anta.arista.com/stable/api/tests/connectivity/#anta.tests.connectivity.VerifyLLDPNeighbors){:target="_blank"} | Verifies LLDP neighbors for Ethernet interfaces. | <ul><li>`ethernet_interfaces[]`</li><li>`ethernet_interfaces[].metadata.validate_state`</li><li>`ethernet_interfaces[].metadata.validate_lldp`</li><li>`ethernet_interfaces[].metadata.peer`</li><li>`ethernet_interfaces[].metadata.peer_interface`</li><li>`peer.metadata.is_deployed`</li><li>`peer.ethernet_interfaces[].shutdown`</li><li>`peer.dns_domain`</li></ul> |
| [**VerifyLoggingErrors**](https://anta.arista.com/stable/api/tests/logging/#anta.tests.logging.VerifyLoggingErrors){:target="_blank"} | Verifies that there are no 'error' or higher severity syslog messages in the last N minutes or entire buffer. | `metadata.validate_no_errors_period` *Optional, defaults to full buffer* |
| [**VerifyMaintenance**](https://anta.arista.com/stable/api/tests/system/#anta.tests.system.VerifyMaintenance){:target="_blank"} | Verifies that the device is not currently under or entering maintenance. | *None* |
| [**VerifyMemoryUtilization**](https://anta.arista.com/stable/api/tests/system/#anta.tests.system.VerifyMemoryUtilization){:target="_blank"} | Verifies whether the memory utilization is below 75%. | *None* |
| [**VerifyMlagConfigSanity**](https://anta.arista.com/stable/api/tests/mlag/#anta.tests.mlag.VerifyMlagConfigSanity){:target="_blank"} | Verifies the health and sanity of the MLAG configuration. | `mlag_configuration` |
| [**VerifyMlagInterfaces**](https://anta.arista.com/stable/api/tests/mlag/#anta.tests.mlag.VerifyMlagInterfaces){:target="_blank"} | Verifies there are no inactive or active-partial MLAG ports. | `mlag_configuration` |
| [**VerifyMlagStatus**](https://anta.arista.com/stable/api/tests/mlag/#anta.tests.mlag.VerifyMlagStatus){:target="_blank"} | Verifies the global MLAG state is 'active' and other parameters are consistent. | `mlag_configuration` |
| [**VerifyNTP**](https://anta.arista.com/stable/api/tests/system/#anta.tests.system.VerifyNTP){:target="_blank"} | Verifies that the device's NTP service is synchronized with a time source. | *None* |
| [**VerifyOSPFMaxLSA**](https://anta.arista.com/stable/api/tests/routing.ospf/#anta.tests.routing.ospf.VerifyOSPFMaxLSA){:target="_blank"} | Verifies that all OSPF instances did not cross the maximum LSA threshold. | `router_ospf` |
| [**VerifyOSPFNeighborState**](https://anta.arista.com/stable/api/tests/routing.ospf/#anta.tests.routing.ospf.VerifyOSPFNeighborState){:target="_blank"} | Verifies that all OSPF neighbors are in the *full* state; the *2Ways* state is **not** accepted. Use `VerifyOSPFSpecificNeighbors` in a user-defined catalog instead for any device with a neighbor that is expected to be in the *2Ways* state. | `router_ospf` |
| [**VerifyPortChannels**](https://anta.arista.com/stable/api/tests/interfaces/#anta.tests.interfaces.VerifyPortChannels){:target="_blank"} | Verifies the status of Port-Channel interfaces and their members. | `port_channel_interfaces` |
| [**VerifyReachability**](https://anta.arista.com/stable/api/tests/connectivity/#anta.tests.connectivity.VerifyReachability){:target="_blank"} | <ul><li>Verifies point-to-point reachability between Ethernet interfaces.</li><li>Verifies VTEP fabric-wide underlay reachability. **Requires:** `avd_catalogs_extra_fabric_validation: true` (role variable)</li><li>Verifies inband management reachability. **Requires:** `avd_catalogs_extra_fabric_validation: true` (role variable)</li><li>Verifies DPS-to-DPS reachability between WAN routers. **Requires:** `avd_catalogs_extra_fabric_validation: true` (role variable)</li><li>Verifies reachability to BGP neighbors.</li></ul> | <ul><li>`ethernet_interfaces`</li><li>`loopback_interfaces`</li><li>`vlan_interfaces`</li><li>`dps_interfaces`</li><li>`router_bgp`</li></ul> |
| [**VerifyReloadCause**](https://anta.arista.com/stable/api/tests/system/#anta.tests.system.VerifyReloadCause){:target="_blank"} | Verifies that the last reload cause was expected. | *Allowed causes:*<ul><li>**USER** - Reload requested by the user.</li><li>**USER_HITLESS** - Hitless reload requested by the user.</li><li>**FPGA** - Reload requested after FPGA upgrade</li><li>**ZTP** - System reloaded due to Zero Touch Provisioning</li></ul> |
| [**VerifyRoutingProtocolModel**](https://anta.arista.com/stable/api/tests/routing.generic/#anta.tests.routing.generic.VerifyRoutingProtocolModel){:target="_blank"} | Verifies the configured routing protocol model. | `service_routing_protocols_model` |
| [**VerifyRoutingTableEntry**](https://anta.arista.com/stable/api/tests/routing.generic/#anta.tests.routing.generic.VerifyRoutingTableEntry){:target="_blank"} | Verifies that Loopback0 and VTEP IPs from all fabric devices (excluding WAN routers) are present in the routing table of VTEP devices to ensure proper IPv4 underlay routing. IPv6 underlays are *not* tested. | Fabric-wide collection of:<ul><li>`loopback_interfaces[name=Loopback0].ip_address`</li><li>`vxlan_interface.vxlan1.vxlan.source_interface` → `loopback_interfaces[name=<source_interface>].ip_address`</li><li>`vxlan_interface.vxlan1.vxlan.mlag_source_interface` → `loopback_interfaces[name=<mlag_source_interface>].ip_address`</li></ul><br>**Requires:** `avd_catalogs_extra_fabric_validation: true` (role variable) |
| [**VerifyRunningConfigDiffs**](https://anta.arista.com/stable/api/tests/configuration/#anta.tests.configuration.VerifyRunningConfigDiffs){:target="_blank"} | Verifies there are no differences between the running and startup configs. | *None* |
| [**VerifySpecificIPSecConn**](https://anta.arista.com/stable/api/tests/security/#anta.tests.security.VerifySpecificIPSecConn){:target="_blank"} | Verifies the status of specific IPSec tunnels. | `router_path_selection` |
| [**VerifySpecificPath**](https://anta.arista.com/stable/api/tests/path_selection/#anta.tests.path_selection.VerifySpecificPath){:target="_blank"} | Verifies the DPS path and telemetry state of an IPv4 peer. | `router_path_selection` |
| [**VerifySTPCounters**](https://anta.arista.com/stable/api/tests/stp/#anta.tests.stp.VerifySTPCounters){:target="_blank"} | Verifies there is no errors in STP BPDU packets. | *None* |
| [**VerifyStormControlDrops**](https://anta.arista.com/stable/api/tests/interfaces/#anta.tests.interfaces.VerifyStormControlDrops){:target="_blank"} | Verifies that no interfaces are dropping packets due to storm-control. | *None* |
| [**VerifyTemperature**](https://anta.arista.com/stable/api/tests/hardware/#anta.tests.hardware.VerifyTemperature){:target="_blank"} | Verifies that all device temperature sensors are within their alert thresholds. | *None* |
| [**VerifyTransceiversManufacturers**](https://anta.arista.com/stable/api/tests/hardware/#anta.tests.hardware.VerifyTransceiversManufacturers){:target="_blank"} | Verifies if all the transceivers come from approved manufacturers. | `metadata.hardware_requirements.transceiver_manufacturers` |
| [**VerifyTransceiversTemperature**](https://anta.arista.com/stable/api/tests/hardware/#anta.tests.hardware.VerifyTransceiversTemperature){:target="_blank"} | Verifies that all transceiver temperature sensors are within their alert thresholds. | *None* |
| [**VerifyVxlanConfigSanity**](https://anta.arista.com/stable/api/tests/vxlan/#anta.tests.vxlan.VerifyVxlanConfigSanity){:target="_blank"} | Verifies the health and sanity of the VXLAN configuration. | `vxlan_interface.vxlan1.vxlan` |
| [**VerifyZeroTouch**](https://anta.arista.com/stable/api/tests/configuration/#anta.tests.configuration.VerifyZeroTouch){:target="_blank"} | Verifies that the Zero Touch Provisioning (ZTP) process is not active. | *None* |

## Logging and Troubleshooting

This section details how to control log verbosity, understand log output, and diagnose common issues for the `anta_runner` role.

### Controlling Log Verbosity

The `anta_runner` role uses Ansible standard verbosity flags (`-v`, `-vv`, etc.) to control log output from its various components, including PyAVD, ANTA, underlying libraries, and the `anta_workflow` action plugin. Adjust the verbosity level using the `ansible-playbook` command:

```bash
ansible-playbook playbooks/anta-runner.yml -vvv
```

!!! tip
    Running `ansible-playbook` with `-vvv` is particularly helpful to troubleshoot why some specific AVD-generated tests are missing from a device's final catalog. PyAVD will output detailed information about skipped tests and the reasons for their exclusion.

### Understanding Log Output

`anta_runner` processes devices in parallel batches for improved performance. To help correlate log messages to specific operations or device batches, each log entry is prefixed with a unique identifier:

- `anta-workflow`: Indicates logs from the main Ansible action plugin process.
- `anta-run-xxxxxxxx`: Indicates logs from a specific ANTA execution run handling a batch of devices.

These prefixes are essential when debugging issues related to a particular device or test batch.

### Managing Log Files

Console logs adhere to standard Ansible logging configurations. For persistent storage and easier analysis, especially when using high verbosity, consider configuring `log_path` in your `ansible.cfg` file to redirect the primary output stream to the specified log file. For more details, refer to the [Ansible documentation](https://docs.ansible.com/ansible/latest/reference_appendices/logging.html).

## License

Project is published under [Apache 2.0 License](https://github.com/aristanetworks/avd/blob/devel/LICENSE).

## Known Issues

- `[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.` This issue affects OSX users only and is covered in Ansible documentation: https://docs.ansible.com/ansible/latest/reference_appendices/faq.html#running-on-macos-as-a-control-node.
