Skip to content

Commit

Permalink
added more docs
Browse files Browse the repository at this point in the history
  • Loading branch information
@hellt
hellt committed Jul 27, 2021
1 parent c6021eb commit 5b74b0c
Show file tree
Hide file tree
Showing 3 changed files with 6 additions and 2 deletions.
1 change: 1 addition & 0 deletions README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -29,6 +29,7 @@ In addition to native containerized NOSes, containerlab can launch traditional v
* [Juniper vMX](https://containerlab.srlinux.dev/manual/kinds/vr-vmx/)
* [Cisco IOS XRv9k](https://containerlab.srlinux.dev/manual/kinds/vr-xrv9k/)
* [Arista vEOS](https://containerlab.srlinux.dev/manual/kinds/vr-veos)
* [Palo Alto PAN](https://containerlab.srlinux.dev/manual/kinds/vr-pan)

And, of course, containerlab is perfectly capable of wiring up arbitrary linux containers which can host your network applications, virtual functions or simply be a test client. With all that, containerlab provides a single IaaC interface to manage labs which can span contain all the needed variants of nodes:

Expand Down
1 change: 1 addition & 0 deletions docs/index.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -27,6 +27,7 @@ In addition to native containerized NOSes, containerlab can launch traditional v
* [Juniper vMX](manual/kinds/vr-vmx.md)
* [Cisco IOS XRv9k](manual/kinds/vr-xrv9k.md)
* [Arista vEOS](manual/kinds/vr-veos.md)
* [Palo Alto PAN](manual/kinds/vr-pan.md)

And, of course, containerlab is perfectly capable of wiring up arbitrary linux containers which can host your network applications, virtual functions or simply be a test client. With all that, containerlab provides a single IaaC interface to manage labs which can span all the needed variants of nodes:

Expand Down
6 changes: 4 additions & 2 deletions docs/manual/vrnetlab.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -34,6 +34,7 @@ The following table provides a link between the version combinations that were v
| -- | [`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) |

### 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).
Expand Down Expand Up @@ -65,14 +66,15 @@ The images that work with containerlab will appear in the supported list gradual
| Cisco CSR1000v | [vr-csr](kinds/vr-csr.md) | | |
| 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) | | |

### 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.

<div class="mxgraph" style="max-width:100%;border:1px solid transparent;margin:0 auto; display:block;" data-mxgraph="{&quot;page&quot;:6,&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/vrnetlab.drawio&quot;}"></div>

??? "Any other datapaths?"
Althout `tc` based datapath should cover all the needed connectivity requirements, if other, bridge-like, datapaths are needed, Containerlab offers OpenvSwitch and Linux bridge modes.
Although `tc` based datapath should cover all the needed connectivity requirements, if other, bridge-like, datapaths are needed, Containerlab offers OpenvSwitch and Linux bridge modes.
Users can plug in those datapaths by specifying `CONNECTION_MODE` env variable:
```yaml
# the env variable can also be set in the defaults section
Expand Down Expand Up @@ -119,4 +121,4 @@ Effectively we run just two types of VMs in that lab, and thus we can implement
[^1]: see [this example lab](../lab-examples/vr-sros.md) with a license path provided in the topology definition file
[^2]: pros and cons of different datapaths were examined [here](https://netdevops.me/2021/transparently-redirecting-packets/frames-between-interfaces/)
[^3]: to install a certain version of containerlab, use the [instructions](../install.md) from installation doc.
[^4]: to have a guaranteed compatibility checkout to the mentined tag and build the images.
[^4]: to have a guaranteed compatibility checkout to the mentioned tag and build the images.

0 comments on commit 5b74b0c

Please sign in to comment.