Skip to content

Upgrading to 0.8

Jump to bottom
sat edited this page Aug 13, 2026 · 12 revisions

Upgrading to 0.8.0

A topology written for 0.7.x meets several changes at once. This page is what to read before upgrading one; the CHANGELOG describes each in full.

Generated files move

A file declared with path: /etc/frr/frr.conf is written to r1/etc/frr/frr.conf, not r1/frr.conf. A node's files are laid out by the path they take inside the container.

What to do: nothing in the topology. Anything reading generated files by path has to follow — a script of your own, or a downstream tool such as netroub, which reads a lab's generated files to replay failures on it. See File Output.

Interfaces are named eth0, eth1, ...

The default interface prefix is eth, where it used to be net.

What to do: update any template that names an interface literally. eth is what a Linux container calls its interfaces and the only prefix Kathara accepts, so this is the one name every platform agrees on.

containerlab nodes get no management network

Generated nodes carry network-mode: none. A lab has only the links its topology describes.

What to do: if the lab relied on clab exec, the clab-* container names, or reachability through the management network, put it back:

module_config:
  containerlab:
    management_network: true

and name the data interfaces something other than eth0, which containerlab keeps for itself.

A shared segment reaching across machines is replaced with bridges

A multi-host topology that drew a segment spanning machines now gets one bridge per machine, linked to each other, instead of one link leaving a machine per member on the far side.

What to do: nothing, unless the old shape was wanted: global.aggregate_crossing_links: false.

virtual on an interface no longer takes its link with it

virtual: true used to mean "leave this out of the output" and to reach the connection as well, so an interface marked virtual silently removed the link it sat on. It now says what it says: the interface is not deployed, and whether a link is emitted follows from whether a platform is being told to make one.

What to do: a topology that used virtual on an interface to drop a link gets the link. If the link should not exist, say so on the connection.

Mistakes that used to be quiet are now errors

What Why
An unknown or duplicate key in the config file A key the config did not know was dropped without a word, which looks exactly like a setting that had no effect
Two file definitions writing the same file Whichever was written last won, and the other's content was gone
A config entry naming both template and sourcefile Which came first was decided in the code and written down nowhere

What to do: run dot2net build and fix what it names. Each message says what is wrong and how to write it instead.

The Kathara startup file

0.7.0 documented writing <device>.startup yourself, with name_suffix: .startup and output: root. The Kathara module owns that file now.

What to do: if the topology declared it, drop the declaration and write a startup template instead — the same one containerlab and TiNET already read:

nodeclass:
  - name: router
    config:
      - name: startup
        template:
          - "ip link set lo up"

The old declaration still works on its own; it collides once the Kathara module is loaded, and dot2net says which two definitions collided.

See Also

Clone this wiki locally