Ansible Automation Ansible for Network Automation 2 — Questions and Answers
Question 1: What is the purpose of the 'ansible.netcommon.net_get' and 'net_put' modules?
- net_get transfers files from network devices to the control node; net_put transfers files from the control node to network devices (Correct answer)
- net_get retrieves configuration facts; net_put pushes configuration changes
- They are used for SCP/SFTP file transfer to Linux-based network devices only
- net_get downloads IOS images; net_put uploads new firmware
Correct answer: net_get transfers files from network devices to the control node; net_put transfers files from the control node to network devices
'net_get' copies files FROM network devices (config backups, logs); 'net_put' copies files TO network devices (new configs, firmware).
File transfer modules for network devices: net_get (device → control node): - name: Backup running configuration ansible.netcommon.net_get: src: running-config dest: /backups/{{ inventory_hostname }}-{{ ansible_date_time.date }}.cfg net_put (control node → device): - name: Push new configuration ansible.netcommon.net_put: src: /configs/{{ inventory_hostname }}.cfg dest: startup-config These modules handle the underlying SCP/SFTP/HTTP transfer protocols supported by specific network devices. They are vendor-agnostic when used with appropriate connection plugins, and support various transfer protocols (SCP, FTP, HTTP) depending on device capabilities.
Question 2: What is the 'network_cli' persistent connection and why is it important for performance?
- It maintains a persistent SSH connection across multiple tasks rather than reconnecting for each task, significantly reducing playbook execution time (Correct answer)
- It creates a dedicated network interface on the control node for device communication
- It enables simultaneous connections to multiple devices in a single SSH session
- It persists connection state between separate playbook runs
Correct answer: It maintains a persistent SSH connection across multiple tasks rather than reconnecting for each task, significantly reducing playbook execution time
Persistent connections reuse established SSH sessions across multiple tasks, avoiding the overhead of repeated SSH handshakes and authentication for every task.
Network CLI persistent connections work via the 'ansible-connection' daemon: - SSH connection established once per host per play - All tasks in the play reuse the same connection - Configured via ansible.cfg: [persistent_connection] connect_timeout = 60 command_timeout = 30 connect_retry_timeout = 15 Without persistence: 100 tasks × 2s SSH handshake = 200s overhead per host With persistence: 1 SSH handshake + 100 commands = ~2s overhead Persistent connections are enabled by default for network_cli. The 'ansible-connection' background process manages the connection pools. Connection timeout and command timeout settings are critical for slow WAN-connected devices.
Question 3: How do you create a network automation inventory that separates Cisco IOS, NX-OS, and Junos devices?
- Create inventory groups with group_vars defining ansible_network_os and connection parameters per vendor (Correct answer)
- Create separate inventory files per vendor and merge them at runtime
- Use a dynamic inventory script that auto-detects device OS types
- Network inventories cannot be mixed; one inventory per OS type is required
Correct answer: Create inventory groups with group_vars defining ansible_network_os and connection parameters per vendor
Group-based inventories with group_vars per vendor type is the standard pattern for managing heterogeneous network environments.
Multi-vendor network inventory structure: inventory.ini: [ios_routers] router1 ansible_host=10.1.1.1 router2 ansible_host=10.1.1.2 [nxos_switches] switch1 ansible_host=10.2.1.1 [junos_firewalls] fw1 ansible_host=10.3.1.1 group_vars/ios_routers.yml: ansible_connection: network_cli ansible_network_os: cisco.ios.ios ansible_user: admin ansible_become: true ansible_become_method: enable group_vars/nxos_switches.yml: ansible_connection: network_cli ansible_network_os: cisco.nxos.nxos ansible_user: admin group_vars/junos_firewalls.yml: ansible_connection: netconf ansible_network_os: junipernetworks.junos.junos ansible_user: automation
Question 4: What is the role of 'napalm' (Network Automation and Programmability Abstraction Layer with Multivendor support) in Ansible network automation?
- NAPALM provides a vendor-agnostic Python API for network devices that Ansible can use via the 'napalm' collection, enabling consistent operations across IOS, NX-OS, EOS, and Junos (Correct answer)
- NAPALM is Ansible's internal connection framework for all network protocols
- NAPALM replaces SSH with a proprietary protocol for faster network automation
- NAPALM is a Cisco-developed library that only works with Cisco products
Correct answer: NAPALM provides a vendor-agnostic Python API for network devices that Ansible can use via the 'napalm' collection, enabling consistent operations across IOS, NX-OS, EOS, and Junos
NAPALM abstracts vendor differences, providing a unified API for operations like get_interfaces(), get_bgp_neighbors(), and load_merge_candidate() across multiple network OS vendors.
NAPALM (Network Automation and Programmability Abstraction Layer with Multivendor support): Vendor drivers: EOS, IOS, IOS-XR, NX-OS, JunOS Unified operations: - get_facts(): Device information - get_interfaces(): Interface details - get_bgp_neighbors(): BGP peer information - load_merge_candidate(): Merge config changes - load_replace_candidate(): Replace configuration - commit_config(): Apply changes - discard_config(): Roll back pending changes - compare_config(): Show diff before committing Ansible NAPALM collection ('napalm.napalm'): - napalm_get_facts - napalm_install_config - napalm_validate NAPALM's atomic config operations with diff/commit/rollback provide safer network change management than raw CLI commands.
Question 5: What is 'config diff' functionality in Ansible network modules and why is it useful?
- Network config modules can show a diff between desired and current device configuration, enabling review before applying changes and supporting --check mode (Correct answer)
- Config diff compares running vs startup configuration on the device
- It shows differences between two network device configurations for compliance
- Config diff is a backup feature that tracks configuration changes over time
Correct answer: Network config modules can show a diff between desired and current device configuration, enabling review before applying changes and supporting --check mode
Network modules' diff support enables reviewing what would change before applying, similar to 'terraform plan', enabling safer network change management.
Network config diff with Ansible: $ ansible-playbook network-config.yml --check --diff Output shows: --- before +++ after @@ -10,6 +10,7 @@ interface GigabitEthernet0/0 ip address 192.168.1.1 255.255.255.0 + description WAN_UPLINK no shutdown This enables: 1. Change review workflow: Run --check --diff to generate a change proposal for approval 2. CI/CD integration: Fail pipeline if unexpected changes detected 3. Auditing: Save diff output to document what changes were made 4. Rollback planning: Know exactly what changed if issues occur Modules like ios_config, eos_config, and junos_config natively support --check and --diff modes.
Question 6: How do you generate network device configurations from templates using Ansible?
- Use the 'template' module with Jinja2 templates to render device-specific configurations from variable data, then push with network config modules (Correct answer)
- Use ios_template or similar vendor-specific template modules
- Configuration generation requires external tools—Ansible only pushes pre-built configs
- Use ansible-builder to generate device configurations from YANG models
Correct answer: Use the 'template' module with Jinja2 templates to render device-specific configurations from variable data, then push with network config modules
Jinja2 templating with variable-driven data is the standard approach for generating consistent, scalable network device configurations.
Network config generation with Jinja2 templates: templates/cisco_interface.j2: {% for interface in interfaces %} interface {{ interface.name }} description {{ interface.description }} {% if interface.ip is defined %} ip address {{ interface.ip }} {{ interface.mask }} {% endif %} no shutdown ! {% endfor %} Playbook task: - name: Generate config template: src: cisco_interface.j2 dest: /configs/{{ inventory_hostname }}.cfg - name: Push config cisco.ios.ios_config: src: /configs/{{ inventory_hostname }}.cfg With host_vars containing interface lists per device, this generates hundreds of device configurations from a single template. Combined with group_vars for shared parameters, this scales to thousands of devices.
Ansible Automation Ansible for Network Automation 2
What is the purpose of the 'ansible.netcommon.net_get' and 'net_put' modules?