Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: Alex Zinin (azininCISCO.COM)
Date: Tue Mar 27 2001 - 00:51:24 CST
As Curtis already explained, OSPF data is NOT preserved, but
recollected from the neighbors. That's why we go through the
LSDB resync process.
> Some people would rather have any effort available expended towards
> good software (or a real OS, if that crutch is needed). I can see
> bringing back BGP quickly, but the disasters possible with crunched
> OSPF data are soooo much worse. 80k routes causing cyclic crashing
> and propagation, anyone?
>> I hope it is clear by now that nobody is trying to solve OSPF
>> bugs leading to crashes with additional mechanisms in the protocol.
>> However, realistically speaking, SW will always have bugs, and
>> the question is how one would like to react on a crash. If you
>> want the process to remain down---no mechanisms are required.
>> If some people want to try to bring it back up there definitely
>> are people who want to do it without resetting the forwarding
>> >> Or this way: would you not like your router to at least try to
>> >> bring the process that has just crashed back up with (of course,
>> >> with an oscillation prevention mechanism)?
>> > How about starting by not having the process/router crash to begin with?
>> > That would solve 99% of the problems that you are trying to address.
>> >> > Case B is even more interesting. The software crashed. Ok, so now I'm
>> >> > supposed to believe that crashing software can be fixed by adding MORE
>> >> > software and protocol extentsions, even though the original software
>> >> > didn't work well enough not to crash in the first place? Essentially my
>> >> > take on this is: I couldn't write robust software, so let me make the
>> >> > system more robust by adding more software!
>> >> Following your logic here we would probably have to remove
>> >> protected memory support from all CPUs and OSes and have all programmers
>> >> fix all their bugs in all their programs... Oh, dear...
>> > Page fault caused by de-referrencing a virtual address while running in a
>> > state that can be pre-empted is very very very different from a page fault
>> > caused by a process that does not pay attention to the heap boundaries...
>> > Alex