> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # OSPF Stub Router: max-metric router-lsa and Graceful Maintenance - URL: https://www.pinglabz.com/ospf-max-metric-stub-router/ - Published: 2026-07-12T07:18:23.000Z - Updated: 2026-08-24T09:42:52.000Z - Description: max-metric router-lsa tells OSPF a router is still here but a terrible choice for transit, so traffic drains before you reload it. Covers the RFC 6987 stub router advertisement, its options, and a lab demonstration. - Author: Jaime - Tags: OSPF, Labs, CCIE, #Import 2026-08-01 19:54 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](https://www.pinglabz.com/ospf/). ## 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: **include-stub** Also max out the metric on stub links, including loopbacks. The router becomes hard to reach, not just useless as transit. Use this only if you genuinely want traffic to stop arriving at the router's own addresses too. **summary-lsa \[metric\]** For an ABR: also max out the metric in the Type-3 summary LSAs it generates. Without this, inter-area traffic keeps choosing this ABR because its summaries still look cheap. Default max is 16711680 (0xFF0000). **external-lsa \[metric\]** For an ASBR: also max out the metric in the Type-5 external LSAs it generates. Same reasoning - without it, external traffic keeps coming to this ASBR. **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" behavior 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: max-metric (stub router) **Says:** "I am here but do not route through me." **For:** planned maintenance, and post-boot convergence protection. **Traffic:** actively moved away. Graceful restart / NSF **Says:** "My control plane is restarting, keep forwarding through me, my FIB is intact." **For:** a supervisor switchover on a dual-RP chassis. **Traffic:** deliberately kept in place. 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 ` 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](https://www.pinglabz.com/ospf-forwarding-address/), an optimization that quietly becomes an outage. The full cluster index lives on the [OSPF pillar guide](https://www.pinglabz.com/ospf/).