Sorry Andrew, when I wrote this:<div><br></div><div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">

What concerns me is that once upon a time we used Nagios/NetSaint,</blockquote><blockquote>> big-brother, cricket, MRTG, and looked at Rancid, Cacti, OpenNMS and</blockquote><blockquote>> ZenOSS.</blockquote><blockquote>

> Have we moved in the wrong direction?</blockquote></div><div><br></div><div>I was talking about the organisation I work for, not the AusNOG community.</div><div><br></div><div>Phil<br><br><div class="gmail_quote">On Thu, Jul 8, 2010 at 8:43 AM, Andrew Fort <span dir="ltr"><<a href="mailto:afort@choqolat.org">afort@choqolat.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Thu, Jul 8, 2010 at 1:56 AM, phil colbourn <<a href="mailto:philcolbourn@gmail.com">philcolbourn@gmail.com</a>> wrote:<br>


> Again, that you for sharing your use of network management tools.<br>
> I have roughly tallied the main products mentioned: (I counted OpsView as<br>
> Nagios+MRTG)<br>
> Nagios  7<br>
> MRTG  3<br>
> Cacti  4<br>
> RANCID  5<br>
> and notably<br>
> PRTG  2<br>
> Collectd  2<br>
<br>
</div>I don't know why collectd, something which does very little, fits the<br>
unix pipeline mentality, and is thus incredibly useful for sysadmins<br>
and toolwriters, is "notable", but it's pretty good :).<br>
<div class="im"><br>
> Many use custom in-house-developed databases, scripts and tools.<br>
<br>
</div>The "every network is different" bit applies here.  Turns out most of<br>
the scripts people use that are custom are tying together their<br>
pipelines.<br>
<br>
Because your network (or gear) may be service oriented, your database<br>
probably has customers and services in it, too; that's fine, but it's<br>
going to differ from a content provider who has only peers and mostly<br>
runs a SP BGP kinda network.<br>
<br>
And finally because you'll come at things from different levels of<br>
requirements, maturity, time/money budgets.  Letting protocols deal<br>
with most of the issue without them being modelled seems generally<br>
fine.  At some point you're going to need to automate some knobs, at<br>
which point you do the extra work.<br>
<div class="im"><br>
> A significant number use commercial products.<br>
> Most described alarm/event/performance management or configuration backup<br>
> products<br>
> A few mentioned configuration generation systems.<br>
<br>
</div>No-one mentioned how to actually deploy that stuff to routers.  What<br>
if I have to deploy to 10 different hardware platforms and<br>
so-on.  Are people just wrapping RANCID scripts for this?   (I used to<br>
do it this way, quite handy).  At some point years ago I needed<br>
something a little more complicated and so had the idea for an agent<br>
to manage these CLI connections.  I wrote that<br>
(<a href="http://code.google.com/p/notch" target="_blank">http://code.google.com/p/notch</a>) open source after having written it<br>
at my last employer.  But mostly it's just been my itch to scratch.<br>
<br>
What other tools are people using for deployment of configuration to<br>
routers?  I mean everything from config + bootp/dhcp to in-place<br>
automation.  I'm less interested in the "we use 5620 SAM" (Alcatel's<br>
sales droids don't have to work hard here - it really doesn't suck!),<br>
but more interested in the "here's how we do that for 5 different<br>
vendors' gear".  That's the problem I've been interested in solving<br>
with open source software, and IMO it's better than the commercial<br>
approaches here.<br>
<div class="im"><br>
> Does that seem about right? Are these typical of what network operators are<br>
> using?<br>
<br>
</div>In Australia, yes.  An exhaustive list?  Certainly not.<br>
<div class="im"><br>
> No one mentioned (other NMS products that I have heard of) HP OpenView,<br>
> Tivolli, NetCool, cricket, OpenNMS, ZenOSS or even SNMP2XML ;) ?<br>
<br>
</div>Plenty of people use OpenNMS and ZenOSS.  I've a little experience<br>
with ZenOSS and its Python is not a good posterboy for the language<br>
(good Perl == Radiator.  good python == most anything except zenoss,<br>
it seems).  It's relatively powerful, but I dislike the "we do<br>
everything" approach, personally.<br>
<div class="im"><br>
><br>
> <br>
<br>
</div>What do you mean; people are apparently using less "integrated" NMSes,<br>
so this is a bad thing?  If so, I disagree.<br>
<br>
Big NMSes, million dollar software with $3000/day consultants, should<br>
this be encouraged?  I think not.  Instead, start from the ground up,<br>
with a few basic requirements.  You don't need to spend big money to<br>
do that.  Conversely, a million dollar price tag doesn't mean they<br>
have customers who use the software to do what you do. Shocking, I<br>
know.  The important part is that you need your best operators,<br>
architects and engineers to talk about this long enough to get a set<br>
of requirements and a design isolated.<br>
<br>
Again referencing Stephen Stuart's NANOG26 presentation about these<br>
things: "perfect is the enemy of done.".<br>
<font color="#888888"><br>
-a<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Phil<br><br><a href="http://philatwarrimoo.blogspot.com">http://philatwarrimoo.blogspot.com</a><br><a href="http://code.google.com/p/snmp2xml">http://code.google.com/p/snmp2xml</a><br>

<br>"Someone has solved it and uploaded it for free."<br><br>"If I have nothing to hide, you have no reason to look."<br><br>"Any sufficiently advanced technology is indistinguishable from magic." Arthur C. Clarke - Who does magic today?<br>

<br>
</div>