|CacheTable (string tablename, Safi safi, BGPRouteTable< A > *parent, const PeerHandler *peer)|
|int||add_route (InternalMessage< A > &rtmsg, BGPRouteTable< A > *caller)|
|int||replace_route (InternalMessage< A > &old_rtmsg, InternalMessage< A > &new_rtmsg, BGPRouteTable< A > *caller)|
|int||delete_route (InternalMessage< A > &rtmsg, BGPRouteTable< A > *caller)|
|int||push (BGPRouteTable< A > *caller)|
|int||route_dump (InternalMessage< A > &rtmsg, BGPRouteTable< A > *caller, const PeerHandler *dump_peer)|
|const SubnetRoute< A > *||lookup_route (const IPNet< A > &net, uint32_t &genid, FPAListRef &pa_list) const|
|void||route_used (const SubnetRoute< A > *route, bool in_use)|
|RouteTableType||type () const|
|string||str () const|
|bool||get_next_message (BGPRouteTable< A > *next_table)|
|int||route_count () const|
|string||dump_state () const|
|EventLoop &||eventloop () const|
RefTrie< A, const CacheRoute|
< A > > *
|const PeerHandler *||_peer|
The XORP BGP is internally implemented as a set of pipelines consisting of a series of BGPRouteTables. Each pipeline receives routes from a BGP peer, stores them, and applies filters to them to modify the routes. Then the pipelines converge on a single decision process, which decides which route wins amongst possible alternative routes. After decision, the winning routes fanout again along a set of pipelines, again being filtered, before being transmitted to peers.
Typically there are two FilterTables for each peer which modify routes passing down the pipeline, one in the input branch from that peer, and one in the output branch to that peer. A FilterTable does not store the routes it modifies, so a CacheTable is placed downstream of a FilterTable to store routes that are modified.
In the current code, a CacheTable isn't strictly necessary, but it simplifies life for all downstream tables, because they know that all routes they receive are stored in stable storage and won't go away without explicit notification.
In the future, it is likely that the CacheTables in the outgoing branches will be removed, as they waste quite a bit of memory for very little gain. However, they have not yet been removed because their internal sanity checks have served as a valuable debugging device to ensure consistency in the messages travelling down the outgoing branches.