Skip to content

Module FRR

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

Module: FRR

This page describes the FRR module for dot2net.

What is FRR?

FRRouting (FRR) is a free and open source Internet routing protocol suite for Linux and Unix platforms. It implements BGP, OSPF, RIP, IS-IS, PIM, LDP, BFD, Babel, PBR, OpenFabric and VRRP.

What the FRR Module Provides

The FRR module generates no output file of its own. It provides a FormatStyle for writing configuration as vtysh commands, and a class that gives a node file logging.

Provided FormatStyles

FormatStyle Name Purpose Output Format
FRRVtyshCLI vtysh command format Shell commands for vtysh

FRRVtyshCLI FormatStyle

The FRRVtyshCLI FormatStyle formats configuration lines as vtysh commands suitable for shell execution:

vtysh -c "conf t" -c "router ospf" -c "router-id 10.255.0.1"

This is useful for the startup config block when you want to configure FRR via command line rather than configuration files.

frrLogFile: writing FRR's log to a file

nodeclass:
  - name: router
    use: [frrLogFile]

That is the whole of it. The class makes the log file, gives it to the frr user, names it to a running FRR, and collects it when the lab is destroyed.

It exists because FRR cannot make that file itself: its daemons run as the frr user and /var/log belongs to root, so a log file named in a configuration read at boot is one FRR reports it cannot open. Mounting an empty file in was the older answer, and it does not survive Kathara, which mounts directories and would have to replace /var/log wholesale.

The commands run from startup, so what is lost is whatever FRR logged before they run — a handful of lines about reading its configuration. From then on the log is complete.

Value Default Meaning
frr_log_path /var/log/frr.log Where the log is written inside the container
frr_log_level informational How much is written. FRR's own default is debugging, which floods a lab's log 
nodeclass:
  - name: router
    use: [frrLogFile]
    values:
      frr_log_level: debugging

Collecting it needs an entry script (module_config.<module>.generate_scripts: true); dot2net says so if one is missing. The collected file lands in collected/<node>/var/log/frr.log.

Usage Example

Using FRRVtyshCLI in startup

module:
  - containerlab
  - frr

nodeclass:
  - name: router
    values:
      image: quay.io/frrouting/frr:8.5.0
      kind: linux
    config:
      # Configure FRR via vtysh commands in startup
      - name: startup
        format: FRRVtyshCLI
        template:
          - "conf t"
          - "router ospf"
          - "router-id {{ .ip_loopback }}"
          - "network {{ .ip_net }} area 0"

Generated Output

In topo.yaml exec section:

exec:
  - vtysh -c "conf t" -c "router ospf" -c "router-id 10.255.0.1" -c "network 10.0.0.0/24 area 0"

Alternative: Configuration File Approach

For more complex configurations, you may prefer using FRR configuration files instead of vtysh commands:

module:
  - containerlab

file:
  - name: frr.conf
    path: /etc/frr/frr.conf
  - name: daemons
    path: /etc/frr/daemons
  - name: vtysh.conf
    path: /etc/frr/vtysh.conf

nodeclass:
  - name: router
    values:
      image: quay.io/frrouting/frr:8.5.0
      kind: linux
    config:
      - file: frr.conf
        template:
          - "hostname {{ .name }}"
          - "!"
          - "router ospf"
          - " router-id {{ .ip_loopback }}"
          - "{{ .interfaces_ospf_network }}"
          - "!"
      - file: daemons
        sourcefile: ./daemons
      - file: vtysh.conf
        sourcefile: ./vtysh.conf
      - name: startup
        template:
          - "vtysh -b"  # Load configuration from frr.conf

Comparison: Commands vs Config Files

Approach Pros Cons
FRRVtyshCLI (commands) Simple, no extra files Hard to debug, limited complexity
Config files Full FRR syntax, easier debugging Requires file setup (daemons, vtysh.conf)

Recommendation: Use config files for production scenarios; use FRRVtyshCLI for simple tests or quick prototypes.

Required FRR Files

When using FRR with configuration files, you typically need:

File Purpose Example Content
frr.conf Main configuration Generated by dot2net
daemons Enable routing daemons ospfd=yes
vtysh.conf vtysh settings service integrated-vtysh-config

Example daemons file

zebra=yes
bgpd=no
ospfd=yes
ospf6d=no
ripd=no
ripngd=no
isisd=no
pimd=no
ldpd=no
nhrpd=no
eigrpd=no
babeld=no
sharpd=no
staticd=no
pbrd=no
bfdd=no
fabricd=no

Example vtysh.conf file

service integrated-vtysh-config

Complete Example with FRRVtyshCLI

input.yaml

name: ospf_simple
module:
  - containerlab
  - frr

layer:
  - name: ip
    default_connect: true
    policy:
      - name: p2p
        range: 10.0.0.0/16
        prefix: 30
      - name: lo
        type: loopback
        range: 10.255.0.0/24

nodeclass:
  - name: router
    policy: [lo]
    values:
      image: quay.io/frrouting/frr:8.5.0
      kind: linux
    config:
      - name: startup
        format: FRRVtyshCLI
        template:
          - "conf t"
          - "router ospf"
          - "router-id {{ .ip_loopback }}"
          - "{{ .interfaces_ospf_cmd }}"

interfaceclass:
  - name: default
    policy: [ip]
    config:
      - name: ospf_cmd
        format: FRRVtyshCLI
        template:
          - "int {{ .name }}"
          - "ip addr {{ .ip_addr }}/{{ .ip_plen }}"
          - "router ospf"
          - "network {{ .ip_net }} area 0"

Generated topo.yaml

name: ospf_simple
topology:
  nodes:
    r1:
      kind: linux
      image: quay.io/frrouting/frr:8.5.0
      exec:
        - vtysh -c "conf t" -c "int net0" -c "ip addr 10.0.0.1/30" -c "router ospf" -c "network 10.0.0.0/30 area 0"
        - vtysh -c "conf t" -c "router ospf" -c "router-id 10.255.0.1"
    r2:
      kind: linux
      image: quay.io/frrouting/frr:8.5.0
      exec:
        - vtysh -c "conf t" -c "int net0" -c "ip addr 10.0.0.2/30" -c "router ospf" -c "network 10.0.0.0/30 area 0"
        - vtysh -c "conf t" -c "router ospf" -c "router-id 10.255.0.2"
  links:
    - endpoints: [r1:net0, r2:net0]

See Also

Clone this wiki locally