Improving OSPF Convergence Times

Problem

You want to speed up convergence of OSPF routes in case a path fails with no hardware indication, which might happen on an Ethernet network.

Solution

Reduce the interval at which OSPF exchanges Hello messages and, in parallel, decrease the dead interval:

	[edit protocols ospf area 0.0.0.0 ]
	aviva@RouterG# set interface fe-0/0/1 hello-interval 2 
	aviva@RouterG# set interface fe-0/0/1 dead-interval 8 
	aviva@RouterG# set interface fe-1/0/1 hello-interval 2 
	aviva@RouterG# set interface fe-1/0/1 dead-interval 8 

Discussion

The OSPF protocol specifications were developed when routers and network interfaces were slower to allow enough time for LSAs to reach all nodes and for the SPF calculation to run on all routers. Modern routers and interfaces are much faster, so one strategy for speeding up route convergence is to modify the default OSPF timers. The base JUNOS OSPF code already optimizes convergence times by doing fast link detection and flooding, by quickly regenerating LSAs, and by quickly scheduling SPF calculations, so you don often need to modify the timers.

When changing OSPF timers, you must modify each interface, changing the hello timer and dead timer intervals. The default timer settings, as defined in the OSPF specification, are 10 seconds for sending periodic Hello packets and 40 seconds for declaring the adjacency dead, or down (four times the hello interval):

	aviva@RouterG> show ospf interface detail
	Interface State Area DR ID BDR ID Nbrs
	fe-0/0/1.0 DR 0.0.0.0 192.168.19.1 192.168.18.1 1
	Type: LAN, Address: 10.0.1.2, Mask: 255.255.255.0, MTU: 1500, Cost: 1
	DR addr: 10.0.1.2, BDR addr: 10.0.1.1, Adj count: 1, Priority: 128
	Hello: 10, Dead: 40, ReXmit: 5, Not Stub
	Auth type: None
	fe-1/0/1.0 DR 0.0.0.0 192.168.19.1 192.168.17.1 1
	Type: LAN, Address: 10.0.0.1, Mask: 255.255.255.0, MTU: 1500, Cost: 1
	DR addr: 10.0.0.1, BDR addr: 10.0.0.2, Adj count: 1, Priority: 128
	Hello: 10, Dead: 40, ReXmit: 5, Not Stub
	Auth type: None

This recipe lowers the hello timer interval to two seconds and the dead timer interval to eight seconds. You have to change the timers on each interface and on all routers in the area because adjacencies can be established only between systems with the same timer values (as required by the OSPF specifications). If you do not change the timers on all interfaces, OSPF cannot establish the adjacency. Here, you see that the adjacency to the router at 10.0.1.1 through interface fe-0/0/1 has broken because the timers are different:

	aviva@RouterG> show ospf neighbor
	 Address Interface State ID Pri 
Dead
	10.0.0.2 fe-1/0/1.0 Full 192.168.17.1 128 38

When the timers are the same, the adjacency comes back up:

	aviva@RouterG> show ospf neighbor 
	 Address Interface State ID Pri Dead
	10.0.1.1 fe-0/0/1.0  Full 192.168.18.1 128 33
	10.0.0.2 fe-1/0/1.0 Full 192.168.17.1 128 37

For data traveling at gigabit rates, even decreasing the OSPF hello timer may not detect failures fast enough. An alternative to adjusting the OSPF timer intervals is to use the BFD, which detects communication failures with a forwarding-plane next hop. BFD is useful on interfaces where you can detect failure quickly, such as Ethernet interfaces. Other interface types, such as SONET interfaces, already have built-in failure detection, so you don need to use BFD.

BFD is a simple hello protocol. A pair of systems exchange BFD packets periodically, and if a system stops receiving the packets for long enough, some component in that particular bidirectional path to the neighboring system is assumed to have failed. If you want to shorten the OSPF link failure detection time to 1.5 seconds, set the BFD packet exchange interval to 500 milliseconds:

	[edit protocols ospf area 0.0.0.0 ]
	aviva@RouterG# set interface fe-0/0/1 bfd-liveness-detection minimum-interval 500 

By default, BFD multiplies the packet exchange interval by three to determine the link detection failure time. Configuring an interval of 500 milliseconds results in a failure time of 1.5 seconds.

You also need to configure BFD on the interface at the other end of the link. Unlike the OSPF timers, you do not have to enable BFD on all interfaces in the area. Use the show bfd session command to see BFD information:

	aviva@RouterG>  
show bfd session detail
	 Transmit
	Address State Interface Detect Time Interval Multiplier
	10.0.1.1 Up fe-0/0/1.0 1.500 0.500 3
	 Client OSPF, TX interval 0.500, RX interval 0.500, multiplier 3
	 Session up time 00:13:02
	 Local diagnostic None, remote diagnostic None
	 Remote heard, hears us
	10.0.0.2 Up fe-1/0/1.0 1.500 0.500 3
	 Client OSPF, TX interval 0.500, RX interval 0.500, multiplier 3
	 Session up time 00:01:25
	 Local diagnostic None, remote diagnostic CtlExpire
	 Remote heard, hears us
	2 sessions, 2 clients
	Cumulative transmit rate 4.0 pps, cumulative receive rate 4.0 pps

This output shows two BFD sessions on the routers two interfaces. The BFD client is OSPF, and the timers that we configured are shown. The last line for each interface, Remote heard, hears us, indicates that the OSPF link is operating properly. If the link fails, neither side initially hears the other:

	aviva@RouterG> show bfd session detail
	Transmit
	Address State Interface Detect Time Interval Multiplier
	10.0.1.1 Up fe-0/0/1.0 1.500 0.500 3
	 Client OSPF, TX interval 0.500, RX interval 0.500, multiplier 3
	 Session up time 00:16:55
	 Local diagnostic None, remote diagnostic None
	 Remote heard, hears us
	10.0.0.2 AdminDown fe-1/0/1.0 3.000 1.000 3
	 Session down time 00:00:09, previous up time 00:05:09
	 Local diagnostic NbrSignal, remote diagnostic AdminDown
	 Remote not heard, doesn	 hear us

Once the link is completely down and the BFD session fails, the link is no longer shown:

	aviva@RouterG> show bfd session detail
	Transmit
	Address State Interface Detect Time Interval Multiplier
	10.0.1.1 Up fe-0/0/1.0 1.500 0.500 3
	 Client OSPF, TX interval 0.500, RX interval 0.500, multiplier 3
	 Session up time 00:18:10
	 Local diagnostic None, remote diagnostic None
	 Remote heard, hears us
	1 sessions, 1 clients
	Cumulative transmit rate 2.0 pps, cumulative receive rate 2.0 pps