cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
40226
Views
0
Helpful
9
Replies

%OSPF-5-ADJCHG: Neighbor Down: Dead timer expired

asaykao73
Level 1
Level 1

Hi All,

I am seeing a lot of OSPF "Dead timer expired" and OSPF adjacency drop off for for R1 (see below).

Physical topology.

R1 (Cisco 7206) --> R2 (Cisco 7606)

R1 = 203.17.101.x

R2 = DR = 203.17.101.A

Is there a way to narrow down what is causing this? My understanding is that the dead timer is an indication that no hello packets are being received. I can also confirm that the link between R1 and R2 remains up/up.

This is the log from another router running the same OSPF process showing R1 going down.

Nov 30 05:47:32.342 AEDT: %OSPF-5-ADJCHG: Process 100, Nbr 203.17.101.x
on GigabitEthernet0/0 from 2WAY to DOWN, Neighbor Down: Dead timer expired

Nov 30 06:15:32.401 AEDT: %OSPF-5-ADJCHG: Process 100, Nbr 203.17.101.x
on GigabitEthernet0/0 from 2WAY to DOWN, Neighbor Down: Dead timer expired

Nov 30 17:43:32.140 AEDT: %OSPF-5-ADJCHG: Process 100, Nbr 203.17.101.x
on GigabitEthernet0/0 from 2WAY to DOWN, Neighbor Down: Dead timer expired

Dec  1 00:35:09.808 AEDT: %OSPF-5-ADJCHG: Process 100, Nbr 203.17.101.x
on GigabitEthernet0/0 from 2WAY to DOWN, Neighbor Down: Dead timer expired

Dec  1 00:59:46.163 AEDT: %OSPF-5-ADJCHG: Process 100, Nbr 203.17.101.x
on GigabitEthernet0/0 from 2WAY to DOWN, Neighbor Down: Dead timer expired

Dec  1 05:28:56.613 AEDT: %OSPF-5-ADJCHG: Process 100, Nbr 203.17.101.x
on GigabitEthernet0/0 from 2WAY to DOWN, Neighbor Down: Dead timer expired

R1:

R1#sh ip ospf interface gigabitEthernet 0/2
GigabitEthernet0/2 is up, line protocol is up
  Internet Address 203.10.110.x/27, Area 0.0.0.0
  Process ID 100, Router ID 203.17.101.x, Network Type BROADCAST, Cost: 1
  Transmit Delay is 1 sec, State DROTHER, Priority 1
  Designated Router (ID) 203.17.101.A, Interface address 203.10.110.A
  Backup Designated router (ID) 203.17.101.B, Interface address 203.10.110.B
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:05
  Supports Link-local Signaling (LLS)
  Cisco NSF helper support enabled
  IETF NSF helper support enabled
  Index 1/1, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 0, maximum is 40
  Last flood scan time is 0 msec, maximum is 28 msec
  Neighbor Count is 17, Adjacent neighbor count is 2
    Adjacent with neighbor 203.17.101.A  (Designated Router)
    Adjacent with neighbor 203.17.101.B  (Backup Designated Router)
  Suppress hello for 0 neighbor(s)

R2:

R2#sh ip ospf interface vlan 11
Vlan11 is up, line protocol is up
  Internet Address 203.10.110.A/27, Area 0
  Process ID 100, Router ID 203.17.101.A, Network Type BROADCAST, Cost: 2
  Transmit Delay is 1 sec, State DR, Priority 15
  Designated Router (ID) 203.17.101.A, Interface address 203.10.110.A
  Backup Designated router (ID) 203.17.101.B, Interface address 203.10.110.B
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:06
  Supports Link-local Signaling (LLS)
  Index 3/3, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 40
  Last flood scan time is 0 msec, maximum is 8 msec
  Neighbor Count is 17, Adjacent neighbor count is 17
    Adjacent with neighbor 203.17.101.x
    Adjacent with neighbor 203.17.101.y
    Adjacent with neighbor 203.17.101.B  (Backup Designated Router)
    Adjacent with neighbor 203.17.101.z

.

.

  Suppress hello for 0 neighbor(s)

Thanks.

Andy

9 Replies 9

asaykao73
Level 1
Level 1

Could it possibly be a MTU mismatch between the two interfaces???

R1:

interface GigabitEthernet0/2
description Connect to R2:Gi2/5
ip address 203.10.110.x 255.255.255.224
ip flow ingress
load-interval 30
media-type rj45
speed 1000
duplex full
no negotiation auto
mpls ip
no clns route-cache


R2::

interface GigabitEthernet2/5
description Connect to R1:Gi0/2
switchport
switchport access vlan 11
switchport mode access
mtu 9216
no ip address
load-interval 30
speed 1000
duplex full

Notice no "mtu 9216" set on R1:Gi0/2.

asaykao73 wrote:

Could it possibly be a MTU mismatch between the two interfaces???

R1:

interface GigabitEthernet0/2
description Connect to R2:Gi2/5
ip address 203.10.110.x 255.255.255.224
ip flow ingress
load-interval 30
media-type rj45
speed 1000
duplex full
no negotiation auto
mpls ip
no clns route-cache


R2::

interface GigabitEthernet2/5
description Connect to R1:Gi0/2
switchport
switchport access vlan 11
switchport mode access
mtu 9216
no ip address
load-interval 30
speed 1000
duplex full

Notice no "mtu 9216" set on R1:Gi0/2.

Andy

Yes, a mismatch in mtu would affect the neighborship.

Jon

Jun 2 08:17:44.503: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.9 on GigabitEthernet0/0/1.9 from FULL to DOWN, Neighbor Down: Dead timer expired
Jun 2 08:18:20.914: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.9 on GigabitEthernet0/0/1.9 from LOADING to FULL, Loading Done

 

And if the "ip mtu" matches, but periodically in the logs appears this message (a couple of times a day - 1-3) does it make sense to increase the dead interval on this interface and on the corresponding interface of another router?

Hello

Post the output of this debug into a file

debug ip ospf adj


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

It may preclude the drops, but then if you have a real issue, the time to detect one will increase. (Further on Ethernet, I recall the detection time is 40 seconds, by default.)

This issue might also be caused by a very busy interface, w/o QoS.

This is a backup channel with a Mikrotik SXT-LTE, which is needed "to be". 

 

Yes, default timers are 10 seconds for hello and 40 seconds for dead. I think to leave 10 seconds hello and make 120 seconds (2 minutes) dead on both sides of the link.

Or, you might try decreasing the hello interval while increasing the number of missed hellos.

Hello @kapydan88 ,

I agree with @Joseph W. Doherty . Likely the platforms in use have not a hidden system queue for OSPF messages and when the link becomes full there is a drop probability for OSPF hellos messages. IF four of them are lost in a row the dead interval will trigger the OSPF neighborship to be turned down as the log messages show.

You may need an explicit QoS configuration to protect OSPF traffic on both sides of the link. The configuration details are platform dependent so it could be interesting if you post the show version of both devices.

The local node should be a router given the interface numbering starting with 0 :

>> GigabitEthernet0/0/1.9

 

Edit:

if it is a backup link over a wireless technology yes increasing the dead interval can be a wise move.

 

Hope to help

Giuseppe

 

Yes, its ISR 4331 from one side and Mikrotik SXT from second.

 

192.168.1.10 - isr side

192.168.1.9 - Mikrotik side

 

4331_wr_1#sh ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
192.168.10.2 0 FULL/ - 00:00:37 192.168.22.1 Tunnel109
192.168.1.9 1 FULL/DR 00:00:37 192.168.1.9 GigabitEthernet0/0/1.9
4331_wr_1#sh run | s ospf
router ospf 1
redistribute connected subnets
network 192.168.22.0 0.0.0.3 area 192.168.22.0
network 192.168.1.8 0.0.0.3 area 192.168.1.8
4331_wr_1#sh run int gi0/0/1.9
Building configuration...

Current configuration : 150 bytes
!
interface GigabitEthernet0/0/1.9
encapsulation dot1Q 901
ip address 192.168.1.10 255.255.255.252
ip ospf mtu-ignore
ip ospf cost 65535
end

4331_wr_1#

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: