9.4 The Routing Control Plane: RIP, OSPF and BGP
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." They distribute reachability and path information. A healthy protocol session does not prove that application packets can pass; this lesson follows failure detection, selection, and forwarding-table installation.
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 Bellman–Ford relation expresses this update, with v ranging over x’s neighbors:
D_x(y) = min_v { cost(x, v) + D_v(y) }Suppose A reaches a destination directly, while B reaches it through A. After A's link fails, A may accept B's stale advertisement as an alternative and route through B, which still routes through A. Their outdated reports repeatedly increase the reported distance: count-to-infinity. Split horizon, poison reverse, and triggered updates reduce the problem but do not guarantee immediate convergence in every topology.
RIPv2 uses hop count, with 15 the largest reachable metric and 16 meaning unreachable. It normally sends periodic updates every 30 seconds and uses multicast 224.0.0.9 for RIPv2 updates. Compatibility modes and configuration can change the sending behavior. These are protocol rules and deployment options, not arbitrary implementation details. RFC 2453
3. Link state: All routers in the same area build a shared topology database
OSPF routers establish adjacencies, advertise state in link-state advertisements (LSAs), maintain link-state databases (LSDBs), and independently calculate shortest-path-first (SPF) trees.
Areas limit distribution of full topology, but LSA flooding scopes differ. OSPFv2 Router-LSAs and Network-LSAs stay within an area. Type 5 AS-external-LSAs generally cross areas, with exceptions such as stub areas. An area topology database does not imply that every LSA is area-local. RFC 2328 §12
Area Border Routers (ABRs) advertise summary or reachability information between areas, using backbone area 0 for inter-area routing. An ordinary router inside an area need not know every link in other areas. Area design therefore affects scale, failure scope, and troubleshooting.
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 passes through several stages
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 AS path of an announcement, used for loop checks and policy, without cryptographic proof that the path is genuine;ORIGIN: The origin type of a prefix as it enters BGP; it is not a cryptographic identity;MED: A preference among entry points from a neighboring AS, usually favoring lower values, with comparison scope constrained by policy;NEXT_HOP: The forwarding next-hop address, which must resolve recursively through underlying routing;- Community/large community: A policy tag applied to routes for administrative control.
BGP has a defined state machine, message processing, loop checks, and route-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.
An RPKI Route Origin Authorization (ROA) identifies the authorized origin AS, prefix, and maximum length. A validator checks these signed objects and supplies validated ROA payloads (VRPs) to routers. Route Origin Validation (ROV) classifies announcements as Valid, Invalid, or NotFound; operators still configure the handling policy.
Suppose the local database contains just one VRP: 192.0.2.0/24, maximum length 25, origin AS 64496. This calculation uses documentation addresses and AS numbers without advertising real routes:
| Announced prefix | Origin AS | Result | Reason |
|---|---|---|---|
| 192.0.2.0/25 | 64496 | Valid | Coverage, length, and origin all match |
| 192.0.2.0/26 | 64496 | Invalid | Exceeds the permitted maximum length |
| 192.0.2.0/24 | 64497 | Invalid | A covering record exists, but the origin differs |
| 198.51.100.0/24 | 64496 | NotFound | No VRP covers the prefix |
With several covering records, one full match is enough for Valid; do not use only the longest record. NotFound means no covering record exists, not verified trust or a confirmed hijack. RFC 6811 §2
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. Follow a route from the RIB to actual forwarding
- 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?
- Which information does an OSPF area contain, and which LSAs can cross areas?
- Why can't BGP be summarized by the rule "the shortest AS_PATH always wins"?
- How do Invalid and NotFound differ in the table, and why does neither validate the entire path?