- Cisco Networking: OSPF stub router advertisement

Cisco IOS provides an OSPF feature known as stub router advertisement. Simply put, a router can be configured to advertise all its OSPF routes with a maximum (infinite) metric, persuading traffic to flow over alternate paths. This can be handy for elegantly forcing a failover condition when a router in the primary path needs to be taken offline, or for implementing a delay between boot time and traffic forwarding to allow routing table convergence to complete.

Routers 1 through 4 have been configured with all interfaces in OSPF area 0, and R4 provides the only connection between the 192.168.1.0/24 subnet and the rest of the network. R4's interface facing R3 has been configured with a cost of 20 so that the path via R2 is preferred.

Graceful Shutdown

Assume a critical Cisco security advisory is released for the version of IOS running on R2. After you've upgraded the image to resolve the vulnerability, the router needs to be reloaded so the new IOS can run. Unfortunately, R2 is currently the primary path for all traffic destined for the 192.168.1.0/24 subnet:

R4# show ip route 192.168.1.0 Routing entry for 192.168.1.0/24   Known via "ospf 1", distance 110, metric 21, type intra area   Last update from 10.0.24.2 on FastEthernet0/1, 00:01:56 ago   Routing Descriptor Blocks:   * 10.0.24.2, from 1.1.1.1, 00:01:56 ago, via FastEthernet0/1   Route metric is 21, traffic share count is 1 

Simply reloading the router will cause a number of packet drops before OSPF reconverges and begins forwarding traffic out via R3. Instead, stub router advertisement can be used in this situation to force a graceful failover before reloading the router. Stub routing can be turned on temporarily with the max-metric router-lsa command under the OSPF process:

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

Stub routing operation can be verified with show ip ospf:

R2# show ip ospf  Routing Process "ospf 1" with ID 2.2.2.2  Start time: 00:00:20.308, Time elapsed: 00:00:52.988  Supports only single TOS(TOS0) routes  Supports opaque LSA  Supports Link-local Signaling (LLS)  Supports area transit capability  Originating router-LSAs with maximum metric  Condition: always, State: active  ... 

Here's how R4 normally sees R2's router (type 1) LSA:

R4# show ip ospf database router 2.2.2.2  OSPF Router with ID (4.4.4.4) (Process ID 1)  Router Link States (Area 0)  LS age: 38   Options: (No TOS-capability, DC)   LS Type: Router Links   Link State ID: 2.2.2.2   Advertising Router: 2.2.2.2   LS Seq Number: 80000007   Checksum: 0xA6D9   Length: 48   Number of Links: 2  Link connected to: a Transit Network  (Link ID) Designated Router address: 10.0.24.4  (Link Data) Router Interface address: 10.0.24.2   Number of TOS metrics: 0    TOS 0 Metrics: 10  Link connected to: a Transit Network  (Link ID) Designated Router address: 10.0.12.2  (Link Data) Router Interface address: 10.0.12.2   Number of TOS metrics: 0    TOS 0 Metrics: 10 

And after enabling stub routing:

R4# show ip ospf database router 2.2.2.2  OSPF Router with ID (4.4.4.4) (Process ID 1)  Router Link States (Area 0)  LS age: 2   Options: (No TOS-capability, DC)   LS Type: Router Links   Link State ID: 2.2.2.2   Advertising Router: 2.2.2.2   LS Seq Number: 80000008   Checksum: 0xC2D0   Length: 48   Number of Links: 2  Link connected to: a Transit Network  (Link ID) Designated Router address: 10.0.24.4  (Link Data) Router Interface address: 10.0.24.2   Number of TOS metrics: 0    TOS 0 Metrics: 65535  Link connected to: a Transit Network  (Link ID) Designated Router address: 10.0.12.2  (Link Data) Router Interface address: 10.0.12.2   Number of TOS metrics: 0    TOS 0 Metrics: 65535 

The metrics for R2's advertised routes have increased from 10 to 65535, the maximum value. Consequently, R4 now sees R3 as the better path to R1:

R4# show ip route 192.168.1.0 Routing entry for 192.168.1.0/24   Known via "ospf 1", distance 110, metric 31, type intra area   Last update from 10.0.34.3 on FastEthernet0/0, 00:03:09 ago   Routing Descriptor Blocks:   * 10.0.34.3, from 1.1.1.1, 00:03:09 ago, via FastEthernet0/0   Route metric is 31, traffic share count is 1 

As R2 is no longer being relied upon to carry transit traffic, it can be reloaded without affecting broader network operation.

Startup Delay

Just as stub routing can be used to avoid forwarding traffic in preparation for a disruption, it can also be triggered automatically for a brief period after service has been restored, to allow the routing topology time to fully converge. For example, instead of advertising routes and forwarding traffic as soon as the OSPF adjacencies are formed, we can employ an artificial delay of 120 seconds to ensure all link-state updates have been received and processed (typically this would only be needed on a very large network). This is done by appending the on-startup argument to the max-metric router-lsa command:

R2(config-router)# max-metric router-lsa on-startup 120 

With the above command applied, we can verify that stub routing is in effect for the first 120 seconds after boot:

R2# show ip ospf  Routing Process "ospf 1" with ID 2.2.2.2  Start time: 00:00:13.580, Time elapsed: 00:00:34.052  Supports only single TOS(TOS0) routes  Supports opaque LSA  Supports Link-local Signaling (LLS)  Supports area transit capability  Originating router-LSAs with maximum metric, Time remaining: 00:01:26  Condition: on startup for 120 seconds, State: active  ... 

Alternatively, the wait-for-bgp keyword can be used in place of a seconds count if the router is running BGP. This will force stub routing to remain active until the BGP table has settled or 600 seconds have passed, whichever comes first.