where was my white knight....

Leigh Porter leigh.porter at ukbroadband.com
Tue Nov 8 16:15:03 CST 2011


On 8 Nov 2011, at 21:37, "Leo Bicknell" <bicknell at ufp.org> wrote:

> In a message written on Tue, Nov 08, 2011 at 04:22:48PM -0500, Christopher Morrow wrote:
>> I think actually it wouldn't have caused more validation requests, the
>> routers have (in some form of the plan) a cache from their local
>> cache, they use this for origin validation... there's not a
>> requirement to refresh up the entire chain. (I think).
> 
> I kinda think everyone is wrong here, but Chris is closer to accurate.
> :P
> 
> When a router goes boom, the rest of the routers recalculate around
> it.  Generally speaking all of the routers will have already had a
> route with the same origin, and thus have hopefully cached a lookup
> of the origin.  However, that lookup might have been done
> days/weeks/months ago, in a stable network.
> 
> While I'm not familar with the nitty gritty details here, caches
> expire for various reasons.  The mere act of the route changing
> paths, if it moved to a device with a stale cache, would trigger a
> new lookup, right?
> 
> Basically I would expect any routing change to generate a set of
> new lookups proportial to the cache expiration rules.

Which may very well fail because all the routing is hosed. I'm not all that familiar with the potential implementation issues, but I would think that network-local caches would be in order. 

Even with local caches, I would expect a high incidence of change to trigger something sensible to mitigate this kind of craziness from happening. I am sure enough people have had incorrectly scaled RADIUS farms blow up when a load of DSLAMS vanish and come back again not to repeat such storms.


--
Leigh Porter


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________



More information about the NANOG mailing list