Static routes or a routing protocol over a site-to-site VPN?

Both options carry packets between sites, so the decision is not about which protocol is newer, and the size of the tunnel does not settle it either. Three conditions do: how many prefixes change and how often, whether the design needs automatic failover between paths, and how much control-plane machinery the team can operate at three in the morning. Answer those honestly and the choice usually makes itself. The rest of this piece is what each answer costs.

Three conditions decide it

The first condition is churn. A handful of stable subnets with clear ownership can be maintained by hand for years, and each route stays a line someone can read and check. Dozens of prefixes that move as projects come and go are a different problem, because every move has to reach every device that still remembers the old path.

The second is failure behaviour. When a backup path must become active without a human noticing, something has to detect the failure and withdraw the route. Static routing can do that only through tracking or conditional installation, and only for the failures you thought to model in advance.

The third is appetite for a second control plane. A routing protocol adds sessions, authentication, filters and selection policy, and every one of those needs monitoring plus a change process. That is a permanent operating cost, not a one-off configuration task.

The table below the third paragraph is the short version; the three sections after it explain why each row sits where it does. Read the rows against your own site count before choosing, because a decision that ignores the operating cost is only half a decision.

What static routing actually costs

A static route has to be correct on both sides of the tunnel. Adding a subnet means editing the remote gateway, the local gateway and usually the return path, and forgetting any one of them produces a one-way failure that looks like an application bug. The application team sees timeouts while the network team sees a route that is present and apparently healthy. Neither team is wrong, which is why this failure takes so long to place.

A static entry also stays installed after the path beneath it disappears. Unless the platform supplies tracking, the route keeps pointing at a next hop that no longer forwards, and traffic vanishes instead of failing over. That silence is the expense you are accepting when you choose the simple option.

Write the tracking method next to each route, note which failures it covers, and keep the list with the tunnel configuration. Otherwise the next outage is discovered by a user rather than by the network, which is always the more expensive discovery.

What dynamic routing actually costs

A protocol advertises new prefixes, withdraws unreachable ones and expresses preference between paths. That is genuinely useful when several sites or redundant tunnels would otherwise need coordinated edits on every change. It is also the reason the protocol can surprise you at the worst moment. Every one of those actions is a state change you did not personally make.

It creates two states that can disagree. The tunnel can be up while the routing session is down, and the session can be up while its advertisements omit the subnet the application needs. Both look like a network that is half working, and neither is visible from a tunnel status page.

Filters and policy therefore become part of the design rather than an afterthought. A protocol that advertises everything will eventually advertise something wrong, and the wrong prefix travels faster than the person who can correct it. Write the filters before the first session is enabled so the first advertisement is already deliberate.

Control what the routing session may say

Decide the permitted prefix list per peer and enforce it on ingress, because an outbound filter cannot stop a peer from sending you a default route. Defaults and aggregates are the expensive mistakes here: they can quietly replace unrelated paths with a single learned entry that looks legitimate. Reject them explicitly unless the design genuinely wants them.

Write the owning site next to every network before the first session comes up, since that mapping is the source of the filter list rather than a documentation nicety. Without it, the person editing a filter has to guess which site should be announcing the prefix.

Redistributing between two protocols is where loops start, and where the same prefix arrives twice with attributes that do not compare cleanly. Keep redistribution out of the design until a specific requirement forces it, and if it must exist, mark and filter the routes at the boundary.

Route-based tunnel interfaces make dynamic routing easier to represent, because the tunnel becomes an interface with routes instead of a policy matching selectors. That does not remove the peer scope question: the IPsec selectors still have to permit the traffic you intend to route.

Test the failure path, not the happy path

Whatever you pick, bring one uplink down and confirm that traffic moves, or that it fails in the way you documented. A design that has only been tested with both paths healthy is a design that has not been tested at all. Time the detection while you are there, because the number you measured is the number users will experience.

Then confirm the return path independently, since asymmetric routing over a VPN is common and invisible until a stateful device drops the replies. A flow that works in one direction proves only half of the path.

Order of work: count the prefixes, decide how failures should be detected, check who can operate the protocol, control what is advertised, then test one outage end to end. Each step produces a fact the next step needs.