Does anybody know how exactly this is kept clean? I would assume that when a prefix with a ref to the as-path reftable is no longer in a rib , the refcount of the entry is decremented and at zero the ref is cleaned up.
I seem to have stale data in mine, this example concerns a prefix leak from AS30071 (a peer network) which is no longer happening (i.e, I do not appear to see nor select these paths) #sh ip bgp paths _30071_7018 Address Hash Refcount Metric Path 0x52866F14 954 7 40 30071 7018 26415 i 0x556E1A78 1234 4 40 30071 7018 71 i 0x547CED9C 1234 37 40 30071 7018 71 i 0x54F383F8 2708 10 40 30071 7018 i 0x5E20558C 2885 4 40 30071 7018 40912 i I see this across a GSR peering router running 12.0(SY), a 7600 PE router running 12.2(33)SRC1 and a 65K PE router running 12.2(33)SXH2a. is this intended behaviour (not to decrement refcounts) or a bug? and if so, what constraints exist to prevent this reftable consuming huge amounts of RAM (i.e , if somebody were to spam it with multiple bogus AS-paths) ? Thoughts? Dave. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
