OSPF Stub Router: max-metric router-lsa and Graceful Maintenance

You need to reload a core router. It is carrying live traffic. The naive approach - just reload it - drops every packet in flight and triggers a reconvergence storm. The slightly-less-naive approach - shut its interfaces one at a time - is fiddly, error-prone, and still causes churn on every shutdown.

The correct approach is to tell OSPF, politely, that this router is still here but is a terrible choice for transit. Traffic drains away on its own. Nothing is dropped. Then you reload. That mechanism is max-metric router-lsa, and it is one of the highest-value, least-known OSPF features there is.

This article covers the stub router advertisement (RFC 6987), its options, and a lab demonstration of traffic draining away from a router without a single interface going down. For the fundamentals, start at the complete OSPF guide.

The idea

OSPF path selection is metric-driven. If a router advertises its transit links with a metric so large that no sane SPF calculation would ever route through it, traffic simply stops using it as a transit path - while the router itself remains fully reachable and fully adjacent.

The magic number is 65535 (0xFFFF), the maximum value of the 16-bit metric field in a Router LSA. This is not infinity - OSPF has no infinity - but it is the largest cost expressible, so any alternate path in a sanely-designed network will win.

The critical design detail: only transit links are maxed out. Stub links, including loopbacks, keep their real metric. The router stays reachable. Its services stay reachable. It just stops being used as a road.

Configuration

router ospf 1
 max-metric router-lsa

That is the manual, "I am about to do maintenance" form. It takes effect immediately and stays until you remove it.

The variant you should actually deploy on every router in your network, permanently:

router ospf 1
 max-metric router-lsa on-startup 300

This makes the router advertise max-metric for 300 seconds after every OSPF process start, then automatically return to normal. That solves a genuine problem: a router that has just booted has OSPF adjacencies up long before BGP has converged, or before its line cards have finished programming their FIBs. Without on-startup max-metric, the network starts sending it transit traffic that it cannot yet forward. This is a real, common, and completely avoidable outage.

Even better, tie it to BGP convergence rather than a fixed timer:

router ospf 1
 max-metric router-lsa on-startup wait-for-bgp

Now OSPF stays in stub-router mode until BGP signals that it has converged (or a 600-second safety timer expires). On any router that is both an OSPF speaker and a BGP edge, this should be considered mandatory.

The lab: watching traffic drain away

R2 is an ABR in area 0 with two transit links. R1 sits on the other side and has two equal-cost paths to a destination - one through R2, one through R4.

Before

R1#show ip ospf database router 2.2.2.2
  Advertising Router: 2.2.2.2
     (Link ID) Network/subnet number: 2.2.2.2
       TOS 0 Metrics: 1                             <-- the loopback (a stub link)
     (Link ID) Designated Router address: 10.0.24.2
       TOS 0 Metrics: 10                            <-- transit link
     (Link ID) Designated Router address: 10.0.12.2
       TOS 0 Metrics: 10                            <-- transit link

And R1 is load-sharing across both paths to the R2-R4 link subnet:

R1#show ip route ospf | include 10.0.24
O        10.0.24.0/30 [110/20] via 10.0.14.2, Ethernet0/2
                      [110/20] via 10.0.12.2, Ethernet0/1

Apply max-metric on R2

R2(config-router)#max-metric router-lsa

R2#show ip ospf | include originating router-LSAs
 Originating router-LSAs with maximum metric

After

R1#show ip ospf database router 2.2.2.2
  Advertising Router: 2.2.2.2
     (Link ID) Network/subnet number: 2.2.2.2
       TOS 0 Metrics: 1                             <-- loopback UNCHANGED
     (Link ID) Designated Router address: 10.0.24.2
       TOS 0 Metrics: 65535                         <-- maxed
     (Link ID) Designated Router address: 10.0.12.2
       TOS 0 Metrics: 65535                         <-- maxed

And the routing table, which is the whole story in two commands:

R1#show ip route 10.0.24.0 255.255.255.252
Routing entry for 10.0.24.0/30
  Known via "ospf 1", distance 110, metric 20, type intra area
  Routing Descriptor Blocks:
  * 10.0.14.2, from 4.4.4.4, via Ethernet0/2        <-- ONLY via R4 now

R1#show ip route 2.2.2.2
Routing entry for 2.2.2.2/32
  Known via "ospf 1", distance 110, metric 11, type intra area
  * 10.0.12.2, from 2.2.2.2, via Ethernet0/1        <-- R2 ITSELF still reachable at normal cost

Traffic that transited R2 has moved to R4. Traffic destined for R2 still arrives. No interface went down. No adjacency dropped. No packet was lost. That is the entire design intent, and it is visible in one routing table.

The options, and what they actually do

By default, max-metric touches only the transit links in the Router LSA. Three options extend it:

If your router is an ABR or an ASBR, the bare command is not enough. It stops intra-area transit but leaves inter-area and external traffic pointing straight at you. From the lab, with summary-lsa added:

R2(config-router)#max-metric router-lsa include-stub summary-lsa external-lsa

R1#show ip route 3.3.3.3 | include metric
  Known via "ospf 1", distance 110, metric 16711690, type inter area

R1#show ip route 2.2.2.2 | include metric
  Known via "ospf 1", distance 110, metric 65545, type intra area

The inter-area route through R2 now costs 16.7 million. The loopback route (with include-stub) costs 65545. Nothing in a sane topology is going to pick those.

An IOS trap that cost us fifteen minutes

no max-metric router-lsa include-stub summary-lsa external-lsa does not remove max-metric. It removes only the options, leaving plain max-metric router-lsa active and the router still advertising 65535 on its transit links. We chased phantom metric values for a while before running:

R2#show running-config | include max-metric
 max-metric router-lsa

The fix is no max-metric router-lsa with no arguments. This "the negation only removes the options" behaviour is general across IOS (it bit us again the same session with no redistribute static subnets metric-type 2). Always verify with show running-config | section, never assume the negation did what you meant.

Where max-metric does not help

If the router is the only path, traffic still comes. Max-metric makes a router unattractive, not unusable. If R2 is the sole ABR into an area, maxing its metric changes nothing, because there is no alternative. This is not a limitation - a routing protocol cannot conjure a path that does not exist - but it is a constraint you must design around. If you need to reload a single-homed ABR gracefully, the answer is redundancy, not max-metric.

It does not drain BGP. Max-metric is an OSPF mechanism. If the router is also a BGP speaker, its BGP next-hops remain valid and BGP will keep sending it traffic. For a graceful BGP drain you need bgp graceful-shutdown (RFC 8326) or a policy that prepends and lowers local-pref on the way out. Use both together.

Related: stub router vs graceful restart

These get confused and they solve different problems:

They are opposites, and both are correct in their own context. Graceful restart says "trust me, keep sending". Max-metric says "stop sending". Use graceful restart for an in-service software upgrade on redundant hardware; use max-metric when the box is genuinely going away.

Key takeaways

• max-metric router-lsa advertises transit links at 65535 so traffic routes around the router, while leaving adjacencies up and the router's own addresses reachable at normal cost.
• Deploy max-metric router-lsa on-startup wait-for-bgp permanently on every OSPF+BGP router. A freshly-booted router with converged OSPF and unconverged BGP is a black hole, and this one line prevents it.
• On an ABR or ASBR, add summary-lsa and external-lsa. The bare command only stops intra-area transit.
• include-stub also maxes the loopbacks. Usually you do not want that - keeping the router reachable is the point.
• no max-metric router-lsa <options> removes only the options. Use the bare negation and verify with show running-config.
• Max-metric makes a router unattractive, not unusable. If it is the only path, traffic still comes.
• It is an OSPF mechanism only. Drain BGP separately with graceful-shutdown.

Next: the OSPF forwarding address, an optimisation that quietly becomes an outage. The full cluster index lives on the OSPF pillar guide.