A master craftsman's workshop contains many tools—each optimized for specific tasks. A hammer drives nails; a saw cuts wood; a level ensures precision. Using the wrong tool makes work harder, produces inferior results, or even causes damage.

Routing protocols are the network engineer's tools. RIP, OSPF, IS-IS, EIGRP, BGP, static routes—each is designed for specific scenarios, and choosing incorrectly leads to poor performance, unnecessary complexity, or outright failure. Yet this choice is often made without systematic analysis, based on familiarity rather than fit.

This page equips you with a protocol selection framework—a methodology for analyzing network requirements and matching them to the right routing solution.

Protocol selection should be systematic, not instinctive. The following framework provides a structured approach to analyzing requirements and selecting protocols.

Step 1: Define the Routing Domain

First, identify what you're routing:

• Single site: Campus, data center, branch office
• Multiple sites under common management: Enterprise WAN
• Multiple organizations: Service provider, Internet connectivity
• Hybrid: Mix of internal and external routing requirements

This immediately suggests IGP vs. EGP scope.

Step 2: Analyze Key Requirements

Step 3: Consider Operational Factors

• Configuration complexity: How much ongoing management overhead?
• Troubleshooting difficulty: How easy to diagnose issues?
• Automation compatibility: Does protocol support modern automation (NETCONF, gRPC)?
• Monitoring and visibility: What tools exist for observability?
• Documentation: How well-understood is the protocol internally?

Step 4: Evaluate Trade-offs

No protocol is optimal in all dimensions. Common trade-offs:

Before selecting a dynamic routing protocol, consider whether static routing meets your needs. Dynamic protocols add complexity; if that complexity isn't justified, static routes are preferable.

Static Routing Advantages:

• Zero protocol overhead: No CPU cycles for route calculation, no bandwidth for updates
• Predictable behavior: Routes don't change unexpectedly
• Simple security: No routing protocol authentication needed
• Reduced attack surface: No routing protocol to exploit
• Deterministic paths: Traffic always follows the configured path

Hybrid Approach: Static + Dynamic

Many networks combine static and dynamic routing:

• Static for Internet egress: Default route to upstream provider
• Dynamic for internal: OSPF/EIGRP between internal routers
• Static for partner connections: Specific routes to partner networks via dedicated links
• Dynamic for data center: Full IGP deployment for redundancy and load balancing

This hybrid approach uses each method where it's most appropriate—static for stable, simple paths; dynamic for complex, redundant internal routing.

When dynamic interior routing is needed, choosing the right IGP is critical. Here's a comprehensive decision matrix:

Detailed Protocol Comparison:

When to Choose RIP:

• Legacy environments where RIP already runs
• Extremely simple networks where any IGP works
• Educational or lab scenarios
• Integration with non-router devices that only support RIP

Reality check: RIP is rarely the right choice for new deployments. Its 15-hop limit, slow convergence, and hop-count-only metric are severe limitations.

When to Choose EIGRP:

• All-Cisco environment (or Cisco-dominant with minority other vendors)
• Need fastest possible convergence (sub-second with feasible successors)
• Want unequal-cost load balancing across multiple paths
• Prefer simpler configuration over OSPF's explicit hierarchy
• Team has EIGRP expertise and no compelling reason to switch

Consideration: EIGRP is now an IETF RFC (7868), but adoption outside Cisco remains minimal. Long-term multi-vendor strategy may favor OSPF.

When to Choose OSPF:

• Multi-vendor environment (universal support)
• Need hierarchical design (areas for scaling)
• Industry-standard required (many environments mandate open standards)
• Segment Routing deployment planned (SR-OSPF is well-supported)
• Engineering staff familiar with OSPF from education/certification

Consideration: OSPF is the "safe default" for enterprise networks—well-understood, universally supported, scales well with proper area design.

When to Choose IS-IS:

• Service provider core network
• Hyperscale data center (Facebook, Google, Microsoft scale)
• MPLS Traffic Engineering deployment
• Need multi-topology routing (IPv4 and IPv6 with different topologies)
• Building a new network without legacy constraints

Consideration: IS-IS has a steeper learning curve but rewards with simpler scaling. If your team knows OSPF and you're not at extreme scale, stick with OSPF.

BGP operates in a different domain than IGPs. The question isn't "BGP vs. OSPF"—they serve complementary purposes. The question is: Do you need BGP at all?

BGP Is Required When:

BGP Is NOT Required When:

• Single-homed to one ISP: Static default route is sufficient
• Multi-connection to same ISP: Provider handles redundancy; you just need their PE routes
• Internal routing only: IGPs handle intra-AS routing; BGP is for inter-AS
• Small business with basic Internet: Static routing or provider-managed connectivity

eBGP vs. iBGP Deployment:

Real networks often run multiple routing protocols. A service provider might run IS-IS in the core, OSPF in customer-facing segments, and BGP for Internet connectivity. An enterprise might have EIGRP in legacy campus, OSPF in the data center, and BGP for cloud connectivity.

Common Multi-Protocol Architectures:

Route Redistribution:

When routes must flow between protocols, redistribution is required. This is powerful but dangerous—poorly configured redistribution causes routing loops, suboptimal paths, and network instability.

Redistribution Best Practices:

1. Minimize redistribution points: Each redistribution point is a potential problem source. Use the fewest possible.

2. Filter at boundaries: Use route-maps and prefix-lists to allow only intended routes. Never redistribute "everything."

3. Set sensible metrics: Redistributed routes use default metrics that may not reflect reality. Set appropriate metrics or use metric-type considerations.

4. Prevent routing loops: In complex topologies with multiple redistribution points, routes can loop. Use techniques like:

   • Route tagging (tag routes at redistribution, filter tagged routes at other points)
   • Administrative distance tuning
   • Distribute-lists blocking specific prefixes

5. Document thoroughly: Redistribution logic can be subtle. Document what's redistributed where and why.

6. Test extensively: Redistribution errors may not appear until specific failure scenarios. Test failover cases.

Fast failover is often critical, but achieving it requires deliberate design. Different protocols converge at different speeds, and various techniques can accelerate recovery.

Bidirectional Forwarding Detection (BFD):

BFD is a protocol-independent failure detection mechanism. It detects link failures in milliseconds (typically 50-300ms) and notifies the routing protocol, which can then immediately reconverge.

Why BFD is essential:

• Routing protocol hellos are slow (10-30 seconds typical)
• Even "fast" hellos (1-second) with 3-second dead times are too slow for some requirements
• BFD operates at sub-second granularity
• Works with OSPF, IS-IS, EIGRP, BGP, static routes

BFD Design Considerations:

• CPU impact: Fast BFD (50ms intervals) adds load
• Platform support: Hardware-assisted BFD is preferred for sub-100ms timers
• Asymmetric detection: Detect failures even when only one direction fails

Protocol migrations are among the riskiest network operations. A botched migration can cause widespread outages. Careful planning and phased execution are essential.

Migration Strategies:

Migration Best Practices:

1. Plan extensively — Document current state, target state, and each intermediate step

2. Lab validation — Test the migration process in a lab environment that mirrors production

3. Change windows — Schedule migrations during low-traffic periods with sufficient time for rollback

4. Rollback procedures — Document and test rollback before starting; know exactly how to revert

5. Staged rollout — Migrate one segment at a time; validate before proceeding

6. Monitoring — Watch routing tables, neighbor states, and traffic patterns throughout

7. Post-migration validation — Confirm routing is correct from multiple vantage points

8. Stabilization period — Keep old configuration available for quick rollback for days/weeks

We've developed a comprehensive framework for routing protocol selection. Let's consolidate the key insights:

What's Next:

With protocol selection mastered, we'll complete our exploration of the interior vs. exterior distinction by examining AS boundaries—the demarcation points where IGP gives way to BGP, where administrative domains meet, and where routing policy translates to business reality.