Topology simulation with EDA Digital Twin#

One of the powerful features of Nokia EDA is its Digital Twin - a horizontally scalable, virtual environment with a complete replica of the production network.

It is useful for the whole network lifecycle, from day 0 to day 2+ operations. You can safely experiment with, design, develop and validate your network - all without touching production hardware. Safe, fast, and reliable.

In this exercise you are going to solve a challenge that every data center network engineer faces: how to create a virtual twin of a DC fabric and evolve it as requirements in our datacenter change.

1. Objective#

In this activity you will:

• Learn what the EDA Digital Twin is.
• Understand how EDA represents a network topology.
• Deploy a simulated topology using the NetworkTopology workflow.
• Graphically build a topology using the TopoBuilder tool.
• Use TestMan to verify connectivity in the virtualized fabric.

2. Technology explanation#

2.1 The Digital Twin#

EDA's Digital Twin is a unique network virtualization platform that leverages the Kubernetes platform that EDA itself runs on.

Running the digital twin on Kubernetes allows EDA to scale to meet the high node counts of real production network topologies.

Naturally as with Kubernetes, EDA uses the containerized network simulator images for both Nokia SR Linux and Nokia SR OS.
These both behave like the real hardware from a configuration perspective, which will help in configuration validation and change management.

2.2 EDA Resource refresher#

The cornerstone of EDA ethos is its declarative nature to configure the network. Under the hood this is underpinned by the use of Resources - the intent captured in the declarative format that EDA knows how to consume.

EDA represents many things via these resources such as BGP peers, static routes, QoS policies, Filters, Virtual Networks, etc.

Same is true for defining the network topology and its components. There are many resources which make up the topology, and these are important to know and understand.

2.3 What makes up an EDA topology?#

A topology in itself is a collection of links and nodes. In EDA we have three main resources for this:

• TopoNode -Represents a node in the topology (for example: A switch, or a router)
• TopoLink - Represents a link. A connection between two nodes in the topology
• Interface - Represents an interface on a node in the topology

We also have counterpart resources for the virtual digital twin (or sim) domain. These are:

• SimNode - Represents a TopoNode in the Digital Twin domain
• SimLink - Represents a TopoLink in the Digital Twin domain

The EDA instances you are using have the default Try EDA topology already running in the eda namespace. You can inspect the cluster resources to find the following topology resources representing this two leaf, one spine topology:

edactl -n eda get TopoNodes #(1)!

1. This command uses edactl CLI tool to query the EDA cluster for all TopoNode resources.

NAME     PLATFORM       VERSION   OS    ONBOARDED   MODE     NPP         NODE
leaf1    7220 IXR-D3L   26.3.1    srl   true        normal   Connected   Synced
leaf2    7220 IXR-D3L   26.3.1    srl   true        normal   Connected   Synced
spine1   7220 IXR-D5    26.3.1    srl   true        normal   Connected   Synced

We can also take a look and see that the SimNode resources are there for the nodes as well, which indicates the digital twin is in use.

Also notice the testman-default SimNode. We will touch on this later in the TestMan section.

edactl -n eda get SimNodes

NAME
leaf1
leaf2
spine1
testman-default

2.3.1 What the resources actually look like#

What we saw just above was a list of all the topology resources in the cluster. What actually is in the resource itself?

Let's zoom in and take a closer look at the information defined in these custom resources.

edactl -n eda get toponode leaf1 -o yaml

apiVersion: core.eda.nokia.com/v1
kind: TopoNode
metadata:
  labels:
    eda.nokia.com/role: leaf # (1)!
    eda.nokia.com/security-profile: managed
  name: leaf1
  namespace: eda
spec:
  nodeProfile: srlinux-ghcr-26.3.1
  npp:
    mode: normal
  onBoarded: true
  operatingSystem: srl # (2)!
  platform: 7220 IXR-D3L # (3)!
  productionAddress: {}
  version: 26.3.1 # (4)!

apiVersion: core.eda.nokia.com/v1
kind: TopoLink
metadata:
  labels:
    eda.nokia.com/role: interSwitch
  name: leaf1-spine1-1
  namespace: eda
spec:
  links:
  - local:
      interface: ethernet-1-1 # (1)!
      interfaceResource: leaf1-ethernet-1-1
      node: leaf1
    remote:
      interface: ethernet-1-1
      interfaceResource: spine1-ethernet-1-1
      node: spine1
    type: interSwitch
status:
  members:
  - interface: ethernet-1-1
    node: leaf1
    operationalState: Up # (2)!
  - interface: ethernet-1-1
    node: spine1
    operationalState: Up
  operationalState: up # (3)!

apiVersion: core.eda.nokia.com/v1
kind: SimNode
metadata:
  labels:
    eda.nokia.com/role: leaf
    eda.nokia.com/security-profile: managed
    eda.nokia.com/source: derived
  name: leaf1
  namespace: eda
spec:
  containerImage: ghcr.io/nokia/srlinux:26.3.1-410 # (1)!
  dhcp:
    preferredAddressFamily: IPv4
  gatewayAddress:
    ipv4: 192.168.1.1/16
  imagePullSecret: core # (2)!
  license: cx-srl-26-3-1-ghcr-license # (3)!
  operatingSystem: srl
  platform: 7220 IXR-D3L
  port: 57400
  productionAddress:
    ipv4: 192.168.0.2/16
  serialNumberPath: ""
  version: 26.3.1
  versionMatch: v26\.3\.1.*
  versionPath: .system.information.version

apiVersion: interfaces.eda.nokia.com/v1
kind: Interface
metadata:
  labels:
    eda.nokia.com/role: interSwitch
  name: leaf1-ethernet-1-1
  namespace: eda
spec:
  enabled: true
  encapType: "Null" # (1)!
  ethernet:
    stormControl: {}
  lldp: true # (2)!
  members:
  - enabled: true
    interface: ethernet-1-1
    lacpPortPriority: 32768
    node: leaf1
  type: Interface
status:
  enabled: true
  lastChange: "2026-05-04T04:53:57.800Z"
  members:
  - enabled: true
    interface: ethernet-1-1
    lastChange: "2026-05-04T04:53:57.800Z"
    neighbors:
    - interface: ethernet-1/1 # (3)!
      node: spine1
    node: leaf1
    nodeInterface: ethernet-1/1
    operationalState: Up
    speed: 100G # (4)!
  operationalState: Up
  speed: 100G

2.3.2 Edge and ISL Links#

When taking a look at the TopoLink resource, you may have noticed there was a link type field. Which was set to InterSwitch for our leaf1-spine1-1 TopoLink resource.

In EDA we have the following link types:

• Inter-Switch Links (ISL) - Connect fabric nodes to each other (ie. leaf <-> spine). These are the backbone of our fabric and always have a local and remote endpoint defined
• Edge links - Connect nodes to external devices. Typically workloads (compute, storage, firewalls etc). Edge links typically only have a local endpoint defined, since the remote device is outside EDA's management domain

2.4 Workflows in EDA#

Now we know what resources make up a topology, but in a typical fabric you could have a massive topology and making all these resources individually is super tedious and not practical. It would be much easier to define the abstracted topology composition and let some automation generate the underlying resources...

This is where EDA workflows come into play. Workflows are run-to-completion programs that power any non-event-driven automation in EDA.
Run a ping or traceroute - workflow. Upgrade an image on a node - workflow. Rotate a certificate - workflow again.

So it is natural to see the NetworkTopology workflow being used to enable an abstracted definition of your Topology as a single resource, and upon execution of the workflow all the underlying resources will be created automatically by EDA.

2.4.1 The NetworkTopology Workflow#

The NetworkTopology workflow is the declarative way to define and deploy your network with EDA. It combines node definitions, link definitions, simulation parameters, and has powerful templating features into a single resource. Thus making fabric creation easy.

Below is an example of the default 'Try EDA' 2 leaf, 1 spine topology.

# Copyright 2026 Nokia
# Licensed under the BSD 3-Clause License.
# SPDX-License-Identifier: BSD-3-Clause

apiVersion: topologies.eda.nokia.com/v1
kind: NetworkTopology
metadata:
  name: try-eda-topology-hackathon
  namespace: "" # fill in the namespace you are using
spec:
  operation: ReplaceAll
  nodeTemplates:
    - name: leaf
      labels:
        eda.nokia.com/role: leaf
        eda.nokia.com/security-profile: managed
      nodeProfile: srlinux-ghcr-26.3.1
      platform: 7220 IXR-D3L
    - name: spine
      labels:
        eda.nokia.com/role: spine
        eda.nokia.com/security-profile: managed
      nodeProfile: srlinux-ghcr-26.3.1
      platform: 7220 IXR-D5
  nodes:
    - name: leaf1
      template: leaf
      annotations:
        topobuilder.eda.labs/x: "100"
        topobuilder.eda.labs/y: "100"
    - name: leaf2
      template: leaf
      annotations:
        topobuilder.eda.labs/x: "285"
        topobuilder.eda.labs/y: "105"
    - name: spine1
      template: spine
      annotations:
        topobuilder.eda.labs/x: "195"
        topobuilder.eda.labs/y: "-60"
  linkTemplates:
    - name: isl
      type: InterSwitch
      speed: 25G
      encapType: "Null"
      labels:
        eda.nokia.com/role: interSwitch
    - name: edge
      type: Edge
      encapType: Dot1q
      labels:
        eda.nokia.com/role: edge
  links:
    ####################
    # ISLs
    ####################
    - name: leaf1-spine1-1
      template: isl
      endpoints:
        - local:
            node: leaf1
            interface: ethernet-1-1
          remote:
            node: spine1
            interface: ethernet-1-1
    - name: leaf1-spine1-2
      template: isl
      endpoints:
        - local:
            node: leaf1
            interface: ethernet-1-2
          remote:
            node: spine1
            interface: ethernet-1-2
    - name: leaf2-spine1-1
      template: isl
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-1
          remote:
            node: spine1
            interface: ethernet-1-3
    - name: leaf2-spine1-2
      template: isl
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-2
          remote:
            node: spine1
            interface: ethernet-1-4
    ####################
    # Edges
    ####################
    - name: leaf1-ethernet-1-3
      template: edge
      endpoints:
        - local:
            node: leaf1
            interface: ethernet-1-3
    - name: leaf1-ethernet-1-4
      template: edge
      endpoints:
        - local:
            node: leaf1
            interface: ethernet-1-4
    - name: leaf1-ethernet-1-5
      template: edge
      endpoints:
        - local:
            node: leaf1
            interface: ethernet-1-5
    - name: leaf1-ethernet-1-6
      template: edge
      endpoints:
        - local:
            node: leaf1
            interface: ethernet-1-6
    - name: leaf1-ethernet-1-7
      template: edge
      endpoints:
        - local:
            node: leaf1
            interface: ethernet-1-7
    - name: leaf1-ethernet-1-8
      template: edge
      endpoints:
        - local:
            node: leaf1
            interface: ethernet-1-8
    - name: leaf1-ethernet-1-9
      template: edge
      endpoints:
        - local:
            node: leaf1
            interface: ethernet-1-9
    - name: leaf1-e1011
      template: edge
      endpoints:
        - local:
            node: leaf1
            interface: ethernet-1-10
        - local:
            node: leaf1
            interface: ethernet-1-11
    - name: leaf2-ethernet-1-3
      template: edge
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-3
    - name: leaf2-ethernet-1-4
      template: edge
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-4
    - name: leaf2-ethernet-1-5
      template: edge
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-5
    - name: leaf2-ethernet-1-6
      template: edge
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-6
    - name: leaf2-ethernet-1-7
      template: edge
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-7
    - name: leaf2-ethernet-1-8
      template: edge
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-8
    - name: leaf2-ethernet-1-9
      template: edge
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-9
    - name: leaf2-e1011
      template: edge
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-10
        - local:
            node: leaf2
            interface: ethernet-1-11
    - name: leaf1-2-e1212
      template: edge
      endpoints:
        - local:
            node: leaf1
            interface: ethernet-1-12
        - local:
            node: leaf2
            interface: ethernet-1-12
  simulation:
    simNodeTemplates:
      - name: default
        type: TestMan
      - name: server
        type: Linux
        image: ghcr.io/srl-labs/network-multitool
    simNodes:
      - name: testman-default
        template: default
    topologies:
      - node: "*"
        interface: "*"
        simNode: testman-default

We can use the CRD browser to take a look at some key parts of the Workflow definition.

NetworkTopology CRD

There are some key sections to the Workflow.

• nodeTemplates - Reusable templates which define parameters for nodes in the topology are defined.
• linkTemplates - Same concept for links in the fabric. Reusable templates which define parameters for links in the topology are defined.
• nodes - Instances of nodes in the topology (logically this is a TopoNode)
• links - Instances of links in the topology (logically this is a TopoLink)
• simulation - Definition for simNodeTemplates and SimNode instances in the topology, for the simulation/Digital Twin domain.

You may notice the usage of templates. The NetworkTopology workflow is template driven so that parameters for a certain node type/role can be defined once and then applied to instances of nodes in the topology.

This reduces the 'bloat' in large topology files and makes it easier to change parameters on large sets of nodes/links in the topology.

2.4.2 NetworkTopology Workflow Structure#

2.4.2.1 Operations#

The operation field controls how EDA applies the workflow resources.

2.4.2.2 Node Templates#

The nodeTemplates section defines the templates, which are reusable sets of parameters which apply to the node instances in the topology.

The key fields are:

2.4.2.3 Link Templates#

The linkTemplates section defines the templates, which are reusable sets of parameters which apply to the link instances in the topology.

The key fields are:

3. Tasks#

3.1 Bootstrap the namespace#

The EDA instance you are using for this activity is shared across all groups, which means you need to scope your work to a specific namespace to avoid conflicts with other attendees going over the same activity.

EDA supports the notion of namespaces, which allow operators to scope their resources to a specific namespace, which in our case would be a "workspace" for your group. Make sure you check what group ID you have been assigned and execute the namespace creation command to create your unique namespace by replacing with your group number:

edactl namespace bootstrap create --from-namespace eda group<ID> #(1)!

1. Make sure to replace with your group number.

This command should create a namespace in EDA that you should be using for the rest of the activity. In the EDA UI go and select your freshly minted namespace:

3.2 Deploy the Try EDA topology#

First, we'll stand up our own Try EDA topology that consists of three nodes (2x leafs, 1x spine) using the NetworkTopology workflow.

1. Navigate to the workflows in EDA UI.
2. Create a new workflow execution of NetworkTopology.
3. Paste in the workflow YAML
4. Ensure that you fill in the namespace field in the YAML you pasted, as it is intentionally left blank.
5. Run it.

3.2.1 Verification#

In the homepage view you should start to see node and interface counts increasing and the nodes transitioning to the Synced state and the interfaces transitioning to the Up state.

Checking the topology view, we should see our nodes there.

3.2.2 Inspect the Deployed Resources#

Now let's verify that all the resources were created correctly.

Use edactl get -n group<ID> <resource> to list the topology and simulation resources.

Replace <resource> placeholder with the resource types we learned earlier.

We should find that they are all present in the cluster.

3.3 TopoBuilder#

The NetworkTopology workflow has simplified the topology creation in EDA, but we can take it a step further thanks to the community-driven TopoBuilder tool.

TopoBuilder is a WYSIWYG (What You See Is What You Get) topology editor and provides a GUI-driven flow to configure the parameters for the nodes/links used in the topology.

TopoBuilder can be found at topobuilder.x.eda.dev.

Below are some demos of basic operations.

3.4 Add a node to the network#

The fabric is live, but now requirements have changed and we need to grow the fabric to accommodate new workloads. Let's add a new leaf node.

1. Paste the Try EDA topology workflow into the TopoBuilder tool
2. Make sure to change the namespace field in the pasted YAML in the TopoBuilder UI to match your namespace, as by default it is empty
3. Use the TopoBuilder to insert a new leaf node using the canvas (right button click to add the node) and connect it to spine1.
4. Copy the YAML using the button in the toolbar.
5. Create a new workflow in your namespace and paste in the YAML you copied.
6. Run the workflow.

After deploying, we should see our new leaf node in the topology.

Verification

After successful deployment of the workflow, we should see our new node in EDA.

EDA UIedactl

Confirm the new node-1 appears and is onboarded.

Get TopoNodes

edactl -n eda get TopoNodes

NAME     PLATFORM       VERSION   OS    ONBOARDED   MODE     NPP         NODE
leaf1    7220 IXR-D3L   26.3.1   srl   true        normal   Connected   Synced
leaf2    7220 IXR-D3L   26.3.1   srl   true        normal   Connected   Synced
node-1   7220 IXR-D3L   26.3.1   srl   true        normal   Connected   Synced
spine1   7220 IXR-D5    26.3.1   srl   true        normal   Connected   Synced

3.5 Reconcile operation#

We just inserted a new node by using the ReplaceAll operation, this worked well but what it did under the hood is remove and redeploy the existing nodes just to introduce a single new node.

This doesn't really make sense as we didn't need to touch the other nodes in the topology.

This is where the Reconcile operation comes in handy. Our input workflow would become the desired state, and what we have is the current state.

With the Reconcile operation, EDA only makes the differential changes required to achieve the desired state.

3.5.1 Remove a node from the network#

Now we need to remove a switch; perhaps it's being decommissioned or simply no longer needed. Use the Reconcile operation to remove the node we just added.

With Reconcile, we define the desired end state of the topology as it should look without node-1.

apiVersion: topologies.eda.nokia.com/v1
kind: NetworkTopology
metadata:
  name: 46-add-node-topobuilder
spec:
-  operation: ReplaceAll
+  operation: Reconcile

  nodes:
    - name: leaf1
      template: leaf
    - name: leaf2
      template: leaf
    - name: spine1
      template: spine
-   - name: node-1
-     template: leaf

edactl -n eda get TopoNodes

NAME     PLATFORM       VERSION   OS    ONBOARDED   MODE     NPP         NODE
leaf1    7220 IXR-D3L   26.3.1    srl   true        normal   Connected   Synced
leaf2    7220 IXR-D3L   26.3.1    srl   true        normal   Connected   Synced
spine1   7220 IXR-D5    26.3.1    srl   true        normal   Connected   Synced

3.6 Configure LAGs and ESI-LAGs#

With the fabric taking shape, production workloads will need more bandwidth and redundancy. LAGs (Link Aggregation Groups) are a common solution, and EDA makes them easy to add declaratively.

In EDA there are two LAG types:

• Local LAG - A LAG created between a pair of two nodes.

• ESI-LAG - A LAG created between two or more devices in the fabric AND a single external device. Typically for multihoming workloads (such as storage or compute that should connect to many leaf nodes).

3.6.1 Local LAG#

In the NetworkTopology workflow, a local LAG is defined by specifying multiple endpoints that reference the same pair of nodes:

links:
  - name: local-lag-example
    template: isl
    endpoints:
      - local:
          node: leaf1
          interface: ethernet-1-10
        remote:
          node: spine1:
          interface: ethernet-1-5
      - local:
          node: leaf1
          interface: ethernet-1-11
        remote:
          node: spine1:
          interface: ethernet-1-6

Edge LAGs can be created by omitting the remote: portion from the endpoint.

links:
  - name: leaf1-e1011
    template: edge
    endpoints:
      - local:
          node: leaf1
          interface: ethernet-1-10
      - local:
          node: leaf1
          interface: ethernet-1-11

When EDA processes this definition, it creates a single Interface resource for the LAG interface with multiple members.

3.6.2 ESI-LAG#

Since the external device is outside EDA's management domain the ESI-LAGs are edge links. The key difference from a local LAG is that the endpoints reference different fabric nodes:

links:
  - name: esi-lag-example
    template: edge
    endpoints:
      - local:
          node: leaf1
          interface: ethernet-1-1
      - local:
          node: leaf2
          interface: ethernet-1-1

In the Digital Twin, we use the simNode to represent the external devices.

When defining the ESI-LAG in the Digital Twin, each defined endpoint includes the sim block with the corresponding simNode and interface for that particular endpoint:

links:
  - name: esi-lag-sim-example
    endpoints:
      - local:
          node: leaf1
          interface: ethernet-1-1
        sim:
          simNode: workload
          simNodeInterface: eth1
      - local:
          node: leaf2
          interface: ethernet-1-1
        sim:
          simNode: workload
          simNodeInterface: eth2
    template: edge

Notice that each endpoint is connected to the same SimNode (workload), however on different interfaces. This means the SimNode is dual-homed to both leaf1 and leaf2.

3.6.3 Create an ESI-LAG#

A new server needs redundant connectivity. Create an ESI-LAG that connects it to both node-1 and leaf2.

• Add a new SimNode to act as our server.
  • Set the simTemplate to server.
• Create the edge links from our node-1 and leaf-2 leaf nodes to the server.
• Convert the two links into the ESI-LAG.
• Verify that the ESI-LAG TopoLink resource was created.

edactl -n eda get TopoLinks

NAME                  OPERATIONAL STATE
leaf1-2-e1212         up
leaf1-e1011           up
leaf1-ethernet-1-3    up
leaf1-ethernet-1-4    up
leaf1-ethernet-1-5    up
leaf1-ethernet-1-6    up
leaf1-ethernet-1-7    up
leaf1-ethernet-1-8    up
leaf1-ethernet-1-9    up
leaf1-spine1-1        up
leaf1-spine1-2        up
leaf2-e1011           up
leaf2-ethernet-1-3    up
leaf2-ethernet-1-4    up
leaf2-ethernet-1-5    up
leaf2-ethernet-1-6    up
leaf2-ethernet-1-7    up
leaf2-ethernet-1-8    up
leaf2-ethernet-1-9    up
leaf2-spine1-1        up
leaf2-spine1-2        up
my-server-esi-lag-1   up

edactl get -n eda TopoLink my-server-esi-lag-1 -o yaml

apiVersion: core.eda.nokia.com/v1
kind: TopoLink
metadata:
  labels:
    eda.nokia.com/role: edge
  name: my-server-esi-lag-1
  namespace: eda
spec:
  links:
  - local:
      interface: ethernet-1-13
      interfaceResource: lag-my-server-esi-lag-1-local
      node: leaf2
    remote:
      interfaceResource: ""
      node: ""
    type: edge
  - local:
      interface: ethernet-1-13
      interfaceResource: lag-my-server-esi-lag-1-local
      node: leaf1
    remote:
      interfaceResource: ""
      node: ""
    type: edge
status:
  members:
  - interface: ethernet-1-13
    node: leaf2
    operationalState: Up
  - interface: ethernet-1-13
    node: leaf1
    operationalState: Up
  operationalState: up

apiVersion: topologies.eda.nokia.com/v1
kind: NetworkTopology
metadata:
  name: 46-esi-lag
  namespace: ""
spec:
  operation: Reconcile
  nodeTemplates:
    - name: leaf
      labels:
        eda.nokia.com/role: leaf
        eda.nokia.com/security-profile: managed
      nodeProfile: srlinux-ghcr-26.3.1
      platform: 7220 IXR-D3L
    - name: spine
      labels:
        eda.nokia.com/role: spine
        eda.nokia.com/security-profile: managed
      nodeProfile: srlinux-ghcr-26.3.1
      platform: 7220 IXR-D5
  nodes:
    - name: leaf1
      template: leaf
      annotations:
        topobuilder.eda.labs/x: "100"
        topobuilder.eda.labs/y: "210"
    - name: leaf2
      template: leaf
      annotations:
        topobuilder.eda.labs/x: "285"
        topobuilder.eda.labs/y: "215"
    - name: spine1
      template: spine
      annotations:
        topobuilder.eda.labs/x: "195"
        topobuilder.eda.labs/y: "50"
  linkTemplates:
    - name: isl
      type: InterSwitch
      speed: 25G
      encapType: "Null"
      labels:
        eda.nokia.com/role: interSwitch
    - name: edge
      type: Edge
      encapType: Dot1q
      labels:
        eda.nokia.com/role: edge
  links:
    - name: leaf1-spine1-1
      endpoints:
        - local:
            node: leaf1
            interface: ethernet-1-1
          remote:
            node: spine1
            interface: ethernet-1-1
      template: isl
    - name: leaf1-spine1-2
      endpoints:
        - local:
            node: leaf1
            interface: ethernet-1-2
          remote:
            node: spine1
            interface: ethernet-1-2
      template: isl
    - name: leaf2-spine1-1
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-1
          remote:
            node: spine1
            interface: ethernet-1-3
      template: isl
    - name: leaf2-spine1-2
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-2
          remote:
            node: spine1
            interface: ethernet-1-4
      template: isl
    - name: my-server-esi-lag-1
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-13
          sim:
            simNode: my-server
            simNodeInterface: eth1
        - local:
            node: leaf1
            interface: ethernet-1-13
          sim:
            simNode: my-server
            simNodeInterface: eth2
      template: edge
    - name: leaf1-ethernet-1-3
      endpoints:
        - local:
            node: leaf1
            interface: ethernet-1-3
      template: edge
    - name: leaf1-ethernet-1-4
      endpoints:
        - local:
            node: leaf1
            interface: ethernet-1-4
      template: edge
    - name: leaf1-ethernet-1-5
      endpoints:
        - local:
            node: leaf1
            interface: ethernet-1-5
      template: edge
    - name: leaf1-ethernet-1-6
      endpoints:
        - local:
            node: leaf1
            interface: ethernet-1-6
      template: edge
    - name: leaf1-ethernet-1-7
      endpoints:
        - local:
            node: leaf1
            interface: ethernet-1-7
      template: edge
    - name: leaf1-ethernet-1-8
      endpoints:
        - local:
            node: leaf1
            interface: ethernet-1-8
      template: edge
    - name: leaf1-ethernet-1-9
      endpoints:
        - local:
            node: leaf1
            interface: ethernet-1-9
      template: edge
    - name: leaf1-e1011
      endpoints:
        - local:
            node: leaf1
            interface: ethernet-1-10
      template: edge
    - name: leaf1-e1011
      endpoints:
        - local:
            node: leaf1
            interface: ethernet-1-11
      template: edge
    - name: leaf1-2-e1212
      endpoints:
        - local:
            node: leaf1
            interface: ethernet-1-12
      template: edge
    - name: leaf2-ethernet-1-3
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-3
      template: edge
    - name: leaf2-ethernet-1-4
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-4
      template: edge
    - name: leaf2-ethernet-1-5
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-5
      template: edge
    - name: leaf2-ethernet-1-6
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-6
      template: edge
    - name: leaf2-ethernet-1-7
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-7
      template: edge
    - name: leaf2-ethernet-1-8
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-8
      template: edge
    - name: leaf2-ethernet-1-9
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-9
      template: edge
    - name: leaf2-e1011
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-10
      template: edge
    - name: leaf2-e1011
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-11
      template: edge
    - name: leaf1-2-e1212
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-12
      template: edge
  simulation:
    simNodeTemplates:
      - name: default
        type: TestMan
      - name: server
        type: Linux
        image: ghcr.io/srl-labs/network-multitool
    simNodes:
      - name: testman-default
        template: default
      - name: my-server
        template: server
    topologies:
      - node: "*"
        interface: "*"
        simNode: testman-default

3.7 Adding a DCGW (SR OS)#

The DC fabric is running, but now we need WAN connectivity. Let's add a datacenter gateway (DCGW) to connect our fabric to the outside world. For this role, SR OS hardware is the right choice thanks to its stronger routing and WAN feature set.

So far we've only worked with fixed form-factor SR Linux nodes. All ports are built into the chassis, so no additional hardware definition is required besides the chassis type.

Many SR OS devices are modular chassis-based devices, which means we must define the hardware components and chassis layout in our topology.

The key components to know for SR OS devices are:

In the NetworkTopology workflow, you define these using the components field.

There are many permutations and component combinations that can be had with the plethora of SR OS hardware available, but we will stick to a 7750 SR-1 for this task, as it has quite a basic chassis layout.

  nodeTemplates:
    - name: dcgw
      nodeProfile: sros-ghcr-26.3.r1
      platform: 7750 SR-1
      components:
        - kind: controlCard
          type: cpm-1
          slot: a
        - kind: lineCard
          type: iom-1
          slot: "1"
        - kind: mda
          type: me12-100gb-qsfp28 #(2)!
          slot: 1-a
        - kind: connector
          type: c1-100g #(1)!
          slot: 1-a-1
      labels:
        eda.nokia.com/security-profile: managed
        eda.nokia.com/role: borderleaf

1. c1-100g is a connector type which gives 1x 100G port.
2. me12-100gb-qsfp28 is an MDA which gives us 12x100G QSFP28 ports.

SimNode CRD Reference (see the components field).

Now time to add our DCGW.

We need to:

• Add the node template for our 7750 SR-1 device
  • Ensure it is using nodeProfile sros-ghcr-26.3.r1
• Add the relevant CPM, IOM, MDA and Connector components.
• Connect it to the spine node.
  • Double-check to ensure the correct interface name is used.
• Deploy the workflow!

edactl -n eda get TopoNodes

NAME      PLATFORM       VERSION   OS     ONBOARDED   MODE     NPP         NODE
leaf2     7220 IXR-D3L   26.3.1    srl    true        normal   Connected   Synced
my-dcgw   7750 SR-1      26.3.r1   sros   true        normal   Connected   Synced
node-1    7220 IXR-D3L   26.3.1    srl    true        normal   Connected   Synced
spine1    7220 IXR-D5    26.3.1    srl    true        normal   Connected   Synced

edactl get -n eda TopoNode my-dcgw -o yaml

apiVersion: core.eda.nokia.com/v1
kind: TopoNode
metadata:
  labels:
    eda.nokia.com/role: borderleaf
    eda.nokia.com/security-profile: managed
  name: my-dcgw
  namespace: eda
spec:
  component:
  - kind: controlCard
    slot: a
    type: cpm-1
  - kind: lineCard
    slot: "1"
    type: iom-1
  - kind: mda
    slot: 1-a
    type: me12-100gb-qsfp28
  - kind: connector
    slot: 1-a-1
    type: c1-100g
  nodeProfile: sros-ghcr-26.3.r1
  npp:
    mode: normal
  onBoarded: true
  operatingSystem: sros
  platform: 7750 SR-1
  productionAddress: {}
  version: 26.3.r1
status:
  node-details: 10.244.0.195:57400
  node-state: Synced
  npp-details: 10.244.0.184:50057
  npp-pod: eda-npp-1
  npp-state: Connected
  operatingSystem: sros
  platform: 7750 SR-1
  simulate: true
  version: 26.3.r1

apiVersion: topologies.eda.nokia.com/v1
kind: NetworkTopology
metadata:
  name: 46-add-dcgw
  namespace: ""
spec:
  operation: Reconcile
  nodeTemplates:
    - name: dcgw
      nodeProfile: sros-ghcr-26.3.r1
      platform: 7750 SR-1
      components:
        - kind: controlCard
          type: cpm-1
          slot: a
        - kind: lineCard
          type: iom-1
          slot: "1"
        - kind: mda
          type: me12-100gb-qsfp28
          slot: 1-a
        - kind: connector
          type: c1-100g
          slot: 1-a-1
      labels:
        eda.nokia.com/security-profile: managed
        eda.nokia.com/role: borderleaf
    - name: leaf
      labels:
        eda.nokia.com/role: leaf
        eda.nokia.com/security-profile: managed
      nodeProfile: srlinux-ghcr-26.3.1
      platform: 7220 IXR-D3L
    - name: spine
      labels:
        eda.nokia.com/role: spine
        eda.nokia.com/security-profile: managed
      nodeProfile: srlinux-ghcr-26.3.1
      platform: 7220 IXR-D5
  nodes:
    - name: leaf1
      template: leaf
      annotations:
        topobuilder.eda.labs/x: "105"
        topobuilder.eda.labs/y: "215"
    - name: leaf2
      template: leaf
      annotations:
        topobuilder.eda.labs/x: "290"
        topobuilder.eda.labs/y: "220"
    - name: spine1
      template: spine
      annotations:
        topobuilder.eda.labs/x: "200"
        topobuilder.eda.labs/y: "55"
    - name: my-dcgw
      template: dcgw
      annotations:
        topobuilder.eda.labs/x: "50"
        topobuilder.eda.labs/y: "50"
  linkTemplates:
    - name: isl
      type: InterSwitch
      speed: 25G
      encapType: "Null"
      labels:
        eda.nokia.com/role: interSwitch
    - name: edge
      type: Edge
      encapType: Dot1q
      labels:
        eda.nokia.com/role: edge
  links:
    - name: leaf1-spine1-1
      endpoints:
        - local:
            node: leaf1
            interface: ethernet-1-1
          remote:
            node: spine1
            interface: ethernet-1-1
      template: isl
    - name: leaf1-spine1-2
      endpoints:
        - local:
            node: leaf1
            interface: ethernet-1-2
          remote:
            node: spine1
            interface: ethernet-1-2
      template: isl
    - name: leaf2-spine1-1
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-1
          remote:
            node: spine1
            interface: ethernet-1-3
      template: isl
    - name: leaf2-spine1-2
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-2
          remote:
            node: spine1
            interface: ethernet-1-4
      template: isl
    - name: my-dcgw-spine1-1
      endpoints:
        - local:
            node: my-dcgw
            interface: ethernet-1-a-1-1
          remote:
            node: spine1
            interface: ethernet-1-5
      template: isl
    - name: my-server-esi-lag-1
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-13
          sim:
            simNode: my-server
            simNodeInterface: eth1
        - local:
            node: leaf1
            interface: ethernet-1-13
          sim:
            simNode: my-server
            simNodeInterface: eth2
      template: edge
    - name: leaf1-ethernet-1-3
      endpoints:
        - local:
            node: leaf1
            interface: ethernet-1-3
      template: edge
    - name: leaf1-ethernet-1-4
      endpoints:
        - local:
            node: leaf1
            interface: ethernet-1-4
      template: edge
    - name: leaf1-ethernet-1-5
      endpoints:
        - local:
            node: leaf1
            interface: ethernet-1-5
      template: edge
    - name: leaf1-ethernet-1-6
      endpoints:
        - local:
            node: leaf1
            interface: ethernet-1-6
      template: edge
    - name: leaf1-ethernet-1-7
      endpoints:
        - local:
            node: leaf1
            interface: ethernet-1-7
      template: edge
    - name: leaf1-ethernet-1-8
      endpoints:
        - local:
            node: leaf1
            interface: ethernet-1-8
      template: edge
    - name: leaf1-ethernet-1-9
      endpoints:
        - local:
            node: leaf1
            interface: ethernet-1-9
      template: edge
    - name: leaf1-e1011
      endpoints:
        - local:
            node: leaf1
            interface: ethernet-1-10
      template: edge
    - name: leaf1-e1011
      endpoints:
        - local:
            node: leaf1
            interface: ethernet-1-11
      template: edge
    - name: leaf1-2-e1212
      endpoints:
        - local:
            node: leaf1
            interface: ethernet-1-12
      template: edge
    - name: leaf2-ethernet-1-3
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-3
      template: edge
    - name: leaf2-ethernet-1-4
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-4
      template: edge
    - name: leaf2-ethernet-1-5
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-5
      template: edge
    - name: leaf2-ethernet-1-6
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-6
      template: edge
    - name: leaf2-ethernet-1-7
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-7
      template: edge
    - name: leaf2-ethernet-1-8
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-8
      template: edge
    - name: leaf2-ethernet-1-9
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-9
      template: edge
    - name: leaf2-e1011
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-10
      template: edge
    - name: leaf2-e1011
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-11
      template: edge
    - name: leaf1-2-e1212
      endpoints:
        - local:
            node: leaf2
            interface: ethernet-1-12
      template: edge
  simulation:
    simNodeTemplates:
      - name: default
        type: TestMan
      - name: server
        type: Linux
        image: ghcr.io/srl-labs/network-multitool
    simNodes:
      - name: testman-default
        template: default
      - name: my-server
        template: server
    topologies:
      - node: "*"
        interface: "*"
        simNode: testman-default

3.8 Adding TestMan to the Digital Twin topology#

One of the big benefits of having a Digital Twin is that you can emulate client devices in it alongside the network topology, by connecting containers to the simulated network nodes.
From these client containers, one can run test tools such as ping, traceroute, iPerf, and so on.

By adding a SimNode with the type Linux to the topology and using a container image that comes loaded with diagnostic tools, like the srl-labs/network-multitool used elsewhere in the Hackathon topology, you can test the network.
However, having to add a SimNode for each access port, or coming up with a complicated Linux network setup to allow testing from multiple points in the same SimNode can be cumbersome, and frankly, quite manual work.
That is not very EDA-ific!

To address this issue, enter TestMan: a purpose-made testing container made for EDA, presenting the same API you know and love from EDA, that can test from any point in the network.

Adding a TestMan SimNode to our Digital Twin is easy - we just need to add the following snippet to the NetworkTopology resource describing the simulated topology.

spec:
  simulation:
    topologies:
      - node: "*"
        interface: "*"
        simNode: testman-default
    simNodeTemplates:
      - name: default
        type: TestMan #(2)!
    simNodes:
      - name: testman-default #(1)!
        template: default

1. Currently edactl tool expects the TestMan node to be named testman-default.
2. The .spec.simulation.simNodeTemplates[].type field is set to TestMan to indicate that this Sim Node template represents a TestMan container and not just a generic Linux container.

What this snippet ensures is that a single instance of the TestMan container is spun up inside the Digital Twin, and a link is created between TestMan and every defined interface of every node. This is already part of the NetworkTopology you spun up, so you have nothing further to do in this step!

3.9 Viewing TestMan interfaces#

In order to view the TestMan connections to our fabric, we can run the following TestMan edactl command:

edactl -n eda testman get-edge-if all

No EdgeInterfaces found

3.10 Defining a test case using TestMan#

To test the network on the Digital Twin using TestMan, we first need... a network. We already have a running topology, but no fabric, and no services defined!

Let's fix that by creating a Fabric and VirtualNetwork resource, the former creating a EVPN-VXLAN overlay fabric, the latter provisioning a MAC-VRF (Layer 2) service!
The MAC-VRF should be selecting all interfaces with the eda.nokia.com/role=edge label selector, and apply VLAN ID 10!

apiVersion: fabrics.eda.nokia.com/v1
kind: Fabric
metadata:
  name: myfabric-1
spec:
  interSwitchLinks:
    linkSelectors:
    - eda.nokia.com/role=interSwitch
    unnumbered: IPv6
  leafs:
    leafNodeSelectors:
    - eda.nokia.com/role=leaf
  overlayProtocol:
    protocol: EBGP
  spines:
    spineNodeSelectors:
    - eda.nokia.com/role=spine
  systemPoolIPv4: systemipv4-pool
  underlayProtocol:
    bgp:
      asnPool: asn-pool
    protocols:
    - EBGP