trying to add Cisco clustering support to rancid -- almost done

[Chris Stave]

I just realized that this didn't go out to the whole list...


It was mostly a scope of control issue --  I'm not responsible for
deciding that each switch gets an interface, but I am the one who sets
up Rancid, so I did what I could where I could. Right now it's a
little messy, with configs for one dorm going several places
the 3550 group
the clu1 group
the clu2 group
and the clu3 group
 because just listing them as seperate types, but with the same ip
address ended up with configs being overwritten as it went down the
list.

but it seems to work for now (I'm missing 'write term' frequently, but
by the 4th round of collection most of them get caught)

clustering works as follows:
there is pretty much only one command once it is setup -- rcommand,
which connects to the cluster member, if enabled you stay enabled, if
not you can still rcommand, but you need to enable on the cluster
member.  Once you're on the cluster member it is the same as being on
the switch directly.  From a cluster member you can't rcommand to
anything else, you need to exit back to the cluster commander first.
There is no way from the cluster member to completely drop the
session, you can only go back to the commander.  Besides hostname
(here we use an _0, _1, _2, etc. at the end of the hostname) theres
not much you can do to tell that you're on the clustermember.



On 5/13/05, Justin Grote <justin at grote.name> wrote:
> Andrew Partan wrote:
> 
> >On Tue, May 10, 2005 at 11:37:08AM -0400, Chris Stave wrote:
> >
> >
> >>at the end of processing a switch rancid logs out of the switch; where
> >>is this done?  I need to add a second 'exit' command there, but I'm
> >>not sure where it does this.  (a line number would be completely
> >>ideal, since my knowledge of scripting is a bit questionable)
> >>
> >>
> Just out of curiosity, is there some reason you can't just assign IP
> addresses to the VLAN interface of the individual switches and capture
> normally? I know that it's not the most elegant solution, but you sure
> do seem to be going to a lot of work to achieve a goal that can be
> accomplished otherwise rather simply (plus you get the added granularity
> of one config per switch, rather than a giant cluster config).
> 
> --
> __________________________
> Justin Grote
> Network Architect
> JWG Networks
> 
> 
> 
>