From b593b206cea9fe06ef247dd46909e4638840a86a Mon Sep 17 00:00:00 2001 From: Roman Dodin Date: Tue, 9 Jul 2024 16:41:17 +0200 Subject: [PATCH] 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 --- docs/manual/kinds/vr-cat9kv.md | 35 +++++++++++++++---- docs/manual/topo-def-file.md | 3 +- docs/manual/vrnetlab.md | 63 ++++++++++++++++++---------------- docs/rn/0.56.md | 46 +++++++++++++++++++++++++ mkdocs.yml | 1 + 5 files changed, 111 insertions(+), 37 deletions(-) create mode 100644 docs/rn/0.56.md diff --git a/docs/manual/kinds/vr-cat9kv.md b/docs/manual/kinds/vr-cat9kv.md index 836c90933..16d152a6f 100644 --- 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,7 +62,7 @@ ssh admin@ -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. @@ -66,12 +70,12 @@ The interface naming convention is: `GigabitEthernet1/0/X` (or `Gi1/0/X`), where 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 index 83cb94e13..0c7cc6673 100644 --- 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. - + 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. + /// 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 index 4cc45598c..abc0a9225 100644 --- 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 diff --git a/docs/rn/0.56.md b/docs/rn/0.56.md new file mode 100644 index 000000000..0986ad03e --- /dev/null +++ b/docs/rn/0.56.md @@ -0,0 +1,46 @@ +# Release 0.56 + +:material-calendar: 2024-07-09 ยท :material-list-status: [Full Changelog](https://github.com/srl-labs/containerlab/releases) + +## Interface aliases + +We know, it has been a long time coming, but thanks to a brilliant contribution done by [@vista-](https://github.com/vista-) in #2124 we now have added support for [interface aliases](../manual/topo-def-file.md#interface-naming). + +What are interface aliases you ask? They are a way to use interface names as you see them in the NOS CLI, rather than the default `ethX` naming scheme. It is a convenience feature, but, oh boy, how much easier is it to define links when you don't have to keep doing the mental gymnastics of mapping `eth0` to `Gi0/1` and so on. + +--8<-- "docs/manual/topo-def-file.md:aliases" + +Interface aliases will be also displayed in the [generated graph](../cmd/graph.md#html) and even in the [edgeshark](../manual/wireshark.md#edgeshark-integration) web view. + +/// tab | Graph +![pic1](https://gitlab.com/rdodin/pics/-/wikis/uploads/9ce9f8bd9ff7e4adfbe45c46712016b0/image.png){.img-shadow} +/// +/// tab | Edgeshark +![pic2](https://gitlab.com/rdodin/pics/-/wikis/uploads/3d4541b11a1b557967e419165aeb7ffd/image__2___1___1_.png){.img-shadow style=height:500px} +/// + +## Ostinato support + +We have added support for [Ostinato](https://ostinato.org/) traffic generator in containerlab. You can now define Ostinato nodes in your topology file and use them to generate traffic between your nodes. + +See the [Ostinato integration](../manual/kinds/ostinato.md) page for more details. + +## SONiC + +We have added support for the following new SONiC kinds: + +- [`sonic-vm`](../manual/kinds/sonic-vm.md) - is a VM-based upstream SONiC. You may want to pick sonic-vm over [sonic-vs](../manual/kinds/sonic-vs.md) if you hit some issues with the original sonic container #2120 +- [`dell_sonic`](../manual/kinds/dell_sonic.md) - is a SONiC distribution by Dell #2125 + +## Multi-arch `clab` container build + +To support the imminent release of ARM64 friendly Network OSes we fine tuned the release pipeline to make sure the `clab` container is built for both `amd64` and `arm64` architectures. #2128 + +## Cisco Catalyst 9000v + +Thanks to our strong community and @kaelemc in particular, we have added support for the [Cisco Catalyst 9000v](../manual/kinds/vr-cat9kv.md) switch. #2133 + +## Miscellaneous + +- Additions to the Developers Guide done by @pstavirs go about how to contribute to the documentation and how to build the documentation locally. #2109 +- Added more community posts in #2127 diff --git a/mkdocs.yml b/mkdocs.yml index 6fc1e802e..b8a1554f9 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -138,6 +138,7 @@ nav: - 5-stage Clos topology: lab-examples/templated02.md - Generic VM: lab-examples/generic_vm01.md - Release notes: + - "0.56": rn/0.56.md - "0.55": rn/0.55.md - "0.54": rn/0.54.md - "0.53": rn/0.53.md