You might use the *_facts modules in plays where you need to access current configuration settings for your managed nodes, but where you do not necessarily need to save this information. To collect a full set of facts, disable fact gathering at the play level with gather_facts: false, and then add a task such as the following:

- name: Collect facts
  cisco.ios.ios_facts:
    gather_subset:
      - all

If a task gathered configuration facts, then you might use the following task to display those facts:

- name: Display ansible_facts['net_config']
  ansible.builtin.debug:
    var: ansible_facts['net_config']

You might use filters to process the ansible_facts['net_config'] variable, such as the regex_findall filter to search for a pattern, or the split filter to convert the variable into a list where each line is a list item:

- name: Display SNMP configuration
  ansible.builtin.debug:
    var: ansible_facts['net_config'] | regex_findall('^snmp.*$', multiline=true)

- name: Display configuration as a list
  vars:
    separator: "\n"
  ansible.builtin.debug:
    var: ansible_facts['net_config'] | split(separator)

To make it easier to use a variable in another playbook task, you might use the ansible.builtin.set_fact module. The following example uses that module to set the snmp_config_lines variable. Another task could then use the snmp_config_lines variable. In this example, the ansible.builtin.debug module displays the snmp_config_lines variable if the variable contains at least one list item:

- name: Set snmp_config_lines
  ansible.builtin.set_fact:
    snmp_config_lines: >-
      {{ ansible_facts['net_config'] |
      regex_findall('^snmp.*$', multiline=true) }}

- name: Display snmp_config_lines
  when: snmp_config_lines | length > 0
  ansible.builtin.debug:
    var: snmp_config_lines

Usually, the content of a backup file matches the content in the ansible_facts['net_config'] variable. When that is true, you might find it easier to use gathered configuration facts rather than creating and processing backup files.

For Juniper Junos managed nodes, the content of a backup file does not match the content in the ansible_facts['net_config'] variable, and the content of that variable can be difficult to process. The junipernetworks.junos.junos_config module provides the backup_format option, which is not found in other *_config modules. Changing the format of backup files to something different from the default set format might help with processing the backup files. If you create backup files using the JSON format, then you can process those backup files using the from_json filter.

The following example creates a backup file in JSON format for each Juniper Junos managed node:

- name: Create a backup file
  junipernetworks.junos.junos_config:
    backup: true
    backup_options:
      filename: "{{ inventory_hostname }}.json"
      backup_format: json

If you decide to process the content of backup files, then you might use the ansible.builtin.slurp module. This module works for both local and remote files.

Using the ansible.builtin.slurp module typically involves two steps:

- name: Slurp backup file
  ansible.builtin.slurp:
    src: /backups/junos1.lab.example.com.json 
  register: slurped_file

- name: Display decoded slurped_file['content']
  ansible.builtin.debug:
    var: slurped_file['content'] | b64decode | from_json 

- name: Set json_content
  ansible.builtin.set_fact: 
    json_content: >
      {{ slurped_file['content'] | b64decode | from_json }}

- name: Show json_content['configuration']['interfaces']
  ansible.builtin.debug:
    var: >-
      json_content['configuration']['interfaces'] 

For backup files that do not use JSON format, you might use filters such as the regex_findall, regex_search, or split filters for additional data processing.

You can use the resource_manager role from the network.base collection to generate YAML files that contain information about the infrastructure of your managed nodes. The following example defines the action variable with the persist value. This action causes the role to save infrastructure information about your managed nodes.

- name: Network Resource Manager
  ansible.builtin.include_role:
    name: network.base.resource_manager
  vars:
    action: persist
    inventory_directory: ./

If the inventory file in your Ansible project uses the INI format, then you can redirect the output of the ansible-navigator inventory command to create a YAML version of the inventory file:

[user@host project]$ ansible-navigator inventory -i inventory --list \
--yaml > inventory.yaml

The previous command generates a file with content similar to the following example:

all:
  children:
    ios:
      hosts:
        iosxe1.lab.example.com:
          ansible_become: true
          ansible_become_method: enable
          ansible_connection: ansible.netcommon.network_cli
          ansible_network_os: cisco.ios.ios
          ansible_ssh_private_key_file: ~/.ssh/lab_rsa
          ansible_user: student
        iosxe2.lab.example.com:
          ansible_become: true
          ansible_become_method: enable
          ansible_connection: ansible.netcommon.network_cli
          ansible_network_os: cisco.ios.ios
          ansible_ssh_private_key_file: ~/.ssh/lab_rsa
          ansible_user: student
    ungrouped: {}

If your Ansible project already defines host variables in the host_vars directory or group variables in the group_vars directory, then you can delete the variable information from the inventory.yaml file. After removing the variables, the previous example consists of the following content:

all:
  children:
    ios:
      hosts:
        iosxe1.lab.example.com:
        iosxe2.lab.example.com:
    ungrouped: {}

After creating an inventory.yaml file, update your ansible-navigator.yml file or your ansible.cfg file to point to the new inventory file. You can then delete the previous inventory file.

When you use the persist action of the network.base.resource_manager role, the play creates the host_vars directory in the directory specified by the inventory_directory variable. In the host_vars directory, the play creates a directory for each managed node and then creates YAML files for the collected resources. For the iosxe1.lab.example.com managed node, you might see the following files:

[user@host project]$ tree host_vars/iosxe1.lab.example.com/
host_vars/iosxe1.lab.example.com/
├── acls.yaml
├── hostname.yaml
├── interfaces.yaml
├── l2_interfaces.yaml
├── l3_interfaces.yaml
├── lacp.yaml
├── lacp_interfaces.yaml
├── ospf_interfaces.yaml
├── static_routes.yaml
└── vlans.yaml

After you create these files, you can use the content in these files as regular host variables. Based on the content of the l3_interfaces.yaml file, you might use the following task to display the IPv4 addresses for the GigabitEthernet1 interface:

- name: Show IPv4 addresses for the GigabitEthernet1 interface
  ansible.builtin.debug:
    var: >-
      hostvars[inventory_hostname]['l3_interfaces'] |
      selectattr('name', '==', 'GigabitEthernet1') |
      map(attribute='ipv4') |
      flatten |
      map(attribute='address')

This task might result in the following output:

TASK [Show the IPv4 address for the GigabitEthernet1 interface] ****************
ok: [iosxe1.lab.example.com] => {
    "hostvars[inventory_hostname]['l3_interfaces'] | selectattr('name', '==', 'GigabitEthernet1') | map(attribute='ipv4') | flatten | map(attribute='address')": [
        "172.25.250.20/24"
    ]
}

As with the other methods for gaining infrastructure awareness, you might use the ansible.builtin.set_fact module to make it easier for additional tasks to work with specific pieces of data.