[Xorp-hackers] loading complete routing tables

[Ratul Mahajan]

 > Does this make sense?

yes; i agree that the features i was looking for may not make sense from 
a functionality testing perspective.

i wanted them to compare the performance of xorp and my-xorp (xorp with 
local modifications) under "realistic" conditions. for realism i wanted 
to use table_dumps and bgp_updates archived by routeviews.

cheers.


Mark Handley wrote:
> 
>     so i looked at the harness code some time back and came away with the
>     following impressions regarding the current code:
>       - it (harness/Peer::send_dump) does not support mtrd records of type
>     TABLE_DUMP (entire table dumps). it assumes BGP4MP (dumps of routing
>     updates).
>       - it does not support having updates from multiple peers in the same
>     mrtd file (as would be generated by a router with many peers).
> 
> 
> Sounds like these serve different purposes.  So far we've wanted to  
> test XORP, including the message parsing, so replaying update messages 
> is good for this purpose.
> 
> What you describe is loading a previously stored router state.  We could 
> in principle build such a load function into BGP for testing purposes.  
> As we're event-driven, this would have to be implemented by effectively 
> mapping the route state into update messages, or we'd  not end up with 
> the right metadata stored in the routes.  But a more tricky problem 
> concerns filters.  There's no way to load state in after the import 
> filters as we only store routes prior to filtering.  Thus the only way 
> to do a table load for a config file that was stored from a 
> post-import-filter table dumb would be to load it on a XORP router with 
> *no* import filters in place.  This means you can't do it for a router 
> with EBGP peerings configured, because they must have filters.
> 
> Thus I can't really see any way to load a table dump into a XORP BGP and 
> end upn with the correct behaviour unless that table dump were itself 
> stored from a XORP router, and hence represents pre-filtered routes.  
> Loading a post-filter table dump into a XORP router that had import 
> filters configured would end up with the filters being run on the stored 
> data, which simply won't result in the right behaviour.
> 
> Does this make sense?
> 
>  - Mark
> 
>