Node management#

This chapter provides the following information:

• bootstrapping and related procedures
• background information about zero-touch provisioning (ZTP)
• how to display information about and interact with nodes using the following views from the Nodes section the Nokia Event-Driven Automation (EDA) UI:
  • Resources view
  • Deleted Resources view
  • Discovered Resources view

Bootstrapping#

The Init application generates an initial configuration file for nodes that require bootstrapping. The input to the Init application is an Init resource, which specifies which TopoNodes to select and for which TopoNodes to create an initial configuration.

The initial configuration file is stored in the artifact server. When nodes connect to NPP, NPP pushes the initial configuration file to the node.

Additionally, the Init application generates the Python provisioning script for SR Linux and bootstrap files needed for SR OS or other operating systems. Based on the same selection criteria, a bootstrap file or Python provisioning script is generated for the selected nodes.

The bootstrap file or Python provisioning script ensures that the node boots into the version specified in the TopoNode. The software and any other artifacts are downloaded to the node during ZTP using HTTP/HTTPS.

By default, if no TopoNode selectors are present in the Init resource, an initial configuration file is generated for every TopoNode present in Nokia EDA.

Management interface IP address assignment#

The Init resource allows you to configure the management interface IP assignment method using DHCP or by defining static IP addresses. For details, see Enabling DHCP clients and Setting static management IP addresses.

Saving node configuration on commit#

To specify whether the node configuration is saved after each commit or not, in the Init CR include the entry commitSave: true. The Init script must reflect the commitSave value in the generated initial configuration.

Preparing for bootstrapping#

Ensure that you meet the following requirements:

• The NodeSecurityProfile resource (for TLS) must be configured to ensure successful onboarding. For details, see Node security profile.

• A node requires the relevant Nokia EDA License resource to be applied. Without this license, the node will not be onboarded.

  apiVersion: core.eda.nokia.com/v1
  kind: License
  metadata:
    name: eda-license
    namespace: eda-system #(1)!
  spec:
    enabled: true
    data: "ACoAgOlJq7AABoAU6V6W6XAERezbcYa+ZRZLg8M5IyqMgAABAATAEVEQS1bQkNdLTAuMC4qAAACABIATm9raWEuY29tLOVEQQAAAMAAMQCjorJ+SPKP3if9pcD3OhqlyaWK1VE89JWreOWkyOJcbIWO602C+iwp+FFp8AwAAAADAB4ARWRhIGxpY2Vuc2UgSW50ZXJuYWwgVGVzdAAAAAUAHADl0zNnAAAAAABgKWcAAAAAADohaAAAAADAACQAoKr6XCCQCZj1rWFYik1dGbiqG7TWRK2orh+0sjUKXNYBACkAMDAwMDAwMDAtMDAwMC0wMDAwLTAwMDAtMDAwMDAwMDAwMDAwAAAAAAYADAABAAQAAAAAAMAAMAC/KQqX7Di/m1d0zYz9quIyghaHatF0yDvDgK/fFr011Wa/7FN3LO/OoD3aHg8AXQFkOEh6ejQrTlFyNmVJNTNsVW9SMi9JV2xXd1NqMUF3QVh0eEd6LzhGdlp0WXphTkdOQ1RWRnNCQ3wwZ0p2b21pSDNiZHFTSFBYQ2R6d0xxVlNhM3FZZUZuL1BGMnhoSjN6OS8yS3RlVGpmUngreWFNS1NwZ0p5OE12YlBVbmw2TUFpNHRXR1g4U3R0WXFBN21uVUNhVHp5eXpLOWtXcWgwZVZtR1oyV09RTURML0thaWY1RGMva21tc0NVY042RUdNZUNiTmdvV2RKUFlXZ1o4c2hlaG03b2tsZHdsSDBxMXZWdjhHMjZ4OVUxbTd2ellBN3BDNkFXODJyZ3FsaExWTUJxYm11VDdKSzdPWWhzYVp4Q3h4a2lIbWZ5KytNY3FLVHFBUk1McWhYRzRIb290ME0xK1RaRVZTdUJKNFl5a3pkeHdVV3pGZGRZdjg5Ym5uUHBsdXc9PQAAAAA="
  

  1. If you changed your base namespace, make sure to update the namespace in the metadata.

• The node's images must be uploaded to the artifacts server before bootstrapping. The upload process is triggered by creating an Artifact resource that references the source file by the remoteFileUrl field and supports http(s), ftp and sftp protocols.

  Example Artifact resource to upload the SR Linux image to the artifacts server

  apiVersion: v1
  kind: Secret
  metadata:
    name: srl-ftp-cred
    namespace: eda
  type: Opaque
  data:
    username: base64(username)
    password: base64(password)
  ---
  apiVersion: artifacts.eda.nokia.com/v1
  kind: Artifact
  metadata:
    name: srlinux-24.10.1-492
    namespace: eda
  spec:
    repo: images
    filePath: srl.bin
    remoteFileUrl:
      fileUrl: ftp://10.10.10.10/eda/srl_images/srlinux-24.10.1-492.bin
    secret: srl-ftp-cred
  

Enabling DHCP clients#

To enable the IPv4 and IPv6 DHCP clients on the management interface, in the Init resource, include the following entries in the mgmtcontext:

ipv4DHCP: true

ipv6DHCP: true

In the mgmt section, by default, both ipv4DHCP and ipv6DHCP are set to true. Optionally, you can also set the IP MTU, as shown in the following example:

apiVersion: bootstrap.eda.nokia.com/v1alpha1
kind: Init
metadata:
  name: init-config
spec:
  nodeSelector:
  - 'eda.nokia.com/role=leaf'
  - 'eda.nokia.com/role=spine'
  - 'eda.nokia.com/role=borderleaf'
  - 'eda.nokia.com/role=superspine'
  - 'eda.nokia.com/role=backbone'
  mgmt:
    ipv4DHCP: true
    ipv6DHCP: true
    ipMTU: 9000

Setting static management IP addresses #

To set the management IP address statically, the init script must use the productionAddress setting from the Toponode resource as the IPv4 or IPv6 address in the generated configuration.

The init script sets the address as either IPv4 or IPv6 and sets the prefix length.

The table below displays the different combinations of ipv4DHCP, ipv6DHCP and productionAddress settings and the corresponding resulting initial configuration.

Static Routes#

To define the static routes in the Init CR, specify an IP prefix and a next hop. The Init script adds static routes to the management network instance. For example:

apiVersion: bootstrap.eda.nokia.com/v1alpha1
kind: Init
metadata:
  name: init-config
spec:
  nodeSelector:
  - 'eda.nokia.com/role=leaf'
  - 'eda.nokia.com/role=spine'
  - 'eda.nokia.com/role=borderleaf'
  - 'eda.nokia.com/role=superspine'
  - 'eda.nokia.com/role=backbone'
  mgmt:
    ipv4DHCP: true
    ipv6DHCP: true
    ipMTU: 9000
    staticRoutes:
      - prefix: 10.10.0.0/16
        nextHop: 172.16.255.29
      - prefix: 2001:10:10::/64
        nextHop: "200::"

Zero-touch provisioning#

Zero Touch Provisioning (ZTP) allows for a device to be installed in a rack, powered on, and without any additional input from an operator, boot up, pull down the software version of its operating system, an initial configuration and any other boot artifacts required for it to be managed.

Most ZTP implementations rely on DHCP to provide an IP address to the DUT and use DHCP options to inform the DUT of the location of any boot artifacts it requires to complete its ZTP process. In SR Linux, the DHCP server provides the URL of a Python provisioning script which is then used by the DUT to perform actions such as software upgrade and applying an initial configuration. In SR OS, the DHCP server provides a URL to a provisioning file which is a text file containing URLs to software images and configuration files.

For devices running SR OS and SR Linux, the devices send a DHCP Discover message with option 61 (client-id) set to the chassis serial number. This setting is used on the DHCP server to associate a DHCP discover message with a specific DUT and allows for the DHCP server to allocate static DHCP leases (IP addresses) and potentially device-specific boot artifacts (Python script or boot file).

Nokia EDA supports the following modes of operation for DHCP aspect of ZTP:

• Use of an internal DHCP server (hosted and managed by Nokia EDA)
• Use of an external DHCP server (hosted and managed outside of Nokia EDA)

To serve the boot artifacts (Python script, boot file, software, or any other files needed during the bootstrapping process), an artifact server must be present in Nokia EDA. An intent is used to allow for artifacts to be added to the server, which is then retrieved by the devices during boot.

DHCP server#

In deployments that use Nokia EDA to handle ZTP in its entirety, a DHCP server is required to provide IP addresses to devices.

When a device issues a DHCP discovery message, the client-id option (61) attribute includes their chassis serial number. This serial number is used to associate real devices with node objects in EDA. Additionally, an IP address is assigned to device via a Target object.

The DHCP server must support the following capabilities:

• Static lease assignment using the client-id (option 61) as the binding between an IP address and a device
• Ability to receive DHCP packets from a DHCP relay (the DHCP relay between the devices and the DHCP server)
• When providing an IP address to the device, the DHCP server must be able to populate option 66 or 67 in the DHCP offer. This option provides HTTPs. The URL points to the ZTP provisioning script or boot file hosted on the artifact server.
• Ability to populate other options as required by the operator, for example:
  • Router option 3
  • Time Server option 4
  • Name Server option 5
  • Domain Server option 6
  • Log server option 7
• Support both IPv4 and IPv6 IP addressing

Working with nodes from the Nokia EDA UI#

This section provides information about how to work with nodes using the UI.

Node Resources view#

The following table lists the default columns shown in the Node Resources page.

Click the Row actions menu for a node to display the actions that you can perform on the node. For example:

You can select from one of the following options:

• View: display details about a selected node, including status, mode of operation, and so forth.

  You can also double-click a node from the list to display the details for a node.

• Edit: edit the settings of a node

• Duplicate: create a new TopoNode based on an existing node
• Delete: delete a node
• Node Configuration: view the node configuration (its CR)

• Under the Workflows options, you can run the following tasks with the node as the target:

  • update the image of the node
  • ping the node
  • create a help package for tech support
  • do a route lookup
  • do a route trace
  • do an attachment lookup

  For more information about these workflows, see Workflow Definition List page.

Creating a TopoNode#

Deleted Resources page#

The Deleted Resources page displays all of the nodes that have previously been deleted from the system. From here you can view details about the reverted nodes, and if necessary, revert the deletion.

The list of nodes in the Deleted Resources page displays the following columns by default:

Discovered Nodes page#

The Discovered Nodes page contains a list of discovered nodes that have not been assigned to a fabric. When a discovered node is assigned to a fabric, it is removed from the Discovered Nodes list and added to the main list of nodes.

The list of nodes in the Discovered Nodes view displays the following columns by default.

Creating a new node#

You can create a new node from scratch or from an existing node.

Associating to an existing node#

You can associate a selected discovered node to an existing node.

Retrieving log files from nodes#

The edactl node log command retrieves logs from all nodes. You can specify a node to limit the logs retrieved to that specific node (see the example that follows).

Use the following options to filter the logs retrieved:

• --debug <app>: Retrieves debug logs for the specified application, matching the filename on the filesystem (for example, sr_bgp_mgr).
• --errors: Retrieves only error-level logs.
• --from <timestamp>: Sets the start of the collection period; retrieves only logs with a timestamp greater than or equal to the supplied value.
• --to <timestamp>: Sets the end of the collection period. Use with --from to define an interval.
• --prior <duration>: Retrieves logs from the most recent duration (for example, 5m for the last five minutes). When combined with --to, the collection window is limited to the period ending at the --to timestamp; if --to is absent, the window ends at the current time.
• --ignore <severity>: Ignores logs with certain severities. For example, --ignore NI ignores notification and informational logs.

You can enter a timestamp in one the following formats:

• Syslog format: Aug 21 03:48:00
• Linux date format: Apr 16 09:41:30 AM PDT 2026
• RFC3339 format: 2025-08-20T19:20:03.487197+00:00

edactl node log leaf-1 -n eda

Sep 28 04:56:16 leaf-1 sr_supportd: log|13683|13683|00001|I: File /var/log/messages has been rolled over
Sep 28 04:56:20 leaf-1 sr_aaa_mgr: aaa|3227|13661|00059|N: Opened session 2243 for user admin from host 10.244.0.213 in network-instance mgmt
Sep 28 04:56:20 leaf-1 sr_aaa_mgr: aaa|3227|13661|00060|N: User admin on session 2243 successfully authenticated from host 10.244.0.213 in network-instance mgmt
Sep 28 04:56:20 leaf-1 sr_aaa_mgr: aaa|3227|13661|00061|N: Closed session 2243 for user admin from host 10.244.0.213 in network-instance mgmt
Sep 28 04:56:30 leaf-1 sr_aaa_mgr: aaa|3227|13668|00035|N: Opened session 2244 for user admin from host 10.244.0.213 in network-instance mgmt
Sep 28 04:56:30 leaf-1 sr_aaa_mgr: aaa|3227|13668|00036|N: User admin on session 2244 successfully authenticated from host 10.244.0.213 in network-instance mgmt
Sep 28 04:56:30 leaf-1 sr_aaa_mgr: aaa|3227|13661|00062|N: Closed session 2244 for user admin from host 10.244.0.213 in network-instance mgmt
Sep 28 04:56:40 leaf-1 sr_aaa_mgr: aaa|3227|13668|00037|N: Opened session 2245 for user admin from host 10.244.0.213 in network-instance mgmt
Sep 28 04:56:40 leaf-1 sr_aaa_mgr: aaa|3227|13668|00038|N: User admin on session 2245 successfully authenticated from host 10.244.0.213 in network-instance mgmt
Sep 28 04:56:40 leaf-1 sr_aaa_mgr: aaa|3227|13661|00063|N: Closed session 2245 for user admin from host 10.244.0.213 in network-instance mgmt`