As much as we’d love everything in our networks to be dynamic, auto-configured, or software-defined, reality often intervenes and forces us to use static routes, so we needed a mechanism to specify them in netlab lab topologies.

A static route has two components: the destination prefix and the next hop – the device that we hope knows how to reach that destination. The next hop is usually specified as an IPv4 or IPv6 address, but may also include outgoing interface information¹.

One of the beauties of netlab is that it takes over the IPAM chores; link subnets and interface addresses are assigned automatically. Our static route data structures had to reflect this; we couldn’t expect you to assign static IP addresses to node interfaces just to be able to specify them as next hops in static routes.

A netlab static route thus has these components:

• The destination prefix, which can be specified as ipv4 or ipv6 prefix, but also as an address pool, a named prefix or a node loopback interface.
• The next hop (specified within the nexthop dictionary), which can also be an ipv4 or ipv6 address (in case you really want to use static addresses), the next hop node, or the default gateway. A static route can also be a discard route (pointing to null interface).
• Optional VRF information – the vrf in which the static route should be installed and the nexthop.vrf if you want to do inter-VRF static routing.

The static routes are specified for individual nodes (or groups of nodes) in the routing.static attribute²

For example, this is all you have to do if you want R1 to have a default route pointing to R2.

module: [ routing ]

nodes:
  R1:
    routing.static:
    - ipv4: 0.0.0.0/0
      nexthop.node: R2
  R2:
  
links: [ R1-R2 ]

Notes:

• Static routes are part of the generic routing configuration module that has to be active on the node(s) using the static routes (line 1)
• We didn’t have to specify the IP address of R2 or the outgoing interface; netlab takes care of that automatically (line 7)

If you want to do the same for a bunch of hosts, you can define static routing for a group of nodes. It’s worth noting that even though every host has to use a different IP address as the next hop (each host is in a different subnet), netlab takes care of that behind the scenes; all you need to know is the node name of the next hop.

nodes: [ H1, H2, H3, R ]

groups:
  hosts:
    members: [ H1, H2, H3 ]
    device: linux
    module: [ routing ]
    routing.static:
    - ipv4: 0.0.0.0/0
      nexthop.node: R

links: [ H1-R, H2-R, H3-R ]

How about a static route toward a default gateway? Absolutely not a problem if you’re using the first-hop gateway on the LAN segment. In the following lab topology³, S1 and S2 have an anycast gateway, and the host (H) is using it as the next hop of the default route:

nodes:
  H:
    module: [ routing ]
    routing.static:
    - ipv4: 0.0.0.0/0
      gateway: True
  S1:
    module: [ gateway ]
  S2:
    module: [ gateway ]

links:
- interfaces: [ H, S1, S2 ]
  gateway.protocol: anycast

Finally, how about a typical Internet access scenario where the customer and the ISP use static routing? We don’t have an elegant answer for this one yet⁴; you have to specify a static IPv4 prefix on the customer LAN subnet and use that prefix in the static route on the ISP router⁵:

module: [ routing ]
defaults.device: eos
provider: clab

nodes:
  ce:
    routing.static:
    - ipv4: 0.0.0.0/0
      nexthop.node: pe
  pe:
    routing.static:
    - ipv4: 192.168.42.0/24
      nexthop.node: ce

links:
- pe-ce
- ce:
  prefix.ipv4: 192.168.42.0/24

Note:

• The implementation of static routes in netlab release 25.06 does not allow you to refer to a link prefix (unless you’re using named prefixes). We have to specify a static IPv4 prefix for the CE LAN subnet (line 18) and use that prefix as the destination prefix on the PE-router (line 12)