From 178ca00ac019334862da58fd2e3d34ba949b0cc8 Mon Sep 17 00:00:00 2001 From: Ivan Pepelnjak Date: Tue, 31 Dec 2024 09:10:48 +0100 Subject: [PATCH] Fix documentation crossreferences --- docs/dev/clab-netns.md | 10 +++++----- docs/module/bgp.md | 2 +- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/dev/clab-netns.md b/docs/dev/clab-netns.md index 2b69c55c8..f09593ead 100644 --- a/docs/dev/clab-netns.md +++ b/docs/dev/clab-netns.md @@ -1,12 +1,12 @@ # Linux Containers and Network Namespaces -Containers provide a relatively new mechanism to execute self-contained network device logic on a host, and *Netlab* supports them through [Containerlab](labs/clab.md). +Containers provide a relatively new mechanism to execute self-contained network device logic on a host, and *Netlab* supports them through [Containerlab](lab-clab). From a developer perspective, there are some nuances in dealing with the provisioning of generic Linux containers. ## Network Namespaces -Each container runs inside its own network namespace (netns), which contains the logical devices that make up its interfaces to the external world. Containers typically have a minimal number of 1 network interface (not counting the internal loopback), but in the context of *Netlab* most network device containers have multiple - all of which needs to be provisioned. -To minimize dependencies on programs available inside each Linux container image, *Netlab* implements logic to use the Linux host for provisioning while operating inside the target Linux container netns. This logic is triggered by the name of the provisioning script: If the name ends with `-clab.sh`, it gets executed on the host using `ip netns exec`. -If not, a `docker exec` command is used to execute within the container (using whatever program binaries it contains) +Each container runs inside its own network namespace (`netns`), which contains the logical devices that make up its interfaces to the external world. Containers typically have a minimal number of 1 network interface (not counting the internal loopback); in the context of *Netlab*, most network device containers have multiple interfaces, all of which need to be provisioned. -See netsim/ansible/tasks/deploy-config/linux-clab.yml for details +To minimize dependencies on programs available inside each Linux container image, *Netlab* implements logic to use the Linux host for provisioning while operating inside the target Linux container netns. This logic is triggered by the name of the provisioning script: If the name of the provisioning template ends with `-clab.j2`, it gets executed on the host using `ip netns exec`. Otherwise, a `docker exec` command is used to execute the provisioning script within the container (using whatever program binaries it contains) + +See `netsim/ansible/tasks/deploy-config/linux-clab.yml` for details. diff --git a/docs/module/bgp.md b/docs/module/bgp.md index a1cf91cbb..63b19dcca 100644 --- a/docs/module/bgp.md +++ b/docs/module/bgp.md @@ -163,7 +163,7 @@ Additional per-node BGP configuration parameters include: * **bgp.advertise_loopback** -- when set to `False`, the IP prefixes configured on loopback interfaces are not advertised in BGP. See also [*Advanced Global Configuration Parameters*](#advanced-global-configuration-parameters). * **bgp.community** -- override global BGP community propagation defaults for this node. See *[](bgp-community-propagation)* for more details. * **bgp.import** -- [import (redistribute) IPv4 and IPv6 routes](routing_import) into global BGP instance (default: **false**) -* **bgp.local_as** -- the autonomous system used on all EBGP sessions. See *[](bgp-ibgp-localas)* on how this could result in **IBGP** sessions as well. +* **bgp.local_as** -- the autonomous system used on all EBGP sessions. See *[IBGP local-as](bgp-ibgp-localas)* on how this could result in **IBGP** sessions as well. * **bgp.next_hop_self** -- Use *next-hop-self* on IBGP sessions. This parameter can also be specified as a global value; the system default is **true**. * **bgp.originate** -- a list of additional prefixes to advertise. The advertised prefixes are supported with a static route pointing to *Null0*. * **bgp.router_id** -- Set a static router ID. The default **router_id** is taken from the IPv4 address of the loopback interface or the **router_id** address pool if the device does not have a loopback interface or there is no usable IPv4 address on the loopback interface.