6.3 Dynamic Routing Protocols Overview

Why use dynamic routing?

A dynamic routing protocol exchanges reachability information and reacts to changes according to its rules and configuration. It reduces the manual work needed to maintain routes across a changing network. It does not remove the need to design addressing, metrics, policy, and failure recovery.

Static and dynamic routes often coexist. A small customer network may use a static default toward a provider, while the provider runs OSPF in its core and BGP for external or VPN reachability. Choosing a protocol starts with the scope of the routing problem.

Static routes generate no routing-protocol messages, but they still consume memory and processing resources. Dynamic protocols consume additional bandwidth and CPU for their exchanges; that cost can be worthwhile when the alternative is maintaining many manual routes.

Autonomous systems and administrative scope

An Autonomous System (AS) is a routing domain presenting a coherent routing policy. Public AS numbers identify domains in interdomain routing. Private AS numbers can be used within private arrangements and must be handled appropriately at public boundaries.

An Interior Gateway Protocol (IGP) distributes internal reachability. OSPF and IS-IS are common link-state IGPs. An Exterior Gateway Protocol serves interdomain routing; modern Internet routing uses BGP. BGP can also run between routers inside the same AS as IBGP. That does not turn it into an IGP: it retains BGP's path and policy rules.

Keep a protocol's administrative scope separate from its encapsulation. OSPF is carried directly in IP protocol 89; BGP uses TCP port 179; IS-IS control PDUs use link-layer encapsulation. Encapsulation alone does not tell you whether the protocol computes shortest internal paths or applies interdomain policy.

Distance-vector operation

A distance-vector protocol learns destination information from neighbors. An entry communicates a destination and a distance or metric through the advertising neighbor. RIP is a familiar example using hop count.

This limited topology view can create a count-to-infinity problem. Suppose R2 reaches a network through R1, but R1 loses that network. If R1 mistakenly accepts R2's stale advertisement as an alternative path, the two routers can keep increasing the metric while depending on each other.

Split horizon avoids advertising a route back through the interface from which it was learned. Poison reverse advertises the reverse path with an unreachable metric instead. RIP uses metric 16 for unreachable destinations. These techniques mitigate particular loops; they are not a guarantee against every multi-router convergence loop.

Periodic updates are characteristic of RIP. Do not generalize them to every protocol placed in the broad distance-vector category. Triggered updates and timers vary by protocol and implementation.

Link-state operation

A link-state protocol distributes descriptions of links and reachability within a defined flooding scope. Routers build a Link-State Database (LSDB) and calculate paths from their own position in the topology.

In converged OSPF operation, routers in an area share the area's topology information. Their shortest-path trees differ because each uses itself as the root. Their routes, next hops, and ARP entries therefore need not be identical. Temporary database differences can occur while updates are flooding.

A topology change can trigger new advertisements, but link-state protocols also maintain their state through periodic Hellos and advertisement refresh or synchronization mechanisms. It is incorrect to assume that a stable network sends only Hellos forever.

A consistent topology and SPF calculation produce the intended loop-free routes after convergence. During a transition, different routers can install updates at different times, so transient forwarding loops or blackholes remain possible.

Path-vector operation

BGP advertises prefixes with path attributes. Its AS_PATH records AS traversal and normally allows a receiver to reject a path containing its own AS. LOCAL_PREF, path length, and other attributes help apply policy.

BGP does not choose the route with the fewest physical router hops. A commercially preferred route can traverse a longer AS path or greater geographic distance. A short AS path is also not proof that the path is fast or uncongested.

IBGP needs additional distribution rules because the AS number is not prepended at each internal hop. A full mesh or an appropriate scaling design distributes routes without treating ordinary IBGP peers as unrestricted relays. Separate lessons explain the basic peering and attribute concepts.

Convergence after a failure

For a link-state example, R1–R2 fails while R1 has an alternate path through R3. Recovery has several dependencies:

1. Detect the failure through physical state, protocol timers, or configured detection mechanisms.
2. Originate and distribute changed topology information.
3. Update local databases and calculate eligible replacement paths.
4. Select routes and program new forwarding state.
5. Forward traffic over the surviving path.

The elapsed time depends on topology, timers, CPU work, forwarding updates, and protection features. BFD can shorten detection when supported and configured, but no universal “under 30 milliseconds” result follows merely from enabling a dynamic protocol.

A backup path must actually exist and have sufficient capacity. Fast detection cannot route around a cut that partitions the network. Local fast reroute may restore traffic before complete routing convergence, but restoration and full convergence are different events.

Diagnose by evidence

If a route is missing, ask whether the source advertised it, whether the neighbor exchange succeeded, whether policy accepted it, and whether it won route selection. If the route exists but traffic fails, check next-hop resolution, service context, filters, and the return path. A protocol session being Up proves only part of the delivery chain.

Primary reference

OSPF specification and BGP specification, checked October 20, 2026. Examples here state their topology assumptions explicitly.