Merge branch 'master' into newstructure

README.md

@@ -28,6 +28,8 @@ In addition to native containerized NOSes, containerlab can launch traditional v
 * [Nokia virtual SR OS (vSim/VSR)](https://containerlab.srlinux.dev/manual/kinds/vr-sros/)
 * [Juniper vMX](https://containerlab.srlinux.dev/manual/kinds/vr-vmx/)
 * [Cisco IOS XRv9k](https://containerlab.srlinux.dev/manual/kinds/vr-xrv9k/)
+* [Cisco Nexus 9000v](https://containerlab.srlinux.dev/manual/kinds/vr-n9kv)
+* [Cisco CSR 1000v](https://containerlab.srlinux.dev/manual/kinds/vr-csr)
 * [Arista vEOS](https://containerlab.srlinux.dev/manual/kinds/vr-veos)
 * [Palo Alto PAN](https://containerlab.srlinux.dev/manual/kinds/vr-pan)
 

clab/clab.go

@@ -120,7 +120,10 @@ func NewContainerLab(opts ...ClabOption) (*CLab, error) {
 		o(c)
 	}
 
-	err := c.parseTopology()
+	var err error
+	if c.TopoFile.path != "" {
+		err = c.parseTopology()
+	}
 
 	return c, err
 }

clab/config.go

@@ -46,6 +46,7 @@ var kinds = []string{
 	"ceos",
 	"crpd",
 	"sonic-vs",
+	"vr-n9kv",
 	"vr-sros",
 	"vr-vmx",
 	"vr-xrv",
@@ -572,7 +573,16 @@ func resolveBindPaths(binds []string, nodedir string) error {
 
 		_, err = os.Stat(hp)
 		if err != nil {
-			return fmt.Errorf("failed to verify bind path: %v", err)
+			// check if the hostpath mount has a reference to ansible-inventory.yml
+			// if that is the case, we do not emit an error on missing file, since this file
+			// will be created by containerlab upon lab deployment
+			labdir := filepath.Base(filepath.Dir(nodedir))
+			s := strings.Split(hp, string(os.PathSeparator))
+			// creating a path from last two elements of a resolved host path
+			h := path.Join(s[len(s)-2], s[len(s)-1])
+			if h != path.Join(labdir, "ansible-inventory.yml") {
+				return fmt.Errorf("failed to verify bind path: %v", err)
+			}
 		}
 		elems[0] = hp
 		binds[i] = strings.Join(elems, ":")

clab/config_test.go

@@ -159,7 +159,7 @@ func TestTypeInit(t *testing.T) {
 		"undefined_type_returns_default": {
 			got:  "test_data/topo1.yml",
 			node: "node2",
-			want: "ixr6",
+			want: "ixrd2",
 		},
 		"node_type_override_kind_type": {
 			got:  "test_data/topo2.yml",
@@ -369,7 +369,7 @@ func TestLabelsInit(t *testing.T) {
 				"containerlab":      "topo1",
 				"clab-node-name":    "node2",
 				"clab-node-kind":    "srl",
-				"clab-node-type":    "ixr6",
+				"clab-node-type":    "ixrd2",
 				"clab-node-group":   "",
 				"clab-node-lab-dir": "./clab-topo1/node2",
 				"clab-topo-file":    "./test_data/topo1.yml",

cmd/config.go

@@ -26,7 +26,6 @@ var configCmd = &cobra.Command{
 	ValidArgs:    []string{"commit", "send", "compare", "template"},
 	SilenceUsage: true,
 	RunE:         configRun,
-}
 
 var configSendCmd = &cobra.Command{
 	Use:          "send",

cmd/deploy.go

@@ -8,6 +8,7 @@ import (
 	"context"
 	"net"
 	"os"
+	"path/filepath"
 	"strings"
 	"sync"
 
@@ -93,6 +94,14 @@ var deployCmd = &cobra.Command{
 		log.Info("Creating lab directory: ", c.Dir.Lab)
 		utils.CreateDirectory(c.Dir.Lab, 0755)
 
+		// create an empty ansible inventory file that will get populated later
+		// we create it here first, so that bind mounts of ansible-inventory.yml file could work
+		ansibleInvFPath := filepath.Join(c.Dir.Lab, "ansible-inventory.yml")
+		_, err = os.Create(ansibleInvFPath)
+		if err != nil {
+			return err
+		}
+
 		cfssllog.Level = cfssllog.LevelError
 		if debug {
 			cfssllog.Level = cfssllog.LevelDebug

cmd/generate.go

@@ -34,7 +34,7 @@ var interfaceFormat = map[string]string{
 var supportedKinds = []string{"srl", "ceos", "linux", "bridge", "sonic-vs", "crpd", "vr-sros", "vr-vmx", "vr-xrv9k"}
 
 const (
-	defaultSRLType     = "ixr6"
+	defaultSRLType     = "ixrd2"
 	defaultNodePrefix  = "node"
 	defaultGroupPrefix = "tier"
 )

cmd/generate_test.go

@@ -127,9 +127,9 @@ var nodesTestSet = map[string]struct {
 		},
 		out: nodesOutput{
 			out: []nodesDef{
-				{numNodes: 1, kind: "srl", typ: "ixr6"},
-				{numNodes: 2, kind: "srl", typ: "ixr6"},
-				{numNodes: 3, kind: "srl", typ: "ixr6"},
+				{numNodes: 1, kind: "srl", typ: "ixrd2"},
+				{numNodes: 2, kind: "srl", typ: "ixrd2"},
+				{numNodes: 3, kind: "srl", typ: "ixrd2"},
 			},
 			err: nil,
 		},
@@ -142,7 +142,7 @@ var nodesTestSet = map[string]struct {
 		out: nodesOutput{
 			out: []nodesDef{
 				{numNodes: 1, kind: "linux", typ: ""},
-				{numNodes: 2, kind: "srl", typ: "ixr6"},
+				{numNodes: 2, kind: "srl", typ: "ixrd2"},
 				{numNodes: 3, kind: "ceos", typ: ""},
 			},
 			err: nil,
@@ -156,7 +156,7 @@ var nodesTestSet = map[string]struct {
 		out: nodesOutput{
 			out: []nodesDef{
 				{numNodes: 1, kind: "srl", typ: "ixrd"},
-				{numNodes: 2, kind: "srl", typ: "ixr6"},
+				{numNodes: 2, kind: "srl", typ: "ixrd2"},
 				{numNodes: 3, kind: "ceos", typ: ""},
 			},
 			err: nil,
@@ -169,7 +169,7 @@ var nodesTestSet = map[string]struct {
 		},
 		out: nodesOutput{
 			out: []nodesDef{
-				{numNodes: 2, kind: "srl", typ: "ixr6"},
+				{numNodes: 2, kind: "srl", typ: "ixrd2"},
 			},
 			err: nil,
 		},

docs/community.md

@@ -0,0 +1,7 @@
+Containerlab openness and focus on multivendor labs was a key to its success and adoption. With more than a dozen Network Operating Systems spread across several networking vendors and opensource teams it became a tool that can answer the needs of a wide network engineers community.
+
+Growing the number of supported NOSes is a task that can't be done by a single person, and there the community role is adamant. To support and cherish the growing containerlab community and provide a better feedback and discussions platform we launched a containerlab's own Discord server.
+
+Everybody is welcome to join and chat to our community members about all things containerlab!
+
+<center>[:fontawesome-brands-discord: Join Containerlab Discord Server](https://discord.gg/vAyddtaEV9){ .md-button .md-button--primary }</center>

docs/index.md

@@ -26,6 +26,8 @@ In addition to native containerized NOSes, containerlab can launch traditional v
 * [Nokia virtual SR OS (vSim/VSR)](manual/kinds/vr-sros.md)
 * [Juniper vMX](manual/kinds/vr-vmx.md)
 * [Cisco IOS XRv9k](manual/kinds/vr-xrv9k.md)
+* [Cisco Nexus 9000v](manual/kinds/vr-n9kv.md)
+* [Cisco CSR 1000v](manual/kinds/vr-csr.md)
 * [Arista vEOS](manual/kinds/vr-veos.md)
 * [Palo Alto PAN](manual/kinds/vr-pan.md)
 

docs/manual/kinds/srl.md

@@ -38,11 +38,11 @@ For SR Linux nodes [`type`](../nodes.md#type) defines the hardware variant that
 
 The available type values are: `ixr6`, `ixr10`, `ixrd1`, `ixrd2`, `ixrd3` which correspond to a hardware variant of Nokia 7250/7220 IXR chassis.
 
-By default, `ixr6` type will be used by containerlab.
+By default, `ixrd2` type will be used by containerlab.
 
-Based on the provided type, containerlab will generate the [topology file](#topology-file) that will be mounted to SR Linux container and make it boot in a chosen HW variant.
+Based on the provided type, containerlab will generate the topology file that will be mounted to SR Linux container and make it boot in a chosen HW variant.
 ### Node configuration
-SR Linux nodes have a dedicated [`config`](#config-directory) directory that is used to persist the configuration of the node. It is possible to launch nodes of `srl` kind with a basic "empty" config or to provide a custom config file that will be used as a startup config instead.
+SR Linux nodes have a `config.json` file that is used to persist the configuration of the node. It is possible to launch nodes of `srl` kind with a basic "default" config or to provide a custom config file that will be used as a startup config instead.
 #### Default node configuration
 When a node is defined without `config` statement present, containerlab will generate an empty config from [this template](https://github.com/srl-labs/containerlab/blob/master/nodes/srl/srl.cfg) and put it in that directory.
 
@@ -71,7 +71,7 @@ topology:
       kind: srl
       type: ixr6
       image: ghcr.io/nokia/srlinux
-      config: myconfig.json
+      startup-config: myconfig.json
 ```
 
 With such topology file containerlab is instructed to take a file `myconfig.json` from the current working directory, copy it to the lab directory for that specific node under the `config.json` name and mount that file to the container. This will result in this config to act as a startup config for the node.
@@ -133,24 +133,15 @@ To start an SR Linux NOS containerlab uses the configuration that is described i
     `SRLINUX=1`
 
 ### File mounts
-#### Config directory
 When a user starts a lab, containerlab creates a lab directory for storing [configuration artifacts](../conf-artifacts.md). For `srl` kind containerlab creates directories for each node of that kind.
 
 ```
 ~/clab/clab-srl02
 ❯ ls -lah srl1
-drwxrwxrwx+ 6 1002 1002   87 Dec  1 22:11 config
--rw-r--r--  1 root root 2.8K Dec  1 22:11 license.key
--rw-r--r--  1 root root 4.4K Dec  1 22:11 srlinux.conf
--rw-r--r--  1 root root  233 Dec  1 22:11 topology.clab.yml
+-rwxrwxrwx+ 1 1002 1002 36169 Aug  2 17:31 config.json
+-rw-r--r--  1 root root  233 Dec  1 22:11 topology.yml
 ```
 
-The `config` directory is mounted to container's `/etc/opt/srlinux/` in `rw` mode and will effectively contain configuration that SR Linux runs of as well as the files that SR Linux keeps in its `/etc/opt/srlinux/` directory:
+The `config.json` file is mounted to container's `/etc/opt/srlinux/config.json` in `rw` mode and will effectively contain the node's configuration that SR Linux runs:
 
-```
-❯ ls srl1/config
-banner  cli  config.json  devices  tls  ztp
-```
-
-#### Topology file
 The topology file that defines the emulated hardware type is driven by the value of the kinds `type` parameter. Depending on a specified `type` the appropriate content will be populated into the `topology.yml` file that will get mounted to `/tmp/topology.yml` directory inside the container in `ro` mode.

docs/manual/kinds/vr-n9kv.md

@@ -0,0 +1,50 @@
+# Cisco Nexus 9000v
+
+Cisco Nexus900v virtualized router is identified with `vr-n9kv` kind in the [topology file](../topo-def-file.md). It is built using [vrnetlab](../vrnetlab.md) project and essentially is a Qemu VM packaged in a docker container format.
+
+vr-n9kv nodes launched with containerlab comes up pre-provisioned with SSH, SNMP, NETCONF, NXAPI and gRPC services enabled.
+
+## Managing vr-n9kv nodes
+
+!!!note
+    Containers with Nexus 9000v inside will take ~8-10min to fully boot.  
+    You can monitor the progress with `docker logs -f <container-name>`.
+
+Cisco Nexus 9000v node launched with containerlab can be managed via the following interfaces:
+
+=== "bash"
+    to connect to a `bash` shell of a running vr-n9kv container:
+    ```bash
+    docker exec -it <container-name/id> bash
+    ```
+=== "CLI"
+    to connect to the Nexus 9000v CLI
+    ```bash
+    ssh admin@<container-name/id>
+    ```
+=== "NETCONF"
+    NETCONF server is running over port 830
+    ```bash
+    ssh admin@<container-name> -p 830 -s netconf
+    ```
+=== "gRPC"
+    gRPC server is running over port 50051
+
+!!!info
+    Default user credentials: `admin:admin`
+
+## Interfaces mapping
+vr-n9kv container can have up to 128 interfaces and uses the following mapping rules:
+
+* `eth0` - management interface connected to the containerlab management network
+* `eth1` - first data interface, mapped to first data port of Nexus 9000v line card
+* `eth2+` - second and subsequent data interface
+
+When containerlab launches vr-n9kv node, it will assign IPv4/6 address to the `eth0` interface. These addresses can be used to reach management plane of the router.
+
+Data interfaces `eth1+` needs to be configured with IP addressing manually using CLI/management protocols.
+
+
+## Features and options
+### Node configuration
+vr-n9kv nodes come up with a basic configuration where only `admin` user and management interfaces such as NETCONF, NXAPI and GRPC provisioned.

docs/manual/kinds/vr-nxos.md

@@ -0,0 +1,43 @@
+# Cisco NXOS
+
+[Cisco NXOS](https://www.cisco.com/c/en/us/products/ios-nx-os-software/nx-os/index.html) virtual appliance is identified with `vr-nxos` kind in the [topology file](../topo-def-file.md). It is built using [hellt/vrnetlab](../vrnetlab.md) project and essentially is a Qemu VM packaged in a docker container format.
+
+!!!note
+    This is a Titanium based system, which is an older version of NX-OS.
+
+vr-nxos nodes launched with containerlab come up pre-provisioned with SSH service enabled.
+
+## Managing vr-nxos nodes
+Cisco NXOS node launched with containerlab can be managed via the following interfaces:
+
+=== "bash"
+    to connect to a `bash` shell of a running vr-nxos container:
+    ```bash
+    docker exec -it <container-name/id> bash
+    ```
+=== "CLI via SSH"
+    to connect to the NX-OS CLI
+    ```bash
+    ssh clab@<container-name/id>
+    ```
+
+
+!!!info
+    Default user credentials: `admin:admin`
+
+## Interfaces mapping
+vr-nxos container can have up to 90 interfaces and uses the following mapping rules:
+
+* `eth0` - management interface connected to the containerlab management network
+* `eth1` - first data interface, mapped to first data port of NX-OS line card
+* `eth2+` - second and subsequent data interface
+
+When containerlab launches vr-nxos node, it will assign IPv4/6 address to the `eth0` interface. These addresses can be used to reach management plane of the router.
+
+Data interfaces `eth1+` needs to be configured with IP addressing manually using CLI/management protocols.
+
+
+## Features and options
+### Node configuration
+vr-nxos nodes come up with a basic configuration where only the control plane and line cards are provisioned, as well as the `clab` user.
+

docs/manual/kinds/vr-xrv9k.md

@@ -58,5 +58,3 @@ The following labs feature vr-xrv9k node:
 
 - [SR Linux and Cisco XRv9k](../../lab-examples/vr-xrv9k.md)
 
-## Known issues and limitations
-* LACP and BPDU packets are not propagated to/from vrnetlab based routers launched with containerlab.

docs/manual/vrnetlab.md

@@ -33,8 +33,9 @@ The following table provides a link between the version combinations that were v
 | --               | [`0.2.2`](https://github.com/hellt/vrnetlab/tree/v0.2.2)       | fixed serial (telnet) access to SR OS nodes                                                                                                              |
 | --               | [`0.2.3`](https://github.com/hellt/vrnetlab/tree/v0.2.3)       | set default cpu/ram for SR OS images                                                                                                                     |
 | `0.13.0`         | [`0.3.0`](https://github.com/hellt/vrnetlab/tree/v0.3.0)       | added support for Cisco CSR1000v via [`vr-csr`](kinds/vr-csr.md) and MikroTik routeros via [`vr-ros`](kinds/vr-ros.md) kind                              |
-|                  | [`0.3.1`](https://github.com/hellt/vrnetlab/tree/v0.3.1)       | enhanced SR OS boot sequence                                                                                                                             |
-| `0.15.5`         | [`0.4.0`](https://github.com/hellt/vrnetlab/tree/v0.4.0)       | fixed SR OS CPU allocation and added Palo Alto PAN support [`vr-pan`](kinds/vr-pan.md)                                                                   |
+| --               | [`0.3.1`](https://github.com/hellt/vrnetlab/tree/v0.3.1)       | enhanced SR OS boot sequence                                                                                                                             |
+| --               | [`0.4.0`](https://github.com/hellt/vrnetlab/tree/v0.4.0)       | fixed SR OS CPU allocation and added Palo Alto PAN support [`vr-pan`](kinds/vr-pan.md)                                                                   |
+| `0.16.0`         | [`0.5.0`](https://github.com/hellt/vrnetlab/tree/v0.5.0)       | added support for Cisco Nexus 9000v via [`vr-n9kv`](kinds/vr-n9kv.md) kind, added support for non-continuous interfaces provisioning                     |
 
 ### Building vrnetlab images
 To build a vrnetlab image compatible with containerlab users first need to ensure that the versions of both projects follow [compatibility matrix](#compatibility-matrix).
@@ -67,6 +68,8 @@ The images that work with containerlab will appear in the supported list gradual
 | Arista vEOS       | [vr-veos](kinds/vr-veos.md)   |                                            |                                                                                                                                                                                                              |
 | MikroTik RouterOS | [vr-ros](kinds/vr-ros.md)     |                                            |                                                                                                                                                                                                              |
 | Palo Alto PAN     | [vr-pan](kinds/vr-pan.md)     |                                            |                                                                                                                                                                                                              |
+| Cisco Nexus 9000v | [vr-n9kv](kinds/vr-n9kv.md)   |                                            |                                                                                                                                                                                                              |
+
 
 ### Connection modes
 Containerlab offers several ways VM based routers can be connected with the rest of the docker workloads. By default, vrnetlab integrated routers will use **tc** backend[^2] which doesn't require any additional packages to be installed on the container host and supports transparent passage of LACP frames.