OSPF max-metric: Discouraging Branch Transit Without Removal

Two offices connect through a branch that should carry its own traffic and very little else. The branch needs routes to both sites, and neither site should prefer it as the path between them. Removing the branch from the topology would solve the transit problem and break the requirement, because the branch still needs to reach both sites and both sites still need to reach the branch.

What you want is a preference, expressed in the routing protocol, that leaves the branch fully reachable and makes it a poor choice for anything passing through. Walk the problem in the order the routers see it.

Start from the path you want to avoid

Draw the topology as the protocol sees it, not as the diagram sees it. Which interfaces form adjacencies, which are in the same area, and which of those adjacencies would carry traffic between the two offices if the branch were preferred? Those are three separate questions, and a diagram answers none of them reliably.

Then find the alternate path. If the only route between the offices crosses the branch, no metric can move traffic off it, because there is nowhere for the traffic to go. Redundancy is not a detail of this design; it is the precondition. A second path that exists only on paper does not count.

show ip ospf neighbor
show ip ospf interface brief
show ip route 10.40.0.0

Those three views answer different questions: who is adjacent, which interfaces participate and with what cost, and which path the device currently selects. A tunnel deployment adds a fourth: a line on a diagram is not proof that the adjacency formed over it, and a formed adjacency is not proof that forwarding follows the same path. Tunnel designs are where that gap shows up most often.

What the maximum metric advertises

RFC 6987 describes a router advertising its non-stub links with the maximum link metric, defined as 0xffff. The router still describes itself and its links; it simply prices them at the top of the range, so every other router computes a path through it as expensive.

This is a router-LSA change, not a topology removal. The distinction matters: flushing the router-LSA withdraws the topology information itself, which can also withdraw the relationships needed to reach the router and the prefixes behind it. Keeping the advertisement and raising its price preserves those relationships. That is the whole difference between this technique and removal.

The RFC 6987 mechanism also has nothing to do with area types or with designated-router election. A stub area blocks a category of link-state advertisements at an area boundary, and a stub router prices its own links. Similar words, unrelated machinery.

Why reachability survives and transit does not

Other routers still have a route to the branch's connected prefixes, because the branch still advertises them and the links still exist. What changes is the total cost of any path that passes through the branch on the way somewhere else. The prefixes do not move; only the price of crossing the router does.

For traffic whose source or destination is the branch itself, the expensive link is still on the only sensible path, so it is used. For traffic between the two offices, the alternate path now wins on cost, and the branch drops out of the forwarding decision without disappearing from the topology. Two directions, two different answers, and both of them are the mechanism working.

That is the behaviour to verify rather than assume. Look at the router-LSA the branch generates, then at the path another router selects for a destination behind the branch and for a destination in the other office. The two answers should differ, and if they do not, the metric change is not reaching the decision you think it is.

The last-path problem

The same RFC is explicit that the technique does not prohibit use. When the alternate path fails, routers fall back to the expensive path through the branch, because it is still a valid path and the protocol prefers a costly route over no route.

Whether that fallback is acceptable is a policy question you have to answer before deploying. A branch on a small uplink that suddenly carries inter-office traffic may be worse than an outage, and it may be exactly what you want during a maintenance window. Both answers are legitimate; silence is not.

If the requirement is a strict ban rather than a preference, metric design alone will not produce it. You need forwarding enforcement that matches the intent, plus a defined behaviour for the case where traffic arrives anyway. Advertising a path as usable and then dropping the traffic creates a black hole that is harder to diagnose than a routing loop.

For OSPFv3 the RFC discusses the R-bit as a different way to exclude transit participation. Do not assume it inherits the same last-path behaviour as the maximum-metric technique, and do not copy settings between the two address families as though they were the same feature.

Prove it under normal and failed conditions

Test twice: once with both paths available and once with the preferred path removed. The first test shows the preference working, and the second shows what the network does when the preference cannot be honoured. Skipping the second test leaves the important half unexamined.

show ip ospf database router 10.0.0.3
show ip route 172.20.8.0
traceroute 172.20.8.1

The database view shows the advertised metric, the route lookup shows the selected next hop, and the trace shows where packets actually went. When those three agree, you have a verified design rather than a configuration that looks right.

Then restore the preferred path and confirm the branch returns to carrying only its own traffic. The restore step belongs to the test rather than to cleanup, because a design that only works until the next change is not a design. Write down both outcomes, including the fallback, since the second one is the answer someone will need at three in the morning.