Troubleshooting OSPF Adjacencies And Authentication

A Cisco CCNP BSCI 642-901 Certification Exam Tutorial

By Chris Bryant, CCIE #12933

There are two major reasons OSPF authentication fails - either the authentication is only configured on one neighbor, or the password is misspelled.

Luckily, these problems are both easy to spot with debug ip ospf adj. "adj" is obviously short for "adjacency", but if I had a nickel for every time I entered "adjacency" with this command... well, I'd have a lot of nickels! You have to use "adj", because the full word doesn't work with this debug!

R3#debug ip ospf adjacency
^
% Invalid input detected at '^' marker.

R3#debug ip ospf adj
OSPF adjacency events debugging is on

For the following labs, R2 (OSPF RID: 172.12.23.2) and R3 have an OSPF adjacency that is currently protected with MD5 authentication. Now I'll remove message-digest authentication from R3's ethernet interface and replace it with clear-text authentication. As expected, the adjacency goes down quickly. (Using the ip ospf authentication command with no encryption type specified will result in a default to clear-text authentication.)

R3(config)#int e0
R3(config-if)#ip ospf authentication

00:52:44: %OSPF-5-ADJCHG: Process 1, Nbr 172.12.23.2 on Ethernet0 from FULL to DOWN, Neighbor Down: Dead timer expired

We know the adjacency is down, but in the real world and the Cisco exam room, that's just not enough. How would you find the reason for the downed adjacency? By running debug ip ospf adj.

R3#debug ip ospf adj
OSPF adjacency events debugging is on

00:54:04: OSPF: Rcv pkt from 172.12.23.2, Ethernet0 : Mismatch Authentication type. Input packet specified type 2, we use type 1

R3#undebug all
All possible debugging has been turned off

The debug pays off right away, as we get a message that there's a mismatch in the authentication type. The incoming Hello is using "type 2" authentication (MD5). Since R3's ethernet0 interface is running "type 1" (clear-text), we've got a mismatch problem. By changing R3's type back to MD5, the adjacency will form again. And once you see what the problem is, always turn your debugs off with undebug all!

R3(config)#interface e0
R3(config-if)#ip ospf authentication message-digest

00:56:50: %SYS-5-CONFIG_I: Configured from console by console

00:56:54: %OSPF-5-ADJCHG: Process 1, Nbr 172.12.23.2 on Ethernet0 from LOADING to FULL, Loading Done

If the authentication type matches but the password does not, the debug will give a different result. I'll remove the key from R3's E0 interface and replace it with a different password that's off by just one letter.

R3(config)#int e0
R3(config-if)#no ip ospf message-digest-key 1 MD5 CCIE
R3(config-if)#ip ospf message-digest-key 1 MD5 CCIEE

00:27:59: %OSPF-5-ADJCHG: Process 1, Nbr 172.12.123.2 on Ethernet0 from FULL to DOWN, Neighbor Down: Dead timer expired

What does a debug reveal?

R3#
00:28:49: OSPF: Rcv pkt from 172.12.23.2, Ethernet0 : Mismatch Authentication Key - Message Digest Key 1

That's about as self-explanatory as a debug gets! Knowing your debugs truly means the difference between just "trying something" and knowing what to do. With OSPF, debug ip ospf adj is the king of debugs and the command that will successfully diagnose most OSPF issues.

To your success,

Chris Bryant

CCIE #12933

chris@thebryantadvantage.com