1 # Network Topology Simulator (NTS)
3 The Network Topology Simulator is a framework that allows simulating devices that expose a management interface through a NETCONF/YANG interface.
9 The NETCONF/YANG management interface is simulated, and any YANG models can be loaded by the framework to be exposed. Random data is generated based on the specific models, such that each simulated device presents different data on its management interface.
11 The NTS Manager can be used to specify the simulation details and to manage the simulation environment at runtime.
13 The NTS framework is based on several open-source projects:
14 * [Netopeer2](https://github.com/CESNET/Netopeer2)
15 * [libnetconf2](https://github.com/CESNET/libnetconf2)
16 * [libyang](https://github.com/CESNET/libyang)
17 * [sysrepo](https://github.com/sysrepo/sysrepo) - all of these are used for the implementation of the NETCONF Server, both in the NTS Manager and in each simulated device
18 * [cJSON](https://github.com/DaveGamble/cJSON) - used to create the JSON payloads for talking with the simulation framework
19 * [pyang](https://github.com/mbj4668/pyang) - used to create random data from the YANG models that are exposed
21 Each simulated device is represented as a docker container, where the NETCONF Server is running. The creation and deletion of docker containers associated with simulated devices is handled by the NTS Manager. The NTS Manager is also running as a docker container and exposes a NETCONF/YANG interface to control the simulation.
25 The purpose of the NTS Manager is to ease the utilization of the NTS framework. It enables the user to interact with the simulation framework through a NETCONF/YANG interface. The user has the ability to modify the simulation parameters at runtime and to see the status of the current state of the NTS. The NETCONF/YANG interface will be detailed below.
28 module: network-topology-simulator
29 +--rw simulator-config!
30 | +--rw simulated-devices? uint32
31 | +--rw mounted-devices? uint32
32 | +--rw netconf-call-home? boolean
33 | +--rw notification-config
34 | | +--rw fault-notification-delay-period* uint32
35 | | +--rw ves-heartbeat-period? uint32
36 | | +--rw is-netconf-available? boolean
37 | | +--rw is-ves-available? boolean
38 | +--rw controller-details
39 | | +--rw controller-ip? inet:ip-address
40 | | +--rw controller-port? inet:port-number
41 | | +--rw netconf-call-home-port? inet:port-number
42 | | +--rw controller-username? string
43 | | +--rw controller-password? string
44 | +--rw ves-endpoint-details
45 | +--rw ves-endpoint-ip? inet:ip-address
46 | +--rw ves-endpoint-port? inet:port-number
47 | +--rw ves-endpoint-auth-method? authentication-method-type
48 | +--rw ves-endpoint-username? string
49 | +--rw ves-endpoint-password? string
50 | +--rw ves-endpoint-certificate? string
51 | +--rw ves-registration? boolean
52 +--ro simulator-status
53 +--ro simulation-usage-details
54 | +--ro running-simulated-devices? uint32
55 | +--ro running-mounted-devices? uint32
56 | +--ro ssh-connections? uint32
57 | +--ro tls-connections? uint32
58 | +--ro base-netconf-port? uint32
59 | +--ro cpu-usage? percent
60 | +--ro mem-usage? uint32
61 +--ro notification-count
62 | +--ro total-ves-notifications
63 | | +--ro normal? uint32
64 | | +--ro warning? uint32
65 | | +--ro minor? uint32
66 | | +--ro major? uint32
67 | | +--ro critical? uint32
68 | +--ro total-netconf-notifications
69 | +--ro normal? uint32
70 | +--ro warning? uint32
73 | +--ro critical? uint32
74 +--ro simulated-devices-list* [uuid]
76 +--ro device-ip? string
77 +--ro device-port* uint32
78 +--ro is-mounted? boolean
79 +--ro operational-state? operational-state-type
80 +--ro notification-count
81 +--ro ves-notifications
82 | +--ro normal? uint32
83 | +--ro warning? uint32
86 | +--ro critical? uint32
87 +--ro netconf-notifications
92 +--ro critical? uint32
95 +---x restart-simulation
96 +---x add-key-pair-to-odl
97 +---x invoke-notification
99 | +---w device-id string
100 | +---w yang-module-name string
101 | +---w notification-object string
103 +--ro status enumeration
106 #### Detailed information about the YANG attributes
110 * **simulated-devices** - represents the number of simulated devices. The default value is 0, meaning that when the NTS is started, there are no simulated devices. When this value is increased to **n**, the NTS Manager starts docker containers in order to reach **n** simulated devices. If the value is decreased to **k**, the NTS Manager will remove docker containers, until the number of simulated devices reaches **k**;
111 * **mounted-devices** - represents the number of devices to be mounted to an ODL based SDN Controller. The same phylosophy as in the case of the previous leaf applies. If this number is increased, the number of ODL mountpoints increases. Else, the simulated devices are being unmounted from ODL. The number of mounted devices cannot exceed the number of simulated devices. The details about the ODL controller where to mount/unmount are given by the **controller-details** container; **Please note that this cannot be set to a value > 0 if the *ves-registration* leaf is set to 'True'**; For each simulated device, a number of NETCONF endpoints will be mounted, according to the **ssh-connections** and **tls-connections** leafs. See **NETCONF Endpoints** section for more details;
112 * **netconf-call-home** - if set to `true`, each simulated device will try to use NETCONF Call Home feature and try to reach the ODL Controller. The default value is `false`.
113 * **notification-config** - this container groups the configuration about fault notification generation of each simulated device;
114 * **fault-notification-delay-period** - the amount of seconds between two generated fault notifications. For example, if this has a value of *10*, each simulated device will generate a **random** fault notification every *10* seconds; **when this is set to 0, it will reset the notification counters for the VES and NETCONF notifications, which are exposed in the simulator-status**; The type is a leaf-list, such that the user could define a pattern for sending the notifications. E.g.: [10, 3, 5] means that a notification will be sent after 10 seconds, then after another 3 seconds, then after 5 seconds, and then again after 10, 3, 5 etc.
115 * **ves-heartbeat-period** - the amount of seconds between VES heartbeat messages that can be generated by each simulated device. The details about the VES connection endpoint are given in the **ves-endpoint-details** container;
116 * **is-netconf-available** - if set to 'True', NETCONF notifications will be sent when a random fault notification is generated, The NETCONF notification that is being sent is currently *o-ran-fm:alarm-notif*; if set to 'False', NETCONF notifications are not being sent out;
117 * **is-ves-available** - if set to 'True', VES *faultNotification* messages will be sent when a random fault notification is generated; if set to 'False', VES *faultNotification* messages are not generated;
118 * **controller-details** - this container groups the configuration related to the ODL based SDN controller that the simulated devices can connect to;
119 * **controller-ip** - the IP address of the ODL based SDN controller where the simulated devices can be mounted. Both IPv4 and IPv6 are supported;
120 * **controller-port** - the port of the ODL based SDN controller;
121 * **netconf-call-home-port** - the NETCONF Call Home port of the ODL based SDN controller;
122 * **controller-username** - the username to be used when connecting to the ODL based SDN controller;
123 * **controller-password** - the password to be used when connecting to the ODL based SDN controller;
124 * **ves-endpoint-details** - this container groups the configuration related to the VES endpoint where the VES messages are targeted;
125 * **ves-endpoint-ip** - the IP address of the VES endpoint where VES messages are targeted;
126 * **ves-endpoint-port** - the port address of the VES endpoint where VES messages are targeted;
127 * **ves-endpoint-auth-method** - the authentication method to be used when sending the VES message to the VES endpoint. Possible values are:
128 + *no-auth* - no authentication;
129 + *cert-only* - certificate only authentication; in this case the certificate to be used for the communication must be configured;
130 + *basic-auth* - classic username/password authentication; in this case both the username and password need to be configured;
131 + *cert-basic-auth* - authentication that uses both username/password and a certificate; all three values need to be configured in this case;
132 * **ves-endpoint-username** - the username to be used when authenticating to the VES endpoint;
133 * **ves-endpoint-password** - the password to be used when authenticating to the VES endpoint;
134 * **ves-endpoint-certificate** - the certificate to be used when authenticating to the VES endpoint;
135 * **ves-registration** - if this is set to 'True' **when simulated devices are starting**, each simulated device will send out *pnfRegistration* VES messages to the configured VES endpoint; if this is set to 'False', *pnfRegistration* VES messages will not be sent out. **Please note that this cannot be set to 'True' is simulated devices are already mounted to ODL based SDN controller (mounted-devices leaf > 0)**; For each simulated device, **ssh-connections + tls-connections** pnfRegistration VES messages will be sent out. See **NETCONF Endpoints** section for more details.
139 * **simulation-usage-details** - this container groups the information about the current simulator status;
140 * **running-simulated-devices** - the current number of running simulated devices;
141 * **running-mounted-devices** - the current number of running simulated devices that have been mounted to the ODL based SDN controller; For each simulated device, 10 NETCONF endpoints will be mounted (7 SSH + 3 TLS). See **NETCONF Endpoints** section for more details.
142 * **ssh-connections** - represents the number of SSH endpoints that are exposed by each of the simulated devices. **Please note that the total number of SSH and TLS connections cannot exceed 100.** The default value is 1. **The value can only be changed when the NTS Manager is started, through the SshConnections environment variable**.
143 * **tls-connections** - represents the number of TLS endpoints that are exposed by each of the simulated devices. **Please note that the total number of SSH and TLS connections cannot exceed 100.** The default value is 0. **The value can only be changed when the NTS Manager is started, through the SshConnections environment variable**.
144 * **base-netconf-port** - the port that was used as a base when craeting simulated devices;
145 * **cpu-usage** - the percentage of the CPU used currently by the simulation framework;
146 * **mem-usage** - the amount of RAM used (in MB) currently by the simulation framework;
147 * **notification-count** - this container groups the details about the total number of notifications that were generated by the simulated devices;
148 * **total-ves-notifications** - this container groups the details about the total number of VES notifications that were generated by the simulated devices, grouped by severity;
149 * **total-netcnof-notifications** - this container groups the details about the total number of NETCONF notifications that were generated by the simulated devices - grouped by severity;
150 * **simulated-devices-list** - this list contains the details about each simulated devices that is currently running;
151 * **uuid** - the Universally Unique ID of the simulated device;
152 * **device-ip** - the IP address of the simulated device;
153 * **device-port** - the port of the simulated device, where the NETCONF connection is exposed;
154 * **is-mounted** - boolean to show whether the device is currently mounted to an ODL based SDN controller;
155 * **operational-state** - the operational state of the current simulated device; it can be either *not-specified*, *created*, *running* or *exited*;
156 * **notification-count** - this container groups the details about the number of notifications that were generated by this particular simulated device;
157 * **ves-notifications** - this container groups the details about the number of VES notifications that were generated by this simulated device, grouped by severity;
158 * **netconf-notifications** - this container groups the details about the number of NETCONF notifications that were generated by this simulated device - grouped by severity.
162 * **add-key-pair-to-odl** - this RPC can be used to trigger the loading of a *keystore* entry in an ODL based SDN controller such that the controller can connect to the simulated devices via **TLS**. A private key, an associated certificate and a trusted certificate are loaded in the *keystore* entry in ODL. The certificate associated with the private key to be used by ODL in the TLS communication is signed by the same CA as the certificates used by the simulated devices, easing the TLS configuration in both the NETCONF Server and the ODL.
163 * **restart-simulation** - this RPC is not yet implemented.
164 * **invoke-notification** - this RPC is used for forcing a simulated device to send a NETCONF notification, as defined by the user.
165 - The **input** needed by the RPC:
166 - **device-id** - this is a string containing the name of the simulated device that we want to send the notification. The user is responsible to give a correct name which really exists, otherwise the RPC will fail.
167 - **yang-module-name** - this is a string containing the name of the YANG module which implements the notification that we want to send. E.g.: ***org-openroadm-device*** module defines several notifications.
168 - **notification-object** - this is a string containing the notification object that we are trying to send from the simulated device, in JSON format. **Please note that the user has the responsibility to ensure that the JSON object is valid, according to the definition of the notification in the YANG module.** There is no possibility to see what was wrong when trying to send an incorrect notification. The RPC will only respond with an "ERROR" status in that case, without further information. E.g. of a JSON containing a notification object of type ***otdr-scan-result*** defined in the ***org-openroadm-device*** YANG module: ***{"org-openroadm-device:otdr-scan-result":{"status":"Successful","status-message":"Scan result was successful","result-file":"/home/result-file.txt"}}***. **Please note that the notification object contains also the name of the YANG model defning it, as a namespace, as seen in the example.**
169 - The **output** returned by the RPC:
170 - **status** - if the notification was send successfully by the simulated device, the RPC will return a **SUCCESS** value. Else, the RPC will return a **ERROR** value.
174 Each simulated device is represented as a docker container, inside which the NETCONF Server runs. The simulated device exposes the YANG models which are found inside the **yang** folder. A custom version of the *pyang* utility is used to generate random data for each of the YANG modules found inside the **yang** folder.
176 #### NETCONF Endpoints
178 Each simulated device exposes a number of NETCONF endpoints which represented by the sum of the **SshConnections** and **TlsConnections** environment variables, on consecutive ports. The first simulated device uses the ports starting from the **NETCONF_BASE** environment variable used when starting the NTS Manager, while the next one uses the next ports and so on and so forth. E.g. if the **NETCONF_BASE=50000** and **SshConnections=5** and **TlsConnections=3**, the first simulated device will expose ports from *50000* to *50007*, the second simulated device will expose ports from *5008* to *50015* etc.
180 The first **SshConnections** ports exposed by a simulated device are **SSH** based. A NETCONF client can connect to the exposed endpoint using one of the SSH ports (e.g. 50000 to 50007, considering the previous example) and the **username/password**: *netconf/netconf*.
182 The last **TlsConnections** ports exposed by a simulated device are **TLS** based. A NETCONF client can connect to the exposed endpoint using one of the TLS ports (e.g. 50006 to 50008, considering the previous example), using a valid certificate and the **username**: *netconf*.
186 ### Building the images
188 The `docker-build-nts-manager.sh` script can be used to built the docker image associated with the NTS Manager. This will create a docker image named *ntsim_manager_light*, which will be used to start the simulation framework. Inside the docker image, port 830 will wait for connections for the NETCONF/YANG management interface.
190 The `docker-build-onf-core-model-1-2.sh` script can be used to build the docker image associated with a simulated device, exposing the ONF CoreModel version 1.2.
192 The `docker-build-onf-core-model-1-4.sh` script can be used to build the docker image associated with a simulated device, exposing the ONF CoreModel version 1.4.
194 The `docker-build-openroadm.sh` script can be used to build the docker image associated with a simulated device, exposing the OpenROADM models.
196 The `docker-build-o-ran-device.sh` script can be used to build the docker image associated with a simulated device, exposing the O-RAN models.
198 The `docker-build-o-ran-sc-o-ran-ru.sh` script can be used to build the docker image associated with a simulated device, exposing the O-RAN-SC models.
200 The `docker-build-x-ran-device.sh*` script can be used to build the docker image associated with a simulated device, exposing the X-RAN models.
202 ### Starting the NTS Manager
204 The NTS Manager can be started using the `docker-compose.yml` file that is provided inside tthe **scripts** folder. Further, the parameters present in this file are explained.
210 image: "ntsim_manager:latest"
211 container_name: NTS_Manager
215 - "/var/run/docker.sock:/var/run/docker.sock"
216 - "/var/tmp/NTS_Manager:/opt/dev/scripts"
217 - "/usr/bin/docker:/usr/bin/docker"
223 DOCKER_ENGINE_VERSION: "1.40"
224 MODELS_IMAGE: "ntsim_oran"
225 VesHeartbeatPeriod: 0
226 IsVesAvailable: "true"
227 IsNetconfAvailable: "true"
228 VesRegistration: "false"
229 VesEndpointPort: 8080
230 VesEndpointIp: "172.17.0.1"
233 K8S_DEPLOYMENT: "false"
234 CONTAINER_NAME: "ntsimulator"
235 NetconfCallHome: "true"
236 NetconfCallHomePort: 6666
237 ControllerIp: "10.20.11.121"
239 ControllerUsername: "admin"
240 ControllerPassword: "admin"
246 * `"8300:830"` - this maps the *830* port from inside the docker container of the NTS Manager to the port *8300* from the host, and binds it to any IP address on the host:
248 * Volumes - these map 3 important things:
249 * the docker socket from the host is mapped inside the docker container:
250 `/var/run/docker.sock:/var/run/docker.sock` - **please do not modify the path inside the container!**;
251 * any folder from the host can be mapped to inside the docker container into othe **/opt/dev/scripts** folder:
252 `/var/tmp/NTS_Manager:/opt/dev/scripts` - **please do not modify the path inside the container!**;
253 * the path to the docker executable needs to be mapped inside the container:
254 `/usr/bin/docker:/usr/bin/docker` - **please do not modify the path inside the container!**;
256 * Labels - this associates the *NTS-manager* label to the docker container where the NTS runs;
257 * Environment variables:
258 * **NTS_IP** - this should point to an IP address **from the host**, through which the simulated devices will be accessed;
259 * **NETCONF_BASE** - this is the starting port used to expose NETCONF endpoints. Starting from this, each device will use 10 consecutive ports for its endpoints; **Please note that if multiple managers are deployed on the same machine, this environment variable needs to be different for each of the managers!**
260 * **DOCKER_ENGINE_VERSION** - this is the version of the *docker engine* installed currently on the host. This can be verified using `docker version` command in the host, and looking to the `API version: #.##` variable from the Server details.
261 * **MODELS_IMAGE** - this represents the name of the docker image that represents the simulated device. The NTS Manager will start containers using this image, when starting simulated devices.
262 * **VesHeartbeatPeriod** - this can change the default value of the **ves-heartbeat-period** leaf used by the NTS Manager.
263 * **IsVesAvailable** - this can change the default value of the **is-ves-available** leaf used by the NTS Manager.
264 * **IsNetconfAvailable** - this can change the default value of the **is-netconf-available** leaf used by the NTS Manager.
265 * **VesRegistration** - this can change the default value of the **ves-registration** leaf used by the NTS Manager.
266 * **VesEndpointPort** - this can change the default value of the **ves-endpoint-port** leaf used by the NTS Manager.
267 * **VesEndpointIp** - this can change the default value of the **ves-endpoint-ip** leaf used by the NTS Manager.
268 * **SshConnections** - **this can change the number of SSH connection endpoints which are exposed by each simulated device.**
269 * **TlsConnections** - **this can change the number of TLS connection endpoints which are exposed by each simulated device.**
270 * **K8S_DEPLOYMENT** - this value can be set to `true` when the user wants to the NTS Framework in a Kubernetes deployment. The default is `false`.
271 * **CONTAINER_NAME** - this represents the name to be used by the NTS Manager for asigning to each simulated device, suffixed by a number. The default is `ntsim`. E.g.: the first simulated device will be *ntsim-0*, the second onoe *ntsim-1* and so on. **Please note that if multiple managers are deployed on the same machine, this environment variable needs to be different for each of the managers!**
272 * **ControllerIp** - this can change the default value of the **controller-ip** leaf used by the NTS Manager. The default is `172.17.0.1`.
273 * **ControllerPort** - this can change the default value of the **controller-port** leaf used by the NTS Manager. The default is `8181`.
274 * **NetconfCallHomePort** - this can change the default value of the **netconf-call-home-port** leaf used by the NTS Manager. The default is `6666`.
275 * **ControllerUsername** - this can change the default value of the **controller-username** leaf used by the NTS Manager. The default is `admin`.
276 * **ControllerPassword** - this can change the default value of the **controller-password** leaf used by the NTS Manager. The default is `admin`.
277 * **NetconfCallHome** - this can change the default value of the **netconf-call-home** leaf used by the NTS Manager. The default is `false`.
278 * **IPv6Enabled**: if this is set to `true`, IPv6 is enabled. **Please note that for a working configuration, it is the user responsibility to correctly configure the Docker daemon to work with IPv6, prior to starting the NTS Manager!**
280 After modifying the `docker-compose.yml` file with values specific to your host, the NTS Manager can be started by running the command `docker-compose up` from the **scripts** folder.
282 After the NTS Manager is started, it will wait for connections on its NETCONF/YANG management interface. One can connect to this using a NETCONF Client. The **username/password** for connecting are: *netconf/netconf*.
284 Example of `docker ps` command result, after the NTS Manager was started:
287 7ff723b7f794 ntsim_manager:latest "sh -c '/usr/bin/sup…" 5 days ago Up 5 days 0.0.0.0:8300->830/tcp NTS_Manager
290 ### Using the NTS Manager
292 When the NTS Manager is started, its default configuration looks like this:
295 <simulator-config xmlns="urn:onf:params:xml:ns:yang:network-topology-simulator">
296 <simulated-devices>0</simulated-devices>
297 <mounted-devices>0</mounted-devices>
298 <netconf-call-home>false</netconf-call-home>
299 <notification-config>
300 <fault-notification-delay-period>0</fault-notification-delay-period>
301 <ves-heartbeat-period>0</ves-heartbeat-period>
302 <is-netconf-available>true</is-netconf-available>
303 <is-ves-available>true</is-ves-available>
304 </notification-config>
306 <controller-ip>172.17.0.1</controller-ip>
307 <controller-port>8181</controller-port>
308 <netconf-call-home-port>6666</netconf-call-home-port>
309 <controller-username>admin</controller-username>
310 <controller-password>admin</controller-password>
311 </controller-details>
312 <ves-endpoint-details>
313 <ves-endpoint-ip>172.17.0.1</ves-endpoint-ip>
314 <ves-endpoint-port>30007</ves-endpoint-port>
315 <ves-endpoint-auth-method>no-auth</ves-endpoint-auth-method>
316 <ves-registration>false</ves-registration>
317 </ves-endpoint-details>
321 This configuration can be altered by connecting to the NTS Manager with a NETCONF Client.
323 ### Starting a simulated device
325 Example RPC for starting **one** simulated device:
328 <?xml version="1.0" encoding="utf-8"?>
329 <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="">
335 <simulator-config xmlns="urn:onf:params:xml:ns:yang:network-topology-simulator">
336 <simulated-devices>1</simulated-devices>
344 If the leaf `<simulated-devices>1</simulated-devices>` will be set to a value of **1**, the NTS Manager will start a new docker container. We can verify that this was successfull by running the `docker ps` command. The results will look like this:
347 c18eb7a362f5 ntsim_oran "sh -c '/usr/bin/sup…" 4 days ago Up 4 days 172.17.0.1:50000->830/tcp, 172.17.0.1:50001->831/tcp, 172.17.0.1:50002->832/tcp, 172.17.0.1:50003->833/tcp, 172.17.0.1:50004->834/tcp, 172.17.0.1:50005->835/tcp, 172.17.0.1:50006->836/tcp, 172.17.0.1:50007->837/tcp, 172.17.0.1:50008->838/tcp, 172.17.0.1:50009->839/tcp reverent_bhabha
353 ### No simulated devices are starting
355 If, after setting the leaf `<simulated-devices>1</simulated-devices>` to a value greater that 0, no new containers are created, please make sure that the image name specified in the **MODELS_IMAGE** environment variable when starting the NTS Manager is present in the host. You can verify that using the `docker images` command.
357 Example of a result of such a command:
360 ntsim_oran_light latest 57b065de4458 4 days ago 186MB
363 This means that `MODELS_IMAGE: "ntsim_oran_light:latest"` can be used as an environment variable when starting the NTS Manager.
368 ### **version 0.6.4**
370 Bug fixes and improvements:
371 * Fixed bug where pnfRegistration messages for TLS connections were not sent.
372 * Fixed bug for manual notification generation failed when notification object was too long.
374 ### **version 0.6.1**
377 * **Manual notification generation** - this enables the user to send a NETCONF notification from a simulated device, using the *invoke-notification* RPC defined in the NTS Manager.
378 * **automatic pulling of the simulated device image** - the NTS Manager will automatically try to pull the image of the simulated device (as defined in the **MODELS_IMAGE** environment variable) before starting a simulated device.
379 * **custom naming of simulated devices** - the user can now define its own name prefix for simulated devices, through the **CONTAINER_NAME** environment variable defined in the docker-compose.yml. E.g.: if CONTAINER_NAME: "ntsim", the simulated devices will be: *ntsim-0*, *ntsim-1* etc.
381 Bug fixes and improvements:
382 * **ssh-connections** and **tls-connections** are now removed from the simulator-config, and can be set only when the NTS Manager is started, through the **SshConnections** and **TlsConnections** environment variables defined in the docker-compose.yml. The leafs are not moved in the simulator-status, such that the user can check at runting what are the values defined.
383 * **fault-notification-delay-period** has now the attribute *ordered-by user*, meaning that the order defined by the user when adding multiple values to the leaf-list is preserved.
385 ### **version 0.5.1**
388 * **NETCONF Call Home** - this enables each simulated device to use the Call Home feature to connect to the ODL instance, once it boots up. **Please note that when a device is using Call Home, it will no longed expose all the number of *ssh-connections* and *tls-connections*, but a single Call Home endpoint. **
389 * **controller-details** configuration leafs are now exposed can now be set at startup time in the docker-compose YAML file, as environment variables.
Code Review / sim / o1-interface.git / blob