Skip to content
My Docs

Network Automation And Programmability

Category: Advanced Networking Concepts
Type: Network Concepts
Generated on: 2025-07-10 09:12:13
For: Network Engineering, Administration & Technical Interviews

Network Automation and Programmability Cheatsheet

Section titled “Network Automation and Programmability Cheatsheet”

What is it?

Network automation and programmability refer to the use of software tools, scripts, and APIs to automate network management tasks, configure devices, monitor network performance, and respond to network events dynamically. It shifts network management from manual CLI-based configuration to software-defined processes.

Why is it important?

  • Increased Efficiency: Automates repetitive tasks, freeing up engineers for more strategic initiatives.

  • Reduced Errors: Minimizes human error in configuration and deployment.

  • Faster Deployment: Speeds up the provisioning and deployment of network services.

  • Improved Scalability: Enables networks to scale quickly and efficiently.

  • Enhanced Agility: Allows networks to adapt dynamically to changing business needs.

  • Centralized Management: Provides a single pane of glass for managing the entire network.

  • Cost Reduction: Lowers operational expenses (OpEx) by automating tasks and reducing downtime.

  • Automation: The process of performing tasks automatically, without human intervention.

  • Programmability: The ability to control and configure network devices and services using software.

  • Infrastructure as Code (IaC): Managing and provisioning infrastructure through code rather than manual processes.

  • Software-Defined Networking (SDN): A network architecture that separates the control plane from the data plane, allowing for centralized control and programmability.

  • Network Functions Virtualization (NFV): Virtualizing network functions, such as firewalls and load balancers, allowing them to be deployed on commodity hardware.

  • APIs (Application Programming Interfaces): Interfaces that allow software applications to interact with network devices and services.

  • Ansible: An open-source automation engine that uses YAML playbooks to configure and manage network devices.

  • Puppet: A configuration management tool that uses a declarative language to define the desired state of network devices.

  • Chef: A configuration management tool that uses Ruby to define the desired state of network devices.

  • NAPALM (Network Automation and Programmability Abstraction Layer with Multivendor support): A Python library that provides a unified API for interacting with network devices from different vendors.

  • Netconf: A network configuration protocol based on XML that provides a secure and reliable way to configure network devices.

  • RESTCONF: A network configuration protocol based on HTTP and JSON that provides a simple and lightweight way to configure network devices.

  • gNMI (gRPC Network Management Interface): A high-performance, streaming telemetry protocol for monitoring network devices.

  • Telemetry: The process of collecting and analyzing network data to monitor network performance and identify potential problems.

  • Intent-Based Networking (IBN): A network management approach that focuses on defining the desired network behavior (the “intent”) rather than configuring individual devices.

  • Orchestration: The process of automating the deployment and management of network services across multiple devices and platforms.

  • Idempotency: The property of an operation that can be executed multiple times without changing the result beyond the initial application. Important for robust automation.

Here’s a simplified workflow for network automation using Ansible:

+---------------------+     +---------------------+     +---------------------+
| Ansible Control Node| --> | Network Device(s)   | --> | Network Device(s)   |
| (Playbooks, Modules)|     | (Target Devices)     |     | (Desired State Achieved)|
+---------------------+     +---------------------+     +---------------------+
        | SSH/Netconf       |     |                  |     |                  |
        +-------------------->     +-------------------->     +-------------------->
                                   | Agentless         |     |                  |
                                   +-------------------->     +-------------------->

Steps:

  1. Define the desired state: Create an Ansible playbook in YAML that specifies the desired configuration for the network device(s).
  2. Connect to the network device: Ansible uses SSH or Netconf to connect to the target network device(s). No agent needs to be installed.
  3. Execute the playbook: Ansible executes the playbook, sending commands to the network device(s) to configure them according to the desired state. Ansible modules are used to interact with different device types.
  4. Verify the configuration: Ansible verifies that the configuration has been applied correctly.
  5. Report the results: Ansible reports the results of the automation process, including any errors or warnings.

Example using NAPALM (Python):

from napalm import get_network_driver


driver = get_network_driver('ios')
device = driver('192.168.1.1', 'username', 'password')
device.open()


interfaces = device.get_interfaces()
print(interfaces)


device.close()

This section focuses on the key automation-related protocols.

4.1 NETCONF

Section titled “4.1 NETCONF”
  • Purpose: A protocol for managing network devices, offering configuration, state retrieval, and event notifications.
  • Transport: Typically SSH.
  • Data Encoding: XML.
  • Architecture: Client-server (Manager - Agent)
  • Key Features: Transactions, rollback, validation.

Simplified NETCONF Message Flow:

+----------+      +----------+
| Manager  |      |  Agent   |
+----------+      +----------+
    |            |      |
    | <hello>    |----->|
    |            |      |
    | <hello>    |<-----|
    |            |      |
    | <edit-config>|----->|  (Configuration Data)
    |            |      |
    | <ok>       |<-----|  (Confirmation)
    |            |      |
    | <get>      |----->|  (Request State Data)
    |            |      |
    | <rpc-reply>|<-----|  (State Data)
    |            |      |
    | <close-session>|-->|
    |            |      |
    | <ok>       |<-----|
    |            |      |
+----------+      +----------+

4.2 RESTCONF

Section titled “4.2 RESTCONF”
  • Purpose: Similar to NETCONF, but uses RESTful principles.
  • Transport: HTTP/HTTPS.
  • Data Encoding: JSON or XML.
  • Architecture: Client-server (REST Client - REST Server)
  • Key Features: Simplicity, leverages existing HTTP infrastructure.

Simplified RESTCONF Message Flow:

+------------+      +------------+
| REST Client|      | REST Server|
+------------+      +------------+
    |            |      |
    |  GET /restconf/data/interfaces  |----->|  (Request Interface Data)
    |            |      |
    |  200 OK (JSON data)    |<-----|  (Interface Data)
    |            |      |
    |  PUT /restconf/data/interfaces/interface=GigabitEthernet1/enabled  |----->| (Update Interface State)
    |            |      |
    |  204 No Content   |<-----|  (Confirmation)
    |            |      |
+------------+      +------------+

4.3 gNMI

Section titled “4.3 gNMI”
  • Purpose: A high-performance streaming telemetry interface.
  • Transport: gRPC (based on HTTP/2).
  • Data Encoding: Protocol Buffers (protobuf).
  • Architecture: Client-server (gNMI Client - gNMI Server)
  • Key Features: Streaming telemetry, push-based data delivery, efficient encoding.

Simplified gNMI Message Flow:

+------------+      +------------+
| gNMI Client|      | gNMI Server|
+------------+      +------------+
    |            |      |
    | SubscribeRequest  |----->|  (Request Telemetry Stream)
    |            |      |
    | SubscribeResponse (Stream Starts)  |<-----|
    |            |      |
    |  (Telemetry Data Stream)  |<----->| (Continuous Updates)
    |            |      |
    | SubscribeRequest (Cancel)  |----->|  (Stop Stream)
    |            |      |
    | SubscribeResponse (Stream Ends)  |<-----|
    |            |      |
+------------+      +------------+
  • Automated VLAN Creation: Using Ansible to create VLANs across multiple switches based on a spreadsheet of requirements.
  • Configuration Backup: Scheduling regular backups of network device configurations using a script and TFTP/SCP.
  • Automated Incident Response: Using a monitoring system (e.g., Nagios, Zabbix) and an automation tool (e.g., Ansible) to automatically remediate common network issues, such as restarting a service or disabling a port.
  • Zero-Touch Provisioning (ZTP): Automatically configuring new network devices as they are added to the network.
  • Network Validation: Using automated tests to verify that network changes have been implemented correctly and that the network is functioning as expected.
  • Automated Security Patching: Using Ansible or other automation tools to apply security patches to network devices in a timely manner.

Example: Automated VLAN Creation (Ansible):

---
- hosts: switches
  gather_facts: false
  tasks:
    - name: Create VLAN 100
      ios_config:
        lines:
          - vlan 100
          - name DATA
        parents: vlan database
  • Network Device Compatibility: Different network devices may have different APIs and configuration formats. NAPALM and Ansible modules help abstract this, but issues can still arise.
    • Solution: Thorough testing with different device types. Use NAPALM’s get_facts module to determine device capabilities.
  • Authentication and Authorization: Securing access to network devices is crucial.
    • Solution: Use SSH keys, strong passwords, and access control lists (ACLs). Consider using a centralized authentication system like RADIUS or TACACS+.
  • Error Handling: Automation scripts should be able to handle errors gracefully and provide informative error messages.
    • Solution: Implement error handling in your scripts. Use try...except blocks in Python or rescue blocks in Ansible.
  • Idempotency: Ensure that your automation scripts are idempotent, meaning that they can be run multiple times without causing unintended changes.
    • Solution: Use conditional statements and idempotency checks in your scripts.
  • Version Control: Track changes to your automation scripts using a version control system like Git.
    • Solution: Use Git for version control. Create branches for new features and bug fixes.
  • Security Vulnerabilities: Automation scripts can introduce security vulnerabilities if they are not written carefully.
    • Solution: Follow secure coding practices. Regularly review your scripts for potential vulnerabilities. Use static code analysis tools.
  • Lack of Standardization: Different teams may use different automation tools and approaches, leading to inconsistency and complexity.
    • Solution: Establish standards for network automation within your organization. Choose a common set of tools and best practices.

Cisco IOS-XE Configuration (using Ansible):

---
- hosts: cisco_devices
  gather_facts: false


  tasks:
    - name: Configure hostname
      ios_hostname:
        hostname: "{{ inventory_hostname }}"


    - name: Configure NTP server
      ios_ntp:
        server: 192.168.1.10
        source_interface: GigabitEthernet1


    - name: Configure banner
      ios_banner:
        banner: motd
        text: |
          ************************************************
          * Unauthorized access is prohibited!          *
          ************************************************

Juniper Junos Configuration (using Ansible):

---
- hosts: juniper_devices
  gather_facts: false


  tasks:
    - name: Configure hostname
      junos_hostname:
        hostname: "{{ inventory_hostname }}"


    - name: Configure NTP server
      junos_ntp:
        servers:
          - 192.168.1.10
        source_address: 192.168.1.1

Example using NAPALM to get network facts:

from napalm import get_network_driver


driver = get_network_driver('ios')
device = driver('192.168.1.1', 'username', 'password')
device.open()


facts = device.get_facts()
print(facts)


device.close()
  • What is network automation and why is it important? (Refer to the overview)
  • What are some of the key benefits of network automation? (Refer to the overview)
  • What are some common tools used for network automation? (Ansible, Puppet, Chef, NAPALM, Python)
  • Explain the difference between SDN and NFV. (SDN separates control and data plane, NFV virtualizes network functions)
  • What is Infrastructure as Code (IaC)? (Managing infrastructure through code)
  • What is Ansible and how does it work? (Refer to the ‘How It Works’ section)
  • What is a playbook in Ansible? (A YAML file that defines the desired state of a system)
  • What is an Ansible module? (A reusable piece of code that performs a specific task)
  • What is idempotency and why is it important in network automation? (Refer to the ‘Key Concepts’ and ‘Common Issues’ sections)
  • Explain the difference between NETCONF and RESTCONF. (NETCONF uses XML, RESTCONF uses JSON/XML and HTTP)
  • What is gNMI and how is it used? (High-performance telemetry interface using gRPC)
  • How would you automate the creation of VLANs across multiple switches? (Use Ansible, Python, or other automation tools to configure the switches)
  • How would you troubleshoot a network automation script that is failing? (Check logs, verify connectivity, test individual commands)
  • What are some security considerations when implementing network automation? (Authentication, authorization, secure coding practices)
  • How do you handle different vendor devices within your automation framework? (NAPALM, Ansible modules, conditional logic)
  • Explain the concept of Intent-Based Networking (IBN). (Defines desired network behavior instead of configuring individual devices)
  • Describe a time you used network automation to solve a real-world problem. (Provide a specific example with details on the problem, solution, and results)

Example Answer (Elaborated):

Question: Explain the difference between NETCONF and RESTCONF.

Answer: Both NETCONF and RESTCONF are protocols used for configuring network devices. However, they differ in their underlying technology and approach.

  • NETCONF: Uses XML for data encoding and typically relies on SSH for transport. It’s a more mature protocol with strong support for transactions and rollback, making it suitable for complex configuration changes. The architecture is client-server.

  • RESTCONF: Uses HTTP/HTTPS for transport and JSON or XML for data encoding. It’s based on RESTful principles, making it simpler and easier to integrate with existing HTTP-based tools and systems. The architecture is also client-server.

The key difference lies in their complexity and integration capabilities. RESTCONF is generally considered easier to learn and implement due to its reliance on standard HTTP methods and JSON/XML data formats. NETCONF, while more complex, offers more robust features for managing complex network configurations. The choice between the two depends on the specific requirements of the network environment and the level of control needed.

  • DevOps: A software development methodology that emphasizes collaboration between development and operations teams.
  • Continuous Integration/Continuous Deployment (CI/CD): A software development practice that automates the process of building, testing, and deploying software.
  • Network Monitoring: The process of monitoring network performance and identifying potential problems.
  • Security Automation: Automating security tasks, such as vulnerability scanning and incident response.
  • Cloud Computing: Delivering computing services over the internet.
  • Edge Computing: Processing data closer to the edge of the network.
  • Big Data Analytics: Analyzing large datasets to gain insights into network performance and behavior.

Further Reading:

This comprehensive cheatsheet provides a solid foundation for understanding and implementing network automation and programmability. Remember to practice with the tools and techniques described here to gain hands-on experience and deepen your knowledge.