Ansible Automation Ansible for Network Automation 1 — Questions and Answers
Question 1: What is the primary difference between Ansible's 'network_cli' and 'netconf' connection types for network devices?
- network_cli connects via SSH and executes CLI commands; netconf connects via SSH port 830 using XML-based NETCONF protocol for structured data exchange (Correct answer)
- network_cli is for Cisco devices only; netconf works with all vendors
- netconf is older and deprecated; network_cli is the modern replacement
- They are identical but network_cli is faster due to persistent connections
Correct answer: network_cli connects via SSH and executes CLI commands; netconf connects via SSH port 830 using XML-based NETCONF protocol for structured data exchange
'network_cli' is SSH-based CLI automation; 'netconf' provides structured YANG-modeled data access via the NETCONF protocol on supported devices.
Ansible network connection types:
'network_cli':
- Connects via standard SSH (port 22)
- Sends CLI commands and parses text output
- Supported by virtually all network vendors
- Works even on legacy devices
- Uses connection: network_cli in inventory/group_vars
'netconf':
- Connects via SSH on port 830
- Exchanges structured XML data using NETCONF RPC
- Supported by modern network devices (Junos, IOS-XE 16.6+, NX-OS)
- Enables atomic configuration changes and rollback
- Data is structured (YANG models) making parsing unnecessary
'httpapi':
- Connects via REST/HTTP APIs (NX-OS NX-API, EOS eAPI, FortiOS)
- JSON or XML data exchange
Question 2: In Ansible network automation, why is 'ansible_network_os' an important inventory variable?
- It tells Ansible which network OS modules and connection plugins to use, determining how commands are formatted and sent to the device (Correct answer)
- It specifies the version of the network operating system installed on the device
- It selects which Python library to use for parsing network output
- It determines which user account Ansible uses for authentication
Correct answer: It tells Ansible which network OS modules and connection plugins to use, determining how commands are formatted and sent to the device
'ansible_network_os' identifies the device OS type, enabling Ansible to use the correct connection plugin, modules, and command syntax for that platform.
'ansible_network_os' is critical for network automation:
[cisco]
router1 ansible_host=192.168.1.1 ansible_network_os=cisco.ios.ios
[juniper]
fw1 ansible_host=10.0.0.1 ansible_network_os=junipernetworks.junos.junos
Common values:
- cisco.ios.ios (Cisco IOS/IOS-XE)
- cisco.nxos.nxos (Cisco NX-OS)
- cisco.eos.eos (Arista EOS)
- junipernetworks.junos.junos
- ansible.netcommon.network_cli
This variable, combined with 'ansible_connection', determines:
1. Which connection plugin handles SSH
2. How privilege escalation works (enable mode)
3. How commands are terminated (newline handling)
4. Which modules are compatible
Question 3: What does the 'cisco.ios.ios_command' module do and when should 'ios_config' be used instead?
- ios_command runs show commands and captures output for analysis; ios_config is used to push configuration changes to the device (Correct answer)
- ios_command is for configuration; ios_config is for show commands
- ios_command supports all IOS commands; ios_config only supports interface configuration
- They are equivalent; the choice depends on personal preference
Correct answer: ios_command runs show commands and captures output for analysis; ios_config is used to push configuration changes to the device
'ios_command' is for operational/show commands to gather data; 'ios_config' is for making configuration changes in a structured, idempotent way.
Cisco IOS Ansible modules:
ios_command (read/operational):
- name: Get interface status
cisco.ios.ios_command:
commands:
- show interfaces
- show ip route
register: output
ios_config (write/configuration):
- name: Configure OSPF
cisco.ios.ios_config:
lines:
- router ospf 1
- network 10.0.0.0 0.0.0.255 area 0
save_when: modified
Key differences:
- ios_config is idempotent (checks if config exists before applying)
- ios_config can save config with 'save_when'
- ios_command returns raw text output requiring parsing
- Use 'cisco.ios.ios_facts' to gather structured device information
Question 4: What is a 'network facts module' in Ansible, and what information does 'ios_facts' typically return?
- Facts modules gather structured device information (hostname, interfaces, routing, VLANS, version) and store it as Ansible variables (Correct answer)
- Facts modules return device hardware specifications only
- Facts modules execute show commands and return raw text output
- Facts modules generate configuration backup files from the device
Correct answer: Facts modules gather structured device information (hostname, interfaces, routing, VLANS, version) and store it as Ansible variables
Network facts modules parse device output into structured Ansible variables, enabling condition-based automation without manual text parsing.
ios_facts (cisco.ios.ios_facts) collects and structures:
- ansible_net_hostname: Device hostname
- ansible_net_version: IOS version
- ansible_net_serialnum: Serial number
- ansible_net_model: Hardware model
- ansible_net_interfaces: Dict of all interfaces with IP, admin/oper state, description
- ansible_net_neighbors: CDP/LLDP neighbor information
- ansible_net_config: Running configuration
Usage:
- name: Gather IOS facts
cisco.ios.ios_facts:
gather_subset:
- interfaces
- routing
- name: Configure interface if in wrong state
cisco.ios.ios_config:
...
when: ansible_net_interfaces.GigabitEthernet0/0.operstatus != 'up'
Question 5: What is the 'ansible.netcommon.cli_parse' module used for in network automation?
- It parses raw CLI output from network devices into structured data using templates (TextFSM, TTP, or NTC templates) (Correct answer)
- It validates CLI command syntax before sending to devices
- It converts Ansible playbooks to vendor-specific CLI scripts
- It parses YANG models from NETCONF devices
Correct answer: It parses raw CLI output from network devices into structured data using templates (TextFSM, TTP, or NTC templates)
'cli_parse' transforms unstructured CLI text output into structured data (lists/dicts) using parsing frameworks like TextFSM or TTP.
cli_parse solves the text-parsing problem for network automation:
- name: Parse show ip bgp output
ansible.netcommon.cli_parse:
command: show ip bgp summary
parser:
name: ansible.netcommon.ntc_templates
set_fact: bgp_summary
- name: Show BGP neighbor count
debug:
msg: "BGP neighbors: {{ bgp_summary | length }}"
Parsing engines:
- TextFSM: State machine based, NTC Templates library has 1000+ templates
- TTP (Template Text Parser): Python-based, regex with YAML output
- PyATS/Genie: Cisco's parsing library with deep IOS/NX-OS support
- JSON: For devices that support JSON output natively
This bridges the gap between legacy CLI devices and structured automation.
Question 6: How does Ansible handle network device privilege escalation (enable mode on Cisco IOS)?
- Set 'ansible_become: true' and 'ansible_become_method: enable' in inventory; ansible_become_password holds the enable password (Correct answer)
- Use 'enable_mode: true' in the task definition
- Configure 'privilege_mode: enable' in ansible.cfg under [network]
- Network devices don't support privilege escalation in Ansible
Correct answer: Set 'ansible_become: true' and 'ansible_become_method: enable' in inventory; ansible_become_password holds the enable password
Network privilege escalation uses the 'become' system with 'become_method: enable', which sends the 'enable' command and password to enter privileged exec mode.
Cisco IOS privilege escalation in Ansible inventory:
[cisco:vars]
ansible_connection=network_cli
ansible_network_os=cisco.ios.ios
ansible_user=ansible
ansible_password=ssh_password
ansible_become=true
ansible_become_method=enable
ansible_become_password=enable_secret
Or per-task:
- name: Configure access list
cisco.ios.ios_config:
lines:
- ip access-list standard MGMT
- permit 10.0.0.0 0.0.0.255
become: true
become_method: enable
The 'enable' become method sends 'enable' then the password to enter privileged exec mode (IOS prompt changes from '>' to '#'). For NX-OS, use 'ansible_become_method: ansible.netcommon.enable'.
