Node discovery

Several entities participate in the ZTP process when used in conjunction with the Fabric Services System.

• The Fabric Services System: this process assumes that the system is up and running and able to communicate across the network. Based on a user's input when designing a fabric intent, the system creates a set of configuration files that are used to configure each node so that it can perform its intended role in the fabric.

  Two subsystems integrated within the Fabric Services System also participate in the ZTP process:

  • a DHCP server: the system's integrated DHCP server is capable of receiving a newly booted SR Linux node's DHCP request and replying with an assigned IPv4 address, provided this SR Linux serial number is assigned to a fabric.

    You can use an external DHCP server if you prefer.

  • an HTTP file server: the system's integrated HTTP file server stages and transfers SR Linux image files, scripts, and other node configuration files after communication with an SR Linux node is established.

    You can use an external HTTP file server if you prefer.

• The SR Linux node: when first booted up, an SR Linux node continuously sends DHCP discovery messages requesting an IP address. After it receives an address and subsequent data from a DHCP server, ZTP software built into the Fabric Services System can process this information and allows the node to configure itself in accordance with information sent by a management system (in this case, the Fabric Services System).

The following sequence describes the series of events from the initial fabric intent design, to the communication with a newly installed SR Linux node, to the configuration of that node so it can function in its assigned role in the planned fabric.

Steps 2 through 7 in this process represent the standard SR Linux ZTP process.

Step 8 configures support for ZTP with the Fabric Services System. This step specifies the system server, its role as the fabric manager, and the FTP and HTTPS server's IP address and authentication data. These settings allows the node to communicate directly with the system and to be configured as required to participate in the planned fabric design.

1. In the Fabric Services System, an operator:
   1. adds any required SR Linux image intended for use on a fabric's nodes to the file server
   2. creates a fabric, specifying an SR Linux image
   3. associates individual nodes in the fabric intent with planned hardware, based on the hardware serial number
   The system waits for the required nodes to communicate with the DHCP server.
2. A newly-booted SR Linux node comes online and sends out IPv4 DHCP discovery requests.

   For IPv6 DHCP soliciting, a hard reboot of SR Linux in required. In addition, the Fabric Services System expects a route advertisement (RA) to be available on the network.

3. The system's internal DHCP server receives the request, replies with the assigned IP address, and points the SR Linux node to a ZTP configuration file (provisioning.py) on the integrated file server.
4. The node requests the ZTP configuration file from the system's file server and receives the file in reply. The configuration file identifies a particular SR Linux image for the node to use, and an associated MD5 file.
5. The node requests the MD5 file from the system's file server and receives the file in reply.
6. The node requests the binary file containing the correct SR Linux image from the file server, and receives the file in reply.
7. The node compares the received SR Linux image version to its current SR Linux version. If necessary, the node upgrades or downgrades itself to the new version of SR Linux contained in the image file.
8. The node requests from the file server the initconfig.json file identified in the provisioning.py file, and receives the file in reply. This file identifies the Fabric Services System as the fabric manager and includes the IP address and authentication information that the node can use to communicate with the system.
9. The node "phones home," telling the Fabric Services System server that the node is configured and ready for management.
10. Internally, the system updates the node's status to Ready.
11. After all nodes are in the Ready state, the operator must:
    1. add the fabric to region's deployment pipeline
    2. deploy the fabric from the deployment pipeline

    The system deploys additional configuration data to the node, so that the node can configure itself for participation in the fabric as intended by the fabric design from step 1.