[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 14:43:37 +0100
On Fri, Nov 04, 2005 at 01:53:16PM +0100, Patrick Marc Preuss wrote:
> > --- Ursprüngliche Nachricht ---
> > Von: Kristian Larsson <kristian@juniks.net>
> > An: Patrick Preuss <deathdealer@gmx.net>
> > Kopie: xorp-hackers@xorp.org
> > Betreff: Re: [Xorp-hackers] AW: [Xorp-users] Does xorp latest CVS have
> > some problem with the export command?
> > Datum: 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.
>
> Yes thats right.
Great!
> >
> > > > 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.
>
> Yes for the most things right, but i have experrenced on IOS if you
> configure in 12.3T line "crypto pki ..." you would be warned in 12.4 line
> this command is obsolete and will be replaced with "crypto ca ...",
> underlying the same config. its only smallthings like a change from ospf4 to
> ospf in the nameing which should be replaced by such a mechanism.
> While loading the saved config this is done sillent;-) Nice the system comes
> up and you have the things running;-) I think this would be nice so you can
> upgrade routers at remote locations, my company has 500 locations all over
> Europe, so you can't drive to any routerdo this by hand.
I still think it's dangerous.
What if you just wanna try out a new version, you
find out it sucks. You switch back. But the new
xorp has rearranged your configuration file so now
the old version won't accept it.
Warning is enough ;)
> > I don't really understand what you mean with the
> > AAA system?
>
> aaa stands usualy for autentication, authorisation and accounting.
> With this you can say user a can do all things on the router, user b can not
> or can only edit interface config or can change the state of interfaces but
> is not allowed to edit routing processes. You can use this subsystem for
> Dial-In, ipsec and so on.
I am aware of what it is. I've setup a numerous
TACACS solutions ;)
What I don't understand is how this automagic
check of configuration files will affect AAA?
Kristian
> >
> > Kristian
> > >
> > >
> > >
> > > _______________________________________________
> > > Xorp-hackers mailing list
> > > Xorp-hackers@icir.org
> > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
> > _______________________________________________
> > Xorp-hackers mailing list
> > Xorp-hackers@icir.org
> > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
> >
>
> Patrick
>
> --
> best regards
> Patrick Marc Preuss
> ----------------------------------------------------------------------
> --
>
> "...a hundred billion castaways looking for a home."
> - Sting "Message in a
> Bottle" (1979)
>
> Telefonieren Sie schon oder sparen Sie noch?
> NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie