Logging OSPF Adjacency Changes

Problem

You want to monitor OSPF adjacency state changes to ensure network stability.

Solution

The log-adjacency-changes configuration command instructs the router to create a log message whenever two OSPF routers establish or break their adjacency relationship:

Router2#configure terminal 
Enter configuration commands, one per line. End with CNTL/Z.
Router2(config)#router ospf 12
Router2(config-router)#log-adjacency-changes
Router2(config-router)#exit
Router2(config)#end
Router2#

Discussion

No routes are exchanged between routers if they lose their adjacency relationship. Every time this relationship is lost, the corresponding routes are removed, and every router in the area must be updated with the new network topology. This can be quite disruptive to a network. So it can be extremely useful to log these changes for troubleshooting, as well as for reconstructing serious problems that occurred in the past. We recommend using this option.

Here are some example log messages. The first message shows that the adjacency has been lost due to an expired timer. This means that this router has not heard its neighbor's regularly scheduled "hello" messages recently, so it needs to delete its routes. A few minutes later, the neighbor has come back and reestablished its adjacency:

Oct 14 09:54:13: %OSPF-5-ADJCHG: Process 12, Nbr 172.25.25.1 on Serial0/0 from FULL to DOWN, Neighbor Down: Dead timer expired
Oct 14 09:57:43: %OSPF-5-ADJCHG: Process 12, Nbr 172.25.25.1 on Serial0/0 from LOADING to FULL, Loading Done

Starting in 12.1, Cisco added the keyword detail:

Router2#configure terminal 
Enter configuration commands, one per line. End with CNTL/Z.
Router2(config)#router ospf 12
Router2(config-router)#log-adjacency-changes detail
Router2(config-router)#exit
Router2(config)#end
Router2#

When you enable the detailed logging, you get considerably more information. It now shows all of the various stages that OSPF neighbors need to go through to establish their adjacencies:

%OSPF-5-ADJCHG: Process 12, Nbr 172.25.25.1 from FULL to DOWN, Neighbor Down: Dead timer expired
%OSPF-5-ADJCHG: Process 12, Nbr 172.25.25.1 from DOWN to INIT, Received Hello
%OSPF-5-ADJCHG: Process 12, Nbr 172.25.25.1 from INIT to 2WAY, 2-Way Received
%OSPF-5-ADJCHG: Process 12, Nbr 172.25.25.1 from 2WAY to EXSTART, AdjOK?
%OSPF-5-ADJCHG: Process 12, Nbr 172.25.25.1 from EXSTART to EXCHANGE, Negotiation Done
%OSPF-5-ADJCHG: Process 12, Nbr 172.25.25.1 from EXCHANGE to LOADING, Exchange Done
%OSPF-5-ADJCHG: Process 12, Nbr 172.25.25.1 from LOADING to FULL, Loading Done

This level of detail is rarely required unless you suspect that there is a problem with the handshake process between two routers. In that case, it might be more effective to use debugging as discussed in Recipe 8.21. We wouldn't normally recommend using the detail option in production networks because it just fills up the logs with extra messages. It is usually sufficient to know when two neighbors lost their adjacency and when they managed to reestablish it.