Fix documentation crossreferences

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.

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.