<div> </div><div>Hi Jörg,</div><div> </div><div>Thanks for confirming my hypothesis.</div><div> </div><div>We run 5.2.0gT183, which is quite old, I know, but in fact we are decommissioning most of Brocade gear and prefer not to bother with testing and validation of the new bugs^W software.</div><div> </div><div>Things have been reasonably stable for us, but our NOC has seen this issue a few times during last year or two. Normally guys don't bother to troubleshoot, they just go ahead with planned/urgent reboot, thanks to the fact that CER reboots tremendously quickly.</div><div> </div><div>But at some point I came around to enjoy the hunt for a less brutal way to fix this state. Didn't succeed a lot though :)</div><div> </div><div>>debug ospf <spf, adj, bfd, error)</div><div> </div><div>I haven't found any debug option for SPF throttling. As SPF never runs, "debug ip ospf spf" shows nothing.</div><div> </div><div>>timers throttle spf <span>5 1000 90000</span></div><div> </div><div>Thanks for the idea, I tried to play around with these timers but it doesn't affect the broken negative delay. Not sure I completely understood what you meant by "set different timers and reboot". Why reboot? You think that we might reproduce it this way?</div><div> </div><div>We don't have any SPF throttling configured, so, as can be seen from my output, these timers are set to 0 by default. This means, if I correctly understand the Cisco-like logic of NetIron software, it should run SPF on demand as frequently as it receives LSA updates. It doesn't care for any CPU spikes during SPF calculation, even if we had them. But we don't as of "show cpu-utilization detail | include ospf".</div><div> </div><div>This router doesn't struggle a lot with OSPF nor with anything else, it just carries less than 100 LSAa, pure MPLS core IGP (with TE), signle area, just two neighbors (uplinks) + BFD. As I said above, all the LSA flooding and neighbor state machinery works well. I see that it updates LSAs in the OSPF database as appropriate but the routes are stuck even if the corresponding interface/neighbor goes down.</div><div> </div><div>Well, I am not expecting any real help, rather just sharing my observations :)</div><div> </div><div>What is strange, however, is that routes are still active even if the next-hop interface goes down. AFAR, this should be treated at the pure data plane level: no forwarding next-hop — no FIB entry. However the routes are still active, both as of "show ip route", and "show ip ospf routes". This makes me think that it might be something beyond OSPF. I am not an expert in Brocade implementation details though.</div><div> </div><div>Regards,</div><div>Pavel</div><div> </div><div> </div><div> </div><div>03.08.2017, 18:21, "Jörg Kost" <jk@ip-clear.de>:</div><blockquote type="cite"><div><div style="font-family:sans-serif;"><div style="white-space:normal;"><p>Hi,</p><p>this looks like an integer overflow and could be a bug. SPF will never run with minus timer and I wonder which condition will trigger this.</p><p>What versions are your running?</p><p>I would start with<br />debug ospf <spf, adj, bfd, error)<br />show cpu-utilization detail | include ospf<br />show ip os neighbor</p><p>and maybe try and set different timers and then restart the router?<br />E.g.<br />router ospf<br />timers throttle spf <span>5 1000 90000</span></p><p>Jörg</p></div></div></div></blockquote>