In previous articles, we have discussed the network automation journey, and we have explained what a Source of Truth / Source of Intent is and why it is needed. In this article, we focus on the concept of a Digital Twin.
Before we dive into the realm of Digital Twins, we need to take a look at how network or infrastructure operators work when it comes to new equipment, software, or services.
A standard approach is to have a lab which, to some extent, resembles what is in the production network. The lab is built based on physical equipment, some virtualized appliances, and quite often, network simulators or testers. What type of network equipment is used in the lab is dependent on what is used in the production network, and the types of simulator or tester depend on the tests that need to be performed. A lot of readers are probably familiar with commercial network testers like IXIA (now Keysight) or Spirent or with open-source options like TRex. These testers are used to check different aspects of network solutions, including performance, scalability, and reliability. Some of them are also capable of simulating some external nodes, at least from the point of view of the control plane of the tested device.
However, while such solutions are suitable for testing specific functionalities on specific equipment (or a virtualized appliance), the test is usually done out of the context of the whole network. But what if we want to see how a new service or solution will behave in the network? It seems unreasonable to test it in production.
For such a situation, a Digital Twin comes in handy.
What is a Digital Twin and what is its purpose?
The idea (and practice) of testing the changes that are to be performed on a production network or infrastructure is not a new one. Tests are done even for such specific entities as a new line card in modular network equipment or a single patch for a network OS, not to mention new services. These tests were traditionally performed in laboratories; safe environments modeled on the network. But building a physical reproduction of a network has its limitations:
- cost - the equipment is quite expensive to buy and to operate),
- number of elements - it is not possible to have a lab with thousands of nodes to reflect a real network),
- limited possibility of concurrent usage.
So, if one wants to mirror a production network (or a significant part of it), having a physical lab does not solve that problem.
What can help though is a modeled network reflected as virtualized or containerized entities. There are solutions that were designed for this purpose, and they are already commonly used, for example, the open-source GNS3, EVE NG, or Containerlab, or commercial options like Cisco Modeling Labs, which models a network in the form of virtual entities - all to a different extent and in different numbers.
This list is not exhaustive. For readers interested in comparing various modeling solutions, we encourage them to explore our blog post on the virtual labs topic.
What we can and cannot check with a Digital Twin
So, what can we use a Digital Twin for?
First of all, we can build a virtualized model of our network. This is a reasonable approach - we can have a model, quite often running on our own laptop, where we can have full and exclusive control. The number of elements simulated varies, of course, and that depends on the modeling technology and equipment used. But in the end, the model will always be more flexible and almost always will have more nodes than a physical lab.
Using this modeled network, we can see it as a whole, we can watch the interaction between network elements, and certify the impact that changes have on it. But does it mean that a Digital Twin is a remedy for all our testing and design problems, and we can check everything using this approach? No, unfortunately, that is not the case.
If we look closely at the concept of a Digital Twin (and network modeling in the form of virtual environments), we see that what is really well reflected from a physical device is the control plane and management plane.
The data plane is usually simplified and cannot match the real physical device. There are some exceptions, such as Juniper vMX or vSRX, which attempts to also emulate PFE chipsets (however, its behavior, although complete, might be different from the behavior of real HW). In reality, this is to be expected: the data plane’s role is to forward traffic for carrier-grade devices, those are TBs of data, and there are dedicated ASICs responsible for that.
To read about the difference between these planes, take a look at Management vs. Control vs. Data Planes in a Network Device.
On the other hand, management and control planes run as software on a standard CPU that is not vendor-specific, so it is easy to move it to a virtual machine or a container (if they are not in such a form already). An interesting example is SONiC (Software for Open Networking in the Cloud), an open-source network operating system. It supports various hardware platforms from supported vendors with different data plane solutions, but it offers unified management and control planes (the same set of supported routing protocols or the same way of configuring). SONiC is also available as a virtual machine, making it effortlessly adaptable for use in Digital Twin models. In this context, its control and management plane mirror the behavior of real (supported) hardware, though the data plane differs.
What can we check using a Digital Twin?
We can check elements that concern the control plane - the protocols, the architecture, and the correctness of the configuration. Let’s remember that data plane connectivity is still there - just in a simplified form - so the virtual entities can talk to each other and exchange information. The same tends to be true for the management plane - if all the ways of managing a physical device, like an API or even a simple SSH connection, are valid for the modeled entity, an operator can talk with it the same way they would with a physical device. So, two out of three planes are well reflected, but what about the last one, the data plane? Well, as mentioned above, this is not the case, at least not for a modeled physical device, as it is built in a form of dedicated hardware, which, by its nature, is not virtual.
With that in mind, what can we verify using a Digital Twin? Of course, we can check a lot that is related to control plane setup: protocols can be modeled, their data exchange, end-to-end services can be simulated. We can also check the route traffic will take to verify our setup. We can also easily check the correctness of the configuration and the way of applying it on virtual devices. What one cannot do, as mentioned before, is check things related to hardware-based traffic forwarding like forwarding performance (in fact, we can, it just won’t make any sense), QoS, or ACL.
Digital Twins and network automation
Now, let’s explore another way a Digital Twin can be of help: network automation.
When one starts with network automation, usually in the form of scripts dedicated to performing specific tasks, the question arises: how to test if the script does what it should. If one is lucky enough to have a lab environment, and there is a device that we need the test to be run on (or a similar one, with the same network OS, for example), and it is not being used at the moment, then we can check the developed script on that device. But even if the lab is available and includes the necessary device, it is still not enough if one wants to check automation at scale.
The big advantage of using automation is that it can speed up applying changes at scale thanks to parallelizing the work. In such cases, at least two aspects of the automation script must be checked:
- Whether we are passing the correct values to the variables (the script must use values for variables for different network entities).
- Whether we are actioning the changes in the correct order (so we do not cause service interruptions or they are kept within their intended impact).
With a physical lab, due to the impossibility of recreating a big network, such verification would not be possible. With a Digital Twin approach, this can be done easily and accurately.
The cherry on top is that by combining this with techniques like GitOps (GitOps in network automation explained) and incorporating CI (Continuous Integration) we can automate tests for the proposed changes. This ensures accurate checks and verification before rolling out the changes to the production network.
Summary
This article presents the concept of the Digital Twin - what it is, how we can use it (including as an alternative to a physical lab), and examples of solutions that can serve that purpose. We have also shown the advantages of having a Digital Twin when working with network automation.
We encourage you to take a look at the available solutions. For more information on their properties, you can see the above-mentioned article on virtual labs comparing different solutions.
