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:
{
"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#
| Field | Read from |
|---|---|
| Local AS | protocols bgp system-as, falling back to local-as |
| Router ID | protocols bgp parameters router-id |
| Neighbours | the 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#
| Field | Read from |
|---|---|
| Router ID | protocols ospf parameters router-id |
| Areas | the keys under protocols ospf area |
| Interfaces | the 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 bgpThat 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 65002The 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 0The 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-sourceor 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#
- Network → BGP / OSPF → + OSPF.
- Router ID
10.255.255.1— an address on a dummy interface, made on Adding an interface. - Area
0, network10.0.0.0/16, interfaceeth0. 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- 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.