Mailing List Archive

trying to add Cisco clustering support to rancid -- almost done
I'm trying to add support for clustering into rancid, I'm on my second
attempt, and this time I'm almost done (I'll describe the process and
provide code when I'm done)... I've just got one question/problem to
solve before it is done (or at least testable):

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)

Any advice on this would be great...
trying to add Cisco clustering support to rancid -- almost done [ In reply to ]
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)

Its in clogin; look for this line:
send "exit\r"

Or you could add it to the list of commands in bin/rancid; I'd try
adding it to the end of $cisco_cmds. This may be harder, since
rancid looks for 'quit' to see if its done running all of the
commands; if it sees 'quit', than rancid figures its done with all
of its work and stops.

I'm not quite sure what needs to be changed so that you can have
quit commands to log out of parts of the cluster, but then still
have more commands left.

I don't know what cisco cluster stuff looks like, but for HFR support,
we had to add commands like these:
admin show diag
- which means to run show diag in admin mode. Does cisco support
anything sorta like
run_on cluster_node 3 show something
? If so, adding commands like these to the list of commands would
be trivial.

I just think that we are going to run into problems with rancid's
control logic if we want to spit a serias of commands like this to
some cluster:
show version
show diag
login cluster_node 1
show version
show diag
exit
login cluster_node 2
show version
show diag
exit
show running-config
exit
These embedded 'exit' commands are really going to mess things up.
rancid's control logic is really very simple right now; all that
it knows is that is runs a series of commands and that the last
command is 'exit', and that when it sees 'exit', its done & its an
error if there are commands left over.
--asp
trying to add Cisco clustering support to rancid -- almost done [ In reply to ]
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
trying to add Cisco clustering support to rancid -- almost done [ In reply to ]
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
>
>
>
>