On Tue, 2009-06-23 at 11:18 -0400, Steffen Weiberle wrote: > On 06/23/09 11:08, Sebastien Roy wrote: > > Given two equivalent routes for a given destination, the route chosen > > for a given packet to that destination is not deterministic. The > > current implementation tries to be clever and alternate which default > > route is used when communicating with a new destination, and again, this > > is unrelated to the source address used to communicate with that > > destination. > > For a given destination, what is the 'timeout' value, and does it change > based on initial creation, or last use timeout? I'd ask on James' great > blog, however comments are closed :)
This is a function of the IRE cache, which is not an administrative construct, but rather an implementation detail[1]. The route used for a given destination is cached in that destination's "IRE cache" entry, and that IRE cache will stick around forever, or until it is "reclaimed" either due to a full IRE cache "bucket" or by the memory allocation subsystem when the system is running low on memory. The code that cleans these IREs up does not do so deterministically (e.g., it doesn't simply free all "unused" IREs). It frees some fraction of IREs based on an algorithm that prefers temporary IREs, then "unused" IREs (where "unused" is 60 seconds). Thus, one cannot depend on unused IREs being freed after 60s, as this is only done when the system detects that it needs to clean things up. -Seb [1] Thankfully, IRE caches are going the way of the dodo bird, thanks to the datapath refactoring project (http://www.opensolaris.org/os/project/ip-refactor/). _______________________________________________ networking-discuss mailing list [email protected]
