Skip to content

eos_validate_state

Overview

eos_validate_state is a role leveraged to validate Arista EOS devices’ operational states.

eos_validate_state role:

  • Consumes structured EOS configuration file, the same input as the role eos_cli_config_gen. This input is considered the system of record (the desired state).
  • Leverages Arista Network Test Automation (ANTA) framework to:
    • Connect to EOS devices via eAPI to collect operational states (actual state). This requires access to the configured devices.
    • Compare the actual states against the desired state.
  • Generates CSV and Markdown reports of the results.
  • Supports Ansible check mode. When running in check mode, eos_validate_state produces a report of tests that would be performed without running the tests on your network. Tests will be marked as NOT RUN in the final reports. This can be useful to inspect which tests are going to be run.
ansible-playbook playbooks/fabric-validate.yaml --check
  • This role supports additional level of verbosity in Ansible. In particular, when run with -v, logs gives visibility on which test categories are being removed from a device catalog by AVD according to the structured configurations.

Role Inputs and Outputs

Figure 1 below provides a visualization of the role’s inputs, outputs, and tasks in order executed by the role.

Figure 1: Ansible Role eos_validate_state Figure 1: Ansible Role eos_validate_state

Inputs:

  • Devices’ structured configurations generated by abstraction role.
  • Device state (collected during ANTA test execution).
  • Custom ANTA test catalogs (optional).

Outputs:

  • JSON test results (per device).
  • ANTA test catalog (per device, optional).
  • CSV report.
  • Markdown report.

Tasks:

  1. Include devices’ structured configurations.
  2. Generate per-device test catalogs:
    • Optionally store catalogs
    • Execute tests using ANTA
    • Store results as JSON
  3. Generate CSV and Markdown reports.

Tip

You can provide your own custom ANTA catalogs using any of the available ANTA tests to the AVD eos_validate_state role. Please refer to the Custom ANTA catalog section for more details.

Test categories

  • AvdTestHardware
    • VerifyEnvironmentPower: Validate environment power supplies status.
    • VerifyEnvironmentCooling: Validate environment fan status.
    • VerifyTemperature: Validate environment temperature.
    • VerifyTransceiversManufacturers: Validate transceivers manufacturer.
  • AvdTestNTP
    • VerifyNTP: Validate NTP status.
  • AvdTestInterfacesState
    • VerifyInterfacesStatus: Validate interfaces status.
      • Ethernet interfaces
      • Port-channel interfaces
      • Vlan interfaces
      • Loopback interfaces
      • Vxlan1 interface
      • DPS interfaces
  • AvdTestP2PIPReachability
    • VerifyReachability: Validate IP reachability for point-to-point l3 ethernet interfaces.
  • AvdTestInbandReachability
    • VerifyReachability: Validate loopback reachability from the inband management VLAN interface.
  • AvdTestLoopback0Reachability
    • VerifyReachability: Validate loopback reachability between devices.
  • AvdTestDpsReachability
    • VerifyReachability: Validate DPS reachability between devices.
  • AvdTestLLDPTopology
    • VerifyLLDPNeighbors: Validate LLDP topology.
  • AvdTestMLAG
    • VerifyMlagStatus: Validate MLAG status.
  • AvdTestRoutingTable
    • VerifyRoutingTableEntry: Validate remote Loopback0 address and source interface for Vxlan1 interface are in the routing table.
  • AvdTestBGP
    • VerifyBGPSpecificPeers: Validate IP BGP and BGP EVPN sessions state.
    • VerifyRoutingProtocolModel: Validate ArBGP is configured and operating.
  • AvdTestReloadCause
    • VerifyReloadCause: Validate last reload cause. (Optional)
  • AvdTestAPIHttpsSSL
    • VerifyAPIHttpsSSL: Validate eAPI HTTPS SSL profile status.
  • AvdTestIPSecurity
    • VerifySpecificIPSecConn: Validates the establishment of IP security connections for a peer within the default VRF. In its current state, the test validates only IPsec connections defined as static peers under the router path-selection section of the configuration.
  • AvdTestStun
    • VerifyStunClient: Validates the presence of a STUN client translation for a given source IPv4 address and port for WAN scenarios. The list of expected translations for each device is built by searching local interfaces in each path-group.
  • AvdTestAvtRole
    • VerifyAVTRole: Validate the Adaptive Virtual Topology (AVT) role of a device.
    • VerifyAVTSpecificPath: Validate that the status is active and the type is direct for an Adaptive Virtual Topology (AVT) path in a specified VRF for the static peers.

Input Variables

The following input variables are available for the role. When a default value exists, it is indicated.

# Root directory.
root_dir: <str; | default="{{ inventory_dir }}">

# Output directory.
output_dir_name: <str; | default="intended">
output_dir: <str; | default="{{ root_dir }}/{{ output_dir_name }}">

# Output for test catalog YAML files if save_catalog is set to true.
test_catalogs_dir_name: "<str; | default="test_catalogs">
test_catalogs_dir: <str; | default="{{ output_dir }}/{{ test_catalogs_dir_name }}">

# Output directory for eos_validate_state reports.
eos_validate_state_name: <str; | default="reports">
eos_validate_state_dir: <str; | default="{{ root_dir }}/{{ eos_validate_state_name }}">

# Output for test results JSON files if save_results is set to true.
test_results_dir_name: <str; | default="test_results">
test_results_dir: <str; | default="{{ eos_validate_state_dir }}/{{ test_results_dir_name }}">

# Reports name.
eos_validate_state_md_report_path: <str; | default="{{ eos_validate_state_dir }}/{{ fabric_name }}-state.md">
eos_validate_state_csv_report_path: <str; | default="{{ eos_validate_state_dir }}/{{ fabric_name }}-state.csv">

# Input directory for structured configuration files.
structured_dir_name: <str; | default="structured_configs">
structured_dir: <str; | default="{{ output_dir }}/{{ structured_dir_name }}">

# Structured configuration files format.
avd_structured_config_file_format: "yml"

# Input directory for custom ANTA catalogs.
custom_anta_catalogs_dir_name: <str; | default="custom_anta_catalogs">
custom_anta_catalogs_dir: <str; | default="{{ root_dir }}/{{ custom_anta_catalogs_dir_name }}">

# Allow different manufacturers.
accepted_xcvr_manufacturers: <list; | default="['Arastra, Inc.', 'Arista Networks']">

# Allow different states for power supplies.
accepted_pwr_supply_states: <list; default=['ok']>

# Allow different states for fans.
accepted_fan_states: <list; default=['ok']">

# Generate CSV results file.
validation_report_csv: <bool; default=True>

# Generate MD results file.
validation_report_md: <bool; default=True>

# Print only FAILED tests.
only_failed_tests: <bool; default=False>

# Save each device test catalog to 'test_catalogs_dir'.
save_catalog: <bool; default=False>

# Logging level for the ANTA libraries.
logging_level: <str; "INFO" | "WARNING" | "ERROR" | "CRITICAL" | "DEBUG"; default="WARNING">

# The variable `skip_tests` can be used for running/skipping test categories.
# Examples
# skip_tests:
#   - category: AvdTestHardware
#
# or to skip specific tests (ANTA test names) in a given category for more granularity:
# skip_tests:
#  - category: AvdTestHardware
#    tests:
#      - VerifyEnvironmentCooling
#      - VerifyTemperature
#  - category: AvdTestBGP
#    tests:
#      - VerifyBGPSpecificPeers
skip_tests:
  - category: <str>
    # Optional tests
    tests:
      - <str>

The default accepted manufacturers are “Arastra, Inc.” and “Arista Networks.” To change this, use accepted_xcvr_manufacturers.

By default, all fans and power supplies are expected to be in the ok state. However chassis switches may intentionally be missing some fans or power supplies as they are not fully populated. In this case, accepted_fan_states and accepted_pwr_supply_states can be updated to include the notInserted state to avoid failures on missing fans/power supplies.

Two user-defined variables control the generation of CSV and MD reports. These are validation_report_csv and validation_report_md respectively.

The variable only_failed_tests is used to limit the number of tests shown in the reports. When set, all reports will only show failed tests.

Requirements

Requirements are located here: avd-requirements

Custom ANTA catalog

You can provide custom ANTA catalogs to the AVD eos_validate_state role. By default, AVD will search for catalog YAML files in the custom_anta_catalogs directory and incorporate these tests into the existing dynamically created catalog from AVD. The custom catalog files must be named as follows:

  • <hostname>.yml or <hostname>.yaml
  • <group>.yml or <group>.yaml

When specifying a group, it must be a group from the Ansible inventory. The custom tests will then be added to all devices that are part of this group. You can also use the all group to target all the devices in your inventory. The directory where the custom catalogs are stored can be changed with the custom_anta_catalogs_dir variable.

Warning

The skip_tests variable will ONLY skip the dynamically generated tests from the AVD validate state role. It will not skip tests added from custom catalogs.

Info

The final catalog will be validated by ANTA before running the tests on your network. Duplicate tests with the same inputs will be automatically removed. Therefore, dynamically generated tests by AVD will never be overwritten. To overwrite them, you should first skip them using the skip_tests variable and provide your own tests with inputs via a custom catalog.

Example Playbook

---
- name: validate states on EOS devices using ANTA
  hosts: DC1
  gather_facts: false
  tasks:
    - name: validate states on EOS devices
      ansible.builtin.import_role:
        name: arista.avd.eos_validate_state
      vars:
        # Optionally save catalogs
        save_catalog: true

Input example

inventory/inventory.ini

---
all:
  children:
    DC1:
      children:
        DC1_FABRIC:
          children:
            DC1_SPINES:
              hosts:
                switch2:
                  ansible_host: 10.83.28.190
            DC1_L3LEAFS:
              children:
                DC1_LEAF1:
                  hosts:
                    switch1:
                      ansible_host: 10.83.28.216
                DC1_LEAF2:
                  hosts:
                    switch3:
                      ansible_host: 10.83.28.191

inventory/group_vars/DC1.yml

ansible_user: arista
ansible_password: arista
ansible_network_os: eos
ansible_become: yes
ansible_become_method: enable
ansible_become_password: arista
ansible_connection: httpapi

fabric_name: "DC1"

accepted_xcvr_manufacturers:
  - Manufacturer 1
  - Manufacturer 2
accepted_pwr_supply_states:
  - ok
  - notInserted
accepted_fan_states:
  - ok
  - notInserted

inventory/intended/structured_configs/switch1.yml

router_bgp:
  neighbors:
    - ip_address: 10.10.10.1
      remote_as: 65002
    - ip_address: 10.10.10.3
      remote_as: 65003

ethernet_interfaces:
  - name: Ethernet2
    peer: switch3
    peer_interface: Ethernet4
    ip_address: 10.10.10.2/31
    type: routed
  - name: Ethernet5
    peer: switch2
    peer_interface: Ethernet5
    ip_address: 10.10.10.0/31
    type: routed

mlag_configuration:
  domain_id: MLAG12
  local_interface: Vlan4094
  peer_address: 172.16.12.1
  peer_link: Port-Channel10
  reload_delay_mlag: 300
  reload_delay_non_mlag: 330

ntp:
  local_interface:
    interface: Management1
    vrf: MGMT
  servers:
    - name: 0.fr.pool.ntp.org
      vrf: MGMT
    - name: 1.fr.pool.ntp.org
      vrf: MGMT

dns_domain: lab.local

Usage example

ansible-playbook playbooks/pb_validate_yml --inventory inventory/inventory.yml

License

Project is published under Apache 2.0 License

Known issues