[Xorp-hackers] RE: Xorp-hackers digest, Vol 1 #183 - 1 msg

Weaver John-JWEAVER1 John.Weaver@motorola.com
Fri, 26 Aug 2005 14:30:10 -0500


Sounds like a very interesting project although I am having a hard time
wrapping my brain around the XRL stuff.  I remember you telling once that
XORP can be brought up and read particular interfaces on its own and
configure itself.  How would I do this and is this possible with just TAP
interfaces?

Thanks,
John 

-----Original Message-----
From: Pavlin Radoslavov [mailto:pavlin@icir.org] 
Sent: Thursday, August 25, 2005 7:36 PM
To: Weaver John-JWEAVER1
Cc: xorp-hackers@icir.org
Subject: Re: [Xorp-hackers] RE: Xorp-hackers digest, Vol 1 #183 - 1 msg 

> The lib version of the xorpsh is prolly exactly what I need.  I would 
> think for the XORP project to be successful in an embedded market this 
> would be necessary.  Most of the switch/router projects I have done in 
> the past have always required many boot time decisions on how to 
> configure all the interfaces and protocols.  None of our systems have 
> ever had direct configuration by a user and almost always requires 
> run-time changes via applications that trigger off of upstream 
> database changes.  I hope I can come to a way to use XORP in this way 
> because I hate to think of the other vendor I will have to use if not.  
> Plus it puts me way behind schedule. ;) I guess I can always resort to 
> hacking out some scripts to try and configure things but it sounds 
> real risky and not very easy, especially since I don't know shell
scripting.

Yes, I think this is a very good idea.

Would you volunteer to extract the core xorpsh functionality in such
library? :) Otherwise, I am afraid that currently we don't have the spare
cycles to do this ourselves. We can add it to our TODO list, but it may take
a while before it is ready. So your best bet would be to invest in the shell
scripting solution, and eventually in the future you can switch to using the
library instead.
In any case, can you send us pointers to existing solutions (e.g.,
high-level description, API, etc).

Thanks,
Pavlin