Wheelhouse docs

BGP / OSPF#

Network → BGP / OSPF, at /routing. It owns the protocols subtree. Two panels, one per protocol, each saying whether it is configured and summarising what it is configured with. Below them, the whole protocols subtree rendered as commands.

The routing daemon is FRR, and it is VyOS'. Wheelhouse does not run it, does not talk to it directly and adds nothing to it: this page reads the configuration tree and writes the configuration tree, and the router does the rest.

What "configured" means here#

GET /api/routing, polled every 15 seconds, reads two config paths and reports each as configured or not-configured:

json
{
  "bgp":  { "status": "configured", "config": { "system-as": "65001", "…": "" } },
  "ospf": { "status": "not-configured" }
}

The verdict is a configuration read, nothing more: protocols bgp returning a subtree means configured, and a read that fails or comes back empty means not-configured — agent/main.go (handleRouting).

The BGP panel#

FieldRead from
Local ASprotocols bgp system-as, falling back to local-as
Router IDprotocols bgp parameters router-id
Neighboursthe number of keys under protocols bgp neighbor

Under the summary, one line per neighbour: its address and its remote-as. A neighbour with no remote-as shows , which on a real configuration means a peer-group member whose AS is set on the group.

The OSPF panel#

FieldRead from
Router IDprotocols ospf parameters router-id
Areasthe keys under protocols ospf area
Interfacesthe entries under protocols ospf interface

Under the summary, one line per interface with the area it is in.

Remove#

Each panel carries a Remove button when its protocol is configured. It stages one operation:

delete protocols bgp

That is the entire protocol: every neighbour, every address family, every route map reference under it. There is no confirmation dialogue — the staged operation in the Commit Bar is the confirmation, and it can be removed there before you commit.

The configuration as commands#

When either protocol is configured, the panel below the two summaries renders GET /api/config/commands?path=protocols — the whole protocols subtree, which includes protocols static and protocols failover as well. It is the accurate view of what the routing configuration actually is, and it is the block to copy when you are asking someone else why a session is not coming up.

Below admin, values whose leaf name is a secret are blanked before the response leaves the agent, so a BGP password does not reach a viewer through this block — agent/security.go.

The starter editors#

+ BGP and + OSPF open a side panel each. They write the minimum that makes the protocol exist and nothing else; everything past that is CLI or config tree.

BGP#

Requires a local AS. The neighbour is written only when both its address and its remote AS are filled.

set protocols bgp system-as 65001
set protocols bgp parameters router-id 10.255.255.1
set protocols bgp neighbor 192.0.2.2 remote-as 65002

The router ID hint suggests a loopback address, which is the usual practice: an ID tied to an interface that cannot go down.

OSPF#

Every field is optional, and each one that is filled produces its own command.

set protocols ospf parameters router-id 10.255.255.1
set protocols ospf area 0 network 10.0.0.0/16
set protocols ospf interface eth0 area 0

The Area control is a menu with three values — 0, 1 and 2. An area outside that set is a CLI command; the node itself takes any area identifier the router accepts.

The Interface field is free text and defaults to eth0; it is not checked against the interfaces that exist.

What the editors will not write#

The panels are a first commit, not a routing configuration.

  • No address families, peer groups, route maps, prefix lists or communities.
  • No BGP timers, ebgp-multihop, update-source or authentication.
  • No OSPF cost, authentication, network type, stub or NSSA settings, or redistribution.
  • No BFD.
  • No second neighbour: the panel writes one, and the rest are added elsewhere.

All of it is reachable as ordinary configuration. The config tree page will render any node under protocols as commands, and everything you type on the CLI shows up in this page's summary on the next poll.

Worked example: an OSPF area 0 on the LAN#

  1. Network → BGP / OSPF → + OSPF.
  2. Router ID 10.255.255.1 — an address on a dummy interface, made on Adding an interface.
  3. Area 0, network 10.0.0.0/16, interface eth0.
  4. The Commands block reads:

    set protocols ospf parameters router-id 10.255.255.1
    set protocols ospf area 0 network 10.0.0.0/16
    set protocols ospf interface eth0 area 0
  5. Stage, then commit.

The OSPF panel now says configured and lists area 0 and one interface. That is all this page will ever tell you. To see whether an adjacency formed, go to Static routes and look for rows with source ospf; if none appear after a minute, the neighbour is not up and the CLI is where you find out why.

See also#

  • Static routes — where routes learned by these protocols appear, and where the static ones are written.
  • Interfaces — the interfaces an OSPF area is bound to.
  • Uplinks (multi-WAN) — the default route, which these protocols can also supply, and which the uplink model reads out of the same table.

Checked against ui/src/pages/Routing.tsx, agent/main.go (handleRouting, handleConfigCommands), agent/security.go, ui/src/lib/api.ts.

Updated 2026-09-02 manual network routing bgp ospf frr