%commands vs. @commands

[john heasley]

Wed, Jun 08, 2005 at 11:23:20AM -0400, Ed Ravin:

> And then, to keep code changes to a minimum,  build @commands and %commands
> automatically from @commandtable.  Here we don't care about the order of

> Any thoughts from the RANCID maintainers about this?  I'll be happy to
> test this out and submit patches.  The fragments above work as expected
> when I tested them in isolation.

I've never considered it much of a burden, but that change would be ok
by me.

> > I'd like to
> > prune out all the commands I know my switches/routers don't support
> > (or in the case of write term, will always support). Do I need to
> > add/remove any new commands to both lists?
> 
> Yes, you would need to edit both lists.  Or use the code above so that
> there's only one list.
> 
> On the larger issue of pruning out commands, note my previous (unanswered)
> query to the list about running both "show running-config" and "write term".
> RANCID's philosophy seems to be "send all commands, let RANCID sort 'em out
> afterwards".  This makes sense because the xxxrancid programs don't talk
> directly to the router, the xxxlogin program does that and produces an
> output file that is presented to xxxrancid for parsing.  RANCID happily
> ignores commands that aren't supported on the device.  And if one day you
> upgrade IOS and one of those commands is supported, then all the better,
> you get more data in your repository.  In almost all cases, there's barely
> any penalty for sending the unrecognized commands, so why bother pruning
> them?  My query about "show running-config" / "write term" was due to
> a router here that takes 30-45 seconds to dump its config - which to my
> mind was a penalty worth trying to program around.  Or maybe not -
> remember, RANCID connects to multiple devices in parallel, so unless there
> are dozens of devices at your site that are slow to dump their config,
> the RANCID won't take that much longer to finish.

I had hoped that andrew would reply; he remembers much more history than
i do.

but, we're not trying to drop support for older devices; there are folks
who use really old boxes (eg ags) in places where it is difficult to get
equipment and then there are versions of IOS that actually run for a year
w/o crashing so why upgrade them (eg 11.1 on 2500) if there is no compelling
reason.

that aside, given that rancid does it's thing in the background, I see no
reason to remove the compatibility.  I'd rather work on the configurable-
rancid idea, where one can define the commands they want rancid to run, or
skip.  This way, possibly one could use a *login script (clogin -s) which
has the intelligence to skip unnecessary commands.  but, thats TBD.