Hi, Ulf Samuelsson wrote: >> From RFC2461: >> >> | REACHABLE Roughly speaking, the neighbor is known to have been >> | reachable recently (within tens of seconds ago). >> : >> | STALE The neighbor is no longer known to be reachable but >> | until traffic is sent to the neighbor, no attempt >> | should be made to verify its reachability. >> | DELAY The neighbor is no longer known to be reachable, and >> | traffic has recently been sent to the neighbor. >> | Rather than probe the neighbor immediately, however, >> | delay sending probes for a short while in order to >> | give upper layer protocols a chance to provide >> | reachability confirmation. >> >> > > It is all depending on the meaning of the word "recently". > You imply, that if timeouts have been triggered, then it is no longer > "recent", > but that is not the only interpretation, it is up to the implementer to decide > what is "recently".
That quoted text is just a "brief" description. The document has detailed state machine. > Therefore, if a timeout occurs due to no traffic, they must be probed before > they are garbage collected. It is what we do in PROBE state. > If this is not acceptable, how do you propose to solve the problem that you > cannot > make remote units inaccessible for more than a fraction of a second? How many neighbors do you want to maintain? I guess you have to increase the number of gc_thresh1. -- Hideaki Yoshifuji <hideaki.yoshif...@miraclelinux.com> Technical Division, MIRACLE LINUX CORPORATION -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
