Buy or Renew
Buy or Renew
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
5539
Views
1
Helpful
1
Replies

why did OSPF routing convergence take 6 sec

Go to solution
shelley_wang
Level 1
Level 1

‎11-23-2011 12:27 PM - edited ‎03-07-2019 03:34 AM

I have 2 routers connected to each other. Primary link has ospf, and backup link has static routing.

After ospf detected that primary link went down at 18:34:24.539, R1 deleted primary route at 18:34:30.039. So it took almost 6 sec to update the routing table. This is too long for OSPF routing convergence. Is there anything wrong with my configuration? Is there any way to improve this convergence time?

               10.1.5.1                10.1.5.2

   R1         --------------ospf----------------       R2   (Loopback:15.2.1.2)        

                                                                               

                 --------------static--------------                     

               10.1.7.1                10.1.7.2

R1’s configuration:

interface GigabitEthernet7/9

ip address 10.1.5.1 255.255.255.0

ip ospf dead-interval minimal hello-multiplier 3

ip ospf mtu-ignore

load-interval 30

no cdp enable

!

router ospf 10

router-id 10.1.5.1

log-adjacency-changes

redistribute connected subnets

redistribute static subnets

network 10.1.5.0 0.0.0.255 area 0

maximum-paths 1

distance ospf external 240

!

ip classless

ip route 15.2.1.2 255.255.255.255 10.1.7.2 200

debug on R1:

Nov 23 18:34:24.539: %OSPF-5-ADJCHG: Process 10, Nbr 15.2.1.2 on GigabitEthernet7/9 from FULL to DOWN, Neighbor Down: Dead timer expired

Nov 23 18:34:24.539: OSPF: Neighbor change Event on interface GigabitEthernet7/9

Nov 23 18:34:24.539: OSPF: DR/BDR election on GigabitEthernet7/9

Nov 23 18:34:24.539: OSPF: Elect BDR 10.1.5.1

Nov 23 18:34:24.539: OSPF: Elect DR 10.1.5.1

Nov 23 18:34:24.539: OSPF: Elect BDR 0.0.0.0

Nov 23 18:34:24.539: OSPF: Elect DR 10.1.5.1

Nov 23 18:34:24.539:       DR: 10.1.5.1 (Id)   BDR: none

Nov 23 18:34:24.539: OSPF: Remember old DR 15.2.1.2 (id)

Nov 23 18:34:24.735: OSPF: Send hello to 224.0.0.5 area 0 on GigabitEthernet7/9 from 10.1.5.1

Nov 23 18:34:25.039: OSPF: No full nbrs to build Net Lsa for interface GigabitEthernet7/9

Nov 23 18:34:25.075: OSPF: Send hello to 224.0.0.5 area 0 on GigabitEthernet7/9 from 10.1.5.1

Nov 23 18:34:25.411: OSPF: Send hello to 224.0.0.5 area 0 on GigabitEthernet7/9 from 10.1.5.1

Nov 23 18:34:25.747: OSPF: Send hello to 224.0.0.5 area 0 on GigabitEthernet7/9 from 10.1.5.1

Nov 23 18:34:26.083: OSPF: Send hello to 224.0.0.5 area 0 on GigabitEthernet7/9 from 10.1.5.1

Nov 23 18:34:26.419: OSPF: Send hello to 224.0.0.5 area 0 on GigabitEthernet7/9 from 10.1.5.1

Nov 23 18:34:26.755: OSPF: Send hello to 224.0.0.5 area 0 on GigabitEthernet7/9 from 10.1.5.1

Nov 23 18:34:27.091: OSPF: Send hello to 224.0.0.5 area 0 on GigabitEthernet7/9 from 10.1.5.1

Nov 23 18:34:27.235: %LINK-3-UPDOWN: Interface GigabitEthernet7/11, changed state to up

Nov 23 18:34:27.239: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet7/11, changed state to up

Nov 23 18:34:27.234: %LINK-SP-3-UPDOWN: Interface GigabitEthernet7/11, changed state to up

Nov 23 18:34:27.238: %LINEPROTO-SP-5-UPDOWN: Line protocol on Interface GigabitEthernet7/11, changed state to up

Nov 23 18:34:27.247: %LINK-3-UPDOWN: Interface GigabitEthernet7/14, changed state to up

Nov 23 18:34:27.246: %LINK-SP-3-UPDOWN: Interface GigabitEthernet7/14, changed state to up

Nov 23 18:34:27.251: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet7/14, changed state to up

Nov 23 18:34:27.427: OSPF: Send hello to 224.0.0.5 area 0 on GigabitEthernet7/9 from 10.1.5.1

Nov 23 18:34:27.763: OSPF: Send hello to 224.0.0.5 area 0 on GigabitEthernet7/9 from 10.1.5.1

Nov 23 18:34:28.099: OSPF: Send hello to 224.0.0.5 area 0 on GigabitEthernet7/9 from 10.1.5.1

Nov 23 18:34:27.250: %LINEPROTO-SP-5-UPDOWN: Line protocol on Interface GigabitEthernet7/14, changed state to up

Nov 23 18:34:28.435: OSPF: Send hello to 224.0.0.5 area 0 on GigabitEthernet7/9 from 10.1.5.1

Nov 23 18:34:28.771: OSPF: Send hello to 224.0.0.5 area 0 on GigabitEthernet7/9 from 10.1.5.1

Nov 23 18:34:29.107: OSPF: Send hello to 224.0.0.5 area 0 on GigabitEthernet7/9 from 10.1.5.1

Nov 23 18:34:29.443: OSPF: Send hello to 224.0.0.5 area 0 on GigabitEthernet7/9 from 10.1.5.1

Nov 23 18:34:29.779: OSPF: Send hello to 224.0.0.5 area 0 on GigabitEthernet7/9 from 10.1.5.1

Nov 23 18:34:30.039: RT: del 15.2.1.2/32 via 10.1.5.2, ospf metric [110/2]

Nov 23 18:34:30.039: RT: delete subnet route to 15.2.1.2/32

Nov 23 18:34:30.039: RT: add 15.2.1.2/32 via 10.1.7.2, static metric [200/0]

Labels:
0 Helpful
1 Accepted Solution

Accepted Solutions

Go to solution
Peter Paluch
Cisco Employee
Cisco Employee

‎11-23-2011 12:46 PM

Hello,

The OSPF convergence is a difficult topic because on Cisco routers, there are several timers deliberately slowing down the convergence so that a flapping link or a transitory outage does not result in huge and unnecessary recalculations. What you are seeing is the initial SPF delay that is set to 5 seconds, i.e., after receiving a new LSA, the router schedules the SPF run to take place 5 seconds after the arrival of this new LSA. It is expected that there may be more LSAs coming during this period, so a SPF run after 5 seconds will process all of them at once. These 5 seconds constitute the major part of the delay you are seeing. There are also other timers in place (LSA generation delay in particular) but they should not be as important right now.

What you could do is to reduce the initial SPF delay down to a reasonable time, say, 500 ms. The command is:

router ospf 1

timers throttle spf 500 1000 10000

Read more about the command here:

http://www.cisco.com/en/US/docs/ios/12_2s/feature/guide/fs_spftrl.html

Best regards,

Peter

View solution in original post

1 Reply 1

Go to solution
Peter Paluch
Cisco Employee
Cisco Employee

‎11-23-2011 12:46 PM

Hello,

The OSPF convergence is a difficult topic because on Cisco routers, there are several timers deliberately slowing down the convergence so that a flapping link or a transitory outage does not result in huge and unnecessary recalculations. What you are seeing is the initial SPF delay that is set to 5 seconds, i.e., after receiving a new LSA, the router schedules the SPF run to take place 5 seconds after the arrival of this new LSA. It is expected that there may be more LSAs coming during this period, so a SPF run after 5 seconds will process all of them at once. These 5 seconds constitute the major part of the delay you are seeing. There are also other timers in place (LSA generation delay in particular) but they should not be as important right now.

What you could do is to reduce the initial SPF delay down to a reasonable time, say, 500 ms. The command is:

router ospf 1

timers throttle spf 500 1000 10000

Read more about the command here:

http://www.cisco.com/en/US/docs/ios/12_2s/feature/guide/fs_spftrl.html

Best regards,

Peter

Customers Also Viewed These Support Documents