What is Digital Twin for Network Automation

As more and more of the infrastructure becomes virtualized and the gradual shift from conventional methods to CI/CD and DevOps mindset in the field of network engineering and automation is adopted, it is going to become an absolute necessity to have digital twins of the live networks.

What is Digital Twin for Network Automation?

Digital twins are virtual replicas of the live networks that network engineers can use to run simulations before actual implementations are done on the live networks. The end goal is to make sure the current state of the live network is replicated by this test network at all times so that any testing you do is done on the most updated version of the live network.

While the concept of Digital Twins can be applied to any industry but we will keep our discussion limited to networking.

Since the live network, these days are also becoming more and more virtualized, it’s relatively easier to set up a Digital twin of the live network. To explain the core advantage and relevance of the twin networks, let’s assume we are doing any and every change to the live network through scripts and APIs. I don’t think there is any need to explain how this setup would have been leverage working the conventional way because that’s what we have been doing to date.

Let’s take an example that we need to make a change to the existing OSPF configuration of the live network. We want to add a new network to the advertisements, maybe added a new LAN subnet. Let’s see the workflow

COMPONENT 1 ( Jinja templates )

All of the network configurations are now stored in a version-controlled repository like GIT. The provider for GIT could be locally hosted GITLAB solutions or GITHUB or bitbucket.

# template.j2 - Jinja2 template

hostname {{ hostname }}

no ip domain lookup
ip domain name cisco.com
ip name-server {{ primary_ns }}
ip name-server {{ secondary_ns }}

ntp server {{ primary_ntp }} prefer
ntp server {{ secondary_ntp }}

COMPONENT 2 ( YAML VARIABLE FILES ). This could be YAML, a python dictionary, or any other structured data

---
hostname: dc-rtr-01
name_server_pri: 4.2.2.2
name_server_sec: 8.8.8.8
ntp_server_pri: ntp1.abc.com
ntp_server_sec: ntp2.abc.com

COMPONENT 3 – A framework that can read the template and variables and produce the desired output. In most cases, it’s going to be python.

import yaml
from jinja2 import Template

#read your yaml file
with open("variables.yaml") as file:
    variables = yaml.safe_load(file)

#read your jinja template file
with open("template.j2") as file:
    template = Template(file.read())

#use jinja to render your configuration
template.render(variables)



##### OUTPUT #######
hostname dc-rtr-01

no ip domain lookup
ip domain name cisco.com
ip name-server 4.2.2.2
ip name-server 8.8.8.8

ntp server ntp1.abc.com prefer
ntp server ntp2.abc.com

Jinja2 templates, variables, python script are stored in a repository

If you see closely, all these are part of the main branch. Now imagine if we need to update the NTP servers across multiple devices. A network engineer can now propose the change in the current configuration by using below process

A simplified view of the CI/CD workflow for network engineers

1. Fork the git repository, propose the changes and submit a Pull Request which can be approved by the network architect. For the sake of simplicity, let’s assume all the proposal can be done under another branch called testing

1. The network engineer who wants to make a proposal will git clone the repository
2. checkout to the testing branch
3. edit the yaml file to reflect the new servers.
4. push the changes to the remote repository.
5. The moment a CI/CD pipeline detects the change in testing repository, it will trigger a workflow which will involve a tool like Jenkins to
   • pull down any modifications to the files to the automation server.
   • create the required configuration using python scripts
   • Trigger the next script to send configuration to the devices in the test lab or digital twin.
   • Examine the outputs of the push and validate if the result is a SUCCESS or not.
   • If the result is a SUCCESS ( the success parameters are defined inside Jenkins ), it can move to next step.
6. submit a Pull request which will trigger an email to approval who is probably the network architect.
7. He will review the proposal and if he deems everything to be acceptable, he will merge the network engineers pull request into the main branch.
8. As soon as a a change is detected in the main branch by the Github CI/CD or any other CI/CD tools like Jenkins, The entire process like above is repeated now for the live network
   • pull down any modifications to the files to the automation server.
   • create the required configuration using python scripts
   • Trigger the next script to send configuration to the devices in the test lab or digital twin.
   • Examine the outputs of the push and validate if the result is a SUCCESS or not.

I understand this topic deems a greater insight into:-

1. How to leverage CI/CD for network engineers.
2. How to integrate Jenkins, Github using a real detailed example.
3. An example of python script that can take the variables demo the push to config in test and real network.

All these I will cover in the follow-up versions of this topic. If you have any more suggestions/requirements related to this topic. Please let me know and I will try to include them in the next post.

To bring more context, this article on DevOps for network engineers will give more insight.