[Xorp-users] Re: Adapting routing daemon to XORP

[Mark Handley]

[NOTE: this message should really be on xorp-hackers - I've added that
to the cc list, but please send replies only to xorp-hackers]

>I am trying to port an existing routing protocol implementation to XORP and 
>I am really lost. What should I do first? How can I identify which points 
>should I touch in the code? It seems to me that I would need to map all 
>interaction with the linux forwarding table, the management functions and 
>the part that deals with sending/receiving control packets into XRL 
>interfaces. But, how should I do this? From where should I begin?


An ideal XORP routing protocol should only interact with the outside
world through XRLs, because then it won't need to run as a privileged
process, and it will be much more portable between OSes.  But that's
the ideal - you can make progress incrementally towards that goal.
Hopefully between each of these steps you'll have a working protocol
again - just more of it will use the XORP interfaces.


Step 1: The first place to start is to figure out where the existing
process receives packets, and handles timers.  Normally a XORP process
would do all it's I/O and timers from the main XORP eventloop.  What
you do next depends on whether the process you're porting is single
threaded or multi-threaded.

Single-threaded:

You really need one place where timers and network events are handled.
You can craft the XORP eventloop onto the processes original
timer/event handling framework, or port the existing processes
eventloop to use the XORP eventloop.  The latter would normally be
preferable.  Thus you replace calls to select with callbacks from the
XORP eventloop.

Multi-threaded:

The XORP libraries aren't thread-safe, so you'll need to add a new
thread to handle all the XORP XRL handling.  This should have it's own
eventloop.  The rest of the original process can be left unchanged,
except where it needs to interface with the XRL thread.


Step 2: You want to identify the places where the original process
sends routes to the kernel.  This code needs to be replaced with calls
to send XRLs to the XORP FEA process to add and delete routes.


Step 3: You want to identify the places where the original process
finds out about the existing network interfaces and their IP addresses
(assuming it's an interface-based protocol, like RIP, OSPF, IS-IS,
etc, rather than like BGP).

You'll need to add a framework to register interest in interfaces and
addresses, so that when IP addresses change, or interfaces come up and
down, you routing protocol finds out about them.  For a model of how
to do this, you might look at the RIP XrlPortManager class, and it's
use of IfMgrXrlMirror.


Step 4: You want to add code to monitor the liveness of the RIB
process.  If the RIB ever goes down, your process should terminate
itself.  This avoids spurious copies of the routing process ever
getting left behind.  For a model of how to do this, look at the RIP
XrlProcessSpy class.


Step 5: You want to re-write the routing protocol configuation so it
is configured using XRLs from the router manager rather than by
reading its own configuration file.  Also note that XORP processes can
be reconfigured on the fly by the router operator.  


Step 6: You want to replace the actual packet send/receive code with
calls to XRLs to do this for you.  This is the least critical change,
and the state of using the FEA code to do this relaying varies
somewhat depending on what you're trying to do - not all protocols are
currently supported.



Hopefully this helps get you started.  If you've not seen it, there's
also the short guide to writing a XORP process:
  http://nrg.cs.ucl.ac.uk/mjh/tmp/xorpdev101.pdf
This is also in the xorp/docs/xorpdev-101 directory in CVS.  This
probably isn't sufficient, but might help get you started.

Feel free to ask for more help as you need it, ideally on the
xorp-hackers list.  That's where the people best qualified to help you
tend to hang out.

Cheers,
	Mark