From 0723464f239f2ad68933cb29f90afcbdf079b09c Mon Sep 17 00:00:00 2001 From: hellt Date: Thu, 14 Jan 2021 22:05:15 +0200 Subject: [PATCH] moved diagrams to orphaned branch --- docs/cmd/generate.md | 4 ++-- docs/index.md | 6 +++--- docs/lab-examples/ext-bridge.md | 4 ++-- docs/lab-examples/lab-examples.md | 4 ++-- docs/lab-examples/min-5clos.md | 4 ++-- docs/lab-examples/min-clos.md | 4 ++-- docs/lab-examples/single-srl.md | 4 ++-- docs/lab-examples/two-srls.md | 2 +- docs/lab-examples/wan.md | 4 ++-- docs/manual/network.md | 6 +++--- docs/manual/topo-def-file.md | 6 +++--- docs/manual/wireshark.md | 4 ++-- docs/quickstart.md | 4 ++-- 13 files changed, 28 insertions(+), 28 deletions(-) diff --git a/docs/cmd/generate.md b/docs/cmd/generate.md index aebb7db28..859b907ce 100644 --- a/docs/cmd/generate.md +++ b/docs/cmd/generate.md @@ -23,9 +23,9 @@ With the global `--name | -n` flag a user sets the name of the lab that will be #### nodes The user configures the CLOS fabric topology by using the `--nodes` flag. The flag value is a comma separated list of CLOS tiers where each tier is defined by the number of nodes, its kind and type. Multiple `--node` flags can be specified. -
+
- + For example, the following flag value will define a 2-tier CLOS fabric with tier1 (leafs) consists of 4x SR Linux containers of IXR6 type and the 2x Arista cEOS spines: ``` diff --git a/docs/index.md b/docs/index.md index 62ce7311e..c5bce3a3c 100644 --- a/docs/index.md +++ b/docs/index.md @@ -12,7 +12,7 @@ Unfortunately, container orchestration tools like docker/podman/etc are not a go Containerlab provides a framework for setting up networking labs with containers. It starts the containers and builds a virtual wiring between them to create lab topologies of users choice. -
+
Containerlab focuses on containerized Network Operating Systems which are typically used to test network features and designs, such as: @@ -22,7 +22,7 @@ Containerlab focuses on containerized Network Operating Systems which are typica * [Juniper cRPD](https://www.juniper.net/documentation/en_US/crpd/topics/concept/understanding-crpd.html) But, of course, containerlab is perfectly capable of wiring up arbitrary containers which can host your network applications, virtual router or simply be a test client. -
+
## Features * **IaaC approach** @@ -40,4 +40,4 @@ But, of course, containerlab is perfectly capable of wiring up arbitrary contain * **Lab catalog** The "most-wanted" lab topologies are [documented and included](lab-examples/lab-examples.md) with containerlab installation. Based on this cherry-picked selection you can start crafting the labs answering your needs. - + diff --git a/docs/lab-examples/ext-bridge.md b/docs/lab-examples/ext-bridge.md index f205e2619..a32fd20c0 100644 --- a/docs/lab-examples/ext-bridge.md +++ b/docs/lab-examples/ext-bridge.md @@ -9,7 +9,7 @@ ## Description This lab consists of three Nokia SR Linux nodes connected to a linux bridge. -
+
!!!note `containerlab` **will not** create/remove the bridge interface on your behalf. @@ -29,4 +29,4 @@ By introducing a link of `bridge` type to the containerlab topology, we are open [^1]: Resource requirements are provisional. Consult with SR Linux Software Installation guide for additional information. - \ No newline at end of file + \ No newline at end of file diff --git a/docs/lab-examples/lab-examples.md b/docs/lab-examples/lab-examples.md index 2b10a2abb..2921164de 100644 --- a/docs/lab-examples/lab-examples.md +++ b/docs/lab-examples/lab-examples.md @@ -1,6 +1,6 @@ # About lab examples -
- +
+ `containerlab` aims to provide a simple, intuitive and yet customizable way to run container based labs. To help our users to have a running and functional lab as quickly as possible, we ship some essential lab topologies within the `containerlab` package. diff --git a/docs/lab-examples/min-5clos.md b/docs/lab-examples/min-5clos.md index 89da2b22d..b8f9b19dc 100644 --- a/docs/lab-examples/min-5clos.md +++ b/docs/lab-examples/min-5clos.md @@ -9,7 +9,7 @@ ## Description This labs provides a lightweight folded 5-stage CLOS fabric with Super Spine level bridging two PODs. -
+
The topology is additionally equipped with the Linux containers connected to leaves to facilitate use cases which require access side emulation. @@ -24,4 +24,4 @@ With this lightweight CLOS topology a user can exhibit the following scenarios: [^1]: Resource requirements are provisional. Consult with SR Linux Software Installation guide for additional information. - \ No newline at end of file + \ No newline at end of file diff --git a/docs/lab-examples/min-clos.md b/docs/lab-examples/min-clos.md index 9f8d19160..ec01a82d1 100644 --- a/docs/lab-examples/min-clos.md +++ b/docs/lab-examples/min-clos.md @@ -9,7 +9,7 @@ ## Description This labs provides a lightweight folded CLOS fabric topology using a minimal set of nodes: two leaves and a single spine. -
+
The topology is additionally equipped with the Linux containers connected to leaves to facilitate use cases which require access side emulation. @@ -24,4 +24,4 @@ With this lightweight CLOS topology a user can exhibit the following scenarios: [^1]: Resource requirements are provisional. Consult with SR Linux Software Installation guide for additional information. - \ No newline at end of file + \ No newline at end of file diff --git a/docs/lab-examples/single-srl.md b/docs/lab-examples/single-srl.md index 6331ea13a..0d2aeba2d 100644 --- a/docs/lab-examples/single-srl.md +++ b/docs/lab-examples/single-srl.md @@ -9,7 +9,7 @@ ## Description A lab consists of a single SR Linux container equipped with a single interface - its management interface. No other network/data interfaces are created. -
+
The SR Linux's `mgmt` interface is connected to the `containerlab` docker network that is created as part of the lab deployment process. The `mgmt` interface of SRL will get IPv4/6 address information via DHCP service provided by docker daemon. @@ -28,4 +28,4 @@ This lightweight lab enables the users to perform the following exercises: [^1]: Resource requirements are provisional. Consult with SR Linux Software Installation guide for additional information. [^2]: Check out [gnmic](https://gnmic.kmrd.dev) gNMI client to interact with SR Linux gNMI server. - \ No newline at end of file + \ No newline at end of file diff --git a/docs/lab-examples/two-srls.md b/docs/lab-examples/two-srls.md index 0398acfe9..b554673e5 100644 --- a/docs/lab-examples/two-srls.md +++ b/docs/lab-examples/two-srls.md @@ -37,4 +37,4 @@ This lab, besides having the same objectives as [srl01](single-srl.md) lab, also [^1]: Resource requirements are provisional. Consult with SR Linux Software Installation guide for additional information. [^2]: versions of respective container images or software that was used to create the lab. - \ No newline at end of file + \ No newline at end of file diff --git a/docs/lab-examples/wan.md b/docs/lab-examples/wan.md index c5a765529..ff41ae040 100644 --- a/docs/lab-examples/wan.md +++ b/docs/lab-examples/wan.md @@ -9,7 +9,7 @@ ## Description Nokia SR Linux while focusing on the data center deployments in the first releases, will also be suitable for WAN deployments. In this lab users presented with a small WAN topology of four interconnected SR Linux nodes with multiple p2p interfaces between them. -
+
## Use cases The WAN-centric scenarios can be tested with this lab: @@ -22,4 +22,4 @@ The WAN-centric scenarios can be tested with this lab: [^1]: Resource requirements are provisional. Consult with SR Linux Software Installation guide for additional information. - \ No newline at end of file + \ No newline at end of file diff --git a/docs/manual/network.md b/docs/manual/network.md index 2bae40e0a..5b75a8f69 100644 --- a/docs/manual/network.md +++ b/docs/manual/network.md @@ -1,4 +1,4 @@ - + One of the most important tasks in the process of building container based labs is to create a virtual wiring between the containers and the host. That is one of the problems that containerlab was designed to solve. In this document we will discuss the networking concepts that containerlab employs to provide the following connectivity scenarios: @@ -34,7 +34,7 @@ topology: As seen from the topology definition file, the lab consists of the two SR Linux nodes which are interconnected via a single point-to-point link. -
+
The diagram above shows that these two nodes are not only interconnected between themselves, but also connected to a bridge interface on the lab host. This is driven by the containerlab default management network settings. @@ -188,7 +188,7 @@ As explained in the beginning of this article, containers will connect to this d ## Point-to-point links Management network is used to provide management access to the NOS containers, it does not carry control or dataplane traffic. In containerlab we create additional point-to-point links between the containers to provide the datapath between the lab nodes. -
+
The above diagram shows how links are created in the topology definition file. In this example, the datapath consists of the two virtual point-to-point wires between SR Linux and cEOS containers. These links are created on-demand by containerlab itself. diff --git a/docs/manual/topo-def-file.md b/docs/manual/topo-def-file.md index 250107106..96b411759 100644 --- a/docs/manual/topo-def-file.md +++ b/docs/manual/topo-def-file.md @@ -1,9 +1,9 @@ Containerlab builds labs based on the topology information that users pass to it. This topology information is expressed as a code contained in the _topology definition file_ which structure is the prime focus of this document. -
+
- + ## Topology definition components The topology definition file is a configuration file expressed in YAML. In this document we take a pre-packaged [Nokia SR Linux and Arista cEOS](../lab-examples/srl-ceos.md) lab and explain the topology definition structure using its definition file [srlceos01.yml](https://github.com/srl-wim/container-lab/tree/master/lab-examples/srlceos01/srlceos01.yml) which is pasted below: @@ -98,7 +98,7 @@ topology: As you see, the `topology.links` container consists of links. The link itself is expressed as list of two `endpoints`. This might sound complicated, lets use a graphical explanation: -
+
As demonstrated on a diagram above, the links between the containers are the point-to-point links which are defined by a pair of interfaces. The link defined as: diff --git a/docs/manual/wireshark.md b/docs/manual/wireshark.md index c1c1677ea..d7f2140ae 100644 --- a/docs/manual/wireshark.md +++ b/docs/manual/wireshark.md @@ -7,9 +7,9 @@ Containerlab is no exception and capturing packets is something you can and shou Consider the following lab topology which highlights the typical points of packet capture. -
+
- + Since containerlab leverages linux network devices, users are free to use whatever tool of choice to sniff from any of them. This article will provide examples for `tcpdump` and `wireshark` tools. diff --git a/docs/quickstart.md b/docs/quickstart.md index a81282ef0..29e7bb9ad 100644 --- a/docs/quickstart.md +++ b/docs/quickstart.md @@ -1,4 +1,4 @@ - + ## Installation Getting containerlab is as easy as it gets. Thanks to the trivial [installation](install.md) procedure it can be set up in a matter of a few seconds on any RHEL or Debian based OS[^1]. @@ -13,7 +13,7 @@ Once installed, containerlab manages the labs defined in the so-called [topology In this tutorial we will be using [one of the provided labs](lab-examples/two-srls.md) which consists of two Nokia SR Linux nodes connected one to another. -
+
The lab topology is defined in the [srl02.yml](https://github.com/srl-wim/container-lab/blob/master/lab-examples/srl02/srl02.yml) file. To make use of this lab example, we need to copy the corresponding files to our working directory: