[Xorp-hackers] AW: [Xorp-users] Does xorp latest CVS have some problem with the export command?

Kristian Larsson kristian@juniks.net
Fri, 4 Nov 2005 11:41:54 +0100


On Fri, Nov 04, 2005 at 10:45:46AM +0100, Patrick Preuss wrote:
> 
> 
> 
> > We have already support for notifying the user if some configuration
> > statement is obsoleted: the "%deprecated" keyword in the
> > configuration template files. E.g., add "enabled: true"
> > config statement to an interface and try to start with or load that config
> > file. The rtrmgr will refuse and will print a predefined error
> > message.
> If something similar to this happens during startup, eg. Read the config
> parts and mark them as obsolete / error, the line in the show config could
> look like: "E> enable: true"

I'm not sure if I understand you correctly, but I
think I do and it's a great idea ;)
When xorp reads a line it doesn't know what to do
with (ie corrupt line, old configuration statement
...) it comments the line and marks it with error:
 E> or whatever is suitable.
 
> > Unfortunately this mechanism has its limitations. E.g., it can tell
> > you if a node in the configuration tree has been deprecated, but it
> > cannot tell you if the syntax of a node has been changed (as it
> > seems to be the case with the old/new policy for RIP).
> 
> In this case the config file should contain something like the "version
> 12.4" line on the cisco's so you could determine witch parts are differ 
> Between versions. So it will be possible to show parts witch have been
> obsolete, changed and so on. 
My patch to BugZilla 53 includes this :) 
> 
> > We don't have yet a functionality to rewrite old configs into new
> > ones, because we are still in the process of tweaking various
> > things, and such tool will quickly become obsolete (or an additional
> > burden to maintain and keep it up to date).
> 
> I think not to rewrite the config in all parts, may the rip is such a thing
> where it goes or not, have not thought about it yet, but for example:
> If the config changes from:
> 
> Protocols {
> 	Ospf4 {
> 		....
> 	}
> }
> 
> To 
> 
> Protocols {
> 	Ospf {
> 		.... keeps the same
> 	}
> }
> 
> The next time you write the config there will be the new version. 
> 
> You can add a mechanism for such rules, something like check config url, it
> will have the side effect for an "aaa" subsystem, you can control the access
> to statements for a user, group, like the Juniper does. I know this will be 
> A lot of work ;-) 
> 
> But for Production env. Where you might not have full access it would be a
> good idea.


I think it's both difficult and dangerous to have
XORP change stuff automatically for you, it would
be better to just warn and let the user decide on
action.

I don't really understand what you mean with the
AAA system?

   Kristian
> 
> 
> 
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers@icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers