Routers, Host, and Bridges

netlab supports three types of nodes:

router – a device performing a combination of layer-3 and (optional) layer-2 forwarding.
host – an IP host, usually using static (default) routes instead of a routing protocol
bridge – simple layer-2 switches (devices formerly known as bridges)

Most netlab-supported devices act as routers; see the platform support tables for a list of devices that can act as hosts or bridges.

Routers and Layer-3 Switches

The defining characteristics of devices with the router role (the default device role) are:

At least one global loopback interface that can be used as the router ID and the control-plane endpoint
Layer-3 packet forwarding for the configured address families (IPv4/IPv6)

Routers usually run routing protocols but can also rely on static routing. When used with the vlan configuration module, they can also perform layer-2 packet forwarding and IRB.

Hosts

Hosts do not have loopback interfaces (it’s easiest if they have a single interface) and use static routes toward an adjacent default gateway. On devices that don’t have the management VRF, Vagrant or containerlab set up the default route, and netlab adds static IPv4 routes for IPv4 prefixes defined in address pools.

Hosts that have a management VRF (mostly network devices used as hosts) get two IPv4 default routes. Vagrant or containerlab sets up the IPv4 default route in the management VRF, and netlab adds a default route toward an adjacent router in the global routing table.

Most hosts listen to IPv6 RA messages to get the IPv6 default route. netlab can add an IPv6 default route[1] on devices that do not listen to RA messages.

Bridges

The bridge role is a thin abstraction layer on top of the vlan configuration module, making deploying simple topologies with a single bridge connecting multiple routers or hosts easier. You can also use a bridge node to test failover scenarios using a familiar layer-2 device[2].

Do not try to build complex topologies with bridges; use the VLAN configuration module.

Bridges are simple layer-2 packet forwarding devices[3]. They do not have a loopback interface and might not even have a data-plane IP address. Without additional parameters, netlab configures them the way non-VLAN bridges have been working for decades – bridge interfaces do not use VLAN tagging and belong to a single layer-2 forwarding domain.

You can use the bridge devices to implement simple small bridged segments, for example:

nodes:
  rtr:
    device: eos
  h1:
    device: linux
  h2:
    device: linux
  br:
    device: ioll2
    role: bridge

links: [ rtr-br, h1-br, h2-br ]

In the above topology, netlab assigns an IP prefix from the lan pool to the VLAN segment connecting the four devices (you can change that).

You can also connect multiple bridges into a larger bridged network. This scenario stretches the limitations of the bridge nodes (using the vlan configuration module would be better). If you decide to use it in your topology, you SHOULD define a global br_default VLAN (defined as vlans.br_default topology attribute) to share the same IP subnet across all bridges.

nodes:
  rtr:
    device: eos
  h1:
    device: linux
  h2:
    device: linux
	br1:
    device: ioll2
    role: bridge
  br2:
    device: ioll2
    role: bridge

links: [ rtr-br1, br1-br2, h1-br2, h2-br2 ]

Warning

netlab does not implement multiple independent bridge domains for the same VLAN.

Bridge Implementation Details

netlab uses the vlan configuration module to implement the simple bridging functionality – it places all bridge interfaces without an explicit vlan parameter into the same access VLAN.

The VLAN configuration module needs the default access VLAN name and VLAN ID (tag). The default name of that VLAN is br_default[4], and it uses VLAN tag 1[5] to make the final device configuration similar to the out-of-the-box configuration of simple layer-2 switches.

You can use the node- or global VLAN definition of the br_default VLAN to change the parameters (for example, the IP prefix or address pool) of the LAN segment created around a bridge node.

For more VLAN configuration- and implementation details, read the vlan configuration module documentation.

Implementing Multi-Access Links with Bridge Nodes

You can use the bridge link attribute to use a bridge node (instead of a Linux bridge) to build a LAN segment consisting of point-to-point links attaching link nodes to the bridge node.

For example, you can use the following topology to create a topology equivalent to the one above; the multi-access link is expanded into a series of point-to-point links with the br device.

nodes:
  rtr:
    device: eos
  h1:
    device: linux
  h2:
    device: linux
  br:
    device: ioll2
    role: bridge

links:
- interfaces: [ rtr, h1, h2 ]
  bridge: br

Each multi-access link implemented with a bridge node is a separate bridging domain. netlab creates a separate VLAN with a topology-wide unique VLAN ID on the bridge node for every multi-access link and copies the link attributes into the VLAN attributes. Thus, it’s safe to use the same bridge node to implement multiple multi-access links.