[Xorp-hackers] Accessing RIB Database Questions

[Francisco Rodriguez]

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?

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?

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?

Cheers,
Francisco 
 


-----Original Message-----
From: Bruce M. Simpson [mailto:bms at icsi.berkeley.edu] 
Sent: 20 February 2008 15:34
To: Francisco Rodriguez
Cc: 'Pavlin Radoslavov'; xorp-hackers at icir.org
Subject: Re: [Xorp-hackers] Dummy Fea Matters

Francisco Rodriguez wrote:
> The next step that I'm looking to do is to access the RIB database. I'm
not
> 100% sure if accessing to the RIB has to be done through the use of XRLs
or
> not. For this, I'm planning to write an application (I guess a sort of
XORP
> Process) which needs to have the capability to speak to XORP processes, in
> this case the RIB, and that make other tasks no related with XORP. Any
> insight that you could give me to start this will be much appreciated. 
>   

I recommend you use XRL. There is a "RIB direct" interface but that is 
in there largely as a backdoor for testing purposes and I would not 
condone its use for new code, but for a prototype it may be much easier 
for you to use.

Watch for asynchronicity. All 'Xrl*Client' class 'send*' methods require 
that you pass a callback parameter and yes these things may happen 
asynchronously, it's RPC after all.

At the moment XRL is best called from C++. Certainly all the client 
bindings depend upon it.

It is a tricky problem to solve unless you reimplement libxipc in a 
language other than C++, because the XRL sender classes require XORP 
event loop and callback semantics. These expect C++ linkage i.e. the 
instance you pass to it must be derived from XorpCallback.

How we deal with this in shell scripts, is just to use the call_xrl 
tool, however this obviously means you block waiting for each XRL call 
to execute, and it also doesn't let you implement XRL targets outside of 
C++.

I tried to solve this in SWIG the other day, but I can't get my head 
around how to write typemaps at the level of wrapping we require (ie 
references to callback types). Hint: XRL targets themselves are actually 
easy enough to wrap in SWIG-- you just need to instantiate an 
XrlStdRouter from outside and pass that in.

Clients are harder because of asynchronicity.

Someone really needs to sit down and solve the scripting language 
wrapper problem.

What would be really cool is if someone slapped together a Bouml plug-in 
and plug-out which allows XORP XIF RPC specifications to be expressed in 
UML. I think you can even do this in Python now.

This shouldn't be too difficult as the XIF syntax is C-like and the 
grammar isn't at all complex, and it will let you visualize the XIF 
interfaces as... nice shiny standard diagrams.

cheers
BMS