9.4 Routing control plane: RIP, OSPF, and BGP
As road networks expand across multiple autonomous regions, static routing tables become insufficient. Individual routing nodes must exchange information, yet they cannot blindly trust every announcement.
The forwarding plane examines each packet against the FIB. Meanwhile, the control plane learns and computes candidate routes, selecting the active one to populate the RIB/FIB. Routing protocols do not directly "carry each data packet along its path." Instead, they distribute reachability and path information.
1. First distinguish candidate selection and packet lookup
A router can simultaneously learn the same prefix from connected routes, static routes, OSPF, and BGP. The vendor or operating system selects the active route based on route source preference (administrative distance), protocol metric, and policy.
Packet lookup first performs a longest-prefix match on the destination address. These two steps must not be conflated with the idea that "the route with the smallest metric is always selected": /24 is more specific than /16, even if they come from different protocol or metric spaces. Metrics are typically only compared within the same prefix and source selection context.
Equal-cost multipath (ECMP) can install multiple equal-candidate routes into the FIB and forward traffic based on flow hashing. Per-packet load balancing may result in reordering; modern implementations often use per-flow or consistent hashing. However, the choice of hash fields, resilience, and rebalancing behavior are implementation-specific policies.
2. Distance vector: neighbors tell me where they can go
A distance-vector router receives destination and distance information from its neighbors, then updates its own view by adding the cost to reach that neighbor. The core intuition behind this process is captured by the Bellman–Ford equation:
D_x(y) = min_v { cost(x, v) + D_v(y) }When a failure occurs, outdated information can circulate among neighbors, leading to a count-to-infinity problem. Techniques such as split horizon, poison reverse, triggered updates, and hold-down timers help mitigate this, but they do not guarantee immediate convergence in arbitrary network topologies.
RIPv2 uses hop count as its metric, with a value of 16 indicating unreachable destinations, making it suitable only for small networks. The default update timer and multicast behavior in RIP are implementation-specific details. When understanding the core concept, it's more important to recognize that RIP does not broadcast the full topology; instead, it only informs neighbors of the distance vector.
3. Link state: All routers in the same area build a shared topology database
OSPF routers establish adjacencies and advertise their local state using link-state advertisements (LSAs), which are then reliably flooded throughout the area. Routers within the same area work to achieve a consistent link-state database (LSDB), after which each independently performs a shortest-path-first calculation to determine routes.
"It is not true that every OSPF router knows the state of every link in the world." Areas serve as boundaries for flooding and LSDB propagation. Area Border Routers (ABRs) exchange summary and reachability information between areas. The backbone area (Area 0) and the overall area design significantly impact scalability, failure domains, and troubleshooting efforts.
OSPF cost is a metric configured by the network operator or implementation, not a real-time latency measurement. Without uniform adjustment of the reference bandwidth, high-speed links may appear to have the same cost. Features such as authentication, passive interfaces, area types, route summarization, and default route policies are all integral components of production network design.
4. Convergence is Not Just "The Algorithm Runs to Completion"
The convergence chain following a link failure includes:
- Failure detection (physical signals, hello/dead timers, BFD);
- Adjacency or state transitions;
- LSA generation and flooding;
- SPF or policy recalculations;
- RIB selection and FIB programming;
- Transient microloops or blackholes caused by neighbor routers updating at different times.
Thus, measuring only Dijkstra runtime is insufficient to determine outage duration. Fast reroute can precompute backup next hops and restore forwarding before full control-plane convergence, but it requires both loop-free conditions and capacity planning.
5. BGP Transfers Policy-Rich Reachability Between Autonomous Systems
BGP speakers exchange NLRI (prefix reachability) and path attributes via TCP connections. eBGP is used for communication between ASes, while iBGP distributes external and internal BGP routes within an AS, commonly achieved using route reflectors to reduce the complexity of a full mesh topology.
Common path attributes:
LOCAL_PREF: A high-level outbound policy within an AS; higher values typically take precedence;AS_PATH: The sequence or set of ASes through which a route was announced, used for loop detection and policy enforcement;ORIGIN: The origin type of a prefix as it enters BGP, this is not a cryptographic identity;MED: A preference for multiple entry points to a route, requiring clear scope and policy definitions to compare;NEXT_HOP: The next-hop address used to forward the route, which must be reachable via IGP or static routing;- Community/large community: A policy tag applied to routes for administrative control.
BGP is not merely "just diplomacy", it has a well-defined finite state machine, message processing logic, loop prevention mechanisms, and a best-path selection procedure. However, local policy can override the simple shortest AS path principle. Different implementations may vary in default tie-breakers and operator-defined policies, so a vendor-specific route preference list should not be assumed to represent a fixed order across the entire Internet.
6. Route leak, hijack, and RPKI origin validation
Route hijacking occurs when an unauthorized autonomous system (AS) declares someone else's prefix, while route leaking typically involves forwarding routes to a peer that, according to commercial or relationship policies, should not receive them. Both scenarios can cause traffic to be diverted, dropped, or funneled into the wrong AS.
RPKI Route Origin Authorization (ROA) specifies which origin AS is authorized to announce a particular prefix and defines the maximum prefix length. Route Origin Validation (ROV) evaluates BGP announcements to determine whether they are valid, invalid, or not found, after which operators apply their own policies.
ROV validates origin authorization but does not cryptographically verify the entire AS_PATH, nor does it automatically block all route leaks. To effectively mitigate these risks, operators must combine multiple defenses: prefix filtering, maximum prefix limits, IRR/RPKI data, peer policies, monitoring, and incident response coordination.
7. Diagnosing the Journey from RIB to FIB
- Was the prefix received in the protocol database / Adj-RIB-In?
- Was it rejected or modified by an inbound policy?
- Why didn’t the candidate route become the active route?
- Is the next hop resolvable?
- Has the active route been programmed into the FIB or hardware?
- Has neighbor resolution and adjacency been successfully established?
- Do data-plane counters or packet captures align with the control-plane’s expectations?
Observing only "BGP session Established" does not confirm that the target prefix was received, selected, or installed. Simply checking the route table does not verify that ASIC entries or neighbor forwarding entries are actually capable of forwarding packets.
8. Acceptance Questions
- Distinguish between the control plane, RIB, FIB, and forwarding plane.
- Why does distance vector routing lead to count-to-infinity?
- What problem does OSPF area design solve, and why don’t area routers need to know the full AS topology?
- Why can't BGP be summarized by the rule "the shortest AS_PATH always wins"?
- What can ROV verify, and what does it fail to verify?