Unlocking the Power of Network Automation: A Journey Into the Future of Networking

Photo by Christina @ wocintechchat.com on Unsplash

Hey there, fellow network enthusiast! I’m Menna Elsakaty, a fresh face in the world of networks, brimming with enthusiasm and a thirst for knowledge.

Recently bitten by the networking bug, I’m venturing into the intriguing world of network automation. As a newcomer to this dynamic field, I’m on a mission to unravel the mysteries of networks and dive headfirst into the exciting world of automation. Join me on this journey as I share my discoveries and insights into the basics of networks and the transformative power of automation. Whether you’re a fellow newbie or a seasoned pro, let’s embark on this adventure together and unlock the potential of network automation!

Internet connectivity has become ubiquitous in our daily lives and is now an essential utility like water and electricity. The complex infrastructure that drives the internet is created, built, run, and monitored by network operators, who work nonstop behind the scenes in this enormous digital landscape. Think of the horror that would accompany hearing the dreaded statement: “Hey, there is no Internet!” Suddenly, everything stops, emphasising how important network operators are to maintaining our world’s constant connectivity.

Automation is being used to simplify infrastructure by streamlining and centralising network management tasks, reducing the complexity of configurations, and enabling more consistent and standardised setups across devices. This approach provides greater control and adaptability to meet the increasing demands for reliable internet connections. Network operators are also using artificial intelligence (AI) and machine learning (ML) to automate repetitive processes, lower human error, and boost productivity. The trend toward automation guarantees not just faster problem-solving times but also more efficient operations, which adds up to a stronger and resilient internet infrastructure.

So, what are these network operators doing specifically? They perform tasks necessary to keep network infrastructure strong and secure. The fault, configuration, accounting, performance & security (FCAPS) model aims to provide a guide for developers and operators on how to manage a networked environment.

FCAPS, namely the International Organisation for Standardisation (ISO) Telecommunications Management Network (TMN) model and network management framework, was introduced at the International Telecommunications Union in 1977. It has been instrumental for nearly a decade in condensing and streamlining the core principles of Infrastructure Network Management. FCAPS encompasses Fault Management, Configuration Management, Accounting Management, Performance Management, and Security Management. More information can be found with link provided below in the references.

Figure 1. FCAPS Model

Today’s customers stream videos, play online games, use cloud storage, and chat and call on messaging and social media platforms without giving extra thought to how they connect to those services, they only give the network any thought when something goes wrong. Service providers must offer excellent end user experiences in addition to providing services as needed — a failure to meet these expectations is sorely noticed. However, customers’ requirements for instantaneous, high-quality services available on demand are not addressed by existing methods of configuring, monitoring, and addressing network issues that impact services.

Network Automation 101: An Introductory Overview

Enter network automation — the key to unlocking the full potential of modern networking. Automation revolutionises every aspect of network operations, from service deployment to troubleshooting. Let’s explore some of the key benefits and advancements in network automation:

Traditional ways:

• Before deploying router images into production, operators thoroughly test them. It was common practice to test new router software for months at a time before a new service was finally put into production. Automation may contribute to quicker deployment times. Application programming interfaces (APIs) in network devices should be fully and consistently instrumented to enable networking suppliers to automate everything.
• A CLI (Command-Line Interface) is no longer the standard. To begin with, many configuration changes linked to services involve numerous devices. For example, updating an access list and all Layer 3 VPN (L3VPN) endpoints, which are virtual private networks that operate at the third layer of the OSI model to provide isolated and secure communication over a shared infrastructure, would be necessary for a point-to-point L3VPN.

Let’s illustrate this with a more specific example. Let’s say a large online retailer’s website takes a while to load and that the cause is a load balancer that isn’t set up correctly. The network segment managing e-commerce transactions exhibits abnormally high latency and packet loss, which is detected by the automated monitoring system.

1. Alert Generation: The network operations centre (NOC) receives an instant alert from the system. >>Fault
2. Configuration Adjustment: Network administrators utilise the automated configuration management tool to make necessary configuration adjustments, then they send a revised configuration script to the load balancer. >>Configuration
3. Change Logging: The accounting system records information about the deployment, including the operator’s ID, the timestamp, and the modifications carried out. >>Accounting
4. Performance Testing: Post-deployment, the performance management tool runs tests to ensure the load balancer now distributes traffic evenly, reducing latency and packet loss. >>Performance
5. Security Check: After making a configuration change, the security management system checks for any new vulnerabilities. >>Security
6. Learning and Optimisation: The event is recorded so that machine learning algorithms can examine it and enhance defect identification and reaction times in the future.

This shift from conventional to more programmable networks demonstrate the effectiveness and durability that automation offers.

As network engineers, it’s crucial to adapt to these changes and embrace automation technologies. Scripting and automation skills are becoming increasingly valuable, enabling engineers to automate routine tasks and focus on strategic initiatives.

Consider this shift to be like picking up a new language. The conventional techniques and instruments that engineers have employed for years are changing, and it is now crucial to learn the “language” of automation. This new language encompasses technologies like Ansible, Puppet, and Chef, as well as programming languages like Python. Exploring how these tools and languages reshape network management will be the focus of the next blog.

Software Defined Networking:

Figure 2. SDN Model

The software-defined approach to networking demands a model that allows networks to be treated in a programmable way. Network elements, such as routers and Layer 3 instances, and the relationships between them — connectivity state and other parameters such as speed, physical connection types etc. — all have to be parameterised in a programmable way.

Emergence of Programmable Devices like WLCs and NFVs:

The following items highlight the significance and capabilities of emerging programmable devices in modern network infrastructure. These devices, such as Wireless LAN Controllers (WLCs) and Network Function Virtualisation (NFV), play a crucial role in enhancing network efficiency and automation.

1. WLCs, or wireless LAN controllers:

• Functionality: Within a wireless local area network (WLAN), several wireless access points (APs) are managed centrally by WLCs. They handle tasks like client management, security settings, and AP configuration.
• Programmability: The programmable nature of WLCs enables administrators to automate processes like policy enforcement, configuration updates, and AP installation.
• As an illustration, centralised management is used by Cisco Wireless LAN Controllers (WLCs) to guarantee uniform setup across all APs, improving security and streamlining network administration.

2. Network Function Virtualisation (NFV):

• Functionality: NFV substitutes virtualised network operations operating on common servers for conventional network appliances. This covers features like load balancers, firewalls, and WAN accelerators.
• Programmability: Through automation and orchestration, NFV platforms allow for the dynamic deployment and scalability of network functions. Virtual network functions (VNFs) can be provisioned and managed programmatically by administrators.
• As an illustration, the NFV platform VMware NSX-T enables administrators to automate deployment and management activities by offering programmable network and security services.

Relation to Software Defined Networking (SDN):

• Centralised Control: Both WLCs and NFVs align with the principles of SDN by providing centralised control over network resources.
• Programmable Interfaces: These devices offer programmable interfaces that enable administrators to define network configurations, manage relationships between network elements, and automate tasks.
• Dynamic Adjustment: Administrators can dynamically adjust network behaviour, optimise performance, and enhance security through programmable and automated management.

Consider a business network that includes both programmable and conventional equipment. Many Cisco APs are managed by a Cisco WLC, which also makes sure that all of the APs follow the same wireless configurations and security guidelines. In the meantime, load balancing and virtualised firewall operations are managed by an NFV platform, which automatically scales these services according to trends in network traffic.

In this case, network administrators can handle network elements programmatically thanks to the software-defined approach, which guarantees uniform configuration and network-wide performance improvement.

There are many vendors and open-source products that allow for this model to be adopted and provide pre-configured automation on top of it. However, before we dive into these offerings, let’s start with the basics: how should these network elements communicate with each other? The answer is protocols developed specifically for automated and programmable network configuration, such as NETCONF and RESTCONF — the two protocols that we shall briefly explore. But first, let us look at YANG, a modelling language that allows us to programmatically change the configuration. Moving from storing configuration in Word documents into a new programmable network language model.

Table(1) below shows differences in both protocols:

Table 1

YANG:

When SNMP’s shortcomings in configuration management were brought to the attention of the Internet Architecture Board (IAB), NETCONF and RESTCONF were born. There is standardisation for the NETCONF and RESTCONF protocols, but not for the data content. The outcome was the development of YANG, a superior modelling language that simplified and improved the understanding of the data model.

YANG is a comprehensive, formal contract language that offers rich semantics and syntax for developing applications. However, the transition from traditional CLI-based network configurations to YANG can be challenging, especially for legacy network users. It requires investment in training and tooling to support a smooth transition and maximise its advantages in network management.

Challenges in Transition:

• Paradigm Shift: YANG introduces a different approach — data modelling. Unlike CLI, which uses device-specific commands, YANG models network elements in a structured, hierarchical format.
• Learning Curve: Engineers accustomed to CLI may find learning YANG, NETCONF, or RESTCONF protocols and data modelling concepts challenging at first.

Tooling and Automation: While YANG enables automation and improves network management, adopting it often requires new tools and processes to interpret models and manage configurations effectively.

Benefits and Considerations:

• Human readable and easy to learn (Administrators who are already familiar with YAML (explained later in this article) may find learning YANG, a modelling language often used for network configuration, easier due to their similar structured formats).

• Hierarchical configuration data models
• Reusable types and groupings
• Data modularity through modules and sub-modules
• Well-defined versioning rules

Key Elements of YANG Data Modeling Language

In YANG, a module is the primary construct used to define a data model. The module serves as the foundational element, and it can import and reference data from other modules and submodules. The attributes of a module define various properties and metadata associated with it.

Module Attributes:

The following table lists the key attributes of a YANG module:

Table 2. Module Attributes

Node Types in YANG:

Beyond attributes, YANG modules define various node types that structure the data model. The following table outlines some of the key node types:

Table 3. Node Types

YANG is used to standardise the language for both NETCONF and RESTCONF, ensuring consistent and effective network management across these protocols.

YAML (YAML Ain’t Markup Language):

YAML is a human-readable data serialisation standard that is often used in conjunction with configuration files and applications where data needs to be easily readable by humans. While not directly related to YANG, it’s worth mentioning for its role in configuring applications and systems in a straightforward manner.

NETCONF:

NETCONF (Network Configuration Protocol) is a standardised network management protocol used for configuring, monitoring, and managing network devices. It operates on top of a secure transport protocol, typically SSH (Secure Shell) or TLS (Transport Layer Security) and employs XML-based data encoding for communication.

The key features of NETCONF include:

• Transactions: A transaction mechanism made available by NETCONF ensures that the configuration is applied accurately and completely.
• Dump and restore: Configuration data can be saved and restored using NETCONF. You can also carry out this action for a particular YANG module.
• Configuration handling: The ability to discriminate between activating and delivering configuration data is addressed by NETCONF.

For managing device configurations and retrieving device state information, the NETCONF protocol offers a range of low-level operations that can be called remote procedure calls (RPCs) from the client to the server.

Here are some common NETCONF Operations:

Table 4. NETCONF Operations

NETCONF: Security, Access Control, and Data Management Features

NETCONF typically runs over SSH (Secure Shell), providing strong encryption and secure authentication mechanisms to ensure the confidentiality, integrity, and authenticity of exchanged data.

• Access Control: NETCONF offers granular and flexible access control mechanisms.
• Data Models: NETCONF uses structured data models, such as YANG, to define configurations and operational states. This reduces misconfigurations and security issues arising from misunderstandings or human error.
• Error Handling and Transactions: NETCONF supports good error handling and atomic transactions, allowing configuration changes to be fully committed or rolled back, ensuring consistency and reducing security vulnerabilities.

RESTCONF:

RESTCONF implements the corresponding NETCONF procedures via HTTP methods, allowing for basic CRUD operations on a hierarchy of conceptual resources. CRUD stands for Create, Read, Update, and Delete, which are basic operations used to manage resources. In RESTCONF, CRUD operations correspond to HTTP methods (POST, GET, PUT/PATCH, DELETE) for managing network device configurations and states, each call in a separate transaction. Multiple calls together forming a transaction are not conceptualised in the RESTCONF protocol. There is no way to validate using RESTCONF without also activating a configuration. Nevertheless, implicit validation is a component of the RESTCONF calls, and their success or failure is determined per transaction.

RESTCONF is particularly useful for managing network devices through APIs and management portals, offering more capabilities than native device interfaces. For instance, a vendor might provide a RESTCONF API that allows network administrators to automate routine tasks such as device provisioning or configuration updates. By leveraging RESTCONF APIs, administrators can build custom automation scripts and integrate network management into broader IT workflows.

As a result, RESTCONF only supports device-by-device configuration, as opposed to network-wide transactions supported by NETCONF. Because there is only one orchestrator, RESTCONF is appropriate between a portal, and it is not appropriate from an orchestrator toward a network with several devices.

NETCONF (Network Configuration Protocol) and RESTCONF are modern network management protocols designed to offer better security and functionality compared to SNMP (Simple Network Management Protocol).

RESTCONF: Security, Access Control, and Data Management Features

RESTCONF runs over HTTPS (Hypertext Transfer Protocol Secure), similar to web applications, ensuring strong encryption and authentication for secure data exchange.

• Access Control: RESTCONF supports Role-Based Access Control (RBAC), allowing fine-grained permissions based on user roles.
• Data Models: Like NETCONF, RESTCONF uses YANG data models for structured representation and manipulation of configurations.
• Transaction Support: RESTCONF handles transactions as separate operations (POST, PUT, PATCH, DELETE), with implicit validation ensuring transactional success or failure.

Practical Examples

Imagine you’re developing a web application that needs to interact with network devices to retrieve configuration information or make changes dynamically. In this scenario, RESTCONF would be an ideal choice. Since RESTCONF leverages HTTP methods like GET, PUT, POST, and DELETE, it aligns perfectly with the web-centric nature of your application. You can use RESTCONF to send requests to network devices over HTTP, making it easy to integrate network management capabilities into your web application seamlessly. Ad-hoc programming, however, can eventually make these applications more difficult to operate, even while custom automation might offer a number of advantages. Scaling and maintaining custom scripts may demand more sophisticated knowledge and resources as your network expands and your application changes. It is imperative that you prepare for this complexity by carefully documenting your automation processes and taking into account reusable, modular code architectures. This strategy can lessen the difficulties associated with ongoing support and maintenance, guaranteeing the continued effectiveness and efficiency of your network administration.

In this scenario, while you technically could use NETCONF, it might not be the most practical choice. NETCONF is more suited for complex configuration management tasks in network infrastructure. It operates over a secure connection and uses XML to communicate with devices, offering features like transaction support and data modelling.

RESTCONF, on the other hand, also supports YANG data models but typically uses JSON (JavaScript Object Notation) encoding, which is more lightweight and commonly used in web applications. JSON is simpler and more concise than XML, making it easier to work with in modern web environments.

For instance, imagine a multinational corporation with offices across the globe. They rely on a vast network infrastructure to facilitate communication and data exchange between branches. With NETCONF, the network operations team can centrally manage the configurations of routers and switches deployed at each location. They can remotely adjust routing protocols, update access control lists, and monitor device performance in real time, all from a centralised management platform.

In summary, while NETCONF with XML and YANG is powerful for complex network configuration management, RESTCONF with JSON and YANG is more aligned with web application development and provides easier integration with modern IT workflows.

Conclusion

In conclusion, we’ve explored fundamental SDN principles through RESTCONF and NETCONF protocols, shedding light on the indispensable role of network automation in modern networking. YANG, as a key data modelling language, plays a crucial role in defining configurations and operational states, ensuring consistency and reducing errors. Organisations can greatly benefit from SDN by improving network agility, reducing operational costs, and enhancing security. Automated networks enable faster adaptation to changing conditions and more efficient threat response. Moreover, metrics to consider include reduced downtime, faster incident response times, and lower operational costs. Monitoring these can demonstrate the tangible benefits of network automation and its potential to transform network management.

However, this discussion merely scratches the surface of a vast pool of related topics waiting to be explored. As we dive deeper into the realm of network automation, we’ll uncover a wealth of techniques, tools, and best practices that promise to revolutionise the way we manage and optimise our networks. So, let this be just the beginning of an exciting journey into the intricacies of network automation!

Future Directions

In my next article, I will delve into automating popular off-the-shelf automation tools like Ansible, Puppet, and Chef. These tools offer powerful capabilities for configuration management, provisioning, and deployment automation across diverse network environments. Stay tuned as we explore how these tools can streamline operations and enhance network scalability.

References

1. YANG, NETCONF, RESTCONF: Semanticscholar. (n.d.). YANG, NETCONF, RESTCONF: Network programmability with YANG: the structure of network automation with YANG, NETCONF, RESTCONF, and gNMI. Available at: https://pdfs.semanticscholar.org/1e7e/bd7e5726a922047c5feb327f1f8e662d12b4.pdf

Note: This article speaks only to my personal views / experiences and is not published on behalf of Deloitte LLP and associated firms, and does not constitute professional or legal advice. All product names, logos, and brands are property of their respective owners. All company, product and service names used in this website are for identification purposes only. Use of these names, logos, and brands does not imply endorsement.