Routing daemon logs — zebra, bgpd, ospfd, the log-level configuration

FRRouting (FRR) is the routing daemon suite on VyOS 1.5 LTS. The daemons (zebra, bgpd, ospfd, ripd, isisd, etc.) each have their own log file and log level. When a routing problem surfaces, the operator reviews the daemon’s log to identify the symptom and the root cause.

This lesson covers the FRRouting log configuration on VyOS 1.5 LTS, the per-daemon log files, the log-level configuration, the interpretation of common log messages, and the production failure modes where routing daemons silently fail.

The FRR daemon suite

flowchart LR
  Z["zebra<br/>kernel routing table"] --> LOG["/var/log/frr/zebra.log"]
  B["bgpd<br/>BGP protocol"] --> LOG
  O["ospfd<br/>OSPF protocol"] --> LOG
  R["ripd<br/>RIP protocol"] --> LOG
  I["isisd<br/>IS-IS protocol"] --> LOG
  L["ldpd<br/>LDP protocol"] --> LOG
  LOG --> SYS["syslog"]
  LOG --> JNL["journald"]

Each daemon has its own log file in /var/log/frr/. The log files are rotated by logrotate. The daemon logs are also captured by syslog (via the local0 to local7 facilities) and journald.

Configuring log levels

configure
set FRR log facility 'local7'
set FRR log level 'informational'
commit
save

The configuration sets the default log level for all FRR daemons to informational and uses local7 as the syslog facility. Individual daemons can override:

set FRR zebra log level 'notifications'
set FRR bgpd log level 'debugging'
set FRR ospfd log level 'warnings'

The log levels (from most verbose to least):

• debugging — every message including debug.
• informational — info and above.
• notifications — notifications and above (normal operation messages).
• warnings — warnings and above.
• errors — errors only.
• critical — critical only.
• emergencies — emergencies only.

The production default: informational for most daemons; warnings for noisy daemons; debugging only when troubleshooting.

Locating the log files

vyos@R1:~$ ls /var/log/frr/
zebra.log
bgpd.log
ospfd.log
ripd.log
isisd.log
watchfrr.log

Each daemon writes to its own file. The watchfrr.log records the FRR watchdog activity (which daemons are running, restarts, etc.).

Interpreting common log messages

zebra.log — interface state changes

2026-08-15 12:00:01 R1 zebra: interface eth0 state changed to up
2026-08-15 12:00:05 R1 zebra: interface eth1 state changed to down
2026-08-15 12:00:10 R1 zebra: route add 192.0.2.0/24 via 10.0.0.1 dev eth0

zebra logs every interface state change and every route add / remove. The operator correlates the route add / remove with the interface state change to identify the root cause of a routing problem.

bgpd.log — BGP session events

2026-08-15 12:00:01 R1 bgpd: [12345] Established
2026-08-15 12:00:05 R1 bgpd: [12345] Update message received from 203.0.113.50
2026-08-15 12:00:10 R1 bgpd: [12345] NOTIFICATION received: Hold Timer Expired

The operator reviews the bgpd.log to identify BGP session state changes (Established, Idle, Active), update messages (prefixes received / sent), and errors (notifications, hold timer expired).

ospfd.log — OSPF adjacency events

2026-08-15 12:00:01 R1 ospfd: Neighbor 10.0.0.2 (eth0) state changed from Loading to Full
2026-08-15 12:00:05 R1 ospfd: Neighbor 10.0.0.3 (eth1) state changed from Full to Down
2026-08-15 12:00:10 R1 ospfd: LSDB update: LSA 10.0.0.0/24 id 10.0.0.2 seq 80000001

The operator reviews the ospfd.log to identify OSPF adjacency state changes (Down, Init, 2-Way, Exstart, Exchange, Loading, Full), LSA updates, and SPF calculations.

How the result is validated

show FRR log
journalctl -u frr
tail -f /var/log/frr/bgpd.log

The first shows the FRR log via the VyOS command tree. The second shows the journald view (useful for filtering by time). The third tails the bgpd log file in real-time.

A working FRR logging setup:

• Daemon log files are populated with relevant events.
• The log level is appropriate (informational for most daemons).
• The log files are rotated by logrotate.
• The log files are exported to the central syslog server.

vyos@R1:~$ show FRR log
... [truncated output] ...
2026-08-15 12:00:01 R1 bgpd: Established
2026-08-15 12:00:05 R1 bgpd: Update message received from 203.0.113.50
2026-08-15 12:00:10 R1 ospfd: Neighbor 10.0.0.2 state changed to Full

How it fails

The production failure modes a routing engineer must recognise:

• Log level too low. The operator set the daemon to errors only. The daemon logs errors but not state changes. The operator cannot troubleshoot because the log doesn’t show what happened. The fix: set the level to informational or higher.
• Log level too high. The operator set the daemon to debugging permanently. The log fills the disk. The fix: set the level back to informational after troubleshooting.
• Log file missing. The /var/log/frr/ directory is empty. FRR cannot write logs. The fix: check the directory permissions, the FRR configuration, and the disk space.
• Log file not rotated. The bgpd.log is 10 GB. logrotate is not configured for /var/log/frr/. The fix: configure logrotate for FRR log files.
• Logs not exported. Local logs fill the disk and are lost. The fix: configure remote syslog export.
• Daemon not running. The daemon is supposed to be running but is not. The operator sees no log output because there is no daemon. The fix: check systemctl status frr, restart FRR.

Exporting routing daemon logs

configure
set system syslog host 203.0.113.100 facility all level info
commit
save

The configuration exports all syslog messages (including FRR daemons) to the central server at 203.0.113.100. The operator can filter for local0 to local7 facilities on the central server to isolate the FRR logs.

For finer-grained control, the operator can configure per-facility export:

set system syslog host 203.0.113.100 facility local7 level info

This exports only local7 (typically the FRR daemon logs) to the central server at info level.

Rollback

The recovery from a broken FRR logging configuration:

• Log level too high: delete FRR bgpd log level and re-add at informational.
• Log file missing: mkdir -p /var/log/frr/ and restart FRR.
• Log file not rotated: configure logrotate for FRR log files.

The VyOS configuration rollback (rollback N) restores the previous configuration if the FRR logging change breaks the system.

Production discipline

Cross-course references

• XLVIII-VyOS-Logging (vyos-xlviii-01-local-logging, vyos-xlviii-05-remote-syslog, vyos-xlviii-06-log-validation) cover the rest of the logging subsystem.
• XVIII-VyOS-OSPFFund covers OSPF; this lesson covers its log interpretation.
• XXIII-VyOS-BGPFund covers BGP; this lesson covers its log interpretation.
• III-VyOS-Architecture (vyos-iii-02-frr-and-routing-daemons) covers the FRR architecture.

Quiz