Wheelhouse

Interfaces, routing and uplinks#

The parts of a router that decide where a packet goes, with the live state shown beside the configuration that was supposed to produce it.

Interfaces#

The table merges what the configuration declares with what the kernel reports: counters, MTU, the attached qdisc, link state. An interface the kernel has and the configuration does not declare is flagged as drift rather than quietly listed.

The add-interface editor covers VLAN (802.1Q), bridge, bond with LACP, tunnel (GRE, IP-in-IP, SIT), VXLAN and dummy. The detail panel edits MTU, disables an interface administratively, and adds or removes addresses. PPPoE uplinks are created by the add-uplink wizard on the High availability page, because a PPPoE interface is an uplink before it is an interface.

The page also carries a neighbours view of the resolved addresses the kernel holds. LLDP — what the switch on the other end says it is, and which of its ports you are plugged into — is on Monitoring → Diagnostics → Neighbors, beside the ARP table.

Static routes#

The Static routes page shows the router's forwarding table and the declared static routes side by side, so a route you configured that the kernel is not using shows up as exactly that. Adding, editing and deleting a route are side panels that render their commands like everything else.

BGP and OSPF#

FRR is in the base, so the routing protocols are real ones rather than a plugin. The BGP / OSPF page reports whether each is configured and shows the configuration, with the same staging and commit behaviour as everything else.

Multi-WAN, through all five mechanisms#

VyOS has no gateway object. An uplink is any interface that carries a default route, and the agent finds them through every mechanism the platform offers:

MechanismConfigurationRanking knobDefault
Staticprotocols static route 0.0.0.0/0 next-hop <gw> distance <n>distance1
DHCP clientinterfaces … address dhcpdhcp-options default-route-distance210
PPPoE clientinterfaces pppoe pppoeNdefault-route-distance1
Failoverprotocols failover route 0.0.0.0/0 next-hop <gw>metric1
Load balancingload-balancing wan interface-health <if>rule weights1

Each uplink is joined with the live forwarding table, the kernel's link state, the load balancer's own report and the source-NAT rules, and the page shows per uplink: its addressing, its gateway (declared, or learned from the table when it came from DHCP), its rank and role, whether its default route is selected, installed, present or absent, and which NAT rule masquerades behind it.

There is an add-uplink wizard, a health-check editor, load-balancing rules, policy routing, and per-uplink NAT. Every one of those actions counts as dangerous, so commit-confirm is offered: they all decide which way packets leave, including the ones carrying your session.

Two mistakes the page catches, because both were made on the bench first: an uplink with no health check is never withdrawn, and dhcp-options no-default-route on a DHCP uplink that also has a dhcp-interface failover entry makes the daemon install nothing while its own tests keep passing.

High availability#

One page, four tabs: Uplinks (the above), VRRP (keepalived groups, with live state from show vrrp, add, disable, delete, priority and sync groups), Conntrack sync, and CLI.

VRRP is described as what it is. It is configuration you write, not availability that arrives switched on.

Read on#

Updated 2026-09-02