getting packet drop after using the command ip ospf dead-interval minimal hello-multiplier 5

[Nirvickchopra]

I have two point to point WAN links between two locations. under primary link interface I issued the command ip ospf dead-interval minimal hello-multiplier 5. After this if I ping secondary links ip (other location) I am getting lot of request timed out which was not there when no command was issued. More over if this secondary link becomes primary (after failover) this drop of packets if not observed. Not able to resolute what can be the issue.

[Peter Paluch]

Hello,

Try checking your CPU load using the show process cpu sorted on both routers interconnected through the WAN links and please post the first 10-15 lines. OSPF Fast Hellos can easily incur increased CPU load which might contribute to the packet losses.

In addition, are you using static neighbor statements in your OSPF config, or are you discovering your OSPF neighbors dynamically over the WAN circuits?

Can you actually try pinging not from router to a router, but rather from one station behind one router to another station behind the other router? I simply want to avoid the pings being generated and replied to by the routers. Can you confirm the packet losses in such setup as well?

Best regards,
Peter

[Nirvickchopra]

Hi Peter,

  The CPU utilization is not getting affected much only 2% increase in it that I don't think will harm.

No static neighbor command is there. 

And ping when done between two stations behind those links works fine. But on the link the packet drop is there. 

The packet drop % is around 10% after this command. But when I replaced ip ospf dead-interval minimal hello-multiplier 5 command with ip ospf hello-interval 1 the packet loss is just 1%. According to my understanding in the earlier command it will send 5 hello packets in 1 sec and in the later one it will send just 1 hello packet per sec. If CPU utilization is not getting hampered then I dont think it should be a problem.

Note: The same scenario is there with two other locations as well but no such issue over there.

[Peter Paluch · Accepted solution]

Hi,

In IOS, responding to ICMP pings has a low priority. Therefore, if there is anything more important to do at the moment a ping comes in, IOS will first handle the important issue and only then it will care about responding to pings. Handling OSPF hellos should be more important than responding to pings, and that is why you probably see the ping losses - because, even though the CPU is not overloaded, it has more important work to do.

That is why I asked you to ping through the link but not make the routers on the link the source and destination of those pings. If I understand you correctly, when you did a ping using two stations behind the routers, there were no packet losses. When you pinged directly from a router to its neighbor, the packet losses were there. Right?

If this is what you observed then I believe you are simply experiencing the way IOS handles less important traffic when it has more important work to do. I would personally do the packet loss test using the two stations behind the routers, optionally using some kind of traffic generator that allows creating a flow of differing intensity and evaluate the losses, but so far, I do not believe that there is a cause for concern.

Best regards,
Peter

[Nirvickchopra]

Hi, 

I completely understand that icmp has low priority but this thing is particulary just for one specific link. Other link to the same location and other links to different locations were abloutely fine. This is not a link issue that I have checked.