FRRouting (FRR) Documentation

FRR supports Lua scripting (version 5.3) to extend built-in behavior, perform calculations, or make decisions using arbitrary user code. This is implemented via standard Lua C bindings.

Key characteristics:

• Data Exchange: C objects can be passed into Lua, and Lua objects can be retrieved by C code through an encoding/decoding system, allowing arbitrary data from FRR to be passed to scripts.
• Isolation: The Lua environment is isolated from the C environment. User scripts cannot access FRR's address space unless explicitly allowed by FRR.

The Zebra protocol (also known as ZAPI) is a streaming protocol used by protocol daemons to communicate with the zebra daemon. It allows daemons to request or send information regarding interface states, routing state, nexthop-validation, and to install routes.

Session Identification: Each ZAPI session is uniquely identified by the tuple: {protocol, instance, session_id}.

• The default session_id is 0.
• Daemons requiring multiple sessions (e.g., LDPD for label blocks) must assign unique session_id values.

The FRR Management Daemon (MGMTd) serves as the centralized Management Plane for FRR. It provides a unified interface for various UI/Frontend clients (CLI, Netconf, Restconf, Grpc, etc.) to interact with FRR components.

Key features include:

• Centralized Data Management: Stores and retrieves management data using YANG-compliant schemas.
• Computational Offloading: Offloads YANG parsing and validation from individual component daemons to improve performance.
• Transaction Control: Provides centralized control over configuration validation, commits, and rollbacks.
• Sub-components: Consists of the MGMT Frontend Interface, MGMT Backend Interface, and MGMT Transaction Engine.

FRR Flowspec implements a mechanism to distribute traffic rule flow specifications using a new NLRI (Network Layer Reachability Information) encoding format. Instead of relying solely on destination IP prefixes, Flowspec uses an n-tuple rule to define traffic criteria.

Supported rule components include:

• Network: Source and/or destination IP (IPv4 or IPv6).
• Layer 4 (UDP/TCP): Source port, destination port, or any port.
• Layer 4 (ICMP): ICMP type and ICMP code.
• Layer 4 (TCP): TCP Flags.
• Layer 3: DSCP value, Protocol type, packet length, and fragmentation.

Actions associated with these rules (encoded via BGP extended communities) can include rerouting (to a specific nexthop or VRF), shaping, or discarding traffic.

PCEPlib is a PCEP (Path Computation Element Communication Protocol) implementation library designed for use by either a PCE (Path Computation Element) or a PCC (Path Computation Client).

Key capabilities include:

• Simultaneous connection to multiple PCEP peers.
• Maintenance of persistent PCEP connections.
• Currently, the FRR pathd daemon is the primary implementation using PCEPlib as a PCC.

The OSPF API allows external applications to interact with the OSPF daemon's Link-State Database (LSDB). It provides two primary capabilities:

1. LSDB Retrieval: Applications can obtain a full or partial copy of the LSDB (including router LSAs, network LSAs, etc.). The API module provides real-time synchronization by sending messages to the application whenever a new LSA arrives.
2. Opaque LSA Origination: Applications can originate their own opaque LSAs (types 9, 10, or 11) to distribute application-specific information (e.g., for Traffic Engineering like MPLS-TE) across the network. These LSAs are transparent to the routing process but can be processed by other modules.