Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Flock Routing Suite Daemon flockd

Overview

The flockd process is controlled by systemd.

$ systemctl status flockd
# systemctl start flockd
# systemctl stop flockd

flockd is a single process that is split into separate components.

System Component

The system component manages the other components and presents a unified API to the outside world.

The system component monitors external signals and updates the other components as required. Example external signals would be the addition of an IP address to an interface, or the addition of a route to the Linux Kernel.

The system component provides the configuration and operations API.

Routing Information Base (RIB) Component

The RIB component receives route updates from other components and from the Linux Kernel. The RIB component selects the best update for each route and redistributes it to other components and to the Linux Kernel. This redistribution can be controlled by configuration. By default the RIB will send the best route to the Linux Kernel. From the Linux Kernel it takes the routes the local host installs, for example with ip route add or from DHCP. Connected routes are derived from the interface addresses.

The RIB component also includes the Label RIB (LRIB) which manages MPLS label bindings programmed by protocols such as BGP and OSPF Segment Routing.

Multicast RIB (mRIB) Component

The mRIB component holds the multicast (S,G) forwarding entries derived by PIM, and flockd programs them into the Linux Kernel multicast forwarding table of their VRF.

OSPF Components

The OSPF components run the OSPFv2 and OSPFv3 protocols. These components get interface state information and connected IP subnet information from the System Component. These components get external state information by connecting to OSPF neighbors via Linux Kernel raw IP sockets. This information is combined and each best route is derived and sent to the RIB component.

BGPv4 Component

The BGPv4 component runs the BGPv4 protocol. This component gets IP route information from the RIB component and external state information by connecting to BGP neighbors via Linux Kernel TCP sockets. This information is combined and each best route is derived and sent to the RIB component.

PIM Component

The PIM component runs PIM Source-Specific Multicast in each configured VRF. An embedded IGMP instance on each PIM interface learns which multicast traffic local hosts want. PIM resolves the path back to each source from the RIB, and sends each (S,G) that is ready to forward to the mRIB component.

BFD Component

The BFD (Bidirectional Forwarding Detection) component provides sub-second failure detection for routing protocols. BFD sessions are created by protocols (BGP, OSPF, static routes) rather than configured directly. When a BFD session detects that a neighbor is unreachable, the associated protocol is notified immediately, enabling faster convergence than relying on protocol-level hello timers alone.

Static Component

The Static component manages the configuration of IPv4/IPv6 static routes. Static routes have a default administrative distance of 1 and therefore are preferred over dynamic routes by default. However, Static component allows you to specify a non-default administrative distance, thereby allowing a static route to be used as a backup route to a dynamic route. The configured static routes can be either recursive or non-recursive by specifying an explicit outgoing interface.

Multithreading

The routing suite runs in a single process and each component runs in its own thread. One way to view the active threads is via the Linux /proc virtual file system. The System component runs on the flockd thread. The RIB, mRIB, BGP, BFD, OSPFv2, OSPFv3, Static and PIM components are each allocated a thread when flockd starts, whether or not they are configured.

BGP and OSPF share a thread pool, which has a thread for each logical CPU core on the router. The pool is started the first time it is needed, and its threads take the name of the thread that started it. flockc sys overview reports the size of the pool as global_thread_pool_size, and starts the pool if nothing has yet.

flock@flocknet:~$ grep Name /proc/`pidof flockd`/task/*/status
/proc/409/task/409/status:Name: flockd
/proc/409/task/431/status:Name: RIB
/proc/409/task/432/status:Name: mRIB
/proc/409/task/433/status:Name: BGP
/proc/409/task/434/status:Name: BFD
/proc/409/task/435/status:Name: OSPFv2
/proc/409/task/436/status:Name: OSPFv3
/proc/409/task/437/status:Name: STATIC
/proc/409/task/438/status:Name: PIM
/proc/409/task/440/status:Name: BGP
/proc/409/task/441/status:Name: BGP
/proc/409/task/442/status:Name: BGP
/proc/409/task/443/status:Name: BGP
flock@flocknet:~$

In the example above:

  • The entire routing suite is running in a single process (process id 409).

  • The thread with thread id 409 is the flockd system thread.

  • The thread with thread id 433 is the BGP thread. The threads with id's 440, 441, 442 and 443 belong to the shared thread pool, which BGP started. There are 4 threads in the pool as the router has 4 logical CPU's.

      flock@flocknet:~$ cat /proc/cpuinfo | grep -c processor
  4
  flock@flocknet:~$

  • The current CPU and memory ulitization of each thread can be viewed using

      flock@flocknet:~$ top -H -p `pidof flockd`
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
  525 root      20   0  280708   4460   4008 S   0.3   0.4   0:00.96 STATIC
  518 root      20   0  280708   4460   4008 S   0.0   0.4   0:01.38 flockd
  523 root      20   0  280708   4460   4008 S   0.0   0.4   0:02.06 BGP
  526 root      20   0  280708   4460   4008 S   0.0   0.4   0:01.29 RIB
  535 root      20   0  280708   4460   4008 S   0.0   0.4   0:00.96 BGP
  flock@flocknet:~$

Logging

Logging can be viewed using journalctl.

View flockd logs since router was booted.

# journalctl -u flockd --boot
-- Logs begin at Fri 2020-01-10 14:01:47 GMT, end at Mon 2020-06-29 09:38:44 BST. --
Jun 29 08:49:36 r61 flockd[455]: [INFO  flockd] START: PID=455, Compile Mode=Release, Log Level="info"
...

View flockd logs since a certain time.

# journalctl -u flockd --since "2020-06-26 17:19:20"
-- Logs begin at Fri 2020-01-10 14:01:47 GMT, end at Mon 2020-06-29 09:40:55 BST. --
Jun 26 17:19:20 r61 flockd[431]: [INFO  flockd::bgp::bgp_neigh] 90.0.93.70/Some(BgpId(70.0.100.70)) BgpAsn2(70) Outgoing FSM state change OpenConfirm -> Established
...

Monitor for the latest flockd logs.

# journalctl -u flockd --follow
-- Logs begin at Fri 2020-01-10 14:01:47 GMT. --
Jun 29 09:44:34 r61 flockd[455]: [INFO  flockd::bgp::bgp_neigh] 60.0.60.60/Some(BgpId(60.0.100.60)) BgpAsn2(60) Incoming FSM state change OpenConfirm -> Established
...

Log Levels

Log levels can be set using the RUST_LOG environment variable.