Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

added 0.56 release notes #2134

Merged
merged 8 commits into from
Jul 9, 2024
Merged
Show file tree
Hide file tree
Changes from 5 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 27 additions & 4 deletions docs/manual/kinds/vr-cat9kv.md
hellt marked this conversation as resolved.
Show resolved Hide resolved
Original file line number Diff line number Diff line change
Expand Up @@ -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:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

May be worth specifying by default is requires the UADPs minimum resources. The table just shows the recommended resources for each ASIC simulation. Q200 will use UADP's 4vCPU and 18432M RAM unless the user overwrites this.


| | 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:
Expand Down Expand Up @@ -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.

Expand Down Expand Up @@ -103,6 +107,25 @@ 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
Expand Down
3 changes: 2 additions & 1 deletion docs/manual/topo-def-file.md
Original file line number Diff line number Diff line change
Expand Up @@ -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 |
Expand Down Expand Up @@ -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.
Expand Down
63 changes: 33 additions & 30 deletions docs/manual/vrnetlab.md
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down
Loading