Thursday, July 10, 2008

OSPF - dead time expiring

I was setting up a frame-relay lab a few moments ago and I ran into strange issue. R5 and R6 are going to connect via EBGP with their loopbacks. To connect to each other's loopbacks I was using OSPF over the Frame cloud.

However, I kept getting this message on R6:

Mar 1 00:34:18.895: %OSPF-5-ADJCHG: Process 1, Nbr on Serial1/1 from FULL to DOWN, Neighbor Down: Dead timer expired
Mar 1 00:34:46.323: %OSPF-5-ADJCHG: Process 1, Nbr on Serial1/1 from LOADING to FULL, Loading Done

These are point-to-multipoint links by the way. I started monitoring the neighbor relationship to se if hello's were being received. I was alarmed when I saw this:

R6#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface 0 FULL/ - 00:01:08 Serial1/1 0 FULL/ - 00:01:50 Serial1/1

The dead time crept well below 1:20 which is the period during which I should have received a hello. I ran "debug ip ospf packet" on R6 and was not receiving any hellos from R5. But how was the adjacency forming in the first place! It did however receive replies when R6 initiated the process. This was immediately after the neighbor went down.

So I did some more searching on R5 and found this:

R5#show run int s1/1
Building configuration...

Current configuration : 217 bytes
interface Serial1/1
ip address
encapsulation frame-relay
ip ospf network point-to-multipoint
serial restart-delay 0
frame-relay map ip 506
no frame-relay inverse-arp

What's the problem? No broadcast statement on the frame-relay map command!


  1. Awesome!! Thanks. I was facing the same problem in my lab setup. 'broadcast' keyword was certainly missing..


  2. "No broadcast statement on the frame-relay map command!"

    OMG! I can't believe i missed this. Thanks!

  3. thanks mate, you made my day :)

  4. Thanks again.
    It is surprising how missing something so simple can be overlooked.
    You saved me a lot of time.


Note: Only a member of this blog may post a comment.