Links between virtual lab devices are specified in links element of the topology file – a list of links in one of these formats:
A dictionary of node names and other link attributes. Use this format when you want to have a tight control over interface attributes like IP addresses, or when you have to specify additional link attributes like OSPF cost.
A list of node names. Use this format for multi-access interface when you’re OK with default IP addressing and don’t need to specify any additional link attributes.
A string in node-node format. Use this format for a point-to-point link.
A dictionary of link attributes and a list of node interfaces.
You can use all four link formats in the same topology file – they are always converted into a dictionary+list of interfaces format, and augmented with addressing details during the topology transformation process.
role – link role, used to select specific configuration module behavior. Typical link roles include stub, passive and external. Please read Common Routing Protocol Parameters for more details.
type – link type (lan, p2p, stub, loopback, tunnel)
You can use most link attributes on individual node attachments (dictionary under node name key). You can also use these node attachment attributes:
ifindex – optional per-node interface index used to generate the interface/port name. Useful to select specific ports to match typical network designs (example: using high-speed ports for uplinks) when the virtualization provider supports mapping of host interfaces into VM/container interfaces.
ifname – target interface name. Use to create tunnel interfaces on some platforms, or to create unusual interface types.
Lab topology could contain lan, p2p, stub, loopback and tunnel links. The link type could be specified with the type attribute; when that attribute is missing the link type is selected based on the number of devices connected to the link:
Single node connected to a link ⇒ stub or loopback (see below)
The link type influences the address prefix pool used to assign IPv4 and IPv6 prefixes to the link and the node addressing:
Prefixes assigned to point-to-point links are taken from p2p pool. The node with the smaller node name gets the lower (.1) address, the other node gets the higher (.2) address. The default addressing setup uses /30 IPv4 prefixes and /64 IPv6 prefixes.
Prefixes assigned to other links are taken from lan pool, unless you specified the pool link attribute. The host portion of the IP address on large-enough prefixes is the node ID. When faced with a non-VLAN prefix that would not accommodate the largest ID of a node connected to the link, netlab uses sequential IP address allocation.
The default link types usually work well, and you should use the pool attribute to specify the address pool instead of changing the link type. You might have to change link type in advanced scenarios; for example, you have to set link type to lan to use Linux bridges instead of UDP tunnels in libvirt environment.
Stub links (links with a single node) are treated as physical links and consume VM/container interfaces. Some virtualization platforms limit the number of VM interfaces, so you might be forced to turn such links into loopback interfaces.
You could turn an interface attached to a stub link into a loopback interface with type: loopback link attribute. You could also change the default behavior with defaults.links.stub_loopback global setting or defaults.devices.<device>.features.stub_loopback device-specific setting.
For example, to turn stub links into loopback interfaces on all lab devices apart from Cisco IOSv routers, use the following lab topology parameters:
Links with type: tunnel can be used to create tunnel interfaces. Tunnel links are addressed in the same way as LAN links and can have any valid link/module attribute.
netlab assigns an IP prefix to the tunnel link, creates tunnel interfaces on nodes connected to tunnel links, assigns IP addresses to the tunnel interfaces, and copies all other link parameters into interface data. Tunnel interface name is generated from device data (when available), or specified in the ifname interface (node-on-link) parameter.
Standard netlab device configuration templates will create tunnel interfaces, and configure all netlab-supported parameters on them. You will have to use custom configuration templates to make tunnel interfaces operational (specifying, for example, source and destination underlay IP address and tunnel encapsulation).
For example, use this topology to create a tunnel between two Cisco CSR edge routers.
When your lab topology contains numerous links with identical (or similar) attributes, it might be worth defining those links as a link group. A link group MUST have a group attribute (an identifier) and a list of member links.
The link initialization phase of the lab topology transformation creates new regular links from the group members links. Group attributes (apart from group and members attributes) are added to the member link attributes.
You could, for example, use a link group to define a set of links with the same VLANs in a VLAN trunk (complete example):
You can use the prefix attribute to specify IPv4 and/or IPv6 prefix to be used on the link. When the prefix attribute is not specified, the link prefix is taken from the corresponding address pool (see above).
The prefix attribute could be either an IPv4 CIDR prefix or a dictionary with ipv4 and/or ipv6 elements.
You can use the shorthand (string) syntax if you’re building an IPv4-only network, for example:
You can specify static interface address with the ipv4 and/or ipv6 attributes within the link-specific node data. You can also set ipv4 or ipv6 attribute of link-specific node data to these special values:
True: enable IPv4 or IPv6 on the interface without assigning it an IP address (unnumbered/LLA-only interface)
False: disable IPv4 or IPv6 on the interface, allowing you to have layer-2-only nodes attached to an IPv4/IPv6 subnet (needed to implement stretched subnets).
an integer value: the interface is assigned N-th IPv4/IPv6 address from the link prefix.
The following example uses static interface addresses for two out of three nodes connected to a LAN link:
These interface address are assigned to the three nodes during the topology transformation process:
e1: 10.42.0.2/29 (unchanged)
e2: 192.168.22.17/24 (subnet mask copied from on-link prefix)
e3: 192.168.22.3/24 (IPv4 address derived from on-link prefix and node id).
An interface address could use a subnet mask that does not match the link subnet mask. If you don’t specify a subnet mask in an interface address, it’s copied from the link prefix.
You could specify an IPv6 interface address on an IPv4-only link (or vice versa). An interface address belonging to an address family that is not specified in the link prefix (static or derived from an address pool) is not checked.
All devices supported by netlab are assumed to use ancient default layer-3 MTU value of 1500 bytes. Most VM-based network devices already use that default; container-based devices have their MTU set to 1500 through system settings.
Please note that the mtu specified by netlab is always the layer-3 (IPv4 or IPv6) MTU. The peculiarities of individual device configuration commands are transparently (to the end-user) handled in the device configuration templates.
You can change the mtu on an individual interface (probably not a good idea), on a link, for a particular node or device type, or for the whole lab.
mtu parameter specified on a node is applied to all node interfaces that don’t have their MTU set through a link or interface parameter. In the following example, r1 has mtu set to 1500 bytes on the inter-router link and to 8192 bytes on the stub link:
When the node mtu parameter is not specified, its default value is fetched from defaults.interfaces.mtu or defaults.devices setting.
For example, to build a lab using 8K jumbo frames, use:
All devices without explicit MTU setting will inherit the lab-wide default (8192) which will be further propagated to all interfaces without an explicit MTU value.
mtu parameter can also be specified within device defaults. For example, to set default Cumulus Linux MTU to 1500 use:
Point-to-point links between network devices are implemented with P2P tunnels (assuming the virtualization environment supports them).
Multi-access and stub links are implemented with custom networks (as supported by the underlying virtualization environment). The bridge attribute allows you to specify the custom network name; its default value is name_N where: