Two of my daughters are twins, and they’re active online, so they are arguably digital twins. However, this blog will not be about them.
TL;DR: Like other phrases that people can instantly relate to, the term “digital twins” is getting a fair amount of press lately. As happens in such cases, marketing latches onto the latest hot words, so there’s some drift in exactly what <substitute hot term here> means.
This blog will explore some of the different variants of (networking) digital twins. The usual networking answer applies: “it depends.”
What works for you as a network (or other) digital twin depends on your requirements and what you’re trying to do. So this is a case where the different meanings aren’t just the result of marketing trying to tie products into the hot term, but where there are varying degrees of digital twinnage.
Why Digital Twin?
Routing/switching technology has gotten complex, with “interesting” interactions sometimes causing problems. ACLs and security just add to that.
The basic idea is to be able to model your actual network in some fashion to validate proposed designs or changes to configurations. Preferably at much lower cost than with actual lab hardware.
NetCraftsmen has found modeling/lab work useful recently with some customers, determining exactly why what the customer implemented has some issues, and/or for testing changes before deploying them.
Base Case
The obvious variant of “digital twin” is where you build a test lab using real equipment that resembles some key part(s) of your network. That’s the costly but high-fidelity approach.
If your network is critical enough, e.g. life/health critical, having a real lab might be a good idea. Backing it up with larger modeling capability might also be useful.
Prior Blog: Virtual Labs
The tools discussed in my LinkedIn blog about Virtual Labs could be considered digital twins. The distinction made there was between fidelity in terms of control plane versus actually forwarding packets between virtual devices.
In particular, EVE-NG and CML-P use actual device images so should provide pretty good fidelity. Old code versions might be an issue. Scaling could be an issue but adding compute (cloud? budget?) and using the corporate version of CML might address that. In conjunction with EVE/containers, I’ll also note Ivan Pepelnjak and others’ work with netsim-tools.
Another tool that somewhat fits in here is batfish. While it isn’t a virtual lab per se (it is a “configuration analysis tool”), I’m told its modeling can do a lot of useful things with high accuracy – a weaker form of digital twinnage?
What’s Different with a Digital Twin?
So, what are some of the differentiating factors for network digital twins?
- Scale, limitations
- Protocol fidelity (vendor variations on standards, protocol stack behaviors).
- Passing packets vs. protocol layer only
- Load simulation, link failure or link conditions simulation
- Accuracy down to the level of vendor, hardware platform, line cards, and OS code version. (Probably WAY too much to hope for).
- (Other aspects I’m not thinking of right now)
What else might you want from a digital twin?
- Appropriate scaling: able to support sufficiently large models and product results reasonably quickly. And affordable cost.
- Automated lab stand-up: perhaps start with a single source of truth like NetBox, and have scripts build the model. Or start with discovery of part of the production network and automatically build the model, perhaps picking which devices to include or omit.
- Automatic copy of configurations to model.
- Capture of lab scenarios with automated restoration of connectivity and configuration snapshots.
- Synthetic automated connectivity and traffic testing between various points, with reporting of any connectivity problems.
- Diagram of topology, graphical access to model components.
- Ability to test automation scripts external to the model prior to use on production devices.
Concerning scaling, I’ll note that overly large models can be counter-productive, and just add cost and consume your time.
As a side note, some of the CCIE training classes strike me as going way over the top in that regard (“my lab is bigger than yours” syndrome?).
For example, it might make sense to model a core plus 2-3 sites, maybe omitting most or all site internal details if your focus is routing. If you’re modeling VXLAN, you probably would want a mini-fabric, say 2 spine, 2 leaf, but more spines and leaves is probably not going to add value. And so on.
The one place full scale might be helpful is if you need to model exact configuration changes, rather than trusting ability to correctly adjust device specific details as needed to scale up a design/change.
“Your mileage (of course) may vary.”
Ivan Pepelnjak recently posted a great blog that among other things, touches on the many ways in which a virtual device’s behavior will likely differ somewhat from what an actual physical device does.
Some Other Digital Twin Products
I’ll list and briefly discuss some products that either market themselves as digital twins or might be considered digital twins.
- Forward Networks: https://www.forwardnetworks.com. Forward Networks models network forwarding and access list enforcement. It allows you to validate access list and firewall rules, and helps solve “where did my flow get blocked.”
- My open question about Forward Networks is fidelity. What exactly do they model? They apparently collect device configuration and perhaps other information (routing tables?) They apparently do bulk flow testing against actual network devices, rather than modeling e.g. EIGRP or BGP routing per se. How accurate is that?
- My guess is it is probably fine for tracking flows. Can it predict the effects of routing protocol configuration changes? Or is the routing etc. forwarding more static?
- VeriFlow: VeriFlow was similar to Forward Networks but with a different approach to modeling device forwarding behavior. It was acquired by VMware and became a component of VRNI. It is apparently now being used for Network Assurance and Verification. I can’t quickly find further details, it has been fully subsumed into VRNI. It is not clear that modeling / digital twin functionality is present in VRNI, which appears to have more of a troubleshooting focus. https://www.vmware.com/products/vrealize-network-insight.html
- Nupsys: Nupsys appears to be first a network monitoring and visualization tool. However, it apparently couples with and drives Cisco’s CML for modeling. https://www.nupsys.com
Other
If you google search “digital twin,” it becomes apparent that digital twin is potentially huge for modeling manufacturing, IOT, and processes. That is out of the scope of this blog. I’ll include one entry to give you the flavor of the non-network digital twinning:
- “Azure Digital Twins is an Internet of Things (IoT) platform that enables you to create a digital representation of real-world things, places, business processes, and people. Gain insights that help you drive better products, optimize operations and costs, and create breakthrough customer experiences.” https://azure.microsoft.com/en-us/services/digital-twins/
Conclusions
If your employer is moderate to large in size, you need a digital twin solution (and time to use it). The cost-justification case to management is being pro-active and validating changes before making them.
A digital twin lab solution could be useful for multiple people to model changes or new buildouts. A physical lab might then be used to validate changes do not encounter hardware quirks or bugs, prior to actual deployment. There’s a cost versus need trade-off lurking there.
If your employer is a consulting/services organization, having the ability to model in a digital twin might be very useful. Customers would have to authorize the cost of consultants doing modeling, etc. Recovering the lab/digital twin hosting costs might also be a consideration.