Added netconf example for sros and gnmic url rename (#2327)

added netconf example for sros and gnmic url rename

Author: hellt

docs/lab-examples/min-5clos.md

@@ -7,27 +7,32 @@
 | **Name**                      | clos02                                                               |
 
 ## Description
+
 This labs provides a lightweight folded 5-stage CLOS fabric with Super Spine level bridging two PODs.
 
 <div class="mxgraph" style="max-width:100%;border:1px solid transparent;margin:0 auto; display:block;" data-mxgraph="{&quot;page&quot;:7,&quot;zoom&quot;:1.5,&quot;highlight&quot;:&quot;#0000ff&quot;,&quot;nav&quot;:true,&quot;check-visible-state&quot;:true,&quot;resize&quot;:true,&quot;url&quot;:&quot;https://raw.githubusercontent.com/srl-labs/containerlab/diagrams/containerlab.drawio&quot;}"></div>
 
 The topology is additionally equipped with the Linux containers connected to leaves to facilitate use cases which require access side emulation.
 
 ## Use cases
+
 With this lightweight CLOS topology a user can exhibit the following scenarios:
 
 * perform configuration tasks applied to the 5-stage CLOS fabric
 * demonstrate fabric behavior leveraging the user-emulating linux containers attached to the leaves
 
 ## Configuration setup
+
 To help you get faster to the provisioning of the services on this mini fabric we added an auto-configuration script to this example.
 
 In order to make a fully deterministic lab setup we added another topology file called [setup.clos02.clab.yml][setup-topofile] where the management interfaces of each network node and clients are statically addressed with [`mgmt-ipv4/6` config option](../manual/nodes.md#mgmt-ipv4). Other than that, the topology files does not have any changes.
 
 ### Prerequisites
-The configuration of the fabric elements is carried out with [`gnmic` client](https://gnmic.kmrd.dev/install/), therefore it needs to be installed on the machine where you run the lab.
+
+The configuration of the fabric elements is carried out with [`gnmic` client](https://gnmic.openconfig.net/install/), therefore it needs to be installed on the machine where you run the lab.
 
 ### Run instructions
+
 First deploy this topology as per usual:
 
 ```
@@ -40,11 +45,9 @@ Once the lab is deployed, execute the [configuration script][setup-script]:
 bash setup.sh
 ```
 
-
-
 ### Configuration schema
-The [setup script][setup-script] will use the following IP addresses across the nodes of the lab:
 
+The [setup script][setup-script] will use the following IP addresses across the nodes of the lab:
 
 The script will configure the following:
 
@@ -122,4 +125,4 @@ Configuration snippets that are used to provision the nodes are contained within
 
 [^1]: Resource requirements are provisional. Consult with SR Linux Software Installation guide for additional information.
 
-<script type="text/javascript" src="https://viewer.diagrams.net/js/viewer-static.min.js" async></script>
+<script type="text/javascript" src="https://viewer.diagrams.net/js/viewer-static.min.js" async></script>

docs/lab-examples/single-srl.md

@@ -7,13 +7,15 @@
 | **Name**                      | srl01                                                                |
 
 ## Description
+
 A lab consists of a single SR Linux container equipped with a single interface - its management interface. No other network/data interfaces are created.
 
 <center><div class="mxgraph" style="max-width:100%;border:1px solid transparent;" data-mxgraph="{&quot;page&quot;:2,&quot;zoom&quot;:1.5,&quot;highlight&quot;:&quot;#0000ff&quot;,&quot;nav&quot;:true,&quot;check-visible-state&quot;:true,&quot;resize&quot;:true,&quot;url&quot;:&quot;https://raw.githubusercontent.com/srl-labs/containerlab/diagrams/containerlab.drawio&quot;}"></div></center>
 
 The SR Linux's `mgmt` interface is connected to the `containerlab` docker network that is created as part of the lab deployment process. The `mgmt` interface of SRL will get IPv4/6 address information via DHCP service provided by docker daemon.
 
 ## Use cases
+
 This lightweight lab enables the users to perform the following exercises:
 
 * get familiar with SR Linux architecture
@@ -26,6 +28,6 @@ This lightweight lab enables the users to perform the following exercises:
 [topofile]: https://github.com/srl-labs/containerlab/tree/main/lab-examples/srl01/srl01.clab.yml
 
 [^1]: Resource requirements are provisional. Consult with SR Linux Software Installation guide for additional information.
-[^2]: Check out [gnmic](https://gnmic.kmrd.dev) gNMI client to interact with SR Linux gNMI server.
+[^2]: Check out [gnmic](https://gnmic.openconfig.net/) gNMI client to interact with SR Linux gNMI server.
 
-<script type="text/javascript" src="https://viewer.diagrams.net/js/viewer-static.min.js" async></script>
+<script type="text/javascript" src="https://viewer.diagrams.net/js/viewer-static.min.js" async></script>

docs/lab-examples/templated01.md

@@ -45,14 +45,13 @@ Run `configure.sh` script to configure the lab
 bash configure.sh
 ```
 
-The `configure.sh` script relies on [gomplate](https://docs.gomplate.ca) and [gnmic](https://gnmic.kmrd.dev).
+The `configure.sh` script relies on [gomplate](https://docs.gomplate.ca) and [gnmic](https://gnmic.openconfig.net/).
 
 - [gomplate](https://docs.gomplate.ca) is used to generate the necessary configuration variables based on the number of spines and leaves, their type and prefix.
-- [gnmic](https://gnmic.kmrd.dev) is used to generate configuration payloads per node and push it using a gNMI Set RPC.
+- [gnmic](https://gnmic.openconfig.net/) is used to generate configuration payloads per node and push it using a gNMI Set RPC.
 
 [srl]: https://www.nokia.com/networks/products/service-router-linux-NOS/
 [topofile]: https://github.com/srl-labs/containerlab/tree/main/lab-examples/templated01/templated01.clab.gotmpl
 [topovarfile]: https://github.com/srl-labs/containerlab/tree/main/lab-examples/templated01/templated01.clab_vars.yaml
 
-
 <script type="text/javascript" src="https://viewer.diagrams.net/js/viewer-static.min.js" async></script>

docs/manual/kinds/ceos.md

@@ -45,7 +45,7 @@ Arista cEOS node launched with containerlab can be managed via the following int
     ```
 === "gNMI"
     gNMI server is running over port 6030 in non-secure mode
-    using the best in class [gnmic](https://gnmic.kmrd.dev) gNMI client as an example:
+    using the best in class [gnmic](https://gnmic.openconfig.net/) gNMI client as an example:
     ```bash
     gnmic -a <container-name/node-mgmt-address>:6030 --insecure \
     -u admin -p admin \

docs/manual/kinds/srl.md

@@ -50,7 +50,7 @@ docker exec -it <container-name/id> sr_cli
 or with SSH `ssh admin@<container-name>`
 ///
 /// tab | gNMI
-using the best in class [gnmic](https://gnmic.kmrd.dev) gNMI client as an example:
+using the best in class [gnmic](https://gnmic.openconfig.net/) gNMI client as an example:
 
 ```bash
 gnmic -a <container-name/node-mgmt-address> --skip-verify \
@@ -93,28 +93,30 @@ SR Linux nodes come up with SNMPv2 server enabled and running on port 161. The d
 
 ```shell
 docker run -i -t ghcr.io/hellt/net-snmp-tools:5.9.4-r0 \
-  snmpwalk -v 2c -c public $address
+  snmpwalk -v 2c -c public <node-name>
 ```
 
 ///
 
 /// tab | NETCONF
 From SR Linux release 24.7.1 onwards, SR Linux comes with NETCONF server enabled and running on port 830.
 
+Using [netconf-console2](https://github.com/hellt/netconf-console2-container):
+
 ```bash
 docker run --rm --network clab -i -t \
 ghcr.io/hellt/netconf-console2:3.0.1 \
---host srl --port 830 -u admin -p 'NokiaSrl1!' \
+--host <node-name> --port 830 -u admin -p 'NokiaSrl1!' \
 --hello
 ```
 
 ///
 
 ### Credentials
 
-Default credentials[^4]: `admin:NokiaSrl1!`
+Default credentials[^1]: `admin:NokiaSrl1!`
 
-Containerlab will automatically enable public-key authentication for `root`, `admin` and `linuxadmin` users if public key files are found at `~/.ssh` directory[^1].
+Containerlab will automatically enable public-key authentication for `root`, `admin` and `linuxadmin` users if public key files are found at `~/.ssh` directory[^2].
 
 ## Interfaces naming
 
@@ -360,7 +362,7 @@ Besides augmenting the factory-provided `mgmt` gRPC server block, containerlab a
 
 ### SSH Keys
 
-Containerlab will read the public keys found in `~/.ssh` directory of a sudo user as well as the contents of a `~/.ssh/authorized_keys` file if it exists[^2]. The public keys will be added to the startup configuration for `admin` and `linuxadmin` users to enable passwordless access.
+Containerlab will read the public keys found in `~/.ssh` directory of a sudo user as well as the contents of a `~/.ssh/authorized_keys` file if it exists[^4]. The public keys will be added to the startup configuration for `admin` and `linuxadmin` users to enable passwordless access.
 
 ### NETCONF
 
@@ -477,7 +479,7 @@ The easiest way to enable SSSE3 instruction set is to configure the hypervisor t
 
 Or it's also possible via the proxmox configuration file `/etc/pve/qemu-server/vmid.conf`.
 
-[^1]: The `authorized_keys` file will be created with the content of all found public keys. This file will be bind-mounted using the respecting paths inside SR Linux to enable password-less access. Experimental feature.
-[^2]: If running with `sudo`, add `-E` flag to sudo to preserve user' home directory for this feature to work as expected.
+[^1]: Prior to SR Linux 22.11.1, the default credentials were `admin:admin`.
+[^2]: The `authorized_keys` file will be created with the content of all found public keys. This file will be bind-mounted using the respecting paths inside SR Linux to enable password-less access. Experimental feature.
 [^3]: CLI configs can be saved also in the "flat" format using `info flat` command.
-[^4]: Prior to SR Linux 22.11.1, the default credentials were `admin:admin`.
+[^4]: If running with `sudo`, add `-E` flag to sudo to preserve user' home directory for this feature to work as expected.

docs/manual/kinds/vr-sros.md

@@ -34,16 +34,25 @@ ssh admin@<container-name/id>
 ```
 
 ///
-/// tab | "NETCONF"
+/// tab | NETCONF
 NETCONF server is running over port 830
 
 ```bash
-ssh root@<container-name> -p 830 -s netconf
+ssh admin@<node-name> -p 830 -s netconf
+```
+
+or using [netconf-console2](https://github.com/hellt/netconf-console2-container) container:
+
+```bash
+docker run --rm --network clab -i -t \
+ghcr.io/hellt/netconf-console2:3.0.1 \
+--host <node-name> --port 830 -u admin -p 'admin' \
+--hello
 ```
 
 ///
-/// tab | "gNMI"
-using the best in class [gnmic](https://gnmic.kmrd.dev) gNMI client as an example:
+/// tab | gNMI
+using the best in class [gnmic](https://gnmic.openconfig.net) gNMI client as an example:
 
 ```bash
 gnmic -a <container-name/node-mgmt-address> --insecure \
@@ -52,7 +61,7 @@ capabilities
 ```
 
 ///
-/// tab | "Telnet"
+/// tab | Telnet
 serial port (console) is exposed over TCP port 5000:
 
 ```bash

docs/manual/kinds/vr-veos.md

@@ -34,7 +34,7 @@ Arista vEOS node launched with containerlab can be managed via the following int
     ssh admin@<container-name> -p 830 -s netconf
     ```
 === "gNMI"
-    using the best in class [gnmic](https://gnmic.kmrd.dev) gNMI client as an example:
+    using the best in class [gnmic](https://gnmic.openconfig.net/) gNMI client as an example:
     ```bash
     gnmic -a <container-name/node-mgmt-address>:6030 --insecure \
     -u admin -p admin \

docs/manual/kinds/vr-vmx.md

@@ -34,7 +34,7 @@ Juniper vMX node launched with containerlab can be managed via the following int
     ssh admin@<container-name> -p 830 -s netconf
     ```
 === "gNMI"
-    using the best in class [gnmic](https://gnmic.kmrd.dev) gNMI client as an example:
+    using the best in class [gnmic](https://gnmic.openconfig.net/) gNMI client as an example:
     ```bash
     gnmic -a <container-name/node-mgmt-address> --insecure \
     -u admin -p admin@123 \

docs/manual/kinds/vr-xrv.md

@@ -35,7 +35,7 @@ Cisco XRv node launched with containerlab can be managed via the following inter
     ssh clab@<container-name> -p 830 -s netconf
     ```
 === "gNMI"
-    using the best in class [gnmic](https://gnmic.kmrd.dev) gNMI client as an example:
+    using the best in class [gnmic](https://gnmic.openconfig.net/) gNMI client as an example:
     ```bash
     gnmic -a <container-name/node-mgmt-address> --insecure \
     -u clab -p clab@123 \

docs/manual/kinds/vr-xrv9k.md

@@ -48,7 +48,7 @@ Cisco XRv9k node launched with containerlab can be managed via the following int
     ssh clab@<container-name> -p 830 -s netconf
     ```
 === "gNMI"
-    using the best in class [gnmic](https://gnmic.kmrd.dev) gNMI client as an example:
+    using the best in class [gnmic](https://gnmic.openconfig.net/) gNMI client as an example:
     ```bash
     gnmic -a <container-name/node-mgmt-address> --insecure \
     -u clab -p clab@123 \