added 0.56 release notes (#2134)

* added 0.56 release notes * added vrnetlab 0.18 release * added a note about interfaces status for cat9kv * added a note about tuning cpu/mem for a node * adressing review comments * more phrasing fixes * adding a link to vrnetlab readme * router -> switch
srl-labs · Jul 9, 2024 · b593b20 · b593b20
1 parent f0d39b3
commit b593b20
Show file tree

Hide file tree

Showing 5 changed files with 111 additions and 37 deletions.
diff --git a/docs/manual/kinds/vr-cat9kv.md b/docs/manual/kinds/vr-cat9kv.md
@@ -7,7 +7,7 @@ kind_short_display_name: Cat9kv
 ---
 # Cisco Catalyst 9000v
 
-The [[[ kind_display_name ]]] (or [[[ kind_short_display_name ]]] for short) is a virtualised form of the Cisco Catalyst 9000 series switches. It is identified with `[[[ kind_code_name ]]]` 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.
+The [[[ kind_display_name ]]] (or [[[ kind_short_display_name ]]] for short) is a virtualised form of the Cisco Catalyst 9000 series switches. It is identified with `[[[ kind_code_name ]]]` kind in the [topology file](../topo-def-file.md) and built using [vrnetlab](../vrnetlab.md) project and essentially is a Qemu VM packaged in a docker container format.
 
 The [[[ kind_display_name ]]] performs simulation of the dataplane ASICs that are present in the physical hardware. The two simulated ASICs are:
 
@@ -20,12 +20,16 @@ The Q200 simulation has a limited featureset compared to the UADP simulation.
 
 ## Resource requirements
 
+The [[[ kind_display_name ]]] is a resource-hungry VM. When launched with the default settings, it requires the following resources:
+
 |           | UADP  | Q200  |
 | --------- | ----- | ----- |
 | vCPU      | 4     | 4     |
 | RAM (MB)  | 18432 | 12288 |
 | Disk (GB) | 4     | 4     |
 
+Users can adjust the CPU and memory resources by setting adding appropriate environment variables as explained in [Tuning Qemu Parameters section](../../manual/vrnetlab.md#tuning-qemu-parameters).
+
 ## Managing [[[ kind_display_name ]]] nodes
 
 You can manage the [[[ kind_display_name ]]] with containerlab via the following interfaces:
@@ -58,20 +62,20 @@ ssh admin@<container-name> -p 830 -s netconf
 Default credentials: `admin:admin`
 ///
 
-## Interface naming convention
+## Interface naming
 
 You can use [interfaces names](../topo-def-file.md#interface-naming) in the topology file like they appear in the [[[ kind_display_name ]]] CLI.
 
 The interface naming convention is: `GigabitEthernet1/0/X` (or `Gi1/0/X`), where `X` is the port number.
 
 With that naming convention in mind:
 
-* `Gi1/0/1` - first data port available
-* `Gi1/0/2` - second data port, and so on...
+- `Gi1/0/1` - first data port available
+- `Gi1/0/2` - second data port, and so on...
 
 The example ports above would be mapped to the following Linux interfaces inside the container running the [[[ kind_display_name ]]] VM:
 
-- `eth0` - management interface connected to the containerlab management network.
+- `eth0` - management interface connected to the containerlab management network. Mapped to `GigabitEthernet0/0`.
 - `eth1` - First data-plane interface. Mapped to `GigabitEthernet1/0/1` interface.
 - `eth2` - Second data-plane interface. Mapped to `GigabitEthernet1/0/2` interface and so on.
 
@@ -103,13 +107,32 @@ topology:
 Regardless of how many links are defined in your containerlab topology, the Catalyst 9000v will always display 8 data-plane interfaces. Links/interfaces that you did not define in your containerlab topology will *not* pass any traffic.
 ///
 
+When containerlab launches [[[ kind_display_name ]]] node the `GigabitEthernet0/0` interface of the VM gets assigned `10.0.0.15/24` address from the QEMU DHCP server. This interface is transparently stitched with container's `eth0` interface such that users can reach the management plane of the [[[ kind_display_name ]]] using containerlab's assigned IP.
+
+Data interfaces `GigabitEthernet1/0/1+` need to be configured with IP addressing manually using CLI or other available management interfaces and will appear `unset` in the CLI:
+
+```
+c9kv(config-if)#do sh ip in br
+Interface              IP-Address      OK? Method Status                Protocol
+Vlan1                  unassigned      YES unset  administratively down down    
+GigabitEthernet0/0     10.0.0.15       YES manual up                    up      
+GigabitEthernet1/0/1   unassigned      YES unset  up                    up      
+GigabitEthernet1/0/2   unassigned      YES unset  up                    up      
+GigabitEthernet1/0/3   unassigned      YES unset  up                    up      
+GigabitEthernet1/0/4   unassigned      YES unset  up                    up      
+GigabitEthernet1/0/5   unassigned      YES unset  up                    up      
+GigabitEthernet1/0/6   unassigned      YES unset  up                    up      
+GigabitEthernet1/0/7   unassigned      YES unset  up                    up      
+GigabitEthernet1/0/8   unassigned      YES unset  up                    up
+```
+
 ## Features and options
 
 ### ASIC data-plane simulation configuration
 
 The default ASIC simulation of the node will be UADP. To enable the Q200 simulation or to enable specific features for the UADP simulation, you must provide a `vswitch.xml` file (with the relevant configuration).
 
-You can do this when building the image with [vrnetlab](../vrnetlab.md), Please refer to the README file in vrnetlab/cat9kv for more information.
+You can do this when building the image with [vrnetlab](../vrnetlab.md), Please refer to the README file in [vrnetlab/cat9kv](https://github.com/hellt/vrnetlab/blob/master/cat9kv/README.md) for more information.
 
 You can also use supply the vswitch.xml file via `binds` in the containerlab topology file. Refer to the example below.
 

diff --git a/docs/manual/topo-def-file.md b/docs/manual/topo-def-file.md
@@ -156,7 +156,7 @@ topology:
 ###### Aliases
 
 The downside of using Linux interface names is that they often do not match the interface naming convention used by the Network OS. This is where Interface Aliases feature (added in Containerlab v0.56.0) comes in handy.
-
+<!-- --8<-- [start:aliases] -->
 Imagine we want to create a lab with four different Kinds: SR Linux, vEOS, CSR1000v and vSRX, cabled like this:
 
 |                A side | B side           |
@@ -197,6 +197,7 @@ Both topology definitions result in the same lab being deployed, but the latter
 Many [Kinds](../manual/kinds/index.md) (but not all) support interface aliases and the alias names are provided in the respective kind' documentation.
 
 Containerlab transparently maps from interface aliases to Linux interface names, and there's no additional syntax or configuration needed to specify either an interface alias or a Linux interface name in topologies.
+<!-- --8<-- [end:aliases] -->
 
 /// details | How do aliases work?
 Internally, interface aliases end up being deterministically mapped to Linux interface names, which conform to Linux interface naming standards: at most 15 characters, spaces and forward slashes (`/`) not permitted.

diff --git a/docs/manual/vrnetlab.md b/docs/manual/vrnetlab.md
@@ -29,36 +29,39 @@ Containerlab depends on `hellt/vrnetlab` project, and sometimes features added i
 
 The following table provides a link between the version combinations:
 
-| containerlab[^3] | vrnetlab[^4]                                                       | Notes                                                                                                                                                                |
-| ---------------- | ------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `0.10.4`         | [`0.1.0-cl`](https://github.com/hellt/vrnetlab/tree/v0.1.0-cl)     | Initial release. Images: sros, vmx, xrv, xrv9k                                                                                                                       |
-| `0.11.0`         | [`0.2.0`](https://github.com/hellt/vrnetlab/tree/v0.2.0)           | added [vr-veos](kinds/vr-veos.md), support for [boot-delay](#boot-delay), SR OS will have a static route to docker network, improved XRv startup chances             |
-|                  | [`0.2.1`](https://github.com/hellt/vrnetlab/tree/v0.2.1)           | added timeout for SR OS images to allow eth interfaces to appear in the container namespace. Other images are not touched.                                           |
-|                  | [`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 [`cisco_csr`](kinds/vr-csr.md) and MikroTik routeros via [`mikrotik_ros`](kinds/vr-ros.md) kind                                 |
-|                  | [`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 [`paloaltp_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 [`cisco_n9kv`](kinds/vr-n9kv.md) kind, added support for non-continuous interfaces provisioning                              |
-| `0.19.0`         | [`0.6.0`](https://github.com/hellt/vrnetlab/tree/v0.6.0)           | added experimental support for Juniper vQFX via [`juniper_vqfx`](kinds/vr-vqfx.md) kind, added support Dell FTOS via [`dell_ftosv`](kinds/vr-ftosv.md)               |
-|                  | [`0.6.2`](https://github.com/hellt/vrnetlab/tree/v0.6.2)           | support for IPv6 management for SR OS; support for RouterOS v7+                                                                                                      |
-|                  | [`0.7.0`](https://github.com/hellt/vrnetlab/tree/v0.7.0)           | startup-config support for vqfx and vmx                                                                                                                              |
-| `0.32.2`         | [`0.8.0`](https://github.com/hellt/vrnetlab/releases/tag/v0.8.0)   | startup-config support for the rest of the kinds, support for multi line card SR OS                                                                                  |
-| `0.34.0`         | [`0.8.2`](https://github.com/hellt/vrnetlab/releases/tag/v0.8.2)   | startup-config support for PANOS, ISA support for Nokia VSR-I and MGMT VRF for VMX                                                                                   |
-|                  | [`0.9.0`](https://github.com/hellt/vrnetlab/releases/tag/v0.9.0)   | Support for IPInfusion OcNOS with vrnetlab                                                                                                                           |
-| `0.41.0`         | [`0.11.0`](https://github.com/hellt/vrnetlab/releases/tag/v0.11.0) | Added support for Juniper vSRX3.0 via [`juniper_vsrx`](kinds/vr-vsrx.md) kind                                                                                        |
-| `0.45.0`         | [`0.12.0`](https://github.com/hellt/vrnetlab/releases/tag/v0.12.0) | Added support for Juniper vJunos-switch via [`juniper_vjunosswitch`](kinds/vr-vjunosswitch.md) kind                                                                  |
-| `0.49.0`         | [`0.14.0`](https://github.com/hellt/vrnetlab/releases/tag/v0.14.0) | Added support for [Juniper vJunos-Evolved](kinds/vr-vjunosevolved.md), [Cisco FTDv](kinds/vr-ftdv.md), [OpenBSD](kinds/openbsd.md)                                   |
-| `0.53.0`         | [`0.15.0`](https://github.com/hellt/vrnetlab/releases/tag/v0.15.0) | Added support for [Fortigate](kinds/fortinet_fortigate.md), [freebsd](kinds/freebsd.md), added lots of FP5 types to Nokia SR OS and support for external cf1/2 disks |
-| `0.54.0`         | [`0.16.0`](https://github.com/hellt/vrnetlab/releases/tag/v0.16.0) | Added support for [Cisco c8000v](kinds/c8000.md)                                                                                                                     |
-| `0.55.0`         | [`0.17.0`](https://github.com/hellt/vrnetlab/releases/tag/v0.17.0) | Added support for [Juniper vJunos-router](kinds/vr-vjunosrouter.md), [Generic VM](kinds/generic_vm.md), support for setting qemu parameters via env vars nodes       |
-
-???note "how to understand version inter-dependency between containerlab and vrnetlab?"
-    When new VM-based platform support is added to vrnetlab, it is usually accompanied by a new containerlab version. In this case the table row will have both containerlab and vrnetlab versions.  
-    When vrnetlab adds new features that don't require containerlab changes, the table will have only vrnetlab version.  
-    When containerlab adds new features that don't require vrnetlab changes, the table will not list containerlab version.
-
-    It is worth noting, that you can use the latest containerlab version with a given vrnetlab version, even if the table doesn't list the latest containerlab version.
+| containerlab[^3] | vrnetlab[^4]                                                       | Notes                                                                                                                                                                  |
+| ---------------- | ------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `0.10.4`         | [`0.1.0-cl`](https://github.com/hellt/vrnetlab/tree/v0.1.0-cl)     | Initial release. Images: sros, vmx, xrv, xrv9k                                                                                                                         |
+| `0.11.0`         | [`0.2.0`](https://github.com/hellt/vrnetlab/tree/v0.2.0)           | added [vr-veos](kinds/vr-veos.md), support for [boot-delay](#boot-delay), SR OS will have a static route to docker network, improved XRv startup chances               |
+|                  | [`0.2.1`](https://github.com/hellt/vrnetlab/tree/v0.2.1)           | added timeout for SR OS images to allow eth interfaces to appear in the container namespace. Other images are not touched.                                             |
+|                  | [`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 [`cisco_csr`](kinds/vr-csr.md) and MikroTik routeros via [`mikrotik_ros`](kinds/vr-ros.md) kind                                   |
+|                  | [`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 [`paloaltp_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 [`cisco_n9kv`](kinds/vr-n9kv.md) kind, added support for non-continuous interfaces provisioning                                |
+| `0.19.0`         | [`0.6.0`](https://github.com/hellt/vrnetlab/tree/v0.6.0)           | added experimental support for Juniper vQFX via [`juniper_vqfx`](kinds/vr-vqfx.md) kind, added support Dell FTOS via [`dell_ftosv`](kinds/vr-ftosv.md)                 |
+|                  | [`0.6.2`](https://github.com/hellt/vrnetlab/tree/v0.6.2)           | support for IPv6 management for SR OS; support for RouterOS v7+                                                                                                        |
+|                  | [`0.7.0`](https://github.com/hellt/vrnetlab/tree/v0.7.0)           | startup-config support for vqfx and vmx                                                                                                                                |
+| `0.32.2`         | [`0.8.0`](https://github.com/hellt/vrnetlab/releases/tag/v0.8.0)   | startup-config support for the rest of the kinds, support for multi line card SR OS                                                                                    |
+| `0.34.0`         | [`0.8.2`](https://github.com/hellt/vrnetlab/releases/tag/v0.8.2)   | startup-config support for PANOS, ISA support for Nokia VSR-I and MGMT VRF for VMX                                                                                     |
+|                  | [`0.9.0`](https://github.com/hellt/vrnetlab/releases/tag/v0.9.0)   | Support for IPInfusion OcNOS with vrnetlab                                                                                                                             |
+| `0.41.0`         | [`0.11.0`](https://github.com/hellt/vrnetlab/releases/tag/v0.11.0) | Added support for Juniper vSRX3.0 via [`juniper_vsrx`](kinds/vr-vsrx.md) kind                                                                                          |
+| `0.45.0`         | [`0.12.0`](https://github.com/hellt/vrnetlab/releases/tag/v0.12.0) | Added support for Juniper vJunos-switch via [`juniper_vjunosswitch`](kinds/vr-vjunosswitch.md) kind                                                                    |
+| `0.49.0`         | [`0.14.0`](https://github.com/hellt/vrnetlab/releases/tag/v0.14.0) | Added support for [Juniper vJunos-Evolved](kinds/vr-vjunosevolved.md), [Cisco FTDv](kinds/vr-ftdv.md), [OpenBSD](kinds/openbsd.md)                                     |
+| `0.53.0`         | [`0.15.0`](https://github.com/hellt/vrnetlab/releases/tag/v0.15.0) | Added support for [Fortigate](kinds/fortinet_fortigate.md), [freebsd](kinds/freebsd.md), added lots of FP5 types to Nokia SR OS and support for external cf1/2 disks   |
+| `0.54.0`         | [`0.16.0`](https://github.com/hellt/vrnetlab/releases/tag/v0.16.0) | Added support for [Cisco c8000v](kinds/c8000.md)                                                                                                                       |
+| `0.55.0`         | [`0.17.0`](https://github.com/hellt/vrnetlab/releases/tag/v0.17.0) | Added support for [Juniper vJunos-router](kinds/vr-vjunosrouter.md), [Generic VM](kinds/generic_vm.md), support for setting qemu parameters via env vars for the nodes |
+| `0.56.0`         | [`0.18.1`](https://github.com/hellt/vrnetlab/releases/tag/v0.18.1) | Added support for [Dell SONiC](kinds/dell_sonic.md), [SONiC VM](kinds/sonic-vm.md), [Cisco Catalyst 9000v](kinds/vr-cat9kv.md)                                         |
+
+/// details | how to understand version inter-dependency between containerlab and vrnetlab?
+    type: note
+When new VM-based platform support is added to vrnetlab, it is usually accompanied by a new containerlab version. In this case the table row will have both containerlab and vrnetlab versions.  
+When vrnetlab adds new features that don't require containerlab changes, the table will have only vrnetlab version.  
+When containerlab adds new features that don't require vrnetlab changes, the table will not list containerlab version.
+
+It is worth noting, that you can use the latest containerlab version with a given vrnetlab version, even if the table doesn't list the latest containerlab version.
+///
 
 ### Building vrnetlab images