Layer 3 Routing Protocols - Choose Wisely for Stability

Modern networks do not move traffic by magic; they build and maintain a map of reachable prefixes, then keep updating that map when links fail, costs change, or policy says a route should be preferred. In practice, layer 3 routing protocols are the control-plane tools that keep that map accurate enough for routers to make the next-hop decision.

That matters in enterprise backbones, factory networks, and IoT edges alike. A weak routing design can turn a small fault into slow convergence, broken telemetry, or a control segment that takes longer to recover than it should.

What these protocols actually do at Layer 3

Routing at the network layer is about reachability and next-hop selection. The router learns which prefixes exist, where they sit, and what path is currently best, then it installs that decision into the forwarding table so packets can move without any extra discussion on each hop. Static routes can help with simple edges, but they do not scale the way dynamic protocols do, which is why I usually separate the design into two jobs: the protocol learns the map, and the forwarding plane uses it.

That split matters because many design mistakes come from treating routing as if it were the same thing as packet forwarding. It is not. A router can forward very quickly once the table is correct, but if the control plane is badly designed, the table itself becomes stale, inconsistent, or far too large. Once you see that distinction clearly, the real differences between the major protocol families become much easier to judge.

The cleanest way to think about the market is this: IGPs keep a site or autonomous system moving, while BGP stitches different routing domains together. That separation is the backbone of most stable networks, and it is the point where practical engineering starts to matter more than protocol trivia.

The protocol families you’ll actually encounter

If I strip away the jargon, the field boils down to a few protocols that solve different problems. OSPF and IS-IS are link-state interior protocols, BGP is the policy layer between routing domains, and RIP is the older distance-vector option that survives mostly where simplicity or legacy constraints still matter. The question is not which one sounds smartest; it is which one matches the size, shape, and operational style of the network.

Protocol	Type	Best fit	Strength	Trade-off
OSPF	Link-state IGP	Campus, enterprise core, plant backbone	Fast shortest-path calculation inside one routing domain	Needs sensible area design and summarisation
IS-IS	Link-state IGP	Large backbones and scalable site cores	Very flexible and well suited to growth	Less familiar to some teams
BGP	Path-vector interdomain protocol	WAN edges, multi-site interconnects, internet boundaries	Policy control and scale	More operational discipline is required
RIP	Distance-vector IGP	Small or legacy networks	Very simple to understand	15-hop ceiling and slower convergence

OSPF and IS-IS are the workhorses inside a site

OSPF is a link-state protocol that floods topology information within a single autonomous system and then lets each router calculate a shortest-path tree. IS-IS does the same broad job with a different data model and a reputation for scaling cleanly in larger backbones. In practice, both are strong fits when you want the network to recover quickly and you want the routing logic to stay understandable to the people operating it.

For manufacturing sites, that usually means the plant core, aggregation layer, or campus backbone. I like them because they keep the design local: a problem in one part of the site does not automatically force every router to reconsider the entire world.

BGP is about policy, not shortest path

BGP is the protocol I reach for when routing needs to cross boundaries. Its job is not to find the mathematically shortest path inside one site; its job is to exchange reachability between autonomous systems and let policy decide which path is preferred. That is why it dominates internet and WAN edge designs, where business rules matter as much as topology.

In a plant or smart manufacturing environment, BGP often belongs at the edge, not everywhere. That keeps the core simple and gives you a controlled point for talking to a WAN provider, a cloud region, or another site.

RIP is still useful as a warning label

RIP is the protocol that reminds me how far routing has come. It uses hop count as its metric, and its 15-hop ceiling is exactly why it stays out of larger networks. RIPv2 improved on the original by carrying more useful information, but it is still a distance-vector design, which means slower reaction and less headroom for growth.

That does not make RIP useless in every case. It can still make sense in tiny legacy segments where replacing old hardware is not worth the risk, but I would not choose it for any network that needs fast recovery, multiple sites, or real operational growth.

Once you see the split between interior protocols and boundary protocols, the next question is not “which one is best”, but “which one recovers well enough for the network I am running?”

Why convergence and failure handling matter more than the acronym

Convergence is the time it takes for routers to agree on the best live path after something changes. That change might be a failed link, a new subnet, a cleaner summary route, or a policy update at the edge. When convergence is poor, the user experience is usually poor too: traffic black-holes, brief loops, or sessions that survive only because the application is forgiving.

This is where protocol choice becomes practical rather than theoretical. Link-state designs usually give you stronger control over how much of the topology each router has to process, while BGP gives you more policy power but asks for more discipline. The fastest network on paper is not always the safest one in production. I care more about predictable recovery than about a protocol name that sounds impressive.

• Topology depth matters, because every extra layer is another place where delay or inconsistency can appear.
• Redistribution matters, because moving routes between protocols can leak prefixes or distort metrics if you are careless.
• Summarisation matters, because it reduces table size and limits how far a local failure spreads.
• Device capability matters, because embedded or low-power hardware may survive a simple design better than a clever one.

In industrial networks, I also treat convergence as an availability issue, not a routing issue. If a plant historian, remote support tunnel, or machine cell path takes too long to settle, the business feels it immediately. That is why the next step is not more theory, but choosing a protocol that fits the shape of the network.

How I would choose a routing protocol for a plant, campus, or edge network

My default approach is simple. I keep one interior protocol inside the site, I use BGP only where policy or external interconnects make it necessary, and I leave endpoints alone unless they genuinely need to route. That sounds conservative because it is conservative, and conservative routing is usually what holds up best in industrial automation and IoT deployments.

Scenario	My starting point	Why it fits
Small lab or single machine cell	Static routes, or RIP only if legacy gear forces it	There is no benefit in adding complexity before scale demands it
Plant backbone or campus core	OSPF or IS-IS	Fast enough recovery, clear hierarchy, and sensible summarisation
Multi-site WAN or cloud edge	BGP at the boundary	Policy control matters more than shortest-path calculation
Low-power IoT endpoints	Route at the gateway, not on the device	Embedded devices should stay focused on sensing and control, not on topology management

One point I would stress for smart manufacturing is that routing does not make a network deterministic in the hard real-time sense. It improves path selection and recovery, but it does not turn Ethernet into a fieldbus by itself. If you need predictable control behaviour, keep routing close to the site core and keep the endpoint design boring.

That approach gives you room to grow without forcing every new line, gateway, or cloud connection to become a routing redesign. It also reduces the chance that a single design slip will ripple through the whole site.

Common mistakes that make routing unstable

• Using RIP because it feels familiar, even when the network has already outgrown it.
• Redistributing everything into everything else, then wondering why prefixes appear in places they should not.
• Flattening the routing domain so that one failure triggers more churn than the site can absorb comfortably.
• Putting routing adjacency on fragile endpoints instead of on stable gateways or distribution devices.
• Ignoring authentication, filtering, and prefix limits, which turns a good design into an avoidable risk.
• Assuming the protocol will save a badly designed topology, when the opposite is usually true.

The pattern here is consistent: instability is usually a design problem first and a protocol problem second. If redistribution, summarisation, and neighbour control are handled carefully, even a fairly ordinary routing stack can behave very well. Once those risks are removed, the design can stay almost boring, which is exactly what you want.

What I would standardise before the network grows

If I were setting up a new manufacturing or IoT backbone in 2026, I would standardise early. I would keep one interior routing model for the site, define clear edge boundaries, and document every place where routes are summarised or redistributed. I would also make sure the team knows which prefixes are local, which are external, and which device is responsible for each boundary.

• Choose one IGP for the site and keep it consistent.
• Use BGP only where external policy or multi-site interconnects really need it.
• Summarise at the right boundary, not everywhere.
• Filter and protect every adjacency that can inject routes.
• Keep low-power devices out of the routing role unless there is a strong reason to do otherwise.

The best routing design is usually the one that disappears into the background. If the network stays stable, prefixes stay sensible, and failover is predictable, the rest of the stack gets to do its job without drama.