Consider the use case of enterprise data centers with leaf switch pairs in the top of rack(TOR). It is tedious to configure the switches individually, and ZTP is an excellent choice for pushing needed firmware and configurations.

The configuration sections that are defined in the ZTP JSON file are processed in the lexical order of their names. This provides a suitable way for the user to indicate the order in which they must be run.

Figure 16: Leaf-spine topology use case for ZTP

An example ZTP JSON file to update the firmware and configuration for Leaf3 in the figure is shown below:

{
  "ztp": {
      "01-firmware": {
          "install": {
             "url": "http://192.168.1.1/SONiC-OS-3.0.1-Enterprise_Base.bin"
            }
    },
    "02-configdb-json": {
         "dynamic-url": {
             "source": {
                 "prefix": "http://192.168.1.1/",
         "identifier": "Leaf3",
               "suffix": "¬_config_db.json"
      }
         }
      },     
     "03-provisioning-script": {
          "plugin": {
            "url":"http://192.168.1.1/post_install.sh"
           },
           "reboot-on-success": true
      },
      "04-connectivity-check": {
          "ping-hosts": [ "172.16.11.1", "172.16.11.2" ]
         }
     }
}

This is from the Examples section of https://github.com/Azure/SONiC/blob/master/doc/ztp/ztp.md#62-configuration-commands .

The config_db.json is saved as Leaf3_config_db.json in the web root of the HTTP server with the address 192.168.1.1. This allows the ZTP service to identify the configuration file associated with the switch uniquely. In this manner, multiple config_db.json files are related to several switches. The post_install.sh postprovisioning script downloads and runs. After the system reboots, perform a connectivity check to verify the connectivity by pinging hosts 172.16.11.1 and 172.16.11.2.