[Xorp-hackers] Accessing RIB Database Questions

[Pavlin Radoslavov]

Francisco Rodriguez <f.rodriguez at lancaster.ac.uk> wrote:

> 
> Thanks for your reply. Actually, I was looking into using XRLs since it is
> the natural IPC for XORP processes. 
> 
> My current objective is to be able to access the final RIB table and any
> particular routing protocol table from an application that doesn't
> participates on the XORP (router), but that can interact with different
> process by doing some queries to them. I've been revising RIB's XRLs targets
> and some questions:
> 1) From my understanding the XRLs Targets that RIB implements for doing such
> thing in XORP are the redistribution XRLS:
> + rib_0_1_redistenable4/6 and disable
> + rib_0_1_redisttransaction_enable4/6 and disable
> + rib_0_1_redistenable4/6 and disable
> To me it seems like these XRLs have been design only for the routing
> protocol processes, so I'm not entirely sure that I can call them unless I
> register the other process (application) that might want to use such XRL I
> won't be able to use them, I'm right? Then the next questions would be, do I
> need to register my application? And, where do I register it?

For an application to use the above XRLs that application obviously
needs to be XRL-aware. Basically it needs to use the libxipc library
to register with the XRL Finder with its own target name. See the
"Introduction to Writing a XORP Process" document and the source
code of static_routes for more info on the subject.

Then this process needs to implement some of the following XRL
targets as appropriate:
redist4.xif
redist6.xif
redist_transaction4.xif
redist_transaction6.xif

> 2) Also, looking at the parameters that these XRLs receive, it doesn't seem
> to me that I can use them for querying the final RIB table. For example,
> look at the following XRL:
> XrlCmdError rib_0_1_redist_enable4(
> 	// Input values,
> 	const string&	to_xrl_target,
> 	const string&	from_protocol,
> 	const bool&	unicast,
> 	const bool&	multicast,
> 	const IPv4Net&	network_prefix,
> 	const string&	cookie);
> Them my questions would be, is the final RIB table being declared as
> protocol in order to access it? How does the rtrmgr process access such
> table when the CLI request to see the final routing table? Is there a
> different method or XRL able to use in order to access the final RIB?

If you use the special string "all" as the "from_protocol" it will
give you the final (winning) routes.

> 3) Also, I'm still a little bit unsure which processes would need to use the
> rib_0_1_de/register_interest4/6, are they only used for policy routing and
> redistribution? Do a redistribution request that doesn't filter any route
> would use it?

Currently it is used by BGP by the next-hop resolver mechanism.
The advantage of that mechanism vs the redist*.xif mechanism is that
your process will get updates only for the particular subnet address
you are interested at. The downside is the extra complexity
associated with it.

Hope that helps,
Pavlin